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.

Изоляция скомпрометированных инстансов EC2

Первоочередная операционная задача при подозрении на компрометацию инстанса EC2 — это его изоляция без уничтожения улик. Изоляция в AWS — это многоуровневый процесс, который затрагивает сетевую доступность инстанса, его привязки к жизненному циклу и доступность для специалистов по реагированию.

Каноническая последовательность действий по изоляции начинается с ужесточения правил группы безопасности инстанса. Поскольку в идеале у каждого инстанса есть своя выделенная группа безопасности, вы можете заменить правила для входящего и исходящего трафика на минимальный набор, разрешающий доступ только команде форензики (или специальной группе безопасности для диагностики). Если инстанс находится за Application Load Balancer или в целевой группе (target group), сначала отмените его регистрацию. Если он является частью группы Auto Scaling, отсоедините его с флагом --should-decrement-desired-capacity, чтобы ASG немедленно не запустила замену или, что ещё хуже, не завершила «неработоспособный» инстанс в середине расследования.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

Включение защиты от удаления (termination protection) крайне важно, так как оператор из лучших побуждений, скрипт автоматизации или событие сжатия ASG могут уничтожить те самые тома, которые вы пытаетесь сохранить. Защита от удаления не заменяет отсоединение от ASG — группа Auto Scaling всё равно может завершить защищённые инстансы во время сжатия, если вы не исключите инстанс из её состава.

Для изоляции на уровне подсети, когда требуется немедленно заблокировать исходящий трафик (например, если инстанс отправляет сигналы на известные вредоносные IP-адреса), вы можете добавить в сетевой ACL подсети явное запрещающее правило для всего исходящего трафика с наименьшим номером. Это правило работает без сохранения состояния и немедленно применяется ко всем потокам, в отличие от изменений в группах безопасности, которые влияют только на новые потоки. Как только путь доступа для форензики через диагностическую SG будет настроен, запрещающее правило в NACL можно удалить, чтобы подсеть специалистов по реагированию могла получить доступ к целевому инстансу через разрешающий список в SG.

Сохранение энергозависимых и энергонезависимых улик

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

Сбор энергозависимых улик должен быть автоматизирован с помощью скриптов и выполняться через SSM Run Command, а не человеком, вводящим команды в интерактивной оболочке. Run Command записывает вызов, параметры, исполнителя (principal) и вывод в CloudWatch Logs или S3, что само по себе становится частью записей для обеспечения цепочки ответственности.

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

Сценарий: Компания Meridian Financial запускает свои клиентские веб-приложения в одном аккаунте AWS в нескольких VPC, используя группы Auto Scaling за Application Load Balancers, инстансы EC2 с томами EBS, централизованное логирование через CloudTrail и CloudWatch, GuardDuty и архив логов на базе S3, зашифрованный с помощью KMS. Команда по операционной безопасности использует AWS Systems Manager для удалённого управления и хранит резервные копии и снимки в специальном аккаунте для восстановления.

Задача: Один из продакшен-инстансов EC2 демонстрирует признаки компрометации: подозрительный исходящий трафик и непредвиденная активность процессов. Команда должна изолировать инстанс и сохранить как энергозависимые (память), так и энергонезависимые (диск) улики для криминалистического анализа, не уничтожая при этом аудиторские следы.

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

