Управление идентичностью в организации складывается из трёх механизмов, и каждый закрывает свою часть. Единый вход централизует аутентификацию: сотрудник заходит через корпоративного провайдера, и отзыв доступа там отзывает его везде. Автоматическая подготовка учётных записей заводит, обновляет и отключает пользователей по данным кадровой системы, снимая с администратора ручную сверку списков. Ограничение по идентификаторам команд через управление устройствами не даёт работать с личных учётных записей на корпоративной технике.
Смысл третьего механизма понимают не сразу, а он важен. Без него сотрудник может использовать инструмент под личной учётной записью на рабочем ноутбуке, и тогда к нему не применяются ни командные политики, ни настройки приватности, ни ограничения моделей, ни списки разрешённых внешних серверов. Формально всё настроено, фактически часть работы идёт мимо всей вашей конфигурации, и в отчётах её не видно - потому что происходит она в чужом арендаторе.
Отсюда следующий шаг: организационные группы связывают группы провайдера идентичности с доступом к каталогам и средствами управления. Это меняет роль идентичности - она перестаёт быть только пропуском и становится носителем политики. Перевод человека между отделами в кадровой системе меняет не только его рассылки, но и лимиты расхода, набор доступных моделей, управление автозапуском, доступ к каталогу и состав команд вместе с ролями. Выгода очевидна: политика перестаёт зависеть от того, вспомнил ли администратор про конкретного сотрудника. Цена тоже понятна: ошибка в членстве групп стоит дороже, потому что распространяется на инструмент автоматически.
Полезно один раз пройти базовый чек-лист идентичности. Ниже он и приведён: домен единого входа и аварийные административные учётные записи задокументированы; создание, обновление и отключение пользователя проверены на тестовом человеке; ограничение по командам действует на управляемых устройствах; уходящий сотрудник теряет доступ и к инструменту, и к подключённым системам; служебные учётные записи имеют владельца, назначение, минимальные права и ротацию; человеческие и машинные учётные данные не взаимозаменяемы.
Последний пункт нарушается чаще всего, причём из лучших побуждений. Автоматизацию быстрее поднять под своей учётной записью: она уже есть, уже настроена, права выданы. Но тогда действия робота неотличимы от ваших в журналах, разбор инцидента упирается в вопрос, вы это были или процесс, ваш отпуск влияет на конвейер ровно до первой смены пароля, а ваш уход из компании ломает процессы, о которых вы уже не помните. Машинная учётная запись стоит десяти минут заведения и снимает все четыре проблемы сразу.
Отдельно стоит понимать границу автоматического отключения. Оно надёжно закрывает то, чем владеет провайдер идентичности: вход, сессию, членство в командах. Но ключи программного интерфейса, интеграции с системами хранения кода и подключения к внешним серверам живут своей жизнью - они выданы внутри инструмента или во внешней системе и не обязаны исчезнуть от того, что пользователь деактивирован. Именно поэтому в чек-листе стоит отдельный пункт про подключённые системы: без него отключение выглядит выполненным, а канал доступа остаётся открытым.
Проверять всё это лучше не документом, а упражнением. Раз в квартал возьмите тестовую личность и отключите её, как если бы человек уволился. Затем докажите, что исчезли сессия в инструменте, возможность продолжить его облачные задачи, ключ программного интерфейса, доступ через интеграцию с репозиториями и доступ к внешним серверам. Занимает это около часа и обычно находит один-два незакрытых канала, как правило именно среди тех, что выданы в обход провайдера идентичности.
Именно такие упражнения превращают настройку в гарантию. Пока отключение не проверено на практике, вы знаете, что настроили, но не знаете, что получилось. В вопросах доступа разница между настроил и проверил обнаруживается в самый неудобный момент: когда бывший сотрудник ещё может запустить агента с правами, которых у него уже не должно быть, и когда объяснять это приходится не коллегам, а аудитору.
Инженерный вывод простой: идентичность - это не список настроек, а проверяемое свойство системы. Централизованный вход, автоматическая подготовка, ограничение устройств, групповая политика и дисциплина служебных учётных записей дают это свойство только вместе; ни один из механизмов не работает в одиночку, а результат доказывается регулярным упражнением по отключению.
Типичные провалы предсказуемы. Настроить единый вход, но не закрыть личные учётные записи на рабочих устройствах. Использовать личный ключ в командной автоматизации. Считать, что деактивация пользователя сама убирает ключи и внешние подключения. Не проверять отключение на практике. И оставить служебные учётные записи без владельца и ротации.
Базовый уровень идентичности
[ ] домен единого входа и аварийные административные учётные записи задокументированы
[ ] создание, обновление и отключение пользователя проверены на тестовом человеке
[ ] ограничение по идентификаторам команд действует на управляемых устройствах
[ ] уходящий теряет доступ и к инструменту, и к подключённым системам
[ ] у служебных учётных записей есть владелец, назначение, минимальные права и ротация
[ ] человеческие и машинные учётные данные не взаимозаменяемы