«Управление учётными записями, это не технический процесс, а бизнес-логика, зашитая в права доступа. Частая ошибка — воспринимать его как набор рутинных действий, тогда как на самом деле каждый этап жизненного цикла сотрудника формирует ландшафт рисков компании. Без чёткого и централизованного Provisioning организация рискует не столько потерять данные, сколько утратить понимание, кому и почему доступны её критичные системы».
Как создаются учётные записи пользователей
Provisioning, или управление жизненным циклом учётных записей,, это основа контролируемого доступа в любой инфраструктуре. В условиях российского регулирования (152-ФЗ, ФСТЭК) ошибки в этом процессе ведут не только к инцидентам безопасности, но и к нарушениям, чреватым серьёзными санкциями. Речь идёт о системном подходе к созданию, модификации и блокировке учётных записей на всех уровнях: от Active Directory и доменных служб до корпоративных приложений и баз данных.
Основные сценарии, требующие Provisioning
1. Приём нового сотрудникаНачало работы нового сотрудника запускает цепочку процессов. Менеджер по персоналу или руководитель направляет в службу информационной безопасности или IT-администраторам оформленный запрос. В качественных системах это происходит не через почту, а через тикет в ITSM или специализированной системе управления идентификацией (IAM).
Ключевые данные в запросе:
- Авторизация и основание — приказ о приёме на работу.
- Должность и подразделение — определяют стартовый набор ролей (role-based access control, RBAC).
- Список необходимых систем — CRM, ERP, корпоративная почта, файловые хранилища, специализированный софт.
На этом этапе критичен принцип минимальных привилегий (Principle of Least Privilege). Предоставление прав «с запасом» или по аналогии с коллегой создаёт избыточный доступ. Для административных учётных записей часто требуется дополнительное согласование с CISO или руководством.
2. Изменение должности или переводПеревод сотрудника — один из самых уязвимых процессов с точки зрения накопления избыточных прав (privilege creep). Старые доступы должны быть отозваны, а новые — предоставлены согласно новой роли.
- JIT (Just-in-Time) доступ — для временных задач. Права автоматически отзываются после дедлайна.
- Ресертификация (Re-certification) — регулярный аудит, когда руководитель подтверждает актуальность прав своих подчинённых. Часто это требование стандартов ФСТЭК.
Отсутствие автоматизированного процесса ведёт к ситуации, когда бывший финансовый аналитик, переведённый в маркетинг, сохраняет доступ к платёжным ведомостям.
3. Увольнение сотрудникаУвольнение требует немедленных и чётких действий. Стандартная ошибка — полное и моментальное удаление учётки. Это нарушает аудиторский след и может заблокировать доступ к важным бизнес-документам.
Правильная последовательность:
- Мгновенная блокировка в день увольнения. Аккаунт деактивируется во всех системах одновременно (через интеграцию IAM).
- Вывод из всех групп и ролей.
- Отзыв сессий, токенов, сертификатов.
- Сохранение аккаунта в заблокированном состоянии 30-90 дней для нужд аудита и передачи данных.
- Окончательное удаление или архивация.
В зрелых системах этот процесс автоматически запускается сигналом из кадровой системы.
Критичные рекомендации и типовые ошибки
Ключевое правилоНикогда не копируйте профиль существующего пользователя для создания нового. Это прямой путь к наследованию исторических ошибок и избыточных прав.
Вместо копирования необходимо использовать библиотеку стандартных ролей. Например, роль «Менеджер по продажам в регионе X» включает доступ к CRM, почте, календарю и региональному каталогу в файловом хранилище. Все новые сотрудники этой категории получают идентичный, проверенный набор прав.
Другая скрытая проблема — orphaned accounts (осиротевшие учётные записи). Они остаются в системе после увольнения пользователей, но не блокируются, часто с привилегированным доступом. Регулярный сквозной аудит учётных записей против актуального штатного расписания — обязательная практика.
Сравнение подходов к управлению учётными записями
| Риск-ориентированный подход (рекомендуется) | Реактивный подход (ведёт к нарушениям) |
|---|---|
| Использование стандартных ролей (RBAC) на основе должностных инструкций. | Копирование прав «как у Иванова» или ручное назначение по запросу. |
| Интеграция IAM-системы с кадровыми системами для автоматизации процессов онбординга, перевода и увольнения. | Ручное создание и удаление учёток администраторами по письмам. |
| Обязательная периодическая ресертификация прав (например, раз в квартал). | Отсутствие регулярного пересмотра предоставленного доступа. |
| Правило «отключить, затем удалить» при увольнении с периодом ожидания. | Немедленное удаление учётной записи, разрушающее логи аудита. |
Итог: от рутины к стратегии
Provisioning, это не техническая рутина, а бизнес-процесс, формализующий политику безопасности. Его автоматизация через IAM-решения не просто экономит время администраторов, но и создаёт доказуемую базу для аудиторов ФСТЭК. Ключевые элементы успеха: отказ от ручных методов в пользу ролевых моделей, жёсткая интеграция с HR и регулярный пересмотр предоставленных прав. Внедрение такого подхода резко снижает поверхность атаки и закрывает один из самых распространённых векторов утечек — через легитимные, но некорректно управляемые учётные записи.