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 Inspector: Расширенное сканирование в EC2, Lambda и ECR

Amazon Inspector — это непрерывный сервис для управления уязвимостями, работающий с помощью агента, который обнаруживает CVE в экземплярах EC2, образах контейнеров в ECR и функциях Lambda (как в коде приложения, так и в слоях с зависимостями). Включение Inspector на уровне аккаунта автоматически регистрирует подходящие ресурсы — процесса ручного включения для каждого ресурса не существует — а результаты сканирования (findings) автоматически отправляются в AWS Security Hub в стандартизированном формате ASFF, что является правильным паттерном интеграции, когда требуется централизованная панель мониторинга состояния безопасности.

Для EC2 Inspector использует гибридную модель сканирования. SSM Agent (с ассоциацией, предоставляемой AWS) собирает инвентарную информацию о программном обеспечении, которая используется для оценки сетевой доступности и пакетов в стиле безагентного сканирования, в то время как для глубокой оценки хоста требуется, чтобы агент был запущен и экземпляр был доступен через SSM. Вот почему подход «только безагентное сканирование» — это ловушка: без пути через SSM Agent (или глубокой инспекции на основе агента Inspector, где это необходимо) вы получаете поверхностные результаты — сетевая уязвимость и CVE, полученные из манифестов, — но упускаете инвентаризацию библиотек времени выполнения, неуправляемые пакеты и конфигурации. Гибридный режим — это то, что необходимо большинству производственных сред.

Для Lambda Inspector выполняет два типа сканирования: стандартное (уязвимости пакетов в слоях и зависимостях функции) и сканирование кода (статический анализ кода функции на предмет уязвимостей к инъекциям, жестко закодированных секретов и небезопасного использования API). Критически важное правило соответствия: Lambda-функция должна была быть вызвана хотя бы один раз за последние 90 дней, чтобы быть просканированной. Простаивающие или архивированные функции молча исключаются из области действия Inspector. Команды, которые полагают, что «раз Inspector включен, значит, все функции защищены», сталкиваются с проблемами, когда аудиторы запрашивают подтверждения по редко выполняемым функциям. Решение — либо вызывать функции по расписанию (с помощью EventBridge), либо принять это исключение и задокументировать его.

