Amazon SCS-C02: Защита данных и S3 — Руководство по подготовке

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

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

Политики бакетов S3, ARN ресурсов и явные запреты (Explicit Deny)

Политика бакета S3 — это документ JSON на основе ресурсов, который оценивается вместе с политиками на основе удостоверений. В его поведении доминируют два правила. Во-первых, явный Deny всегда имеет приоритет: независимо от количества правил Allow, соответствующий Deny блокирует запрос. Во-вторых, элемент Resource должен точно соответствовать шаблону ARN для данного действия. Действия на уровне бакета, такие как s3:ListBucket, применяются к arn:aws:s3:::my-bucket, в то время как действия на уровне объектов, такие как s3:GetObject и s3:PutObject, применяются к arn:aws:s3:::my-bucket/*. Распространенная ошибка конфигурации — предоставление права s3:GetObject для arn:aws:s3:::my-bucket без суффикса /*. В этом случае вызов API нацелен на ARN объекта, ни одно правило не соответствует, и запрос отклоняется по умолчанию.

Следующая политика запрещает любой доступ без использования TLS и предоставляет права на чтение для определенной роли, корректно используя обе формы ARN.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

Частая ловушка — попытка «сделать исключение», добавляя Allow после широкого Deny. Правила в политике не чувствительны к порядку, и логика оценки IAM возвращает Deny, как только находит соответствующее правило запрета. Правильный способ исправления — сузить область действия Deny (например, с помощью NotPrincipal или Condition), а не добавлять разрешающее правило после него.

Правила жизненного цикла, истечение срока действия объектов и Vault Lock

Правила жизненного цикла S3 автоматизируют переходы между классами хранения и истечение срока действия объектов. Чтобы удовлетворить требования к хранению данных, например, удаление PII через 30 дней после загрузки, прикрепите правило, которое устанавливает срок действия для текущих версий объектов через 30 дней и вскоре после этого окончательно удаляет неактуальные версии. Для связанных метаданных, записываемых в DynamoDB, включите атрибут TTL DynamoDB, чтобы элементы удалялись самостоятельно по тому же расписанию. Комбинирование этих двух механизмов операционно эффективно, поскольку не требует Lambda, планировщика или самописного кода для очистки.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

Для архивированных данных с нормативными требованиями к хранению S3 Glacier Vault Lock предоставляет отдельный контроль WORM на уровне хранилища (vault). После фиксации политики Vault Lock (двухэтапный процесс initiate/complete, выполняемый в течение 24 часов) ее нельзя изменить даже root-пользователем аккаунта. Это отличается от Object Lock, который работает на уровне объектов S3.

Блокировка публичного доступа (Block Public Access) и CloudFront OAC

S3 Block Public Access (BPA) — это набор из четырех переключателей на уровне аккаунта и бакета, которые переопределяют любой ACL или политику, которые в ином случае предоставили бы публичный доступ. Включите все четыре на уровне аккаунта и примените принудительное правило с помощью SCP, например, запретив s3:PutBucketPublicAccessBlock, если это ослабит настройки. Эта глубокоэшелонированная оборона предотвращает случайное открытие доступа к бакету инженером через разрешающий ACL.

Для публичного контента, раздаваемого через CloudFront, правильным подходом является Origin Access Control (OAC). OAC подписывает запросы от CloudFront к S3 с помощью SigV4; политика бакета затем разрешает доступ только сервисному принципалу дистрибуции CloudFront. Использование CloudFront без OAC (или устаревшего OAI) оставляет URL-адрес S3 напрямую доступным, обходя средства контроля доступа и WAF сети CDN. Бакет должен оставаться приватным, BPA — включенным, а политика — ограниченной ARN дистрибуции:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock и межрегиональная репликация

Object Lock обеспечивает семантику WORM для отдельных объектов и требует, чтобы версионирование было включено, а Object Lock активирован при создании бакета (его нельзя добавить к существующему бакету позже без обращения в AWS). Существует два режима хранения:

Режим управления (Governance mode): привилегированные принципалы с правом s3:BypassGovernanceRetention могут сокращать или удалять срок хранения.
Режим соответствия (Compliance mode): ни один пользователь, включая root-пользователя аккаунта AWS, не может удалить, перезаписать объект или сократить его срок хранения до его истечения. Дополнительно может быть применено юридическое удержание (legal hold), которое может быть установлено и снято пользователями с правом s3:PutObjectLegalHold.

Режим соответствия — правильный выбор, когда требуется абсолютная неизменность для всех удостоверений. Чтобы распространить эту гарантию на другие регионы, используйте Object Lock в паре с S3 Replication. Реплицированные объекты сохраняют свою конфигурацию блокировки в целевом бакете (в котором также должен быть включен Object Lock), поэтому сбой в масштабе региона или попытка злонамеренного удаления не смогут скомпрометировать сохраненную копию.

Macie и Athena для обнаружения и расследования

Amazon Macie использует управляемые и пользовательские идентификаторы данных для сканирования объектов S3 на наличие PII, PHI, учетных данных и других конфиденциальных шаблонов. Он сообщает о находках в Security Hub и EventBridge, позволяя реализовать автоматизированное исправление, например, помещение объектов в карантин с помощью ограничивающей политики бакета на основе тегов. Включите Macie в каждом регионе, где хранятся данные клиентов, и делегируйте администрирование через AWS Organizations для централизованного сбора находок.

Amazon Athena предоставляет возможность выполнять бессерверные SQL-запросы к данным в S3 и является стандартным инструментом для запросов к событиям данных (data events) CloudTrail на уровне объектов. Чтобы расследовать, кто получал доступ к конкретному объекту S3, включите события данных CloudTrail для бакета, доставляйте журналы в центральный бакет S3 и выполняйте запросы с помощью Athena:

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

Сводка типичных ошибок и их первопричины

Отсутствие /* в ARN объектов. API-вызовы на уровне объектов проверяются по bucket/key, а не по ARN бакета. Без /* ни одно правило не сработает, и IAM вернет неявный отказ (implicit deny), что проявляется в виде неожиданных ошибок 403 при вызове GetObject, даже если доступ к «бакету» кажется разрешенным.
Добавление правила Allow после явного Deny. IAM не учитывает порядок правил; любое совпавшее правило Deny немедленно приводит к отказу. Решение — сузить область действия правила Deny (с помощью Condition, NotPrincipal или NotResource), а не добавлять разрешающие правила.
CloudFront без OAC или ограничивающей политики бакета. URL источника S3 остается доступным напрямую, в обход подписанных URL, правил WAF и геоблокировок. Всегда включайте BPA для бакета-источника и ограничивайте s3:GetObject для сервисного принципала CloudFront с помощью AWS:SourceArn.
Предположение, что Object Lock можно включить для существующего бакета. Object Lock необходимо настраивать при создании бакета. Для добавления этой функции потребуется создать новый бакет с включенным Object Lock и перенести данные.
Путаница между режимами governance и compliance. Режим governance не мешает привилегированному пользователю снять блокировку; только режим compliance блокирует даже root-пользователя.

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

Сценарий: Компания Meridian Financial хранит выписки клиентов, журналы транзакций и долгосрочные архивы для соответствия нормативным требованиям в нескольких бакетах S3 в двух регионах AWS. В их среде используется CloudFront для клиентских порталов, межпрофильного сбора логов и автоматического переноса данных в архивные классы хранения в соответствии с жизненным циклом для соблюдения нормативных сроков хранения.

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

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

Включить S3 Block Public Access на уровне аккаунта и бакета и развернуть CloudFront Origin Access Control (OAC); ужесточить политику бакета, чтобы разрешить GetObject только от принципала CloudFront OAC, используя точные ARN ресурсов, и добавить явные запреты для любых запросов, поступающих не через OAC.
Принудительно включить серверное шифрование с помощью AWS KMS, требуя kms:Encrypt/kms:GenerateDataKey в политике бакета, и добавить явные запреты для запросов PutObject, которые не содержат x-amz-server-side-encryption и требуемый kms:context, чтобы предотвратить незашифрованные загрузки.
Настроить S3 Object Lock в режиме compliance для бакетов, которые должны быть неизменяемыми, и включить Cross-Region Replication (CRR) с правилами репликации, которые сохраняют метаданные Object Lock, чтобы реплицированные объекты оставались неизменяемыми в регионе DR.
Создать правила жизненного цикла S3 для перемещения устаревших объектов в классы хранения S3 Glacier и установить срок действия объектов в соответствии с допустимыми периодами хранения; для архивов, которые должны быть юридически неизменяемыми, поместить их в хранилища Amazon S3 Glacier и применить политики Glacier Vault Lock для обеспечения однократной записи и запрета на изменение.
Развернуть Amazon Macie в разных аккаунтах для обнаружения и классификации PII, включить S3 Inventory и запрашивать результаты с помощью Amazon Athena для проведения расследований, а также запускать автоматическое исправление (Lambda/Step Functions) для того, чтобы помечать тегами, помещать в карантин или перемещать конфиденциальные объекты в заблокированные, зашифрованные бакеты.

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

Amazon Macie: автоматическое обнаружение, задания классификации и списки разрешений

Amazon Macie — это управляемый сервис безопасности данных, который использует машинное обучение и сопоставление с образцом для обнаружения конфиденциальных данных — персональных данных (PII), номеров платежных карт (PAN), учетных данных и пользовательских типов данных, определяемых регулярными выражениями, — хранящихся в Amazon S3. Macie работает в двух взаимодополняющих режимах, которые часто путают.

Автоматическое обнаружение конфиденциальных данных — это недорогой, постоянно работающий процесс, который выборочно проверяет объекты во всех бакетах аккаунта (или во всей организации, если Macie делегирован аккаунту безопасности). Он создает оценку конфиденциальности и инвентарный список для каждого бакета. Это правильная отправная точка, когда у вас тысячи бакетов и вы еще не знаете, где находятся конфиденциальные данные, поскольку это минимизирует затраты и административные издержки за счет выборочной проверки, а не сканирования каждого объекта.

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

Списки разрешений — это механизм для подавления заведомо ложных срабатываний. Если в озере данных содержатся синтетические тестовые PAN (например, известный диапазон тестовых карт 4111 1111 1111 1111), Macie будет помечать каждое вхождение. Перезапись или перемещение данных — это дорого и нарушает работу; правильный подход — определить список разрешений Macie (либо список точных значений в виде обычного текста, либо регулярное выражение) и связать его с вашими заданиями классификации и конфигурацией автоматического обнаружения. Совпадения со списком разрешений исключаются из результатов, в то время как подлинные PAN продолжают вызывать оповещения.

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

Сценарий: Meridian Financial управляет многоаккаунтной средой AWS с сотнями бакетов S3, в которых хранятся транзакционные логи, документы клиентов и долгосрочные архивы, перемещенные в S3 Glacier. Их команда безопасности использует базовое шифрование и логирование, но у них нет централизованного обнаружения конфиденциальных данных или единых правил хранения для всех аккаунтов.

Проблема: Недавно был обнаружен публично доступный бакет, содержащий архивные записи клиентов с персональными данными (PII). Это произошло из-за ошибочной политики бакета и жизненного цикла, переместившего данные в S3 Glacier. Meridian Financial необходимо найти все конфиденциальные данные, устранить уязвимости и обеспечить соответствие требованиям по хранению архивов в будущем.

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

Включить Amazon Macie для всей AWS Organization и активировать автоматическое обнаружение S3, чтобы Macie непрерывно оценивал бакеты и объекты на предмет наличия конфиденциальных данных и рискованных конфигураций.
Создать задания классификации Macie, нацеленные на все бакеты S3; настроить пользовательские идентификаторы конфиденциальных данных для номеров социального страхования и номеров счетов, а также настроить списки разрешений для исключения известных тестовых данных, файлов поставщиков и сервисных аккаунтов.
Использовать S3 Inventory для перечисления объектов в S3 Glacier, затем запустить S3 Batch Operations для временного восстановления только тех объектов, которые были отмечены inventory для сканирования Macie, чтобы задания классификации могли проверить содержимое, заархивированное в Glacier.
Автоматизировать устранение уязвимостей, отправляя находки Macie в Amazon EventBridge и Security Hub; запускать функции Lambda для применения безопасных политик бакетов S3, включения S3 Block Public Access, удаления публичных ACL и пометки бакетов тегами для проверки.
Внедрить долгосрочное хранение и превентивные меры: включить S3 Versioning и S3 Object Lock (в режимах governance/compliance) на критически важных бакетах, принудительно использовать SSE-KMS с CMK через политику бакета и развернуть SCP в AWS Organizations для блокировки публичных ACL и требования шифрования и Object Lock там, где это необходимо.
Включить события данных CloudTrail для S3 и передавать находки в SIEM для оповещений и периодического планирования заданий классификации Macie для обеспечения непрерывного покрытия.

Обоснование: Этот подход использует Macie для автоматического обнаружения и целевой классификации (со списками разрешений), восстанавливает объекты из Glacier только при необходимости для проверки, автоматизирует устранение уязвимостей через EventBridge/Lambda и обеспечивает неизменяемое хранение и шифрование с помощью Object Lock и KMS, что соответствует лучшим практикам AWS по обнаружению, устранению и превентивному контролю.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

Обработка необработанных находок Macie как абсолютной истины без настройки списков разрешений или подавления приводит к усталости от оповещений и может маскировать реальные инциденты в шуме от синтетических данных — именно поэтому просто «доверять находкам» является неверным подходом в средах с большим количеством ложных срабатываний.

Интеграция находок Macie с EventBridge

Macie публикует каждую находку в Amazon EventBridge с источником aws.macie. Это позволяет вам маршрутизировать находки без необходимости опрашивать API Macie. Типичное правило перенаправляет находки типа Policy в SNS для оповещения дежурной команды и отправляет находки SensitiveData в AWS Security Hub для агрегации.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Целями правила могут быть топики SNS, Security Hub или функция Lambda для пользовательского устранения уязвимостей (например, автоматического применения ограничивающей политики к проблемному бакету).

Условия в политиках бакетов для границ организации

S3 Block Public Access (BPA) блокирует только доступ из публичного интернета или от анонимных участников. Он не предотвращает доступ к бакету аутентифицированного участника из другого аккаунта AWS или другой AWS Organization, если политика бакета или ACL разрешает такой доступ. Поэтому полагаться только на BPA некорректно, когда требуется предотвратить межорганизационный доступ — необходимо сочетать политики бакетов с Service Control Policies (SCP) на уровне Organizations.

Два ключа условий IAM делают принудительное применение границ организации точным:

aws:ResourceOrgID: ID организации, которой принадлежит запрашиваемый ресурс. Используется в политиках удостоверений/SCP, чтобы запретить участникам доступ к ресурсам за пределами вашей организации.
aws:PrincipalOrgID: ID организации вызывающего участника. Используется в политиках бакетов, чтобы запретить доступ участникам из-за пределов вашей организации.
aws:SourceOrgPaths: путь к OU исходного участника, позволяющий ограничить область действия конкретным OU (например, только OU “Production” может записывать данные в бакет для соответствия требованиям).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

Совместите это с SCP, который запрещает s3:DeleteObject* для ресурсов, у которых aws:ResourceOrgID не совпадает с ID вашей организации, и межорганизационная эксфильтрация или удаление данных станут невозможными, даже если политика бакета будет случайно ослаблена.

S3 Object Lock: режимы Compliance и Versioning

Object Lock обеспечивает семантику однократной записи и многократного чтения (WORM) для отдельных версий объектов. Для этого требуется, чтобы на бакете было включено версионирование S3 (S3 Versioning) (использование Object Lock без версионирования невозможно — блокировка защищает конкретный ID версии, а не ключ).

Режим Governance (управление): пользователи с разрешением s3:BypassGovernanceRetention могут сокращать или отменять срок хранения. Подходит для обеспечения соблюдения внутренних политик.
Режим Compliance (соответствие): ни один участник, включая корневого пользователя аккаунта AWS, не может сократить, отменить или удалить версию объекта до истечения срока хранения. Это правильный выбор для выполнения требований регуляторов по неизменяемости данных (SEC 17a-4, FINRA, архивирование HIPAA).

Срок хранения можно установить для каждого объекта (дата Retain-Until) или через конфигурацию хранения по умолчанию на уровне бакета. Legal Holds (блокировки по юридическим причинам) — это отдельные бессрочные блокировки, которые действуют до тех пор, пока не будут явно сняты участником с разрешением s3:PutObjectLegalHold.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock: Исправление ошибок в политике до её фиксации

Vault Lock в S3 Glacier обеспечивает применение неизменяемых политик доступа к хранилищу. Процесс состоит из двух вызовов: initiate-vault-lock переводит политику в состояние in-progress с 24-часовым окном, а complete-vault-lock делает её постоянной. Если в течение этого 24-часового окна обнаруживается опечатка — например, слишком разрешающий Principal — правильным и самым дешёвым способом исправления будет:

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

Вызов abort-vault-lock бесплатно отменяет блокировку в состоянии in-progress, позволяя повторно инициировать процесс с исправленной политикой. Альтернативные «исправления» — удаление и повторное создание хранилища (что потребует удаления всех 10 ТБ архивов и их повторной загрузки, что повлечёт за собой расходы на извлечение и передачу данных) или ожидание завершения блокировки с последующими попытками её обойти — являются расточительными или невозможными. После выполнения complete-vault-lock политика становится неизменяемой навсегда; отмена возможна только в то время, пока блокировка находится в состоянии in-progress.

Смежная ловушка: Цепочка доверия DNSSEC

Распространённая междоменная ловушка связана с DNSSEC в Route 53. Включение подписи DNSSEC для размещённой зоны (hosted zone) поддомена генерирует ключ для подписи ключей (Key Signing Key, KSK) и соответствующую ему запись DS. Эта запись DS должна быть опубликована в родительской зоне; без неё разрешители (resolvers) не могут проверить цепочку доверия и либо считают ответы недействительными (bogus), либо откатываются к небезопасному разрешению имён, что нарушает работу DNS для клиентов, выполняющих проверку. Включение подписи без экспорта записи DS и её добавления у регистратора или в родительской зоне является состоянием неполной конфигурации, а не работающим развёртыванием DNSSEC.

← Шифрование · Все домены · Сетевое взаимодействие и безопасность VPC →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Сдайте экзамен →

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