Глубже в IAM-evaluation, envelope-шифрование KMS и Secrets Manager

Как на самом деле принимается решение по запросу

С identity-политиками ты уже познакомился в базовом уроке по IAM: principal, action, resource, effect. Сеньорская модель — это evaluation, то, как AWS сводит несколько типов политик в одно «да/нет» для одного API-вызова. Стартовая точка никогда не нейтральна: каждый запрос по умолчанию — неявный deny. Дальше у правила три хода, и порядок фиксирован.

Первый: явный allow в любой применимой политике может перевернуть дефолт в «разрешено». Второй: типы политик комбинируются — identity-based и resource-based образуют объединение (allow в любой из них достаточно в пределах одного аккаунта), тогда как permissions boundaries и Service Control Policies пересекаются: запрос должен быть разрешён всеми применимыми категориями. Третий, перекрывающий всё: явный Deny где угодно всегда побеждает. Deny в identity-политике, resource-политике, boundary или SCP не перебивается никаким числом allow’ов. Это самое важное предложение во всём IAM, и большинство тикетов «почему у меня нет доступа?» упираются в явный deny, про который кто-то забыл.

Типы политик складываются в слои, у каждого своя роль:

• Identity-based политики — привязаны к пользователю, группе или роли; дают то, что может делать этот principal.
• Resource-based политики — привязаны к ресурсу (политика S3-бакета, key policy KMS, политика SQS-очереди); задают, кто может трогать этот ресурс, и уникально включают cross-account-доступ.
• Permissions boundaries — продвинутая identity-политика, задающая максимум прав, который principal вообще может иметь. Сама по себе ничего не даёт; она ограничивает. Эффективные права principal’а — это пересечение его identity-политик и его boundary.
• Service Control Policies (SCP) — общеорганизационные ограждения на уровне AWS Organizations. Тоже ничего не дают; они ограничивают, что могут делать все аккаунты и principal’ы под ними, как бы щедро ни выдавал права локальный админ.
• Session policies — передаются inline при assume роли; они дополнительно сужают права сессии на её время жизни.

Итого: эффективные права = (объединение allow’ов), пересечённое с каждой применимой boundary и каждым применимым SCP, минус любой явный deny. Wildcard-политика из истории давала всё, но без boundary и SCP пересечение никогда не сжималось — потолок был бесконечным, поэтому утёкший ключ унаследовал бесконечный охват. Boundary PowerUserAccess или SCP, запрещающий iam:* вне break-glass-роли и действия вне одобренных регионов, превратили бы катастрофу в локализованное неудобство.

Conditions делают least privilege настоящим

Statement с "Resource": "*" — это риск; statement, суженный Condition, — это least privilege. Condition-ключи проверяют контекст запроса и пропускают statement: aws:SourceIp (только из офисного CIDR), aws:PrincipalOrgID (только principal’ы твоей организации), aws:SecureTransport (только по TLS), aws:RequestedRegion или StringEquals по тегу ресурса (только ресурсы с тегом твоей команды). Statement применяется, только когда его conditions истинны. Эта политика позволяет principal’у читать один бакет, но только по TLS и только из известной сети — убери любое из условий, и запрос будет отклонён:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReportsTlsAndOffice",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-reports/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" },
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

Более глубокая привычка, которую дают conditions, — роли вместо долгоживущих ключей. Долгоживущий access-key — это статичный, экспортируемый, часто неротируемый credential, ровно то, что утекло в завязке. IAM-роль выдаёт временные credentials через AWS STS (Security Token Service — сервис временных токенов безопасности): короткоживущие, авто-истекающие, никогда не попадающие в репозиторий, потому что существуют лишь минуты. Любая рабочая нагрузка — EC2-инстанс (через instance profile), Lambda, ECS-таск, CI-джоб (через OIDC) — должна ассьюмить роль, а не носить ключ. Когда нужно проаудитить, что вообще выдано, IAM Access Analyzer помечает resource-политики, дающие доступ внешним аккаунтам, и подсвечивает неиспользуемые права, которые можно срезать.

Cross-account-доступ и confused deputy

Cross-account-доступ строится на ролях: роль в аккаунте B имеет trust policy, называющую аккаунт A допущенным к вызову sts:AssumeRole. Principal’ы аккаунта A ассьюмят роль и действуют в B с правами B. Но называние внешнего аккаунта в trust policy открывает классическую дыру — confused deputy. По AWS, это «проблема безопасности, где сущность, не имеющая прав выполнить действие, может вынудить более привилегированную сущность выполнить его». Если ты нанимаешь сторонний SaaS, который ассьюмит роль в аккаунтах многих клиентов, а твой role ARN не секрет, другой их клиент может передать вендору твой ARN и обманом заставить вендора («deputy») действовать на твоих ресурсах.