Для ECR расширенное сканирование (на базе Inspector) заменяет устаревшее базовое сканирование на основе Clair. Расширенное сканирование поддерживает как сканирование при отправке (scan on push), так и непрерывное сканирование образов, уже находящихся в реестре. Таким образом, новые обнаруженные CVE для ранее отправленных образов генерируют свежие результаты без повторной отправки образа. Включите расширенное сканирование на уровне реестра и настройте фильтры для каждого репозитория (например, prod/* — непрерывное, sandbox/* — только сканирование при отправке) для контроля затрат.

Делегированное администрирование и подавление результатов

В среде с несколькими аккаунтами в AWS Organizations назначьте аккаунт делегированного администратора для Inspector из управляющего аккаунта (management account). Делегированный администратор видит агрегированные результаты по всем аккаунтам-участникам и управляет конфигурацией сканирования для всей организации. Это позволяет избежать предоставления кросс-аккаунтных IAM-ролей для получения результатов и предотвращает антипаттерн, когда Inspector включается в каждом аккаунте по отдельности.

Правила подавления (suppression rules) позволяют команде безопасности отфильтровать шум, не удаляя сами результаты. Правило срабатывает по таким атрибутам, как тег ресурса, уровень серьезности, идентификатор CVE или репозиторий ECR. Чтобы скрыть результаты сканирования Lambda-функций из dev/test-среды на панели мониторинга продуктивной среды, примените правило подавления, основанное на теге Environment=dev — результаты по-прежнему хранятся в базовом хранилище данных для аудита, но они исключаются из представлений по умолчанию и из Security Hub, если это настроено. Не стоит добиваться этого, отключая Inspector для dev-аккаунтов; так вы потеряете возможность отловить продвижение уязвимого артефакта из разработки в продуктив.

Блокировка в CI/CD для продвижения образов

Расширенное сканирование ECR генерирует результаты, привязанные к дайджесту образа (image digest) (а не только к тегу), который и должен запрашивать конвейер. Канонический паттерн выглядит так: сборка образа → отправка в ECR (запускает сканирование при отправке) → опрос или ожидание завершения сканирования → прерывание сборки, если найдены уязвимости уровня High или Critical → в противном случае обновление задачи ECS или развертывания EKS.

Минимальный шаг в CodeBuild в файле buildspec.yml:

post_build:
  commands:
      DIGEST=$(aws ecr describe-images --repository-name $REPO \
        --image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
      aws inspector2 list-findings \
        --filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
        --query 'findings[].findingArn' --output text > findings.txt
    - if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi

Не использовать блокировку на этом этапе, полагаясь на то, что «Inspector нас оповестит», — это классическая ошибка: оповещения приходят асинхронно и уже после того, как уязвимый образ запущен. Блокировка должна быть синхронной с процессом продвижения. Аналогично, блокировка только по тегу, а не по дайджесту, небезопасна, поскольку теги изменяемы; две отправки с одним и тем же тегом смешают результаты сканирования.

Patch Manager, базовые наборы и группы патчей

SSM Patch Manager оперирует тремя основными элементами:

Базовый набор патчей (patch baseline): определяет правила автоматического одобрения, одобренные патчи, отклоненные патчи и уровень соответствия (compliance level) для каждого уровня серьезности/классификации.
Группа патчей (patch group): тег с ключом ровно Patch Group, значение которого регистрирует экземпляры для определенного базового набора.
Окно обслуживания (maintenance window): расписание, в течение которого AWS-RunPatchBaseline выполняет задачи сканирования (Scan) или установки (Install).

Для среды, где в Dev требуется немедленно автоматически одобрять все патчи безопасности, а в Prod — одобрять только патчи уровня Critical/Important после 7-дневного периода «отстаивания» (soak), отклоняя при этом пакеты ядра, вы создаете два базовых набора. Базовый набор для Dev использует правило одобрения с ApproveAfterDays: 0, охватывающее все классификации безопасности. Базовый набор для Prod использует ApproveAfterDays: 7, ComplianceLevel: CRITICAL, фильтры Classification=Security и Severity in [Critical, Important], а также добавляет kernel* в список отклоненных патчей с опцией BlockAllPatchesFromRejectedList. Экземпляры помечаются тегами Patch Group=Dev или Patch Group=Prod, и каждая группа патчей регистрируется для соответствующего базового набора. Информация о соответствии собирается в отчетах о соответствии патчам (Patch Compliance reports) и может быть экспортирована в S3 для централизованного аудита.

Один базовый набор «с логикой» не может выразить различия между Dev и Prod — базовые наборы статичны для каждой зарегистрированной группы. Не пытайтесь имитировать это поведение с помощью разных окон обслуживания; окно контролирует, когда выполняется установка патчей, а не какие патчи одобряются.

Конвейер уведомлений в реальном времени

Для оповещений о новых находках в Slack или Microsoft Teams наиболее эффективная с точки зрения эксплуатации схема выглядит так:

Inspector отправляет находки в EventBridge через источник событий aws.inspector2.
Правило EventBridge фильтрует по степени серьезности (например, HIGH, CRITICAL) и направляет события в топик SNS.
Топик SNS имеет подписку AWS Chatbot, сопоставленную с каналом Slack или рабочей областью Teams.

Chatbot подписывается напрямую на SNS — не вставляйте между ними Lambda для переформатирования сообщений, так как Chatbot нативно отображает находки Inspector. Пример шаблона для EventBridge:

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": { "severity": ["HIGH", "CRITICAL"] }
}

Здесь следует избегать двух ловушек: маршрутизация через Security Hub добавляет задержку и может привести к потере гранулярности серьезности при неверной настройке пользовательских правил (custom insights); а использование SES или кастомной Lambda с веб-хуком увеличивает операционные издержки, не добавляя функциональности, которую Chatbot уже предоставляет нативно.

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

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

Проблема: Недавно образ, содержащий библиотеку с уязвимостью высокой степени серьезности, был развернут в производственной среде, поскольку сканирование не было принудительно включено в CI/CD, а установка исправлений на инстансах EC2 выполняется непоследовательно в разных средах, что оставляет окна уязвимости и создает избыточные находки, перегружающие команду.

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

Включите Amazon Inspector Enhanced Scanning для EC2, Lambda и ECR из аккаунта безопасности, настроив делегированное администрирование в AWS Organizations, чтобы сканирования, находки и правила подавления можно было управлять централизованно.
Настройте сканирование образов ECR при отправке (on push) и интегрируйте шлюзы сканирования в CodePipeline/CodeBuild: блокируйте продвижение образа до тех пор, пока результаты сканирования Inspector/ECR не будут соответствовать пороговым значениям серьезности, и отображайте находки на этапе сборки.
Внедрите AWS Systems Manager Patch Manager с определенными базовыми наборами исправлений (patch baselines) и группами исправлений (patch groups) для каждой среды, запланируйте окна обслуживания (Maintenance Windows) для развертывания сначала в непроизводственных средах и автоматизируйте утверждение критических исправлений CVE с помощью документов SSM Automation.
Создайте конвейер уведомлений в реальном времени с помощью Amazon EventBridge для сбора находок Inspector и событий соответствия SSM, направляйте их в Amazon SNS и в легковесную AWS Lambda, которая обогащает, дедуплицирует и публикует приоритетные оповещения в Slack, а также создает заявки в системе отслеживания.
Автоматизируйте сдерживание и исправление: используйте SSM Automation или сценарии Lambda (runbooks), запускаемые через EventBridge, для изоляции затронутых версий EC2/Lambda или запуска пересборки образов, и применяйте правила подавления Inspector только для отслеживаемых ложноположительных срабатываний через аккаунт делегированного администратора, чтобы уменьшить информационный шум.

Обоснование: Централизованное управление Inspector, использование шлюзов в CI/CD, базовые наборы исправлений в Patch Manager и конвейер на базе EventBridge соответствуют лучшим практикам AWS, обеспечивая автоматизированное предотвращение, последовательное применение исправлений и приоритетное, аудируемое реагирование, одновременно снижая усталость от оповещений.

Обнаружение уязвимостей с помощью Amazon Inspector

Amazon Inspector — это основной управляемый сервис оценки уязвимостей в AWS, который работает с тремя типами ресурсов, имеющих отношение к безопасности хостов: инстансы EC2, образы контейнеров в Amazon ECR и функции Lambda. Когда он включен на уровне аккаунта или Organizations (через делегированного администратора в консоли Inspector), он выполняет непрерывное сканирование без агентов или на основе SSM, а не сканирование по расписанию в определенный момент времени. Этот непрерывный подход важен, поскольку ленты CVE обновляются ежедневно; снимок состояния недельной давности может быть уже неактуальным.

Для EC2 Inspector использует SSM Agent для перечисления установленных пакетов и версий ядра, а затем сопоставляет их с рекомендациями поставщиков и Национальной базой данных уязвимостей (National Vulnerability Database). Находки включают идентификатор CVE, оценку CVSS, затронутый пакет, исправленную версию и контекст сетевой доступности (правила сетевой доступности определяют порты, открытые в интернет через ENI, группы безопасности, NACL и таблицы маршрутизации). Поскольку сканирование зависит от SSM, инстанс EC2, у которого в профиле инстанса отсутствует управляемая политика AmazonSSMManagedInstanceCore, просто не появится в результатах Inspector — это «тихий» сбой, о котором стоит помнить.

Для ECR Inspector поддерживает два режима сканирования:

Базовое сканирование: бесплатное, использует движок с открытым исходным кодом Clair, запускается только при отправке образа (on push) или по запросу.
Расширенное сканирование: на базе Inspector, непрерывно пересканирует образы (как пакеты ОС, так и пакеты языков программирования, таких как Python, Node, Java) по мере публикации новых CVE, даже спустя долгое время после отправки образа.

Распространенная ошибка — считать сканирование ECR при отправке (scan-on-push) достаточной мерой для обеспечения безопасности хоста. Это не так. Сканирование при отправке проверяет образ во время сборки, но запущенный контейнер наследует образ плюс любые изменения (drift), а базовый хост EC2 или Fargate имеет собственное ядро и пакеты ОС, которые необходимо исправлять независимо. Расширенное сканирование в сочетании со сканированием хостов EC2 устраняет этот пробел. Все находки Inspector следует направлять в AWS Security Hub, который нормализует их в формат ASFF и обеспечивает агрегацию между аккаунтами, дедупликацию и последующую автоматизацию через EventBridge.

Patch Manager и устранение уязвимостей в масштабе всего парка

AWS Systems Manager Patch Manager дополняет Inspector, фактически устраняя уязвимости, которые тот обнаруживает. Если Inspector отвечает на вопрос «Какие CVE затрагивают мои ресурсы?», то Patch Manager отвечает на вопросы «Какие исправления отсутствуют и как их безопасно установить?».

Patch Manager работает через наборы правил исправлений (patch baselines) — декларативные правила, которые определяют, какие исправления одобрены, на основе классификации (Security, Critical, Bugfix), серьезности и задержки автоматического одобрения (например, одобрять исправления безопасности через семь дней после выпуска, чтобы убедиться в их стабильности). AWS предоставляет наборы правил по умолчанию для каждой ОС (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline и т. д.), но в производственных средах обычно используются пользовательские наборы правил, привязанные к группам исправлений (patch groups) через тег Patch Group на инстансах.

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

Scan: сообщает о соответствии требованиям без установки чего-либо; результаты появляются на панели соответствия Patch Manager и в Config.
Install: применяет одобренные исправления и, для многих ОС, выполняет перезагрузку.

Эти операции обычно планируются через окна обслуживания (maintenance windows) с целевым документом AWS-RunPatchBaseline. Для срочных сценариев с уязвимостями нулевого дня Patch Manager предлагает Patch Now — действие по требованию, которое выполняется в обход расписания окон обслуживания. Рекомендуемый подход — создать узкоспециализированный набор правил исправлений, одобряющий только конкретный KB или пакет, устраняющий уязвимость, нацелить его на затронутую группу исправлений, запустить Patch Now и направить вывод выполнения в централизованный бакет S3 и группу CloudWatch Logs. Этот централизованный лог становится вашим артефактом для аудита — доказательством устранения уязвимости для аудиторов или команды реагирования на инциденты.

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

Сценарий: Meridian Financial управляет многоаккаунтной средой AWS с несколькими сотнями инстансов EC2 (Windows и Amazon Linux) и небольшим кластером EKS, поддерживающим сервисы для клиентов. Они используют AWS Organizations, AWS Systems Manager для операционных задач и хранят AMI в общем аккаунте для образов, но у них нет последовательного автоматизированного сканирования уязвимостей или скоординированного развертывания исправлений между аккаунтами.

Проблема: Была опубликована информация об общедоступной уязвимости CVE, затрагивающей OpenSSL, и Amazon Inspector сообщил о находках с высоким уровнем серьезности на нескольких инстансах. Однако установка исправлений была неравномерной, и один из производственных сервисов подвергся кратковременной попытке эксплуатации из-за задержки в устранении уязвимости.

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

Включить Amazon Inspector во всех аккаунтах и регионах для сканирования уязвимостей как в образах, так и в запущенных инстансах, и пересылать находки с высоким уровнем серьезности в AWS Security Hub и на пользовательскую шину событий EventBridge.
Использовать AWS Systems Manager Inventory для выявления затронутых инстансов и их тегирования по степени критичности; создать набор правил Patch Manager, включающий необходимые исправления для OpenSSL и нацеленный на правила для Windows/Linux.
Создать правило EventBridge, которое запускает документ SSM Automation при достижении находками Inspector определенного уровня серьезности, передавая список ID инстансов в runbook Automation, который вызывает Patch Manager или Run Command для применения исправлений и перезагрузки, где это необходимо.
Для сервисов с отслеживанием состояния или высоким риском организовать последовательные обновления с помощью EC2 Image Builder для создания AMI с исправлениями, обновить Auto Scaling группы или группы узлов EKS с помощью контролируемого сине-зеленого или последовательного развертывания и проверить работоспособность сервиса с помощью проверок состояния Route 53/ALB.
После устранения уязвимости повторно запустить Amazon Inspector, чтобы убедиться, что находки устранены, обновить отчеты SSM Compliance и отправить сводку команде безопасности через SNS; сохранить runbook Automation в библиотеке Systems Manager Automation для повторяемого реагирования в масштабе всего парка.

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

# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
  PatchRules:
    - PatchFilterGroup:
        PatchFilters:
          - Key: PRODUCT
            Values: [AmazonLinux2]
          - Key: CVE_ID
            Values: [CVE-2024-XXXXX]
      ApproveAfterDays: 0
      ComplianceLevel: CRITICAL

Централизованное управление соответствием требованиям достигается путем настройки делегированного администратора в Systems Manager Explorer и включения синхронизации данных о ресурсах (resource data sync) для агрегации состояния соответствия исправлений из каждого аккаунта в один бакет S3, который затем можно запрашивать с помощью Athena или визуализировать в QuickSight.

Session Manager для администрирования с возможностью аудита

Традиционный доступ по SSH имеет три структурных недостатка: долгоживущие ключи хранятся на ноутбуках операторов, порт 22 должен быть доступен (даже если только через бастион-хост), а активность в командной строке не записывается централизованно без дополнительных инструментов. Session Manager устраняет все три.

Session Manager туннелирует интерактивную оболочку через исходящее HTTPS-соединение SSM Agent к эндпоинтам SSM. Нет входящего порта, нет пары ключей SSH и нет бастион-хоста. Доступ авторизуется политиками IAM (ssm:StartSession, ограниченными тегом инстанса или ARN), и каждая сессия может быть записана в CloudWatch Logs или S3, опционально с шифрованием KMS. В Linux сессии по умолчанию запускаются от имени пользователя ssm-user; поведение sudo контролируется конфигурацией sudoers на инстансе, а не IAM.

Правильный шаблон усиления безопасности для новых парков инстансов: запускать инстансы без пары ключей EC2, прикреплять профиль инстанса с политикой AmazonSSMManagedInstanceCore, размещать инстансы в приватных подсетях с VPC-эндпоинтами для ssm, ssmmessages и ec2messages, и принудительно включать логирование сессий на уровне настроек Session Manager. Продолжать распространять ключи SSH наряду с Session Manager — это ловушка: это сохраняет ту самую поверхность атаки, для устранения которой был внедрен Session Manager, и оставляет непротоколируемый канал доступа. Удалите предоставление authorized_keys из вашего процесса создания AMI.

Сбор телеметрии с хоста с помощью агента CloudWatch

Единый агент CloudWatch собирает метрики уровня ОС (память, диск, загрузка ЦП по процессам) и файлы журналов, которые гипервизор EC2 не видит. Он настраивается с помощью JSON-файла, который обычно хранится в Parameter Store, а затем применяется командой amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux.

Наиболее частая эксплуатационная проблема с агентом — это отсутствие IAM-разрешений в профиле экземпляра. Агенту требуются как минимум:

logs:CreateLogGroup (если группа не создана заранее)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (для пользовательских метрик)
ssm:GetParameter (для получения конфигурации из Parameter Store)

Управляемая политика CloudWatchAgentServerPolicy объединяет эти разрешения. При отсутствии разрешений агент успешно запускается и выглядит исправным в выводе systemctl status, но журналы так и не поступают в CloudWatch — ошибки видны только в файле /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Любая архитектура безопасности хоста, которая предполагает централизованный сбор журналов, должна проверять их доставку, а не только статус агента.

Объединяя все вместе

Защитный контур выглядит так: Inspector обнаруживает CVE на хостах и в образах контейнеров, результаты поступают в Security Hub для агрегации, Patch Manager устраняет уязвимости через запланированные окна обслуживания или немедленно (Patch Now) в экстренных случаях, Session Manager предоставляет единственный путь для административного доступа, а агент CloudWatch передает как подтверждения установки патчей, так и операционные журналы в централизованную учетную запись. Каждый элемент контроля полагается на остальные: Inspector без Patch Manager генерирует отчеты, по которым никто не принимает мер; Patch Manager без централизованного сбора журналов не оставляет аудиторского следа; Session Manager без правильных настроек IAM оставляет либо слишком много, либо слишком мало прав доступа; а агент CloudWatch без корректных разрешений для журналов создает лишь иллюзию наблюдаемости.

← Управление · Все домены · Безопасность контейнеров и 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 →