Используйте API Auto Scaling и ELB, чтобы отсоединить инстанс от целевых групп и приостановить процессы Auto Scaling. Затем примените ограничивающую группу безопасности (запретить весь входящий/исходящий трафик) и обновите правила сетевого ACL инстанса, чтобы изолировать сетевой доступ, сохранив при этом управление через AWS Systems Manager Session Manager.
Используйте AWS Systems Manager Run Command для выполнения захвата памяти гостевой ОС (например, с помощью LiME), который записывает дамп ОЗУ на подключённый зашифрованный том EBS или напрямую в бакет S3, зашифрованный с помощью SSE-KMS и с включённой блокировкой объектов S3 (Object Lock) для удержания.
Используйте EC2 CreateSnapshot (или CreateImage) для создания мгновенных снимков EBS всех подключённых томов на определённый момент времени. Затем скопируйте эти снимки в отдельный аккаунт AWS или другой регион, чтобы обеспечить цепочку ответственности и предотвратить несанкционированное изменение.
Включите или получите данные VPC Traffic Mirroring для ENI инстанса, чтобы собирать захваченные пакеты на выделенный EC2 для мониторинга. Одновременно экспортируйте VPC Flow Logs, логи доступа ELB, данные CloudTrail, CloudWatch Logs и отчёты GuardDuty в защищённый архив S3.
Присвойте теги и инвентаризируйте все собранные артефакты в AWS Security Hub или системе тикетов. Убедитесь, что объекты S3 зашифрованы и для них установлена блокировка (Object Lock). Ограничьте доступ IAM для небольшой группы форензики, логируя все обращения через CloudTrail.

Обоснование: Изоляция сетевого доступа перед созданием образов предотвращает дальнейшее заражение, а использование SSM позволяет избежать открытия новых сетевых векторов. Сбор энергозависимой памяти в первую очередь, а также создание неизменяемых снимков EBS и защищённых архивов S3 обеспечивают целостность улик и цепочку ответственности в соответствии с лучшими практиками AWS по реагированию на инциденты.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Сразу после сбора энергозависимых улик создайте снимок каждого подключённого тома EBS. Присвойте снимкам тег с идентификатором инцидента, чтобы они были однозначно связаны с делом.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

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

Оперативное реагирование с помощью Session Manager и Run Command

Тонкий, но критически важный для экзамена момент: существующие SSH-сессии выдерживают удаление правил группы безопасности. Группы безопасности работают с отслеживанием состояния (stateful) и оценивают правила при установлении соединения; уже установленная TCP-сессия продолжает работать даже после удаления правила для входящего трафика, которое её разрешило. Если специалист по реагированию изолирует инстанс, удаляя правила SG, и при этом полагается на собственную SSH-сессию для доступа, эта сессия будет работать — до тех пор, пока не прервется. В этот момент он окажется заблокирован, и любой повторный вход через бастион или по ключу станет невозможен.

Правильный подход — предоставить команде криминалистов доступ через SSM Session Manager, который не требует открытия каких-либо входящих портов. Session Manager работает через исходящее соединение SSM Agent с эндпоинтами SSM, EC2 Messages и SSM Messages (в идеале — через VPC interface endpoints, чтобы изолированному инстансу не требовался маршрут в интернет). Прикрепите профиль инстанса (instance profile), разрешающий ssm:UpdateInstanceInformation и API для сообщений, и предоставьте специалистам по реагированию право ssm:StartSession, ограниченное тегом карантинного инстанса.

Поскольку сессии Session Manager управляются через control plane сервиса SSM, ужесточение или полное удаление входящих правил группы безопасности не влияет на них. При этом каждое нажатие клавиши может быть записано в S3 или CloudWatch Logs, обеспечивая аудируемую интерактивную сессию, а не «черный ящик».

Межаккаунтное восстановление зашифрованных снимков

В зрелых средах криминалистические снимки (snapshots) направляются в выделенный аккаунт для криминалистики, изолированный от скомпрометированного рабочего аккаунта. Для совместного использования снимков между аккаунтами требуется два условия: снимок должен быть предоставлен целевому аккаунту (modify-snapshot-attribute --create-volume-permission), и если снимок зашифрован управляемым клиентом ключом KMS (customer-managed KMS key), политика ключа KMS должна предоставлять принципалам аккаунта криминалистики права kms:Decrypt, kms:CreateGrant и kms:DescribeKey. Снимки, зашифрованные управляемым AWS ключом aws/ebs, нельзя передавать между аккаунтами — сначала их необходимо перешифровать с помощью CMK через операцию копирования. В аккаунте для криминалистики скопируйте предоставленный снимок и перешифруйте его с помощью локального CMK, чтобы последующее создание томов не зависело от исходного аккаунта.

