Вопросы и ответы по 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 в организации. 

• Политики управления сервисами (SCP) обеспечивают централизованный контроль над максимально доступными разрешениями для пользователей и ролей IAM в организации. 
• Благодаря политике управления ресурсами (RCP) можно обеспечить централизованный контроль над максимально доступными разрешениями для ресурсов в организации. 
• Политики резервного копирования позволяют централизованно управлять ресурсами AWS и применять к ним планы резервного копирования во всех аккаунтах организации.
• Декларативная политика — это политика управления, которая помогает реализовать долгосрочные цели, такие как базовая конфигурация данного сервиса AWS в организации, с помощью нескольких простых действий или команд. После вступления в силу эти политики предотвращают действия, не соответствующие требованиям. Конфигурация, заданная в декларативной политике, сохраняется при внедрении AWS новых API и функций или при внесении изменений в организацию, например при добавлении ресурсов, доверителей и аккаунтов.
• Политики в отношении тегов позволяют стандартизировать теги, прикрепляемые к ресурсам AWS в аккаунтах организации.
• Политики в отношении чат-ботов позволяют контролировать доступ к аккаунтам организации из приложений для чата, таких как Slack и Microsoft Teams.
• Политики отказа от сервисов искусственного интеллекта позволяют контролировать сбор данных сервисами искусственного интеллекта AWS во всех аккаунтах организации.

Все сущности организации доступны глобально, аналогично тому, как сейчас работает сервис 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 Organizations поддерживает следующие политики.

• Политики управления сервисами (SCP) обеспечивают централизованный контроль над максимально доступными разрешениями для пользователей и ролей IAM в организации. 
• Политики управления ресурсами (RCP) обеспечивают централизованный контроль над максимально доступными разрешениями для ресурсов в организации.
• Декларативная политика — это политика управления, которая помогает реализовать долгосрочные цели, такие как базовая конфигурация данного сервиса AWS в организации, с помощью нескольких простых действий или команд. После вступления в силу эти политики предотвращают действия, не соответствующие требованиям. Конфигурация, заданная в декларативной политике, сохраняется при внедрении AWS новых API и функций или при внесении изменений в организацию, например при добавлении ресурсов, доверителей и аккаунтов.
• Политики резервного копирования позволяют централизованно управлять ресурсами AWS и применять к ним планы резервного копирования во всех аккаунтах организации.
• Политики в отношении тегов позволяют стандартизировать теги, прикрепляемые к ресурсам AWS в аккаунтах организации.
• Политики в отношении чат-ботов позволяют контролировать доступ к аккаунтам организации из приложений для чата, таких как Slack и Microsoft Teams.
• Политики отказа от сервисов искусственного интеллекта позволяют контролировать сбор данных сервисами искусственного интеллекта AWS во всех аккаунтах организации.

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

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

SCP следуют тем же правилам и используют тот же синтаксис, что и политики IAM. Дополнительную информацию о синтаксисе SCP см. в разделе Синтаксис SCP. Примеры 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 может помочь ограничить доступ к вашим ресурсам, чтобы к ним могли обращаться только лица, принадлежащие вашей организации, или указать условия, при которых внешние идентификаторы могут получать доступ к вашим ресурсам.

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

Политики управления сервисами (SCP) обеспечивают централизованный контроль над максимально доступными разрешениями для пользователей и ролей IAM в организации. Декларативные политики упрощают задание конфигурации и позволяют конечным пользователям понять, почему их действия не принесли результатов, благодаря настраиваемым сообщениям об ошибках. Если вы используете декларативные политики, вам не нужно обновлять SCP, применяя новые API, для защиты целевой конфигурации. Заданная декларативная политика обеспечивает поддержку конфигурации. Если у вас есть политики SCP для компонента управления, поддерживаемого декларативными политиками, добавление их в декларативную политику послужит дополнительным уровнем защиты для обеспечения требуемой конфигурации. Вы можете продолжать использовать правила обнаружения AWS Config для постоянного мониторинга изменений в среде и проактивные правила AWS Config для предотвращения создания ресурсов, не соответствующих требованиям, с помощью CloudFormation.

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

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

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

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

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

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

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

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