Внешний ID и проблема запутавшегося заместителя

Когда вы разрешаете третьей стороне принимать роль в вашей учетной записи, может возникнуть риск безопасности, называемый проблемой запутавшегося заместителя. Внешний идентификатор — это простой, но важный механизм защиты от нее. Этот шаблон часто встречается на экзамене, когда поставщику SaaS требуется доступ к вашей учетной записи AWS.

Запутавшийся заместитель — это доверенная сущность (заместитель), которую обманом заставляют использовать свои полномочия в интересах злоумышленника. В AWS сторонний сервис получает разрешение принимать роли во множестве учетных записей клиентов. Если ничто не связывает запрос с законными отношениями с клиентом, злоумышленник может обманом заставить сервис принять вашу роль.

Представьте SaaS-сервис мониторинга, который принимает роль в каждой учетной записи клиента. SaaS использует одно удостоверение AWS для всех клиентов. Если злоумышленник, который сам является клиентом, угадает ARN вашей роли, он может убедить SaaS принять вашу роль, поскольку SaaS является доверенным субъектом. Одного идентификатора учетной записи недостаточно для защиты от этого.

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

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

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

Внешний идентификатор не предназначен для хранения в секрете, как пароль; он может присутствовать в инструкциях по настройке. Его защитная ценность определяется тем, что он уникален для каждого клиента и контролируется поставщиком, поэтому злоумышленник не может заставить заместителя использовать значение другого клиента. Считайте его маркером защиты от выдачи себя за другого, а не учетными данными.

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

Шаблон с запутавшимся заместителем применим и к сервисам AWS, действующим от вашего имени. При доверии между сервисами в политиках ресурсов часто используются ключи условий, такие как aws:SourceArn и aws:SourceAccount, чтобы убедиться, что вызывающий сервис действует от имени вашего ресурса. Это та же защитная идея в другой форме.

Если в вопросе описывается принятие роли третьей стороной или SaaS-сервисом между учетными записями, безопасный ответ почти всегда предполагает использование внешнего идентификатора в политике доверия. Если описан обмен данными между сервисами, ищите вместо этого условия aws:SourceArn/aws:SourceAccount. Распознав подсказку, вы сразу определите правильный механизм защиты.

Проблема запутавшегося заместителя позволяет злоумышленнику обманом заставить доверенную третью сторону неправомерно использовать доступ. Внешний идентификатор, уникальный для каждого клиента и контролируемый поставщиком, предотвращает это, требуя совпадающее значение при вызове AssumeRole. Для сервисов AWS используйте aws:SourceArn и aws:SourceAccount. Всегда сочетайте эти механизмы с разрешениями с минимальными привилегиями.

Проверьте понимание концепции запутавшегося заместителя.

Проблема запутавшегося заместителя возникает, когда доверенную третью сторону обманом заставляют неправомерно использовать доступ между учетными записями. Внешний идентификатор, уникальный для каждого клиента и контролируемый поставщиком, предотвращает это благодаря условию политики доверия с использованием sts:ExternalId. Для доверия между сервисами AWS используйте aws:SourceArn и aws:SourceAccount, всегда соблюдая принцип минимальных привилегий.