Справочник

Потенциально скомпрометированный инстанс EC2 в группе Auto Scaling требует расследования с минимальными сбоями.

→Отменить регистрацию из целевой группы ELB, удалить из группы Auto Scaling и применить ограничительную группу безопасности "forensic", которая запрещает весь трафик, за исключением доступа с криминалистической рабочей станции.

Почему: Это изолирует инстанс от сети, сохраняя его изменчивое состояние (память, запущенные процессы) для криминалистического анализа. Немедленное завершение уничтожает улики.

Автоматизировать многоэтапный рабочий процесс реагирования на инциденты (например, создание снимка, изоляция, уведомление), запускаемый обнаружением GuardDuty.

→Использовать правило EventBridge для захвата конкретного обнаружения и запуска конечного автомата AWS Step Functions. Конечный автомат оркестрирует последовательность действий с обработкой ошибок и логикой повторных попыток.

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

Обнаруживать угрозы времени выполнения (например, криптомайнинг, повышение привилегий) в запущенных контейнерах ECS Fargate или EC2 без развертывания побочных агентов.

→Включить Amazon GuardDuty ECS Runtime Monitoring. Для EC2 развернуть агент безопасности GuardDuty как DaemonSet. Для Fargate использовать автоматическую конфигурацию агента.

Почему: Это обеспечивает обнаружение угроз времени выполнения без агента (для Fargate) или с централизованным управлением (для EC2), захватывая поведение внутри контейнера без изменения задач приложения.

Источник↗

Автоматически устранять конкретное обнаружение AWS Security Hub, например, общедоступный бакет S3.

→Создать правило EventBridge, которое соответствует конкретному типу обнаружения (например, `S3.1`) и запускает функцию Lambda или документ SSM Automation для выполнения исправления.

Почему: Это нативный, событийно-ориентированный шаблон для автоматического реагирования Security Hub, обеспечивающий целевое исправление в реальном времени.

Ключ доступа IAM был публично скомпрометирован. Локализовать инцидент и оценить масштаб ущерба.

→1. Деактивировать скомпрометированный ключ доступа. 2. Прикрепить встроенную политику deny-all к пользователю/роли для аннулирования активных сессий STS. 3. Просмотреть логи CloudTrail для всех вызовов API, сделанных с помощью ключа. 4. Удалить все несанкционированные ресурсы или субъекты IAM, созданные злоумышленником.

Почему: Деактивация ключа предотвращает его дальнейшее использование. Политика deny-all имеет решающее значение для отзыва активных сессий, созданных *до* деактивации ключа. CloudTrail предоставляет журнал аудита для оценки ущерба.

Улучшить обнаружение угроз GuardDuty с помощью фидов информации об угрозах, специфичных для компании или отрасли.

→Загрузить текстовый файл вредоносных IP-адресов/CIDR в S3. Создать и активировать новый набор угроз в GuardDuty, указывающий на файл S3.

Почему: Это позволяет дополнить управляемую информацию об угрозах GuardDuty пользовательскими индикаторами компрометации (IOC), генерируя обнаружения, когда ваши ресурсы взаимодействуют с указанными IP-адресами.

Идентифицировать инстансы EC2 с сетевыми путями, открытыми для интернета на определенных портах, учитывая все сетевые конфигурации.

→Включить Amazon Inspector и просмотреть его обнаружения сетевой доступности.

Почему: Inspector выполняет полный анализ сетевого пути от IGW до инстансов, оценивая группы безопасности, NACL и таблицы маршрутизации для определения фактической доступности. Это более точно, чем просто проверка отдельных правил группы безопасности.

Исследовать полный объем обнаружения безопасности, визуализируя все связанные сущности и историческое поведение.

→Использовать Amazon Detective. Перейдите к профилю сущности (например, для инстанса EC2 или роли IAM), чтобы просмотреть график поведения и хронологию связанных вызовов API, сетевых подключений и обнаружений GuardDuty.

