Azure Lighthouse による Defender for Cloud と Sentinel のマルチテナント環境での一元的な運用

本記事について

本記事は2020年の記事ですが、一部2023年4月時点での情報に更新しています。

Microsoft 365 や Azure を利用する際には、通常 Azure AD はシングルディレクトリの構成を取ることが推奨されています。

複数のアカウントとディレクトリを管理すると、セキュリティに関する不適切なやり方を促す動機が生まれます。 このやり方としては、複数のアカウント間でのパスワードの再利用などがあります。 古いアカウントや放棄されたアカウントが生じる可能性が高まり、これを攻撃者が対象にできます。

しかし、実際には多くのケースで一企業内に複数のディレクトリが見られます。そこで、本記事では特にセキュリティ運用に絞り、マルチディレクトリ環境での管理の一元化について見ていきます。

Microsoft Defender for Cloud と Microsoft Sentinel

Azure のセキュリティ管理・運用の中心を担うのが、Microsoft Defender for Cloud と Microsoft Sentinel です。Defender for Cloud は Azure における CSPM (Cloud Security Posture Management) と CWPP (Cloud Workload Protection Platform) を担い、Sentinel は SIEM (Security Information and Event Management) と SOAR (Security Orchestration, Automation, and Response)を担います。

マルチテナント運用と Azure Lighthouse

Azure において、マルチテナント運用の肝になるのが、Azure Lighthouse です。本記事では、Azure Lighthouse を利用した際に、Defender for Cloud と Sentinel の管理がどう一元化できるのかを見ていきます。

Defender for Cloud のマルチテナント運用

Defender for Cloud は、CSPM として、Azure の各サブスクリプションのセキュリティ態勢を可視化したり、CWPP としてリソースにおける脅威を検知したりします。そして、その運用においては、セキュリティの責任者がすべての Azure サブスクリプションに対して状況を把握できるようにしておく必要があります。

シングルテナント・マルチサブスクリプションの場合

シングルテナントの場合は、テナント内のすべてのサブスクリプションを含む管理グループを作り、その管理グループに対して、セキュリティの責任者が「セキュリティ管理者」または「セキュリティ閲覧者」の権限を持たせることによって、可視性を持つことができます。また、これらのロールは、Azure の組み込みロールであり、Azure AD のロールではない点にご注意ください。

マルチテナント・マルチサブスクリプションの場合

テナントをまたぐ場合は、Azure Lighthouse による委任が必要です。特に Defender for Cloud はサブスクリプション単位のサービスのため、サブスクリプションに対してのセキュリティ管理者ロールをアサインする必要があります。

他テナントから、サブスクリプションへのアクセス権限が付与されると、Defender for Cloud のダッシュボードで他のテナントのサブスクリプションも自テナントのサブスクリプションと同じように見ることができるようになります。

例えば下記の例では、2つの Azure AD のテナントに属する管理グループとサブスクリプションが1つの画面で見えています。

Lighthouse による委任の実施

委任の実施は、サブスクリプションの管理者権限があれば、容易に実行できます。委任のステップについては、こちらをご参照ください。サブスクリプションの委任のテンプレートを利用し、パラメーターファイルを変更します。

なお、roleDefinitionId で設定するセキュリティ管理者のIDは fb1c8493-542b-48eb-b624-b4c8fea62acd で、セキュリティ閲覧者のIDは 39bc4728-0917-49c7-9d2c-d95423bc2eb4 です。

また、ステップバイステップで委任プロセスを確認したい方は、手前味噌ですが下記の記事もご参照ください。

Microsoft Sentinel のマルチテナント運用

Sentinel の場合は、複数の構成パターンがあります。マイクロソフト社が推奨している構成は、テナントごとにワークスペースを作成し、Azure Lighthouse を使って管理を委任して、セキュリティ運用チームがすべてのワークスペースをモニタリングできるようにする方式です。一方で、なるべくログをひとつのワークスペースに集めるような構成も可能です。（※ログの種類に依存）

Azure Lighthouse による管理の委任

下記の図が、構成をまとめています。それぞれのテナントに Sentinel ワークスペースを作成し、片方のメインとなるテナントのセキュリティ運用を行う AAD 上の Group に対して、管理を委任します。

なお、委任に際してはどのロールを付与するかを検討する必要があります。Sentinel は、Sentinelのロール、Log Analytics のロール、Logic Apps のロールが関係するため、委任したいオペレーションによって、付与するロールの検討が必要です。

