Amazon DOP-C02: Безопасность, соответствие требованиям и управление — Руководство по подготовке

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Часть AWS DevOps Engineer Professional DOP-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Обзор

Безопасность, соответствие требованиям и управление в AWS основаны на детерминированных средствах контроля, которые масштабируются на все аккаунты и регионы, не замедляя разработку. Надежная архитектура включает несколько уровней: контроль удостоверений (IAM, границы разрешений и политики управления сервисами), управление несколькими аккаунтами (AWS Organizations и Control Tower), непрерывная оценка и исправление (AWS Config), обнаружение угроз (Security Hub, GuardDuty, Inspector), гигиена секретов, шифрование с помощью AWS KMS и сетевая изоляция (группы безопасности VPC, NACL, эндпоинты и PrivateLink). Цель — минимизировать радиус поражения, постоянно подтверждать соответствие требованиям и автоматизировать предотвращение и исправление, сохраняя при этом принцип минимальных привилегий и автономность разработчиков.

Удостоверения, политики и управление несколькими аккаунтами

Роли IAM, политики, границы разрешений и SCP совместно формируют эффективный набор разрешений. Политики на основе удостоверений для роли IAM определяют разрешенные действия; политика доверия роли определяет, кто может ее принять. Границы разрешений ограничивают то, что может делать субъект, независимо от содержания политик на основе удостоверений. SCP в AWS Organizations устанавливают абсолютный максимум разрешений для любого субъекта в дочернем аккаунте (включая root-пользователя). Политики на основе ресурсов (для S3, KMS, Secrets Manager и т. д.) могут разрешать межсетевой доступ, но они также не могут выходить за рамки, установленные SCP или границами разрешений. Эффективное разрешение — это пересечение: политики на основе удостоверений ∩ граница разрешений ∩ политики сессии (если есть) ∩ политика ресурса (если применимо) ∩ SCP, при этом любой явный запрет (Deny) имеет приоритет.

Используйте границы разрешений для безопасного самообслуживания в рамках одного аккаунта. Например, конвейер для предоставления ресурсов может создавать роли только в том случае, если он прикрепляет границу, которая запрещает iam:PassRole за исключением определенных шаблонов, запрещает kms:Decrypt для конфиденциальных ключей и ограничивает типы инстансов EC2. Границы могут прикрепляться только субъектами, у которых уже есть разрешение iam:PutRolePermissionsBoundary; тщательно охраняйте это право.

SCP — это защитные барьеры в масштабе всей организации. Распространенные защитные барьеры включают запрет на отключение AWS Config или CloudTrail, предотвращение приглашений извне организации, запрет на изменение делегированного администратора IAM Identity Center и ограничение доступных регионов. Чтобы минимизировать трения, предпочитайте шаблоны явного разрешения по исключению с условиями (например, разрешая изменения центральной административной роли). Всегда разрешайте создание и использование необходимых сервисных ролей (service-linked roles), например, для GuardDuty, Inspector, Config, иначе ваши SCP будут непреднамеренно блокировать настройку сервисов.

AWS Organizations предоставляет иерархические OU для разделения сред (например, Sandbox, Dev, Prod), типов рабочих нагрузок и путей для исключений. Наследуйте SCP от родительских OU, чтобы избежать расхождения политик. Используйте автоматизированное создание аккаунтов для стандартизации их настройки: Account Factory в AWS Control Tower (консоль) или Account Factory for Terraform (AFT) для интеграции в CI/CD. AFT добавляет рабочие процессы в стиле GitOps, обнаружение расхождений и функциональные флаги (например, для подключения Enterprise Support) и масштабируется до сотен аккаунтов с единообразными базовыми защитными барьерами.