Проектирование сценариев реагирования (Playbooks) и минимизация накладных расходов

Опишите шаги по сдерживанию в виде документа SSM Automation или рабочего процесса Step Functions, запускаемого по событиям от GuardDuty или Security Hub через EventBridge. Единая автоматизация должна: (1) собрать волатильные данные с помощью Run Command, (2) создать снимки томов с тегами инцидента, (3) включить защиту от удаления (termination protection), (4) отсоединить от ASG и отменить регистрацию в целевых группах ELB, (5) заменить SG на карантинную SG и (6) пометить инстанс тегом с ID заявки. Сохранение инстанса в рабочем состоянии сберегает «живые» улики и позволяет проводить интерактивное расследование через Session Manager. Выключение должно быть осознанным последующим шагом, а не частью автоматического сдерживания, поскольку оно уничтожает волатильные улики и может запустить логику очистки, встроенную во вредоносное ПО.

Ловушки, которые нужно усвоить: удаление правил SG с расчетом на существующую SSH-сессию оставляет специалиста по реагированию «слепым» и создает ложное чувство изоляции; выполнение исправления «на месте» до создания снимка уничтожает артефакты, которые отвечают на вопрос, как произошло вторжение; а оставление инстанса в его ASG или целевой группе может привести к автоматическому удалению или, что еще хуже, к тихой замене, которая скроет масштаб инцидента.

Немедленное сдерживание

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

Два нативных средства контроля AWS работают на разных уровнях, и это различие имеет значение. Группы безопасности (Security groups) работают с отслеживанием состояния (stateful) и прикрепляются к эластичным сетевым интерфейсам (ENI); списки контроля доступа к сети (NACL) работают без отслеживания состояния (stateless) и прикрепляются к подсетям. Замена групп безопасности инстанса на заблокированную «карантинную» SG — это «хирургический» подход: он изолирует один ENI, не затрагивая другие рабочие нагрузки в той же подсети, и сохраняет состояние инстанса во время выполнения. Однако изменения в группах безопасности влияют только на новые потоки, поступающие на ENI, и если у скомпрометированного инстанса уже есть долгоживущие исходящие соединения, их состояние может сохраняться. Запрещающие правила NACL вступают в силу на границе подсети немедленно и могут блокировать трафик еще быстрее, когда скорость важнее хирургической точности — например, когда затронуто несколько инстансов в одной подсети или когда активную сессию злоумышленника необходимо прервать мгновенно. NACL также полезны, когда политики запрещают прямое изменение инстанса.

Каноническая карантинная SG разрешает нулевой входящий трафик и исходящий трафик только к VPC interface endpoints для com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages и com.amazonaws.<region>.ec2messages. Это сохраняет доступ через Systems Manager Session Manager, блокируя при этом каналы управления (C2), утечку данных и горизонтальное перемещение по сети.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Порядок сохранения улик

Криминалистическая ценность улик убывает от наиболее волатильных к наименее, поэтому порядок действий является строгим и не подлежит обсуждению:

