Azure Lighthouse

解決する課題

• マネージドサービス事業者（MSP）が、顧客ごとにテナントを切り替えてサインインし直す運用を強いられ、横断的な管理が難しい
• 委任のために顧客テナントへゲストユーザー（B2B）を多数招待すると、ID 管理やオフボーディングが煩雑になる
• 複数の顧客サブスクリプションを、自社の運用チームから 1 つの管理面でまとめて統制したい
• 委任した権限が広すぎる/恒久的になりがちで、最小権限や監査が効きにくい
• 自社内に複数テナントがある大企業でも、運用部門のテナントから各事業テナントを横断管理したい

主要概念と用語

• Azure Lighthouse: 顧客（管理対象）テナントのリソースを、サービスプロバイダー（管理側）テナントのアイデンティティから横断的に管理できるようにする委任の仕組み。テナントを切り替えずに複数顧客を扱える
• 委任リソース管理（delegated resource management）: 管理側テナントのユーザー・グループ・サービスプリンシパルに、顧客側のサブスクリプションまたはリソースグループに対する Azure RBAC ロールを射影する仕組み。実体のリソースは顧客テナントに残る
• サービスプロバイダーテナント / 顧客テナント: 管理する側と、管理される側の Entra ID テナント。Lighthouse はこの 2 テナント間の権限委任を定義する
• オファー（マネージドサービスオファー）: 委任の定義を ARM テンプレートまたは Marketplace の公開オファーとして記述したもの。どのプリンシパルにどのロールをどの範囲で渡すかを宣言する
• 承認者（authorizations）: 委任で渡す「プリンシパル ID とロール定義 ID の組」のリスト。原則として個人ではなく Entra ID グループに対して付与する
• My customers / My service providers: 管理側ポータルで委任先の顧客一覧を見る画面と、顧客側で委任元のプロバイダーを確認・取り消す画面

仕様・制限・クォータ

• 委任は サブスクリプション単位またはリソースグループ単位で行う。管理グループ全体をそのまま 1 操作で委任することはできない
• 委任で渡せるのは Azure RBAC（コントロールプレーン）の権限が中心で、所有者（Owner）ロールは原則として委任できない。ロール割り当てを伴う一部のロールには制約がある
• データプレーンの操作（ストレージ内データへのアクセスなど）は、委任で扱える範囲がリソース種別ごとに異なるため設計時に確認する
• Lighthouse 自体の利用に追加料金は発生しない。課金は管理対象リソースを使った顧客側で従来どおり発生する
• 委任は顧客側がいつでも取り消せる。管理側は委任の追加・更新に新しいオファーの再デプロイが必要

内部の仕組み

Lighthouse の中核は 委任リソース管理です。顧客テナントで「マネージドサービスオファー」を ARM テンプレートとしてデプロイすると、そのテンプレートに書かれた **承認者（プリンシパル ID とロール定義 ID の組）**が、指定したサブスクリプションまたはリソースグループのスコープに登録されます。

これにより、管理側テナントのユーザーやグループは、自テナントにサインインしたまま顧客スコープのリソースを操作できます。権限の評価は通常の Azure RBAC と同じ経路で行われ、顧客リソースに対する操作は管理側プリンシパルの ID で監査ログに記録されます。

• 顧客テナントへゲスト招待（B2B）を行わずに横断管理が成立する点が、従来のゲスト方式との大きな違い
• 委任の定義はテンプレートに集約されるため、多数の顧客へ同じ権限セットを再現性高く配布できる
• 顧客は My service providers から委任内容を確認し、不要になれば委任を取り消せる（取り消すと管理側からの可視性も即座に失われる）

設計パターン / ベストプラクティス

