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

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Этот раздел охватывает примитивы идентификации, шифрования, управления секретами и аудита, которые лежат в основе безопасных и соответствующих нормативным требованиям операций в AWS. Он фокусируется на предоставлении правильного доступа (принцип наименьших привилегий), защите данных с помощью управления ключами и шифрования, а также на создании неизменяемых журналов аудита для непрерывного соответствия требованиям. Повседневные обязанности SysOps-инженера включают проектирование IAM-ролей и границ доверия, управление ключами KMS и секретами, а также использование AWS Config и CloudTrail для обнаружения отклонений в конфигурации и нарушений политик.

IAM, роли, политики и федерация

Управление IAM должно начинаться с разделения ролей и принципа наименьших привилегий: используйте отдельные роли для администрирования, ведения журналов и рабочих нагрузок приложений; избегайте прикрепления широких политик, таких как AdministratorAccess, к долгоживущим субъектам (principals). Создавайте роли с политикой доверия (trust policy) (в консоли или через CLI:

undefined

) и прикрепляйте политики разрешений с помощью

undefined

или управляемых политик. Используйте границы разрешений (permission boundaries) и условия IAM Conditions (

undefined

,

undefined

), чтобы ограничить, где и как могут использоваться привилегии.

Для федерации удостоверений предпочитайте SAML/OIDC для выпуска временных учетных данных через STS. Для SAML настройте поставщика удостоверений (identity provider) в IAM и используйте

undefined

. Для OIDC (Cognito, Auth0 или другие провайдеры) создайте OIDC-провайдера в IAM и сопоставьте утверждения (claims) с ролями; федерация через веб-удостоверения использует

undefined

. Выбирайте федеративные роли, когда пользователи являются внешними или когда централизованные службы каталогов управляют аутентификацией; используйте AWS IAM Identity Center (SSO) для централизованного корпоративного доступа и управления сессиями.

KMS, управление ключами и шифрование

KMS — это центральный сервис для управления жизненным циклом ключей и контролем доступа. Выбирайте между ключами, управляемыми AWS (простота), ключами, принадлежащими AWS, и ключами, управляемыми клиентом (CMK) (детальный контроль). Создавайте CMK с помощью

undefined

и включайте автоматическую ротацию с помощью

undefined

. Используйте политики ключей (key policies) для определения, кто может управлять ключами, и гранты (grants) для временного делегирования доступа (

undefined

) вместо широких IAM-политик.

Критерии принятия решений: используйте CMK, когда требуется аудит и контроль жизненного цикла ключей (ротация, окна удаления); используйте ключи, управляемые AWS, для автоматического удобства во многих управляемых сервисах. Защищайте ключи, применяя IAM-политики и политики ключей, ограничивайте использование через

undefined

или гранты KMS для меж-аккаунтного доступа и избегайте планирования немедленного удаления — используйте минимальный период ожидания. Отслеживайте использование KMS с помощью журналов CloudTrail для операций Encrypt/Decrypt и GenerateDataKey, чтобы обнаруживать аномальное использование.

Управление секретами и хранилища параметров

Используйте AWS Secrets Manager для ротации учетных данных и автоматизации жизненного цикла, а Systems Manager Parameter Store (тип SecureString) — для более простых секретов, где ротация выполняется вручную. Создавайте секреты с помощью

undefined

и включайте ротацию, указав Lambda-функцию для автоматической смены. Для Parameter Store используйте

undefined

.

Ключевые моменты для принятия решения:

• Secrets Manager: встроенная ротация, версионирование секретов, репликация и интегрированные шаблоны ротации в консоли; более высокая стоимость, но лучше подходит для учетных данных баз данных и API-ключей.
• Parameter Store SecureString: бесплатный уровень для базового хранения секретов, используйте KMS CMK для шифрования и IAM-политики для доступа. Всегда ограничивайте доступ к секретам с помощью IAM-политик с наименьшими привилегиями и предпочитайте доступ на основе ролей (роли выполнения EC2/ECS/Lambda), а не встраивание долгоживущих учетных данных в код или переменные окружения.

AWS Config, аудит и мониторинг соответствия требованиям

AWS Config обеспечивает непрерывную запись состояния ресурсов, историю изменений и оценку правил. Включите рекордер и канал доставки (в консоли или через

undefined

) и создайте управляемые или пользовательские правила с помощью

undefined

. Комбинируйте Config с CloudTrail (

undefined

) и CloudWatch Alarms для обнаружения и устранения проблем почти в реальном времени (используйте действия по исправлению (remediation actions) в Config или документы автоматизации Systems Manager).

