AWS vs GCP vs Azure: иерархия организаций, IAM и управление ключами, бок о бок

Если вы уже знакомы с моделью управления одного облака, то вы знаете 80% других двух — концепции идентичны, меняется только терминология. Каждое облако заставляет вас ответить на одни и те же три вопроса, прежде чем вы выпустите что-то реальное: как организовать свои аккаунты, кому разрешено что делать и как создаются и контролируются мои ключи шифрования? Этот пост сопоставляет AWS, Google Cloud и Azure друг с другом, слой за слоем, и указывает на четыре места, где аналогия незаметно нарушается.

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

Три проблемы, которые решает каждое облако

Если отбросить маркетинг, то любое обсуждение управления состоит из трех слоев, наложенных друг на друга:

• Структура — вложенный набор контейнеров (организация → группировка → граница рабочей нагрузки), чтобы можно было изолировать среды, применять guardrails и разделять счета.
• Идентификация и разрешения — какие principals могут выполнять какие действия с какими ресурсами, плюс потолок, ограничивающий все, что может быть выдано любым грантом.
• Управление ключами — где хранятся криптографические ключи, кто может использовать их, и кто может администрировать их — два разных вопроса, которые люди постоянно путают.

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

Уровень 1 — иерархия ресурсов

Каждое облако имеет корневой organization node, опциональный middle grouping layer, который вы вкладываете для отделов или сред, и workload boundary, которая также служит единицей тарификации и blast radius. Политики, установленные высоко, передаются вниз во всех трех.

• Корневой узел организации — AWS: Organization с management account. GCP: organization node. Azure: tenant root management group, поддерживаемый Microsoft Entra tenant.
• Контейнер группировки (вложенный) — AWS: Organizational Unit (OU). GCP: folder. Azure: management group.
• Граница рабочей нагрузки и тарификации — AWS: account. GCP: project. Azure: subscription.
• Группировка ресурсов внутри границы — AWS: отсутствует (tags или per-account). GCP: отсутствует — project является контейнером. Azure: resource group, которая является обязательной; каждый ресурс находится ровно в одной.

Первое реальное расхождение кроется здесь. В AWS account является жесткой стеной — единицей blast radius по умолчанию — вот почему серьезные инфраструктуры AWS используют десятки или сотни account'ов. В GCP project выполняет две функции одновременно: это одновременно единица группировки и единица тарификации/изоляции, поэтому отдельной концепции "resource group" не существует. Azure добавляет четвертый уровень, которого нет у других — resource group — находящуюся под subscription в качестве контейнера жизненного цикла, который вы развертываете и удаляете как единое целое.

Уровень 2 — превентивные защитные механизмы (потолок разрешений)

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

• Ограничение того, что могут делать principals — AWS: Service Control Policy (SCP). GCP: Organization Policy constraints плюс IAM deny policies. Azure: Azure Policy.
• Ограничение того, кто может касаться ресурса — AWS: Resource Control Policy (RCP). GCP: IAM allow/deny policies на ресурсе. Azure: Azure Policy плюс deny assignments.
• Обеспечение конфигурации сервиса — AWS: declarative policies. GCP: Organization Policy constraints. Azure: Azure Policy (deny / audit / deployIfNotExists).

AWS разделил эту задачу на две части. SCP являются principal-centric ("наши люди не могут делать X"), а более новые RCP являются resource-centric ("никто — даже внешний account — не может касаться этого S3 bucket, KMS key или role, если они не находятся в нашей org"). Используемые вместе, они закрывают пробелы, которые ни один из них не охватывает по отдельности. Ловушка: в AWS и GCP SCP или Org Policy никогда не предоставляют ничего — они только вычитают. Azure устроен иначе, четко разделяя RBAC (разрешения) и Azure Policy (соответствие и конфигурация), так что задача guardrail в основном принадлежит Azure Policy, в то время как "кто может что делать" полностью относится к RBAC.

Уровень 3 — идентификация и разрешения

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

