Эскалация привилегий: почему управление доступом - это операционная задача
Почему большинство серьёзных инцидентов начинается изнутри периметра, и как думать об управлении привилегиями как о непрерывном процессе.
Большинство компаний тратят значительные ресурсы на защиту периметра: межсетевые экраны, системы обнаружения вторжений, антивирусы. Это разумно. Но статистика инцидентов говорит о другом: значительная часть серьёзных нарушений происходит не снаружи, а изнутри - через аккаунты с избыточными правами, которые уже находятся внутри.
Это не обязательно злонамеренные действия. Чаще это скомпрометированный аккаунт, ошибка конфигурации, или бывший сотрудник, чьи права не были отозваны вовремя.
Что такое эскалация привилегий
Эскалация привилегий - это ситуация, когда субъект (пользователь, процесс, программа) получает доступ к ресурсам или действиям, которые выходят за пределы его легитимных полномочий.
Это происходит двумя путями. Вертикальная эскалация: обычный пользователь получает права администратора. Горизонтальная: пользователь получает доступ к данным другого пользователя на том же уровне.
В корпоративной среде обе формы встречаются регулярно - и чаще всего не как атака, а как следствие неаккуратного управления правами.
Как накапливается избыток прав
Права имеют свойство только расти. Сотруднику нужен временный доступ к системе для проекта - его открывают и не закрывают. Разработчику нужны права администратора в продакшн-базе для отладки - и они остаются навсегда. Уволившийся сотрудник был в нескольких группах доступа - деактивация аккаунта прошла, но сервисные токены и API-ключи остались.
Со временем картина становится непрозрачной. Никто точно не знает, у кого какие права. Никто не помнит, зачем конкретному аккаунту нужен конкретный доступ.
Это не признак плохой команды. Это признак отсутствия процесса.
Почему это операционная задача, а не проектная
Управление доступом нельзя "сделать один раз". Права нужно пересматривать регулярно, потому что ситуация постоянно меняется: люди приходят и уходят, роли меняются, проекты завершаются, системы появляются и выводятся.
Проектный подход выглядит так: навести порядок, отчитаться, забыть. Через полгода всё возвращается на круги своя.
Операционный подход выглядит иначе: есть процесс онбординга, который выдаёт минимально необходимые права; есть процесс оффбординга, который гарантированно закрывает все точки доступа; есть регулярный аудит - раз в квартал или раз в полгода - который проверяет соответствие прав текущим ролям.
Практический минимум
Не каждая компания может позволить себе полноценную IAM-систему прямо сейчас. Но есть минимум, который реалистичен для большинства:
- Ведётся актуальный список: кто, к чему, на каком основании имеет доступ.
- Оффбординг включает явный чеклист по доступам - не только деактивация AD-аккаунта.
- Привилегированный доступ (администраторские права, доступ к продакшн-данным) выдаётся явно и с ограниченным сроком, а не по умолчанию.
- Раз в квартал кто-то смотрит на список привилегированных аккаунтов и задаёт вопрос: этот доступ ещё нужен?
Этого недостаточно для зрелой безопасности. Но это принципиально лучше, чем не делать ничего.
Вопрос для руководителя
Один вопрос, который стоит задать своей команде: если сотрудник уволился вчера - через сколько часов он гарантированно теряет весь доступ ко всем системам? Если ответ "не знаем" или "зависит от системы" - это отправная точка для разговора.