При настройке инфраструктуры AWS вам необходимо решить, в каких аккаунтах будут размещаться ваши приложения, конвейеры развертывания и общие службы. AWS Organizations позволяет организовывать рабочие нагрузки и общие службы в дочерние аккаунты на основе их владельцев, назначения и требований к изоляции. Отдельный управляющий аккаунт отвечает за консолидированную выставление счетов и администрирование организации. Однако настройка отдельных аккаунтов и конфигурация доступа между ними требует планирования, поэтому запуск рабочих нагрузок в управляющем аккаунте может показаться более простым способом начать работу.
В нашем отчете о состоянии безопасности в облаке за 2026 год мы выяснили, что 14% проанализированных организаций запускают экземпляры Amazon Elastic Compute Cloud (Amazon EC2) в своем управляющем аккаунте по сравнению с 9% в 2025 году. Разделение рабочих нагрузок и административных обязанностей помогает снизить риск того, что скомпрометированное приложение предоставит учетные данные, которые злоумышленник сможет использовать для администрирования других аккаунтов. В этой статье мы объясним, почему размещение аккаунтов влияет на безопасность, где следует размещать рабочие нагрузки и общие службы, а также какие разрешения необходимо проверить при настройке или реорганизации аккаунтов.
Понимание рисков запуска рабочих нагрузок в управляющем аккаунте
В дочерних аккаунтах вы можете использовать политики организации для ограничения доступа, который в противном случае разрешали бы политики AWS Identity and Access Management (IAM). Например, service control policies (SCPs) limit what users and roles can do, while resource control policies (RCPs) limit access to resources. Но эти дополнительные ограничения не применяются в управляющем аккаунте, хотя политики IAM по-прежнему регулируют доступ в нем. Это одна из причин, почему AWS рекомендует хранить рабочие нагрузки в дочерних аккаунтах и оставлять управляющий аккаунт для других задач в масштабах всей организации, таких как выставление счетов.
Скомпрометированная рабочая нагрузка в управляющем аккаунте также может предоставить злоумышленнику доступ к дочерним аккаунтам, если ее учетные данные позволяют принимать там роли. Например, AWS Organizations обычно создает административную роль с именем OrganizationAccountAccessRole в аккаунтах, создаваемых через этот сервис. Эта роль доверяет управляющему аккаунту, поэтому злоумышленник, получивший учетные данные с правом принимать ее, может получить административный доступ к дочернему аккаунту с учетом ограничений этого аккаунта. Специалисты AWS также фиксировали случаи, когда злоумышленники использовали привилегии управляющего аккаунта для вызова sts:AssumeRoot, что предоставляет краткосрочные сеансы для конкретных привилегированных задач в дочерних аккаунтах, где включены сеансы учетной записи root.
Когда инструменты развертывания или общие службы нуждаются в доступе к нескольким аккаунтам, вам необходимо предоставить этот доступ, не перенося повседневную работу в управляющий аккаунт. Вам следует зарезервировать этот аккаунт для консолидированного выставления счетов и задач, требующих этого, таких как регистрация делегированных администраторов. Вы можете использовать делегированное администрирование, чтобы позволить командам управлять своими службами из дочерних аккаунтов в соответствии с их обязанностями. Например, команда безопасности может администрировать Amazon GuardDuty из аккаунта инструментов безопасности, в то время как команда платформы управляет общими службами из отдельного аккаунта.
Аккаунты рабочих нагрузок должны отражать то, кто владеет приложениями, чем они занимаются и какие рабочие нагрузки или данные должны оставаться изолированными. Например, вам также следует keep production and development workloads in separate accounts, чтобы применять различные элементы управления доступом и сетевые средства к каждой среде. В следующей таблице используются рекомендации AWS по организации аккаунтов, которые помогут вам выбрать, где запускать рабочие нагрузки и общие службы:
Принудительное соблюдение границ доступа между аккаунтами
Рабочая нагрузка в дочернем аккаунте все еще может иметь ненужный доступ к другим аккаунтам через роли, которые ей разрешено принимать. Политики IAM предоставляют этот доступ, а SCP устанавливают ограничения разрешений для пользователей и ролей в дочерних аккаунтах, включая аккаунты, которые служат делегированными администраторами. Если в вашей организации включены все функции, вы можете применять SCP к отдельным аккаунтам или прикреплять их к организационным единицам (OU) для обеспечения одинаковых ограничений для аккаунтов со схожими требованиями к безопасности.
Например, конвейер развертывания может выполняться под ролью IAM в выделенном дочернем аккаунте развертывания и принимать роли в аккаунтах рабочих нагрузок для развертывания приложений. Вам следует ограничить разрешения sts:AssumeRole для роли конвейера целевыми ролями, которые ей необходимы. Политика доверия каждой целевой роли должна ограничивать доступ к тем сущностям, которым необходимо ее принимать, а ее разрешения должны охватывать только те задачи развертывания, которые необходимо выполнять конвейеру.
Вы можете усилить эти ограничения IAM, прикрепив SCP к тому же аккаунту развертывания. SCP может запрещать sts:AssumeRole для каждой целевой роли, за исключением тех, которые находятся в утвержденном списке, указанном вами путем включения их имен Amazon Resource Names (ARN) в элемент NotResource политики. Это ограничение мешает ролям конвейера аккаунта принимать неутвержденные роли, даже если кто-то позже предоставит им более широкие разрешения IAM.
Если ваш конвейер использует инструменты автоматизации, такие как GitHub Actions, для аутентификации в AWS, вам также следует ограничить то, какие рабочие процессы могут принимать его исходную роль IAM. Исследование Datadog Security Labs, посвященное недостаткам аутентификации GitHub в AWS, показывает, как излишне широкие политики доверия могут позволить недоверенным рабочим процессам получать учетные данные AWS.
Прежде чем широко применять SCP, вам следует протестировать его на небольшом наборе аккаунтов в тестовой OU. Тестовый аккаунт позволяет проверить, что необходимые развертывания по-прежнему успешны, а попытки принять неутвержденные роли терпят неудачу. Это также помогает убедиться, что администраторы и другие рабочие нагрузки в аккаунте развертывания по-прежнему могут принимать необходимые им роли. Наше руководство по ошибкам конфигурации периметра данных AWS содержит дополнительные примеры тестирования SCP, блокирующих изменения AWS CloudTrail и доступ к корзинам Amazon S3 за пределами вашей организации.
Храните администрирование организации отдельно от рабочих нагрузок
По мере того как ваша команда добавляет или перемещает рабочие нагрузки, вам следует проверять, в каких аккаунтах они будут выполняться, какие роли они могут принимать и какие политики организации применяются. Вы можете использовать SCP для обеспечения соблюдения ограничений в дочерних аккаунтах, а политики IAM — для предоставления только того доступа, который необходим каждой рабочей нагрузке. При каждом изменении этого доступа следует проверять, что необходимые задачи по-прежнему выполняются успешно, а попытки принять неутвержденные роли терпят неудачу.
Дополнительные рекомендации по мониторингу развертываемых рабочих нагрузок см. в наших руководствах по мониторингу функций AWS Lambda, рабочих нагрузок AWS Fargate и кластеров Amazon Elastic Kubernetes Service (Amazon EKS). Вы также можете узнать, как отслеживать логи CloudTrail, обнаруживать несанкционированный сторонний доступ к AWS и отслеживать AWS WAF для расширения видимости вашей среды и возможных векторов атак.
Если у вас еще нет аккаунта Datadog, зарегистрируйтесь для получения 14-дневной бесплатной пробной версии, чтобы начать мониторинг вашей среды AWS.
