Содержание статьи
Управление ИТ-доступом должно отвечать на три вопроса: кто получил право, зачем оно нужно и когда его отзовут. Практичная система связывает учетную запись с ролью сотрудника, владельцем ресурса и кадровым событием. Базовые права выдаются автоматически, дополнительные проходят согласование, привилегии ограничиваются, а увольнение запускает проверяемое отключение во всех связанных системах.
Главный принцип — минимально необходимые права. Он не означает, что каждому вручную выдают один флажок. Компания проектирует удобные роли для типовых задач, а затем контролирует исключения и регулярно пересматривает доступ.
Составьте инвентарь систем и владельцев
Начните с критичных ресурсов: почта, каталог пользователей, VPN, CRM, ERP, банк-клиент, облака, репозитории, аналитика, сервисные учетные записи и физические серверы. Для каждого укажите бизнес-владельца, технического администратора, способ входа, источник учетных записей и журнал действий.
Без бизнес-владельца ИТ вынуждено самостоятельно решать, кому нужны финансовые данные или экспорт клиентов. Владелец определяет допустимые роли и согласует исключения, ИТ реализует решение, ИБ проверяет риск.
Найдите локальные учетные записи, которые не связаны с общим каталогом. Они часто остаются после увольнения, потому что кадровое событие до них не доходит.
Постройте ролевую модель
Роль объединяет набор прав для устойчивой рабочей функции: менеджер продаж, бухгалтер по расчетам, руководитель филиала. Она должна быть достаточно широкой для работы и достаточно узкой, чтобы не давать лишний доступ.
Не копируйте должностное расписание буквально. Два сотрудника с одинаковой должностью могут работать в разных организациях или регионах. Практичная роль складывается из базовой функции, области данных и уровня полномочий.
Избегайте сотен уникальных ролей на одного человека. Если исключение повторяется, возможно, нужна новая типовая комбинация. Если право встречается один раз, оставьте его как отдельное согласованное назначение со сроком.
Сделайте матрицу прав рабочим инструментом
Матрица связывает роли и ресурсы. В строках удобно держать системы или объекты, в столбцах — роли, а в ячейках — уровень доступа: просмотр, изменение, утверждение, экспорт, администрирование.
Для каждого права добавьте владельца, основание, срок пересмотра и несовместимые полномочия. Например, создание поставщика и подтверждение платежа не должны бесконтрольно находиться у одного человека.
Матрица не обязана быть огромной таблицей. Начните с десяти критичных систем и пяти массовых ролей. Важно, чтобы изменения проходили через управляемый процесс и отражались в фактических настройках.
Автоматизируйте joiner-mover-leaver
Жизненный цикл начинается до первого рабочего дня. HR-система или подтвержденная заявка создает событие о выходе сотрудника, роли и подразделении. Базовый доступ должен быть готов к началу работы, а не выдаваться хаотично в течение недели.
Перевод — самый недооцененный этап. Новые права добавляются, старые остаются. Процесс mover должен сначала рассчитать целевую роль, показать разницу и отозвать больше не нужные назначения после согласованного перехода.
Увольнение запускает offboarding: блокировку входа, отзыв сессий и токенов, закрытие VPN, передачу рабочих данных, изменение владельцев объектов, отзыв привилегий и проверку локальных систем. Время зависит от риска и сценария ухода, но подтверждение выполнения должно быть единым.
Разделите постоянные и временные права
Проектный доступ, замещение, диагностика и работа подрядчика не должны становиться бессрочными. У каждого временного назначения есть дата окончания, владелец и автоматический отзыв или повторное согласование.
Для аварийного доступа используйте отдельный сценарий с усиленным журналом и уведомлением. Общая учетная запись «admin» мешает понять, кто действовал, и усложняет отзыв.
Привилегированные права выдавайте на время задачи, где это технически возможно. Администратор не обязан постоянно читать бизнес-данные только потому, что поддерживает систему.
Введите регулярную сертификацию доступа
Даже хороший автоматический процесс не ловит все изменения. Раз в согласованный период владелец ресурса получает понятный список: пользователь, роль, конкретный доступ, последнее использование и основание.
Не отправляйте тысячу строк с кнопкой «подтвердить все». Группируйте по риску и показывайте изменения, неиспользуемые права, внешних пользователей и привилегии. Решение владельца должно сохраняться в журнале.
Если доступ не использовался долго, это сигнал для проверки, но не автоматическое доказательство ненужности. Некоторые аварийные роли используются редко, зато требуют строгого контроля.
Настройте проверки несовместимости
Разделение обязанностей снижает риск ошибки и злоупотребления. Определите критичные пары: создание и оплата, изменение реквизитов и подтверждение, разработка и выпуск в production, администрирование и независимый аудит.
Если бизнесу нужно исключение, оформите компенсирующий контроль: дополнительное подтверждение, лимит, журнал и срок. Система должна показывать конфликт до выдачи права, а не через год на аудите.
Управляйте сервисными учетными записями
Интеграции и роботы часто работают под учетными записями, про которые вспоминают только при сбое. Для каждой нужны владелец, назначение, минимальные права, способ хранения секрета, ротация и зависимые процессы.
Не привязывайте критичную интеграцию к личной учетной записи сотрудника. Его увольнение либо остановит обмен, либо заставит оставить доступ активным.
Секреты храните в специализированном защищенном хранилище, а не в таблице или коде. Изменение ключа должно быть отработано без простоя.
Измеряйте качество управления
Полезные метрики: время выдачи базового доступа, доля назначений через роли, число бессрочных исключений, время отключения после кадрового события, доля систем в едином процессе, просроченные сертификации и неиспользуемые привилегии.
Количество заявок само по себе ничего не говорит. Если их стало меньше благодаря ролям, это хорошо; если сотрудники обходят процесс и делятся учетными записями — опасно.
Проверяйте путь выборочно. Возьмите уволенного сотрудника, перевод и подрядчика и проследите все назначения до фактических настроек систем.
Как запустить проект без большой IAM-платформы
Сначала договоритесь о данных и ответственности. Выберите кадровый источник, десять критичных систем и пять массовых ролей. Создайте единый реестр назначений и процедуру подтверждения, даже если часть операций пока выполняется вручную.
Настройте ежедневный список кадровых событий и контроль исполнения. Увольнение с высоким риском обрабатывается сразу, стандартный перевод — по согласованному окну. Владелец системы подтверждает фактическое изменение, а координатор видит незакрытые действия.
После нескольких циклов станет понятно, какие интеграции дают наибольший эффект. Автоматизируйте сначала единый вход и системы с большим количеством пользователей. Платформа IAM ускоряет зрелый процесс, но не создаст владельцев и ролевую модель вместо компании.
FAQ
RBAC подходит любой компании?
Ролевой подход удобен как основа, но сложные условия могут требовать дополнительных атрибутов: организации, проекта, региона, времени или типа данных.
Кто согласует доступ?
Бизнес-владелец ресурса подтверждает необходимость, руководитель — рабочую задачу, ИБ — риск по установленным правилам. Не каждое стандартное право требует ручной цепочки.
Что отключать при увольнении первым?
Единый вход, активные сессии, удаленный доступ и привилегии. Полный порядок определяют риск и архитектура, а затем проверяют по чек-листу.
Нужно ли хранить историю прав?
Да. История назначений, согласований, изменений и отзывов нужна для расследований, аудита и подтверждения процесса.
Практический вывод
Надежное управление доступом строится вокруг роли, владельца и события отзыва. Начните с критичных систем, спроектируйте пять типовых ролей, автоматизируйте выход, перевод и увольнение и ограничьте временные привилегии. Затем сравнивайте матрицу не с заявками, а с фактическими настройками.
Полезно коллегам?
