Microsoft Sentinel ワークスペースアーキテクチャを設計する

[アーティクル]
06/28/2023

この記事では、Microsoft Sentinel ワークスペースアーキテクチャの設計方法に関する重要な決定を下す際に役立つデシジョンツリーを提供します。詳細については、「Microsoft Sentinel のサンプルワークスペースの設計」および「Microsoft Sentinel アーキテクチャのベストプラクティス」を参照してください。この記事は、Microsoft Sentinel のデプロイガイドの一部です。

前提条件

デシジョンツリーを使用する前に、次の情報がそろっていることを確認してください。

前提条件	説明
Azure でのデータ所在地に関連する規制要件	Microsoft Sentinel は、Log Analytics の GA でサポートされている、ほとんどのリージョンのワークスペースで実行できます。ただし、実行できないリージョンもあります。 Log Analytics の新しくサポートされたリージョンでは、Microsoft Sentinel サービスのオンボードに時間がかかる場合があります。インシデント、ブックマーク、分析ルールなど、Microsoft Sentinel によって生成されたデータには、顧客の Log Analytics ワークスペースをソースとする顧客データが含まれている可能性があります。詳細については、「リージョン別の提供状況とデータの保存場所」を参照してください。
[データソース]	Microsoft と Microsoft 以外の両方のソリューションへの組み込みコネクタを含め、どのデータソースに接続する必要があるかを確認します。 Common Event Format (CEF)、Syslog、または REST-API を使用して、データソースを Microsoft Sentinel に接続することもできます。複数の Azure の場所にログ収集の必要な Azure VM があり、データエグレスコストの節約が重要な場合は、帯域幅価格計算ツールを使用して、Azure の場所ごとのデータエグレスコストを計算する必要があります。
ユーザーロールとデータアクセスレベルまたはアクセス許可	Microsoft Sentinel では、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、Azure のユーザー、グループ、サービスに割り当てることができる組み込みロールが提供されています。 Microsoft Sentinel のすべての組み込みロールでは、Microsoft Sentinel ワークスペース内のデータに対して読み取りアクセス権が付与されます。したがって、データソースまたは行レベルごとにデータアクセスを制御する必要があるかどうかを確認する必要があります。このことはワークスペースの設計に関する決定に影響を与えるからです。詳細については、「カスタムロールと高度な Azure RBAC」を参照してください。
日次インジェスト率	日次インジェスト率 (通常 GB/日単位) は、Microsoft Sentinel のコスト管理と計画に関する考慮事項およびワークスペースの設計における重要な要素の 1 つです。ほとんどのクラウドやハイブリッド環境では、取り込まれたデータのほとんどは、ファイアウォールやプロキシなどのネットワークデバイスおよび Windows や Linux サーバーによって生成されます。最も正確な結果を得るには、データソースを包括的にインベントリすることをお勧めします。また、Microsoft Sentinel のコスト計算ツールには、データソースの占有領域を見積もるのに役立つ表が含まれています。重要: これらの見積もりは出発点であり、ログの詳細設定やワークロードによって差異が生まれます。実際のシステムを定期的に監視して、すべての変更を追跡することをお勧めします。各自のシナリオに基づいて、定期的に監視することをお勧めします。詳細については、Azure Monitorログの価格の詳細に関するページを参照してください。

デシジョンツリー

次の画像は、ワークスペースを最適に設計する方法を理解するのに役立つ完全なデシジョンツリーフローチャートを示しています。

次のセクションでは、このデシジョンツリーのフルテキストバージョンを提供します。画像内で参照されている次の注記が含まれています。

注 #1 | 注 #2 | 注 #3 | 注 #4 | 注 #5 | 注 #6 | 注 #7 | 注 #8 | 注 #9 | 注 #10

手順 1: ワークスペースは新規か既存のものか?

Microsoft Sentinel に使用できる既存のワークスペースがありますか?

なくて、いずれにしても新しいワークスペースを作成する場合は、手順 2 に直接進みます。
使用できる可能性がある既存のワークスペースがある場合は、取り込むデータの量を検討します。
- 取り込む量が 100 GB/日を "上回る" 場合は、コスト効率のために個別のワークスペースを使用することをお勧めします。
- 取り込む量が 100 GB/日を "下回る" 場合は、手順 2 に進んで、さらなる評価を行います。手順 5 でこの問題が持ち上がった場合は、この質問を再度検討します。

手順 2: 異なる Azure 地域にデータを保持するか?

