В продолжение темы защиты #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

​​aws-allowlister — полный набор SCP политик под различные compliance:

https://github.com/salesforce/aws-allowlister

С помощью данной утилиты можно создать SCP правила, которые разрешат работу лишь с сервисами, поддерживаемыми конкретным compliance, например, получить простыню (Allow List), где перечислены все AWS сервисы, разрешённые с точки зрения HIPAA.

Таким образом можно навесить полученный SCP на какой-то AWS аккаунт (или OU) и протестировать в нём окружение, что даст гарантию его HIPAA совместимости.

#SCP #compliance #security

​​SCP Best Practices

🔹 Deny list strategy
🔹 Allow list strategy

🔹 https://aws.amazon.com/blogs/mt/codify-your-best-practices-using-service-control-policies-part-1/

🔸 Organizational Units

🔸 https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/

▪️ Deny Changes to CloudWatch monitors
▪️ Deny Changes to CloudWatch Logs
▪️ Deny Changes to Config
▪️ Deny accounts from leaving the organization
▪️ Deny all actions
▪️ Deny access to IAM with role exception
▪️ Deny actions outside approved regions
▪️ Deny ability to pass IAM roles
▪️ Deny changes to GuardDuty
▪️ Deny changes to AWS Budget Actions
▪️ Limit changes to Cost Anomaly Detection, except when using a specific IAM Role

▪️ https://aws.amazon.com/blogs/mt/codify-your-best-practices-using-service-control-policies-part-2/

☮️

#SCP #security #best_practices

Student SCP policy — политика для защиты аккаунтов, предназначенных для изучения AWS.

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StudentSCPpolicy",
      "Effect": "Deny",
      "Action": [
        "athena:CreateCapacityReservation",
        "aws-marketplace:AcceptAgreementRequest",
        "aws-marketplace:CreateAgreementRequest",
        "aws-marketplace:CreatePrivateMarketplaceRequests",
        "aws-marketplace:Subscribe",
        "backup:CreateLogicallyAirGappedBackupVault",
        "backup:PutBackupVaultLockConfiguration",
        "bedrock:CreateFoundationModelAgreement",
        "bedrock:CreateProvisionedModelThroughput",
        "cloudfront:CreateSavingsPlan",
        "devicefarm:PurchaseOffering",
        "directconnect:ConfirmCustomerAgreement",
        "dynamodb:PurchaseReservedCapacityOfferings",
        "ec2:AcceptReservedInstancesExchangeQuote",
        "ec2:CreateCapacityReservation",
        "ec2:CreateCapacityReservationFleet",
        "ec2:CreateReservedInstancesListing",
        "ec2:LockSnapshot",
        "ec2:PurchaseCapacityBlock",
        "ec2:PurchaseHostReservation",
        "ec2:PurchaseReservedInstancesOffering",
        "ec2:PurchaseScheduledInstances",
        "eks:CreateEksAnywhereSubscription",
        "elasticache:PurchaseReservedCacheNodesOffering",
        "elemental-appliances-software:CreateOrderV1",
        "elemental-appliances-software:SubmitOrderV1",
        "es:PurchaseReservedElasticsearchInstanceOffering",
        "es:PurchaseReservedInstanceOffering",
        "freertos:CreateSubscription",
        "glacier:CompleteVaultLock",
        "glacier:PurchaseProvisionedCapacity",
        "groundstation:ReserveContact",
        "iottwinmaker:UpdatePricingPlan",
        "iq:ApprovePaymentRequest",
        "mediaconnect:PurchaseOffering",
        "medialive:PurchaseOffering",
        "memorydb:PurchaseReservedNodesOffering",
        "organizations:LeaveOrganization",
        "organizations:DeleteOrganization",
        "organizations:RemoveAccountFromOrganization",
        "outposts:CreateOrder",
        "panorama:ProvisionDevice",
        "quicksight:Subscribe",
        "quicksight:UpdateSPICECapacityConfiguration",
        "rbin:LockRule",
        "rds:PurchaseReservedDBInstancesOffering",
        "redshift:AcceptReservedNodeExchange",
        "redshift:PurchaseReservedNodeOffering",
        "route53domains:AcceptDomainTransferFromAnotherAwsAccount",
        "route53domains:RegisterDomain",
        "route53domains:RenewDomain",
        "route53domains:TransferDomain",
        "route53domains:TransferDomainToAnotherAwsAccount",
        "s3:PutBucketObjectLockConfiguration",
        "s3:PutObjectLegalHold",
        "s3:PutObjectRetention",
        "s3-object-lambda:PutObjectLegalHold",
        "s3-object-lambda:PutObjectRetention",
        "savingsplans:CreateSavingsPlan",
        "shield:CreateSubscription",
        "snowball:CreateJob",
        "snowball:CreateLongTermPricing"
      ],
      "Resource": "*"
    }
  ]
}

Student SCP policy не имеет ограничений на адекватные действия и создание любых ресурсов, что могут потребоваться для изучения. Поэтому предполагается обязательная настройка AWS Budgets и алертов.

Если требуется более жёсткие ограничений, то нужно использовать Allow List Approach — вместо запрещения проблемных лишь разрешать нужные.

#security #organizations #scp