Оцінювання політик 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 — allow або deny, 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 — allow або deny, Action — який виклик API, Resource — на що він вказує, задане ARN, і Condition — за яких умов. Завершальний рядок: чотири поля — одне правило.

Три поля питають, одне відповідає

Питання

Action: це саме той виклик
Resource: це саме та ціль
Condition: умови збігаються

Відповідь

Effect: allow або deny

Чотири поля вислову 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 → результат: Denied.

Явна заборона переважує будь-який allow, хоч як би широкий

Вислів allow і вислів deny сходяться в один запит; шлях deny виділений, підсумок — denied.

Порядок оцінювання і неявна заборона

Блок-схема оцінювання політик IAM: для запиту API спершу перевіряється явна заборона, далі — явний дозвіл, і якщо жодного не знайдено — неявна заборона.

Явна заборона: десь сказано «ні»
Дозвіл: десь сказано «так», і ніде не сказано «ні»
Неявна заборона: ніде нічого не сказано

Чотири запити — три результати

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

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

s3:GetObject → allow: широкий allow це покриває
s3:DeleteObject → explicit deny: є вислів із «ні»
kms:Decrypt, dynamodb:GetItem → implicit deny: ця політика їх не згадує
KMS містить ключі шифрування; DynamoDB — керована key-value база даних

Чому додавання дозволів часто не допомагає

Одна помилка, дві причини

Явна заборона

Додатковий allow нічого не змінює
Знайдіть deny, звузьте або приберіть його

Неявна заборона

Додайте один вузький allow
На ідентичність, що зробила виклик

Помилка AccessDenied розгалужується на дві причини. Ліворуч знайдено deny, тож більше allow нічого не дають. Праворуч allow не знайдено, тож один вузький allow на ідентичність виклику розв'язує проблему.

Давайте потренуємось!

Використання AWS Security для розробників