はじめまして！ カンと申します。
Microsoft Security Advent Calendar 2022 22日目の投稿いってみます！
はじめに
Microsoft Sentinel（以下、Sentinelと記載します）はログデータを保管するLog Analytics Workspace上にSentinelを有効化することで利用可能となります。
シンプルな環境であればAzureテナント上にLog Analytic Workspaceを一つ用意し、そこにログを集約してSentinelを有効化すればすぐに利用開始することができますが、企業環境では様々な事情や要件が影響して一概に一つのLog Analytics Workspaceにまとめることが難しいケースが発生します。
一方で、Log Analytics Workspaceを無暗に増やしてしまうと管理が難しくなるだけでなく、Sentinelの機能に制限が発生するケースもありますので、マイクロソフトは基本的には単一のワークスペースでの構成をおすすめしています。
それでは、どういったポイントを考慮してシングルワークスペースか、複数のワークスペースを用意するのでしょうか。
このような場合に、ワークスペースのアーキテクチャー設計に役立つディシジョンツリーが公式ドキュメントに用意されていますので、ポイントを絞って解説していきたいと思います。
Microsoft Sentinel ワークスペース アーキテクチャを設計する
なお、このディシジョンツリーの他にもMicrosoft Sentinel ワークスペース アーキテクチャのベストプラクティスも公開されていますし、@hisnakadさんがわかりやすく解説いただいている記事もありますので、是非合わせて参考にしていただければと思います。
ディシジョンツリー
公開情報のディシジョンツリーは英語版しか提供されていませんので、日本語化してみました。（意訳を含みます）
ステップ1~ステップ8まで検討ポイントがあり、Yes/No形式で答えていくことによりワークスペースを分けるのか、単一のワークスペースを利用するのか設計における意思決定に役立てることができます。
公開情報にはそれぞれのステップ、注記が詳細に記載されています。
ステップ1 | ステップ2 | ステップ3 | ステップ4 | ステップ5 | ステップ6 | ステップ7 | ステップ8
注#1 | 注#2 | 注#3 | 注#4 | 注#5 | 注#6 | 注#7 | 注#8 | 注#9 | 注#10
これらのステップを検討する前に、前提条件の情報がそろっていること、また、Azure Monitorの設計戦略にも記載されているように、設計を始めるときには常にシングルワークスペースで要件を満たせるか？を思い浮かべながら検討いただければと思います。
保管するデータはSOCチームによる利用が主目的か？それ以外も含むか？またその量は？
ステップ1、ステップ5に関係します。
既存のワークスペースの利用を検討するかそうでないかにもよりますが、一般に、SOC利用目的以外のデータがワークスペースに多く含まれる場合、Sentinelを有効化することでコストが嵩む要因になります。この場合はSOC以外のデータ用、SOCのデータ用に個別のワークスペースを用意することをおすすめになります。
Log AnalyticsとSentinelにはコミットメントレベルの価格が用意されており、100GB/日からコミットメントを購入することができます。従量課金に比べてお得な課金となりますので、総量のデータ量がコミットメントを利用できる量となるのであれば、ワークスペースをまとめる検討をすることでコストを抑えることが可能になります。
図．Sentinel 価格の設定ページ
前述したようにSOC目的外のデータのほうが多くなるようであれば仮に100GBを超えたとしてもSentinelで分析・検知が必須でないデータが多く含まれていることになりますので、この場合は個別のワークスペースの用意を検討します。
公式ドキュメントの注3には、SOC目的以外のデータが含まれる場合でもワークスペースをまとめたほうがコストが低くなるケースが紹介されていますので、併せて参考にしていただければと思います。
コンプライアンスやデータエグレスコストを考慮したリージョン（地域）毎のワークスペース構成
ステップ2、ステップ6に関係します。
GDPR要件やデータオーナーの求めに応じコンプライアンス要件を考慮する場合、また異なるリージョンにVMなどのリソースが存在する場合データ転送の料金を考慮する必要性からリージョンごとにワークスペースを分けることが必要になるケースがあります。
データエグレスコストを懸念する場合でも、注#5に記載の例のように、Sentinel/Log Analyticsをそれぞれ用意する場合と比較してそれほど大きな割合を占めないこともあります。
複数のワークスペースを運用、管理する場合のトータルのワークロードや料金に比べて、リージョン間の転送料金がどれほど発生するかの試算が重要ですね。
図．リージョンが異なるリソースからシングルワークスペースにデータを転送する場合のイメージ図
複数のAzure AD テナントのログを分析する必要がある
ステップ3の観点ですね。
私がSentinelの提案に従事する際に、この場合の構成のご相談をいただくことが比較的多い印象です。
SentinelはMicrosoftソリューションのログ取り込みが非常に容易（データソース毎に用意されているコネクタを利用します）である側面がありますが、Office 365やMicrosoft 365 Defenderといったデータソースは同じテナントに存在する場合にビルトインのコネクタを利用可能です。
注#1に記載の通り、これらのログをテナントを超えて取り込むことは可能ですが、作りこみが発生したりSentinelにビルトインのテンプレートルール等を利用できないといったいくつかの制限が発生しますので、お勧めはしません。
テナントをまたいでワークスペースが複数存在する場合でも、「Azure Lighthouse」という機能を使って複数ワークスペースに対する統合ダッシュボードを用意することは可能です。
図．Azure ADテナントが分かれる場合のイメージ図
データへのアクセス制御
ステップ8についてです。
職責に応じて必要十分なデータ範囲を参照できるように制御したいケースは往々にしてあると思いますが、SentinelではリソースコンテキストRBAC、テーブルレベルのRBACをサポートしていますので、きめ細かにアクセス制御を設定することが可能です。
前者は、特定のリソースに関するデータに限定して参照させたい場合（こちらにわかりやすく説明されています）、後者は特定のデータ（テーブル）に沿って参照させたい場合が主な利用シーンになってきます。
図. テーブルレベルのRBAC イメージ図
おわりに
今回の記事では、Sentinelワークスペース設計におけるディシジョンツリーの観点をいくつかピックアップして解説してみました。
ワークスペース設計一つをとっても複数の観点での検討が必要になるので複雑に思われるかもしれないですが、ディシジョンツリーも活用いただいて、Step by Stepで検討項目を整理いただければと思います。
ご利用の環境にとって最適なワークスペース設計の検討に少しでもお役に立てば幸いです。