AWS Control Tower автоматизирует создание целевой зоны (landing zone) с предписывающими защитными барьерами. Превентивные защитные барьеры — это SCP, которыми управляет Control Tower; обнаруживающие защитные барьеры — это правила AWS Config, которые он развертывает. Control Tower интегрируется с IAM Identity Center для SSO и наборов разрешений. Используйте наборы разрешений на основе ABAC с атрибутами для контроля доступа, чтобы ограничить действия по тегу aws:PrincipalTag или атрибутам удостоверения. Расширяйте базовую конфигурацию с помощью Customizations for AWS Control Tower (CfCT) для автоматического развертывания CloudFormation, SCP и пакетов Config для каждого OU/аккаунта. Держите OU для исключений, чтобы размещать рабочие нагрузки, требующие индивидуальных политик, не ослабляя глобальные защитные барьеры.

Непрерывное соответствие требованиям и автоматизированное исправление

Включите AWS Config в масштабе всей организации из аккаунта делегированного администратора. Включите запись для всех ресурсов во всех регионах и агрегируйте конфигурации со всей организации с помощью агрегатора организации. Используйте управляемые правила для общих проверок (например, ebs-encryption-by-default, restricted-ssh, s3-bucket-level-public-access-prohibited) и создавайте собственные правила на основе Lambda для специфической логики (например, проверка периодичности ротации ключей KMS на соответствие 90-дневной политике или принудительное использование тегов и значений по умолчанию). Пакеты соответствия (conformance packs) группируют правила, параметры и исправления в версионируемые, развертываемые пакеты для каждого OU; храните их в системе контроля версий и развертывайте через StackSets или CfCT для обеспечения согласованности и аудита.

Автоматизированное исправление замыкает цикл. Сопоставьте каждую оценку несоответствия от правила со сборником сценариев (runbook) SSM Automation, который приводит ресурс в соответствие с базовой конфигурацией: прикрепляет профиль инстанса по умолчанию, применяет тег со значением по умолчанию, включает S3 Block Public Access или перезапускает инстанс EC2 для обслуживания. Используйте параметризованные документы и динамические входные данные (например, из результатов Config), чтобы сборники сценариев оставались универсальными. Для ресурсов с высоким риском настройте автоматическое выполнение исправления; для чувствительных действий требуйте подтверждения изменений или ручного запуска через EventBridge и ChatOps. Защитите сам Config с помощью SCP, которые запрещают остановку рекордера или удаление каналов доставки всем, кроме центрального администратора.

Firewall Manager дополняет этот уровень, реализуя модель «политика как услуга» (policy-as-a-service) для всех аккаунтов с использованием Organizations. Делегируйте центрального администратора и создавайте политики для ассоциации web ACL WAF с интернет-ориентированными ALB/API Gateway, аудита и очистки групп безопасности VPC или распространения правил DNS Firewall. Это смещает будущий контроль с обнаружения/исправления на предотвращение.

Обнаружение угроз, гигиена секретов и управление уязвимостями

Security Hub служит единым окном для просмотра результатов проверок из разных аккаунтов и регионов. Включите его с делегированным администратором, агрегируйте результаты проверок и активируйте соответствующие стандарты (AWS Foundational Security Best Practices, CIS, PCI DSS, где это применимо). Результаты проверок поступают в формате AWS Security Finding Format (ASFF), нормализуя данные от GuardDuty, Inspector, IAM Access Analyzer, Config, Macie и партнёрских инструментов. Настройте шаблоны EventBridge для маршрутизации критически важных результатов проверок в автоматизированные сценарии исправления (SSM Automation, Lambda) и для отправки уведомлений (SNS, чат).

GuardDuty обеспечивает управляемое обнаружение угроз, не требуя от вас управления конвейерами логов на уровне данных. Он анализирует события управления и данных CloudTrail, VPC Flow Logs, журналы DNS-запросов Route 53 Resolver и журналы аудита EKS для выявления аномального поведения, утечки учётных данных, криптомайнинга, DNS-эксфильтрации и многого другого. Включите Malware Protection для сканирования S3 и EC2/EBS при подозрительной активности. Используйте автоматическое включение в масштабе организации и систематически архивируйте малозначимые результаты с помощью правил подавления, чтобы сосредоточиться на практически значимых результатах.

