IAM: пользователи, роли и политики

Как AWS решает, кому и что разрешено: разбираем IAM по косточкам.

IAM (Identity and Access Management) — сервис управления доступом: кто (пользователь, роль) и что (действие над ресурсом) может делать в вашем аккаунте.

Четыре кита IAM

В IAM всего несколько ключевых сущностей, и, поняв их, вы поймёте всю систему доступов AWS.

Пользователи (Users)

Постоянная личность для человека или приложения: имя, пароль, опционально access keys. Под пользователем входят в консоль или обращаются к API.

Группы (Groups)

Набор пользователей с одинаковыми правами. Удобно: дали права группе «Разработчики» — они появились у всех её участников.

Роли (Roles)

Временная личность без постоянного пароля. Роль «примеряют» на время: её берут сервисы (например, EC2, чтобы читать S3) или пользователи для разовой задачи. Это безопаснее ключей, потому что доступ временный.

Политики (Policies)

JSON-документ, описывающий разрешения: какие действия над какими ресурсами разрешены или запрещены. Политику прикрепляют к пользователю, группе или роли.

Как выглядит политика

Политика — это JSON. Вот пример, разрешающий только чтение объектов из одного бакета S3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

Здесь Effect — разрешить или запретить, Action — какие операции, Resource — над чем (в формате ARN — уникального идентификатора ресурса AWS).

Как работает под капотом

Каждый запрос к AWS проходит проверку IAM. Система собирает все политики, применимые к запрашивающему (его собственные, групповые, политику роли), и оценивает их. Правило простое: по умолчанию запрещено всё; явный Allow открывает доступ; но любой явный Deny перевешивает любой Allow. То есть запрет всегда сильнее разрешения. Поэтому даже широкая права администратора можно «вырезать» точечным Deny на опасное действие.

Частые ошибки

Раздавать AdministratorAccess всем. Нарушается принцип наименьших привилегий: давайте ровно столько прав, сколько нужно для задачи.
Хранить access keys в коде. Ключ в Git утекает мгновенно; для сервисов используйте роли, а не ключи.
Путать роли и пользователей. Для приложения на EC2 нужна роль (временные права), а не вшитый пользователь с ключом.

Итог

IAM управляет тем, кто и что может делать в аккаунте.
Пользователи и группы — постоянные личности, роли — временные (для сервисов и разовых задач).
Политики — это JSON с Effect/Action/Resource; явный Deny всегда перевешивает Allow.
Соблюдайте принцип наименьших привилегий и не храните ключи в коде.