ステップバイステップで委任プロセスを確認したい方は、MS Tech Community の記事か、または下記の Qiita 記事をご参照ください。

委任をすると、Defender for Cloud と同じく、同じ画面で複数テナントの配下のワークスペースが見れるようになります。

インシデントの管理

インシデントの管理は Lighthouse を構成すると、すぐに複数テナントのワークスペースにまたがって実行できるようになります。こちらは公式ドキュメントで分かりやすく説明されています。

クエリ、分析、Workbooks の一元化

ワークスペースまたぎのクエリ

Sentinel の Lighthouse による委任で一番重要なのが、ワークスペースをまたぐクエリです。たとえば、下記のクエリを使うと自テナントのワークスペースと他テナントのワークスペース（仮に名前を Workspace2 とします）のSyslog (過去7日間) に対して、検索を同時に実行できます。

union Syslog, workspace('Workspace2').Syslog
| where TimeGenerated > ago(7d)

これは、検索画面からクエリを投げるときだけではなく、Workbook でダッシュボードを作るときにも活用できます。これにより、Hunting や 監視用ダッシュボードの一元化が実現できます。これらの詳細についても、下記の MS Tech Community の記事をご参照ください。

また、Qiita の下記記事が日本語でクロスワークスペースクエリの使い方や制限事項をわかりやすくまとめられていました。

分析

クロスワークスペースクエリを利用することで、MSSP 事業者は自身のクエリロジックをエンドユーザーに公開することなく、MSSP 事業者側で検知を行うことができます。

公式ドキュメントの下記図が分かりやすく構成を示しています。MSSP のテナント・サブスクリプション上にログは空の状態の Sentinel ワークスペースを作成し、クロスワークスペースクエリで実行する分析ルールを配置します。これによりクエリの本体と結果は MSSP 側のワークスペース、ログの実体はエンドユーザー側のワークスペースにそれぞれ存在することができます。

後ほどログの一元化について触れますが、基本的にはログ送信のテナント越えは非推奨のため、ログはエンドユーザー側に残しつつ、MSSP 側の資産となるクエリやダッシュボードは MSSP 側に残すことができるというのは、Azure Lighthouse 利用の大きなメリットになります。

Workbooks

Workbooks では、パラメータ設定で Log Analytics ワークスペースを選択させるようにすることが多いかと思います。その際、Lighthouse が構成されている時は、他テナントのワークスペースも選択できるように設定できますので、インシデントダッシュボードと同じくひとつのテナントから複数のワークスペース上のデータを同時に可視化できます。

こちらも公式ドキュメントで詳しく解説がなされています。特に、MSSP として Sentinel の運用サービスを提供する際に、エンドのお客様側に Workbooks を公開せずにダッシュボード運用ができる点がポイントです。

Azure Lighthouse によるログの保管（ワークスペース）の一元化

エージェントを利用するサーバーや、Azure 診断ログを使うサービスについては、テナントを越えたログ送信が可能です。

サーバー、ネットワークアプライアンス

Azure Monitor Agent (AMA) と Log Analytics エージェント (MMA) は、テナントをまたいでログ送信が可能です。AMA の場合は Lighthouse で設定者がサーバーと Log Analytics ワークスペースとそれぞれに必要な権限を持つことで、データ収集ルールをテナントまたぎで設定することができます。MMA の場合は、エージェントでワークスペース ID とキーを正しく設定すれば、テナントを意識せずにログ送信が可能です。

Azure 診断ログ

Azure 診断ログは Lighthouse の関係を持つテナント間であれば、異なるテナント内にあるワークスペースにもログ送信が可能です。Azure 診断ログは、Azure の各種サービス、Azure Activity・Azure AD などが利用しています。

各リソースの診断設定において、Log Analytics ワークスペースとして、外部のテナント配下のサブスクリプションにあるワークスペースを選択できます。

テナントを越えてログ送信が不可能なもの

以下のものはログをテナントを越えて送ることができません。

• Office 365 監査ログ
• Microsoft 365 E5 Security および Defender for Cloud のアラート
• Azure のセキュリティログ（Activity Log のうち、セキュリティに分類されるもの）

これらがターゲットに含まれる場合、Azure Lighthouse による管理の委任を利用した一元化が推奨です。

最後に

本記事では、Azure Lighthouse を使って、Defender for Cloud と Sentinel がどう一元的に管理できるかを見てきました。すでにマルチテナント環境で Azure が利用されている場合、そのセキュリティ管理は ID の管理も含めてばらばらになりがちです。本稿がその一元化への第一歩にお役に立てば幸いです。

＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。