«Процесс предоставления прав доступа часто воспринимается как рутинная операция ‘добавь-удали пользователя’. На деле это цепь событий, где формализованный запрос — лишь верхушка айсберга. Реальная задача — синхронизировать цифровую идентичность человека с его организационной ролью, при этом защитив систему от накопления избыточных прав и сохранив возможность контроля за каждым изменением.»
Как осуществляется предоставление учетных записей пользователей
Управление доступом в защищенных инфраструктурах выходит далеко за рамки простой регистрации в системе. Это сквозной процесс управления цифровой идентичностью сотрудника на протяжении всего его взаимодействия с организацией — от приема до увольнения. В международной практике он известен как identity lifecycle management, а его ключевая фаза — provisioning — непосредственно касается предоставления и настройки прав доступа. В контексте требований 152-ФЗ и ФСТЭК корректность этого процесса напрямую влияет на выполнение требований по защите персональных данных и информации ограниченного доступа.
Ключевые сценарии предоставления доступа
1. Прием нового сотрудника
Инициация процесса начинается с формализованного запроса от руководителя структурного подразделения. Такой запрос, часто в виде служебной записки или заявки в системе Service Desk, должен содержать не только ФИО, но и санкционированное описание требуемых уровней доступа. Обычно это ссылка на должностную инструкцию или стандартную роль (роль безопасности).
Что должно быть в запросе:
- Санкционирующая подпись ответственного лица (руководитель, куратор).
- Привязка к ролевой модели — указание на стандартную роль (например, «бухгалтер 1С», «разработчик DEV») или явный перечень информационных систем.
- Базовые атрибуты учетной записи — планируемое имя пользователя (логин), принадлежность к подразделению.
Важный нюанс: для доступа к системам, обрабатывающим персональные данные или гостайну, может требоваться дополнительное согласование со службой безопасности или отделом compliance.
2. Смена должности или обязанностей (Move)
Это самый сложный с точки зрения контроля сценарий. Формальный перевод сотрудника должен автоматически запускать процесс репроvisioning — пересмотра и актуализации прав.
- Добавление новых привилегий, соответствующих новой роли. Происходит на основе обновленного запроса.
- Отзыв устаревших прав (de-provisioning). Критичный этап, который часто игнорируется. Доступы от предыдущей роли должны быть явно отозваны, если они не нужны в новой.
- Изменение членства в группах безопасности Active Directory, LDAP или корпоративных порталах.
Отсутствие четкой процедуры для этого сценария — прямая дорога к «расползанию привилегий».
3. Увольнение сотрудника (Leave)
Процедура отзыва всех доступов должна быть синхронизирована с отделом кадров. Идеальная модель — единая точка входа для уведомления об увольнении (приказ), которая автоматически запускает процесс отключения.
Правильная последовательность действий:
- Блокировка (Disable) учетной записи строго в дату увольнения, указанную в приказе. Пароль изменяется.
- Удаление из всех групп доступа и ролей. Учетная запись изолируется.
- Выгрузка и архивация данных, связанных с пользователем (почта, личные файлы на корпоративных ресурсах), если это требуется по регламенту.
- Отложенное удаление (Delete). Саму учетную запись не удаляют сразу. Ее оставляют в заблокированном состоянии на период, определенный политикой архивации (например, 90 дней). Это сохраняет ссылки в журналах аудита и позволяет восстановить доступ к данным при возникновении спорных ситуаций.
Опасная практика: Создание учетной записи нового сотрудника путем копирования прав коллеги. Это кажется быстрым решением, но копирует не только стандартные права, но и все индивидуальные исключения и временные доступы, накопленные этим коллегой за годы работы.
Ползучее расширение привилегий (Privilege Creep) — тихая угроза
Это не единовременная ошибка, а системная проблема, которая накапливается месяцами. Механизм прост: сотруднику для разовой задачи временно дают доступ к папке, отчету или системе. После выполнения задачи доступ не отзывается. Через год таких «временных» прав накапливается десяток. Если на основе его профиля создают учетную запись новичку — тот получает избыточные, неконтролируемые возможности с первого дня.
Именно поэтому ФСТЭК в своих рекомендациях настаивает на регулярном пересмотре и аттестации прав доступа. Это не бюрократия, а единственный способ обнаружить и обрубить такие «ползучие» цепочки.
| Рекомендуемый подход (Соответствует лучшим практикам и требованиям регуляторов) | Рисковый подход (Ведет к нарушению конфиденциальности и целостности) |
|---|---|
| Ролевая модель доступа (RBAC). Создание типовых ролей («Кассир», «Аналитик 1С») с фиксированным минимальным набором прав. | Индивидуальное назначение прав каждому сотруднику вручную, без шаблонов. |
| Запрос-санкционирование. Любое предоставление права инициируется запросом и утверждается ответственным лицом. | Устные распоряжения или запросы в личных сообщениях без документального оформления. |
| Автоматизированный de-provisioning. Отзыв прав при смене роли или увольнении — обязательный автоматический этап. | «Забывание» отозвать доступы. Уволенный сотрудник остается в списках групп доступа к почтовым рассылкам или файловым хранилищам. |
| Ежегодный или ежеквартальный аудит. Руководители подразделений подтверждают актуальность прав своих подчиненных. | Отсутствие периодического контроля. Права назначаются один раз и никогда не пересматриваются. |
Итоги: базовые принципы безопасного управления доступом
Эффективный provisioning строится на нескольких незыблемых принципах, которые должны быть закреплены в локальных нормативных актах организации (например, в Регламенте управления доступом):
- Принцип минимальных привилегий (Least Privilege). Сотрудник получает ровно тот доступ, который необходим для выполнения текущих задач, и не более.
- Разделение обязанностей (SoD). Критичные операции (например, санкционирование платежа и его проведение) должны быть разделены между разными ролями.
- Своевременность. Права предоставляются к моменту начала работы и отзываются немедленно при изменении статуса.
- Полная аудируемость. Каждое действие — создание, изменение, блокировка учетной записи — должно фиксироваться в защищенном журнале с указанием инициатора, исполнителя и основания.
- Соответствие регуляторным требованиям. Процедуры должны обеспечивать выполнение требований 152-ФЗ (защита ПДн) и приказов ФСТЭК (например, требование о периодической аттестации пользователей).
Игнорирование этих принципов не просто создает операционные риски. Оно формирует системные уязвимости, которые могут быть использованы как для утечки информации, так и для мошеннических действий внутри компании. Управление доступом — это не техническая, а в первую очередь управленческая задача.