Amazon DVA-C02: Безопасность, IAM, KMS и управление секретами (Cognito, Secrets Manager, SSM) — Руководство по подготовке

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

IAM, роли, политики и межаккаунтный доступ

Управление идентификацией и доступом (IAM) должно строиться на основе принципа наименьших привилегий, краткосрочных учетных данных и четкого разделения между сервисными и человеческими идентификаторами. Для приложений, работающих на EC2, ECS или Lambda, предпочитайте использовать роли инстанса/задачи/функции вместо встраивания ключей доступа; AWS SDK автоматически используют предоставленную окружением цепочку поставщиков учетных данных и обновляют временные учетные данные. Для межаккаунтного доступа следует использовать AWS STS AssumeRole (API: sts:AssumeRole) с явной политикой доверия роли в целевом аккаунте и IAM-политикой в вызывающем аккаунте, которая ограничивает, какие ARN ролей можно принимать. Когда для чувствительных операций требуется MFA, применяйте его с помощью условия в политике роли или ресурса, используя aws:MultiFactorAuthPresent, или требуйте sts:GetSessionToken для пользователей-людей. Для веб- или мобильных клиентов используйте AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) через Cognito Identity или федеративных провайдеров, чтобы избежать использования долгосрочных учетных данных. Остерегайтесь распространенных ошибок: излишне разрешающие действия/ресурсы с использованием wildcards, опора на политики на основе ресурсов без соответствующих условий для principal, а также отсутствие условий SourceAccount или aws:SourceVpc для межаккаунтного доступа к S3 или KMS. Используйте симулятор политик IAM и sts:GetCallerIdentity для отладки. Рассмотрите возможность использования политик управления сервисами (SCP) на уровне организации для внедрения защитных барьеров и явного запрета (explicit deny) рискованных действий, таких как kms:CreateGrant или iam:CreateAccessKey, где это уместно.

KMS, шаблоны шифрования и контроль доступа к ключам

