ストーリー
田
田中VPoE
セキュリティベースラインの中でも特に重要なのがID管理とアクセス制御だ。マルチクラウドでは「誰が」「どのクラウドの」「何に」アクセスできるかを統一的に管理しなければならない
あなた
各クラウドに別々のユーザーアカウントを作って管理するのは大変ですね
あ
田
田中VPoE
大変なだけでなく危険だ。退職者のアカウントがGCPだけ残っていた、AWSでは管理者権限だがAzureでは閲覧権限しかないはずが逆になっていた — IDの分散管理はセキュリティインシデントの温床になる
あなた
統一的なID管理基盤が必要ですね
あ
田
田中VPoE
その通り。ID Federationの設計を学ぼう
ID Federationの基本
用語の整理
| 用語 | 説明 | 例 |
|---|---|---|
| IdP（Identity Provider） | IDの発行・管理を行う側 | Entra ID, Okta, Google Workspace |
| SP（Service Provider） | IDを受け入れてサービスを提供する側 | AWS, GCP, Azure |
| Federation | 異なるシステム間でIDを信頼し共有する仕組み | IdP→SPへのSSO |
| SAML 2.0 | Web SSOの標準プロトコル | エンタープライズSSO |
| OIDC | OAuth 2.0ベースのID連携プロトコル | 最新のID連携 |
| SCIM | ユーザープロビジョニングの標準プロトコル | ユーザーの自動同期 |
マルチクラウドID連携アーキテクチャ
統一IdP（例: Entra ID / Okta）
│
├── SAML/OIDC ──→ AWS IAM Identity Center
│ ├── AWSアカウント1
│ ├── AWSアカウント2
│ └── AWSアカウント3
│
├── SAML/OIDC ──→ GCP Workforce Identity Federation
│ ├── GCPプロジェクト1
│ └── GCPプロジェクト2
│
└── SAML/OIDC ──→ Azure（直接統合）
├── Azureサブスクリプション1
└── Azureサブスクリプション2IdPの選定
主要IdP比較
| IdP | 強み | マルチクラウド対応 | コスト |
|---|---|---|---|
| Entra ID | Microsoft 365連携、Enterprise機能 | AWS/GCP/Azure全対応 | M365に含まれるプランあり |
| Okta | マルチクラウド中立、豊富な統合 | AWS/GCP/Azure全対応 | ユーザー数課金 |
| Google Workspace | GCPとの親和性 | GCPは直接、AWS/Azureも対応 | Workspace費用に含む |
| AWS IAM Identity Center | AWSに最適化 | AWSのみ（他は外部IdPが必要） | 無料 |
選定基準
| 基準 | 重み | 評価ポイント |
|---|---|---|
| マルチクラウド対応 | 30% | AWS/GCP/Azure全対応か |
| Enterprise機能 | 25% | 条件付きアクセス、リスクベース認証 |
| 既存環境との親和性 | 20% | 現在のID基盤との統合容易性 |
| コスト | 15% | ユーザーあたりのコスト |
| 運用容易性 | 10% | 管理の複雑さ |
ロールベースアクセス制御（RBAC）の統一
クラウド横断のロール設計
| 統一ロール | AWS | GCP | Azure |
|---|---|---|---|
| CloudAdmin | AdministratorAccess | roles/owner | Owner |
| CloudOperator | PowerUserAccess | roles/editor | Contributor |
| CloudViewer | ReadOnlyAccess | roles/viewer | Reader |
| SecurityAdmin | SecurityAudit | roles/iam.securityAdmin | Security Admin |
| FinOps | Billing + CostExplorer | roles/billing.viewer | Cost Management Reader |
| Developer | カスタムポリシー | カスタムロール | カスタムロール |
最小権限の原則の実装
| プラクティス | 説明 | 実装方法 |
|---|---|---|
| JIT（Just-In-Time）アクセス | 必要な時だけ権限を付与 | PIM（Privileged Identity Management） |
| 時間制限付きアクセス | 一定時間後に権限を自動失効 | セッションポリシー |
| 承認ベースアクセス | 管理者の承認を経て権限付与 | ワークフロー統合 |
| スコープ制限 | リソースやリージョンを限定 | ポリシー条件 |
サービスアカウントの管理
マルチクラウドのサービスアカウント
| 用途 | AWS | GCP | Azure |
|---|---|---|---|
| サービス間認証 | IAM Role（EC2/ECS用） | Service Account | Managed Identity |
| CI/CDパイプライン | IAM User + OIDC Provider | Workload Identity Federation | Federated Credentials |
| クラウド間連携 | AssumeRole + External ID | Workload Identity | Service Principal |
サービスアカウントのベストプラクティス
| プラクティス | 説明 |
|---|---|
| 長期認証情報の排除 | アクセスキーではなく、ロールベースの一時認証情報を使用 |
| 定期ローテーション | やむを得ず使う認証情報は90日以内にローテーション |
| 監査ログ | すべてのサービスアカウント操作を記録 |
| 棚卸し | 四半期ごとに未使用サービスアカウントを削除 |
| 命名規則 | クラウド横断で統一された命名規則 |
まとめ
| ポイント | 内容 |
|---|---|
| ID Federation | 統一IdPから全クラウドにSAML/OIDCでSSO |
| IdP選定 | マルチクラウド対応、Enterprise機能、コストを総合判断 |
| RBAC統一 | クラウド横断の統一ロール定義で一貫したアクセス制御 |
| サービスアカウント | 長期認証情報を排除し、一時認証情報を活用 |
チェックリスト
- ID Federationの基本概念を理解した
- IdPの選定基準を理解した
- クラウド横断のRBAC設計ができる
- サービスアカウントのベストプラクティスを理解した
次のステップへ
次は「ネットワークセキュリティ」を学びます。マルチクラウド環境のネットワーク分離と通信制御の設計を身につけましょう。
推定読了時間: 30分