IAM и политики доступа

В 2019 году Capital One потеряла данные 100 миллионов клиентов: бывший сотрудник AWS обнаружил mis-configured WAF, AssumeRole-нул в роль с доступом ко всему S3 и выгрузил кредитные истории. Расследование показало: IAM-политика, привязанная к роли, разрешала ListBuckets и GetObject на любой ресурс. Никакой Condition по IP, никакой явный Deny, никаких аудит-границ. Закон наименьших привилегий не соблюдался. IAM в облаке - не бюрократия, а фундамент безопасности; ошибка в trust policy или Action: '*' может стоить компании миллиардов.

• **Netflix:** каждый микросервис работает под своей IAM-ролью, доступ к данным и секретам контролируется condition-keys по тегам команд
• **HashiCorp Vault / AWS Secrets Manager:** заменяют долгоживущие credentials в БД и сторонних API на динамические, выдаваемые по запросу
• **GitHub Actions OIDC + AWS IAM Roles:** стандарт CI/CD в 2024-2025 - нулевое количество AWS-ключей в GitHub Secrets по корпоративной политике

IAM роли: краткоживущие учётки вместо ключей

В 2017 году Uber потеряла данные 57 миллионов пользователей: подрядчик закоммитил AWS access keys в публичный GitHub. Тот же класс инцидентов повторялся годами в Snapchat, Capital One, Imperva. Корень один - долгоживущие пары access key + secret, которые лежат в репозиториях, на ноутбуках инженеров, в CI-конфигах. AWS IAM Roles - механизм, заменяющий эти ключи краткоживущими токенами STS. EC2-инстанс, Lambda-функция или контейнер ECS получают временные credentials автоматически через instance metadata service. Никаких ключей в коде, ротация - встроенная, отзыв роли мгновенный.

Роль состоит из двух частей: trust policy (кому разрешено принимать роль через AssumeRole) и permission policies (что разрешено делать). EC2-инстанс получает роль через instance profile, Lambda - через execution role, ECS-task - через task role. AWS STS выдаёт временные credentials (по умолчанию на 1 час, до 12), которые автоматически ротируются runtime'ом. Это база zero-trust подхода в облаке: identity не привязан к статичному секрету.

JSON-политики: Effect, Action, Resource, Condition

IAM-политика - JSON-документ, описывающий разрешения. Каждое заявление (Statement) содержит четыре ключевых поля: Effect (Allow или Deny), Action (что разрешено - 's3:GetObject', 'ec2:RunInstances'), Resource (на чём - ARN ресурса), Condition (при каких условиях - IP, время, тег). Логика вычисления политик: явный Deny перекрывает любой Allow; отсутствие явного Allow равноценно Deny. Это закон наименьших привилегий, выраженный в правилах: всё, что не разрешено явно, запрещено.

Action поддерживает wildcard: 's3:Get*' покрывает GetObject, GetObjectAcl, GetBucketPolicy. Resource - ARN с возможным шаблоном: 'arn:aws:s3:::company-logs/*' - все объекты внутри bucket'а company-logs. Condition - типовой механизм усиления: aws:SourceIp ограничивает доступ по IP, aws:RequestedRegion - по региону, aws:PrincipalTag/team - по тегу принципала. Композиция этих полей даёт чрезвычайно гибкую модель: 'разработчик из команды backend может писать только в свой dev-bucket, и только из офисного IP, и только в рабочее время'.

Cross-account доступ: AssumeRole между аккаунтами

Крупная компания не живёт в одном AWS-аккаунте. Production отдельно от dev, биллинг отдельно от data lake, security tooling отдельно от прикладных сервисов. Сценарий: команда analytics из аккаунта 333333333333 должна читать S3-bucket в production-аккаунте 999999999999. Cross-account IAM решает это без копирования ключей: production создаёт роль с trust policy, разрешающей AssumeRole от identity analytics-аккаунта. Identity из analytics вызывает sts:AssumeRole, получает временные credentials production-аккаунта и работает от его имени. Никаких ключей не передаётся - только описание доверия в JSON.

External ID - дополнительный механизм против confused deputy attack: при доверии стороннему вендору (Datadog, Snowflake) trust policy требует не только правильного аккаунта, но и согласованного external ID. Это защищает от ситуации, когда злоумышленник сумел убедить вендора провести AssumeRole в чужой целевой аккаунт. AWS Organizations + SCP добавляют поверх ещё один слой: даже если в дочернем аккаунте создана роль с широкими правами, Service Control Policy организации может запретить целые действия (например, DeleteBucket в любых production-аккаунтах).

Federation: SSO и identity-provider в облаке

В компании на 5000 человек заводить 5000 IAM users в AWS - провал управления. Сотрудник пришёл - надо создать; уволился - надо отозвать; сменил команду - надо переназначить permission boundary. Federation решает это, оставляя источником истины корпоративный identity provider (Okta, Azure AD, Google Workspace, AWS IAM Identity Center). Сотрудник заходит в IdP, получает SAML- или OIDC-токен, AWS STS обменивает его на временные credentials через AssumeRoleWithSAML / AssumeRoleWithWebIdentity. Никаких локальных учёток в AWS - identity один и тот же, что для Slack, GitHub и Notion.

Workload identity federation (AssumeRoleWithWebIdentity) аналогично решает аутентификацию для workload-ов. GitHub Actions запускают CI, представляются как 'repo:org/repo, branch:main', AWS обменивает OIDC-токен на STS credentials. Никаких хранимых ключей в GitHub Secrets, никакого долгоживущего deploy-юзера. Это стандарт 2024 года: AWS, GCP, Azure, Vault - все поддерживают federation с GitHub, GitLab и Kubernetes ServiceAccount-ами.

Ключевые идеи

• **IAM роли заменяют статичные ключи** краткоживущими STS-токенами; нет credentials в коде - нет утечки через GitHub.
• **JSON-политика Effect/Action/Resource/Condition** - закон наименьших привилегий в правилах; явный Deny всегда перекрывает Allow.
• **Cross-account AssumeRole** даёт доступ между аккаунтами без передачи ключей; External ID защищает от confused deputy у SaaS-вендоров.
• **Federation (SAML/OIDC)** делает источником истины корпоративный IdP или GitHub OIDC - локальных учёток в AWS почти не остаётся.

Связанные темы

IAM - сквозной контур безопасности облака, пересекающийся с сетью, биллингом и аудитом.

• DNS и Route 53 — IAM-политики управляют доступом к зонам Route 53 точно так же, как к S3 и EC2
• Cloud сети и VPC — Condition aws:SourceVpc и aws:SourceIp ограничивают IAM-разрешения сетевым контуром

Вопросы для размышления

• Capital One потеряла данные из-за избыточных permission'ов IAM-роли, не из-за публичного бакета. Как организовать процесс ревью политик, чтобы Action: '*' не проскакивал в продакшен?
• Federation через OIDC убирает долгоживущие ключи из CI. Какие команды и какие задачи всё ещё нуждаются в IAM users с access keys, и можно ли их полностью отучить?
• External ID защищает от confused deputy у вендоров. Какие ещё категории cross-account доступа требуют дополнительных условий в trust policy?

Связанные уроки

• cloud-12 — Предыдущий cloud урок - контекст для IAM
• cloud-14 — KMS использует IAM policy для key access control
• cloud-15 — Compliance требует IAM audit trail
• bt-28-security — IAM принципы применяются к API security
• net-44-zero-trust — Zero Trust = IAM everywhere, без периметра
• prob-04-bayes — Policy evaluation - условный вывод разрешений
• devops-13