Amazon SCS-C02: Безопасность контейнеров и Serverless — Руководство по подготовке

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

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

ECS Exec и инспекция среды выполнения без SSH

ECS Exec предоставляет интерактивную оболочку в работающем контейнере — включая задачи Fargate — без открытия доступа по SSH, использования бастион-хостов или публичных IP-адресов. Он работает на базе агента SSM, который AWS внедряет в среду выполнения сайдкара задачи. Поскольку нет демона SSH, ключей и входящего сетевого пути, который нужно защищать, операционные издержки минимальны, а каждая сессия подлежит аудиту через CloudTrail и (опционально) логируется в S3 или CloudWatch Logs.

Для работы ECS Exec должны быть выполнены три требования:

Разрешения роли задачи: роль задачи (не роль выполнения) требует разрешений ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, ssmmessages:OpenControlChannel и ssmmessages:OpenDataChannel. Роль выполнения только загружает образы и записывает логи; трафик SSM во время выполнения проходит через роль задачи, поскольку именно эту идентичность принимает процесс контейнера.
Конфигурация сервиса или задачи: сервис должен быть создан или обновлен с флагом --enable-execute-command. Этот флаг устанавливает enableExecuteCommand для новых задач; существующие задачи необходимо заменить.
Поддержка в образе контейнера: в образе контейнера должна присутствовать оболочка (/bin/sh или /bin/bash).

Типичный процесс инспекции выглядит так:

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

Из этой оболочки инженер может скопировать логи в S3, инициировать дамп кучи (heap dump) или прочитать /proc для расследования инцидентов. Альтернативные методы — попытка подключиться к контейнеру по SSH или перезапуск задачи для активации отладочного агента — либо не сработают на Fargate, либо уничтожат улики, которые вы пытались собрать.

Блокировка доступа к IMDS из контейнеров на EC2

Распространенное заблуждение заключается в том, что настройки hop-limit для IMDSv2 на инстансе EC2 защищают контейнеры на этом инстансе. Это не так, по крайней мере, по умолчанию в режимах сети bridge или host: контейнеры используют сетевое пространство имен хоста или NAT-мост и могут обращаться к 169.254.169.254 для получения учетных данных профиля инстанса, которые обычно имеют гораздо больше привилегий, чем роль задачи. Это полностью нарушает принцип наименьших привилегий.

Решение, когда миграция на Fargate невозможна, состоит из двух частей:

Используйте сетевой режим awsvpc для задач. Каждая задача получает собственный ENI и сетевое пространство имен. Трафик IMDS больше не может прозрачно достигать link-local эндпоинта хоста.
Установите ECS_AWSVPC_BLOCK_IMDS=true в файле /etc/ecs/ecs.config на инстансе контейнера. Это указывает агенту ECS установить правило iptables, которое отбрасывает пакеты от задач в режиме awsvpc, предназначенные для 169.254.169.254.

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

Совместите это с минимальным профилем инстанса (по сути, только то, что нужно агенту ECS: AmazonEC2ContainerServiceforEC2Role) и IAM-ролями для каждой задачи для разрешений приложения. Установка hop-limit для IMDS инстанса в 1 с обязательным использованием IMDSv2 является полезной мерой глубокоэшелонированной защиты, но не заменой — контейнеры в режиме bridge все еще могут достичь IMDS с hop-limit 1, потому что запрос исходит от хоста.

GuardDuty Runtime Monitoring, EKS Protection и логи Control Plane

GuardDuty предлагает многоуровневое обнаружение угроз в контейнерах:

EKS Protection анализирует аудит-логи EKS для обнаружения подозрительной активности в Kubernetes API — анонимного доступа, создания привилегированных подов, выполнения команд (exec) в системных подах.
Runtime Monitoring развертывает сенсор на основе eBPF (в виде управляемого дополнения для EKS или агента под управлением SSM для ECS/Fargate), который отслеживает активность процессов, файлов и сети внутри контейнеров. Он выявляет такие угрозы, как обратные оболочки (reverse shells), бинарные файлы для криптомайнинга и утечку учетных данных из пода или задачи.

