Amazon SCS-C02: Шифрование, KMS и секреты — Руководство по подготовке

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

Типы ключей, политики и контроль доступа в AWS KMS

AWS KMS поддерживает три основные категории ключей, и выбор правильной категории определяет, кто контролирует ключевой материал, где он хранится и как его можно ротировать. Ключи, принадлежащие AWS, невидимы для вас, бесплатны и используются такими сервисами, как S3, когда вы включаете SSE-S3. Ключи, управляемые AWS (с псевдонимом aws/<service>), позволяют сервису выполнять шифрование от вашего имени, но вы не можете изменять их политику ключа, поэтому они не подходят для межсетевого доступа или детального управления. Ключи, управляемые клиентом (CMK), — это основная «рабочая лошадка»: вы контролируете политику ключа, ротацию (ежегодную автоматическую или по запросу), гранты, псевдонимы и период ожидания удаления.

Важны два специализированных варианта. Импортированный ключевой материал используется, когда нормативные требования или требования BYOK заставляют вас генерировать ключевой материал за пределами AWS и импортировать его в ключ KMS. Импортированный материал — это единственный способ настроить явное истечение срока действия ключевого материала — сгенерированные AWS CMK никогда не истекают. Вы не можете включить автоматическую ежегодную ротацию AWS для импортированных ключей; вы должны повторно импортировать материал самостоятельно. Мультирегиональные ключи используют один и тот же ID и материал ключа в разных регионах с помощью ключей-реплик, поэтому шифротекст, созданный в us-east-1, может быть расшифрован в us-west-1 без повторного шифрования. Каждая реплика имеет свою собственную независимую политику ключа и псевдонимы, но криптографический материал синхронизируется.

Наиболее часто неправильно понимаемый элемент управления — это политика ключа KMS. В отличие от большинства ресурсов AWS, где доступ предоставляется только политиками IAM, ключи KMS используют свою политику ключа в качестве основного источника авторизации. Политика IAM, предоставляющая kms:Decrypt для ключа, не будет действовать, если политика ключа также не делегирует доступ IAM (через Principal корневого пользователя аккаунта с соответствующим выражением или путем прямого указания principal). Вот почему инженер с AdministratorAccess все еще может получить AccessDenied при вызове Decrypt для CMK, политика которого не доверяет аккаунту. Каноническое выражение для делегирования выглядит так:

{
  "Sid": "EnableIAMPermissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Гранты и условия ViaService добавляют дополнительные уровни ограничений — например, требуя, чтобы ключ использовался только через S3 в определенном регионе с kms:ViaService: s3.us-east-1.amazonaws.com.

Шифрование на стороне сервера и на стороне клиента

Для S3 два распространенных варианта шифрования на стороне сервера различаются в основном по уровню контроля и аудируемости:

• SSE-S3 (AES-256): S3 полностью управляет ключами; нет видимой для клиента политики ключа, нет событий расшифровки в CloudTrail для каждого ключа и нет межсетевого управления. Достаточно для базового шифрования неактивных данных, но не подходит, когда требования соответствия обязывают доказывать, кто расшифровал данные.
• SSE-KMS: Использует CMK, который вы контролируете; каждый вызов decrypt регистрируется, политика ключа обеспечивает контроль доступа, и вы можете ограничивать доступ по контексту шифрования. Этот метод дороже за каждый запрос и потребляет квоты TPS для KMS, поэтому следует включать ключи бакета (BucketKeyEnabled: true), чтобы значительно сократить количество вызовов KMS.

Шифрование на стороне клиента с использованием AWS Encryption SDK подходит, когда данные должны быть зашифрованы до того, как они покинут приложение, или когда сервис хранения никогда не должен видеть незашифрованный текст. Для рабочих нагрузок с высокой пропускной способностью следует использовать SDK с менеджером криптографических материалов с кешированием (CachingCryptoMaterialsManager), который повторно использует ключи данных для множества сообщений в рамках настраиваемых ограничений по байтам, сообщениям и TTL. Без кеширования каждый вызов encrypt инициирует запрос GenerateDataKey, что быстро исчерпывает квоты на запросы к KMS и увеличивает затраты.

from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
    master_key_provider=mkp, cache=cache,
    max_age=600.0, max_messages_encrypted=10000)

Secrets Manager и Parameter Store