• Каталог идентификации — AWS: IAM плюс IAM Identity Center (SSO). GCP: Cloud Identity / Google Workspace плюс IAM. Azure: Microsoft Entra ID.
• Пакет разрешений ("роль") — AWS: IAM policy, управляемая или встроенная. GCP: IAM role — базовая, предопределенная или настраиваемая. Azure: RBAC role definition, встроенная или настраиваемая.
• Само предоставление — AWS: policy, прикрепленная к user, group или role. GCP: IAM binding (member + role, опционально condition) на ресурсе. Azure: role assignment (principal + role + scope).
• Условия и явный отказ — AWS: IAM condition keys и явный Deny. GCP: IAM Conditions и deny policies. Azure: RBAC conditions и deny assignments.

Самое глубокое отличие — где находится грант. В AWS вы в основном прикрепляете policy к identity — role или user — и разрешение перемещается вместе с ними. В GCP allow policy прикрепляется к ресурсу: вы предоставляете principal P role R на ресурсе X, и оно наследуется вниз по иерархии. Role assignment Azure напоминает binding GCP, но привязывается к scope в цепочке management-group → subscription → resource-group → resource. Усвойте "AWS = прикреплено к identity, GCP и Azure = прикреплено к ресурсу/scope", и большая часть путаницы между облаками исчезнет.

Уровень 3b — идентификация рабочей нагрузки (часть, о которой забывают)

Люди — не единственные principals. Ваш код также нуждается в идентификации, и правильная настройка является самым большим рычагом для least privilege. Золотое правило везде: никогда не используйте долгоживущие статические ключи — вместо этого прикрепите managed identity к рабочей нагрузке.

• Идентификация для работающей рабочей нагрузки — AWS: IAM role, предполагаемая через instance profile, task role или OIDC. GCP: service account, прикрепленный к ресурсу. Azure: managed identity, назначаемая системой или пользователем.
• Принципал приложения / не-человек — AWS: IAM role. GCP: service account. Azure: service principal.
• Безключевое доверие извне облака — AWS: IAM roles с OIDC/SAML federation. GCP: Workload Identity Federation. Azure: workload identity federation.

Обратите внимание на пересечение названий, которое всех сбивает с толку: "IAM role" в AWS — это workload identity, которую вы принимаете, тогда как "role" в GCP и Azure — это только permission bundle — identity представляет собой service account или managed identity. Одно и то же слово, две разные функции. GCP service-account keys и Azure service-principal secrets все еще существуют, но оба облака теперь активно продвигают keyless federation для всего, что работает за их периметром.

Уровень 4 — управление ключами

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

• Сервис — AWS: KMS, плюс CloudHSM для выделенного оборудования. GCP: Cloud KMS, плюс Cloud HSM / external. Azure: Key Vault, плюс Managed HSM для выделенного оборудования.
• Организация ключей — AWS: KMS keys (CMKs), aliases, multi-Region keys. GCP: key ring → key → key version. Azure: vault → key / secret / certificate.
• Контроль доступа — AWS: key policy + grants + IAM (все три объединяются). GCP: Cloud KMS IAM bindings на уровне project, key-ring или key. Azure: RBAC по умолчанию, или устаревшие access policies для каждого vault; Managed HSM использует собственный локальный RBAC.
• Разделение использования и администрирования — AWS: encrypt/decrypt actions против key-admin actions. GCP: cryptoKeyEncrypterDecrypter против admin roles. Azure: роли типа "Crypto User" против "Crypto Officer".

Актуальная деталь, которую стоит знать: для новых Key Vault с последних версий API Azure RBAC теперь является моделью доступа по умолчанию, а старые per-vault access policies — это устаревший путь, что наконец-то приводит Key Vault в соответствие с тем, как остальная часть Azure управляет разрешениями. AWS остается исключением: key policy KMS key является авторитетной и может предоставлять доступ независимо от IAM, поэтому классическая ловушка AWS — это блокировка доступа к ключу путем редактирования IAM и забывания о key policy. В GCP доступ к KMS — это обычный IAM, как и все остальное.