Проектные решения: используйте управляемые правила Config для стандартных проверок (публичное чтение в бакете S3, MFA для корневого аккаунта) и пользовательские правила (Lambda) для специфичных для домена контролей. Обеспечьте агрегацию данных Config из нескольких регионов в агрегатор и включите запись для нескольких аккаунтов через AWS Organizations. Поддерживайте неизменяемый журнал аудита, отправляя логи CloudTrail в центральный зашифрованный бакет S3 (SSE-KMS) и включите CloudTrail Insights для выявления аномальной активности API.

Защита данных, шифрование при передаче и хранении

Шифрование следует применять на нескольких уровнях: при хранении (at rest) с использованием шифрования на базе KMS для EBS, RDS, S3 (SSE-S3, SSE-KMS или SSE-C) и при передаче (in transit) с использованием TLS для трафика приложений (используйте ACM для публичных/приватных сертификатов и прикрепляйте их к прослушивателям ALB/NLB:

undefined

). Используйте шифрование на стороне клиента, когда требуется дополнительный контроль, и рассмотрите возможность использования envelope-шифрования с помощью GenerateDataKey при шифровании больших объемов данных, превышающих квоты KMS.

Применяйте следующие критерии для принятия решений:

• Используйте SSE-KMS для объектов S3, когда вам нужен аудит и контроль доступа к ключам; SSE-S3 подходит для базового шифрования на стороне сервера.
• Используйте KMS CMK для EBS и RDS, когда вам нужна ротация ключей и контроль доступа между аккаунтами.
• Всегда принудительно используйте TLS для конечных точек сервисов; используйте HSTS и сильные шифры в балансировщиках нагрузки. Используйте VPC-эндпоинты и IAM-политики, чтобы уменьшить публичную доступность API плоскости данных (data-plane).

Распространённые ошибки и критерии принятия решений

• Чрезмерное использование учётной записи root или хранение её учётных данных: вместо этого создавайте роли администратора с MFA и используйте AWS SSO или роли IAM для повседневных задач; заблокируйте учётные данные root в безопасном хранилище и включите для них MFA.
• Использование долгоживущих ключей доступа: регулярно ротируйте ключи или откажитесь от них в пользу временных учётных данных через STS и цепочек ролей (роли EC2/ECS/Lambda).
• Отсутствие ротации или неправильная защита ключей KMS и секретов: включите автоматическую ротацию для CMK, где это возможно, используйте ротацию в Secrets Manager для учётных данных баз данных и отслеживайте использование ключей через CloudTrail.
• Использование разрешений S3 или ACL по умолчанию: применяйте политики бакетов, блокируйте публичный доступ и используйте SSE-KMS для конфиденциальных данных; проверяйте конфигурацию с помощью правил AWS Config.
• Неправильное использование политик ключей в сравнении с политиками IAM: управляйте администрированием ключей в политике ключа KMS и предоставляйте права на использование через grants или IAM, когда это уместно; избегайте широкого предоставления разрешений на Decrypt.
• Игнорирование централизованного сбора логов и межрегиональной агрегации: настройте межрегиональные трейлы CloudTrail и агрегаторы Config для проверки соответствия требованиям в нескольких аккаунтах.

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

AcmeFin, финтех-компания, должна защитить производственные базы данных и API, предоставляя подрядчикам временный доступ и обеспечивая возможность аудита для проверок на соответствие требованиям.

1. Создать отдельные роли IAM для администраторов, приложений и подрядчиков; принудительно использовать MFA и использовать IAM Identity Center для федерации на основе SAML для подрядчиков.
2. Зашифровать RDS и EBS с помощью управляемого клиентом ключа CMK (aws kms create-key), включить ротацию ключей и ограничить их использование с помощью строгой политики ключа, разрешающей доступ только ролям баз данных и аудита.
3. Хранить учётные данные баз данных в AWS Secrets Manager с автоматической ротацией с помощью предоставленного шаблона ротации Lambda.
4. Включить CloudTrail (межрегиональный) и рекордер AWS Config, отправлять логи в центральный бакет S3, зашифрованный с помощью SSE-KMS, и создать правила Config для публичных бакетов S3 и незашифрованных ресурсов.
5. Использовать ALB с сертификатами, выданными ACM, для HTTPS и размещать API за WAF и эндпоинтами VPC, где это необходимо.

Этот подход реализует принцип наименьших привилегий через разделение ролей, автоматизирует ротацию учётных данных и ключей для уменьшения радиуса поражения (blast radius) и централизует логи и оценки Config, чтобы аудиторы могли проверять средства контроля, в то время как операционные команды сохраняют безопасные шаблоны временного доступа.

← Развертывание · Все домены · Сетевые технологии и доставка контента →

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

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