Пользователю назначена IAM-политика, разрешающая нужное действие, но он всё равно получает AccessDenied. Какие причины стоит проверить и в каком порядке?

Короткий ответ

AccessDenied при наличии «разрешающей» политики обычно вызван явным deny в другой привязанной политике, ограничением на уровне организации (SCP/organization policy), отсутствующим разрешением на стороне ресурса (resource-based policy) или границей разрешений (permissions boundary) — любой явный запрет или отсутствие разрешения на любом уровне перекрывает allow.

Как это работает подробнее

итоговое решение по доступу — это пересечение всех применимых уровней: политики организации, политики идентичности, permissions boundary и, при обращении к ресурсу другого аккаунта, политики самого ресурса; явный Deny на любом уровне побеждает любой Allow.

Пример кода

policy.jsonКопировать

{
  "Effect": "Deny",
  "Action": "s3:DeleteObject",
  "Resource": "*",
  "Condition": {"StringNotEquals": {"aws:RequestedRegion": "eu-west-1"}}
}

Что использовать на практике

• Рекомендация. диагностику ведут «сверху вниз» — сначала проверяют ограничения на уровне организации, затем permissions boundary, затем саму identity-политику, затем resource policy целевого ресурса; многие провайдеры дают инструмент симуляции политик для этой проверки.
• Проверка. даже если у пользователя есть "Allow": "s3:DeleteObject", запрос из региона, отличного от eu-west-1, будет отклонён с AccessDenied из-за SCP.

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

• Риск. смотреть только на одну политику, «очевидно» разрешающую действие, и не замечать deny на уровне организации
• Риск. забывать, что доступ к ресурсу в другом аккаунте требует разрешения с обеих сторон
• Риск. путать отсутствие явного разрешения с явным deny.