Оценка политик IAM и явный отказ

Использование AWS Security для разработчиков

Rahul Singh

Technical Product Manager

Политика — это список правил

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Три поля одной инструкции IAM расположены друг над другом и пронумерованы от одного до трёх: Effect — разрешение или запрет, Action — какой вызов API, Resource — на что он указывает, обозначенный ARN.

Политика — это список правил

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Четыре поля одной инструкции IAM расположены друг над другом и пронумерованы от одного до четырёх: Effect — разрешение или запрет, Action — какой вызов API, Resource — на что он указывает, обозначенный ARN, и Condition — при каких условиях. Завершающая строка гласит: четыре поля, одно правило.

Три поля задают вопрос, одно отвечает

Вопрос

Action: тот ли это вызов
Resource: та ли это цель
Condition: совпадают ли условия

Ответ

Effect: разрешить или запретить

Четыре поля инструкции IAM расположены по вертикали: Action, Resource и Condition объединены скобкой с подписью «Вопрос», а Effect — отдельной скобкой с подписью «Ответ».

Правила приходят не из одного источника

Документ политики прикреплён к роли, от роли стрелка ведёт к бакету.

На основе удостоверения

Прикреплена к роли
Что может делать эта роль

Правила приходят не из одного источника

Документ политики прикреплён к роли, от роли стрелка ведёт к бакету.

Документ политики прикреплён к ресурсу, от принципала стрелка ведёт к бакету.

На основе удостоверения

Прикреплена к роли
Что может делать эта роль

На основе ресурса

Прикреплена к объекту, к которому обращаются
Кто может обращаться к этому бакету

Когда правила противоречат друг другу

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Когда правила противоречат друг другу

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Запрос: s3:DeleteObject — результат: отказано.

Явный запрет побеждает любое разрешение, каким бы широким оно ни было

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

Порядок оценки и неявный запрет

Блок-схема оценки политики IAM: запрос API сначала проверяется на явный запрет, затем на разрешение, и если ни то ни другое не найдено, срабатывает неявный запрет.

Явный запрет: что-то сказало «нет»
Разрешение: что-то сказало «да», и ничего не сказало «нет»
Неявный запрет: никто ничего не сказал

Четыре запроса, три исхода

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → разрешено: широкое разрешение покрывает это
s3:DeleteObject → явный запрет: инструкция говорит «нет»
kms:Decrypt, dynamodb:GetItem → неявный запрет: эта политика вообще не упоминает эти сервисы
KMS хранит ключи шифрования; DynamoDB — управляемая база данных типа «ключ-значение»

Почему добавление разрешений часто не помогает

Одна ошибка, две причины

Явный запрет

Ещё одно разрешение ничего не меняет
Найдите запрет, затем ограничьте его или удалите

Неявный запрет

Одно точечное разрешение
Для удостоверения, выполнившего вызов

Ошибка AccessDenied разветвляется на две причины. Слева: найден запрет, поэтому дополнительные разрешения ничего не меняют. Справа: разрешение не найдено, поэтому одно точечное разрешение для вызывающего удостоверения решает проблему.

Давайте потренируемся!

Использование AWS Security для разработчиков