Сначала включите защиту от прекращения работы (termination protection). Установка DisableApiTermination=true предотвращает уничтожение инстанса в середине расследования из-за события Auto Scaling, ошибки оператора или запланированного действия. Также отсоедините инстанс от его группы Auto Scaling, чтобы проверки работоспособности ASG не могли его заменить.
Отсоедините или защитите от Auto Scaling. Используйте EnterStandby или отсоедините инстанс, чтобы ASG не прекратила его работу из-за сбоя проверки работоспособности.
Создайте снимок каждого подключенного тома EBS. CreateSnapshot (или CreateSnapshots для атомарного захвата нескольких томов) создает неизменяемый, зашифрованный криминалистический артефакт. Добавьте к снимкам теги с идентификатором инцидента, ID исходного инстанса, временной меткой и именем аналитика. Скопируйте снимки в выделенный аккаунт для криминалистики, принадлежащий команде безопасности, чтобы они сохранились в случае компрометации основного аккаунта.
Сделайте дамп оперативной памяти. Используйте документ SSM RunCommand для вызова утилиты для сбора данных из памяти (LiME, AVML для Linux; WinPMEM для Windows) и потоковой передачи образа в бакет S3 для криминалистики с включенным Object Lock в режиме соответствия (compliance mode). Память необходимо захватывать, пока инстанс еще работает — у остановленного инстанса нет оперативной памяти для сбора.
Соберите метаданные. Запишите ID инстанса, AMI, профиль инстанса IAM, VPC/подсеть, ID ENI, теги, список запущенных процессов, вывод netstat и содержимое IMDS. Добавьте к инстансу теги Status=Quarantined и IncidentId=<id>, чтобы последующие средства автоматизации и операторы-люди распознавали его состояние.
Только после этого останавливайте инстанс, если расследование требует офлайн-анализа диска. Остановка стирает память, поэтому это всегда последний шаг.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Автоматизированные рабочие процессы реагирования на инциденты (IR)

Результаты проверок GuardDuty должны запускать изоляцию в течение секунд, а не часов. Каноническая схема: EventBridge → Lambda → SSM Automation, с использованием SNS для уведомлений.

