Политики доверия и те, кто может принять роль

Политика доверия — это документ, прикреплённый к роли и точно определяющий, каким субъектам разрешено её принять. Это страж: даже если политика разрешений предоставляет широкие полномочия, никто не сможет использовать роль, если политика доверия не указывает этого субъекта. На экзамене ошибки в политиках доверия часто становятся причиной как неработающего доступа, так и опасного предоставления избыточных разрешений.

Элемент Principal в политике доверия может ссылаться на:

• AWS — аккаунт, пользователя или ARN роли (Amazon Resource Name);
• Service — сервис AWS, например lambda.amazonaws.com;
• Federated — поставщика SAML или поставщика веб-идентичностей.

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

Для принятия роли между аккаунтами требуется согласие обеих сторон. Политика доверия роли в целевом аккаунте должна разрешать доступ вызывающему субъекту, а этот субъект должен иметь политику идентичности, разрешающую действие sts:AssumeRole над ARN роли. Отсутствие любой из этих частей блокирует запрос. Такое двустороннее рукопожатие — классическая ловушка на экзамене.

Эта политика доверия позволяет определённой роли в аккаунте 111122223333 принять данную роль. Указание точного ARN вместо всего аккаунта обеспечивает более строгую и безопасную настройку.

Указание субъекта как arn:aws:iam::ACCOUNT:root означает доверие всему аккаунту: любой субъект в нём, у которого также есть разрешение sts:AssumeRole, сможет принять роль. Это слишком широкое разрешение. По возможности указывайте точный ARN пользователя или роли, следуя принципу наименьших привилегий и уменьшая поверхность доверия.

Политики доверия поддерживают блоки Condition, которые уточняют, кто и при каких обстоятельствах может принять роль. К распространённым ключам относятся sts:ExternalId (для предотвращения проблемы запутавшегося заместителя), aws:MultiFactorAuthPresent (требование MFA) и aws:SourceIp. Условия позволяют разрешить принятие роли только при определённых проверяемых обстоятельствах.

Мощный подход — требовать MFA перед принятием роли с критически важными полномочиями. Условие политики доверия проверяет, что вызывающий сеанс прошёл аутентификацию с MFA. Поэтому даже с помощью украденных долгосрочных учётных данных нельзя принять привилегированную роль без второго фактора, что значительно повышает сложность атаки.

Некоторые роли являются ролями, связанными с сервисами: они заранее определены AWS и имеют политику доверия, которую нельзя редактировать. Такие роли позволяют сервису управлять ресурсами от Вашего имени, используя ровно тот уровень доверия, который требуется AWS. Важно распознавать их, поскольку их разрешения и доверие жёстко контролируются и связаны с жизненным циклом сервиса.

Доверие внутреннему субъекту (в том же аккаунте) обычно сопряжено с меньшим риском, чем доверие внешнему аккаунту или стороннему поставщику SaaS. Для внешнего доверия всегда сочетайте конкретного субъекта с условиями, например ExternalId. Рассматривайте каждую запись о внешнем доверии как точку входа, которой с радостью воспользуется злоумышленник.

IAM Access Analyzer автоматически проверяет политики доверия и политики ресурсов, чтобы находить роли, которые могут быть приняты внешними аккаунтами или общедоступными субъектами. Он отмечает непреднамеренное межаккаунтное или публичное доверие, чтобы Вы могли его ограничить. Проверка результатов Access Analyzer — рекомендуемая и важная для экзамена мера контроля, позволяющая выявлять слишком широкое доверие.

Чтобы безопасно настроить доверие, указывайте максимально конкретного субъекта, добавляйте подходящие условия, например ExternalId и MFA, отдавайте предпочтение ролям вместо доверия корневому пользователю аккаунта и выполняйте проверку с помощью Access Analyzer. Помните: политика доверия отвечает на вопрос «кто», а политики разрешений — на вопрос «что»; обе части должны согласовываться, чтобы доступ работал и соответствовал принципу наименьших привилегий.

Проверьте свои знания о политиках доверия.

Политика доверия определяет, какие субъекты могут принять роль, и выполняет функцию стража независимо от политик разрешений. Для принятия роли между аккаунтами требуется двустороннее рукопожатие: политика доверия плюс разрешение вызывающего субъекта на выполнение sts:AssumeRole. Предпочитайте точные ARN субъектов корневому пользователю аккаунта, добавляйте условия, такие как ExternalId и MFA, и проводите аудит с помощью IAM Access Analyzer.