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

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

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

Этот раздел охватывает элементы управления, сервисы и операционные шаблоны, которые обеспечивают защиту, аудируемость и соответствие требованиям для данных, одновременно позволяя выполнять аналитику. Инженеры данных должны проектировать шифрование, контроль доступа, обнаружение и маскирование данных таким образом, чтобы аналитические рабочие процессы выполнялись без раскрытия персональных данных (PII) и нарушения интеграции сервисов. Нижеследующий раздел посвящен конкретным сервисам и конфигурациям AWS — шифрованию в S3/Redshift, KMS, IAM и политикам ресурсов, детализированному контролю доступа в Lake Formation, обнаружению с помощью Macie и сетевым элементам управления, таким как VPC-эндпойнты, — а также критериям принятия решений, которые вы будете использовать при проектировании конвейеров.

Шифрование неактивных данных и данных при передаче для сервисов данных

Шифруйте данные при передаче с помощью TLS для всех конечных точек сервисов AWS и клиентских SDK; применяйте это требование с помощью конечных точек сервисов, ALB, API Gateway и требования HTTPS в политиках бакетов S3. Для шифрования неактивных данных в S3 выбирайте между SSE-S3, SSE-KMS, SSE-C или шифрованием на стороне клиента со следующими компромиссами и шаблонами для CLI/консоли:

• SSE-S3 (AES-256, управляемый AWS): самый простой; включите по умолчанию для бакета с помощью

undefined

.

• SSE-KMS (ключи AWS KMS): поддерживает ротацию ключей, политики IAM и ключей KMS, а также аудит через CloudTrail; установите по умолчанию для бакета SSE-KMS и укажите –sse-kms-key-id. Требует предоставления сервисам и субъектам доступа как через разрешения IAM, так и через политику ключа KMS (см. примечание о политике ключа KMS ниже).
• SSE-C (ключи, предоставляемые клиентом): клиент предоставляет ключ при каждом запросе; KMS не используется; операционная сложность в передаче ключей и обработке их компрометации.
• Шифрование на стороне клиента: шифрование перед загрузкой с использованием AWS Encryption SDK или клиентских библиотек для конвертного шифрования; ключи управляются клиентом или через кастомное использование KMS. Используйте, когда необходимо сохранять полный контроль над незашифрованным ключевым материалом.

Критерии принятия решений:

• Используйте SSE-S3 для снижения операционных издержек и когда не требуются ключи, управляемые клиентом.
• Используйте SSE-KMS для аудируемости, ротации ключей и при совместном использовании зашифрованных снимков между аккаунтами или сервисами.
• Используйте SSE-C или шифрование на стороне клиента, когда необходимо гарантировать, что AWS никогда не будет иметь доступа к незашифрованному тексту или ключевому материалу.

Шифрование в Redshift: включите шифрование при создании кластера, указав –encrypted и –kms-key-id или через консоль. Шифрование не может быть включено «на месте» для незашифрованного кластера; чтобы зашифровать существующий снимок кластера и восстановить его в новый зашифрованный кластер, используйте

undefined

или рабочий процесс RestoreFromClusterSnapshot с параметром –kms-key-id. Политика ключа KMS должна явно разрешать Redshift использовать ключ (kms:Encrypt, kms:Decrypt, kms:GenerateDataKey).

Для всех сервисов, использующих KMS, обеспечьте TLS при передаче и ограничьте раскрытие незашифрованного текста в логах и снимках.

Политики IAM и политики на основе ресурсов для доступа к данным

Политики на основе удостоверений IAM и политики на основе ресурсов (политики бакетов S3, политики ключей KMS, политики VPC-эндпойнтов) совместно определяют доступ. Конкретный подход:

• Используйте IAM-роли для субъектов вычислений/сервисов (EMR, Glue, Redshift, Lambda) и прикрепляйте политики с минимальными привилегиями, разрешающие необходимые действия в S3, Glue, Redshift и KMS.
• Используйте политики на основе ресурсов для ограничения доступа к бакетам S3 или API для определенных субъектов или VPC-эндпойнтов; применяйте явные запрещающие утверждения (Deny) с осторожностью, так как Deny имеет приоритет над Allow.
• Для доступа, ограниченного VPC, создайте шлюзовой VPC-эндпойнт для S3 и интерфейсные эндпойнты для Glue, KMS, Secrets Manager и контролируйте доступ с помощью политик эндпойнтов.

Шаблоны для CLI/консоли:

• Создание шлюзового эндпойнта:

undefined

• Создание интерфейсного эндпойнта для Glue:

undefined

Критерии принятия решений:

• Используйте политики ресурсов для применения меж-аккаунтных ограничений или для требования, чтобы трафик исходил из определенных VPC-эндпойнтов.
• Используйте IAM для разрешений, ориентированных на удостоверения, и политики ключей KMS для авторизации сервисов на использование ключей — одного лишь IAM недостаточно для разрешения использования KMS.

Детализированные разрешения в Lake Formation

Lake Formation централизует контроль доступа к озеру данных поверх Glue Data Catalog и обеспечивает безопасность на уровне столбцов и строк для Athena и заданий Glue. Ключевые шаблоны:

• Зарегистрируйте расположения S3 как расположения озера данных в Lake Formation и предоставьте разрешение DATA_LOCATION_ACCESS роли, которая читает/пишет в эти расположения.
• Предоставляйте разрешения на уровне таблиц и столбцов через консоль Lake Formation или с помощью

undefined

; разрешения на уровне столбцов используют параметр со списком столбцов и влияют на запросы Athena и Glue, использующие Data Catalog.

• Для безопасности на уровне строк определите LF-теги или фильтры строк для таблиц и прикрепите политики, которые применяют предикаты к данным, возвращаемым Athena. Фильтры на уровне строк оцениваются сервисом Lake Formation во время планирования запроса.

Операционные детали:

• Оцениваются как разрешения Lake Formation, так и разрешения IAM; применяется наиболее строгое из них. Убедитесь, что у заданий есть как доступ IAM-роли к S3, так и разрешения в Lake Formation.
• При использовании Athena установите для рабочей группы использование Glue Data Catalog и настройте расположение результатов запросов в S3 с надлежащим доступом LF.

Критерии принятия решений:

• Используйте элементы управления на уровне столбцов в Lake Formation, когда необходимо скрыть конфиденциальные столбцы от последующих аналитиков.
• Используйте политики на уровне строк для многопользовательских наборов данных, где предикаты строк должны ограничивать видимость в зависимости от субъекта.
• Продолжайте использовать IAM и политики бакетов S3 для крупнозернистого контроля (на уровне бакета/объекта) и Lake Formation для детализированного контроля на основе каталога.

← Запросы к данным и аналитика · Все домены · Мониторинг и устранение неполадок конвейеров данных →

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

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