Amazon SAA-C03: Безопасность, IAM, KMS и управление — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

Основы идентификации: пользователи, root, группы и роли

Управление идентификацией и доступом (IAM) — это плоскость управления, через которую проходит каждая рабочая нагрузка. Его основной принцип — наименьшие привилегии: предоставляйте только то, что необходимо, только на то время, пока это необходимо, и предпочитайте сущности, которые создают краткосрочные учётные данные, тем, что хранят статические секреты.

Корневой пользователь (root) владеет аккаунтом, обладает неограниченными разрешениями и не может быть ограничен политиками IAM или SCP. Это делает его наиболее чувствительными учётными данными в среде, и его следует использовать только для экстренных случаев. В новом аккаунте: включите аппаратное или виртуальное устройство MFA для root, установите длинный уникальный пароль, удалите все исторические ключи доступа root и зарегистрируйте альтернативные контакты для биллинга, операционных вопросов и безопасности, чтобы было возможно восстановление. После первоначальной настройки — создания административной IAM-сущности, настройки биллинга и установки псевдонима аккаунта — root больше не используется, за исключением узкого набора задач, для которых AWS явно его требует (закрытие аккаунта, изменение имени аккаунта, восстановление удалённых разрешений IAM, включение MFA Delete и несколько операций в S3/CloudFront, требующих подписи root). Использовать root для повседневной работы неправильно, потому что его нельзя ограничить политикой, его действия сложно отследить в CloudTrail при совместном использовании, а одна компрометация даёт безвозвратный контроль.

Повседневный доступ для людей осуществляется через IAM-сущности, ограниченные политиками с наименьшими привилегиями. Прикрепляйте управляемые политики к группам, а не к отдельным пользователям: группа Administrators с прикреплённой политикой AdministratorAccess, в которую помещены именованные пользователи, создаёт единую точку для изменений и позволяет избежать антипаттерна копирования одинаковых политик для каждого пользователя. Ограничивайте ресурсы, используя явные ARN, а не *.

Роли служат совершенно иной цели. Они принимаются субъектами (principals) — сервисами, экземплярами EC2, функциями Lambda, федеративными пользователями, вызывающими сторонами из других аккаунтов — и создают временные учётные данные STS, которые ротируются автоматически. Поскольку эти учётные данные не могут утечь в коммите Git и истекают через минуты или часы, а не сохраняются до ручной ротации, роли являются стандартной сущностью для всего, что не является человеком.

Две политики для каждой роли: разрешений и доверия

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

Политика разрешений (на основе удостоверения) определяет, что может делать роль после её принятия. Политика доверия (на основе ресурса, прикреплённая к самой роли) определяет, кто может её принять. Прикрепление AmazonS3ReadOnlyAccess к роли не даст никакого эффекта, если ни одному субъекту не разрешено вызывать для неё sts:AssumeRole, и наоборот, разрешающая политика доверия без политики разрешений создаёт роль, которую можно принять, но которая не делает ничего полезного.

Роль выполнения Lambda демонстрирует шаблон субъекта-службы — вызывающей стороной является сама служба, а не владелец аккаунта:

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Идентификация рабочих нагрузок: профили экземпляров, роли задач, IRSA, Roles Anywhere

Любые учётные данные, хранящиеся в шаблоне, переменной окружения или на ноутбуке, — это будущая утечка. Канонический паттерн AWS заменяет статические ключи доступа на краткосрочные, автоматически ротируемые учётные данные, предоставляемые через роли.

Для EC2 механизмом доставки является профиль экземпляра (instance profile) — тонкий контейнер, который связывает IAM-роль с экземпляром, чтобы сервис метаданных экземпляра (IMDSv2) мог выдавать временные учётные данные для SDK. Цепочка поставщиков учётных данных по умолчанию находит их без дополнительной настройки, поэтому boto3.client('s3') просто работает, и код приложения никогда не видит учётных данных. Следует принудительно использовать IMDSv2 (HttpTokens: required), чтобы предотвратить эксфильтрацию учётных данных через SSRF-атаки. Учётные данные ротируются примерно каждые шесть часов, а отзыв выполняется простым редактированием роли.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Для ECS аналогом является роль задачи (task role); для Lambda — роль выполнения (execution role); для подов EKS — IRSA (IAM Roles for Service Accounts) или EKS Pod Identity. В каждом случае AWS сама выступает посредником при выдаче учётных данных на основе роли, и рабочая нагрузка никогда не видит долгоживущих секретов.