Где ментальная модель ломается

Четкое сопоставление опасно, если доверять ему слишком буквально. Четыре места, где аналогия дает сбой:

• "IAM role" означает две разные вещи. В AWS это принимаемая identity; в GCP и Azure "role" — это только permission set, при этом identity хранится отдельно. Никогда не переводите это дословно.
• AWS прикрепляет разрешения к identity; GCP и Azure прикрепляют их к ресурсам и scope. Ваш инстинкт "где мне искать для аудита доступа?" должен измениться, когда вы переключаетесь между облаками.
• Account, project и subscription не имеют одинакового blast radius. AWS account — это прочная стена; GCP project — это стена, счет и группировка в одном; Azure subscription — это в основном граница для тарификации и масштабирования, а resource group управляет повседневным жизненным циклом.
• Защитные механизмы вычитают, гранты добавляют — за исключением Azure, где задачи разделены. SCP и Org Policies только ограничивают разрешения; Azure ограничивает через Policy и предоставляет через RBAC как две отдельные системы.

Принцип, лежащий в основе всех трех, одинаков: least privilege, обеспечиваемый структурой. Размещайте guardrails высоко (org, OU, folder, management group), предоставляйте разрешения узко и предпочитайте roles статическим ключам, а также разделяйте "может использовать ключ" и "может администрировать ключ". Названия меняются в разных облаках; дисциплина — нет.

Практические выводы

• Разработайте иерархию до первой рабочей нагрузки. Позднее перестраивать accounts, projects или subscriptions будет сложно в каждом облаке.
• Устанавливайте высокие потолки, предоставляйте низкие гранты. SCP/RCP, Org Policy или Azure Policy на верхнем уровне; специфические roles на наиболее узком подходящем scope.
• По умолчанию используйте managed identities. IAM roles в AWS, service accounts в GCP, managed identities в Azure — и keyless federation для всего, что пересекает границу облака.
• Рассматривайте администрирование ключей как привилегированную операцию. Разделяйте encrypt/decrypt от rotate/disable/set-policy, и в AWS всегда проверяйте key policy, а не только IAM.
• Если вы используете Terraform или OpenTofu, эти примитивы — это именно то, что вы будете кодифицировать — aws_organizations_*, google_folder, azurerm_management_group, а также IAM/RBAC и KMS ресурсы под ними.

Изучите каждый уровень для каждого облака

Сертификации по архитектуре и безопасности каждого облака построены строго на иерархии ресурсов, IAM/RBAC и управлении ключами. Если вы хотите попрактиковаться с реальными экзаменационными вопросами, CertLabPro предлагает программу для каждой:

• AWS — Solutions Architect Associate (SAA-C03) для иерархии и IAM, а также Security Specialty (SCS-C03) для SCP, RCP и KMS. Новичок в AWS? Начните с Cloud Practitioner (CLF-C02).
• Google Cloud — Professional Cloud Architect для организации, folders, projects и IAM, а также Professional Cloud Security Engineer для IAM deny policies, Org Policy и Cloud KMS.
• Azure — Solutions Architect Expert (AZ-305) для management groups и управления, а также Security Engineer (AZ-500) для RBAC, Azure Policy и Key Vault. Новичок в Azure? Начните с Azure Fundamentals (AZ-900).

Итог

AWS, Google Cloud и Azure не так сильно отличаются, как может показаться по их документации. Каждое предоставляет иерархию для организации accounts, модель идентификации, построенную на принципале-роли-области действия, слой guardrail, который ограничивает допустимые разрешения, и сервис ключей, который разделяет использование ключей и их администрирование. Изучите эти четыре слоя один раз, и перевод между облаками будет в основном вопросом терминологии — а узнайте четыре места, где аналогия дает сбой, и вы избежите ошибок, которые скрывает терминология. Эти основы — это именно то, для чего созданы банки вопросов CertLabPro, охватывающие все три облака.