EKS Protection бесполезен, если аудит-лог control plane EKS фактически не отправляется в CloudWatch Logs. Включите как минимум типы логов audit и authenticator на кластере:

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Без этого у GuardDuty не будет данных для анализа и выявления угроз с помощью EKS Protection — это частая ловушка, когда операторы включают функцию GuardDuty, но оставляют конфигурацию логирования кластера выключенной, а затем удивляются, почему не появляются находки, связанные с Kubernetes.

Сканирование образов с помощью ECR Enhanced Scanning

ECR Enhanced Scanning работает на базе Amazon Inspector и обеспечивает непрерывное сканирование образов контейнеров на наличие CVE в ОС и пакетах языков программирования (Python, Node, Java, Go, Ruby). Базовое сканирование является однократным (во время push) и охватывает только пакеты ОС; расширенное сканирование является непрерывным и включает зависимости приложений, где и находится большинство современных уязвимостей.

Результаты сканирования автоматически поступают в Security Hub, если оба сервиса включены, что обеспечивает единое окно для контроля соответствия требованиям и позволяет создавать правила EventBridge, которые прерывают сборки в CI/CD. Типичный сценарий принудительного контроля:

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

Сценарий: Корпорация NovaTech Corp использует клиентские микросервисы в смешанной вычислительной среде: несколько кластеров ECS на EC2, кластер EKS для обработки данных и бессерверные функции Lambda для обработки событий. Образы хранятся в ECR, для доступа к хостам используется SSM, а GuardDuty и CloudWatch включены, но видимость компонентов контейнеров и уровня управления неравномерна.

Проблема: В рабочем контейнере были обнаружены подозрительные исходящие соединения, и инженер выяснил, что под мог получить доступ к сервису метаданных экземпляра EC2, что создавало риск утечки учетных данных. Уязвимости в образах и недостаточное логирование уровня управления могут скрывать первопричину.

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

Включить ECS Exec для задач и требовать использования AWS Systems Manager Session Manager для инспекции хоста и среды выполнения контейнеров (ECS Exec + SSM), что устраняет необходимость в SSH и обеспечивает логирование сессий в CloudTrail и CloudWatch Logs.
Принудительно включить IMDSv2 на экземплярах EC2 (Instance Metadata Service HttpTokens=required, hop limit=1) и применить сетевые правила на уровне хоста для блокировки доступа к 169.254.169.254 из сетевых пространств имен контейнеров, чтобы контейнеры не могли запрашивать метаданные экземпляра.
Включить мониторинг среды выполнения и защиту от вредоносных программ Amazon GuardDuty для контейнеров и Lambda, перенаправлять результаты в Security Hub и EventBridge для автоматического запуска сценариев сдерживания угроз.
Усилить безопасность EKS, включив логи уровня управления (audit, authenticator, controllerManager, scheduler) в CloudWatch Logs, внедрить IAM Roles for Service Accounts (IRSA) и применить средства контроля допуска (Pod Security или OPA Gatekeeper) для ограничения рискованных возможностей.
Активировать расширенное сканирование образов Amazon ECR (Inspector/ECR scanning) с функцией сканирования при отправке (scan-on-push) и интегрировать результаты в CI для блокировки/помещения в карантин образов через EventBridge + Lambda.
Централизовать телеметрию: отправлять данные CloudTrail, результаты GuardDuty, логи уровня управления EKS и результаты сканирования ECR в централизованный конвейер S3/Lambda/Security Hub и использовать их для правил AWS Config для непрерывного контроля соответствия.

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

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

Именно интеграция в конвейер превращает сканирование из простого просмотра дашбордов в реальный механизм контроля.

Lambda: авторизаторы, секреты и роли выполнения

Безопасность на уровне функции Lambda имеет три аспекта, которые часто путают:

Политика ресурса (политика функции): контролирует, какие участники (principals) (API Gateway, EventBridge, другие аккаунты) могут вызывать функцию. Авторизаторы Lambda в API Gateway служат шлюзом идентификации для HTTP-клиентов — они возвращают политику IAM, которую API Gateway кэширует и применяет перед вызовом бэкенд-функции.
Роль выполнения: идентификатор, который код функции принимает во время выполнения. Ее политика доверия (trust policy) должна включать lambda.amazonaws.com, и она должна предоставлять разрешения logs:CreateLogGroup, logs:CreateLogStream и logs:PutLogEvents для работы CloudWatch Logs. Если логи отсутствуют, проблема почти всегда в роли выполнения, а не в консоли Lambda, которая лишь отображает те логи, что получил CloudWatch. Полагаться только на «логи в консоли» — это диагностическая ловушка: нет разрешений у роли выполнения — нет потока логов, и консоль ничего не показывает.
Получение секретов: никогда не встраивайте учетные данные в переменные окружения в виде открытого текста. Храните их в Secrets Manager или SSM Parameter Store SecureString и извлекайте их при холодном старте:

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

Роли выполнения необходимы разрешения ssm:GetParameter и kms:Decrypt для ключа CMK. Кэшируйте их в области видимости модуля, чтобы при теплых вызовах избежать обращения к API; используйте расширение Secrets Manager для Lambda для автоматического кэширования с учетом ротации ключей в функциях с высокой пропускной способностью.

Шифрование и защита репозиториев в ECR

По умолчанию Amazon ECR шифрует все образы при хранении (at rest) с помощью AES-256 и ключа, управляемого AWS, однако для рабочих нагрузок, подпадающих под регулирование, обычно требуется ключ KMS, управляемый клиентом, чтобы ротация ключей, политики ключей и аудит через CloudTrail находились под контролем клиента. Шифрование с помощью KMS настраивается только во время создания репозитория; существующий репозиторий ECR нельзя переключить с AES-256 на KMS постфактум. Поэтому миграция требует создания нового репозитория с шифрованием KMS, репликации или повторной отправки образов, обновления всех последующих потребителей и удаления старого репозитория. Потребителям из других аккаунтов, извлекающим образы из репозитория, зашифрованного с помощью KMS, необходимо предоставить разрешение kms:Decrypt для ключа CMK в дополнение к разрешениям на чтение из ECR, в противном случае извлечение (pull) завершится ошибкой доступа KMS, даже если политика репозитория разрешает доступ этому участнику (principal).

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

Неизменяемые теги (immutable tags) предотвращают атаки с подменой тегов, когда проверенный тег v1.2.3 после сканирования незаметно перезаписывается вредоносным образом.

Сканирование образов: базовое, расширенное и с помощью Inspector

ECR предлагает два режима сканирования. Базовое сканирование использует открытую базу данных CVE Clair, запускается только при отправке образа (push) (или вручную) и возвращает результаты в консоли ECR. Оно бесплатно, но не выполняет непрерывное повторное сканирование, не охватывает одновременно пакеты ОС и языков программирования и не имеет нативной интеграции с Security Hub. Расширенное сканирование работает на базе Amazon Inspector и охватывает как пакеты операционной системы, так и пакеты языков приложений (Python, Java, Node.js, Go, Ruby, .NET). Inspector непрерывно отслеживает отправленные образы на предмет новых данных об уязвимостях, поэтому CVE, раскрытая через неделю после отправки образа, все равно приведет к появлению результата без необходимости пересборки.