Используйте AWS KMS для конвертного шифрования: вызовите GenerateDataKey/GenerateDataKeyWithoutPlaintext для создания ключа данных для шифрования на стороне клиента или сервера, затем вызовите Encrypt/Decrypt для небольших объемов данных или используйте ключ данных для массового шифрования. Выберите правильный CMK: принадлежащий AWS для удобства, управляемый AWS (aws/*) для интеграции с сервисами или управляемый клиентом для полного контроля и ротации. Политики ключей — это основной механизм контроля для KMS; прикрепляйте IAM-политики, разрешающие kms:Decrypt, kms:Encrypt, и используйте гранты (grants), когда вам требуется временное, делегированное использование ключа для таких сервисов, как операции с поддержкой CloudHSM или межаккаунтный вызов Lambda. Включайте EncryptionContext, чтобы привязать зашифрованный текст к контексту использования, и требуйте его наличие через условие kms:EncryptionContextEquals для повышения уровня гарантий. Межаккаунтное использование KMS требует явных записей в политике ключа, предоставляющих доступ внешнему principal или роли, а в некоторых случаях — разрешений CreateGrant/RetireGrant. Для аудита и расследований включите события данных CloudTrail для KMS и S3, чтобы отслеживать вызовы GenerateDataKey и Decrypt; логи CloudTrail будут содержать arn:aws:kms и подробную информацию о том, какой principal использовал ключ. Распространенные ошибки включают отсутствие разрешения kms:CreateGrant для сервисов, которые используют гранты в фоновом режиме, отказ от ротации ключей, управляемых клиентом, и предположение, что одних только IAM-политик достаточно для авторизации операций KMS без соответствующих записей в политике ключа.

Управление секретами: Secrets Manager в сравнении с Parameter Store

Secrets Manager и Systems Manager Parameter Store оба предоставляют хранилище зашифрованных секретов, но различаются по функциональности и стоимости: Secrets Manager поддерживает автоматическую ротацию (с помощью шаблонов ротации на Lambda), встроенное версионирование и интегрированную репликацию, а плата взимается за каждый секрет; Parameter Store (SecureString) входит в уровень бесплатного пользования для большого количества параметров и лучше подходит для простой конфигурации. Доступ контролируется IAM-политиками, предоставляющими разрешения secretsmanager:GetSecretValue или ssm:GetParameter с WithDecryption=true, при этом базовый ключ KMS должен разрешать операцию decrypt для данного principal. Используйте политики на основе ресурсов в Secrets Manager для межаккаунтных секретов или репликацию с помощью репликации секретов. При использовании SDK вызывайте secretsmanager.getSecretValue({ SecretId }) или ssm.getParameter({ Name, WithDecryption: true }) и избегайте логирования значений секретов; настраивайте переменные окружения Lambda так, чтобы они использовали ссылки на Secrets Manager или Parameter Store с динамическим разрешением в CloudFormation или SAM, или получайте значения через SDK при запуске приложения. Распространенные ошибки разработчиков включают хранение секретов в виде открытого текста в системе контроля версий, использование переменных окружения Lambda для очень чувствительных данных без защиты KMS и излишне разрешающие IAM-политики, например, предоставление secretsmanager:* широким ролям. Для ротации убедитесь, что Lambda-функция ротации имеет корректные разрешения secretsmanager:RotateSecret и kms:GenerateDataKey, и что код приложения может бесшовно переинициализировать соединения при смене учетных данных.

Аутентификация, авторизация и интеграция с API в Cognito

Amazon Cognito предоставляет пулы пользователей (user pools) для аутентификации и пулы удостоверений (identity pools) для получения временных учетных данных AWS. Используйте Cognito User Pools для управления регистрацией пользователей, многофакторной аутентификацией и выпуском JWT (токенов ID, доступа и обновления). Одностраничные приложения (SPA), работающие в браузере, должны использовать клиенты приложений (app clients) без секрета клиента и применять либо хостируемый UI, либо Amazon Cognito SDK (amazon-cognito-identity-js), реализующий протокол SRP, чтобы избежать раскрытия паролей. Проверяйте JWT на сервере или в API Gateway, получая JWKS URI из пула пользователей и валидируя подпись, издателя (issuer), аудиторию (aud) и срок действия токена. Эту проверку могут выполнять JWT-авторизаторы API Gateway или пользовательские авторизаторы Lambda. Для аутентификации между сервисами обменивайте токен из пула пользователей на временные учетные данные через Cognito Identity Pool с помощью вызова sts:AssumeRoleWithWebIdentity. К распространенным ошибкам относятся неверно настроенные URL-адреса обратного вызова (callback) или выхода, отказ от проверки областей (scopes) или групп в токене, а также ожидание, что ID-токены можно напрямую использовать для вызовов AWS API (их необходимо обменивать через пул удостоверений). Для гранулярной авторизации используйте группы или пользовательские утверждения (custom claims) и сочетайте Cognito с политиками на основе ресурсов и ключами условий IAM, такими как aws:userid или cognito-identity.amazonaws.com:sub, при сопоставлении удостоверений с ролями AWS. Проводите аудит входа в систему и административных действий с помощью CloudTrail и включите расширенные функции безопасности в Cognito для обнаружения скомпрометированных учетных данных.

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

Сценарий: Игровая студия PixelForge использует бессерверный бэкенд в одном аккаунте AWS, включающий Lambda, API Gateway, S3, DynamoDB и пулы пользователей Cognito. Конфиденциальные API-ключи и учетные данные баз данных хранятся для нескольких сред развертывания, а сторонняя команда аудиторов должна получать доступ к подмножеству производственных изображений в S3 на срок от 1 до 24 часов.

Задача: Безопасно предоставить краткосрочный, аудируемый доступ к производственным изображениям для внешних аудиторов, обеспечить ротацию и безопасный доступ к секретам приложений для Lambda, а также принудительно использовать MFA для кросс-аккаунтного доступа администраторов.

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

1. Создайте управляемый клиентом ключ KMS (customer-managed key) с политикой ключа, разрешающей расшифровку для аккаунта PixelForge и предоставляющей права для IAM-роли аудитора; включите ротацию ключа и требуйте использования EncryptionContext при операциях расшифровки.
2. Храните учетные данные в Secrets Manager (отдельные секреты для каждой среды) и прикрепите к функциям Lambda IAM-роль с минимальными разрешениями secretsmanager:GetSecretValue и kms:Decrypt для ключа KMS; реализуйте в коде инициализации Lambda вызов

undefined

с помощью AWS SDK. 3. Для доступа аудиторов создайте отдельную роль в аккаунте AWS аудитора и разрешите sts:AssumeRole из этого аккаунта в политике бакета S3 на основе ресурсов, ограниченной с помощью aws:PrincipalArn и предварительно настроенного сопоставления ролей с ограничением по времени; генерируйте краткосрочные учетные данные через sts:AssumeRole и требуйте MFA с помощью условия aws:MultiFactorAuthPresent при принятии роли. 4. Логируйте все доступы с помощью CloudTrail (события управления и данных для S3 и KMS) и включите логирование на уровне объектов S3, а также Amazon Macie или S3 Access Logs для дополнительного анализа; требуйте, чтобы временные сессии аудиторов использовали определенный EncryptionContext, и тегируйте объекты/запросы для отслеживаемости.

Обоснование: Использование Secrets Manager с KMS и краткосрочными учетными данными STS обеспечивает принцип наименьших привилегий, позволяет автоматизировать ротацию и избежать жесткого кодирования секретов. Паттерны с ограниченным по времени принятием роли (assume-role) с MFA и событиями данных CloudTrail предоставляют аудируемый, отзываемый доступ для третьих сторон, сохраняя при этом разделение обязанностей.

← Развертывание и CI · Все домены · Мониторинг →

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

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