Фикс — условие ExternalId в trust policy. Вендор генерирует уникальный ID на клиента и передаёт его в каждом вызове AssumeRole; твоя trust policy требует твой ID, поэтому запрос с чужим ID не проходит:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "a1b2c3-unique-per-customer" }
    }
  }
}

Для AWS-сервисных principal’ов в cross-service-сценариях (например, CloudTrail, пишущий в твой бакет) аналогичные ограждения — условия aws:SourceArn и aws:SourceAccount, утверждающие, что сервис действует от имени ресурса или аккаунта, которого ты действительно ждёшь.

KMS: envelope-шифрование и key policies

Зачем шифрование на масштабе требует двух ключей вместо одного? Потому что 5-гигабайтный объект нельзя прогнать через облачный API, а раздать мастер-ключ — значит превратить каждую ротацию в катастрофу. Шифрование на масштабе использует envelope encryption (конверт-шифрование), и KMS построен вокруг него. KMS key (customer-managed key) живёт внутри hardware security module и «спроектирован так, чтобы никогда не экспортироваться из HSM в открытом виде». Байты ключа ты не получаешь никогда. Вместо этого ты вызываешь GenerateDataKey, и KMS возвращает data key в двух формах: открытую копию и копию, зашифрованную под твоим KMS key. Ты шифруешь свой большой payload локально открытым data key, тут же затираешь открытый ключ из памяти и хранишь зашифрованный data key рядом с шифротекстом. Чтобы расшифровать позже, ты отправляешь в KMS только зашифрованный data key, тот разворачивает его и возвращает открытый data key ровно для этой операции. Объёмные данные в KMS не ходят никогда; ходит только маленький data key. Поэтому шифрование S3, EBS и RDS масштабируется — каждый объект получает свой data key, и все они обёрнуты одним центральным KMS key.

Кто может использовать и управлять KMS key, задаёт его key policy — resource-based политика, которая, в отличие от большинства, является первичным контролем доступа к ключу. Опасный footgun: если key policy не даёт доступ root’у твоего аккаунта (или другому административному principal’у), ты можешь навсегда заблокировать всех от ключа — зашифрованные под ним данные становятся невосстановимыми, и даже AWS Support не перекроет политику. Помимо key policy, grants делегируют временное, узко ограниченное использование principal’у (часто AWS-сервису) без правки политики; aliases дают ключу стабильное удобное имя, чтобы ротировать материал, не меняя ссылки; автоматическая ротация (для customer-managed-ключей опциональна, по умолчанию ежегодная и теперь настраиваемая) генерирует новый backing-материал, сохраняя старые версии для расшифровки старых данных; а ключи бывают симметричными (один ключ шифрует и расшифровывает — дефолт для большинства данных) или асимметричными (пара public/private — для подписи или шифрования публичным ключом, который можно раздать). Key policy KMS выглядит так:

{
  "Version": "2012-10-17",
  "Id": "key-policy-app-data",
  "Statement": [
    {
      "Sid": "EnableRootAccountAdmin",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowAppToEncryptDecrypt",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/app-runtime" },
      "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" }
      }
    }
  ]
}

Убери первый statement — и ключ осиротел.

Secrets Manager против Parameter Store

Утёкший .env — это более глубокий урок: секреты не место в коде, образах или env-файлах, запечённых в сборку. AWS Secrets Manager хранит секреты, зашифрованные KMS, и — главная фича — поддерживает автоматическую ротацию. Для credential’ов базы он по расписанию запускает Lambda-функцию ротации: функция создаёт новый credential, обновляет базу и переключает staging-метки (AWSPENDING становится AWSCURRENT, старый — AWSPREVIOUS), так что вызывающие всегда читают живое значение без простоя. Он напрямую интегрируется с RDS, Redshift и DocumentDB.

Более дешёвый и простой собрат — SSM Parameter Store. Его параметры SecureString тоже зашифрованы KMS, у него нет помесячной платы за секрет, и он отлично подходит для конфигов плюс секретов, которые не нужно автоматически ротировать. Трейдофф: у Parameter Store нет встроенной ротации и нет нативной интеграции с базами. Сеньорский выбор: Secrets Manager — для credential’ов, которые должны ротироваться (базы, API-ключи с жизненным циклом); Parameter Store — для статичного конфига и редко меняющихся секретов, где важна цена.