Amazon Inspector непрерывно оценивает EC2 (через SSM agent) на наличие CVE в пакетах, образы контейнеров в ECR на наличие уязвимостей перед развёртыванием и функции Lambda на наличие CVE в пакетах кода. Для работы Inspector требуется, чтобы на инстансах EC2 был установлен SSM Agent, профиль инстанса предоставлял разрешения для SSM, а также был разрешён исходящий трафик к эндпоинтам SSM/KMS (через VPC endpoints, если доступ в интернет ограничен). Настройте Inspector для отправки результатов проверок в Security Hub и запуска процессов установки исправлений с помощью Systems Manager Patch Manager или исправления на основе runbook-сценариев. Используйте теги для определения, какие ресурсы подлежат сканированию, и для отделения песочницы от сред с нормативными требованиями.

Secrets Manager централизует хранение, ротацию и межсетевой доступ к секретам с надёжными возможностями аудита. Для учётных данных, требующих ротации, отдавайте предпочтение Secrets Manager перед Parameter Store, используя встроенную ротацию для RDS/Aurora или ротацию на основе Lambda для внешних систем. Метки версий (AWSCURRENT, AWSPREVIOUS) обеспечивают ротацию без простоя. Запускайте Lambda-функции для ротации в VPC с необходимыми эндпоинтами (Secrets Manager, RDS, KMS) и ограничивайте исходящий трафик. Для использования секрета из другого аккаунта прикрепите ресурсную политику, которая предоставляет субъектам (principals) в других аккаунтах право на действие GetSecretValue; убедитесь, что политика ключа KMS для CMK секрета позволяет субъектам-потребителям выполнять расшифровку и, при необходимости, создавать гранты (grants). Для аварийного восстановления или контроля местоположения данных реплицируйте секреты между регионами и согласуйте окна ротации.

Защита данных и сетевая безопасность

Проектируйте шифрование с помощью KMS с явными политиками ключей. Именно политики ключей, а не только политики IAM, в конечном счете авторизуют субъектов для выполнения криптографических операций с CMK. Применяйте модель политики ключа на основе ролей с минимальными привилегиями: делегируйте администрирование центральной роли администратора KMS; предоставляйте права на использование узкоспециализированным ролям рабочих нагрузок; запрещайте использование wildcard kms:*, чтобы избежать случайной эскалации привилегий. Используйте ключи условий (kms:EncryptionContext:*), чтобы привязать расшифровку к ожидаемым контекстам. Мультирегиональные ключи позволяют реализовать шифрование в режиме active-active, когда данные реплицируются между регионами.

Разрешения (grants) — это подходящий инструмент для делегирования временного или строго ограниченного использования ключей без редактирования политики ключа. Они необходимы для некоторых сценариев работы сервисов (например, EC2 Auto Scaling с использованием зашифрованных шаблонов запуска, использование AMI в другом аккаунте). Чтобы разрешить другому аккаунту создавать разрешения (grants), политика ключа должна разрешать kms:CreateGrant для субъектов этого аккаунта; получатель разрешения должен предоставить токен разрешения (grant token) для немедленного использования в том же пути вызова. Для использования зашифрованных AMI в разных аккаунтах скопируйте и зашифруйте AMI с помощью CMK, предоставьте доступ к AMI, разрешите целевому аккаунту создавать разрешения (grants) для CMK и сделайте так, чтобы роль, связанная с сервисом, в целевом аккаунте получила разрешение (grant).

Конвертное шифрование — это стандартный паттерн: сгенерируйте ключ данных с помощью KMS, зашифруйте данные локально с помощью открытого текста ключа данных, а затем храните только шифротекст и зашифрованный ключ данных. При чтении вызовите KMS Decrypt, чтобы восстановить открытый текст ключа данных в памяти. Это минимизирует количество вызовов KMS для больших объемов данных и ограничивает раскрытие ключа в виде открытого текста. Где это поддерживается, используйте управляемое сервисом шифрование SSE-KMS (S3, EBS, RDS) для простоты эксплуатации, но все равно согласуйте политики ключей для производителей/потребителей в разных аккаунтах.