Почему: Detective автоматически коррелирует логи из CloudTrail, VPC Flow Logs и GuardDuty, предоставляя контекстный анализ, который значительно ускоряет расследование первопричины по сравнению с ручной корреляцией логов.

Хранить аудиторские журналы (например, CloudTrail, VPC Flow Logs) для долгосрочного хранения в защищенном от изменений и доступном для запросов виде для обеспечения соответствия требованиям.

→Доставлять журналы в бакет S3 с включенным S3 Object Lock в режиме Compliance Mode. Использовать Amazon Athena для запросов.

Почему: Object Lock в режиме Compliance Mode предотвращает удаление или изменение кем-либо, включая root-пользователя, обеспечивая неизменяемость журнала. Athena предоставляет возможности для выполнения SQL-запросов ad-hoc к хранимым журналам.

Источник↗

Централизованно собирать все события управления и данных для всей AWS Organization.

→В управляющей учетной записи создайте CloudTrail Organization Trail. Для сбора данных на уровне объектов используйте расширенные селекторы событий для журналирования определенных типов событий (например, S3 PutObject, Lambda Invoke) для ценных ресурсов.

Почему: Журнал организации автоматически регистрирует события для всех дочерних учетных записей. Расширенные селекторы событий критически важны для экономически эффективного журналирования больших объемов данных, ориентируясь только на необходимые ресурсы.

Выполнять комплексный, SQL-ориентированный анализ событий CloudTrail из всей организации за несколько лет.

→Включить AWS CloudTrail Lake и создать хранилище данных событий на уровне организации с требуемым сроком хранения (до 7 лет). Использовать встроенный редактор SQL-запросов для анализа.

Почему: CloudTrail Lake предоставляет управляемое, неизменяемое хранилище данных и движок запросов, специально разработанный для событий CloudTrail, устраняя необходимость управлять S3, Glue и Athena для анализа журналов.

Мониторить все DNS-запросы, сделанные ресурсами в VPC, для охоты за угрозами или устранения неполадок.

→Включить Route 53 Resolver DNS Query Logging и настроить его для отправки журналов в CloudWatch Logs, S3 или Kinesis Data Firehose.

Почему: Это обеспечивает подробную видимость активности разрешения DNS в ваших VPC, фиксируя запрашиваемый домен, исходный инстанс и ответ, что крайне важно для обнаружения угроз на основе DNS.

Централизовать и нормализовать журналы безопасности из различных источников AWS и сторонних производителей в озеро данных с использованием стандартной схемы.

→Развернуть Amazon Security Lake. Он автоматически собирает и нормализует данные в Open Cybersecurity Schema Framework (OCSF) и хранит их в формате Parquet в S3.

Почему: Security Lake автоматизирует создание и управление озером данных безопасности, уменьшая операционные накладные расходы на создание пользовательских конвейеров ETL для нормализации.

Автоматизировать сбор доказательств для аудитов соответствия стандартам, таким как SOC 2, PCI DSS или HIPAA.

→Использовать AWS Audit Manager. Выбрать предварительно созданный фреймворк, который автоматически собирает доказательства из служб AWS (CloudTrail, Config, Security Hub) и сопоставляет их с конкретными элементами управления соответствием.

Почему: Audit Manager автоматизирует и централизует процесс сбора доказательств, значительно сокращая ручные усилия, необходимые для подготовки и проведения аудитов соответствия.

Автоматически обнаруживать и классифицировать конфиденциальные данные (PII, PHI, финансовые) во всех бакетах S3.

→Включить Amazon Macie и настроить автоматические задания по обнаружению конфиденциальных данных. Использовать управляемые идентификаторы данных для распространенных типов данных и создавать пользовательские идентификаторы данных для проприетарных форматов.

Почему: Macie предоставляет управляемое, масштабируемое решение для классификации данных S3. Чтобы подавлять обнаружения для известных нечувствительных данных (например, тестовых данных), используйте списки разрешений Macie.

Применить несколько элементов управления безопасностью к бакету S3, например, требовать SSE-KMS с определенным ключом и запрещать HTTP-запросы.

