Межаккаунтные роли и политики ресурсов

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

Безопасный способ — никогда не копировать учётные данные между аккаунтами. Вместо этого предоставляйте доступ с ограниченной областью действия с помощью ролей между аккаунтами или политик на основе ресурсов.

Наиболее распространённый шаблон — роль в целевом аккаунте, которую принимает субъект из исходного аккаунта.

• Политика доверия роли указывает исходный аккаунт или субъект.
• Исходный субъект вызывает AssumeRole и получает временные учётные данные.
• Затем он действует в целевом аккаунте в пределах разрешений роли.

Для принятия роли между аккаунтами обе стороны должны разрешить это:

• Политика доверия целевой роли разрешает доступ исходному субъекту.
• Политика удостоверения исходного субъекта разрешает sts:AssumeRole для этой роли.

Если отсутствует хотя бы одно из этих разрешений, принятие роли завершается ошибкой. Эта двойная проверка часто встречается на экзамене.

Некоторые сервисы поддерживают политики на основе ресурсов, прикреплённые непосредственно к ресурсу, например политику корзины S3, политику ключа KMS или политику очереди SQS.

Они могут предоставлять доступ субъекту из другого аккаунта без принятия этим субъектом роли. Внешний аккаунт использует собственное удостоверение, а политика ресурса разрешает ему доступ.

Выбирайте механизм в зависимости от сервиса:

• Для сервисов без политики ресурсов (EC2, большинство API) используйте роль между аккаунтами.
• Для S3, KMS, SNS, SQS, Lambda и других сервисов политика ресурсов может предоставить прямой доступ между аккаунтами.

Политики ресурсов позволяют избежать дополнительного перехода через AssumeRole.

Предоставляя сторонней организации (например, поставщику SaaS) доступ между аккаунтами, добавьте условие с внешним идентификатором в политику доверия.

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

Роли между аккаунтами должны предоставлять минимально необходимый доступ с ограничением по конкретным ресурсам и действиям.

Распространённая ошибка — широкое доверие ко всему внешнему аккаунту в сочетании с правами администратора. Ограничьте доверие конкретной ролью или пользователем, а разрешения — точной задачей.

Часто определённую функцию централизуют в одном аккаунте, к которому другие обращаются через роли; например, аккаунт безопасности принимает роли только для чтения во всех аккаунтах рабочих нагрузок.

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

AWS Resource Access Manager (RAM) позволяет совместно использовать определённые ресурсы, например подсети или шлюзы Transit Gateway, между аккаунтами одной организации.

RAM предназначен для совместного использования самого ресурса, а не для предоставления разрешений API на работу с ним. Он дополняет роли и политики ресурсов при совместном использовании сети и инфраструктуры.

Доступ между аккаунтами расширяет поверхность доверия, поэтому регулярно проводите его аудит.

• CloudTrail записывает каждый вызов AssumeRole и API-вызов между аккаунтами.
• IAM Access Analyzer выявляет политики ресурсов, предоставляющие доступ за пределами вашего аккаунта.

Проверяйте эти сведения, чтобы своевременно обнаруживать непреднамеренное совместное использование.

Чтобы безопасно связать аккаунты, предпочитайте роли для вычислительных ресурсов и API, политики ресурсов для сервисов хранения и обмена сообщениями и всегда применяйте минимальные полномочия, используя внешний идентификатор для сторонних организаций.

Никогда не передавайте долгосрочные ключи между аккаунтами.

Проанализируйте доступ между аккаунтами.

Вы узнали, как безопасно связывать аккаунты.

• Для ролей между аккаунтами требуются и политика доверия, и политика удостоверения исходного субъекта.
• Политики на основе ресурсов предоставляют прямой доступ для таких сервисов, как S3 и KMS.
• Используйте внешний идентификатор для сторонних организаций и проводите аудит с помощью Access Analyzer и CloudTrail.