Освоение AWS IAM: Эффективное устранение ошибок Access Denied

Ошибки AWS IAM AccessDenied означают, что AWS оценил ваш запрос и не нашел действующего пути разрешений. Самый быстрый способ исправления — не угадывание более широкой политики, а определение точного действия, ресурса, субъекта и контекста условий, которые AWS оценил.

Большинство сбоев IAM происходит по одной из четырех причин: отсутствие соответствующего Allow, явный Deny, граница разрешений или политика контроля сервисов, ограничивающая идентификатор, или условие, не соответствующее запросу.

Начните с логики оценки IAM

AWS начинает с запрета по умолчанию. Запрос разрешается только тогда, когда применимая политика разрешает его, и ни одна применимая политика не запрещает его.

Явный Deny имеет приоритет над любым Allow. Этот запрет может исходить от политики идентификатора, политики ресурса, границы разрешений, политики сессии, политики контроля сервисов или другого применимого типа политики.

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

Зафиксируйте точный неудачный запрос

Прежде чем редактировать политики, зафиксируйте следующие детали:

• Субъект: пользователь, роль, сессия принятой роли или сервисный принципал AWS.
• Действие: операция API, например s3:GetObject или ec2:RunInstances.
• Ресурс: ARN или идентификатор ресурса.
• Регион и аккаунт.
• Условия: исходный IP, конечная точка VPC, MFA, теги, контекст шифрования или запрошенный регион.

CloudTrail обычно является лучшим источником. Найдите неудачное событие примерно в момент ошибки и проверьте eventName, userIdentity, resources, errorCode и errorMessage.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 10

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

Используйте инструменты симуляции и анализа доступа

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

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

aws sts decode-authorization-message \
  --encoded-message '<закодированное-сообщение-из-ошибки>'

Это декодированное сообщение может показать, какой тип политики способствовал запрету.

IAM Access Analyzer полезен для вопросов, связанных с политиками ресурсов и кросс-аккаунтным доступом. Он может помочь найти непреднамеренный внешний доступ и проверить некоторые политики перед развертыванием.

Проверьте каждый уровень политики

Политики на основе идентификатора прикрепляются к пользователям, группам и ролям. Они определяют, что может делать идентификатор.

Политики на основе ресурсов прикрепляются к ресурсам, таким как корзины S3, ключи KMS, очереди SQS, функции Lambda и политики доверия ролей. Они определяют, кто может использовать этот ресурс или принять эту роль.

Границы разрешений устанавливают максимальные разрешения для пользователя или роли. Сами по себе они не предоставляют доступ. Эффективные разрешения представляют собой пересечение политики идентификатора и границы.

Политики контроля сервисов в AWS Organizations устанавливают максимальные разрешения для аккаунтов или организационных единиц. SCP сами по себе также не предоставляют доступ. Они могут заблокировать действие, даже если политика IAM его разрешает.

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

Распространенные шаблоны AccessDenied

Отсутствие зависимых действий

Некоторые операции AWS требуют больше, чем очевидное действие. Например, запуск зашифрованного экземпляра EC2 может потребовать разрешений EC2 плюс разрешений KMS для ключа. CloudTrail и документация сервиса — ваши лучшие источники для зависимых действий.

Неправильный ARN ресурса

ARN на уровне корзины S3 и на уровне объекта различаются:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

arn:aws:s3:::my-bucket охватывает корзину. arn:aws:s3:::my-bucket/* охватывает объекты в корзине. Многие ошибки S3 возникают из-за предоставления одного, когда вызову API требуется другое.

Несоответствие условий

Условия должны точно соответствовать контексту запроса. Политика, разрешающая доступ только через одну конечную точку VPC, запретит запросы от другой конечной точки, от публичной конечной точки AWS или из другого региона, если условие проверяет этот регион.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-sensitive-data",
    "arn:aws:s3:::my-sensitive-data/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

Этот оператор запрещает HTTP-запросы и разрешает HTTPS-запросам продолжить прохождение остальной части оценки политики. Сам по себе он не предоставляет доступ.

Пробелы в политике ключей KMS

KMS является частым источником запутанных ошибок доступа. Политика IAM может разрешать kms:Decrypt, но политика ключа также должна разрешать субъекту напрямую или разрешать аккаунту делегировать доступ через политики IAM.

Проверьте политику ключа, гранты, условия контекста шифрования и сервис, использующий ключ.

Практический процесс устранения неполадок

Сначала воспроизведите или зафиксируйте неудачный вызов. Получите точное действие API и субъекта из CloudTrail.

Затем найдите явные запреты в SCP, политиках ресурсов, границах разрешений и политиках идентификатора. Явные запреты экономят время, так как они переопределяют все остальное.

Затем подтвердите наличие соответствующего разрешения для точного действия и ресурса. Включите зависимые действия и связанные ресурсы, такие как ключи KMS, роли IAM, передаваемые сервисам, сетевые интерфейсы или группы журналов.

Наконец, протестируйте с максимально узким изменением политики. Избегайте исправления неизвестного запрета с помощью Action: "*" или Resource: "*"; это скрывает проблему и создает новый риск безопасности.

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