Least-privilege policies

Как на самом деле выглядит узкая политика

Least privilege — это одно правило: у субъекта должны быть ровно те права, что нужны для его работы, ровно столько времени, сколько нужно, — и ни одним правом больше. Сложность не в принципе, а в том, что удобная и правильная политики выглядят почти одинаково, и удобная отгружается быстрее.

IAM-политика отвечает на два вопроса для каждого запроса: какие действия (s3:GetObject, dynamodb:Query) и на каких ресурсах (конкретный ARN бакета, конкретная таблица). Узкая политика называет оба. Сервис, читающий один объект конфигурации, должен держать вот это:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::acme-config/service-x/*"
}

Одно действие, один префикс ресурса. Если этот ключ утечёт, атакующий получит доступ на чтение к одной папке в одном бакете — сдержанный, скучный инцидент. Радиус поражения — это политика, и ты намеренно написал политику маленькой.

Рефлекс, который надо выработать: начни с deny, добавь единственное действие, которое можешь назвать, ограничь его единственным ARN, который можешь назвать, и остановись. Каждый раз, тянясь к *, ты говоришь «я не знаю, какие действия или ресурсы здесь нужны», — а атакующий, укравший учётку, отлично знает, что делать с этой неопределённостью.

Чем кусаются подстановочные знаки

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

Action: "s3:*" расширяет, что может субъект. Сервису нужен был GetObject; подстановочный знак заодно вручил ему PutObject, DeleteObject, PutBucketPolicy, PutBucketAcl. Теперь учётка для чтения может перезаписать данные, удалить их или сделать приватный бакет публичным. Resource: "*" расширяет, где это применяется — с одного бакета на каждый бакет, включая ещё не существующие. Два знака компонуются: s3:* на * — это полный контроль над всем твоим объектным хранилищем из учётки, выданной ради чтения файла конфигурации.

Есть и более тихая цена: подстановочные знаки делают аудит невозможным. Когда политика говорит s3:GetObject на именованном ARN, рецензент может прочитать её и точно знать, что роль умеет. Когда она говорит s3:* на *, единственный честный ответ на «что эта роль может?» — «всё со всем», и радиус поражения такого размера никто не способен осмыслить. Узкие политики самодокументируемы; подстановочные знаки стирают документацию.

Permission boundaries: ограждение, нужное least privilege на масштабе

Написать одну узкую политику легко. Удержать узкими все политики, по сотням ролей и десяткам инженеров, у каждого из которых есть право создавать роли, — вот настоящая проблема. Её решают permission boundaries.

Permission boundary — это политика, прикреплённая к субъекту, задающая максимум прав, которые он когда-либо может иметь, — потолок, а не выдача. Эффективные права субъекта — это пересечение его identity-политик и его boundary: право разрешено, только если обе его разрешают. Так что даже если разработчик (или атакующий, скомпрометировавший роль разработчика) прикрепит AdministratorAccess к новой роли, boundary обрежет это обратно до того, что boundary разрешает.

Канонический сценарий — делегированное создание ролей. Ты позволяешь разработчикам создавать роли для собственных сервисов — это хорошо для скорости, — но требуешь, чтобы каждая создаваемая ими роль несла контролируемый тобой boundary. Теперь разработчик может выдать своему сервису s3:GetObject на свой бакет, но не может создать роль с iam:* или доступом к продакшен-базе, потому что boundary это запрещает, а пересечение побеждает. Boundary превращает «доверяй каждому инженеру написать идеальную политику» в «доверяй одной boundary-политике и дай инженерам быстро двигаться внутри неё».

Boundary не заменяет узкие политики — это страховочный рубеж. Identity-политика — место, где ты выражаешь намерение (эта роль читает конфиг); boundary — место, где ты выражаешь предел (ни одна роль в этом аккаунте не должна трогать IAM или продакшен-данные). Нужны оба: узкие политики, чтобы типовой случай был корректен, и boundary, чтобы единственная небрежная политика не стала компрометацией аккаунта.

Как рецензировать политику по-сеньорски

Когда политика приходит к тебе на ревью, ты сканируешь три вещи по порядку. Первое — подстановочные знаки: любой Action: "*", "s3:*" или Resource: "*" — это вопрос, не обязательно баг, но он должен быть обоснован, и «так было проще» не обоснование. Второе — опасные глаголы: iam:*, iam:PutRolePolicy, iam:PassRole, sts:AssumeRole на широком ресурсе, *:Delete* — всё, что может менять чужие права или уничтожать данные. Третье — охват ресурсов: называет ли каждый statement конкретные ARN, которых касается, или оставляет Resource: "*", потому что никто их не перечислил?

Сеньорский ход — снижать права со временем, а не только пропускать новые. Облачные провайдеры отдают данные access-analyzer / last-accessed: какие действия роль реально использовала за последние 90 дней. Роль с s3:*, которая вызывала только GetObject и ListBucket, сама сообщает свою настоящую политику — сгенерируй узкую из наблюдаемого использования и замени подстановочный знак. Least privilege — не разовая выдача, которую ты получаешь правильной при создании; это храповик, который ты подтягиваешь по мере того, как узнаёшь, что роль на самом деле делает.