Вопросы и ответы по AWS Organizations

AWS Control Tower, разработанный на основе таких сервисов AWS, как AWS Organizations, предоставляет наиболее легкий способ настройки новой и безопасной среды AWS с несколькими аккаунтами и эффективные функции управления ею. В результате вы получаете хорошо спроектированную среду для работы с несколькими аккаунтами, созданную на базе лучших рекомендаций, и различные инструменты для обеспечения безопасности, соответствия требованиям и контроля над рабочими процессами, Ограничения – это правила SCP, RCP и AWS Config, которые обеспечивают управление безопасностью, соответствием требованиям и операционной деятельностью.

AWS Control Tower — это упрощенный и автоматизированный сервис, который регламентирует работу Организаций AWS. Он автоматически устанавливает Организации AWS в качестве основного сервиса AWS для контроля за аккаунтами и реализует превентивные меры и ограничения с помощью политик управления сервисами (SCP) и политик управления ресурсами (RCP). Сервисы Control Tower и Organizations идеально совместимы между собой. Control Tower позволяет настроить среду и установить ограничения, а с помощью AWS Organizations можно создавать настраиваемые правила (например, политики управления сервисами (SCP) или правила относительно применения тегов и резервного копирования), которые централизованно контролируют использование сервисов и ресурсов AWS в нескольких аккаунтах AWS.

Ограничения – это готовые политики управления сервисами и правила AWS Config, которые позволяют управлять безопасностью и рабочим процессом, а также обеспечивать соответствие требованиям. Пользователи могут выбирать и применять их ко всей организации или отдельным группам аккаунтов. Ограничение формулируется на обычном языке и обеспечивает использование определенного правила управления для вашей среды AWS, которое можно включить в рамках организационной единицы (OU).

AWS Control Tower – это идеальный сервис для пользователей, которые хотят создать среду AWS с несколькими аккаунтами или управлять ею с помощью встроенных передовых методов. Он содержит инструкции по управлению средой AWS на всех уровнях и дает контроль над рабочим процессом без снижения скорости и гибкости, которые платформа AWS предоставляет разработчикам. AWS Control Tower можно использовать для реализации различных сценариев: для создания новой среды AWS или проекта в облаке, а также для работы в уже существующей среде AWS с несколькими аккаунтами. Более того, это решение подойдет и для тех, кто только начинает свое знакомство с сервисами AWS.

Организация – это набор аккаунтов AWS, которые можно организовать иерархически и для которых можно использовать централизованные инструменты управления.

Аккаунт AWS – это контейнер ваших ресурсов AWS. Пользователи создают ресурсы AWS и управляют ими на уровне аккаунта AWS, в котором предусмотрены возможности администрирования для обеспечения доступа и управления счетами.

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

Управляющий аккаунт – это аккаунт AWS, используемый для создания организации. С помощью управляющего аккаунта можно создавать новые аккаунты организации, приглашать аккаунты и управлять приглашениями вступить в организацию, а также удалять аккаунты из организации. Можно также назначать политики определенным сущностям, таким как пользователи с административным доступом root, организационные единицы (OU) или аккаунты, принадлежащие к организации. Пользователь с доступом в управляющий аккаунт – это владелец организации, который полностью контролирует политики, связанные с безопасностью, работой инфраструктуры и оплатой счетов. Этот аккаунт является плательщиком и несет ответственность за оплату всех ресурсов, использованных аккаунтами организации. Роль управляющего аккаунта организации нельзя переназначить.

Аккаунт-участник – это аккаунт AWS, входящий в организацию, но не являющийся управляющим аккаунтом. Администратор организации может создавать в ней аккаунты-участники и приглашать существующие аккаунты присоединиться к ней. Он также может применять политики к аккаунтам-участникам. Аккаунт-участник одновременно может принадлежать только к одной организации.

Административный доступ root предоставляется пользователю управляющего аккаунта, с помощью которого он может создавать аккаунты AWS и управлять ими. Пользователь с административным доступом root – это самый верхний элемент в иерархии вашей организации. Имея доступ root, можно создавать OU для логической группировки аккаунтов и организовывать эти OU в иерархическую структуру, наилучшим образом отвечающую практическим потребностям организации.

Организационная единица (OU) – это группа аккаунтов AWS в рамках организации. В OU могут также входить другие OU, что позволяет создавать иерархическую структуру. Например, можно сгруппировать все аккаунты, относящиеся к одному отделу, в OU отдела. Аналогичным образом можно объединить в группу все аккаунты, относящиеся к сервисам безопасности, в OU безопасности. OU удобно использовать тогда, когда требуется применить одни и те же параметры к некому набору аккаунтов организации. Вложенные OU дают возможность создать более мелкие единицы управления. Например, вы можете настроить OU для каждой рабочей нагрузки, а затем внутри этой структуры создать вложенные OU, чтобы распределить рабочие нагрузки на этапах подготовки и запуска. Кроме подчинения непосредственно назначенным политикам, эти OU уровня групп сотрудников наследуют политики от родительских OU.

