Управление разрешениями организации с помощью «Политики управления службами (SCP)»

Если вам трудно управлять разрешениями вашей организации или вас беспокоят разрешения пользователей или ролей IAM. Тогда это для вас. SCP (Service Control Policy) решит все ваши проблемы. Просто воспользуйтесь ею и поспите подольше.

Если у вас еще нет такой организации, тогда следуйте следующим инструкциям

Политика контроля обслуживания (SCP): Политики контроля услуг (SCP) — это тип организационной политики, которая помогает вам контролировать доступ к вашим всем учетным записям организации. SCP гарантируют вам, что все ваши учетные записи останутся в рамках руководства по контролю доступа вашей организации (за исключением учетной записи root или учетной записи управления организацией).

SCP предоставляют разрешения не на учетные записи ваших организаций, а на те, которые определяют guardrail или set limits на actions, которые администратор учетной записи может делегировать IAM пользователям и roles в затронутых учетных записях.

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

Включение SCP вашей организации

Зайдите в учетную запись управления организации или в учетную запись root. Затем откройте консоль AWS Organizations.
Затем на вкладке Policies откройте Service control policies.
Просто нажмите кнопку Enable service control policies, чтобы включить SCP для вашей организации.

Примечание: SCP доступны только в организации, в которой включены все функции.

Вы успешно включили SCP. По умолчанию политика FullAWSAccess будет присоединена ко всем OU и учетным записям.

Политики SCP:

  • Политика SCP имеет тот же формат, что и политика IAM.

  • Политика SCP прикрепляется к OU (Organizational Unit) или учетной записи.

  • Каждая OU или учетная запись должна иметь одну прикрепленную политику SCP. По умолчанию подключена политика FullAWSAccess.

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

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

Создание политик SCP и прикрепление/открепление к OU/аккаунту

Вы можете создать столько политик, сколько вам нужно. Синтез политик будет таким же, как и политик IAM.

Вы можете присоединять или отсоединять политики из списка политик SCP.

Или
Вы можете присоединить или отсоединить ее из представления OU или учетной записи. Если вы нажмете на любую OU или учетную запись, это покажет вам опцию политики, а также отобразит все политики SCP. Затем вам просто нужно прикрепить или отсоединить политики.

Стратегии использования SCP

Блокирующий список или список запретов: Все действия разрешены по умолчанию, а вы указываете, какие службы и действия являются запрещенными. Конфигурация по умолчанию.

Белый список или список разрешений: По умолчанию все действия запрещены, а вы указываете, какие службы и действия являются разрешенными.

Пример

Предположим, что ваша диаграмма организаций выглядит следующим образом:

Здесь мы видим, что у нас есть

  • 1 Управляющая учетная запись
  • 2 OU (организационные единицы)
  • 3 учетные записи членов AWS. где
    • Учетная запись-1 и учетная запись-2 под приостановленной OU
    • Учетная запись-3 под производственной OU

Блокирующий список или запрещающий список: Это конфигурация по умолчанию AWS Organization SCP. Предположим, мы очень обеспокоены работой наших производственных служб CloudWatch, Config, GuardDuty и CloudTrail и не хотим, чтобы кто-то мог отключить эти службы. Тогда подход Blocklist или deny list будет лучшим решением для этого случая использования.

Создайте политику с именем denyLogServices (любое другое):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudwatch:DeleteAlarms",
        "cloudwatch:DeleteDashboards",
        "cloudwatch:DisableAlarmActions",
        "cloudwatch:PutDashboard",
        "cloudwatch:PutMetricAlarm",
        "cloudwatch:SetAlarmState",
        "config:DeleteConfigRule",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder",
        "guardduty:AcceptInvitation",
        "guardduty:ArchiveFindings",
        "guardduty:CreateDetector",
        "guardduty:CreateFilter",
        "guardduty:CreateIPSet",
        "guardduty:CreateMembers",
        "guardduty:CreatePublishingDestination",
        "guardduty:CreateSampleFindings",
        "guardduty:CreateThreatIntelSet",
        "guardduty:DeclineInvitations",
        "guardduty:DeleteDetector",
        "guardduty:DeleteFilter",
        "guardduty:DeleteInvitations",
        "guardduty:DeleteIPSet",
        "guardduty:DeleteMembers",
        "guardduty:DeletePublishingDestination",
        "guardduty:DeleteThreatIntelSet",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:DisassociateMembers",
        "guardduty:InviteMembers",
        "guardduty:StartMonitoringMembers",
        "guardduty:StopMonitoringMembers",
        "guardduty:TagResource",
        "guardduty:UnarchiveFindings",
        "guardduty:UntagResource",
        "guardduty:UpdateDetector",
        "guardduty:UpdateFilter",
        "guardduty:UpdateFindingsFeedback",
        "guardduty:UpdateIPSet",
        "guardduty:UpdatePublishingDestination",
        "guardduty:UpdateThreatIntelSet",
        "cloudtrail:Delete*",
        "cloudtrail:Update*",
      ],
      "Resource": "*"
    }
  ]
}
Войти в полноэкранный режим Выйти из полноэкранного режима

