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

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Управление идентификацией и доступом: принципиальное управление и федерация

Управление идентификацией должно строиться на основе краткосрочных учетных данных с минимальными привилегиями и четкого разделения между доверием к идентификационным данным и предоставлением разрешений. Используйте роли IAM для всех вычислительных ресурсов и межаккаунтного доступа, избегайте долгосрочных ключей доступа пользователей IAM и применяйте STS для получения временных учетных данных. Для корпоративной федерации через SAML или OIDC настройте централизованный поставщик удостоверений и включите доступ на основе атрибутов с помощью тегов сессии, чтобы разрешения следовали за пользователями и группами без необходимости управлять пользователями в каждой учетной записи. IAM Identity Center предоставляет наборы разрешений в масштабе всей организации, SCIM-провижининг для передачи групп в AWS и интегрируется с принудительным использованием MFA со стороны IdP для соответствия требованиям строгой аутентификации. Дополняйте средства контроля идентификации границами разрешений и управляемыми политиками для ограничения эскалации привилегий, а также используйте IAM Access Analyzer для обнаружения непреднамеренного доступа к ресурсам. Политики управления сервисами (SCP) в AWS Organizations служат защитными барьерами, запрещая целые категории действий в подразделениях (OU), но они не предоставляют разрешений — политики доверия и политики разрешений по-прежнему необходимы. Распространенные ловушки включают слишком широкие действия или принципалы с использованием wildcards (*), использование корневой учетной записи, отсутствие внешних идентификаторов (external ID) для доступа третьих сторон и последовательное принятие ролей (role chaining), которое расширяет эффективную область действия сессии. Компромисс заключается в выборе между операционными издержками и более строгой гранулярностью: высокогранулярные роли требуют большего управления, но значительно уменьшают радиус поражения.

Ключи, секреты и шифрование: жизненный цикл и межаккаунтные шаблоны

Шифрование является основой как для контроля данных в состоянии покоя, так и при передаче; решения должны балансировать между владением ключами, операционным контролем и производительностью. Используйте управляемые клиентом ключи CMK в AWS KMS, когда вам нужны гранулярные политики ключей, межаккаунтные гранты, возможность аудита или автоматическая ротация. Для удобства управления сервисом ключи, управляемые AWS, снижают операционные издержки, но ограничивают контроль над политиками. Конвертное шифрование снижает влияние на производительность при работе с большими объемами данных за счет использования ключа данных для массового шифрования и KMS для его “обертывания” (wrapping). Межаккаунтное или межрегиональное использование требует явных политик ключей и грантов (Grants); избегайте предоставления только разрешений IAM без соответствующей политики ключа. Secrets Manager предлагает рабочие процессы ротации и нативную интеграцию с RDS и другими сервисами, в то время как SSM Parameter Store (тип SecureString) является более дешевым вариантом для менее масштабных нужд; оба сервиса должны использовать VPC-эндпоинты, чтобы избежать публичного исходящего трафика. Распространенные архитектурные ловушки включают предоставление прав kms:* или широких прав на Decrypt в политиках ключей, отсутствие разрешений как в IAM, так и в KMS для ролей выполнения Lambda, а также пренебрежение межрегиональной репликацией ключей, используемых глобально распределенными рабочими нагрузками. Компромиссы между стоимостью и производительностью включают стоимость KMS за каждый запрос и небольшую дополнительную задержку в обмен на преимущества безопасности, которые дает контроль над управляемыми клиентом ключами.

Обнаружение, мониторинг и аудит: телеметрия, детективные контроли и автоматизация

Детективные контроли так же важны, как и превентивные; инструментарий должен быть централизованным, неизменяемым и доступным для поиска. Включите AWS CloudTrail для нескольких регионов и учетных записей с проверкой целостности файлов логов и доставляйте логи в централизованную учетную запись S3 с контролируемым доступом и политиками жизненного цикла. Направляйте логи CloudTrail, VPC Flow Logs и DNS-логи в централизованный конвейер аналитики — CloudWatch Logs, Kinesis Data Firehose и SIEM — для хранения и оповещения. GuardDuty обеспечивает управляемое обнаружение угроз, анализируя поведение учетной записи и рабочих нагрузок; назначьте делегированного администратора для агрегации результатов по всей организации и автоматизируйте реагирование через EventBridge для запуска сценариев (playbooks) на Lambda или Systems Manager Automation. Security Hub агрегирует стандарты и результаты проверок (CIS, PCI, пользовательские правила) и может оркестрировать приоритетное исправление. AWS Config и правила Config обеспечивают непрерывные проверки на соответствие и обнаружение отклонений с возможностью исправления с помощью SSM Automation. Типичные ловушки включают CloudTrail, работающий только в одном регионе, недостаточное время хранения или отсутствие неизменяемости логов, “шумные” оповещения без тонкой настройки и отсутствие делегированных администраторов для масштабирования обнаружения. Компромиссы зависят от стоимости хранения в сравнении с потребностями расследований и соответствия требованиям: более длительное хранение помогает при расследованиях, но увеличивает затраты на S3 и выполнение запросов.