Политика – это «документ», содержащий одно или более выражений, описывающих директивы, которые требуется применить к группе аккаунтов AWS. Сервис AWS Organizations поддерживает следующие политики.

• Политики резервного копирования. Они позволяют контролировать создание резервных копий с заданной частотой с помощью сервиса AWS Backup.
• Политики использования тегов. Благодаря им можно определять ключи тегов и допустимые значения.
• Политики отказа от использования сервисов с элементами искусственного интеллекта. С их помощью можно контролировать то, как эти сервисы хранят и используют контент.
• Политики управления сервисами (SCPs) позволяют определить, какие операции на уровне сервисов AWS, например RunInstances сервиса Amazon EC2, доступны для тех или иных аккаунтов в пределах организации.

Все сущности организации доступны глобально, аналогично тому, как сейчас работает сервис AWS Identity and Access Management (IAM), за исключением организаций, которыми управляют в Китае. При создании организации и управлении ею регион AWS указывать не требуется. Однако для аккаунтов, используемых в Китае, необходимо создать отдельную организацию. Пользователи ваших аккаунтов AWS могут использовать сервисы AWS в любом географическом регионе, где доступен данный сервис.

Нет. Управляющий аккаунт AWS переназначить нельзя. Поэтому следует тщательно подходить к выбору управляющего аккаунта.

Для добавления аккаунта AWS к организации воспользуйтесь одним из следующих методов.

Метод 1. Приглашение в организацию существующего аккаунта

1. Авторизуйтесь как администратор управляющего аккаунта и перейдите в консоль AWS Organizations.

2. Выберите вкладку «Accounts».

3. Выберите «Add account», затем «Invite account».

4. Укажите адрес электронной почты приглашаемого аккаунта или его идентификатор.

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

Указанные аккаунты AWS получат электронные письма с приглашением присоединиться к организации. Администратор приглашаемого аккаунта AWS должен принять или отклонить запрос с помощью консоли AWS Organizations, интерфейса командной строки AWS или API сервиса AWS Organizations. Если администратор принимает приглашение, аккаунт становится видимым в списке аккаунтов-участников вашей организации. Любые соответствующие политики, такие как SCP, будут автоматически применены к добавленному аккаунту. Например, если в организации есть SCP, назначенная на уровне root организации, она будет применена напрямую ко всем создаваемым аккаунтам.

Метод 2. Создание нового аккаунта AWS в организации

1. Авторизуйтесь как администратор управляющего аккаунта и перейдите в консоль AWS Organizations.

2. Выберите вкладку «Accounts».

3. Выберите «Add account», затем «Create account».

4. Введите имя и адрес электронной почты для нового аккаунта.

Аккаунт можно также создать с помощью AWS SDK или командной строки AWS. При использовании любого из методов добавленный аккаунт можно переместить в организационную единицу (OU). Новый аккаунт автоматически наследует все политики, назначенные на уровне OU.

Нет. Аккаунт AWS может принадлежать только к одной организации.

При создании нового аккаунта AWS сервис AWS Organizations создает роль IAM с полным набором прав администратора для этого аккаунта. Пользователи и роли IAM основного аккаунта, имеющие соответствующие разрешения, могут использовать эту роль IAM для доступа к созданному аккаунту.

Нет. Такая возможность в настоящее время отсутствует.

Да. Однако сначала необходимо удалить аккаунт из организации и сделать его независимым (см. ниже). После этого независимый аккаунт можно пригласить присоединиться к другой организации.

Да. При создании аккаунта в рамках организации с использованием консоли AWS Organizations, API или команд CLI AWS не собирает все данные, необходимые для создания независимого аккаунта. Чтобы сделать аккаунт независимым, необходимо указать контактную информацию, предоставить действительный метод оплаты и выбрать план поддержки AWS. AWS использует предоставленный способ оплаты для взимания средств за любую платную (то есть выходящую за пределы уровня бесплатного пользования AWS) активность аккаунта, не связанного с организацией. Дополнительную информацию см. в разделе Удаление аккаунта-участника из организации.

Возможны различные варианты. Если вам требуются дополнительные аккаунты, перейдите в Центр поддержки AWS и подайте заявку на увеличение лимита.

Аккаунт-участник можно удалить, используя один из описанных далее методов. Чтобы удалить аккаунт, созданный с помощью AWS Organizations, возможно, придется предоставить дополнительную информацию. Если попытка удалить аккаунт не удалась, перейдите в Центр поддержки AWS и обратитесь за помощью в удалении аккаунта.

Метод 1. Удаление аккаунта-участника от имени управляющего аккаунта