Расширенное сканирование включается на уровне реестра (для каждого региона) с использованием фильтров включения для каждого репозитория, которые поддерживают шаблоны с подстановочными знаками, такие как prod-* или team-a/*. Это правильный способ для реализации распространенного требования «сканировать большинство репозиториев, но исключать ‘песочницы’ и экспериментальные» — вы определяете позитивные фильтры, перечисляющие, что должно сканироваться, а не негативные исключения для отдельных репозиториев.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Интеграция с Inspector и агрегация в Security Hub

Amazon Inspector должен быть включен в каждом аккаунте и регионе, где требуется сканирование. В среде AWS Organizations аккаунт, предназначенный для инструментов безопасности, назначается делегированным администратором для Inspector, что позволяет ему включать сканирование, настраивать автоматическое включение для новых аккаунтов-участников и просматривать агрегированные результаты. Если забыть делегировать права или включить автоматическую регистрацию, возникает неочевидный сценарий сбоя: новые аккаунты, присоединяющиеся к организации, незаметно отправляют контейнеры в ECR, которые никогда не сканируются, что нарушает гарантии покрытия без каких-либо явных ошибок.

Результаты сканирования Inspector автоматически поступают в AWS Security Hub, когда оба сервиса включены и активирована интеграция Security Hub с Inspector. Затем Security Hub нормализует результаты в формат AWS Security Finding Format (ASFF), сопоставляет их с результатами GuardDuty, Macie и Config и — в сочетании с делегированным администратором Security Hub и межрегиональной агрегацией — представляет все данные на единой панели управления. Правила EventBridge для результатов Security Hub могут направлять критические CVE в Lambda для автоматического создания заявок, помечать проблемный образ меткой quarantine=true или блокировать развертывание через шлюз в конвейере.

Централизованное сканирование и межаккаунтный CI/CD

Рекомендуемый паттерн для контейнерных рабочих нагрузок в многоаккаунтной среде предполагает использование защищенного центрального аккаунта с реестром в качестве ядра:

Центральный аккаунт: содержит репозитории ECR, зашифрованные с помощью KMS, с включенным расширенным сканированием, неизменяемыми тегами и подписанием образов (через Notation/Sigstore, интегрированные с AWS Signer).
Аккаунты сборки: запускают задания CodeBuild/CodePipeline, которые собирают образы, отправляют их в центральный ECR, ожидают результатов от Inspector и блокируют развертывание на основе пороговых значений серьезности.
Аккаунты рабочих нагрузок (dev/stage/prod): загружают образы из центрального реестра, используя межаккаунтные разрешения.

Для межаккаунтного доступа на чтение требуются два уровня разрешений: IAM-политика в потребляющем аккаунте, предоставляющая права ecr:GetDownloadUrlForLayer, ecr:BatchGetImage и ecr:GetAuthorizationToken, а также политика репозитория в ECR в центральном аккаунте, разрешающая доступ конкретному аккаунту-потребителю или роли.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

Поскольку политики репозиториев ECR основаны на ресурсах, доступ определяется пересечением политики удостоверений и политики ресурсов — отсутствие любого из этих уровней приведет к ошибке AccessDeniedException. Если используется KMS, политика ключа KMS также должна предоставлять право kms:Decrypt межаккаунтному принципалу.

Логирование и наблюдаемость панели управления EKS

В EKS управляемая панель управления недоступна напрямую, поэтому важные для безопасности события Kubernetes становятся видимыми только тогда, когда явно включено логирование панели управления. Доступно пять типов логов: api, audit, authenticator, controllerManager и scheduler. Журнал audit является наиболее ценным артефактом безопасности — он записывает каждый вызов API к кластеру с идентификацией вызывающей стороны, определенной через аутентификатор IAM, — а authenticator записывает решения о сопоставлении IAM с RBAC Kubernetes. Все типы логов передаются в CloudWatch Logs в лог-группу /aws/eks/<cluster>/cluster, откуда их можно направить через Kinesis Data Firehose, переслать в S3 или отправить в SIEM.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

Дополняйте логи панели управления с помощью GuardDuty EKS Protection (обнаружение угроз времени выполнения на узлах) и используйте IRSA (IAM-роли для сервисных аккаунтов) вместо профилей инстансов узлов, чтобы в журналах аудита действия с AWS API были привязаны к конкретным подам.

Частые ошибки

Полагаться только на сканирование при отправке (scan-on-push): Базовое сканирование при отправке выявляет уязвимости, известные на момент push-операции, но ничего не делает с CVE, которые обнаруживаются позже в образах, уже находящихся в реестре. Фреймворки аудита, такие как PCI DSS и FedRAMP, требуют постоянной оценки уязвимостей, что обязывает использовать расширенное сканирование с частотой CONTINUOUS_SCAN и агрегацию в Security Hub. Снимок, создаваемый один раз при отправке, не соответствует этому требованию контроля.

Игнорирование KMS в ECR, когда требуется шифрование неактивных данных: Шифрование по умолчанию AES-256 является настоящим шифрованием, но режимы соответствия, требующие ключей, управляемых клиентом, записей о ротации ключей и журналов аудита kms:Decrypt для каждого участника, не могут быть удовлетворены ключами, принадлежащими AWS. Поскольку тип шифрования неизменяем для каждого репозитория, этот вопрос необходимо решать при его создании — вариант «мы включим это позже» невозможен без пересоздания репозитория.

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

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

Сценарий: Meridian Financial управляет много-аккаунтной средой AWS с производственными кластерами EKS, сервисами ECS и несколькими реестрами ECR, распределенными между средами prod, dev и выделенным аккаунтом безопасности. Их инженерные команды отправляют образы контейнеров через конвейеры CI/CD в ECR и развертывают их в EKS/ECS, в то время как команда безопасности поддерживает централизованный аккаунт для мониторинга и соответствия требованиям.

Проблема: Недавнее развертывание доставило в производственную среду контейнер с уязвимостью высокого уровня серьезности, которая не была обнаружена до этого. В ходе расследования выяснилось, что логи панели управления EKS ограничены, а результаты сканирования по разным аккаунтам фрагментированы, что замедлило устранение проблемы.

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

Включить защиту на уровне репозиториев ECR: обеспечить неизменяемость тегов образов, применить политики репозитория, ограничивающие push/pull для определенных IAM-ролей, и шифровать репозитории в состоянии покоя с помощью выделенного ключа, управляемого клиентом (CMK) в AWS KMS.
Включить сканирование образов при отправке (базовое) и активировать расширенное сканирование образов Amazon Inspector для ECR для получения отчетов об уязвимостях; интегрировать Inspector с AWS Security Hub для централизованной агрегации уровней серьезности по всем аккаунтам.
Реализовать централизованное меж-аккаунтное сканирование: настроить репликацию ECR или предоставить роли CodeBuild/CodePipeline из аккаунта безопасности меж-аккаунтные разрешения на pull, чтобы аккаунт безопасности сканировал каждый образ с помощью Inspector и любых дополнительных инструментов SCA/DAST, сохраняя артефакты в централизованный бакет S3, зашифрованный с помощью CMK аккаунта безопасности.
Внедрить проверку в CI/CD (gating): добавить в конвейер этап сканирования (CodeBuild/CodePipeline или GitHub Actions с STS assume-role), который запрашивает находки Inspector/Security Hub и автоматически блокирует или требует одобрения для образов с находками высокого/критического уровня.
Улучшить наблюдаемость EKS: включить отправку логов панели управления EKS (API, Audit, Authenticator, ControllerManager, Scheduler) в CloudWatch Logs в централизованный аккаунт для логирования, включить CloudTrail для событий API EKS и использовать Container Insights и GuardDuty для мониторинга во время выполнения.

Обоснование: Этот подход применяет многоуровневую защиту (defense-in-depth): шифрование и защита реестров, автоматизация расширенного сканирования с помощью Inspector, централизация находок в Security Hub для последовательного применения политик, контроль развертываний в CI/CD и включение логов панели управления EKS для быстрого обнаружения и расследования инцидентов. Все это соответствует лучшим практикам AWS по предоставлению минимальных привилегий и централизованному мониторингу.

← Уязвимости · Все домены · Реагирование на инциденты и криминалистика →

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