→Использовать политику бакета с несколькими операторами `Deny` и ключами условий: `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"`, и `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`.

Почему: Политики бакета обеспечивают детальный контроль на уровне ресурсов. Использование нескольких ключей условий в операторах Deny является стандартным способом обеспечения многоуровневой безопасности для бакета.

Гарантировать, что все новые тома EBS зашифрованы определенным управляемым клиентом ключом KMS, в масштабах всей организации.

→Включить шифрование EBS по умолчанию в настройках учетной записи для каждого региона, указав CMK. Применить SCP, который запрещает `ec2:CreateVolume`, если параметр `encrypted` имеет значение `false`, в качестве превентивной меры.

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

Шифровать большие объекты данных (> 4 КБ) с использованием AWS KMS.

→Использовать конвертное шифрование. Вызвать `KMS:GenerateDataKey` для получения ключа данных в открытом виде и зашифрованного ключа данных. Использовать ключ в открытом виде для локального шифрования большого объекта. Хранить зашифрованный объект и зашифрованный ключ данных вместе. Отбросить ключ в открытом виде.

Почему: API KMS Encrypt имеет ограничение в 4 КБ. Конвертное шифрование позволяет шифровать данные любого размера, при этом небольшой ключ данных защищен KMS, что снижает затраты и задержку по сравнению с потоковой передачей данных через KMS.

Источник↗

Использовать один и тот же ключ шифрования в нескольких регионах AWS для аварийного восстановления или обеспечения глобальной согласованности приложений.

→Создать первичный ключ KMS с поддержкой нескольких регионов в одном регионе и создать ключи-реплики в других регионах. Данные, зашифрованные ключом в одном регионе, могут быть расшифрованы репликой в другом.

Почему: Мультирегиональные ключи используют один и тот же материал ключа и идентификатор ключа, что обеспечивает переносимость данных между регионами без вызовов API между регионами для расшифровки.

Безопасно хранить и автоматически ротировать учетные данные (например, пароли баз данных, API ключи), используемые приложениями.

→Хранить учетные данные в AWS Secrets Manager. Настроить автоматическую ротацию с использованием пользовательской или предоставленной AWS функции ротации Lambda. Приложения извлекают секреты во время выполнения через роль IAM.

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

Управлять как публичными TLS-сертификатами для веб-сайтов, так и частными сертификатами для внутренней коммуникации микросервисов (mTLS).

→Использовать AWS Certificate Manager (ACM) для бесплатных публичных сертификатов, интегрированных с ELB/CloudFront. Создать частный центр сертификации с помощью ACM Private CA для выдачи и управления частными сертификатами для внутренних сервисов.

Почему: Это разделяет публичную и частную PKI, используя подходящий инструмент для каждого случая. ACM управляет жизненным циклом публичных сертификатов, а ACM Private CA предоставляет полностью управляемую иерархию частной PKI.

Хранить данные неизменяемо в течение фиксированного периода хранения, когда даже root-пользователь не может их удалить.

→Включить S3 Object Lock в бакете. Установить для объектов период хранения в режиме Compliance Mode.

Почему: Compliance Mode — это самый строгий контроль WORM (Write-Once-Read-Many), предотвращающий удаление любым пользователем. Режим Governance может быть обойден авторизованными субъектами.

Защитить резервные копии от удаления (например, из-за программ-вымогателей или скомпрометированных учетных данных) на обязательный период хранения.

→Включить AWS Backup Vault Lock в режиме Compliance Mode с минимальным сроком хранения.

Почему: Vault Lock в режиме Compliance Mode делает хранилище резервных копий совместимым с WORM, предотвращая удаление точек восстановления любым пользователем, включая root, до истечения срока хранения.

Обрабатывать высокочувствительные данные, когда данные никогда не должны быть доступны операционной системе, гипервизору или операторам AWS.

→Использовать AWS Nitro Enclaves для создания криптографически изолированной вычислительной среды. Использовать аттестацию KMS, чтобы гарантировать, что только проверенные анклавы могут расшифровывать данные.

