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