異なる Azure 地域にデータを保持するという規制要件がある場合は、コンプライアンス要件がある Azure リージョンごとに個別の Microsoft Sentinel ワークスペースを使用します。詳細については、「リージョンに関する考慮事項」を参照してください。
異なる Azure 地域にデータを保持する必要がない場合は、手順 3 に進みます。

手順 3: 複数の Azure テナントがあるか?

テナントが 1 つしかない場合は、手順 4 に直接進みます。
複数の Azure テナントがある場合は、Office 365 や Microsoft Defender XDR などのテナント境界に固有のログを収集するかどうかを検討してください。
- テナント固有のログがない場合は、手順 4 に直接進みます。
- テナント固有のログを収集する場合は、Microsoft Entra テナントごとに個別の Microsoft Sentinel ワークスペースを使用します。手順 4 に進み、その他について検討します。
  
  デシジョンツリーの注 #1: Office 365 や Microsoft Defender for Cloud など、テナントの境界に固有のログは同じテナント内のワークスペースにのみ格納できます。
  
  カスタムコレクターを使用して他のテナントのワークスペースからテナント固有のログを収集することはできますが、次のような短所があるため、お勧めしません。
  - カスタムコネクタによって収集されたデータは、カスタムテーブルに取り込まれます。そのため、組み込みのルールとブックを一部使用することができません。
  - カスタムテーブルは、UEBA や機械学習ルールなど、一部の組み込み機能では考慮されません。
  - カスタムコネクタには、Azure Functions や Logic Apps を使用するなど、追加のコストと労力が必要です。
  これらの欠点が組織にとって問題とならない場合は、個別の Microsoft Sentinel ワークスペースを使用する代わりに、手順 4 に進みます。

手順 4: 請求またはチャージバックを分割するか?

請求またはチャージバックを分割する必要がある場合は、使用状況レポートまたは手動でのクロスチャージが役立つかどうかを検討します。

請求またはチャージバックを分割する必要が "ない" 場合は、手順 5 に進みます。
請求またはチャージバックを分割する必要が "ある" 場合は、手動でのクロスチャージの使用を検討してください。エンティティごとの正確なコストを取得するために、エンティティごとにコストを分類する Microsoft Sentinel Cost ブックの変更されたバージョンを使用できます。
- 使用状況レポートまたは手動のクロスチャージが役立つ場合は、手順 5 に進みます。
- 使用状況レポートと手動のクロスチャージが "どちらも役立たない" 場合は、コストの所有者ごとに個別の Microsoft Sentinel ワークスペースを使用します。
デシジョンツリーの注 #2: 詳細については、「Microsoft Sentinel のコストと課金」を参照してください。

手順 5: SOC 以外のデータを収集するか?

オペレーショナルデータなど、SOC 以外のデータを収集しない場合は、手順 6 に直接進むことができます。
SOC 以外のデータを収集 "する" 場合は、重複があるかどうかを検討します。ある場合は、SOC と SOC 以外の両方のデータのデータソースが同じである必要があります。

SOC と SOC 以外のデータが重複 "している" 場合は、重複しているデータを SOC データとしてのみ扱います。次に、SOC と SOC 以外の "両方" のデータのインジェストが個別では 100 GB/日を下回るものの、まとめると 100 GB/日を超えるかどうかを検討します。
- はい: 手順 6 に進み、さらなる評価を行います。
- いいえ: コスト効率の点で、同じワークスペースを使用しないことをお勧めします。手順 6 に進み、さらなる評価を行います。
どちらの場合も、詳細については、「注 10」を参照してください。

重複データが "ない" 場合は、SOC と SOC 以外の "両方" のデータのインジェストが個別では 100 GB/日を下回るが、まとめると 100 GB/日を超えるかどうかを検討します。
- はい: 手順 6 に進み、さらなる評価を行います。詳細については、注 3 を参照してください。
- いいえ: コスト効率の点で、同じワークスペースを使用しないことをお勧めします。手順 6 に進み、さらなる評価を行います。

SOC と SOC 以外のデータをまとめる

デシジョンツリーの注 #3: 一般に、SOC 以外のデータが Microsoft Sentinel のコストの対象とならないように、SOC 以外のデータ用に個別のワークスペースを保持することをお勧めしますが、SOC と SOC 以外のデータをまとめた方がそれらを分けるよりもコストが低くなる場合があります。

たとえば、セキュリティログのインジェストが 50 GB/日、オペレーションログのインジェストが 50 GB/日で、ワークスペースが米国東部リージョンにある組織について考えてみます。

