Организации, OU и стратегия SCP

AWS Organizations позволяет централизованно управлять множеством аккаунтов AWS как единой структурой. В ней Service Control Policies (SCPs) задают верхние пределы разрешений, а Organizational Units (OUs) объединяют аккаунты для назначения политик. Грамотное проектирование этой иерархии — основной навык для раздела управления на экзамене SCS-C02.

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

Organizational Unit (OU) объединяет аккаунты с общими потребностями в управлении, например OU «Production», OU «Sandbox» и OU «Security». Подключение SCP к OU распространяет её на каждый содержащийся в ней аккаунт, поэтому аккаунты следует группировать по политикам, которые они должны наследовать.

SCP наследуются вниз по дереву: на аккаунт совместно влияют SCP корневого уровня, родительских OU и самого аккаунта. Чтобы действие было разрешено, оно должно быть разрешено на каждом уровне. Запрет на любом участке цепочки блокирует действие. Этот накопительный эффект имеет ключевое значение при проектировании SCP.

Существуют две стратегии. Список запретов начинается с FullAWSAccess и добавляет явные запреты для действий, которые никогда не должны выполняться, например отключения CloudTrail. Список разрешений удаляет FullAWSAccess и явно перечисляет только разрешённые сервисы, что создаёт гораздо более строгую модель. Большинство организаций начинают со списка запретов ради гибкости.

Эта SCP запрещает всем останавливать ведение журналов CloudTrail — это распространённый защитный механизм, применяемый ко всей организации, чтобы ни один дочерний аккаунт не мог ослепить журнал аудита.

Важное правило: SCP никогда не предоставляют разрешения, а только задают максимальный уровень. Действие должно быть разрешено одновременно SCP и политикой IAM в аккаунте. SCP со списком разрешений лишь делает сервисы доступными для предоставления; IAM всё равно должен предоставить эти разрешения.

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

Два классических защитных SCP запрещают выход из организации (organizations:LeaveOrganization) и запрещают аккаунтам-участникам отключать сервисы безопасности, такие как GuardDuty, Security Hub, Config и CloudTrail. Если применить их на корневом уровне, ни один аккаунт-участник не сможет выйти из-под управления или ослабить средства обнаружения угроз в организации. Это настоятельно рекомендуемый базовый уровень защиты.

Типичная схема выглядит так: базовый SCP со списком запретов на корневом уровне (защита CloudTrail, запрет выхода из организации, ограничение регионов), более строгие SCP для OU Production и менее строгие — для OU Sandbox. Группировка аккаунтов по профилю риска в OU позволяет точно настраивать управление с минимальным разрастанием политик.

Organizations объединяет аккаунты в OU под корневым узлом и аккаунтом управления. SCP наследуются вниз по дереву, и действие должно быть разрешено на каждом уровне. Выберите стратегию со списком запретов (гибкую) или со списком разрешений (строгую), помните, что SCP только ограничивают, но никогда не предоставляют разрешения, а также что они не применяются к аккаунту управления и ролям, связанным с сервисами.

Проверьте свою стратегию SCP.

AWS Organizations объединяет аккаунты в OU под корневым узлом и аккаунтом управления. SCP наследуются вниз по дереву и требуют разрешения на каждом уровне; любой запрет блокирует действие. Используйте стратегию со списком запретов (гибкую) или со списком разрешений (строгую). SCP только ограничивают, но никогда не предоставляют разрешения и не применяются к аккаунту управления или ролям, связанным с сервисами.