Безопасность VPC начинается с групп безопасности с минимальными привилегиями. Группы безопасности работают с отслеживанием состояния (stateful); обратный трафик подразумевается разрешенным. Предпочитайте ссылки на группы безопасности правилам на основе CIDR, чтобы избежать хрупких списков разрешенных IP-адресов и сохранить намерение в коде инфраструктуры. Разрешение исходящего трафика по умолчанию рискованно; явно ограничивайте исходящий трафик до необходимых назначений и используйте конечные точки VPC для доступа к сервисам AWS. NACL работают без отслеживания состояния (stateless) и оцениваются первыми; используйте их как грубые элементы контроля на уровне подсети с явным разрешением обратного трафика для эфемерных портов только тогда, когда вам необходимо реализовать дополнительный барьер или соответствовать нормативным требованиям; в остальных случаях отдавайте предпочтение группам безопасности для удобства управления.

Устраните зависимости от интернета с помощью конечных точек VPC. Шлюзовые конечные точки (Gateway endpoints) для S3 и DynamoDB направляют трафик приватно через сеть AWS; привяжите политику конечной точки, чтобы ограничить доступ к бакетам или таблицам. Интерфейсные конечные точки (Interface endpoints) (AWS PrivateLink) предоставляют доступ к сервисам AWS (Secrets Manager, KMS, SSM, ECR, CloudWatch) через частные IP-адреса; развертывайте их в подсетях с правильными группами безопасности и включайте Private DNS, чтобы стандартные имена сервисов разрешались в частные адреса. Для микросервисов типа «производитель-потребитель» в разных аккаунтах/VPC публикуйте сервис конечной точки на базе NLB и позволяйте потребителям создавать к нему интерфейсные конечные точки через PrivateLink, избегая пиринга или транзитных шлюзов и сохраняя трафик вне публичного интернета. Сочетайте эти элементы контроля с подсетями без NAT и IGW и централизованной инспекцией исходящего трафика там, где доступ в интернет необходим.

Практический сценарий

Expedia Group расширяется до сотен аккаунтов AWS в нескольких регионах и должна обеспечить строгий базовый уровень безопасности: отсутствие исходящего интернет-трафика для рабочих нагрузок, автоматическое исправление неверных конфигураций, централизованное обнаружение угроз, ротация секретов и контролируемый обмен зашифрованными AMI между аккаунтами для стандартизированных «золотых» образов.

Установить управление несколькими аккаунтами с помощью AWS Organizations и AWS Control Tower

Действие: Создать OU для Sandbox, Dev, Prod и Security. Развернуть Control Tower для создания посадочной зоны (landing zone), включения обязательных ограждений (guardrails) и интеграции IAM Identity Center. Использовать Account Factory for Terraform (AFT) для предоставления аккаунтов через GitOps.
Почему: Control Tower предоставляет готовые, постоянно действующие ограждения (SCP и правила Config). AFT стандартизирует предоставление аккаунтов в большом масштабе и кодифицирует базовые конфигурации в системе контроля версий.

Создать SCP для применения глобальных ограждений с исключениями

Действие: Прикрепить SCP, которые запрещают отключение CloudTrail и AWS Config, ограничивают регионы и предотвращают публичные ACL для S3. Включить исключения на основе условий для роли администратора безопасности в OU Security. Разрешить создание/использование необходимых ролей, связанных с сервисами.
Почему: SCP ограничивают максимальные привилегии для всех субъектов, включая root, предотвращая дрейф конфигурации и позволяя делать контролируемые исключения для централизованных операций.

Развернуть пакеты соответствия (conformance packs) Config с автоматическим исправлением