次の表では、個別のワークスペースがある場合とない場合のワークスペースオプションを比較しています。

Note

次の表に記載されているコストと条件は架空のものであり、説明のためにのみ使用されています。最新のコスト情報については、Microsoft Sentinel 価格計算ツールを参照してください。

ワークスペースアーキテクチャ	説明
SOC チームが、Microsoft Sentinel が有効になっている専用のワークスペースを利用する。運用チームが、Microsoft Sentinel が有効になっている専用のワークスペースを利用する。	SOC チーム: Microsoft Sentinel のコストは 50 GB/日で、1 か月あたり 6,500 ドルです。最初の 3 か月のリテンション期間は無料です。運用チーム: - Log Analytics のコストは 50 GB/日で、1 か月あたり約 3,500 ドルです。 - 最初の 31 日のリテンション期間は無料です。両方の合計コストは、1 か月あたり 10,000 ドルです。
SOC と運用の両方のチームが、Microsoft Sentinel が有効になっている同じワークスペースを共有する。	両方のログをまとめると、インジェストは 100 GB/日になり、コミットメントレベルの資格 (Sentinel の場合は 50%、LA の場合は 15%) を満たします。 100 GB/日の Microsoft Sentinel のコストは、1 か月あたり 9,000 ドルです。

ワークスペースアーキテクチャ

説明

SOC チームが、Microsoft Sentinel が有効になっている専用のワークスペースを利用する。

運用チームが、Microsoft Sentinel が有効になっている専用のワークスペースを利用する。

SOC チーム:
Microsoft Sentinel のコストは 50 GB/日で、1 か月あたり 6,500 ドルです。
最初の 3 か月のリテンション期間は無料です。

運用チーム:
- Log Analytics のコストは 50 GB/日で、1 か月あたり約 3,500 ドルです。
- 最初の 31 日のリテンション期間は無料です。

両方の合計コストは、1 か月あたり 10,000 ドルです。

SOC と運用の両方のチームが、Microsoft Sentinel が有効になっている同じワークスペースを共有する。

両方のログをまとめると、インジェストは 100 GB/日になり、コミットメントレベルの資格 (Sentinel の場合は 50%、LA の場合は 15%) を満たします。

100 GB/日の Microsoft Sentinel のコストは、1 か月あたり 9,000 ドルです。

この例では、両方のワークスペースをまとめることで、1 か月あたり 1,000 ドルのコストを削減し、さらに運用チームが無料で利用できるリテンション期間が、たった 31 日ではなく、3 か月間になります。

この例は、SOC と SOC 以外の両方のデータのインジェストサイズが >=50 GB/日以上かつ <100 GB/日未満である場合にのみ適用されます。

デシジョンツリーの注 #10: SOC 以外のデータが Microsoft Sentinel のコストの対象とならないように、SOC 以外のデータ用に個別のワークスペースを使用することをお勧めします。

ただし、SOC 以外のデータに対する個別のワークスペースについてのこの推奨は純粋なコストベースの観点からのものであり、使用するワークスペースの数を 1 つにするか複数にするかを決定する際に確認する重要な設計要素は他にもあります。インジェストコストが二重にかからないようにするには、テーブルレベルの Azure RBAC を使用して、重複するデータを 1 つのワークスペースのみに収集することを検討してください。

手順 6: リージョンは複数か?

"単一" のリージョン内にある Azure VM からのみログを収集する場合は、手順 7 に直接進みます。
"複数" のリージョン内にある Azure VM からログを収集する場合は、データエグレスコストはどの程度問題となりますか?

デシジョンツリーの注 #4:データエグレスは、Azure データセンターからデータを移動する際の帯域幅コストを指します。詳細については、「リージョンに関する考慮事項」を参照してください。
- 個別のワークスペースを維持するために必要な作業量を減らすことが優先事項である場合は、手順 7 に進みます。
- 個別のワークスペースを維持する価値を見いだすうえでデータエグレスコストが十分に懸念される場合は、データエグレスコストを削減する必要があるリージョンごとに個別の Microsoft Sentinel ワークスペースを使用します。
  
  デシジョンツリーの注 #5: ワークスペースの数はできる限り少なくすることをお勧めします。 Azure 価格計算ツールを使用してコストを見積もり、実際に必要なリージョンを特定し、エグレスコストが低いリージョンのワークスペースをまとめます。帯域幅コストは、Microsoft Sentinel と Log Analytics の個々のインジェストコストと比較すると、Azure の請求額のごく一部でしかない場合があります。
  
  たとえば、次の場合のコストを見積もります。
  - VM が 1,000 台あり、それぞれ 1 GB/日を生成する
  - 米国リージョンからヨーロッパリージョンにデータを送信する
  - エージェントで 2:1 の圧縮率を使用する
  このコスト見積もりの計算は 1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost となります
  
  このサンプルコストは、Microsoft Sentinel と Log Analytics の個々のワークスペースの月額コストと比較すると、はるかに安価です。
  
  Note
  
  記載されているコストは架空のものであり、説明のためにのみ使用されています。最新のコスト情報については、Microsoft Sentinel 価格計算ツールを参照してください。

手順 7: データを分離したり、所有権による境界を定義したりするか?

データを分離したり、所有権による境界を定義したりする必要が "ない" 場合は、手順 8 に直接進みます。
データを分離したり、所有権に基づいて境界を定義したりする必要が "ある" 場合、各データ所有者が Microsoft Sentinel ポータルを使用する必要がありますか?
- 各データ所有者が Microsoft Sentinel ポータルにアクセスできる必要がある場合は、所有者ごとに個別の Microsoft Sentinel ワークスペースを使用します。
  
  デシジョンツリーの注 #6: Microsoft Sentinel ポータルにアクセスするには、各ユーザーが少なくとも Microsoft Sentinel 閲覧者のロールと、ワークスペース内のすべてのテーブルに対する閲覧者アクセス許可を持っている必要があります。ワークスペース内のすべてのテーブルにアクセスできないユーザーは、Log Analytics を使用して検索クエリでログにアクセスする必要があります。
- Microsoft Sentinel ポータルにアクセスできない所有者にとって Log Analytics を使用したログへのアクセスで十分な場合は、手順 8 に進みます。
詳細については、「Microsoft Sentinel のアクセス許可」を参照してください。

手順 8: データソースまたはテーブルごとにデータアクセスを制御するか?

ソースまたはテーブルごとにデータアクセスを制御する必要が "ない" 場合は、1 つの Microsoft Sentinel ワークスペースを使用します。
ソースまたはテーブルごとにデータアクセスを制御する必要が "ある" 場合は、次の状況でリソースコンテキスト RBAC を使用することを検討します。
- 行レベルでアクセスを制御する必要がある場合 (各データソースまたはテーブルに複数の所有者を設定する場合など)
- 複数のカスタムデータソースまたはテーブルがある場合 (それぞれに個別のアクセス許可が必要です)
それ以外で、行レベルでアクセスを制御する必要がない場合は、複数のカスタムデータソースまたはテーブルに個別のアクセス許可を付与し、1 つの Microsoft Sentinel ワークスペースを使用し、テーブルレベル RBAC を使用してデータアクセスを制御します。

リソースコンテキストまたはテーブルレベルの RBAC に関する考慮事項

リソースコンテキストまたはテーブルレベルの RBAC の使用を計画している場合は、次の情報を考慮します。

デシジョンツリーの注 #7: Azure 以外のリソースのためにリソースコンテキスト RBAC を構成する場合は、Microsoft Sentinel に送信するときにリソース ID をデータに関連付けることができます。これにより、リソースコンテキスト RBAC を使用してアクセス許可のスコープを指定できます。詳細については、「リソースコンテキスト RBAC を明示的に構成する」およびデプロイ別のアクセスモードに関する記事を参照してください。
デシジョンツリーの注 #8: リソースのアクセス許可またはリソースコンテキストを使用すると、ユーザーはアクセス権を持つリソースのログのみを表示できます。ワークスペースのアクセスモードは、ユーザーリソースまたはワークスペースのアクセス許可に設定する必要があります。 Microsoft Sentinel の [ログ] ページの検索結果には、ユーザーがアクセス許可を持っているリソースに関連するテーブルのみが含まれます。
デシジョンツリーの注 #9: テーブルレベルの RBAC では、他のアクセス許可に加えて、Log Analytics ワークスペースのデータをさらにきめ細かく定義できます。この制御を使用すると、特定のユーザーのグループのみがアクセスできる特定のデータ型を定義できます。詳細については、「Microsoft Sentinel のテーブルレベルの RBAC」を参照してください。

次の手順

この記事では、Microsoft Sentinel ワークスペースアーキテクチャの設計方法に関する重要な決定を下す際に役立つデシジョンツリーについて確認しました。

Microsoft Sentinel のサンプルワークスペースの設計

Microsoft Sentinel ワークスペース アーキテクチャを設計する