はじめに
現在、Azure Security Engineer Associate (AZ-500) の取得に向けて勉強中です。 今回は学習範囲の中で、特に概念理解が重要かつ誤解しやすいと感じた テナントとサブスクリプションの構造 について、自分の理解整理のためにまとめます。
※普段はAWSを使用しているため、AWSの類似機能との比較も記載しています。
1. テナントとサブスクリプションとは
Azureのアイデンティティ基盤とリソース管理の階層構造は、以下の3要素で成り立っています。
- Tenant (テナント): AzureやMicrosoft365の契約インスタンス。組織全体を包む最大の枠組み。「ビル（建物）」そのものとイメージすると分かりやすかったです。
- Directory (Microsoft Entra ID): ユーザーやグループを管理する「ID台帳（ビルの住民台帳のようなイメージ）」。技術的にはTenantとDirectoryは1対1で対応しており、実体は同じもの（GUIDが同じ）。
- Subscription (サブスクリプション): Azureリソース（VMやDBなど）を管理する「論理的なコンテナ」であり、ガバナンスと課金の境界線。
- 1つのテナントには、複数のサブスクリプションを紐付けられる。
- 信頼関係: 1つのサブスクリプションは、ある時点で、たった1つのテナント（Directory）だけを信頼（Trust）する。
- 設計指針: クォータ制限（vCPU数など）がサブスクリプション単位でかかるため、「環境（Prod/Dev）× ワークロード（システム）」 単位で分割するのが一般的。
- 階層管理: 複数のサブスクリプションを Management Group で束ねることで、ポリシー（Azure Policy）や権限（RBAC）を一括適用できる（コスト集計も可能）。
2. AWS Organizations との違い（気づき）
AWSの Organizations / Accountに相当する構造だと考えていましたが、以下の点で決定的な違いがあると感じました。
- AWSの場合： AWSアカウントは「独立したID境界（AWSアカウント内でID:IAMが、ほぼ独立）」を持つ。IAMユーザーやIAMロールはアカウント内部に実体が存在するため、アカウントを別のOrganizationへ移動しても、内部のIAM設定は基本的に維持される。
- Azureの場合： サブスクリプションは「IDを持たないリソースコンテナ」。認証やIDの実態は、Tenant (Entra ID) に依存。そのため、サブスクリプションを別のテナントへ移行することは、認証基盤を丸ごとすげ替える破壊的な変更を意味する。
似ているようで「IDの実体の所在」が異なるため、移行戦略はAWSとAzureでは大きく異なると思います。
3. 実務での運用に関する考察（サブスクリプション移行）
M&Aや組織再編などで「サブスクリプションを別のテナントへ移行（Change Directory）する」場面では、以下の点に気をつける必要がありそうです。
-
リスクや注意点:
- RBACの完全消失: 旧テナントのユーザーは新テナントに存在しないため、移行時にすべての権限設定（RBAC）が削除される。移行直後は「誰もアクセスできない」状態になるため、新テナントのGlobal Adminによる救済措置（アクセス権限の昇格）が必要。
- Managed Identityの破損: リソースに紐付くManaged Identityが無効化される。再作成するとID（GUID）が変わるため、DBやStorage側での権限再設定が必要になり、システム停止のリスクが高い。
- Key Vaultの不整合: Key VaultはテナントIDを記憶しているため、移行後に手動でテナントIDを更新しないとアクセス不能になる。
- データ暗号化：データ暗号化を解除せずに移行した場合は、Key Valtが利用できないため、起動ができなくなり、データにアクセスできなくなる。
-
アーキテクト視点:
- 移行機能（Transfer）のリスク: AWSのアカウントのOrganization移行感覚で実行すると、「認証基盤のすげ替え」 によりRBAC、Managed Identity、Key Vault等の依存関係が崩壊し、長期のシステム停止を招く恐れがある。
- 推奨戦略:
- Re-build (IaC): Terraform/Bicep等で新テナントにクリーンな環境を構築し、データのみ移行する。（最も推奨）
- Re-host (DR活用): IaC化が困難な場合、Azure Site Recovery (ASR) 等のDR機能を使い、新テナントへVM等を複製・移動させる。
- Transfer (移行機能): 依存関係が極めて少ない、またはPoC環境の場合のみ検討するが、事前の影響調査（Managed Identityの再設定計画など）が必須。
移行においては、IaCの次点はDR機能の利用で、本当に無理な場合はSubscription移行になるかもしれない。ただし、BCP（事業継続：システムを止めない）やセキュリティを考慮すると、可能な限りはIaCを選択すべきだと感じた。
おわりに
今回はAzureの階層構造について整理しました。「ID管理がリソースの外にある」というAzureの設計思想を理解することが、セキュアなアーキテクチャへの第一歩だと感じました。AWSの知識をベースにしつつ、Azureならではの作法（Microsoft流のガバナンスの考え方など）に慣れていきたいと思います。
※本記事は、筆者の学習メモを元に、生成AIの支援を受けて執筆・構成しています。