Amazon SCS-C02: Логирование, аудит и криминалистика — Руководство по подготовке

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

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

Результаты и устранение угроз в Amazon GuardDuty

GuardDuty — это управляемый сервис для обнаружения угроз, который незаметно для пользователя непрерывно собирает три потока телеметрии: события управления CloudTrail (и опционально события данных S3), логи VPC Flow Logs и логи DNS-запросов Route 53. Вам не нужно отдельно включать, доставлять или оплачивать эти источники логов, чтобы GuardDuty мог их использовать — сервис напрямую считывает дублирующий поток данных. Именно поэтому GuardDuty можно включить одним вызовом API, и он начнет генерировать результаты в течение нескольких минут без необходимости настраивать конвейер обработки логов.

Результаты имеют уровень серьезности от 0.1 до 8.9, который соответствует уровням Низкий (Low, 0.1–3.9), Средний (Medium, 4.0–6.9) и Высокий (High, 7.0–8.9). Типичные результаты, требующие действий, включают UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B и Recon:IAMUser/MaliciousIPCaller. Сценарии реагирования зависят от типа результата: компрометация на базе EC2 обычно требует изоляции инстанса с помощью карантинной security group, создания снэпшотов томов для криминалистического анализа и его последующего удаления; результат, связанный с IAM, требует смены ключей доступа и проверки недавней активности субъекта в CloudTrail.

Для инфраструктуры с несколькими аккаунтами включайте GuardDuty через AWS Organizations и назначьте аккаунт делегированного администратора (обычно это аккаунт Security Tooling). Делегированный администратор может автоматически включать GuardDuty в каждом существующем и новом аккаунте-участнике во всех регионах, где сервис активирован. Без конфигурации с делегированным администратором результаты GuardDuty для каждого аккаунта остаются изолированными в нем — включение детекторов по отдельности не приводит к их централизованной агрегации.

AWS Security Hub и агрегация между аккаунтами

Security Hub — это слой нормализации и агрегации. Он собирает результаты из GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config и десятков партнерских продуктов, преобразуя их в формат AWS Security Finding Format (ASFF). Он также выполняет собственные проверки на соответствие стандартам, таким как CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS и NIST 800-53.

Межрегиональная агрегация между аккаунтами работает так же, как и в GuardDuty: зарегистрируйте Security Hub у делегированного администратора Organizations, затем назначьте регион агрегации, чтобы результаты из других регионов реплицировались в эту единую панель. Распространенная ошибка — включать Security Hub в каждом аккаунте и ожидать консолидированного представления. Без делегированного администратора и региона агрегации каждый аккаунт по-прежнему видит только свои собственные результаты.

Security Hub сам по себе не отправляет электронные письма. Уведомления и автоматизация настраиваются путем сопоставления событий о результатах Security Hub на шине событий EventBridge по умолчанию и их перенаправления в SNS, Lambda, Step Functions или документы Systems Manager Automation.

CloudTrail: события управления и события данных

CloudTrail записывает две категории действий, и их путаница — это самый распространенный пробел в покрытии обнаружения угроз.

События управления (Management events): операции на уровне плоскости управления — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Включены по умолчанию для любого нового трейла.
События данных (Data events): высокообъемные операции на уровне ресурсов — вызовы на уровне объектов S3 (GetObject, PutObject, DeleteObject, PutObjectAcl), вызов Invoke для Lambda, вызовы API на уровне элементов DynamoDB. Отключены по умолчанию и тарифицируются отдельно.

Если требование безопасности гласит «обнаруживать, когда кто-то делает объект S3 публичным с помощью PutObjectAcl», обычный трейл для событий управления не зафиксирует это, потому что изменения ACL для отдельных объектов являются событиями данных. Аналогично, выгрузка данных с помощью GetObject из конфиденциального бакета невидима без событий данных. PutBucketAcl (на уровне бакета) — это событие управления, и оно будет записано в лог; PutObjectAcl (на уровне объекта) — нет.

Используйте организационный трейл (organization trail), созданный в управляющем аккаунте или аккаунте делегированного администратора, чтобы события из всех аккаунтов-участников собирались в одном бакете S3 и не могли быть отключены субъектами в аккаунтах-участниках. Защитите трейл с помощью:

Шифрования SSE-KMS для целевого бакета с политикой ключа KMS, которая запрещает несанкционированную расшифровку.
Политики бакета, которая запрещает s3:PutObject без сервисного субъекта CloudTrail и запрещает удаление.
Включенной проверки целостности файлов логов, которая ежечасно создает файлы дайджестов, подписанные с помощью SHA-256, что позволяет доказать факт подделки.