1. Авторизуйтесь как администратор основного аккаунта и перейдите в консоль AWS Organizations.

2. На панели слева выберите Аккаунты.

3. Выберите аккаунт, который требуется удалить, и щелкните Удалить аккаунт.

4. Если для аккаунта не указан действительный метод оплаты, его потребуется указать.

Метод 2. Удаление аккаунта-участника от его имени

1. Авторизуйтесь как администратор аккаунта-участника, который требуется удалить из организации.

2. Перейдите в консоль AWS Organizations.

3. Выберите «Покинуть организацию».

4. Если для аккаунта не указан метод оплаты, его потребуется указать.

Чтобы создать OU, выполните следующие действия.

1. Авторизуйтесь как администратор управляющего аккаунта и перейдите в консоль AWS Organizations.

2. Выберите вкладку Систематизировать аккаунты.

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

4. Выберите Создать организационную единицу и укажите имя для OU. Имя должно быть уникальным в пределах организации.

Примечание. Позднее OU можно будет переименовать.

Теперь можно добавлять аккаунты AWS в созданную OU. Для создания OU и управления ими также можно использовать интерфейс командной строки и API AWS.

Для добавление аккаунта-участника в OU выполните следующие действия.

1. В консоли AWS Organizations выберите вкладку «Organize accounts».

2. Выберите аккаунт AWS, затем выберите «Move account».

3. В диалоговом окне выберите OU, в которую требуется переместить выбранный аккаунт AWS.

Кроме того, для добавления аккаунтов AWS в OU можно использовать интерфейс командной строки или API AWS.

Нет. Один аккаунт AWS может принадлежать только к одной OU.

Нет. OU может принадлежать только к одной OU.

Максимальный уровень вложений OU равен пяти. Если считать корневой уровень и аккаунты AWS, созданные в самой нижней OU, в вашей иерархии может быть пять уровней.

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

Назначить политику можно одним из двух способов.

• В консоли организаций AWS выберите объект, которому требуется назначить политику (root, OU или конкретный аккаунт), затем нажмите Назначить политику.
• На консоли организаций AWS перейдите на вкладку Политики и выполните одно из нижеперечисленных действий.
  Выберите существующую политику, затем нажмите на пункт Назначить политику в раскрывающемся списке Действия и выберите root, OU или аккаунт, которым требуется назначить политику.
• Нажмите Создать политику и в процессе создания выберите root, OU или аккаунт, которым требуется назначить новую политику.

Подробнее см. в разделе Управление политиками.

Да. Предположим, аккаунты AWS сгруппированы в несколько OU в соответствии с этапами разработки приложений: DEV, TEST и PROD. Политика P1 назначена на уровне root организации, политика P2 назначена на уровне OU DEV, а политика P3 назначена аккаунту AWS A1, входящему в OU DEV. В этом случае к аккаунту A1 применяются все три политики: P1, P2, и P3.
Подробнее см. в разделе О политиках управления сервисами.

На данный момент сервис AWS Organizations поддерживает следующие политики.

• Политики резервного копирования. Они позволяют контролировать создание резервных копий с заданной частотой с помощью сервиса AWS Backup.
• Политики использования тегов. Благодаря им можно определять ключи тегов и допустимые значения.
• Политики отказа от использования сервисов с элементами искусственного интеллекта. С их помощью можно контролировать то, как эти сервисы хранят и используют контент организации.
• Политики управления сервисами (SCP) позволяют определить и контролировать операции, разрешенные для пользователей, групп и ролей IAM в аккаунтах, где применяются SCP.

Политики управления сервисами (SCP) позволяют определить, какие операции сервисов AWS доступны основным сущностям (таким как аккаунт с правами root, пользователь IAM и роль IAM) в аккаунтах организации. SCP является необходимым, но не единственными средством управления, определяющим, к каким ресурсам могут иметь доступ основные сущности аккаунта. Фактические разрешения для основных сущностей аккаунта, к которому применена SCP, являются пересечением множества разрешений, явно заданных этой политикой, и множества разрешений, явно назначенных данной основной сущности. Например, если примененная к аккаунту SCP допускает только операции сервиса Amazon EC2, а разрешения основной сущности этого же аккаунта AWS допускают операции сервисов EC2 и Amazon S3, то у основной сущности будет доступ только к операциям сервиса EC2.
Кроме того, основные сущности аккаунта-участника (включая пользователя с правами root аккаунта-участника) не могут удалять или изменять примененные к аккаунту SCP.  

SCP следуют тем же правилам и используют тот же синтаксис, что и политики IAM. Дополнительную информацию о синтаксисе SCP см. в разделе Синтаксис SCP. Примеры SCP см. в разделе Примеры политик управления сервисами.  

{ 

 "Version":"2012-10-17", 

 "Statement":[ 

 { 

 "Effect":"Allow", 

 "Action":["EC2:*","S3:*"], 

 "Resource":"*" 

 } 

 ] 

 }