Встраивание ключей доступа в AMI, user-data скрипт или файл .env неправильно по трём конкретным причинам: ключи никогда не ротируются автоматически, их нельзя ограничить контекстом сессии, например, исходной точкой VPC, и если экземпляр скомпрометирован или AMI случайно опубликован, учётные данные утекают навсегда.

Для рабочих нагрузок за пределами AWS — на локальных серверах, в других облаках, в CI-системах, — которым нужны временные учётные данные AWS без встроенных ключей, IAM Roles Anywhere использует сертификаты X.509 из приватного центра сертификации (CA) (AWS Private CA или вашего собственного) в качестве якоря доверия. Рабочая нагрузка предъявляет свой клиентский сертификат и получает краткосрочные учётные данные STS:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Это устраняет тот же антипаттерн, который устраняют роли для экземпляров и Secrets Manager внутри AWS.

Масштабирование доступа для пользователей: Identity Center, SAML, Directory Service

Предоставление IAM-пользователей в каждом аккаунте в любом масштабе неуправляемо. AWS IAM Identity Center (преемник AWS SSO) — это рекомендуемый способ организации доступа для сотрудников: единый каталог, который федерируется в каждый аккаунт в Organization и выдаёт временные сессии на основе ролей через наборы разрешений (permission sets) — шаблонизированные IAM-роли, сопоставленные с группами IdP. Пользователи аутентифицируются один раз на портале Identity Center, а затем принимают наборы разрешений для доступа к любому назначенному аккаунту.

Identity Center интегрируется с внешними IdP (Okta, Entra ID/Azure AD, Google Workspace, ADFS) через SAML 2.0 и SCIM для автоматизации процессов приёма, перемещения и увольнения сотрудников, а также с локальным Active Directory через AWS Directory Service AD Connector (прокси) или AWS Managed Microsoft AD (полная реплика в AWS). Для мобильных или веб-приложений, которым необходимо вызывать AWS от имени неаутентифицированных или аутентифицированных через сторонние сервисы пользователей, Amazon Cognito обменивает внешнюю идентификацию на временные учётные данные STS, что также позволяет избежать встраивания долгоживущих ключей.

Межаккаунтный доступ

Межаккаунтный доступ реализуется с помощью ролей, а не общих пользователей, и требует согласия обеих сторон. Целевой аккаунт (B) создает роль, в политике доверия которой указывается аккаунт A (или конкретный участник в нем), а вызывающий субъект в аккаунте A также должен иметь разрешение sts:AssumeRole для ARN этой роли. Усилий только одной из сторон недостаточно. Это позволяет получить краткосрочные учетные данные и обеспечивает четкий аудиторский след в CloudTrail в обоих аккаунтах.

Когда принимающим участником является третья сторона (например, SaaS-поставщик), добавьте условие ExternalId, чтобы решить проблему «запутавшегося заместителя», и рассмотрите возможность требования MFA:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Для межаккаунтных вызовов между сервисами используются политики ресурсов. Чтобы разрешить топику SNS в аккаунте A вызывать Lambda-функцию в аккаунте B:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

Параметр --principal sns.amazonaws.com указывает на сервисного участника (SNS сам вызывает Lambda), а --source-arn ограничивает доверие конкретным топиком, чтобы предотвратить проблему «запутавшегося заместителя».

При предоставлении доступа к S3 в рамках Organization наивный подход — перечисление ARN каждого аккаунта в политике бакета — не масштабируется и требует изменений при добавлении каждого нового аккаунта. Правильный паттерн — это aws:PrincipalOrgID:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Разрешен любой участник из любого аккаунта в этой организации; всем остальным доступ запрещен. Обратите внимание, что Principal: "*" без этого условия сделал бы бакет публичным — именно ключ условия ограничивает область действия. Сторона идентификации также имеет значение: пользователям в дочерних аккаунтах все равно нужно разрешение s3:GetObject, предоставленное их собственной политикой IAM (если они не являются root-пользователем аккаунта), поскольку межаккаунтный доступ требует, чтобы вызов был разрешен с обеих сторон.

