Театр на 400 строк: почему квартальный пересмотр прав доступа не работает
В последний вторник квартала в календаре тимлида разработки всплывает настойчивое напоминание службы безопасности: Срочно завершить квартальный пересмотр прав доступа.
К задаче прикреплен свежий экспорт из корпоративной системы идентификации: электронная таблица на 412 строк с именами сотрудников, ролями в AWS IAM, группами в GitHub и флагами доступа к базам данных. До важного релиза спринта остается три часа, два ключевых инженера на больничном, а в рабочем чате висят неотвеченные баг-репорты.
Тимлид открывает файл, бросает взгляд на первую строку, яростно крутит колесо мыши до строки 412 и нажимает заветную зеленую кнопку: Утвердить все.
Специалист по комплаенсу получает подписанный лог с электронной меткой времени. Спустя месяц аудитор ISO 27001, проверяя выполнение меры контроля 5.18 (Права доступа), с чистой совестью ставит высший балл. Аудитор видит утвержденный регламент, строгий квартальный график и официальную подпись руководителя.
А на строке 287 тихо числился фронтендер-фрилансер, чей трехмесячный контракт завершился еще в марте. Этот подрядчик до сих пор имеет прямой доступ к продакшен-базе данных.
Добро пожаловать в театр безопасности.
Охранник клуба под проливным дождем
Регулярный пересмотр прав доступа задумывался ради здравой цели: со временем сотрудники накапливают права, которые им больше не нужны для работы. Инженер переходит из отдела инфраструктуры в продуктовую команду, сохраняя root-доступ к серверам баз данных. Внешний дизайнер сдает макеты, но годами остается в закрытых репозиториях. В безопасности это явление называют накоплением привилегий (privilege creep).
Стандарт ISO 27001 пытается решить эту проблему, обязывая живых руководителей регулярно проверять списки пользователей.
На практике это напоминает вышибалу на входе в ночной клуб, который стоит под ледяным ливнем с длинным списком из четырехсот гостей. Очередь растянулась на два квартала, люди замерзли, а администратор кричит из двери быстрее впускать толпу, чтобы наполнить зал.
Охранник скользит взглядом по первым двум именам, смотрит на часы, переворачивает планшет и отстегивает бархатный канат, пропуская всю толпу внутрь без единой проверки документов.
Разница лишь в том, что в клубе охранник хотя бы визуально заметит человека с монтировкой в руках. В таблице Excel неактивный аккаунт маркетолога-подрядчика с доступом к платежным данным клиентов выглядит в точности так же, как строчка ведущего штатного архитектора. В таблице нет контекста, нет истории активности и нет понимания реальных рисков.
Почему ручные таблицы обречены на слепое одобрение
Когда компанию заставляют проверять доступы вручную через бесконечные реестры, когнитивные ограничения человека гарантируют формализм:
- Потеря контекста: Таблица показывает технические идентификаторы ролей вроде
arn:aws:iam::123456789:role/data-sync-worker-v2. Руководитель не помнит наизусть, какие именно ресурсы разрешает эта роль, если не потратит полчаса на изучение политик в консоли AWS. - Усталость от проверок: Исследования показывают, что концентрация человека резко падает уже после двадцати однотипных решений. Требование проверить четыреста строк гарантирует, что 95% решений принимаются машинально.
- Цена ошибки «Отозвать»: Если менеджер по ошибке отзовет нужный доступ, у разработчика упадет сборка, работа встанет, а в личку посыплются жалобы. Если же менеджер подтвердит лишний доступ, сегодня ничего не сломается. Система мотивации толкает на слепое одобрение.
Переход от ручных таблиц к автоматической гигиене
Избавление от показухи не требует найма новых консультантов по стандартам. Безопасность достигается переходом от статичных таблиц к автоматизированному управлению учетными записями:
- Автоматический депровижининг через SCIM: Исключите ручное удаление учетных записей. Свяжите кадровую систему компании напрямую с провайдером идентификации по протоколу SCIM. Как только отдел кадров ставит отметку об увольнении или завершении контракта, все привязанные учетные записи в AWS, GitHub и корпоративных SaaS-сервисах отзываются автоматически за секунды.
- Временный доступ по запросу (Just-In-Time Access): Ни одному инженеру не нужны постоянные круглосуточные права администратора к боевым базам. Внедряйте механизмы временного повышения привилегий, когда доступ выдается под конкретную задачу на несколько часов и автоматически сгорает.
- Проверка только аномалий (Diff-based Reviews): Никогда не выгружайте руководителю сырую простыню из 400 строк. Оставляйте для проверки только подозрительные отклонения: сотрудников, сменивших должность; учетные записи, не проявлявшие активности более 60 дней; и аккаунты с внешними почтовыми доменами. Проверить двенадцать рискованных записей можно внимательно, а четыреста — только вслепую.
Подписанная раз в квартал таблица доказывает наличие бумажек для аудита, а не безопасность компании. Когда ваша команда в прошлый раз согласовывала доступы, кто-нибудь действительно прочитал строку 287?