Secrets Manager хранит учетные данные, зашифрованные с помощью KMS CMK, и поддерживает автоматическую ротацию через Lambda-функцию — AWS предоставляет шаблоны для RDS, Redshift и DocumentDB, а пользовательские Lambda-функции могут обрабатывать любые другие случаи. Ротация выполняет четырехэтапный конечный автомат (createSecret, setSecret, testSecret, finishSecret), который размещает новые учетные данные под меткой AWSPENDING, прежде чем повысить их до AWSCURRENT. Приложения должны перехватывать сбои аутентификации, обновлять секрет и повторять попытку — этот паттерн исключает время простоя, поскольку предыдущие учетные данные кратковременно остаются действительными через AWSPREVIOUS.

Когда Lambda-функция ротации выполняется внутри VPC (что типично для доступа к частному экземпляру RDS), ей необходим исходящий сетевой доступ к конечной точке сервиса Secrets Manager. В частном VPC без NAT вы должны развернуть интерфейсный VPC эндпоинт (com.amazonaws.<region>.secretsmanager) и разрешить группе безопасности Lambda-функции доступ к эндпоинту по порту 443. Забыть об этом — классическая ошибка: ротация кажется настроенной, но каждый вызов завершается по тайм-ауту.

Для межрегиональной отказоустойчивости используйте мультирегиональный ключ KMS и функцию репликации секретов в Secrets Manager. Основной секрет в us-east-1 шифруется основным CMK; реплика в us-west-1 расшифровывается с помощью CMK-реплики. Псевдонимы, такие как alias/prod-db, можно по запросу перенаправить на новый ID ключа для быстрой ротации ключей без изменения кода приложения.

Тип SecureString в Parameter Store является легковесной альтернативой, когда вам не нужна ротация. Оба сервиса предоставляют динамические ссылки в CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}), чтобы шаблоны стеков никогда не содержали незашифрованный текст.

Шифрование в EBS, RDS, Aurora и шифрование снимков

Шифрование неактивных данных включается для каждого тома или экземпляра во время создания и не может быть включено или выключено для существующего ресурса. Схема исправления для незашифрованного ресурса, не соответствующего требованиям, — это копирование снимка с шифрованием:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region us-east-1 --encrypted \
  --kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...

Для RDS и Aurora восстановите зашифрованный снимок в новый экземпляр и переключитесь на него. Восстановление в другом аккаунте требует предоставления доступа к снимку и предоставления целевому аккаунту прав kms:CreateGrant и kms:Decrypt на CMK через политику ключа — простого предоставления доступа к снимку будет недостаточно, так как целевой аккаунт не сможет расшифровать ключ данных. Шифрование EBS по умолчанию на уровне аккаунта должно быть включено, чтобы вновь создаваемые тома всегда шифровались независимо от поведения вызывающей стороны.

TLS: Политики ACM и ALB

ACM бесплатно выпускает и автоматически продлевает публичные сертификаты при их привязке к интегрированным сервисам (ALB, CloudFront, API Gateway). Сертификаты нельзя экспортировать, поэтому для терминирования TLS на EC2 требуется либо ACM Private CA (для частных сертификатов, которые можно экспортировать), либо импортированный сертификат. Прагматичный подход: терминировать публичный TLS на ALB с помощью сертификата ACM и использовать самоподписанный сертификат или сертификат от частного CA для участка от ALB до EC2, если требуется сквозное шифрование. Принудительно используйте для клиентов современные шифры с помощью политики безопасности, такой как ELBSecurityPolicy-TLS13-1-2-2021-06, которая отключает TLS 1.0/1.1 и слабые наборы шифров.

Распространенные ловушки

IAM без политики ключа. Предоставление права kms:Decrypt в политике IAM, когда в политике ключа CMK отсутствует основной субъект (principal) аккаунта, приводит к ошибке AccessDenied. KMS рассматривает политику ключа как авторитетную; разрешения IAM могут только дополнительно ограничивать то, что разрешено политикой ключа.

Lambda-функция ротации без VPC endpoint. Если Lambda-функция выполняется в частных подсетях, а в VPC нет NAT и интерфейсного эндпоинта (interface endpoint) для secretsmanager, вызов для ротации к secretsmanager.<region>.amazonaws.com не сможет разрешить имя или подключиться. Группа безопасности эндпоинта также должна разрешать трафик по порту 443 от группы безопасности Lambda-функции.

Приравнивание SSE-S3 к SSE-KMS. SSE-S3 использует ключ, принадлежащий AWS, без редактируемой клиентом политики, без логирования расшифровки каждого объекта в CloudTrail и без возможности совместного использования ключа между аккаунтами. Этот метод позволяет поставить галочку в пункте «шифрование при хранении», но не может контролировать, какие субъекты могут расшифровывать конкретные объекты — только SSE-KMS с CMK обеспечивает такой уровень управления.

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