Что касается S3, с 2023 года настройка Object Ownership (Владение объектами) по умолчанию Bucket owner enforced (Принудительно для владельца бакета) полностью отключает ACL, делая политики бакета единственным механизмом авторизации для бакета. Если объекты ранее были загружены другими аккаунтами, исторические ACL объектов или стандартный ACL bucket-owner-full-control могут все еще действовать.

Organizations и политики управления сервисами (SCP)

AWS Organizations объединяет аккаунты в древовидную структуру из OU с управляющим аккаунтом в корне. Политики управления сервисами (Service Control Policies, SCP) — это защитные барьеры, применяемые к корню, OU или отдельному аккаунту. Они действуют для каждого пользователя и роли IAM в аккаунте — включая root-пользователя аккаунта — но не для самого управляющего аккаунта, поэтому рабочие нагрузки никогда не должны запускаться в нем.

Ключевая ментальная модель: SCP никогда не предоставляют разрешений. Они определяют максимальный набор действий, разрешенных в аккаунте. Действие разрешено только в том случае, если оно предоставлено политикой удостоверения или ресурса И не заблокировано какой-либо SCP на пути к аккаунту. Если у разработчика есть AdministratorAccess, но SCP запрещает ec2:RunInstances за пределами ap-southeast-2, запуск инстанса в us-east-1 завершится неудачей. И наоборот, SCP, разрешающая s3:*, сама по себе ничего не делает — пользователю все равно нужна политика IAM, предоставляющая s3:*. SCP фильтруют то, что уже разрешено в IAM; они являются «потолком», а не «полом».

Типичные сценарии использования SCP включают блокировку регионов, запрет на отключение CloudTrail или GuardDuty, запрет на удаление ключей KMS не через роль для экстренного доступа (break-glass role) и принудительное использование шифрования. Чтобы принудительно шифровать EBS при запуске, объедините два механизма: включите шифрование EBS по умолчанию в регионе (это настройка аккаунта для каждого региона, чтобы пользователям не приходилось менять скрипты), а также используйте SCP в качестве аудируемого защитного барьера:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Поскольку SCP применяются ко всему аккаунту, их не может обойти скомпрометированный администратор в дочернем аккаунте. Политики тегов (Tag policies) обеспечивают стандартизацию ключей тегов и их регистра (CostCenter, а не costcenter), чтобы распределение затрат и ABAC работали надежно. Organizations также поддерживает делегированное администрирование: вместо того чтобы запускать сервисы безопасности из управляющего аккаунта, делегируйте дочерний аккаунт («security» или «audit») в качестве администратора для GuardDuty, Security Hub, IAM Access Analyzer или Config, сохраняя разделение обязанностей.

KMS: ключи, политики ключей и модели владения

KMS различает ключевой материал по владению и контролю:

Ключ CMK управляется политикой ключа — политикой на основе ресурса, прикрепленной к ключу. В отличие от почти всех других ресурсов AWS, одних лишь политик IAM недостаточно для предоставления доступа к ключу KMS, если политика ключа сначала не делегирует полномочия IAM:

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Без этого утверждения (statement) ни одна политика IAM не сделает ключ доступным для использования. И политика ключа, и политика IAM вызывающей стороны должны разрешать операцию — это самая частая ошибка при работе с шифрованием. Предоставление kms:Decrypt в политике IAM необходимо, но недостаточно; если политика ключа не делегирует полномочия IAM или не указывает участника (principal), расшифровка завершится ошибкой AccessDenied даже для администратора.

Для сервисов, использующих KMS от вашего имени (EBS, S3, RDS, Lambda), вызывающей роли обычно требуются разрешения kms:GenerateDataKey, kms:Decrypt и часто kms:CreateGrant. Для управляемой группы узлов EKS, шифрующей тома EBS с помощью CMK, связанная с сервисом роль (service-linked role) Auto Scaling должна быть указана в политике ключа с разрешением kms:CreateGrant, иначе запуск инстансов будет молча завершаться неудачей.

Ротация управляемых клиентом ключей CMK требует явного включения — многие специалисты ошибочно полагают, что все ключи KMS ротируются автоматически:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

При ротации сохраняется тот же ID и псевдоним ключа; базовый ключевой материал меняется, но ранее зашифрованные данные остаются расшифровываемыми, поскольку KMS сохраняет старый материал для расшифровки существующих шифротекстов, в то время как новые операции записи используют свежий материал. Импортированный материал никогда не ротируется автоматически. KMS принудительно устанавливает обязательный период ожидания удаления от 7 до 30 дней; свяжите это с правилом EventBridge, отслеживающим события ScheduleKeyDeletion или DisableKey в CloudTrail, и направьте его в топик SNS для создания бессерверной системы оповещений без опроса (poll-free):

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

Внешние хранилища ключей (External Key Stores) расширяют модель, когда регуляторы требуют, чтобы ключевой материал физически находился в HSM, контролируемом клиентом. KMS перенаправляет криптографические операции на XKS-прокси, который взаимодействует с on-premise HSM; если HSM недоступен, расшифровка завершается неудачей — доступность становится ответственностью клиента.

Мультирегиональные ключи (Multi-Region Keys, MRK) имеют одинаковый ID ключа и ключевой материал в разных регионах, поэтому шифротекст, созданный в us-east-1, может быть напрямую расшифрован в eu-west-1. Это правильный подход для глобальных таблиц DynamoDB, межрегиональной репликации S3 с SSE-KMS и сценариев аварийного восстановления (DR), где резервный регион должен читать зашифрованные резервные копии. Стандартные однорегиональные ключи потребовали бы расшифровки и повторного шифрования во время репликации.

Межаккаунтный доступ к зашифрованным ресурсам

Предоставление доступа к зашифрованным AMI и снимкам EBS — один из самых частых сценариев сбоев при межаккаунтном взаимодействии, поскольку он требует четырех скоординированных действий: (1) использовать управляемый клиентом ключ CMK — управляемые AWS ключи не могут быть разделены; (2) добавить целевой аккаунт в качестве участника (principal) в политику ключа с разрешениями kms:Decrypt, kms:DescribeKey, kms:CreateGrant и kms:ReEncrypt*; (3) изменить разрешения на запуск/совместное использование AMI или снимка, включив в них этот аккаунт; и (4) убедиться, что участник IAM в целевом аккаунте также имеет эти разрешения KMS. Операция предоставления доступа будет выглядеть успешной, если вы пропустите шаг 2, но принимающий аккаунт не сможет расшифровать данные. Предполагать, что достаточно только предоставить доступ к AMI — это классическая ловушка.

Режимы шифрования на стороне сервера в S3

Когда требование включает автоматическую ежегодную ротацию, аудируемость в CloudTrail и минимизацию затрат на ключи, правильным ответом будет SSE-KMS с управляемым AWS ключом aws/s3 — он ротируется ежегодно бесплатно, и каждый вызов GenerateDataKey/Decrypt регистрируется в логах. SSE-S3 дешевле, но не оставляет следов использования ключа. Управляемый клиентом CMK добавляет $1/месяц к стоимости и ротируется только если вы включите ротацию.

Путаница между SSE-S3 и SSE-KMS — это классическая ловушка. SSE-S3 шифрует данные, но не предоставляет политики ключа, видимости в CloudTrail и способа для команды комплаенса администрировать ключ — поэтому он не соответствует ни одному требованию, упоминающему «администрирование», «контроль», «аудит» или «отзыв доступа» к ключу. И наоборот, выбор SSE-KMS, когда требуется только «шифрование неактивных данных с минимальным управлением», является избыточным решением (over-engineering).

Включение SSE-KMS само по себе не предотвращает несанкционированное чтение. Если политика бакета разрешает s3:GetObject, а политика ключа предоставляет kms:Decrypt тому же участнику (principal), объект будет доступен для чтения. Шифрование неактивных данных защищает от компрометации физических носителей и добавляет вторую проверку авторизации через политику ключа — оно не заменяет правильно настроенные политики бакетов, политики IAM, политики эндпоинтов VPC и условия aws:PrincipalOrgID.

Принудительное шифрование и TLS в S3

Сделать бакет «зашифрованным по умолчанию» недостаточно — клиенты могут пропустить или переопределить заголовок шифрования. Необходимо использовать два защитных механизма: шифрование бакета по умолчанию (добавляет заголовок, если клиент его не указал) и запрещающая политика бакета, которая отклоняет PutObject без необходимого заголовка, а также правило, запрещающее доступ без TLS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Условие aws:SecureTransport принудительно включает HTTPS, что обеспечивает «шифрование при передаче». В сочетании с SSE-KMS, использующим CMK, принадлежащий команде по соответствию требованиям, это является каноническим шаблоном для хранения PHI (защищенной медицинской информации).

Шифрование при передаче и при хранении

Шифрование при хранении (зашифрованные с помощью KMS тома EBS, хранилища RDS, объекты S3) и шифрование при передаче (TLS на сетевом уровне) — это независимые средства контроля, направленные на разные угрозы: кражу диска и перехват сетевого трафика соответственно. Включение KMS для инстанса RDS защищает базовое хранилище, но ничего не делает для сессии между клиентом и базой данных, которая по умолчанию может быть незашифрованной. Для RDS MySQL защита при передаче требует загрузки набора сертификатов CA для RDS, установки require_secure_transport=ON в группе параметров и подключения клиентов с флагом --ssl-ca=rds-combined-ca-bundle.pem. Считать, что «шифрование при хранении включено» достаточно — частая ошибка при аудитах.

Secrets Manager и Parameter Store

Статические пароли баз данных в конфигурационных файлах, переменных окружения или параметрах CloudFormation — основной вектор утечки учетных данных. AWS Secrets Manager хранит секреты в зашифрованном виде с помощью KMS, предоставляет к ним доступ через контролируемый IAM вызов GetSecretValue и, что критически важно, автоматически ротирует их с помощью Lambda-функции ротации. Для RDS, Aurora, Redshift и DocumentDB AWS предоставляет управляемую Lambda-функцию ротации, которая подключается к базе данных, генерирует новый пароль, атомарно обновляет и секрет, и пользователя БД, а также поддерживает стратегии для одного или нескольких пользователей. Для других систем вам нужно создать Lambda-функцию, реализующую четырехэтапный жизненный цикл: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Приложения кэшируют значение на короткое время (используя библиотеку кэширования AWS SDK) и переподключаются при сбое аутентификации. Ротация происходит незаметно, и для смены пароля не требуется развертывание.

SSM Parameter Store SecureString — это альтернатива, когда ротация не требуется, а стоимость является решающим фактором:

Для извлечения параметра SecureString необходимы разрешения ssm:GetParameter и kms:Decrypt для ключа. Забыть про разрешение для KMS — одна из самых распространенных ошибок конфигурации: политика IAM выглядит правильно, но вызов API завершается ошибкой при расшифровке.

На EC2, ECS, EKS и Lambda код должен принимать IAM-роль и вызывать GetSecretValue или GetParameter; никаких долгоживущих учетных данных на диске. Встраивание ключей доступа IAM-пользователя непосредственно в код приложения, даже в зашифрованном виде, нарушает принцип наименьших привилегий и усложняет ротацию.

Инструменты для аудита и расследований

CloudTrail записывает каждый вызов AWS API: кто, что, когда и откуда. Организационный трейл, включенный из управляющего аккаунта, собирает события из всех аккаунтов в один бакет S3, в идеале — в изолированном аккаунте безопасности с S3 Object Lock и MFA Delete. Это обеспечивает неизменяемую хронологию событий для расследований: какой субъект удалил том, какая роль изменила группу безопасности, какой ключ доступа вызвал ec2:RunInstances в 03:17 UTC. Дополните это логами и оповещениями CloudWatch (вход под root, изменения политик IAM) и AWS Config для получения состояния ресурсов на определенный момент времени и использования пакетов соответствия (conformance packs). Предотвратите несанкционированное изменение с помощью SCP, запрещающей cloudtrail:StopLogging и cloudtrail:DeleteTrail.

MFA Delete для бакета S3 требует, чтобы root-пользователь предоставил токен MFA для окончательного удаления версии объекта или отключения версионирования. Эту функцию может включить только root-пользователь через CLI, и она обеспечивает надежную защиту от программ-вымогателей и удаления инсайдерами.

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

Обнаружение угроз: GuardDuty, Security Hub, Detective