Правило EventBridge срабатывает на source: aws.guardduty с detail-type равным GuardDuty Finding и шаблоном, фильтрующим типы находок, относящиеся к EC2, такие как UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* и CryptoCurrency:EC2/*.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

Целевая Lambda-функция извлекает ID инстанса из detail.resource.instanceDetails.instanceId, затем вызывает документ SSM Automation (или напрямую обращается к SDK) для: включения защиты от прекращения работы, замены групп безопасности ENI на карантинную SG с помощью ModifyNetworkInterfaceAttribute, создания снимков всех подключенных томов, добавления тегов к инстансу и публикации сообщения SNS в канал SOC. Использование SSM Automation вместо прямых вызовов SDK обеспечивает пошаговый аудиторский след в истории выполнения Automation.

Сбор логов для анализа эксфильтрации и C2

Изоляция без телеметрии — это работа вслепую. VPC Flow Logs должны быть включены на уровне VPC или подсети с типом трафика ALL (и ACCEPT, и REJECT). Записи REJECT выявляют сканирование, заблокированные попытки эксфильтрации и маячки C2, пытающиеся связаться с известными вредоносными IP; записи ACCEPT показывают, какие потоки были успешными. Направляйте потоковые логи в CloudWatch Logs для запросов в реальном времени и в S3 для долгосрочного хранения с Object Lock. CloudTrail с событиями данных (data events) для бакета S3 с криминалистическими данными и KMS обеспечивает аудиторскую цепочку для работы с уликами. Совмещайте это с логированием DNS-запросов (Route 53 Resolver), чтобы отлавливать DGA и DNS-туннелирование, которые одни только потоковые логи могут упустить.

Контролируемый криминалистический доступ через Session Manager

Session Manager устраняет необходимость в SSH-ключах, бастион-хостах или открытых портах 22/3389, и именно поэтому карантинная SG может блокировать весь традиционный доступ. Включите логирование сессий в бакет S3 с SSE-KMS и в CloudWatch Logs; установите EnforceEncryption=true в настройках сессии, чтобы ни одна сессия не запускалась без TLS и шифрования логов. Политики IAM для ssm:StartSession должны быть ограничены инстансами с тегом tag:Status=Quarantined и предоставляться только роли реагирования на инциденты.

Типичные ошибки и почему они неэффективны

Остановка или удаление инстанса в первую очередь. Остановка освобождает память, разрывает активные соединения и лишает возможности собрать волатильные артефакты. Удаление (terminate) дополнительно уничтожает корневой том, если не установлен флаг DeleteOnTermination=false, и даже в этом случае вы теряете состояние времени выполнения. Всегда изолируйте инстанс на месте перед любым изменением его состояния питания.
Полагаться только на группы безопасности, когда NACL работают быстрее. Изменения в SG точечные, но влияют только на тот ENI, к которому они привязаны, и управляют только новыми потоками данных. Когда затронуто несколько инстансов в одной подсети или когда необходимо немедленно прервать существующую исходящую сессию злоумышленника, запрещающее правило в NACL на уровне подсети закроет доступ быстрее, поскольку NACL работают без сохранения состояния (stateless) и блокируют каждый пакет независимо от его предыдущего состояния.
Устранение уязвимостей до создания снимков. Пересоздание образа, установка патчей или замена инстанса до создания снимков EBS уничтожает доказательства, находящиеся на диске: бинарные файлы вредоносного ПО, механизмы закрепления в системе, логи, временные метки. Снимки дёшевы и неизменяемы; создавайте их перед любыми действиями по устранению последствий и копируйте в выделенный аккаунт для криминалистического анализа, чтобы скомпрометированный рабочий аккаунт не мог их удалить.

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

Сценарий: Компания Meridian Financial использует мультиаккаунтную среду AWS с рабочими нагрузками в выделенном аккаунте: сервисы EC2 и EKS для хранения клиентских данных, бакеты S3 для архивов, централизованное логирование в аккаунте безопасности с включёнными CloudTrail, GuardDuty, Security Hub и Config, а также CI/CD-пайплайн для развёртывания. Их команда эксплуатации использует Systems Manager для установки патчей и обслуживания, а Route 53/ALB — для публичных эндпоинтов.

Задача: Находка GuardDuty и неожиданные всплески исходящего трафика указывают на вероятную компрометацию инстанса EC2, который участвует в эксфильтрации данных и выполняет подозрительные вызовы IAM API. Требуется немедленная изоляция с сохранением криминалистических доказательств и обеспечением аудируемого доступа для следователей.

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

Немедленно запустить изоляцию через EventBridge по событию от GuardDuty для вызова рабочего процесса Step Functions, который с помощью Lambda/SSM Automation применит карантинную группу безопасности, удалит публичные IP-адреса или отсоединит ENI, а также отзовёт/ротирует задействованные учётные данные IAM через сервис IAM.
Сохранить волатильные и постоянные доказательства, выполнив документ SSM Automation для создания снимка EBS и AMI инстанса, скопировать снимки в выделенный AWS-аккаунт для криминалистического анализа и сохранить экспортированные артефакты в бакете S3 с S3 Object Lock (в режиме compliance) и шифрованием KMS.
Собрать логи для анализа эксфильтрации и C2-коммуникаций, убедившись, что включены события управления и данных CloudTrail (для S3, Lambda), перенаправить VPC Flow Logs, логи доступа ALB/NGINX и логи запросов Route 53 в центральный аккаунт безопасности, а также передать находку в Amazon Detective для корреляции событий на временной шкале.
Автоматизировать оркестрацию и уведомления с помощью связки EventBridge -> Step Functions -> Lambda для координации изоляции, копирования доказательств, отправки SNS-уведомлений ответственным за инцидент и создания тикета в существующей ITSM-системе.
Обеспечить контролируемый криминалистический доступ, требуя использования AWS Systems Manager Session Manager для сессий расследования в реальном времени с логированием сессий в CloudWatch Logs и в S3-бакет для криминалистики. Доступ должен быть разрешён только выделенной IAM-роли для криминалистики с использованием MFA и временных учётных данных.

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

← Безопасность контейнеров и Serverless · Все домены

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