Проверка прав доступа: кто и к каким системам должен иметь доступ

Права доступа к информационным системам — это не разовая настройка при найме сотрудника, а постоянно меняющийся актив, который требует регулярной проверки. В небольших компаниях нередко складывается ситуация, когда бухгалтер сохраняет доступ к складскому учёту после смены должности, бывший подрядчик продолжает входить в облачное хранилище, а единый администраторский пароль известен половине офиса. Каждое такое отклонение увеличивает риск утечки данных, ошибочных действий и финансовых потерь. Цель регулярной проверки прав — убедиться, что каждый человек имеет ровно тот доступ, который нужен для работы сегодня, не больше и не меньше, а любые лишние права своевременно отозваны и задокументированы.

Перед началом проверки полезно составить реестр всех систем, в которых хранятся данные компании или выполняются рабочие операции. В типичный перечень входят корпоративная почта, бухгалтерская программа, CRM, кассовое и складское ПО, банк-клиент, облачные диски, мессенджеры с рабочими чатами, системы видеонаблюдения, Wi-Fi, корпоративные ноутбуки и телефоны. К каждому пункту указывают ответственного администратора, способ входа, наличие двухфакторной аутентификации и категорию обрабатываемых данных. Без такого реестра проверка превращается в выборочный обход, при котором часть систем остаётся в слепой зоне и сохраняет устаревшие учётные записи годами.

Следующий шаг — описание ролей и принципа минимально необходимых прав. Для каждой типовой должности фиксируют, какие действия в каких системах допустимы: например, продавец-консультант видит остатки и оформляет продажу, но не имеет права менять цены поставщиков; менеджер по снабжению формирует заказы поставщикам, но не подписывает банковские платежи. Такой подход называют принципом наименьших привилегий, и он лежит в основе всех современных практик информационной безопасности. Когда роли описаны на бумаге, любые отклонения становятся видимыми: достаточно сравнить фактические права конкретного человека с эталонной матрицей и зафиксировать расхождения.

Процедура приёма на работу должна включать формальную выдачу доступов по утверждённой роли. На практике это выглядит так: руководитель направляет администратору заявку с указанием должности, перечня систем и срока действия учётной записи; администратор создаёт учётные записи, выдаёт временные пароли, требует их смены при первом входе и включает двухфакторную аутентификацию. Сотрудник под подпись знакомится с правилами обращения с информацией, обязательством не передавать пароли и порядком сообщения о подозрительных событиях. Все действия фиксируются в журнале выдачи прав, который хранится не менее трёх лет вместе с другими кадровыми документами компании.

Не менее важна процедура изменения прав при переводе сотрудника на другую должность. Распространённая ошибка — добавлять новые доступы поверх старых, не отзывая ненужные. В результате через несколько лет у опытного работника накапливается избыточный набор прав, который позволяет совершить почти любое действие в компании, что особенно опасно при кадровых конфликтах. Правильная схема: при переводе руководитель направляет заявку на пересмотр прав, администратор отзывает все доступы предыдущей роли и выдаёт новые согласно новой должности. Факт пересмотра фиксируется в журнале с датой, инициатором и итоговым составом прав.

Отдельного внимания заслуживает процедура увольнения и расставания с подрядчиками. Лишение доступов должно происходить в день фактического прекращения работы, а в случае конфликтного увольнения — до уведомления сотрудника, по согласованию с руководителем и юристом. Отзыв включает блокировку корпоративной почты, изменение паролей к общим учётным записям, удаление из мессенджеров, отключение VPN, изъятие пропусков, ключей и техники, а также проверку, не настроена ли пересылка писем на личный адрес. По итогам составляется акт сдачи доступов, который подписывают сотрудник, его руководитель и системный администратор.

Общие или обезличенные учётные записи — частый и опасный элемент инфраструктуры малого бизнеса. Под одним логином в банк-клиенте, на маркетплейсе или в CRM работает несколько человек, и при инциденте невозможно установить, кто именно совершил действие. По возможности от таких записей отказываются: каждому сотруднику выдают персональную учётную запись, а общую блокируют или превращают в технологическую с уникальным владельцем. Если общий доступ объективно необходим (например, для приёма заказов на единый ящик), его дополняют журналом дежурств и логированием действий, чтобы сохранить прослеживаемость и ответственность.

Привилегированные права администраторов требуют усиленного контроля. Под этим термином понимают учётные записи, которые позволяют менять настройки систем, создавать и удалять пользователей, выгружать массивы данных и обходить ограничения. Их выдача оформляется отдельным распоряжением руководителя, привязывается к конкретному физическому лицу и сопровождается обязательной двухфакторной аутентификацией. Для рутинных задач администратор использует обычную учётную запись, а к привилегированной переходит только на время выполнения конкретной операции. Действия с правами администратора по возможности логируются и периодически просматриваются вторым ответственным сотрудником или руководителем.

Регулярную проверку прав удобно проводить по календарю: полный пересмотр — раз в полугодие, выборочный — раз в квартал, экспресс-проверка по уволенным и переведённым — ежемесячно. На полной проверке руководители подразделений получают список своих подчинённых с фактическим перечнем доступов и подтверждают, что каждый пункт обоснован текущими обязанностями. Все спорные позиции выносятся на согласование с владельцем системы и собственником компании. Итогом становится подписанный отчёт о проверке с перечнем подтверждённых, отозванных и изменённых прав, а также списком учётных записей, оставленных активными для конкретных задач.

Доказательством того, что лишние права действительно сняты, служит совокупность артефактов: запись в журнале выдачи и отзыва прав, выгрузка из системы со списком активных учётных записей на дату проверки, скриншот настроек роли, акт сдачи-приёмки техники и подписанный сотрудником лист обязательств. Эти материалы хранят в защищённой папке с ограниченным доступом и используют при внутренних расследованиях, налоговых проверках, проверках со стороны контрагентов и при подключении к новым партнёрским сервисам. Отсутствие таких доказательств приравнивается к отсутствию контроля и существенно осложняет защиту позиции компании при инциденте.

Полезно дополнить процедуру проверкой технических аспектов: длина и сложность паролей, обязательность двухфакторной аутентификации для всех внешних входов, ограничение доступа к административным панелям по IP-адресу, отключение неиспользуемых учётных записей сервисов и интеграций, обновление паролей к Wi-Fi и сетевому оборудованию после увольнений. Параллельно стоит проверить, не остались ли в общих чатах ссылки и пароли в открытом виде, не настроены ли автоматические выгрузки данных на личные адреса, а также есть ли резервные копии настроек прав на случай ошибочного изменения. Эти проверки занимают несколько часов, но существенно повышают устойчивость бизнеса.

Информация в статье носит справочный характер. Конкретные требования к защите персональных данных, коммерческой тайны, банковской информации и сведений ограниченного доступа в Казахстане регулируются актуальным законодательством, отраслевыми правилами и договорами с контрагентами, и эти требования периодически меняются. Перед утверждением внутреннего регламента по управлению доступом, формы заявок, перечня обрабатываемых данных и сроков их хранения рекомендуется свериться с действующими нормативными актами на официальных ресурсах и при необходимости привлечь квалифицированного юриста, кадрового специалиста и специалиста по информационной безопасности с опытом работы в малом и среднем бизнесе.