Стороннему сервису/подрядчику нужно дать временный доступ к определённым ресурсам в вашем облачном аккаунте без выдачи постоянных ключей доступа. Как спроектировать такой доступ безопасно?

Короткий ответ

Вместо создания IAM-пользователя с долгоживущими ключами создают роль с узко ограниченной политикой доступа и настраивают доверие так, чтобы её мог принять (assume) только конкретный внешний аккаунт/сервис, желательно с дополнительным условием (external ID), после чего выдают подрядчику только ARN роли и способ её принять.

Как это работает подробнее

trust-политика роли определяет, кто имеет право сделать AssumeRole, а сама роль получает только минимально необходимые разрешения; принявший роль получает временные токены с ограниченным сроком жизни вместо постоянных секретов.

Пример кода

policy.jsonКопировать

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::999988887777:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"StringEquals": {"sts:ExternalId": "partner-acme-2024"}}
}

Что использовать на практике

• Рекомендация. для повторяющегося стороннего доступа используют cross-account role с external ID, чтобы предотвратить «confused deputy» атаку; для доступа из CI/CD предпочитают workload identity federation / OIDC-доверие вместо хранения облачных ключей в секретах CI.
• Проверка. подрядчик может вызвать AssumeRole только с правильным external ID и только с указанного аккаунта, получает временные токены на ограниченный срок, доступ автоматически перестаёт работать после истечения или отзыва роли.

Подводные камни

• Риск. выдавать подрядчику постоянного IAM-пользователя с ключом «на время проекта» и забывать его отозвать
• Риск. делать trust-политику слишком широкой
• Риск. не использовать external ID/условия, что делает роль уязвимой, если ARN роли станет известен третьей стороне.