Чтобы защитить #CloudFormation стэки от удаления/изменения (#termination_protection неудобно и даёт лишь защиту от удаления) в каком-то аккаунте (предполагая, что он входит в AWS #Organizations), можно добавить следующее #SCP:

"CloudFormation CRUD Deny"

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1539948147000",
      "Effect": "Deny",
      "Action": [
        "cloudformation:CreateChangeSet",
        "cloudformation:CreateStack",
        "cloudformation:CreateStackInstances",
        "cloudformation:CreateStackSet",
        "cloudformation:CreateUploadBucket",
        "cloudformation:DeleteChangeSet",
        "cloudformation:DeleteStack",
        "cloudformation:DeleteStackInstances",
        "cloudformation:DeleteStackSet",
        "cloudformation:ExecuteChangeSet",
        "cloudformation:SetStackPolicy",
        "cloudformation:UpdateStack",
        "cloudformation:UpdateStackInstances",
        "cloudformation:UpdateStackSet",
        "cloudformation:UpdateTerminationProtection"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

#blue_green_deployment

В продолжение темы защиты #root_user — для особо опасливых можно посоветовать накрыть всё это дело сверху #SCP политикой для #AWS_Organizations, запрещающей работу из-под рута.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:root"
    }
  }
}

Правда некоторые сервисы под капотом используют (требуют) рута, потому стоит протестировать на чём-то неважном (возможно разбанить нужные сервисы, требующие root).

#paranoid #security

⁠Дальнейшее усложнение AWS #Organizations происходит по мере увеличения количества проектов, команд, требований и т.д.

===
Расширенная схема
===

• Общие ресурсы (ECR, снэпшоты, AMI и др.) вместе с #Shared_VPC выделяются в Shared аккаунт.

• Централизованный мониторинг и логи (ELK/Prometheus/Grafana/Sentry и т.д.) занимают свой аккаунт Monitoring (логи прода могут отправляться туда же или в отдельные - тут чисто условно).

• Бэкапы переезжают в DR (Disaster Recovery) аккаунты своих проектов.

• Наборы окружений dev-test-stg-prod-dr объединяются в #OU (Organization Units) для возможности применения к ним групповых SCP политик (объединение может быть и как Dev OU, DR OU etc - тоже чисто условно).

• Если ваша контора хочет целиком переехать в AWS, то выделяется отдельный аккаунт Organization для "организационных" вещей (название не самое удачное, речь об организации-фирме-компании, где, видимо, вы работаете :) ) — AD (Active Directory) для юзеров (самих работников), используемые для #SSO как единой точки входа, а также финансы, биллинги и прочие бухгалтерии, которые совсем не про код - всё будет там.

Процесс детализации #multi_account_strategy можно продолжать дальше - например, добавить OU для #HIPAA и прочих #compliance, где посредством #SCP будут отрабатывать их требования. Многие используеют Sandbox и/или личные аккаунты для разработчиков. И так далее и тому подобное — основные типы уже были перечислены и это уже лишь детали.

Как запретить использование всех других регионов кроме нужных

Допустим, что на вашем проекте используются лишь регионы N.Virginia, Oregon и Ireland, а остальные вы хотите запретить вообще. Если используется #Organizations, то это реализуется с помощью #SCP.

https://docs.aws.amazon.com/en_us/organizations/latest/userguide/orgs_manage_policies_example-scps.html#example-scp-deny-region

Однако в примере перечислены не все глобальные сервисы и вы будете получать ошибки в консоли на тех, которые не указаны в блоке NotAction.

Воспользуемся заготовкой из предыдущего поста и в результате получим "безошибочный" вариант:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "OnlyOurRegions",
     "Effect": "Deny",
     "NotAction": [
       "a4b:*",
       "budgets:*",
       "ce:*",
       "chime:*",
       "cloudfront:*",
       "cur:*",
       "globalaccelerator:*",
       "health:*",
       "iam:*",
       "importexport:*",
       "mobileanalytics:*",
       "organizations:*",
       "route53:*",
       "route53domains:*",
       "shield:*",
       "support:*",
       "trustedadvisor:*",
       "waf:*",
       "wellarchitected:*"
     ],
     "Resource": "*",
     "Condition": {
       "StringNotEquals": {
         "aws:RequestedRegion": [
           "us-east-1",
           "us-west-2",
           "eu-west-1"
         ]
       }
     }
   }
 ]
}

#IAM #AWS_Region

