Всем, кто работал с AWS хорошо известно о существовании аккаунтов – учетные записи, в которых, собственно, и происходит работа – выделение ресурсов, разграничение прав доступа и так далее. Часто возникает необходимость создания нескольких аккаунтов – будь то отдельные аккаунты для различных отделов компании или отдельные аккаунты под проекты или даже под различные среды одного проекта (разработка, тестирование, эксплуатация). Для управления аккаунтами в AWS есть сервис AWS Organizations, который позволяет создавать новые аккаунты, распределять ресурсы, оптимизировать оплату счетов посредством настройки единого метода оплаты для всех аккаунтов, создавать группы аккаунтов и применять к ним политики, чтобы эффективно управлять рабочими процессами.

Однако для управления аккаунтами одного сервиса AWS Organizations недостаточно. Есть желание не просто создавать аккаунты, но создавать их так, чтобы они удовлетворяли принятым в компании нормам и политикам, иметь возможность отслеживать состояние созданных аккаунтов, управлять политиками, не редактируя JSON документ, а более удобным способом. Также в случае роста количества аккаунтов в организации понимание того, что возможностей сервиса AWS Organizations не хватает приходит достаточно быстро. И вот тем, кто вступил на этот путь есть два варианта – или использовать инструмент от AWS – Control Tower или разработать собственные скрипты управления. Дальше в статье рассказывается почему мы выбрали второй вариант.

Что такое AWS Control Tower?

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

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

К основным возможностям сервиса стоит отнести

• Автоматическое создание и управление Landing Zone. В несколько кликов вы получаете защищенную AWS Organization с настроенной системой мониторинга и нотификаций, SSO для управления пользователями с предустановленным набором политик и ролей и возможность расширения организации до нужных пределов;
• Ограничения. Предопределенный набор политик и правил, которые можно применять к конкретным аккаунтам или группе аккаунтов;
• Account Factory.Конфигурируемые шаблоны для создания аккаунтов, которые помогают стандартизировать процесс создания сетевой инфраструктуры аккаунтов – задавать настройки VPC, подсетей и т. д.;
• Панель управления. Информация обо всех аккаунтах в организации и созданных ограничениях. Тут можно управлять ограничениями – добавлять новые, применять ограничения на аккаунт или группу аккаунтов и также видеть, насколько тот или иной аккаунт соответствует выставленным ограничениям.

Как это работает?

Для начала работы нужно иметь AWS аккаунт и пользователя с правами администратора. Этот аккаунт будет в дальнейшем использован как мастер-аккаунт при создании AWS организации. Также следует упомянуть, что AWS Control Tower поддерживается не во всех регионах, например в США не поддерживается регион Калифорния, в Европе – Милан и Париж, а в Азии из семи доступных регионов поддерживаются только два – Сингапур и Сидней (информация на момент написания статьи).

В основе работы сервиса лежит набор AWS CloudFormation шаблонов, при помощи которых создается landing zone со следующими ресурсам:

• три группы аккаунтов (organisation unit) — Root, Core и Custom;
• два аккаунта в Сore organisation unit — log archive аккаунт для хранения всех логов организации и audit аккаунт для аудита;
• AWS SSO в мастер-аккаунте с предопределенными группами с правами доступа;
• 20 предупредительных ограничений и 6 детективных ограничений. Ограничения применяются на уровне всей организации, за исключением мастер-аккаунта. Для обеспечения работы ограничений в каждом аккаунте поднимается AWS CloudTrail, создается система мониторинга логов и система нотификаций для случаев обнаружения проблем.

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

Так же интеграция с некоторыми сервисами AWS для облегчения процесса создания и управления аккаунтами в организации. Например, интеграция с AWS Firewall Manager дает возможность создания дополнительных политик, действующих на уровне организации, а интеграция с AWS Service Catalog облегчает создания аккаунтов с предварительно заданными свойствами и набором ресурсов.

Преимущества использования

Быстро, просто и безопасно. Создать полноценную организацию можно быстро, сделав несколько кликов в консоле управления. На выходе получаем организацию, которая соответствует рекомендованным стандартам безопасности и систему нотификации о состоянии организации. Все действия по созданию и настройке ресурсов организации спрятаны от пользователя, а их действительно довольно много. Процедура по управлению организацией тоже достаточно упрощена, не нужно думать какую политику прописать какому сервису, чтобы он работал как задумано. Также набор существующих ограничений довольно сильно облегчает жизнь, сводя настройку организации к выбору ограничений из списка, что значительно быстрее собственной разработки.

Почему мы не используем AWS Control Tower?

Одной из основных причин почему AWS Control Tower не был нами использован является отсутствие интеграции сервиса с Terraform, который был принят как de facto стандарт для работы с облачными провайдерами. Возможно, в будущем эта интеграция появится и можно будет пересмотреть решение. И дело даже не в создании самой организации с использованием Terraform, можно было сначала создать организацию в консоле, а потом наполнять ее ресурсами через Terraform. Но хотелось в дальнейшем управлять созданными ресурсами – менять политики, иметь доступ к созданным ресурсам таким как VPC, Security groups, SNS Topics для их дальнейшей настройки и расширения.

Второй причиной было наличие уже существующей организации с набором аккаунтов и какой-то определенной логикой работы. Скажу сразу, что AWS Control Tower позволяет перенести текущую организацию под свое управление. Однако выяснились некоторые моменты, которые являлись не то, чтобы останавливающими, но вызывающими некоторое беспокойство. А именно:

• Наличие существующих SCP политик в организации. Интегрировать их в имеющийся у AWS Control Tower список SCP политик на данный момент невозможно. Но есть возможность сделать дополнительную политику и отдельно навесить ее на аккаунт или группу аккаунтов. Но тут получается управление разделяется на два места и есть возможность упереться в квоты на количество SCP политик, которые достаточно небольшие — сейчас это пять политик аккаунт или группу аккаунтов. Учитывая, что AWS Control Tower создает три для существующих политик оставалось не так много.
• Наличие существующего SSO в мастер-аккаунте. Интеграция его в AWS Control Tower вызывала некоторые сомнения, а рисковать не хотелось. Пользователи были уже заведены, права назначены – очень не хотелось бы все это разломать по неосторожности;

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

Третьей причиной было желание кастомизировать вышеупомянутые AWS Control Tower ограничения. Во-первых, расширять список политик, например запрет на удаление/модификацию определенных ресурсов (определенные роли, связанные с управлением аккаунта или критическими ресурсами). Во-вторых, использовать роли на уровне одного конкретного аккаунта, а не группы аккаунтов, как это сейчас реализовано в AWS Control Tower. Ну и в-третьих, управлять этим всем на лету, например на какое-то время отключать у конкретного аккаунта определенный набор ограничений, потом подключать назад.

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

Заключение

AWS Control Tower или собственные скрипты, готовый продукт или кастомная разработка. Как всегда, готовый продукт дает скорость в реализации решения, снижение затрат на разработку и исправление ошибок, но взамен мы теряем в гибкости.

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

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