Может ли SCP дать права?

Пример: SCP не помогает без IAM policy

// SCP прикреплена к OU — Allow s3:*
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}

// IAM role в account НЕ имеет S3 policy
// Результат: s3:ListBucket → AccessDenied (implicit deny в identity policy)
// SCP Allow не помог — у principal нет собственного Allow

SCP не выдаёт права — только ограничивает

Service Control Policy (SCP) работает исключительно как граница допустимых действий (maximum permissions boundary) для account или OU. Даже явный Allow в SCP не означает, что IAM principal получил разрешение — он означает лишь, что Organizations guardrail не блокирует это действие. Конкретный allow должен прийти из identity policy, resource policy или session policy.

Как проверяется доступ в AWS

При каждом API-вызове AWS проходит по цепочке политик в строгом порядке:

• SCP — если действие не попадает в Allow-list SCP или есть явный Deny, запрос немедленно отклоняется с AccessDenied.
• Permissions boundary — дополнительная граница для IAM entity; тоже не выдаёт прав, только ограничивает.
• Identity policy (IAM) — только здесь появляется реальный Allow для user/role.
• Resource policy — для cross-account или resource-based доступа (S3 bucket policy, KMS key policy).
• Session policy — при AssumeRole с передачей inline policy, сужает права сессии.

Deny-list vs Allow-list подходы

• Deny-list: к account/OU прикреплена FullAWSAccess SCP, а отдельные Deny-statement запрещают нежелательные действия (например, отключение CloudTrail).
• Allow-list: SCP явно перечисляет допустимые service/action; всё остальное неявно запрещено. Но это по-прежнему граница, а не grant.

Пример: SCP Deny побеждает любой IAM Allow

// SCP на OU — Deny ec2:TerminateInstances
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:TerminateInstances",
    "Resource": "*"
  }]
}

// IAM role имеет AdministratorAccess
// Результат: ec2:TerminateInstances → AccessDenied
// Explicit Deny в SCP всегда выигрывает

Диагностика через IAM Policy Simulator

# Проверить эффективные права principal с учётом SCP
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/MyRole \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/file.txt

# Посмотреть, какие SCP применяются к account
aws organizations list-policies-for-target \
  --target-id 123456789012 \
  --filter SERVICE_CONTROL_POLICY

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

• Добавление Allow в SCP — частая ошибка при troubleshooting: разработчик думает, что «открыл доступ», а IAM policy по-прежнему не содержит Allow.
• Временное ослабление SCP для всего OU ради одного account создаёт уязвимость для сотен других аккаунтов.
• SCP не применяется к management account организации — это нередко становится неожиданностью при аудите.
• SCP не применяется к service-linked roles и некоторым AWS-managed actions (например, AWS Support).
• В Allow-list SCP легко забыть разрешить вспомогательные действия (sts:AssumeRole, iam:PassRole), из-за чего ломаются сервисы.
• Цепочка evaluation (SCP → Permissions Boundary → Identity Policy → Resource Policy → Session Policy) нужно проходить целиком — пропуск любого звена даёт неверный диагноз.
• IAM Policy Simulator учитывает SCP только при указании конкретного principal ARN из account с прикреплённой SCP.

• Исправлять AccessDenied добавлением Allow в SCP.
• Не различать allow-list SCP и IAM allow.
• Ослаблять guardrails вместо правки role policy.

• Чётко отвечает, что SCP не grants permissions.
• Объясняет maximum available permissions.
• Применяет это к IAM troubleshooting.