AWS IAM простыми словами: пользователи, группы, роли и политики

Что делает IAM

IAM (Identity and Access Management) — сервис AWS, который для каждого запроса отвечает на один вопрос: может ли эта учётная запись выполнить это действие над этим ресурсом? Это касается людей в консоли, скриптов через CLI и приложений, которые обращаются к API AWS.

Ответ по умолчанию — нет. Ничего не разрешено, пока политика явно это не разрешит.

Четыре строительных блока

Привязывайте политики к группам и ролям, а не к отдельным пользователям. Тогда новый сотрудник просто добавляется в группу, а уходящий — удаляется из неё.

Как читать JSON-политику

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

Читайте её как предложение:

• Effect — Allow (разрешить) или Deny (запретить).
• Action — какие операции API, в формате сервис:Операция. Маска s3:* разрешает все операции S3, а это редко то, что нужно.
• Resource — над какими объектами, по ARN. Здесь — любой файл в бакете my-app-uploads, и больше ничего.
• Condition (необязательно) — дополнительные условия, например определённый IP или вход с MFA.

Version — это версия языка политик, а не дата, которую нужно менять.

Логика проверки коротко: явный Deny всегда побеждает, затем явный Allow разрешает запрос, а всё неупомянутое запрещено.

Уберите root-аккаунт подальше

Root — это email, на который создан аккаунт. Он может всё, включая закрытие аккаунта и изменение биллинга, и его права нельзя ограничить политиками IAM.

Что сделать сразу после создания аккаунта:

1. Включить MFA для root (аппаратный ключ или приложение-аутентификатор).
2. Убедиться, что у root нет ключей доступа, и удалить их, если есть.
3. Поставить сложный уникальный пароль и почту, которую контролирует компания, а не личную.
4. Создать отдельную учётную запись администратора для работы и больше не входить под root.

Root нужен только для редких задач, например некоторых настроек биллинга и аккаунта.

Роли вместо ключей доступа

Access keys — постоянная пара ключей. Если они утекли через репозиторий, лог или ноутбук, они работают, пока кто-то не заметит и не удалит их.

Роли выдают временные учётные данные, которые истекают сами. Используйте их везде, где можно:

• EC2 и контейнеры — прикрепите роль к инстансу или задаче, SDK сам получит учётные данные, без ключей в конфигах.
• Lambda — каждая функция работает с execution role.
• CI/CD — GitHub Actions и похожие системы принимают роль через OIDC без хранения ключей в секретах.
• Люди — для входа сотрудников AWS рекомендует IAM Identity Center, который тоже выдаёт временные учётные данные.

Ключи доступа оставляйте только там, где по-другому нельзя, и регулярно меняйте их.

Минимальные права для небольшой команды

Принцип наименьших привилегий (least privilege) — каждой учётной записи только те права, которые ей действительно нужны.

• Группа Admins — один-два человека, MFA обязательна.
• Группа Developers — доступ к сервисам проекта, в идеале только к ресурсам разработки.
• Группа ReadOnly — для менеджеров, аудиторов и поддержки.
• Отдельная роль на каждое приложение — права только на его бакет, очередь или базу.
• Отдельная роль для деплоя — её принимает CI/CD.

Если нужно стартовать быстро, начните с управляемых политик AWS, а затем сужайте их. IAM Access Analyzer умеет предложить политику на основе того, что учётная запись реально использовала.

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

• Ежедневная работа под root или AdministratorAccess у всех.
• Ключи доступа в Git или в .env на ноутбуке.
• "Action": "*" и "Resource": "*" в политиках приложений.
• Общий пользователь на нескольких человек — непонятно, кто что сделал.
• Забытые учётные записи ушедших сотрудников.