Пример создания:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

Оповещения через EventBridge и SNS

EventBridge — это фабрика маршрутизации, которая связывает результаты с людьми и автоматизированными системами реагирования. Каждый результат GuardDuty, каждое обновление результата Security Hub и каждое событие, полученное из CloudTrail, попадает на шину событий по умолчанию. Правила используют шаблоны событий в формате JSON для фильтрации, а затем разветвляют их на одну или несколько целей (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Канонический шаблон для результатов GuardDuty с высоким уровнем серьезности, перенаправляемых как в топик SNS для отправки по электронной почте, так и в поток доставки Firehose, питающий OpenSearch для аналитики:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

Для КРИТИЧЕСКИХ (CRITICAL) результатов Security Hub, направляемых по электронной почте:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Конечная точка для электронной почты — это простая подписка SNS; подписчик должен подтвердить подписку по ссылке в письме, прежде чем начнется доставка. Одно правило может иметь до пяти целей, поэтому оповещение и последующая аналитика не требуют дублирования правил.

При составлении шаблонов помните, что события управления CloudTrail приходят с "detail-type": "AWS API Call via CloudTrail", в то время как события данных не появляются на шине по умолчанию, если вы не настроите трейл, который публикует данные в CloudWatch Logs, и не используете метрический фильтр или не подпишетесь через интеграцию EventBridge для событий данных CloudTrail. Создание правила EventBridge, соответствующего "eventName": "PutObjectAcl" на шине по умолчанию без включения событий данных, не даст никаких совпадений.

CloudWatch Logs, Insights, фильтры метрик и оповещения

Отправка логов CloudTrail (а также VPC Flow Logs и логов приложений) в CloudWatch Logs обеспечивает обнаружение угроз почти в реальном времени. Фильтры метрик сканируют каждое входящее событие в логах на соответствие шаблону и увеличивают значение пользовательской метрики CloudWatch; оповещение CloudWatch по этой метрике запускает SNS.

Пример: оповещение о повторяющихся неудачных попытках входа в консоль.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights предоставляет возможность выполнять произвольные запросы с помощью специализированного языка запросов, что полезно для реагирования на инциденты после срабатывания оповещения:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

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

Отсутствие данных об активности на уровне объектов S3: PutObjectAcl, GetObject и DeleteObject — это события данных. Trail по умолчанию записывает только события управления; необходимо добавить селекторы событий данных, иначе правило поиска, оповещение или правило EventBridge, нацеленное на эти имена API, никогда не сработает, причём без каких-либо уведомлений.
Централизованный обзор без делегированного администратора: включение GuardDuty или Security Hub в каждом аккаунте не приводит к агрегации результатов. Результаты поиска собираются централизованно только после регистрации делегированного администратора в AWS Organizations и, для Security Hub, выбора региона агрегации. Приглашения между аккаунтами подходят для небольших инфраструктур, но плохо масштабируются и требуют подтверждения в каждом аккаунте.
Путаница между событиями управления и данных в фильтрах: PutBucketAcl (бакет) — это событие управления, и оно будет работать в любом стандартном фильтре EventBridge или фильтре метрик; PutObjectAcl (объект) — нет, независимо от того, насколько хорошо составлен шаблон, если только события данных не включены и не доставляются в тот же конвейер.

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

Сценарий: Meridian Financial использует AWS Organization с несколькими аккаунтами, включая выделенный аккаунт для безопасности и аккаунт для централизованного сбора логов. Их инфраструктура содержит персональные данные клиентов (PII) в S3, транзакционные API на EC2/Lambda, а CloudTrail уже записывает события управления в центральный бакет S3. Команды хотят ускорить обнаружение угроз и обеспечить скоординированное реагирование между аккаунтами.

Проблема: Инженеры по безопасности обнаружили внезапный всплеск запросов GET к S3 и связанные с этим находки GuardDuty, указывающие на возможную утечку данных. Однако оповещения создают много шума, им не хватает контекста из CloudTrail и автоматических мер по сдерживанию угрозы между аккаунтами.

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

Включить Amazon GuardDuty в каждом аккаунте-участнике и назначить аккаунт безопасности делегированным администратором GuardDuty; включить защиту событий данных S3, чтобы находки включали аномалии доступа на уровне объектов.
Настроить CloudTrail в каждом аккаунте для доставки событий управления в центральный бакет S3 для хранения и для пересылки избранных ценных событий данных (S3 GetObject/PutObject/DeleteObject и Lambda Invoke) в CloudWatch Logs в аккаунте безопасности для анализа с низкой задержкой.
Включить AWS Security Hub в аккаунте безопасности и активировать меж-аккаунтную агрегацию с аккаунтами-участниками, чтобы находки GuardDuty, находки на основе данных CloudTrail и результаты Config/Inspector были централизованы и нормализованы.
Создать правила EventBridge, которые отбирают находки GuardDuty и Security Hub с высоким уровнем серьезности и направляют их в SNS для уведомлений на пейджер и в Lambda-функцию для исправления, которая использует контекст CloudTrail для принятия мер по сдерживанию (отзыв ключей API, удаление сессии IAM, изоляция ENI для EC2).
Добавить фильтры метрик CloudWatch Logs для аномальной частоты вызовов s3:GetObject в разрезе IAM-субъектов и оповещение, которое запускает тот же конвейер EventBridge/SNS/Lambda; использовать запросы CloudWatch Logs Insights в аккаунте безопасности для обогащения оповещений связанными событиями CloudTrail для анализа инцидентов.

Обоснование: Централизация находок (GuardDuty + Security Hub) и отправка целевых событий данных CloudTrail в CloudWatch обеспечивают корреляцию с низкой задержкой, оповещения и автоматическое сдерживание через EventBridge/SNS/Lambda, что соответствует лучшим практикам AWS по обнаружению, меж-аккаунтной агрегации и автоматическому реагированию.

Централизованный CloudTrail и целостность логов

CloudTrail — это авторитетный источник записей о действиях с AWS API, и основой любой архитектуры аудита является единый мультирегиональный trail, который доставляет логи в один централизованный бакет S3, в идеале — в выделенный аккаунт для архивации логов в рамках AWS Organizations. Мультирегиональный trail автоматически записывает события управления в каждом текущем регионе и в любом регионе, который AWS запустит в будущем. Trail для одного региона создает слепые зоны в тот момент, когда рабочая нагрузка запускается где-то еще, что является классической ошибкой неполноты данных при аудитах. При применении на уровне организации trail также записывает события каждого аккаунта-участника, поэтому новый аккаунт, присоединяющийся к организации, покрывается без какой-либо дополнительной настройки.

Включите проверку целостности файлов логов для trail. После этого CloudTrail будет каждый час доставлять в тот же бакет S3 подписанный файл-дайджест, содержащий хеши SHA-256 доставленных файлов логов. Команда aws cloudtrail validate-logs проходит по цепочке дайджестов и обнаруживает подделку, удаление или пропуски. Без проверки защищающаяся сторона не сможет доказать, что логи не были изменены после инцидента, что делает их недействительными в качестве улик для расследования.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Сбои доставки почти всегда являются проблемами с разрешениями на стороне получателя, а не ошибками CloudTrail. Бакет S3 должен существовать до создания trail, его политика должна предоставлять разрешение s3:PutObject сервису cloudtrail.amazonaws.com с условием aws:SourceArn, соответствующим trail, а владелец объекта должен быть владельцем бакета (bucket-owner-full-control). Если trail использует SSE-KMS, политика CMK должна разрешать kms:GenerateDataKey* для сервис-принципала CloudTrail, и каждый потребитель (Athena, инженеры по безопасности, парсеры Lambda) должен иметь разрешение kms:Decrypt для этого ключа. Распространенный сценарий сбоя: логи доставляются нормально, но запросы Athena возвращают “AccessDenied”, потому что у роли, выполняющей запрос, отсутствует разрешение Decrypt для CMK, которым зашифрованы логи. Это нужно исправлять в политике ключа, а не отключать шифрование.

Логи CloudWatch, метрические фильтры и оповещения в реальном времени

CloudTrail доставляет данные в S3 пакетами с задержкой от 5 до 15 минут — этого достаточно для ретроспективного аудита, но слишком медленно для обнаружения в реальном времени. Для оповещения о чувствительных событиях передавайте trail в CloudWatch Logs (это опция trail) или направляйте определённые события через EventBridge. Подход с CloudWatch Logs использует метрические фильтры (metric filters), которые сопоставляют события JSON с шаблоном и инкрементируют метрику CloudWatch, что, в свою очередь, запускает оповещение CloudWatch Alarm и уведомление SNS. Канонический пример — вход в консоль под root-пользователем:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge часто лучше подходит для узконаправленных, хорошо известных событий (отключение ключа KMS, изменения политик IAM), поскольку его правила могут напрямую запускать Lambda или Step Functions без затрат на Logs. Используйте метрические фильтры, когда вам нужны агрегированные счётчики или визуализация на дашбордах.

Срок хранения (retention) в CloudWatch Logs по умолчанию установлен на Never Expire (Никогда не истекает), что дорого и редко является правильным выбором. Установите явный срок хранения для каждой лог-группы (aws logs put-retention-policy) в соответствии с требованиями комплаенса — обычно это 90 дней «горячего» хранения в CloudWatch с долгосрочным архивированием в S3 через фильтр подписки (subscription filter) или Kinesis Data Firehose.

Для гигиены чувствительных данных применяйте политики защиты данных CloudWatch Logs (data protection policies) на уровне аккаунта. Они используют управляемые идентификаторы данных (номера кредитных карт, секретные ключи AWS, SSN) для маскирования совпадающих строк при приёме данных (ingestion). Ключевой момент: для снятия маски требуется разрешение logs:Unmask; предоставляйте его только роли типа break-glass. Пользователи, которые могут читать лог-группу, но не имеют разрешения Unmask, видят только звёздочки. Политика на уровне аккаунта применяется ко всем текущим и будущим лог-группам, что является правильным подходом — политики для отдельных групп со временем расходятся, так как новые сервисы создают новые группы.

Запросы к логам в большом масштабе: Insights и Athena

Два движка запросов предназначены для разных уровней данных.

CloudWatch Logs Insights запрашивает данные, уже находящиеся в CloudWatch Logs, используя специализированный язык запросов. Идеально подходит для оперативных данных за недавний период (логи Lambda, VPC Flow Logs в Logs, логи приложений). Работает быстро, не требует настройки схемы, но ограничен сроком хранения в CloudWatch и стоимостью за сканированный гигабайт.
Amazon Athena выполняет SQL-запросы (Presto/Trino) к данным в S3. Идеально подходит для масштабных криминалистических запросов к данным CloudTrail, логам доступа ALB, VPC Flow Logs, хранящимся в S3, и логам CloudFront. Стоимость составляет 5 долларов за терабайт сканированных данных; используйте проецирование разделов (partition projection) или разделы Glue по дате/региону, чтобы резко сократить стоимость сканирования.

Типичный пример криминалистического анализа: определение того, кто отключил ключ KMS. Поскольку JSON в CloudTrail имеет вложенную структуру, созданная для CloudTrail таблица Athena представляет userIdentity как структуру (struct):

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

Для анализа ботов на ALB включите логи доступа ALB в S3, определите таблицу Athena над префиксом логов, затем выполните join с таблицей известных вредоносных IP-адресов и визуализируйте агрегацию в QuickSight. QuickSight читает данные из Athena, поэтому конвейер выглядит так: ALB → S3 → Athena → QuickSight. Отправка логов ALB в CloudWatch Logs Insights не является нативно поддерживаемым путём — логи ALB направляются только в S3.

VPC Flow Logs можно направлять в любое из этих мест: выбирайте Logs для тактических расследований типа filter dstPort=3389 and action="REJECT", а S3 (в формате Parquet, с партиционированием) — для анализа трендов за несколько месяцев.

Сбор доказательств с помощью Audit Manager

AWS Audit Manager автоматизирует непрерывный сбор доказательств, сопоставленных с такими стандартами (фреймворками), как PCI DSS, HIPAA, SOC 2 и CIS. Он извлекает доказательства из правил Config, находок Security Hub, событий CloudTrail и инвентаризации ресурсов, а затем упаковывает их в оценки контролей (control assessments). Когда Audit Manager включён в управляющем аккаунте Organizations или в аккаунте делегированного администратора, он собирает данные со всех аккаунтов-участников, создавая отчёт об оценке — zip-архив с доказательствами и манифестом, который аудиторы принимают вместо скриншотов, сделанных вручную. Это правильный ответ, когда в сценарии требуется непрерывный, многоаккаунтный, соответствующий стандартам сбор доказательств: Config сам по себе даёт только соответствие ресурсов, но без привязки к стандартам; Security Hub предоставляет находки, но без упаковки в отчёт об оценке; самодельный отчёт на базе Athena не является непрерывным.

← Обнаружение угроз и оповещение · Все домены · Шифрование →

Отработать эти вопросы → · Тесты на время на 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 →