SCP для запрета запуска мощных виртуалок

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringNotLike": {
      "ec2:InstanceType": [
        "*.nano",
        "*.micro",
        "*.small",
        "*.medium"
      ]
    }
  }
}

Удобно применять для каких-то sandbox или каких-то личных аккаунтов, чтобы ограничить разработчиков возможностью запускать лишь слабые виртуалки.

#Organizations #SCP #policy

SCP для запрещения обновления CloudFormation стэков

Если вы деплоите всё с помощью CloudFormation и используете мульти-аккаунт схему, то очень удобно в конце отработки процесса создания/обновления для требующих защиты окружений (читай - prod) накладывать на аккаунт следующее SCP:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": [
       "cloudformation:CreateChangeSet",
       "cloudformation:CreateStack",
       "cloudformation:CreateStackInstances",
       "cloudformation:CreateStackSet",
       "cloudformation:CreateUploadBucket",
       "cloudformation:DeleteChangeSet",
       "cloudformation:DeleteStack",
       "cloudformation:DeleteStackInstances",
       "cloudformation:DeleteStackSet",
       "cloudformation:ExecuteChangeSet",
       "cloudformation:SetStackPolicy",
       "cloudformation:UpdateStack",
       "cloudformation:UpdateStackInstances",
       "cloudformation:UpdateStackSet",
       "cloudformation:UpdateTerminationProtection"
     ],
     "Resource": [
       "*"
     ]
   }
 ]
}

В списке запрещены именно изменяющие действия, просто запретить cloudformation:* неудобно, т.к. тогда не получится зайдя в этот аккаунт посмотреть текущее состояние CloudFormation стэков. А так внешне ничего не меняется, только CI/CD утилиты получат отказ при случайном (или намерянном) запуске - прод в безопасности.

#SCP

⁠Форсирование создания ресурсов только через CloudFormation

Если раньше создание ресурсов через CloudFormation было лишь рекомендацией и #best_practices, то теперь с помощью нового Condition параметра aws:CalledViaFirst это можно сделать требованием:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-calledviafirst

Также, в продолжение предыдущего поста - можно защитить окружение от создания Терраформом. Не знаю зачем, но можно. :)

#IAM #SCP #Condition #CloudFormation

Видео по #IAM, #ABAC, #SCP и прочим Access Management тонкостям.

Высокий уровень сложности (Level 400 - Expert, т.е. максимальный по шкале Амазона). Но кому-то это, может, и в плюс - ABAC стратегия описывается весьма детально (обычно лишь общие фразы) и с примерами.

https://www.youtube.com/watch?v=BFrWnKZ0DQ8

#video

​​SCP и мастер (root) AWS-аккаунт

Стоит помнить, что "всемогущие" политики SCP, которые так удобно можно применять ко всей организации — не применяются к юзерам и ролям мастер аккаунта (root-аккаунта):

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

Потому, если, например, думаете, включать или не включать CloudTrail в регионах, что планируете запретить через SCP — однозначно стоит включать. Уже лишь как раз по причине того, что в мастере SCP не сработает, а две защиты лучше, чем одна (в подаккаунтах).

#SCP #Organizations

​​Кто виноват и что делать?

Наверняка все знают эту картинку (внизу поста). Кто не знает, обязательно стоит изучить, т.к. это база для понимания как работает доступ на AWS.

Когда возникает проблема доступа и вы получаете отлуп access denied от IAM, то проблема может быть результатом запрета доступа на любой из стадий с картинки (куда ещё нужно мысленно добавить политики S3 buckets и VPC endpoints).

И нет способа однозначно понять, кто же заблочил доступ, нужно держать в голове все варианты, итерационно перебирать, от того, что прописано в IAM до того, что доступно лишь админу на уровне Organizations - запрета от SCP.

Но теперь выход есть, то есть будет очень скоро!

https://aws.amazon.com/blogs/security/aws-introduces-changes-to-access-denied-errors-for-easier-permissions-troubleshooting/

Мы, наконец, сможем получать конкретный отчёт — что же стало результатом IAM access denied, в первой версии это будут следующие варианты:

🔹 SCP
🔹 Resource-based policies (S3 buckets, ECR, ES etc)
🔹 IAM permissions boundaries
🔹 Session policies
🔹 IAM policies
🔹 VPC endpoint policies

Очень круто, это огромное облегчение для дебага проблем доступа. Так долго ждал этого, как говорится, не прошло и десять лет! (а вот и нет - прошло 😄)

В общем, ждём сентября.

#IAM #SCP #debug