Amazon GuardDuty непрерывно анализирует VPC Flow Logs, DNS-логи, а также события управления и события данных CloudTrail, со специальными планами защиты для логов аудита EKS, событий данных S3, сканирования EBS на вредоносное ПО, сетевой активности Lambda и событий входа в RDS. GuardDuty RDS Protection выявляет аномальные попытки входа или атаки методом перебора (brute-force) на Aurora и RDS — поведение, которое группа безопасности не может отследить, поскольку на уровне L4 соединение является легитимным. Находки поступают на дашборды EventBridge, Security Hub и Detective.

Группы безопасности работают только на уровнях L3–L4. Группа, разрешающая 0.0.0.0/0 по порту 443, выполняет свою задачу, когда пересылает полезную нагрузку SQL-инъекции — именно для предотвращения таких атак и существует WAF. Эшелонированная оборона (Defense in depth) означает использование групп безопасности, WAF, Shield и GuardDuty вместе, где каждый инструмент защищает уровень, невидимый для других.

DDoS: Shield Standard и Advanced

AWS Shield Standard работает автоматически и бесплатно, защищая каждый аккаунт от распространенных атак уровней L3/L4 (SYN-флуд, атаки с отражением). Он работает в фоновом режиме без предоставления видимости, без возможности настраивать собственные меры по смягчению и без путей для вмешательства человека.

AWS Shield Advanced (3000 долларов в месяц на организацию плюс плата за передачу данных) требуется, когда в сценарии упоминаются проактивное взаимодействие, выделенная команда реагирования, защита от затрат на масштабирование, вызванное DDoS-атакой, или видимость атак почти в реальном времени. Он защищает CloudFront, Global Accelerator, ALB, CLB, Route 53 и Elastic IP, а также предоставляет круглосуточный доступ к команде реагирования Shield (Shield Response Team, SRT), предварительно авторизованной через IAM-роль, для создания правил WAF от вашего имени во время активной атаки. Когда архитектуре за ALB и Route 53 требуется управляемое обнаружение и реакция человека, одного лишь Shield Standard недостаточно; это распространенная ловушка. Advanced также предоставляет защиту от затрат на масштабирование, вызванное атаками. Когда упоминается «минимальные усилия по внедрению» и архитектура уже включает Global Accelerator или ALB, правильным ответом обычно является включить Shield Advanced и применить управляемые группы правил AWS WAF, а не создавать собственные функции Lambda@Edge или мигрировать CDN.

Защита на уровне приложений: AWS WAF

AWS WAF применяется к CloudFront, Application Load Balancer, API Gateway, AppSync, App Runner и пулам пользователей Cognito. Он не защищает Network Load Balancer напрямую (для этого перед ним нужно разместить CloudFront). Он инспектирует трафик L7 и применяет правила для защиты от SQL-инъекций, XSS, ограничений по размеру, геоблокировки, репутации IP и ограничения частоты запросов. AWS Managed Rules предоставляют готовые наборы правил, такие как AWSManagedRulesCommonRuleSet и AWSManagedRulesSQLiRuleSet, что избавляет от необходимости писать регулярные выражения.

Правила на основе частоты запросов (Rate-based rules) — это основная защита от HTTP-флуда и атак перебора учетных данных (credential stuffing). Они подсчитывают запросы за пятиминутный интервал с одного IP-адреса источника (или на основе перенаправленного заголовка) и автоматически блокируют нарушителей:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF — это не сервис для защиты от DDoS, эту роль выполняет Shield. WAF дополняет политики ресурсов (политики бакетов S3, запрещающие доступ без TLS; политики VPC endpoint, ограничивающие доступные бакеты) и сетевые средства контроля (группы безопасности, NACL) — неверная конфигурация на любом отдельном уровне не должна приводить к раскрытию данных.

Сетевая изоляция: Security Groups, NACL, Network Firewall

Внутри VPC защита является многоуровневой:

• Группы безопасности (Security groups) работают с отслеживанием состояния (stateful), применяются к ENI, поддерживают только разрешающие правила и оценивают все правила вместе. Ответный трафик разрешается автоматически, поэтому нет необходимости явно открывать эфемерные порты.
• Сетевые ACL (NACL) работают без отслеживания состояния (stateless), применяются к подсетям, поддерживают как разрешающие, так и запрещающие правила и оценивают их в числовом порядке. Поскольку они не отслеживают состояние, если вы разрешаете входящий трафик на порт 443, вы также должны разрешить исходящий трафик на эфемерные порты 1024–65535 для ответов. Если забыть об этом, все ответы будут незаметно отбрасываться. У групп безопасности такой проблемы нет.
• AWS Network Firewall обеспечивает глубокую инспекцию пакетов (DPI), правила IPS, совместимые с Suricata, и фильтрацию исходящего трафика на основе доменов, располагаясь между подсетями и IGW/TGW для централизованной проверки.

Предположение, что одних лишь групп безопасности достаточно, игнорирует угрозы на уровне подсетей и средства контроля радиуса поражения (blast radius); предположение, что достаточно одних NACL, игнорирует их работу без отслеживания состояния и грубую гранулярность.

Каталог ловушек

Забыта политика доверия (trust policy). Политика разрешений (permissions policy) роли предоставляет возможности; только политика доверия предоставляет право на принятие роли (assumability). Обе политики должны быть настроены для работы меж-аккаунтного доступа или доступа между сервисами — вызывающая сторона получит ошибку AccessDenied при вызове sts:AssumeRole независимо от того, насколько разрешающей является политика идентификации.

Политика IAM без соответствующей политики ключа. Разрешение kms:Decrypt в IAM необходимо, но недостаточно. Политика ключа должна либо явно указывать принципала, либо делегировать управление IAM с помощью Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. Совместное использование зашифрованных AMI/снэпшотов не сработает, если предоставить доступ только к AMI, но не обновить политику ключа.

SCPs рассматриваются как разрешающие политики. SCPs только ограничивают, но никогда не предоставляют права. SCP с Allow s3:* ничего не даст без соответствующей политики идентификации. И наоборот, разрешающая политика идентификации будет ограничена любым Deny в SCP на пути к аккаунту.

Предположение об автоматической ротации ключей KMS. Ключи, управляемые клиентом (CMK), не ротируются, пока это не будет включено; импортированный ключевой материал никогда не ротируется автоматически.

Выбор SSE-S3 для данных, требующих соответствия нормативам. У SSE-S3 нет политики ключа, нет видимости в CloudTrail и нет способа отозвать доступ — он не соответствует ни одному требованию, упоминающему «администрирование», «контроль», «аудит» или «отзыв» ключа.

Шифрование в состоянии покоя (at rest) считается достаточным. Шифрование в состоянии покоя и при передаче (in transit) — это независимые вещи. RDS с KMS все равно требует установки require_secure_transport=ON и валидации клиентского CA.

Указание аккаунтов по отдельности в политике бакета. Это не масштабируется и ломается при изменениях в организации. Используйте aws:PrincipalOrgID.

Жестко закодированные ключи доступа где бы то ни было. В user data, файлах .env, параметрах CloudFormation, Git — это всегда неправильно. Используйте профили инстансов, роли задач, роли выполнения, IRSA/Pod Identity или Roles Anywhere.

Использование root-пользователя для повседневной работы или применение к нему политик. Root-пользователя нельзя ограничить с помощью IAM или SCP; добавление политики к root-пользователю бессмысленно. Любой ответ, который это предлагает, заведомо неверный.

Использование IAM-пользователей для меж-аккаунтного доступа. IAM-пользователей нельзя «принять» из другого аккаунта; создайте роль в целевом аккаунте и позвольте принципалу из исходного аккаунта ее принять.

NLB за WAF. WAF не применяется к NLB. Если нужна фильтрация L7, разместите перед NLB сервис CloudFront.

В NACL отсутствуют правила для исходящего эфемерного трафика. NACL, работающие без отслеживания состояния, требуют явных правил для обратного пути. Отсутствие правила для исходящего трафика на порты 1024–65535 незаметно нарушит все ответы на входящие запросы на порт 443.

Использование Shield Standard для управляемого взаимодействия. Standard работает в пассивном режиме без доступа к SRT; только Advanced удовлетворяет требованиям «проактивного управляемого взаимодействия» или «защиты от затрат».

← Интеграция приложений · Все домены · Управление →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →