Создание рекомендованной среды AWS

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

• Быстрое внедрение инноваций с различными требованиями. Аккаунты AWS можно распределять между различными командами, проектами или продуктами в пределах компании, обеспечивая высокую скорость внедрения инноваций с учетом конкретных требований к безопасности.
• Упрощенная оплата. Распределение затрат при использовании нескольких аккаунтов AWS становится легче, так как можно определить, к какому продукту или сервису относится тот или иной платеж AWS.
• Гибкие средства контроля безопасности. Несколько аккаунтов AWS можно использовать для изоляции рабочих нагрузок или приложений, которым необходимо соблюдение особых требований к безопасности или соответствие строгим нормам, таким как HIPAA или PCI.
• Легкая адаптация к бизнес-процессам. Организацию нескольких аккаунтов AWS можно выстроить в соответствии с потребностями бизнес-процессов компании, соблюдая различные операционные, нормативные и бюджетные требования.

В конечном счете среда AWS с несколькими аккаунтами обеспечивает более быструю работу в облаке и помогает создавать разнообразные продукты и услуги, при этом гарантируя надежность, масштабируемость и устойчивость. Но как создать собственную среду AWS с несколькими аккаунтами? У вас могут появиться вопросы о том, какую структуру аккаунтов использовать, какие политики и ограничения следует внедрить или как подготовить среду для аудита.

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

Основой хорошо продуманной среды AWS с несколькими аккаунтами выступает AWS Organizations, сервис AWS, который позволяет централизованно контролировать и управлять несколькими аккаунтами. Для начала познакомимся с несколькими терминами. Организационная единица (OU) – это логическая группа аккаунтов в AWS Organization. OU позволяет выстроить иерархию аккаунтов и упрощает применение средств управления. Политики AWS Organizations – инструменты, с помощью которых применяются средства управления. Политика управления сервисами (SCP) – это политика, которая определяет действия сервиса AWS, например запуск инстанса Amazon EC2, доступные аккаунтам организации.

Во-первых, подумайте, какие группы аккаунтов или OU вам необходимо создать. Организационные единицы стоит сформировать исходя из функций или общего набора средств управления, а не в соответствии с отчетной структурой компании. AWS рекомендует начинать с систем безопасности и инфраструктуры. В большинстве компаний данные вопросы курирует одна команда для всей организации. То есть мы рекомендуем создать набор базовых OU для следующих конкретных функций:

• Инфраструктура: используется для общих сервисов инфраструктуры, таких как сетевые и ИТ-услуги. Создайте отдельный аккаунт для каждого необходимого типа сервиса инфраструктуры.
• Безопасность: используется для сервисов безопасности. Создайте аккаунты для архивов журналов, безопасного доступа только для чтения, инструментов безопасности и защиты от взлома.

Учитывая, что требования к политике производственных рабочих нагрузок у большинства компаний отличаются, инфраструктура и безопасность могут иметь внутреннее разделение на непроизводственные (SDLC) и производственные (Prod) OU. В OU SDLC аккаунты размещают непроизводственные рабочие нагрузки и, следовательно, не должны иметь производственных зависимостей с другими аккаунтами. Если политики организационных единиц отличаются в зависимости от этапов жизненного цикла, то SDLC можно разделить на несколько OU (например, dev и pre-prod). Аккаунты в производственном OU содержат производственные рабочие нагрузки.

Применяйте политики на уровне организационной единицы, чтобы управлять средой Prod и SDLC в соответствии с собственными требованиями. В целом лучше применять политики на уровне организационной единицы, чем на уровне отдельно аккаунта, так как в таком случае ими легче управлять и проще устранять возможные неполадки.

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

• Изолированная среда: содержит аккаунты AWS, которые отдельные разработчики могут использовать для экспериментов с сервисами AWS. Убедитесь, что эти аккаунты можно отключить от внутренних сетей, и настройте возможность ограничения расходов, чтобы предотвратить чрезмерное использование.
• Рабочие нагрузки: cреда для аккаунтов AWS, в которых размещаются сервисы приложений с внешним доступом. Для изоляции и строгого контроля производственных рабочих нагрузок необходимо структурировать OU в средах SDLC и Prod (аналогично базовым единицам).
  

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

• Промежуточная среда для политик: содержит аккаунты AWS, в которых предлагаемые изменения политики тестируются перед применением в масштабе всей организации. Начните с внесения изменений на уровне аккаунта в конкретном OU и постепенно переходите к другим аккаунтам, OU и остальной организации.
• Приостановленная среда: здесь находятся аккаунты AWS, которые были закрыты и ожидают удаления из организации. К этой организационной единице можно прикрепить SCP, запрещающие любые действия. Убедитесь, что аккаунтам присвоены подробные теги, чтобы при необходимости их можно было найти и восстановить.
• Отдельные бизнес-пользователи: организационная единица с ограниченным доступом для аккаунтов AWS бизнес-пользователей (не разработчиков), которым может потребоваться создание приложений, связанных с бизнес-процессами, например настройка корзины S3 для обмена отчетами или файлами с партнером.
• Исключения: здесь находятся используемые в бизнес-сценариях аккаунты AWS, требования к безопасности или аудиту которых крайне индивидуальны и отличаются от требований в OU рабочих нагрузок. Например, можно создать аккаунт AWS специально для нового конфиденциального приложения или функции. Для соблюдения индивидуальных требований используются SCP на уровне аккаунта. Можно настроить систему обнаружения и реагирования с помощью CloudWatch Events и правил AWS Config.
• Развертывания: OU с аккаунтами AWS, предназначенными для развертываний непрерывной интеграции и непрерывной доставки (CI/CD). Эту единицу можно создать, если модель управления и эксплуатации для развертываний CI/CD отличается от принципов работы с аккаунтами в OU рабочих нагрузок (Prod и SDLC). Расширение CI/CD помогает снизить зависимость организации от общей среды CI/CD под управлением главной команды. Создавайте аккаунт для CI/CD в OU развертываний на каждую группу аккаунтов AWS SDLC/Prod для приложения в OU рабочих нагрузок.
  
• Переходная среда: используется в качестве временного места хранения существующих аккаунтов и рабочих нагрузок перед их перемещением в стандартные области организации. Это может происходить, если аккаунты ранее принадлежали третьей стороне или остались от старой организационной структуры. 
  

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

Для начала ознакомьтесь с Руководством по началу работы AWS Organizations, чтобы создать собственную среду AWS с несколькими аккаунтами. Кроме того, можно использовать сервис AWS Control Tower, который поможет быстро настроить безопасную исходную среду AWS.