IAM — фундамент безопасности AWS: он отвечает на вопрос «кто и что может делать». Большинство утечек в облаке — это не взлом, а слишком широкие права или ключи доступа, попавшие в репозиторий. Поэтому модель IAM — роли вместо ключей и least privilege — нужно понимать не на уровне «дал admin и работает», а по-настоящему.

Пользователи против ролей

IAM-пользователь — постоянная личность с долгоживущими ключами доступа. IAM-роль — набор прав, который временно принимают (assume), получая короткоживущие креды. Ключевой принцип: для сервисов и автоматизации используют роли, а не пользователей с ключами.

Почему: ключи пользователя живут вечно и утекают (в код, в логи, в историю команд). Креды роли выдаются на минуты-часы и обновляются автоматически. Сервис на EC2/ECS/EKS получает права через роль (instance/task role / IRSA) — в коде нет ни одного ключа. Это и есть правильный ответ на «как сервису ходить в S3»: роль, не ключи.

Политики

Право описывается политикой — JSON со списком разрешений.

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

Два вида политик:

  • Identity-based — привязаны к пользователю/роли: «этой роли можно читать из этого бакета».
  • Resource-based — привязаны к ресурсу: «этот бакет разрешает доступ такой-то роли/аккаунту». Нужны для cross-account и для сервисов вроде S3, SQS.

Доступ разрешён, если его допускают обе стороны (и identity, и resource, где применимо), и явно не запрещён (Deny всегда сильнее Allow). Условия (Condition) сужают: только из этой VPC, только с MFA, только в рабочее время.

Least privilege

Главный принцип: давать минимум прав, нужный для задачи, и не больше. Action: "*" и Resource: "*" — почти всегда дефект. На практике least privilege — это итеративно: начать узко, расширять по фактической потребности (анализаторы доступа показывают, что реально используется). Широкие права «чтобы не возиться» — самая частая причина инцидентов.

STS и временные креды

За временными кредами стоит STS (Security Token Service). AssumeRole возвращает короткоживущий набор креды для роли. На этом построено всё: instance role незаметно дёргает STS, cross-account доступ — это assume роли в другом аккаунте, федерация (вход через корпоративный провайдер) — тоже выдача временных креды. Понимание «креды временные и берутся через assume» снимает большинство вопросов про то, как сервисы получают доступ без ключей.

Cross-account

Доступ между аккаунтами (а аккаунты — граница изоляции) делают через роль: в аккаунте-владельце ресурса заводят роль с trust policy, разрешающей её принимать аккаунту-потребителю, и identity-политикой с нужными правами. Потребитель делает AssumeRole и работает с временными кредами. Никаких общих ключей между аккаунтами.

Где это в UCP

IAM — слой «кто что может» поверх сетевого слоя «кто до кого достучится». Вместе они и есть least privilege в облаке: минимальная сеть плюс минимальные права. Для backend-разработчика практический вывод прост и важен: сервисы получают доступ через роли и временные креды, а не через ключи в конфиге; права выдаются узко. Это то, что отделяет код, который можно безопасно запустить в проде, от кода, который станет инцидентом. Конкретику секретов и шифрования продолжает безопасность и наблюдаемость.