Почему: Nitro Enclaves обеспечивают самый высокий уровень защиты данных в использовании на AWS, используя аттестацию на аппаратном уровне для создания доверенной среды выполнения.

Использовать сервисы AWS с ключами шифрования, которые физически хранятся и управляются в локальном HSM, вне AWS.

→Настроить KMS External Key Store (XKS), который проксирует криптографические операции из KMS во внешний менеджер ключей.

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

Обеспечить строгое применение политики "нет публичных бакетов S3" по всей организации с превентивными и детективными мерами контроля.

→Включить S3 Block Public Access на уровне организации из управляющей учетной записи. Дополнить SCP, который запрещает действия типа `s3:PutBucketPolicy`, если политика разрешает публичный доступ. Использовать AWS Config для обнаружения отклонений.

Почему: Этот многоуровневый подход обеспечивает блокировку по умолчанию (настройка организации), превентивную защиту, предотвращающую неправильные конфигурации (SCP), и детективную меру контроля для непрерывного мониторинга (Config).

Инспектировать весь трафик между VPC и трафик, направленный в интернет, используя централизованное устройство безопасности (например, AWS Network Firewall).

→Создать выделенную инспекционную VPC. Использовать Transit Gateway для подключения всех VPC. Настроить таблицы маршрутизации TGW для отправки всего трафика через инспекционную VPC. Включить режим устройства на подключении TGW для симметричной маршрутизации.

Почему: Это стандартная модель "звезда" для централизованной инспекции трафика, обеспечивающая масштабируемость и последовательное применение политик без сложных связей VPC.

Защитить веб-приложение (на CloudFront/ALB) от OWASP Top 10, ботов и атак по захвату учетных записей.

→Прикрепить AWS WAF с управляемыми правилами AWS (например, `AWSManagedRulesCommonRuleSet`), управляемой группой правил Bot Control и управляемой группой правил Account Takeover Prevention (ATP).

Почему: Этот многоуровневый подход использует несколько управляемых групп правил для широкой защиты (Common), автоматического обнаружения трафика (Bot Control) и специализированной безопасности конечных точек входа (ATP).

Предоставить безопасный, частный доступ к API-сервису SaaS из клиентских VPC без раскрытия сервиса в интернете.

→Создать службу конечной точки AWS PrivateLink, поддерживаемую Network Load Balancer (NLB). Клиенты создают конечные точки интерфейса VPC в своих VPC для доступа к службе.

Почему: PrivateLink сохраняет трафик в частной магистрали AWS, избегая публичного интернета и устраняя необходимость в сложном пиринге VPC, VPN или белых списках IP. Это стандартный, масштабируемый шаблон для частного подключения SaaS.

Ограничить доступ к бакету S3, чтобы контент был доступен только через дистрибуцию CloudFront.

→Использовать CloudFront Origin Access Control (OAC). Обновить политику бакета S3, чтобы разрешить доступ только от сервисного субъекта дистрибуции CloudFront, с условием на конкретный ARN дистрибуции.

Почему: OAC является текущим рекомендуемым методом, превосходящим устаревший Origin Access Identity (OAI). Он поддерживает все функции S3, включая SSE-KMS, и соответствует лучшим практикам безопасности.

Предоставить безопасный, проверяемый доступ к оболочке инстансов EC2 в частных подсетях без открытия портов SSH/RDP или управления бастионными хостами.

→Установить SSM Agent на инстансы EC2. Использовать AWS Systems Manager Session Manager для доступа. Политики IAM контролируют, кто может запускать сессии. Активность сессий может быть записана в CloudWatch Logs и S3.

Почему: Session Manager предоставляет безопасный доступ через браузер или CLI через зашифрованный туннель, устраняя необходимость во входящих портах, бастионных хостах и ключах SSH, а также обеспечивая полную возможность аудита.

Внедрить фильтрацию на уровне DNS для предотвращения разрешения известными вредоносными доменами ресурсами VPC.