Пример черного списка
Следующая SCP предоставляет доступ ко всем операциям сервисов AWS, кроме операции PutObject сервиса S3. Все основные сущности (аккаунт с правами root, пользователь IAM и роль IAM) с соответствующими, непосредственно им назначенными разрешениями на уровне аккаунта, с применением этой SCP будут иметь доступ к любым операциям, кроме операции PutObject сервиса S3. 

{ 

 "Version":"2012-10-17", 

 "Statement":[ 

 { 

 "Effect":"Allow", 

 "Action": "*:*", 

 "Resource":"*" 

 }, 

 { 

 "Effect":"Deny", 

 "Action":"S3:PutObject", 

 "Resource":"*" 

 } 

 ] 

 }

Другие примеры см. в разделе Стратегии использования SCP.

Нет. SCP действуют точно так же, как и политики IAM, а пустая политика IAM эквивалентна отказу по умолчанию. Применение к аккаунту пустой SCP равнозначно назначению политики, явно запрещающей все операции.

Фактические разрешения для основных сущностей аккаунта (таких как аккаунт с правами root, пользователь IAM и роль IAM) аккаунта AWS, к которому применена SCP, являются пересечением множества разрешений, заданных этой политикой, и множества разрешений, назначенных основным сущностям разрешениями политик IAM. Например, если для пользователя IAM указано "Allow": "ec2:* " и "Allow": "sqs:* ", и в SCP, назначенной аккаунту, указано "Allow": "ec2:* " и "Allow": "s3:* ", результирующее разрешение для пользователя IAM будет "Allow": "ec2:* ". Основная сущность не сможет выполнять никаких операций сервиса Amazon SQS (нет разрешения SCP) или сервиса S3 (не разрешены политикой IAM).

Да, симулятор политик IAM может смоделировать и результат действий SCP. Можно использовать симулятор политик в аккаунте-участнике организации, чтобы увидеть влияние политики на отдельные основные сущности аккаунта. Администратор аккаунта-участника с соответствующими разрешениями AWS Organizations может видеть, влияет ли SCP на доступ основных сущностей (аккаунт root, пользователь IAM и роль IAM) в аккаунте-участнике.
Подробнее см. в разделе Политики управления сервисами.

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

RCP — это политика Организаций AWS, которую можно использовать для определения и применения превентивных средств управления ресурсами AWS в организации. С помощью RCP можно централизованно задавать максимально доступные разрешения для ресурсов AWS по мере масштабирования на AWS рабочих нагрузок. Например, RCP помогает ограничить доступ к ресурсам, чтобы к ним обращались только лица, принадлежащие вашей организации, либо указать условия, при которых внешние лица могут получать доступ к ресурсам.

Примеры RCP см. на страницах документации. Некоторые общие примеры RCP приведены ниже.

• Защита от атак «запутанный заместитель»
• Разрешение только HTTPS-подключений к вашим ресурсам
• Согласованные средства управления политиками в отношении корзин Amazon S3

SCP и RCP независимы друг от друга. Можно включить только SCP или RCP либо использовать оба типа политик вместе. SCP предоставляют максимально доступные разрешения пользователям и ролям IAM в аккаунтах участников. SCP можно использовать, когда необходимо централизованно обеспечивать согласованные средства контроля доступа для доверителей в организации. Это может предусматривать указание того, к каким сервисам AWS или ресурсам могут осуществлять доступ пользователи и роли или при каких условиях они могут отправлять запросы (например, из определенных регионов или сетей). Политики RCP позволяют ограничить максимально доступные разрешения для ресурсов в организации. RCP можно использовать, когда необходимо централизованно обеспечивать согласованные средства контроля доступа к ресурсам в организации. Например, можно ограничить круг лиц, имеющих разрешения на доступ к ресурсам, или ввести требования в отношении способа доступа к ресурсам (например, разрешить доступ только через зашифрованные подключения по протоколу HTTPS). Можно указать средства контроля, которые применяются к ресурсам сервисов AWS, поддерживающих RCP (например, ко всем корзинам S3). 

Дополнительная плата за использование сервиса AWS Organizations не взимается.

За оплату сервисов, ресурсов, а также перемещение и хранение данных в аккаунтах организации, отвечает владелец управляющего аккаунта.

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

Сервисы AWS интегрированы с AWS Organizations для централизованного управления и настройки в разных аккаунтах организации. Это позволяет централизованно управлять сервисами в разных аккаунтах, что упрощает развертывание и конфигурацию.

Полный список сервисов AWS, интегрированных с организациями AWS, см. в разделе Сервисы AWS, которые можно использовать с организациями AWS.

Чтобы начать использовать сервис AWS, интегрированный с AWS Organization, включите интеграцию для этого сервиса в Консоли управления AWS.