Сценарий: Компания Meridian Financial использует AWS Organization с несколькими аккаунтами, включая аккаунт безопасности (Security account) и отдельные аккаунты для Prod/NonProd. В инфраструктуре используются микросервисы на ECS/EKS за ALB, кластеры RDS/Aurora, инстансы EC2 с томами EBS и озера данных на S3. Разработчики и средства автоматизации в настоящее время используют комбинацию ключей, управляемых AWS, параметры SSM в виде простого текста и периодически вручную обмениваются снимками между аккаунтами.

Проблема: Инженер случайно предоставил доступ к незашифрованному снимку RDS стороннему аккаунту, а также было обнаружено, что несколько учетных данных API хранились в виде простого текста в параметрах SecureString, что создало риск утечки данных и несанкционированного доступа к восстановлению.

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

1. Создать в аккаунте безопасности управляемый клиентом (customer-managed) симметричный ключ CMK в AWS KMS с областью действия на уровне организации. В политике ключа предоставить право использования аккаунтам-участникам через aws:PrincipalOrgID и включить автоматическую ротацию; использовать гранты (grants) для краткосрочных меж-аккаунтных операций.
2. Исправить существующие артефакты, скопировав незашифрованный снимок RDS и любые снимки EBS с выбором нового CMK для создания зашифрованных копий, а затем удалить исходные незашифрованные снимки; установить настройки по умолчанию для аккаунтов, чтобы новые ресурсы RDS и EBS создавались зашифрованными по умолчанию.
3. Перенести секреты в AWS Secrets Manager (или SSM Parameter Store SecureString), зашифровав их с помощью CMK, включить автоматическую ротацию учетных данных баз данных в Secrets Manager через Lambda и ограничить доступ с помощью ресурсных политик и IAM-ролей с минимальными привилегиями.
4. Обеспечить шифрование при передаче, предоставив управляемые ACM TLS-сертификаты и прикрепив их к ALB с современной политикой TLS (TLS 1.2/1.3), а также настроить базы данных и клиенты на обязательное использование TLS-соединений.
5. Предотвратить повторение инцидентов с помощью защитных барьеров (guardrails): применить политики управления сервисами (Service Control Policies) для запрета создания/совместного использования незашифрованных снимков и незашифрованных операций put в S3, включить правила AWS Config для проверки шифрования ресурсов и отслеживать использование KMS и Secrets Manager через CloudTrail и CloudWatch Alarms.

Обоснование: Централизованные CMK с политиками на уровне организации, автоматическое перешифрование, использование Secrets Manager для управления жизненным циклом секретов, принудительное применение TLS и превентивные защитные барьеры соответствуют лучшим практикам AWS по предоставлению минимальных привилегий и созданию эшелонированной защиты (defense-in-depth), чтобы исключить хранение секретов в виде простого текста и несанкционированный доступ к снимкам.

CMK, управляемые клиентом: мультирегиональность, импортированный материал и политики ключей

CMK, управляемый клиентом, — это плоскость управления для каждой криптографической операции с вашими данными в AWS. Три свойства, которые чаще всего определяют, будет ли архитектура успешной или приведет к сбою, — это топология регионов ключа, происхождение его материала и прикрепленная к нему политика.

Мультирегиональные ключи — это набор ключей KMS в разных регионах, которые имеют один и тот же идентификатор (key ID) и, что особенно важно, один и тот же базовый материал ключа. Они не реплицируются автоматически, как глобальные таблицы DynamoDB, — вы явно создаете реплики из основного ключа с помощью ReplicateKey. Поскольку материал ключа идентичен во всех репликах, шифротекст, созданный в us-east-1, может быть расшифрован в us-west-1 без межрегиональных вызовов KMS. Это именно то свойство, которое требуется при репликации секрета Secrets Manager между регионами: секрет-реплика в регионе аварийного переключения (failover) должен расшифровываться локально, чтобы устранить задержку межрегиональных вызовов при каждом GetSecretValue и пережить региональный сбой основного региона. Однорегиональный CMK не может использоваться для реплики Secrets Manager в другом регионе, поэтому правильный паттерн — зашифровать основной секрет мультирегиональным CMK, реплицировать ключ в целевой регион, а затем реплицировать секрет, указав на CMK-реплику.

aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
  --replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
  --secret-id prod/db \
  --add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123

Импортированный материал ключа (внешнее происхождение, Origin=EXTERNAL) используется, когда вы генерируете необработанный материал AES-256 за пределами AWS и импортируете его в «оболочку» ключа KMS. AWS никогда не хранит копию этого материала за пределами защищенной памяти HSM, и резервной копии не существует. Если вы удалите импортированный материал — либо с помощью DeleteImportedKeyMaterial, либо по истечении срока его действия, — ключ перейдет в состояние PendingImport, и весь шифротекст, созданный с его помощью, станет невосстановимым, если только вы не импортируете повторно точно те же байты. Это путь восстановления, когда, например, том EBS не может быть присоединен, потому что его зашифрованный ключ данных не удается расшифровать: повторно импортируйте идентичный материал ключа из вашего офлайн-хранилища (escrow), и том снова станет доступным. Не существует восстановления на стороне AWS, трюков с ротацией или обращения в техподдержку, которые могли бы восстановить удаленный импортированный материал. Относитесь к офлайн-копии как к инфраструктуре нулевого уровня (tier-zero).

Политики ключей — это корень доверия для каждого ключа KMS. В отличие от одного лишь IAM, KMS требует явного разрешения в самой политике ключа; политика IAM, предоставляющая kms:Decrypt, не будет работать, если политика ключа не делегирует полномочия IAM ("Principal": {"AWS": "arn:aws:iam::111122223333:root"} в сочетании с условным оператором). Для межаккаунтного использования политика ключа должна явно указывать внешний аккаунт или принципала, а внешний аккаунт, в свою очередь, должен предоставить разрешения своим пользователям через IAM. Отсутствие настройки на стороне политики ключа — самая частая причина сбоев при межаккаунтном доступе к Secrets Manager: политика ресурсов Secrets Manager разрешает внешнему принципалу вызывать GetSecretValue, но базовый вызов Decrypt завершается ошибкой, потому что CMK по-прежнему отклоняет запрос от вызывающей стороны.

Паттерны использования Secrets Manager и Parameter Store SecureString

И Secrets Manager, и SSM Parameter Store SecureStrings делегируют шифрование сервису KMS, но различаются по стоимости, семантике ротации и поведению в разных регионах. Secrets Manager поддерживает нативную мультирегиональную репликацию, версионирование с метками стадий (AWSCURRENT, AWSPENDING) и ротацию на основе Lambda-функций. Parameter Store SecureString дешевле, интегрируется с иерархическими путями и хорошо подходит для секретов конфигурационного типа, которые ротируются редко.

Для межаккаунтного доступа вы должны обновить и политику ресурсов секрета (или политику IAM в аккаунте-потребителе Parameter Store), и политику ключа KMS, используемого для шифрования. Ошибочно полагать, что достаточно одних лишь разрешений Secrets Manager, потому что процесс получения секрета всегда неявно выполняет операцию kms:Decrypt с использованием CMK; без разрешения для внешнего аккаунта в политике ключа вызывающая сторона получит AccessDeniedException на шаге Decrypt, даже если политика самого секрета удовлетворена.

• Secrets Manager: управляемая ротация, структура JSON, ~$0.40/секрет/месяц, встроенная мультирегиональная репликация
• Parameter Store SecureString (Advanced): дешевле при большом количестве значений, 8 КБ на параметр, нет встроенной межрегиональной репликации
• Parameter Store SecureString (Standard): бесплатный уровень для зашифрованных KMS параметров до 4 КБ, нет механизма ротации

Конвертное шифрование, ключи бакета и токены грантов

Конвертное шифрование означает, что KMS никогда не работает с вашими данными напрямую. Вы вызываете GenerateDataKey, который возвращает как незашифрованный ключ данных (используемый локально для шифрования ваших данных с помощью AES-GCM), так и зашифрованную копию этого ключа данных (хранящуюся вместе с зашифрованным текстом). Для расшифровки вы вызываете Decrypt для зашифрованного ключа данных и локально восстанавливаете незашифрованный ключ. Этот паттерн крайне важен, поскольку у KMS есть квоты на запросы (на регион, на ключ) и тарификация за каждый вызов API. Если вы будете шифровать каждую запись размером 4 КБ прямым вызовом Encrypt, вы столкнетесь с троттлингом и резким ростом затрат; если же вы генерируете один ключ данных на пакет или на файл, пропускная способность масштабируется линейно в зависимости от вашей локальной криптографической библиотеки.

S3 Bucket Keys применяют тот же принцип внутри S3 для SSE-KMS. Без ключа бакета каждый PUT и GET объекта SSE-KMS генерирует вызов GenerateDataKey или Decrypt. В бакете, получающем тысячи объектов в секунду, это приводит как к троттлингу KMS, так и к неожиданно большим счетам за его использование. Включение ключа бакета заставляет S3 генерировать один краткосрочный ключ на уровне бакета и повторно использовать его для многих объектов, сокращая объем запросов к KMS на порядки:

aws s3api put-bucket-encryption --bucket app-data \
  --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
      "BucketKeyEnabled":true}]}'

Гранты (Grants) — это альтернатива политикам ключей для временного, гранулярного делегирования полномочий. Они важны с операционной точки зрения из-за итоговой согласованности: после возврата ответа от CreateGrant грант не сразу виден всем эндпоинтам KMS в регионе. Если клиент попытается выполнить Encrypt через несколько миллисекунд, он может получить AccessDeniedException. Тело ответа CreateGrant включает строку GrantToken, которая, будучи переданной в последующих вызовах KMS через параметр --grant-tokens, заставляет KMS немедленно применить грант, независимо от состояния его распространения.

TOKEN=$(aws kms create-grant --key-id $KEY \
  --grantee-principal arn:aws:iam::111122223333:role/worker \
  --operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
  --grant-tokens "$TOKEN"

Полагаться на механизм повторных попыток с экспоненциальной задержкой вместо использования токена гранта — это допустимое, но менее эффективное решение: оно приводит к потере времени на задержках и все равно может давать сбои под нагрузкой. Канонический ответ всегда один: возвращайте токен гранта из сервиса, который создает грант, и требуйте от вызывающих сторон предъявлять его при первой же операции.

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

Сценарий: Meridian Financial работает в многоаккаунтной среде AWS, размещая персональные данные клиентов (PII) в S3, транзакционные базы данных в RDS и бессерверную обработку через Lambda. Они используют управляемые клиентом ключи CMK с импортированным ключевым материалом, чтобы соответствовать региональным правилам хранения ключей, и реплицируют ключи во второй регион для аварийного восстановления (DR).

Задача: Недавний аудит выявил неправильно настроенную политику ключа KMS, которая разрешала меж-аккаунтную расшифровку. Внешнему аудитору требуется временный доступ для расшифровки подмножества объектов S3. Кроме того, Meridian необходимо обеспечить безопасную ротацию секретов и эффективное шифрование для больших объектов, чтобы контролировать затраты на запросы к KMS.

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

1. Изменить некорректную политику CMK в AWS KMS на политику с минимальными привилегиями, которая явно предоставляет доступ только необходимым IAM-субъектам и ролям, и создать мультирегиональную реплику CMK для DR, используя мультирегиональные ключи KMS.
2. Повторно импортировать или запланировать управление жизненным циклом для импортированного ключевого материала в соответствии с окнами соответствия требованиям и включить автоматические уведомления об истечении срока действия/ротации ключевого материала с помощью AWS Config и EventBridge.
3. Для аудитора создать грант KMS с коротким временем жизни (TTL) и немедленно использовать токен гранта в сессии assume-role аудитора, чтобы разрешить временные операции расшифровки без изменения политики ключа.
4. Переместить долгоживущие учетные данные в AWS Secrets Manager с ротацией на основе Lambda, привязанной к базовому сервису (RDS или ключи API), и хранить инфраструктурные параметры как SecureString в Systems Manager Parameter Store для неротируемых элементов, применяя шифрование с помощью CMK и строгие политики на основе ресурсов.
5. Реализовать конвертное шифрование для больших объектов S3, вызывая GenerateDataKey (Encrypt/Decrypt) из KMS в коде приложения или через AWS SDK, и включить S3 Bucket Keys для сокращения количества запросов к KMS и затрат на шифрование больших объектов на стороне сервера.
6. Включить логирование CloudTrail и логирование использования ключей KMS, а также создать правила CloudWatch Alarms/GuardDuty для оповещения о неожиданных операциях расшифровки или создания грантов.

Обоснование: Этот подход обеспечивает доступ к ключам по принципу наименьших привилегий, сохраняет соответствие требованиям для импортированного материала и обеспечивает мультирегиональную непрерывность, использует временные гранты для безопасного доступа третьих сторон, централизует секреты с их ротацией и оптимизирует использование и стоимость KMS в соответствии с лучшими практиками AWS.

← Логирование · Все домены · Защита данных и S3 →

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

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