→Настроить Route 53 Resolver DNS Firewall с управляемыми списками доменов (для вредоносных программ, C2) и пользовательскими списками блокировки. Связать группу правил брандмауэра с VPC.

Почему: Это обеспечивает централизованную, управляемую службу фильтрации DNS на уровне VPC, блокируя вредоносную активность на самой ранней стадии (разрешение DNS) без необходимости использования агентов на хостах.

Внедрить сетевые элементы управления с минимальными привилегиями для трехуровневого веб-приложения.

→Создать отдельные группы безопасности для каждого уровня. Группа безопасности ALB разрешает входящий трафик по порту 443 из `0.0.0.0/0`. Группа безопасности App разрешает входящий трафик только от группы безопасности ALB. Группа безопасности DB разрешает входящий трафик только от группы безопасности App на порту базы данных.

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

Предоставлять детализированные разрешения AWS на уровне подов приложениям, работающим на EKS, избегая использования общих ролей IAM узлов.

→Включить IAM Roles for Service Accounts (IRSA) на кластере EKS. Создать роль IAM с конкретными разрешениями для приложения. Аннотировать учетную запись службы Kubernetes приложения ARN роли IAM.

Почему: IRSA предоставляет временные учетные данные непосредственно подам на основе их учетной записи службы, реализуя принцип наименьших привилегий на уровне пода и устраняя риск безопасности, связанный с избыточно разрешительными ролями узлов.

Обеспечить без VPN-доступ к внутренним веб-приложениям на основе как идентификации пользователя, так и состояния безопасности устройства.

→Развернуть AWS Verified Access. Интегрировать с корпоративным IdP в качестве поставщика доверия пользователя и с решением для управления устройствами в качестве поставщика доверия устройства. Создать политики доступа для каждого приложения.

Почему: Verified Access специально разработан для доступа с нулевым доверием, оценивая каждый запрос на соответствие политикам, учитывающим как контекст пользователя, так и устройства, устраняя зависимость от безопасности сетевого периметра.

Разрешить разработчикам создавать роли IAM, но предотвратить создание ролей, которые могут повысить их собственные привилегии.

→Создать политику границ разрешений, которая определяет максимально допустимые разрешения. В политике IAM разработчиков ограничить разрешение `iam:CreateRole` требованием прикрепления этой конкретной границы через ключ условия `iam:PermissionsBoundary`.

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

Источник↗

Предотвратить выполнение любых высокорискованных действий любым пользователем в любой дочерней учетной записи (включая администраторов), таких как отключение CloudTrail или удаление общего бакета S3.

→Применить политику управления услугами (SCP) к корневому или соответствующему OU, которая содержит оператор `Deny` для ограниченных действий (например, `cloudtrail:StopLogging`, `s3:DeleteBucket`).

Почему: SCP являются главной защитой в AWS Organizations. Они устанавливают максимальные разрешения для всех субъектов в учетной записи, и явное отклонение в SCP не может быть переопределено какой-либо политикой IAM внутри учетной записи.

Обеспечить безопасный, проверяемый доступ между учетными записями для приложения или пользователя.

→В целевой учетной записи создайте роль IAM с политикой доверия, которая указывает ARN субъекта исходной учетной записи. В исходной учетной записи предоставьте субъекту разрешение `sts:AssumeRole` для целевой роли. Приложение использует STS AssumeRole для получения временных учетных данных.

Почему: Это стандартный шаблон для доступа между учетными записями. Он использует временные, краткосрочные учетные данные и полностью подлежит аудиту в обеих учетных записях через CloudTrail.

Интегрировать IAM Identity Center с внешним IdP (например, Okta, Azure AD) и автоматизировать предоставление пользователей/групп.

→Настроить внешний IdP как источник идентификации в IAM Identity Center. Включить автоматическое предоставление через SCIM для синхронизации пользователей и групп. Назначить наборы разрешений синхронизированным группам.

