Principle of Least Privilege, Explained

Принцип наименьших привилегий звучит очевидно, когда его озвучиваешь: дай учетной записи, процессу или пользователю только тот доступ, который ему нужен для работы, ничего больше. Зазор между этим высказыванием и фактическим управлением системами так обычно организуется — вот где большинство взломов превращаются из незначительного инцидента в полный компрометирование домена.

Что это на самом деле означает

Принцип наименьших привилегий (PoLP) говорит, что каждый субъект в системе — пользователь, служебная учетная запись, приложение, контейнер — должен работать с минимальным набором разрешений, необходимых для выполнения своей функции. Не разрешений, которые удобны. Не разрешений, которые кто-то выдал три года назад и забыл отозвать. Минимальный набор.

Это применяется на каждом уровне: права доступа к файловой системе, роли базы данных, области API, политики cloud IAM, правила брандмауэра, доступ через sudo. Процесс веб-сервера, читающий статические файлы, не должен иметь право на запись в /etc. Скрипт отчетности, который только выполняет запросы SELECT, не должен иметь роль базы данных с правами DROP TABLE. Стажер отдела маркетинга не должен быть администратором домена только потому, что это было проще, чем разобраться с нужной группой.

Почему это важнее, чем кажется

Когда злоумышленник компрометирует учетную запись или процесс, он наследует все, что может сделать эта учетная запись. Если ноутбук фишингового сотрудника имеет доступ только к файловым ресурсам, релевантным для его команды, радиус поражения от этого фишинга ограничен. Если та же учетная запись имеет права администратора домена только потому, что IT выставил это для устранения неполадок и никогда не откатил, то злоумышленник теперь владеет сетью.

Это логика, стоящая за большинством форензических отчетов после взлома: начальный доступ был низкой ценности, но боковое движение через чрезмерно привилегированные учетные записи превратило это в программу-вымогатель по всему окружению. Избыточные привилегии не вызывают начальный компрометирование, но почти всегда это то, что делает компрометирование дорогостоящим.

Где это проявляется на практике

Cloud IAM. AWS, Azure и GCP по умолчанию ведут себя разрешительно, если ты не осторожен — политика IAM с "Action": "*" и "Resource": "*" пройдет валидацию и работает нормально, пока утекший ключ доступа не даст злоумышленнику полный контроль над учетной записью. Ограничивай политики конкретными действиями и ARN ресурсов вместо использования подстановочных знаков.

Служебные учетные записи. Это часто самые худшие нарушители, потому что никто их не проверяет так же, как человеческие учетные записи. Pipeline CI/CD, развертывающий код в один bucket S3, не должен держать учетные данные, которые могут читать каждый bucket в учетной записи.

Роли базы данных. Отделяй роли только для чтения для отчетности от ролей приложений, которым нужны INSERT/UPDATE, и отделяй их от роли DBA, которая может изменять схему. PostgreSQL и MySQL оба поддерживают детальные операторы GRANT — используй их вместо того, чтобы давать каждому подключению приложения эквивалент root.

Sudo и локальный администратор. Just-in-time возвышение (запроси доступ, получи его на ограниченный период, потеря его автоматически) всегда лучше, чем постоянные права администратора. Инструменты типа sudo с ограниченными по времени правилами или решения PAM в корпоративных окружениях существуют специально для этого.

Напряженность с