Действие: Из аккаунта с делегированными правами администратора для Security включить AWS Config для всей организации и создать агрегатор. Развернуть пакет соответствия, который обеспечивает шифрование EBS по умолчанию, ограниченный доступ по SSH, обязательные теги со значениями по умолчанию и обязательное использование WAF на публичных точках входа. Сопоставить каждое правило с документами SSM Automation для автоматического исправления (например, прикрепить профиль инстанса по умолчанию, установить отсутствующие теги на еженедельной основе).
Почему: Пакеты соответствия обеспечивают последовательную, аудируемую политику как код с автоматическим исправлением, что поддерживает окружения в состоянии соответствия без потока заявок.

Централизовать обнаружение с помощью Security Hub, GuardDuty и Inspector

Действие: Включить GuardDuty и Inspector для всей организации с делегированным администратором. Включить стандарты Security Hub (AWS FSBP и CIS) и агрегировать результаты. Создать правила EventBridge для маршрутизации находок высокой степени серьезности в runbook-и SSM Automation и в топик SNS для дежурной команды.
Почему: Управляемое обнаружение и оценка уязвимостей обеспечивают непрерывное покрытие с минимальными операционными затратами, а Security Hub консолидирует сигналы для более быстрого анализа и реагирования.

Обеспечить минимальные привилегии в IAM с помощью границ разрешений и ABAC

Действие: В аккаунтах, предоставленных через AFT, требовать, чтобы создаваемые разработчиками роли прикрепляли границу разрешений, которая запрещает iam:PassRole за исключением тщательно подобранных ролей и ограничивает API с высоким уровнем воздействия. Использовать наборы разрешений IAM Identity Center с ABAC для ограничения действий по тегам команды.
Почему: Границы разрешений обеспечивают безопасное самообслуживание, предотвращая эскалацию привилегий; ABAC сокращает разрастание политик и остается согласованным с атрибутами удостоверений.

Укрепить сетевые пути с помощью конечных точек VPC и PrivateLink

Действие: Удалить IGW/NAT из подсетей приложений. Создать интерфейсные конечные точки для KMS, Secrets Manager, SSM, ECR, CloudWatch и шлюзовые конечные точки для S3/DynamoDB с ограничивающими политиками конечных точек. Публиковать внутренние платформенные сервисы через NLB с поддержкой PrivateLink для использования в других аккаунтах.
Почему: Приватное подключение устраняет уязвимость к атакам из интернета и гарантирует, что сервисы остаются доступными в изолированных средах.

Реализовать стратегию ключей KMS с использованием разрешений (grants) для AMI в разных аккаунтах

Действие: Создать CMK для каждой среды с политиками ключей, ограниченными по ролям. В аккаунте для сборки образов зашифровать «золотые» AMI и предоставить к ним доступ. Обновить политику CMK, чтобы разрешить целевым аккаунтам создавать разрешения (grants), а затем создать разрешения для ролей, связанных с сервисами, в этих целевых аккаунтах.
Почему: Разрешения (grants) обеспечивают ограниченное, аудируемое делегирование без редактирования политик ключей для каждого потребителя, позволяя Auto Scaling запускать инстансы из зашифрованных AMI в разных аккаунтах.

Стандартизировать ротацию секретов и доступ между аккаунтами

Действие: Хранить учетные данные баз данных и API в Secrets Manager. Реализовать ротацию с помощью Lambda для целей, не являющихся RDS, и включить встроенную ротацию для RDS. Для общих платформенных секретов прикрепить политики на основе ресурсов, предоставляющие GetSecretValue ролям-потребителям в других аккаунтах, и убедиться, что политики CMK разрешают расшифровку. Разместить Lambda-функции для ротации в VPC с необходимыми конечными точками.
Почему: Автоматическая ротация снижает риск, связанный с учетными данными; политики на основе ресурсов в сочетании с KMS обеспечивают безопасное использование в разных аккаунтах, сохраняя принцип минимальных привилегий и журналы аудита.

Эта архитектура предоставляет Expedia Group принудительно применяемые ограждения, доказуемое соответствие требованиям, автоматические исправления и строго контролируемые пути доступа к данным, сохраняя при этом скорость работы разработчиков за счет безопасного самообслуживания и приватного подключения.

← Мониторинг · Все домены · Контейнеры и бессерверные операции →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →