M365/Entra IDが先にあり、後からAWS——多くの企業がこの順序でマルチクラウドになります。このとき最初に崩れるのが「ID管理」。人間のIDは1つのIdPに集約し、認証はIdP・認可は各クラウドで分担する。その考え方と、外部ベンダー・緊急用・rootといった特殊アカウントの扱いまでを実務目線で整理します。
01クラウドが増えるほど、効いてくるのは「ID」
多くの日本企業は、Microsoft 365 を使っている関係で Microsoft Entra ID（旧 Azure AD）が事実上の全社IdPになっています。そこへ後から AWS を導入し、さらに Azure や GCP、オンプレも並走する——という順序が典型です。
このとき最初に崩れやすいのがアイデンティティ（誰が・何にアクセスできるか）の管理です。AWSにIAMユーザーを人数分作り、Entraとは別に管理し、退職者のアカウントが消えずに残り、委託先には認証情報を共有し……という"二重・三重管理"は、監査でもセキュリティでも必ず問題になります。
全体像を1枚にするとこうなります。
以下、この構成の「考え方」と、実装で迷いやすいワークロード（マシン）のID、閉域ネットワークとの折り合い（何を外に出し、何を閉じたままにできるか）、そして外部ベンダー・緊急用・rootといった特殊なアカウントの扱いまで、2026年時点の公式仕様に沿って掘り下げます。姉妹編のAWS・Azure・GCP・オンプレ サービス対応表とあわせてどうぞ。
02大原則 — 認証はIdPに集約、認可は各クラウド
マルチ/ハイブリッドクラウド統制の出発点は、たった1つのルールに集約できます。「人間のIDは1つのIdPに置き、各クラウドはそこへフェデレーションする」。役割分担はこうです。
- 認証（誰か）はIdP側に一元化：サインイン、多要素認証（MFA）、条件付きアクセス、入退社のライフサイクル、アクセスレビュー。
- 認可（何ができるか）は各クラウド側：AWSは permission set／IAMポリシー、Azureはロール割り当て、GCPはIAM。
03Entra ID × AWS — IAM Identity Center に集約する
最も多い組み合わせ（M365/Entra ＋ AWS）を具体化します。AWS側の受け皿は AWS IAM Identity Center（旧 AWS SSO）。これを「AWS組織全体の唯一のフェデレーション先」に据えるのが、2026年時点のAWS推奨です。
- Entra管理センター ＞ エンタープライズ アプリケーションで、ギャラリーアプリ「AWS IAM Identity Center」を追加
- SAML 2.0でSSO（認証）：IAM Identity Center の識別ソースを「外部IdP」にし、双方のSAMLメタデータを相互登録
- SCIM 2.0で自動プロビジョニング：割り当てたユーザー/グループをEntra→AWSのIDストアへ自動同期
- permission set（IAMポリシーのテンプレート）× 対象AWSアカウントに割当。IAM Identity Center が各アカウントに専用ロールを自動生成・維持
- 構成は root の管理アカウントではなく、委任した Identity Center 管理アカウントで行う（AWS公式推奨）
この構成での「認証（Entra）」と「認可（AWS）」の分担を整理すると、きれいに分かれます。
| 項目 | Entra ID側（認証・ID源泉） | AWS側（認可・アクセス制御） |
|---|---|---|
| ユーザー認証・パスワード | ○ サインインを担う | 外部IdPに委譲 |
| 多要素認証（MFA） | ○ 必ずEntra側で強制 | 外部IdP構成では内蔵MFA不可 |
| 条件付きアクセス | ○ デバイス/場所/リスクで制御 | — |
| ユーザー/グループの源泉 | ○ SCIMで同期元 | 同期された読取専用のミラー |
| ガバナンス（レビュー/権利管理） | ○ Entra ID Governance | 結果がSCIMで伝播 |
| 認可（誰が何をできるか） | グループを渡すのみ | ○ permission set／IAMポリシー |
| 監査 | ○ サインインログ | ○ CloudTrail |
04ハイブリッド — オンプレADが源泉のとき
オンプレADを今も源泉にしている場合は、AD →（Entra Connect Sync / Cloud Sync）→ Entra ID → AWS と連鎖させます。「源泉はオンプレAD、そのクラウド投影がEntra」という関係を1本に保つのがポイントです。
- 同期方式は Entra Cloud Sync が推奨の既定（軽量エージェント・クラウド管理・複数エージェントで自動フェイルオーバー）。Microsoftも新機能を主にCloud Sync側で開発。
- Entra Connect Sync が必要なケース：大規模（1ドメイン15万オブジェクト超）、デバイス同期（Hybrid Azure AD Join）、高度な同期ルール、クロスフォレスト参照など。
- Windowsワークロードのドメイン参加が要るなら、AWS上は AWS Managed Microsoft AD 等を併用（人の認証フェデレーションとは別レイヤ）。
05同じ原則を Azure・GCP へ広げる
背骨が通れば、あとは同じ原則をAzureとGCPに広げるだけです。
- Azure：Entra ID がネイティブ（Azureの認証そのもの）。追加のフェデレーションは不要で、Entraを集約IdPに据える方針と自然に一致します。
- GCP：用途で2系統。①Google Cloud（コンソール/gcloud）だけなら Workforce Identity Federation（Google側にアカウントを持たず、Entraにフェデレーション）。②Google Workspaceや他のGoogleサービスも使うなら Cloud Identity／Workspace へプロビジョニング（SCIM）＋SAML SSO。両方要るならハイブリッド構成。
06ワークロード（マシン）のID — 静的キーを撲滅する
人のIDと同じくらい重要なのに見落とされがちなのが、アプリ・CI/CD・バッチといった「機械」のIDです。ここで長期アクセスキーをばら撒くと、漏洩の最大の入口になります。原則は「キーを発行せず、短期・自動失効の資格情報を使う」。
| シナリオ | 推奨方式（キーレス） | 要点 |
|---|---|---|
| CI/CD（GitHub Actions）→ AWS | IAM OIDCプロバイダ＋ロール（AssumeRoleWithWebIdentity） | JWTをSTSが検証し短期credentialを発行。信頼ポリシーで sub 条件を付けリポ/ブランチを限定 |
| CI/CD → Azure | Entra ワークロードIDフェデレーション | OIDCトークンをEntraが検証。issuer/subject/audienceが完全一致必須。シークレット不要 |
| CI/CD → GCP | Workload Identity Federation | サービスアカウントキー不要でトークン交換 |
| オンプレ/エッジ → AWS | IAM Roles Anywhere（X.509証明書） | 既存PKIのCAをトラストアンカーに登録。短期credentialを発行 |
| オンプレ/他環境 → GCP | Workload Identity Federation（OIDC/SAML/X.509 mTLS） | 公開OIDCエンドポイントが無くてもJWKSアップロードで可 |
| Azure内リソース → Azure | マネージドID（システム/ユーザー割当） | プラットフォームが資格情報を管理。Azure内の第一選択 |
| AWS内リソース → AWS | IAMロール（インスタンス/タスク/実行ロール） | メタデータ経由の一時credential。そもそもキー不要 |
| K8s Pod → クラウド | GKEは Workload Identity Federation for GKE／任意K8s→Entraはワークロード IDフェデレーション | クラスタのprojectedトークンを交換。クラウド非依存 |
混同注意：Workforce Identity Federation（＝人間）と Workload Identity Federation（＝マシン）は別製品。GCPの「Workload Identity Federation」と「〜for GKE」も別機能です。
gcloud auth／az login）で人間の一時credentialを使う。「キーを配らない」を既定にして、例外だけ管理するのが現実解です。07閉域ネットワークではどうするか — 何を外に出し、何を閉じるか
日本企業には根強い「閉域信仰」があります。ここで最初に整理しておきたいのは——閉じるべきは「データ経路（data plane）」であって、「認証（control plane）」ではないということ。SaaS型のIdP（Entra ID、IAM Identity Center、Googleのサインイン）は本質的に公開エンドポイントで、Private化する仕組みはそもそも提供されていません。ここを「全部閉域に」と考えると設計が詰みます。
正しい問いは「何をインターネットに出し（TLS＋認証で守り）、何を閉じたままにできるか」。切り分けるとこうなります。
| 対象 | 既定 | 閉域化の手段 |
|---|---|---|
| 人間のサインイン／IdP | 公開SaaS（不可避） | 私設化不可。条件付きアクセス（名前付き場所/デバイス準拠）・aws:SourceIp＋SCP/RCP・Access Context Manager で「社内NW・管理端末のみ」に制限 |
| クラウド管理API（大半） | 公開・認証必須 | Interface VPCエンドポイント（PrivateLink）／Private Link／Private Service Connect |
| 一時credential（AWS STS） | 公開・認証必須 | Interface Endpoint可（東京対応）→閉域からでも取得可。リージョナルSTSを使う |
| S3／DynamoDB | 公開・認証必須 | Gateway Endpoint（無料） |
| マネージドPaaS（RDS/Storage/SQL等） | 公開・認証必須 | PrivateLink／Private Endpoint／Private Service Access |
| 管理者のSSH／RDP | 公開にしがち | 開けないのが正解：SSM Session Manager／Azure Bastion／GCP IAP |
| ワークロード間・データ通信 | — | 私設サブネット・PrivateLink・専用線/VPN |
| オンプレ⇄クラウド | — | 専用線（Direct Connect／ExpressRoute／Cloud Interconnect）＋VPN |
| CRL/OCSP・OS更新・NTP等 | egressが発生 | 完全遮断は困難→egressプロキシ/FQDN許可（Network Firewall／Azure Firewall／Secure Web Proxy） |
ポイントを3つに絞ります。
- control plane も閉域化できる：STSを Interface Endpoint で私設化すれば、閉域VPCのワークロードもインターネット無しで一時credentialを取得できます（リージョナルSTSが条件）。ただしIAMはグローバルサービスで多くのリージョンで私設化できず、Cross-Region PrivateLink（2025年GA）や Transit Gateway で回します。
- 管理者アクセスは"開けない"のが正解：SSH/RDPをインターネットに晒さず、SSM Session Manager（アウトバウンド443のみ・踏み台/公開IP不要、3つのVPCエンドポイントで完全閉域）／Azure Bastion（Premiumで公開IP無し配置）／GCP IAP（外部IP無しVMへTLSトンネル）。
- 人間のログインだけは閉域化できない（SaaS型IdP）。が、条件付きアクセスの名前付き場所・デバイス準拠・Global Secure Accessで「管理下のネットワーク・端末からのみ」に絞れます。これが閉域信仰の実務的な落としどころです。
08アカウントの種類別・扱い方 — ここが統制の分かれ目
ここまでの原則を「アカウントの種類ごと」に落とすと、実務の判断表になります。ご相談の多い「ベンダーアカウントをどうするか」の実像は、この表の②〜⑥——つまり一般従業員以外をどう別扱いにするか、に集約されます。
| 種別 | 例 | 推奨する扱い |
|---|---|---|
| ①一般従業員 | 正社員の日常ID | Entraでライフサイクル管理・全員MFA必須・条件付きアクセス。AWSは IAM Identity Center 経由でSSO。長期キーは持たせない |
| ②特権管理者 | Global Admin／AWS管理系 | 常時付与しない。Entra PIM で必要時だけJIT昇格（MFA＋承認＋最大時間）。AWSはセッションを短く、管理系 permission set を分離 |
| ③外部委託ベンダー | 常駐SE／スポット委託 | Entra B2Bゲスト＋エンタイトルメント管理（申請→承認→有効期限→自動失効）＋アクセスレビュー。ゲストにも条件付きアクセスでMFA。共有アカウント禁止・個人単位の証跡 |
| ④緊急 break-glass | Entra緊急アカウント／AWS退避経路 | クラウド専用を2つ以上・フィッシング耐性認証・条件付きアクセス除外・PIM常時アクティブ・厳重監視・定期ドリル |
| ⑤root・管理アカウント | AWS Organizations 管理アカウント／各root | 管理アカウントにワークロード/データを置かない。rootはハードウェアMFA＋日常利用しない。中央管理でメンバーのroot資格情報を削除、必要時のみ短時間の sts:AssumeRoot |
| ⑥ワークロード・連携 | サービスプリンシパル／マネージドID／IAMロール | マネージドID／IAMロール＋一時認証情報を優先。長期キー/シークレットの直書き禁止。ワークロードIDにも棚卸し・リーク検知 |
sts:AssumeRoot セッション。「rootは封印する」を公式機能で作りやすくなっています。09外部委託先へのアクセス — 共有アカウントを渡さない
いちばん相談が多いのが外部委託（SIer／BP／業務委託）です。答えは明快で、「共有アカウントを渡さない。Entra B2Bゲスト＋時限＋最小権限＋個人単位の監査」。手順の要点はこうです。
- 委託先を「接続された組織」として登録（相手にEntraが無ければフェデレーションIdPやメールOTP認証も可）
- アクセスパッケージにリソース＋ポリシー（承認要否・レビュー・有効期限）を束ね、委託先の窓口をスポンサー（承認者）に設定
- 本人が自己申請→承認でB2Bゲストを自動作成。有効期限で自動失効し、最終割当を失うとサインインをブロック→既定30日後にゲスト自動削除
- アクセスレビューで定期棚卸し。「ゲストが他ゲストを招待」はNoに
- 条件付きアクセスでゲストにもMFA／認証強度を強制
- AWSへは個人のSSO ID → グループ → permission set で時限付与。セッション時間は業務に必要な最小限に
10緊急アクセス（break-glass）— IdP障害に備える独立経路
見落とされがちですが、ここが最重要です。認証もMFAもすべてIdPに寄せると、「IdPが落ちたら誰もログインできない」共倒れが起きます。だから、フェデレーションに依存しない独立の退避経路を必ず用意します。
- 想定する事故：外部IdP障害でサインイン不能／MFA手段の一斉不能／最後の管理者が退職・削除／PIMで全特権が承認必須なのに承認者が不在でテナントごとロックアウト
- クラウド専用アカウントを2つ以上（オンプレ／フェデレーションに一切依存させない）
- フィッシング耐性認証（FIDO2セキュリティキー／証明書）で、通常管理者とは別方式（共倒れ回避）
- ブロック系の条件付きアクセスから除外し、PIMは常時アクティブ（昇格の承認や条件に依存させない）
- 全サインインを常時監視（アラート）、四半期ごとに使えるかドリル、資格情報は分散保管
- AWS側：管理アカウントの root を退避経路として厳重保管。中央管理でメンバーの root を消しても、root パスワード再設定で回復できる導線を文書化
11現場でよく見るアンチパターン
最後に、繰り返し見る失敗を並べます。1つでも心当たりがあれば、それが着手点です。
- 人にIAMユーザーを配り、長期アクセスキーが各所に散らばっている
- サービス連携でアクセスキー／クライアントシークレットをコード・CIに直書き
- ベンダーに共有アカウント／共有パスワードを渡す（誰が何をしたか追えず、退場時の失効も漏れる）
- 委託ゲストを手動招待しっぱなしで、有効期限もレビューもない（プロジェクト終了後も残存）
- break-glassをMFA／フェデレーションに依存させる（いざ使えない）／逆に無条件除外のまま監視もない
- AWS root を日常利用、root にMFAなし・アクセスキー発行、root用メール受信箱の管理者が不在
- Organizations 管理アカウントにワークロード／データを配置（SCPが効かず、侵害の影響が全社に波及）
- 特権ロールを常時固定付与（PIMでのJIT化・承認・時限化をしていない）
12まとめ — 複雑さを束ねる背骨は「ID」
マルチ/ハイブリッドクラウドは、サービスの数だけ複雑になります。それを1本に束ねる背骨が「ID」です。人間のIDは1つのIdPに集約し、認証はIdP・認可は各クラウド。機械のIDはキーレスに。そして外部委託・緊急用・rootといった特殊アカウントは、最初から別扱いを設計に組み込む——これだけで、統制の大半は片づきます。
EMWは、Entraを軸にした AWS／Azure／GCP・オンプレのID統制設計、外部委託や緊急アクセスの整備を実務で扱ってきました。「今どこが二重管理になっているか」の棚卸しから、一緒に畳んでいきます。
関連して、アカウントの分け方はAWSアカウントの考え方（マルチアカウント戦略）、踏み台・特権アクセスの具体設計はAWSにおける踏み台環境の考え方、サービス名の対応はAWS・Azure・GCP・オンプレ サービス対応表もあわせてどうぞ。
13よくある質問（FAQ）
Entra IDとAWSはどう連携させますか？
AWS IAM Identity Center を唯一のフェデレーション先にし、SAML 2.0でSSO、SCIM 2.0でユーザー/グループを自動同期します。認証はEntra側（MFA・条件付きアクセス）、認可はAWSのpermission setで分担します。
閉域ネットワークでもクラウドのIdPは使えますか？
使えます。IdPのサインイン自体は公開SaaSで私設化できませんが、条件付きアクセスの名前付き場所・デバイス準拠で「社内ネットワーク・管理端末のみ」に制限します。閉じるべきはデータ経路であって認証ではありません。
外部ベンダーにはどうアクセスを渡すべきですか？
共有アカウントは渡さず、Microsoft Entra B2Bゲストで個人IDを発行し、有効期限・最小権限・個人単位の監査を付けます。エンタイトルメント管理でプロジェクト終了時に自動失効する設計にします。
静的アクセスキーは使ってよいですか？
原則使いません。クラウド内はIAMロール/マネージドID、環境外（CI/CD・他クラウド・オンプレ）からはOIDCフェデレーションやAWS IAM Roles Anywhereで、短期・自動失効の資格情報を使います。
Entra ID を軸にした AWS/Azure/GCP・オンプレのID統制、外部委託や緊急アクセスの設計でお困りなら、現状の棚卸しからお手伝いします。「二重管理をどう畳むか」を一緒に描きましょう。
相談する