Затем

  • Нам нужно прикрепить эту политику SCP к Production OU. Тогда она будет применяться для всех учетных записей в Production OU. Даже если мы добавим любую другую учетную запись в Production OU, эта политика будет применяться и там.

  • Затем отключаем стандартную политику SCP ‘FullAWSAccess’. Потому что в подходе Blocklist все действия разрешены по умолчанию.

Примечание: Если вы прикрепите эту политику к корневой OU, то она будет влиять на все ваши OU и учетные записи. Что не является нашим случаем.

Эффект: Эта политика SCP не позволяет пользователям или ролям в любой затронутой учетной записи отключать CloudWatch, Config, GuardDuty & CloudTrail или изменять их конфигурацию, либо непосредственно командой, либо через консоль. Это позволяет получить доступ только для чтения к информации и ресурсам CloudWatch, Config, GuardDuty & CloudTrail. Этого не сможет сделать даже пользователь root затронутой учетной записи.

Белый список или список разрешений: Предположим, у нас есть некоторый старый продукт под Suspended OU. Где используются только сервисы ec2, DynamoDB и Lambda. Поэтому мы не хотим раскрывать все сервисы этих учетных записей, кроме этих. Для этого случая использования лучше всего подойдет подход whitelist.

Создайте политику с именем allowLegacyServices (любое другое):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowsAllActions",
            "Effect": "Allow",
            "Action": [
              "ec2:*",
              "dynamodb:*",
              "lambda:*"
            ],
            "Resource": "*"
        }
    ]
}
Войти в полноэкранный режим Выйти из полноэкранного режима

Затем

  • Прикрепите политику к Suspended OU. Затем она будет применяться ко всем учетным записям и OU под Suspended OU.

  • Затем отсоедините стандартное разрешение SCP FullAWSAccess. В противном случае оба разрешения будут применены. Что не является подходящим случаем. В подходе Withlist все действия запрещены по умолчанию.

Примечание: Вы также можете прикрепить политику SCP к учетной записи пользователя. Но всегда рекомендуется прикреплять политику SCP к OU lavel Тогда она будет применяться ко всем учетным записям и OU под этой OU.

Эффект: Эта политика SCP позволяет пользователям или ролям в любой затронутой учетной записи только ec2, dynamoDB & lambda информацию и ресурсы. Кроме этих прав никто (даже Root User) не может иметь никаких других прав. Даже если пользователь подключил другое разрешение в своих пользователях или ролях, он не будет получать другое разрешение. Максимальный предел, который может получить пользователь или роль, определяется ролью SCP.

Для более подробного примера смотрите здесь

Ограничение

Однако, если вы не уверены, что все учетные записи в вашей организации были созданы после 15 сентября 2017 года, мы рекомендуем вам не полагаться на SCP в попытках ограничить эти операции.

Резюме

SCP — это отличный способ управления разрешениями в организациях из одного центра. Вы можете установить ограничение, разрешив или запретив разрешение нашей организационной единицы OU (Organizational Unit) или учетной записи участника. Это даст вам хорошую уверенность в вашей организационной инфраструктуре. Попробуйте использовать это в своей организации и глубоко усните.

Чтобы узнать больше, ознакомьтесь с документацией по политикам контроля организационных служб AWS (SCPs).

Спасибо за чтение! Счастливых облачных вычислений!

Свяжитесь со мной: Linkedin

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *