Azure Lighthouse のセキュリティとアクセス許可: マルチテナント環境でクラウド アクセスを安全に管理する方法

By Mirko Peters · 2026-10-21

Azure Lighthouse のセキュリティの仕組み、テナント間で最小特権を適用する方法、そして顧客がクラウドを完全に管理し続ける方法について解説します。

Automatically translated with AI from the original post. Read the English original

Azure Lighthouse のセキュリティは、最小特権の原則、論理的なリソースのプロジェクション、顧客が管理する厳格な境界に基づいています。これにより、マネージド サービス プロバイダーは管理者パスワードを保持することなく、組み込みの Azure ロールと永続的な監査証跡を使って、マルチテナントのクラウド環境を扱えます。

重要なポイント

• お客様は、精密なスコープと組み込みロールを定義することで、Azure テナントに対する絶対的な権限を保持します。
• 登録定義と登録の割り当ては、Azure がすべての操作のたびに確認する、継続的な握手のような役割を果たします。
• Azure Lighthouse の委任では、Owner のフル ロールとデータ プレーン アクセスは一切サポートされていません。
• プロバイダーは自社のポータル上の論理的なプロジェクションを通じて操作し、ユーザーのパスワードや資格情報を共有することはありません。
• アクティビティ ログは、お客様のテナント内のすべての変更を記録し、透明性のある監査証跡を提供します。

Azure Lighthouse のセキュリティ アーキテクチャ

従来、複数のクラウド環境を管理するには、顧客のテナントごとに専用の管理者アカウントを作成する必要がありました。この方法は大きなセキュリティリスクを生み、一時パスワードを記した表計算ファイルが増え、外部システムには忘れられた資格情報が残り続けました。Azure Lighthouse は、切り離されたクラウド環境どうしの間に、暗号技術によって結び付けられた安全な扉を設けることで、この状況を根本から変えます。

Lighthouse はテナントを統合したり資格情報を共有したりする代わりに、論理的なプロジェクションを使用します。お客様のリソースは、テナント、サブスクリプション、リソース グループを含め、すべてお客様自身のクラウド環境内に留まります。マネージド サービス プロバイダーは、自社の管理テナントから安全な入口を通してこれらのリソースを確認します。プロバイダーが送信するすべての要求は Azure のコア検証レイヤーを通過し、そこで承認に関する文書が継続的に確認されてから、コマンドが実行されます。

2 つの部分からなる握手

Azure Lighthouse のセキュリティは、盲目的な信頼に基づくものではなく、お客様のトップレベル管理者が直接デプロイする、変更不可の JSON ベースの 2 つの構成ファイルに根差しています。

1 つ目は登録定義です。これはお客様のアカウント内に存在し、どの外部組織を信頼するか、そしてその組織にどの組み込みロールを付与するかを明示的に記述します。2 つ目は登録の割り当てで、その定義を特定のサブスクリプションまたはリソース グループに結び付ける宛先の役割を果たします。

これらのコンポーネントはお客様のテナント内に存在するため、お客様が完全な制御権を保持します。契約が終了した場合、お客様はサービス プロバイダーの協力を必要とせず、登録の割り当てを削除するだけで、即座に扉を閉じることができます。

マルチテナント環境で最小特権を実装する

クラウド セキュリティの基本原則の一つが最小権限の原則です。ユーザーやシステムには、タスクの実行に必要な最小限の権限だけを与えます。Azure Lighthouse では、個々のユーザーではなく、セキュリティ グループ、サービス プリンシパル、自動化アカウントに権限を割り当てることで、この原則を簡単に適用できます。

たとえば、マネージド サービス プロバイダーは、チームのアクセスを次のような階層に分けることがあります。

• サポート チーム: 変更を加えずに仮想マシンの状態と診断ログを確認できるよう、閲覧者ロールを割り当てます。
• 移行エンジニア: 特定のリソース グループに対して共同作成者ロールを割り当て、ワークロードのデプロイと更新プログラムの適用を行います。
• 自動化スクリプト: 夜間のバックアップとテレメトリ収集を実行するための、スコープを限定したカスタム サービス アカウントを割り当てます。

