第6回 Entra IDをまたいだアクセスの自動化 / Microsoft Entra IDの認証の話（Azure周りの自動化編）

この記事の内容

  • Entra IDが1つの場合の自動化パターンのおさらい
  • Entra IDが複数テナントにまたがる場合の課題と対処法
  • ゲスト招待を使った人間向けのクロステナントアクセス
  • サービスプリンシパルとKey Vaultを組み合わせた自動化の仕組み
  • Managed Identityを活用した安全な証明書取得フロー

はじめに

本記事は「Azure周りの自動化編 ─ Microsoft Entra IDの認証の話」シリーズの第6回です。全7回のシリーズとなっており、Azureの処理を自動化したい・対話的な認証を省きたい・しかしパスワードをスクリプトに平文で書くのは避けたい、そういった方を対象にしています。

前回までの動画では、Entra IDが1つの場合における技術的なパターンを一通り解説しました。今回はそれを踏まえた上で、Entra IDが複数テナントにまたがる場合の具体的なやり方について解説します。この内容はパズルを解くような感覚で理解が必要な部分もありますが、順を追って整理していきます。

Entra IDが1つの場合のおさらい

まず、Entra IDテナントが1つだけの場合のパターンをおさらいします。

  • 対話的な認証（ユーザープリンシパル）: ユーザーが対話的にトークンを取得し、APIに投げる。自動化には不向きです。
  • サービスプリンシパル + 資格情報: サービスプリンシパルを使って資格情報を渡し、トークンを取得してサービスを呼び出す。ただし資格情報の保管場所の安全性が課題になります。
  • Key Vault + 証明書 + Managed Identity: Key Vault内で証明書を生成し、Managed IdentityでKey Vaultから証明書を安全に取得。その資格情報でトークンを取得してサービスを叩きます。
  • Managed Identityのみ: Key Vaultを介さずにManaged Identityだけでトークンを取得してサービスを呼び出すシンプルなパターンもあります。

テナントが1つであれば、これらのパターンで対応できます。

Entra IDが複数の場合の課題

Entra IDテナントが複数登場するシナリオはより複雑です。たとえば、あるテナント（アクセス元）のユーザーや自動化の仕組みが、別のテナント（アクセス先）に存在するサービスを操作したい場合が該当します。

別テナントのリソースへのアクセスは、通常の認証フローだけでは対応できません。以下で2つのアプローチを説明します。

アプローチ①：ゲスト招待（人間向け）

人間が別テナントのサービスにアクセスする場合、ゲスト招待という方法が使えます。

仕組みは次のとおりです。

  1. アクセス先テナントの管理者が、アクセス元テナントのユーザーをゲストとして招待する
  2. 招待されたユーザーは自身のアカウント（ID・パスワード・多要素認証）でアクセス先テナントに認証する
  3. 認証先テナントが変わるだけで、認証の仕組み自体はいつものものと同じ
  4. 結果として、1つのテナント内で完結しているのと同じ状態になる

ゲストを招待すれば、Entra IDが1つのときと同じフローで処理できるというのがこのアプローチのポイントです。

ただし、これは人間による対話的な操作を前提としたアプローチです。自動化には向きません。

アプローチ②：サービスプリンシパル + Key Vault（自動化向け）

クロステナント環境での自動化には、サービスプリンシパルとKey Vaultを組み合わせる方法が有効です。以下にそのフローを説明します。

ステップ1：アクセス先テナントの準備

アクセス先テナントの管理者が行う作業です。

  1. サービスプリンシパルを作成する
  2. そのサービスプリンシパルに対して、対象サービスへのアクセス権限を割り当てる

ステップ2：アクセス元テナントの準備

アクセス元テナントの管理者が行う作業です。

  1. Key Vaultを作成する
  2. Key Vault上で証明書を生成する（秘密鍵はKey Vault内に保管）

ステップ3：公開鍵の共有

両テナントの管理者が連携して行う作業です。

  1. アクセス元の管理者がKey Vaultで生成した証明書の公開鍵を、アクセス先の管理者に渡す（メール等で安全に共有可能）
  2. アクセス先の管理者が、その公開鍵をサービスプリンシパルの証明書認証設定にアップロードする

この設定により、「秘密鍵を持っている者が、そのサービスプリンシパルとして認証できる」という状態が整います。

ステップ4：自動化フローの実行

実際の自動化実行時のフローです。

  1. アクセス元の自動化の仕組み（例：Azure上のVM、App Serviceなど）がManaged IdentityでKey Vaultにアクセスする
  2. Key Vaultから証明書（秘密鍵を含む）を取得する
  3. その証明書を使って、アクセス先テナントのサービスプリンシパルとして認証する
  4. アクセス先テナントのEntra IDからトークンを取得する
  5. そのトークンを使ってアクセス先のサービスを呼び出す
[[アアク自KクE対セ動eセn象ス化yスtサ元の先rーテ仕↓V↓テa↓ビナ組aナスンみ証u証ンIトト明l明トDー](書t書]クMを認(ンa取(証サ取n得証ー得a明ビg書スe・プd秘リ密ンI鍵シdをパe保ルn管とt)しiてt認y証))

この仕組みにより、パスワードや資格情報をスクリプトに記載することなく、テナントをまたいだ自動化処理を安全に実行できます。

前提条件

このアプローチが機能する前提として、アクセス先テナント側がアクセス元テナントのサービスを信頼していることが必要です。テナント間の信頼関係と権限の付与が大前提となります。

まとめ

今回は、Entra IDが複数テナントにまたがる場合のクロステナントアクセスの自動化について解説しました。

  • 人間による対話的なアクセスにはゲスト招待が有効です。ゲストとして招待することで、アクセス先テナントでも通常の認証フローを利用できます。
  • 自動化にはサービスプリンシパル + Key Vault + Managed Identityの組み合わせが有効です。公開鍵をテナント間で共有し、秘密鍵はKey Vaultに安全に保管することで、クロステナントでも安全な自動化を実現できます。

この仕組みは一見複雑に見えますが、「誰が証明書を持ち、誰が公開鍵を設定するか」という役割分担を整理すると理解しやすくなります。ぜひ実際に手を動かして試してみてください。

次回は本シリーズの最終回です。これまで触れていなかった重要な内容が解説される予定となっています。