• グループに付与する: 承認者は個人ユーザーではなく Entra ID グループに対して設定する。入退社や担当変更をグループメンバーシップで吸収でき、オファーの再デプロイが不要になる
• 最小権限の委任: 必要なロール（閲覧者・共同作成者・特定の組み込みロール）を、必要なスコープ（特定のリソースグループ）だけに絞って渡す。Owner は委任しない
• 昇格が要る作業は JIT で: 恒久的な高権限を渡さず、必要時のみ **Entra ID PIM（Privileged Identity Management）**で資格を昇格させる運用と組み合わせる
• オファーのコード管理: 委任定義の ARM テンプレートをリポジトリで管理し IaC として配布する。顧客横断で権限セットを統一できる
• 管理グループで顧客横断を整理: 管理側では、委任された複数顧客のサブスクリプションを自社の運用ビューで束ねて監視・統制する

運用・監視

• Azure Monitor / Log Analytics を顧客スコープへ広げ、複数顧客のメトリクス・ログを管理側テナントから横断的に収集・可視化する
• Azure Resource Graph で委任された全顧客のリソースを横断クエリし、棚卸しやコンプライアンス確認をまとめて行う
• アクティビティログで、管理側プリンシパルが顧客リソースに対して行った操作を監査する。誰がどの顧客に何をしたかを追跡できる
• My customers / My service providers で委任状態を定期確認し、不要な委任や期限切れのオファーを整理する
• Azure Policy を委任スコープに適用し、複数顧客に同じコンプライアンス基準を横断強制する

コスト

Azure Lighthouse そのものの利用に追加料金は発生しません。委任を作るのも、管理側テナントから横断管理を行うのも無償です。費用は従来どおり、実際にリソースを消費した顧客側のサブスクリプションで発生します。つまり Lighthouse は課金モデルを変えるものではなく、あくまで「管理面の見え方と権限の射影」を提供する仕組みです。一方で、横断管理に伴って利用する Azure Monitor のログ取り込みや Defender for Cloud の保護などは、それぞれの機能側で課金される点に注意してください。変動する単価は公式の料金ページで都度確認します。

セキュリティ

• 委任は Azure RBAC ベースで、最小権限の原則をそのまま適用できる。閲覧者・共同作成者など必要なロールだけを必要なスコープに渡す
• 所有者（Owner）ロールは委任できないため、管理側が顧客のアクセス制御そのものを掌握してしまう事態を構造的に防げる
• 承認者はEntra ID グループに付与し、メンバー変更で権限の付け外しを管理する。個人付与は退職・異動時の取り残しを生みやすい
• 顧客リソースへの操作は管理側プリンシパルの ID で監査ログに残るため、責任分界点が明確になる
• 高権限が必要な作業は PIM による Just-In-Time 昇格と組み合わせ、恒久的な強い権限の保持を避ける

関連サービス・比較

Lighthouse と混同しやすいのが Azure Arc です。Arc は「Azure 外の資源を Azure リソースとして投影する」のに対し、Lighthouse は「別テナントの Azure リソースへ管理権限を射影する」もので、解決する軸が異なります。両者は併用でき、Arc で投影したハイブリッド資源を Lighthouse 経由で横断管理する構成も成り立ちます。

ハンズオン / CLI例

# 委任された顧客（管理対象スコープ）の一覧を管理側テナントから確認
az managedservices assignment list -o table

# 委任の定義（マネージドサービス定義）を一覧表示
az managedservices definition list -o table

# 委任された顧客サブスクリプションを指定して、横断的にリソースを確認
az resource list \
  --subscription "<customer-subscription-id>" \
  --query "[].{name:name, type:type, rg:resourceGroup}" -o table

# Resource Graph で複数の委任スコープを横断クエリ（拡張機能が必要）
az extension add --name resource-graph
az graph query -q "Resources | summarize count() by subscriptionId, type"

# 委任の登録自体は顧客テナントで ARM テンプレートをデプロイして行う
# （管理側プリンシパルのオブジェクト ID とロール定義 ID を承認者として記述）
az deployment sub create \
  --name lighthouse-delegation \
  --location japaneast \
  --template-file delegation.json \
  --parameters managedByTenantId="<provider-tenant-id>"