この細かい粒度のアプローチにより、プロバイダー側での人的ミスや資格情報の漏えいが、管理対象のすべての顧客環境に波及して大きな被害を生むことを防げます。

セキュリティ ガードレールとしての組み込みロールの制限

組織が過剰な権限を持たないよう、Azure Lighthouse では委任できる内容と委任できない内容に厳格なガードレールを設けています。特に、最上位の 所有者 ロールは Lighthouse の委任ではまったくサポートされていません。サービス プロバイダーが、他のユーザーに権限を割り当てる権限や、顧客のサブスクリプションを最終的に所有する権限を得ることはありません。

さらに、Blob Storage コンテナー内のファイルの読み取りやデータベース レコードの表示など、データ プレーンへのアクセスを許可するロールは、Lighthouse を通じて委任できません。Lighthouse が管理するのはインフラストラクチャのコントロール プレーンだけであり、管理上の監督がデータのプライバシー侵害の領域に踏み込むことはありません。

監査証跡とコンプライアンス追跡

コンプライアンス担当者は、外部ベンダーが企業の基幹クラウド インフラストラクチャにアクセスすることに、たいてい強い不安を抱きます。Azure Lighthouse は、顧客側の境界内で改ざんできない詳細な記録を残すことで、この不安を軽減します。

サービス プロバイダーのユーザーが行った操作は、仮想マシンの再起動、ファイアウォール ルールの変更、ネットワーク設定の更新など、どのようなものでもすべて顧客の Azure アクティビティ ログに直接記録されます。これらのログは顧客のテナント内に保存されるため、外部のプロバイダーが変更や削除をすることはできません。IT 管理者は定期的な監査を実施し、「誰がこのリソースを操作したか」「いつ変更されたか」「どのコマンドが正確に実行されたか」といった重要なセキュリティ上の質問に答えることができます。

さらに、企業は Azure Lighthouse と Privileged Identity Management (PIM) を組み合わせて、ジャスト イン タイムの権限昇格を必須にできます。常時共同作成者の権限を保持させる代わりに、サービス プロバイダーのエンジニアはインシデントが発生したときだけアクセスを申請できます。承認は記録され、有効期限は自動的に適用されます。

まとめ

Azure Lighthouse は、堅牢なクラウド セキュリティと効率的なマルチテナント管理の間で長年続いてきた緊張関係を解消します。パスワードの共有を、暗号的に検証され顧客が管理する委任リソース管理に置き換えることで、IT リーダーはセキュリティ態勢を損なうことなく運用を拡大できます。このアーキテクチャの基本概念を知りたい場合は、M365 FM Podcast のエピソード全編をお聴きください。クラウド管理の本質を専門用語を使わずに解説しています。

よくある質問

Azure Lighthouse のプロバイダーは、私の組織のパスワードを閲覧できますか?

いいえ。Azure Lighthouse がテナント間でパスワードやユーザー資格情報を公開、転送、共有することはありません。プロバイダーは、自社のエンタープライズ ID システムを使用して認証を行い、論理的な投影を通じてお客様のリソースを操作します。

プロバイダーが侵害された場合、Azure Lighthouse のアクセスはどうなりますか?

アクセスは、登録の割り当てで定義された特定の組み込みロールとリソースに厳密に限定されており、所有者ロールは除外されています。そのため、影響範囲は厳しく封じ込められます。さらに、顧客は自社のポータルから登録の割り当てを削除することで、直ちにアクセスを取り消せます。

Azure Lighthouse はカスタム RBAC ロールをサポートしていますか?

いいえ。Azure Lighthouse がサポートするのは、Microsoft が提供する組み込みの Azure ロールのみです。プロバイダーまたは顧客のテナントで作成したカスタム ロールは、登録定義で使用できません。

顧客のテナントに Azure Lighthouse を設定する権限を持つのは誰ですか?

サブスクリプションまたはリソース グループレベルでロールを割り当てられるアクセス許可を持つアカウント（User Access Administrator や Owner など）のような、高い特権を持つユーザーだけが、登録テンプレートをデプロイし、接続を確立できます。