Почему: SCIM (System for Cross-domain Identity Management) обеспечивает автоматическую синхронизацию идентификаторов почти в реальном времени, устраняя ручное управление пользователями и гарантируя, что доступ к AWS управляется IdP.

Предоставлять доступ к ресурсам (например, EC2) на основе тегов, где субъекты могут управлять только ресурсами, помеченными именем их собственной команды/отдела.

→Пометить тегами как субъекты IAM (пользователи/роли), так и ресурсы (инстансы EC2) с общим ключом (например, `Team`). Создать единую политику IAM, которая разрешает действия с условием, сравнивающим `aws:PrincipalTag/Team` с `aws:ResourceTag/Team`.

Почему: Управление доступом на основе атрибутов (ABAC) предоставляет масштабируемую модель разрешений, которая не требует обновления политик при добавлении новых ресурсов или команд. Разрешения определяются динамически на основе тегов.

Субъект в учетной записи B должен прочитать объект S3 в учетной записи A, который зашифрован ключом KMS, также находящимся в учетной записи A.

→Требуются три разрешения: 1) Политика бакета S3 в учетной записи A должна разрешать субъекту из учетной записи B. 2) Политика ключа KMS в учетной записи A должна разрешать субъекту из учетной записи B для `kms:Decrypt`. 3) Субъекту в учетной записи B требуется политика IAM, разрешающая `s3:GetObject` и `kms:Decrypt`.

Почему: Доступ к данным, зашифрованным KMS, требует разрешений как от службы данных (S3), так и от службы шифрования (KMS). Политика ключа KMS является политикой ресурса и критически важна для предоставления доступа между учетными записями.

Понять окончательный результат разрешения, когда применяются несколько политик (IAM, Resource, SCP, Boundary).

→Логика оценки такова: Явный `Deny` в любой политике всегда отменяет любой `Allow`. Если `Deny` отсутствует, явный `Allow` в любой применимой политике предоставляет доступ. Фактические разрешения являются пересечением всех применимых политик.

Почему: Это фундаментальная концепция IAM. Явный `Deny` является самым мощным заявлением и служит жестким "нет". Понимание этого является ключом к устранению проблем с доступом.

Предотвратить передачу пользователем или ролью IAM высокопривилегированной роли в службу AWS (например, EC2), что привело бы к повышению его привилегий.

→Ограничить разрешение `iam:PassRole` в политике IAM пользователя/роли. Ограничить элемент `Resource` только конкретными ARN ролей с минимальными привилегиями, которые сущность авторизована передавать.

Почему: `iam:PassRole` с подстановочным знаком (`"Resource": "*"`) представляет собой значительный риск повышения привилегий. Ограничение его конкретными, менее привилегированными ролями является критически важным элементом управления безопасностью.

Запрашивать у пользователей MFA только тогда, когда попытка входа считается рискованной (например, новое устройство, необычное местоположение).

→Включить расширенные функции безопасности в пуле пользователей Cognito и настроить адаптивную аутентификацию с принудительным использованием MFA на основе рисков.

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

Разрешить локальным серверам, использующим частную PKI, доступ к службам AWS без долгосрочных учетных данных AWS.

→Настроить IAM Roles Anywhere. Создать якорь доверия, используя сертификат частного ЦС. Создать профили, сопоставляющие сертификаты с ролями IAM. Серверы используют свои сертификаты для получения временных учетных данных AWS.

Почему: Это расширяет роли IAM на внешние рабочие нагрузки, используя существующую PKI, устраняя необходимость управлять ключами доступа AWS на локальных серверах.

Предотвратить развертывание несоответствующих ресурсов, определенных в шаблонах CloudFormation, *до* их предоставления.

→Включить проактивные элементы управления AWS Control Tower. Они используют хуки CloudFormation для проверки конфигураций ресурсов на соответствие политикам (написанным в cfn-guard) до их предоставления.

Почему: Это элемент управления "shift-left", который предотвращает неправильные конфигурации на стадии источника, что более эффективно, чем их обнаружение и исправление после развертывания.