Защита на уровне приложений, WAF, Shield и управление в среде с несколькими аккаунтами

Защита приложений, доступных из интернета, требует многоуровневых средств контроля и централизованного управления политиками. Размещайте AWS WAF на границе сети (CloudFront) и/или на региональных ALB для фильтрации угроз класса OWASP, бот-трафика и для реализации ограничения частоты запросов. Для управления правилами в среде с несколькими аккаунтами используйте AWS Firewall Manager с делегированным аккаунтом безопасности для развертывания групп правил WAFv2, подписок Shield Advanced и централизованных политик безопасности по всем OU. Shield Advanced обеспечивает защиту от DDoS-атак и защиту от затрат при крупномасштабных инцидентах, но является дорогостоящим; сопоставьте SLA и подверженность вашего приложения DDoS-атакам со стоимостью подписки. Используйте централизованные Web ACL, управляемые группы правил и гранулярные обновления наборов IP-адресов, чтобы сократить операционные издержки и избежать несогласованной защиты. Архитектурные ловушки включают в себя опору исключительно на группы безопасности на сетевом уровне, отсутствие централизованного развертывания правил (что приводит к расхождениям в конфигурации) или размещение WAF только на региональном уровне, когда требуется глобальная защита через CDN. Компромиссы в производительности включают потенциальную дополнительную задержку на проверку и сложность пользовательских правил в сравнении с устойчивостью, достигаемой за счет блокировки вредоносного трафика до того, как он достигнет серверов-источников. Обеспечьте логирование WAF, сбор метрик и интеграцию с Security Hub/GuardDuty для слаженного реагирования на инциденты.

Практическая задача: сценарий использования

Сценарий: У компании OmniApps Ltd. есть AWS Organization с управляющим аккаунтом, централизованным сетевым аккаунтом, в котором размещен Transit Gateway, и несколькими аккаунтами с рабочими нагрузками в регионах eu-west-1 и us-east-1. Они запускают приватные стеки приложений в VPC с ALB в приватных подсетях, доступные через CloudFront, и требуют централизованных средств управления идентификацией и безопасностью.

Задача: OmniApps должна централизовать доступ с использованием корпоративной MFA на основе SAML, применять защитные барьеры (guardrails) в масштабе всей организации, управлять правилами WAF и защитой от DDoS-атак в разных аккаунтах, а также обеспечить доступ к секретам и ключам только по приватным сетевым путям.

Рекомендуемый подход:

1. Включить IAM Identity Center в управляющем аккаунте и подключить его к корпоративному IdP на базе SAML с принудительным использованием MFA; настроить провижининг через SCIM и создать наборы разрешений (permission sets) для межаккаунтного доступа с минимальными привилегиями.
2. Внедрить политики управления сервисами (Service Control Policies) в Organizations, чтобы запретить неуправляемые действия от имени root и требовать использования CloudTrail/Config; назначить аккаунт безопасности делегированным администратором для Security Hub, GuardDuty и Firewall Manager.
3. Использовать AWS Firewall Manager из аккаунта безопасности для развертывания Web ACL AWS WAFv2 и управляемых правил AWS (AWS Managed Rules) для дистрибуций CloudFront и ALB в разных аккаунтах; оценить необходимость подписки на Shield Advanced для каждого критически важного приложения.
4. Централизовать логи CloudTrail в защищенный аккаунт для логирования, зашифровав их с помощью мультирегионального CMK в аккаунте безопасности, предоставить право на расшифровку через явную политику ключа KMS и Grants для обработчиков логов, а также включить VPC endpoints для KMS и Secrets Manager для приватного доступа.

Обоснование: Централизованное управление идентификацией и делегированное администрирование безопасности уменьшают административные сложности и радиус поражения (blast radius), в то время как Firewall Manager и централизованное логирование обеспечивают последовательное применение политик и возможности для расследований (форензики), что соответствует лучшим практикам профессиональной архитектуры.

← Сетевое взаимодействие и гибридное подключение · Все домены · Вычисления и Auto Scaling →

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

Просмотреть Amazon →