Amazon SCS-C02: Управление идентификацией и доступом — Руководство по подготовке

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Часть AWS Security Specialty SCS-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Сущности, субъекты и оценка политик

IAM различает сущности (пользователи, группы, роли) и субъекты (аутентифицированная сущность, выполняющая запрос). Пользователи — это долгоживущие сущности со статическими учетными данными; роли не имеют собственных учетных данных и принимаются для получения временных токенов STS. Группы — это контейнеры для присоединения политик к пользователям; они никогда не являются субъектами и не могут быть приняты.

Каждый вызов API проходит через детерминированную цепочку оценки: явный запрет (Deny) в любом месте имеет приоритет, затем SCP на уровне организации должны разрешать действие, затем границы разрешений (permissions boundaries) должны разрешать, затем политики сессии (если есть) должны разрешать, и, наконец, хотя бы одна политика на основе сущности или ресурса должна содержать разрешение (Allow). Отсутствие любого разрешающего уровня приводит к неявному запрету. Вот почему многоуровневость важна: политика сущности, предоставляющая s3:*, бессмысленна, если SCP запрещает s3:DeleteBucket или граница разрешений полностью исключает S3.

Политики на основе ресурсов (политики бакетов S3, политики ключей KMS, политики топиков SNS, политики функций Lambda) могут предоставлять доступ напрямую субъекту без какой-либо политики сущности на стороне вызывающего — в пределах одного и того же аккаунта. Для межаккаунтного доступа и политика сущности в исходном аккаунте, и политика ресурса в целевом аккаунте должны разрешать это действие.

Роли, политики доверия и AssumeRole

Роль имеет два документа политик: политику доверия (кто может ее принять) и одну или несколько политик разрешений (что можно делать после принятия роли). Политика доверия — это политика на основе ресурса, применяемая к самой роли и использующая действие sts:AssumeRole. Без соответствующей политики доверия вызов AssumeRole завершится с ошибкой AccessDenied, даже если у вызывающего есть sts:AssumeRole в его политике сущности.

Для межаккаунтного делегирования политика доверия указывает доверенный аккаунт или ARN конкретной роли/пользователя в этом аккаунте и — что критически важно для доступа третьих сторон — требует ExternalId:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

ExternalId защищает от проблемы смешанного заместителя (confused deputy): без него сторонний SaaS-провайдер, принимающий роли во многих аккаунтах клиентов, может быть обманом вынужден действовать от имени роли не того клиента. Отсутствие sts:ExternalId в условии или передача неверного значения при вызове sts:AssumeRole приводит к ошибке AccessDenied при принятии роли — это распространенная ошибка конфигурации при подключении сторонних поставщиков, таких как инструменты мониторинга или CSPM.

Для сервисов AWS (Lambda, EC2, задачи ECS) политика доверия указывает сервисный субъект (service principal), например, "Service": "lambda.amazonaws.com". Функция Lambda, которой нужен доступ к S3, должна принять роль выполнения (execution role), политика разрешений которой предоставляет s3:GetObject и s3:PutObject для бакета; аналогично, политика бакета S3 может указать ARN роли функции в качестве субъекта. Любой из этих механизмов работает самостоятельно в пределах одного аккаунта.

Границы разрешений (Permissions Boundaries)

Граница разрешений — это расширенный механизм контроля, присоединяемый к пользователю или роли, который ограничивает максимальные разрешения, которые эта сущность может когда-либо иметь, независимо от того, что предоставляют политики на основе сущности. Эффективные разрешения — это пересечение политики сущности и границы разрешений. Если политика группы предоставляет ec2:*, но граница разрешает только ec2:Describe*, пользователь сможет выполнять только операции describe.

Границы часто используются для делегирования разрешений: позволить разработчикам создавать IAM-роли для своих приложений, но требовать, чтобы каждая создаваемая ими роль имела определенную границу. IAM-политика для разработчика включает условие, подобное "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary", для действий iam:CreateRole и iam:PutRolePolicy. Это предотвращает эскалацию привилегий, в то же время позволяя самообслуживание.

Частое заблуждение состоит в том, что членство в группе или дополнительные присоединенные политики могут «переопределить» границу разрешений или SCP. Это не так — граница и SCP являются потолком разрешений, а не полом.

Принудительное использование MFA через условия

Два ключа условий управляют политикой MFA: aws:MultiFactorAuthPresent (логический, true, если сессия была получена с использованием MFA) и aws:MultiFactorAuthAge (числовой, секунды с момента проверки MFA). Принудительное использование MFA для чувствительных API и ограничение времени жизни сессии выглядит так:

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

Два часа — это 7200 секунд. Использование BoolIfExists вместо Bool может быть опасно для вызовов от сервисных субъектов (service principals), которые никогда не содержат этот ключ — условие будет оценено как true, что фактически обходит проверку для таких вызовов. Поэтому предпочитайте Bool, когда цель — принудительное использование MFA для людей.

Поскольку запросы через CLI и SDK, использующие долгосрочные ключи доступа, не содержат контекст MFA, пользователи должны сначала вызвать sts:GetSessionToken (с параметрами --serial-number и --token-code) или sts:AssumeRole (с --serial-number/--token-code), чтобы получить временные учетные данные, которые включают контекст MFA. Эти временные учетные данные затем удовлетворяют условию MultiFactorAuthPresent:

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center и федерация

IAM Identity Center (ранее AWS SSO) централизует доступ сотрудников в рамках AWS Organization. Наборы разрешений (Permission sets) — это шаблоны, которые Identity Center материализует в виде IAM-ролей в каждом целевом аккаунте при назначении пользователя или группы. Назначения связывают три элемента: субъект (пользователь или группа из каталога Identity Center или внешнего IdP, такого как Okta/Entra ID), набор разрешений и один или несколько аккаунтов.

Наборы разрешений могут содержать управляемые AWS политики, управляемые клиентом политики (ссылаются по имени, поэтому они должны существовать в каждом целевом аккаунте), встроенные (inline) политики и границы разрешений (permissions boundary). Когда вы редактируете набор разрешений, Identity Center повторно настраивает базовые роли — вы никогда не редактируете эти роли напрямую.

Для SAML-федерации вне Identity Center, AWS проверяет подпись утверждения (assertion) по метаданным IdP, зарегистрированным в объекте IAM SAML provider. Когда IdP ротирует свой сертификат подписи, необходимо загрузить обновленный XML-файл с метаданными; в противном случае STS вернет ошибку InvalidIdentityToken / Response Signature Invalid. Обновление метаданных с помощью команды

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

является решением с минимальными накладными расходами — нет необходимости пересоздавать провайдера или перенастраивать отношения доверия.

Root-аккаунт, отчеты об учетных данных и принцип наименьших привилегий

Root-пользователь имеет полный доступ, который невозможно отозвать, и должен рассматриваться как учетная запись для экстренного доступа (break-glass): включите аппаратное или виртуальное MFA-устройство, удалите все ключи доступа root, не используйте его для повседневной работы и храните учетные данные в офлайне. Используйте SCP на уровне корня организации или OU, чтобы даже администраторы в аккаунтах-участниках не могли отключить GuardDuty, удалить CloudTrail или покинуть определенные регионы. SCP никогда не предоставляют разрешений — они лишь фильтруют то, что может предоставить IAM в аккаунте-участнике.

Принцип наименьших привилегий реализуется с помощью инструментов, а не интуиции. Сгенерируйте отчет об учетных данных IAM (IAM credential report) (сначала

undefined

, затем

undefined

), чтобы найти неиспользуемых пользователей, устаревающие ключи доступа и пользователей без MFA. Используйте IAM Access Analyzer, чтобы выявить политики ресурсов, открывающие доступ к данным между аккаунтами, и сгенерировать политики с точно подобранными правами на основе активности в CloudTrail. Используйте данные о последнем доступе (last-accessed) (

undefined

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

Последняя ловушка, о которой стоит сказать отдельно: предположение, что достаточно добавить Allow в политику удостоверения. Если политика ключа KMS не указывает вашу роль, SCP запрещает действие или граница разрешений его не включает, вызов все равно завершится ошибкой. Всегда проверяйте весь стек — SCP, границу разрешений, политику удостоверения, политику ресурса и политику сессии — при устранении неполадок с AccessDenied.

Практическая задача: сценарий использования

Сценарий: Meridian Financial использует AWS Organization из трех аккаунтов для управления, производственных и разработческих нагрузок. В производственном аккаунте хранятся конфиденциальные торговые и клиентские данные. В настоящее время у них смешанная среда из устаревших IAM-пользователей с долгоживущими учетными данными, аккаунтов подрядчиков и SAML-провайдера идентификации Okta, что приводит к непоследовательному контролю доступа и разрозненным конфигурациям ролей между аккаунтами.

Задача: Недавний инцидент был связан с компрометацией учетных данных подрядчика, который принял меж-аккаунтную роль без MFA и выполнил избыточные действия, поскольку не было границ разрешений или централизованных наборов разрешений. Meridian необходимо усилить федерацию, доверие ролей и принудительно внедрить MFA и принцип наименьших привилегий во всех аккаунтах.

Рекомендуемый подход:

1. Развернуть AWS IAM Identity Center, интегрированный с Okta SAML, как единый уровень федеративной идентификации и перевести всех людей-пользователей и подрядчиков с долгоживущих IAM-пользователей на аккаунты на базе Identity Center, отключив доступ к консоли/ключи для устаревших IAM-пользователей.
2. Создать централизованные наборы разрешений в IAM Identity Center, которые сопоставляются с IAM-ролями в аккаунтах-участниках, и внедрить границы разрешений IAM (permission boundaries) (определенные как IAM-политики) для всех ролей; развернуть эти границы и шаблоны ролей по всем аккаунтам с помощью AWS CloudFormation StackSets.
3. Обновить политики доверия меж-аккаунтных ролей, чтобы разрешать sts:AssumeRole только от ARN субъектов Identity Center, и включить условия, требующие MFA (например, aws:MultiFactorAuthPresent) и ограничения по исходному аккаунту; требовать, чтобы теги сессии содержали атрибуты удостоверения.
4. Принудительно включить MFA на уровне IdP (Okta) и отразить это требование в AWS, добавив условия MFA в сессии ролей; запретить создание доступа к консоли или новых IAM-пользователей, применив Service Control Policies (SCP) в AWS Organizations.
5. Включить AWS CloudTrail, AWS Config и IAM Access Analyzer для непрерывного мониторинга и валидации политик, и отправлять результаты в CloudWatch/GuardDuty для оповещений и автоматизированных рабочих процессов по устранению нарушений.

Обоснование: Централизация федерации через IAM Identity Center, принудительное применение принципа наименьших привилегий с помощью наборов разрешений и границ, требование MFA в политиках доверия, а также применение SCP на уровне организации и мониторинг соответствуют лучшим практикам AWS, чтобы уменьшить радиус поражения, предотвратить эскалацию привилегий и обеспечить возможность аудита.

Роли IAM и политики доверия: PassRole и AssumeRole

Роль IAM имеет два различных аспекта политики, и их путаница является основной причиной большинства сбоев авторизации между аккаунтами. Политика доверия (AssumeRolePolicyDocument) отвечает на вопрос, кто может принять роль и при каких условиях. Политика разрешений отвечает на вопрос, что может делать роль после ее принятия. Оба аспекта должны разрешать действие; одна лишь политика доверия никогда не предоставляет доступ к S3, KMS или чему-либо еще.

Когда субъект вызывает sts:AssumeRole, STS оценивает политику доверия целевой роли в контексте вызывающего субъекта и сессии (IP-адрес источника, состояние MFA, теги сессии, внешний ID). Вызывающий субъект должен также иметь разрешение Allow на основе идентификации для sts:AssumeRole на ARN этой роли. Это двойное требование делает принятие роли безопасным между аккаунтами.

Каноническая политика доверия для межсетевого доступа, требующая MFA и внешний ID, выглядит так:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

Ключ aws:MultiFactorAuthPresent имеет смысл только в политике доверия принимаемой роли, поскольку контекст MFA устанавливается во время вызова STS, а не при последующих вызовах сервисов. Добавление условий MFA в политику бакета S3 или в политику разрешений роли — распространенная ошибка: сессия с принятой ролью обычно не содержит aws:MultiFactorAuthPresent=true, даже если исходный пользователь аутентифицировался с помощью MFA, поэтому такие условия неявно всё запрещают. Применяйте MFA во время принятия роли; используйте aws:MultiFactorAuthAge, чтобы требовать повторной аутентификации для долгоживущих сессий.

PassRole — это второй барьер, на котором строятся экзаменационные сценарии. Когда вы указываете сервису, такому как CloudFormation, EC2, Lambda или CodeBuild, выполняться от имени роли, вызывающий субъект должен иметь `iam:PassRole

Практическая задача: сценарий использования

Сценарий: Компания Meridian Financial использует мультиаккаунтную AWS Organization с отдельными аккаунтами для продакшена, разработки и инструментов CI/CD. Они используют централизованные роли IAM для межсетевых развертываний и сторонние агенты CI, которые принимают роли для внесения изменений в инфраструктуру. Границы идентификации обеспечиваются политиками доверия ролей, а некоторые команды используют долгоживущие профили экземпляров и функции Lambda, которым предоставлено разрешение iam:PassRole для присоединения ролей к экземплярам или задачам.

Проблема: Недавний аудит выявил слишком широкое разрешение iam:PassRole, которое позволяло субъекту CI/CD передавать роль администратора профилю экземпляра EC2. Злоумышленник воспользовался доверием AssumeRole для получения избыточных привилегий в разных аккаунтах.

Рекомендуемый подход:

1. Используйте AWS CloudTrail и Amazon EventBridge для выявления недавних вызовов API iam:PassRole и sts:AssumeRole, а также выполняйте запросы в CloudTrail Lake или Athena, чтобы составить список субъектов, которые передавали определенные ARN ролей, и времени этих действий.
2. Запустите IAM Access Analyzer (для IAM) в разных аккаунтах, чтобы обнаружить уязвимости в политиках доверия на основе ресурсов и составить список ролей, которые можно принять из-за пределов Organization или внешними субъектами.
3. Замените широкие политики iam:PassRole на политики IAM с минимальными привилегиями, которые указывают точные ARN ролей в Resource, и добавьте ключи условий, такие как aws:PassedToService или aws:PrincipalOrgID, чтобы ограничить, кто и что может получить роль.
4. Усильте политики доверия ролей, добавив обязательные условия — используйте aws:PrincipalOrgID, sts:ExternalId для третьих сторон, требуйте aws:SourceIdentity и устанавливайте максимальную продолжительность сессии — чтобы предотвратить широкое использование AssumeRole неизвестными субъектами.
5. Настройте правила Amazon EventBridge для обнаружения аномалий с iam:PassRole и AssumeRole, отправляйте оповещения в Amazon SNS и создавайте автоматизированные сценарии Lambda (playbooks) для отзыва или исправления слишком широких политик, а также записывайте результаты в AWS Security Hub и AWS Config для непрерывного соответствия требованиям.

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

Все домены · Обнаружение угроз и оповещение →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →