はじめに
皆さん、Microsoft Sentinel を活用されていらっしゃいますか？
Microsoft Sentinel を構成する場合、元となる LogAnalytics のワークスペースにログを集約し、溜めたログをどのように検知・分析するのかを実装するのですが、LogAnalytics と Microsoft Sentinel をどのように構成するのか悩む方は多いのではないかと思います。
この回答として、2021/7/28 に公式ドキュメントに「Microsoft Sentinel workspace architecture best practices」 が掲載されたのですが、まだ日本語化されていない状況なので、本記事で概要を訳して取り上げてみたいと思います。
1. テナンシーにおける考慮事項
Microsoft Sentinel を構成する場合、複数のAzure AD テナントとLogAnalytics ワークスペースの要件が上がる場合があります。たとえば、企業では複数のAzure Active Directory（Azure AD）テナントを含むクラウド環境があります。これは、合併や買収、子会社との連携、または ID の分離要件によるものです。
ベストプラクティスでは、テナントとワークスペースの数を決定する際に Sentinel に接続する LogAnalytics を 単一のワークスペース を使用して設定し、ワークスペース内に格納されているすべてのログを取り込むことを推奨しています。
参考：単一ワークスペースで構成する一番大きな理由はコスト対策です。
Microsoft Sentinel の課金体系では、ボリュームディスカウントが効くことから、必要なログを同一のワークスペースで管理することで大幅なコスト削減が期待できます。
Microsoft Sentinel のコストと課金
2. 複数のテナントとの連携
もし、MSSP (マネージドセキュリティサービスプロパイダー）のように、複数のテナントを管理・運用する必要がある場合は、ベストプラクティスとしてAzure ADテナント内で連携するログソース（サービスのデータコネクタ）を少なくとも一つのワークスペースに接続して、設計することを推奨しています。
Azure AD リソースにおける診断設定のログは、そのリソースが存在するテナント内のワークスペース内のみ接続することができます。 これは、Azure ファイアウォール、Azure ストレージ、Azure アクティビティ、Azure ActiveDirectory などのコネクタに適用されます。
Azure Lighthouseを使用することで、さまざまなテナントの複数の Microsoft Sentinel インスタンスを管理することができます。以下の公式ブログに、Azure Lighthouse を用いた Microsoft Sentinel のマルチテナンシー概要について紹介されています。
- Azure Lighthouse と Microsoft Sentinel を使用した、スケーラブルなセキュリティ プラクティスの構築
- ワークスペースおよびテナント全体での Microsoft Sentinel の拡張
公式ドキュメントに掲載されているイメージを以下紹介します。
Microsoft Sentinel には、一元的な監視、構成、管理を可能にする複数ワークスペース機能が用意されており、複数のワークスペースに対するインシデント管理画面や、ワークスペースを横断してクエリーを送るクロスワークスペース クエリ機能などが提供されています。
注意事項として、これらの機能は複数のワークスペース間をまとめて相関分析する機能ではなく、あくまでダッシュボードであり、検索を行う目的に用いるものです。
Microsoft Sentinel には、ワークスペースの中で Enrichment を付与（IPアドレスやユーザー名など）し、相関分析を行う機能があるのですが、これはワークスペース単位である、というのは原則として変わらないため、注意が必要になります。
マネージド SOC のアウトソースや、事業会社などを持った企業が監視を行うダッシュボードのような位置づけですね。
3. コンプライアンスに関する考慮事項
GDPR 要件などを考慮する際、データが収集、保存、処理された後、コンプライアンスは重要な設計要件になり、Microsoft Sentinel アーキテクチャに大きな影響を与える可能性があります。すべての国と地域で、誰がどのデータにアクセスできるかを検証および証明する機能を持つことは、多くの国と地域で重要なデータ主権要件であり、リスクを評価し、Microsoft Sentinel ワークフローのインサイトを得ることが多くのお客様の優先事項です。
Microsoft Sentinel を利用すると、インシデント、ブックマーク、分析ルールなど、生成されたデータに顧客データが含まれている可能性がありますが、Sentinelではデータを保存されたリージョン外に出さないと定義したリージョンが公開されています。日本リージョンのその一つです。
詳細は以下URLを参照して下さい。
- ドキュメント：リージョン別の提供状況とデータの保存場所
- What’s new – Announcing new Azure Sentinel data residency locations: Japan, UK and Canada
一部例外として、Microsoft Sentinel では機械学習 (ML) エンジンを利用する特定の規則を有効にすることで、機械学習エンジンがこれらの規則を処理する必要がある場合に Microsoft Sentinel ワークスペースの地理的な場所以外で取り込まれた関連データをコピーするためのアクセス許可を Microsoft に付与します。
4. リージョンにおける考慮事項
リージョンごとに個別の Microsoft Sentinel インスタンスを使用します。Microsoft Sentinel は複数のリージョンで使用できますが、チーム、リージョン、サイトごとにデータを分離する必要がある場合や、マルチリージョンモデルを不可能にする（または必要以上に複雑にする規制や制御が必要になる場合）ケースがあります。
リージョンごとに個別のインスタンスとワークスペースを使用すると、リージョン間でデータを移動するための帯域幅/出力コストを回避できます。
複数のリージョンで作業する場合は、次の点を考慮します。
-
エージェント側からの出力
- 通常、仮想マシンなどでログを収集するためにLogAnalyticsまたはAzureMonitorエージェントが必要な場合、出力コストが適用されます。
-
インターネットへの出力
- LogAnalytics ワークスペースの外部にデータをエクスポートしない限り影響しない可能性があります。
- たとえば、Log Analytics データをオンプレミスサーバーにエクスポートすると、インターネットの出力料金が発生する場合があります。
-
帯域幅のコスト
- 送信元と宛先の地域および収集方法によって異なります。
-
帯域幅の価格
- LogAnalytics を使用したデータ転送料金
- 分析ルール、カスタムクエリ、ワークブック、およびその他のリソースのテンプレートを使用して、展開をより効率的にします。
- 各リージョンに各リソースを手動でデプロイする代わりに、テンプレートをデプロイします。
たとえば、米国東部の仮想マシンからログを収集し、それらを米国西部の Microsoft Sentinel ワークスペースに送信することにした場合、**大陸間のデータ転送**が請求されます。データ転送はリージョン間転送から課金されるため、事前に注意する必要があります。
参考までに Log Analytics エージェントはデータを圧縮して転送するため、ペイロードサイズの転送料金がそのまま課金される訳ではありません。
これらの背景から、世界中の複数のソースから Syslog および CEF ログを収集している場合、コンプライアンスが問題にならない限り、帯域幅のコストを回避するために、Microsoft Sentinel ワークスペースと同じリージョンにSyslog コレクターをセットアップすることをお勧めします。
5. アクセスに関する考慮事項
異なるチームが同じデータにアクセスする必要がある状況が計画されている場合があります。 たとえば、SOC チームはすべての Microsoft Sentinel データにアクセスできる必要がありますが、運用チームとアプリケーションチームは特定の部分にだけアクセスする要件などが挙げられます。
また、独立したセキュリティチームも Microsoft Sentinel の機能にアクセスする必要がある場合がありますが、データセットはさまざまです。
リソースコンテキスト RBAC とテーブルレベル RBAC を組み合わせて、ほとんどのユースケースをサポートする必要のある幅広いアクセスオプションをチームに提供します。
6.リソースコンテキスト RBAC
Microsoft Sentinel の権限設計を行う上で、セキュリティチームと運用チームがさまざまなデータセットにアクセスする必要があり、リソースコンテキスト RBAC を使用して必要なアクセス許可を提供するワークスペースアーキテクチャを紹介しています。
6-1. セキュリティチームの RBAC 権限設計例
| チーム | RBAC権限 | 適用箇所 |
|---|---|---|
| セキュリティ監視チーム | サブスクリプション | Security Reader |
| SOCアナリストチーム | リソースグループ | Sentinel Responder |
| SOCエンジニアリングチーム | リソースグループ | Sentinel Contributor |
6-2. その他チームのRBAC権限設計例
| チーム | RBAC権限 | 適用箇所 |
|---|---|---|
| 運用チーム | サブスクリプション | Monitoring Contributor |
| アプリケーショングループ1 | リソースグループ1 | Contributor |
| アプリケーショングループ2 | リソースグループ2 | Contributor |
Azure RBAC で提供されている組み込みロールについては、以下の公式ドキュメントを参照してください。
Microsoft Sentinel の専用ロールとしては以下が提供されています。うまく活用しましょう。
| ロール | 英語名 | ロール概要 |
|---|---|---|
| Azure Sentinel 閲覧者 | Azure Sentinel Reader | データ、インシデント、ブック、その他の Azure Sentinel リソースを表示する |
| Azure Sentinel レスポンダー | Azure Sentinel Responder | Azure Sentinel Reader 権限 + インシデントの管理 (割り当て、無視など) を行うことができる。 |
| Azure Sentinel 共同作成者 | Azure Sentinel Contributer | Azure Sentinel Responder 権限 + ブック、分析ルール、その他の Azure Sentinel リソースの作成と編集を行うことができる。 |
もう1つのオプションは、Microsoft Sentinel をセキュリティ専用の別の管理グループの下に配置することです。これにより、最小限のアクセス許可の割り当てのみが継承されます。 セキュリティチーム内では、いくつかのグループにその機能に応じて権限が割り当てられています。 これらのチームはワークスペース全体にアクセスできるため、割り当てられた Azure Sentinel の役割によってのみ制限され、完全な Microsoft Sentinel としてアクセスできます。
7.テーブルレベルの RBAC
テーブルレベルの RBAC を使用すると、特定のデータ型（テーブル）を定義して、指定したユーザーのセットのみがアクセスできるようにすることができます。
例として、内部監査チームに Office 365 ログへのアクセスも許可する必要があるかどうかを検討してください。この場合、テーブルレベルの RBAC を使用して、他のテーブルへのアクセス許可を付与せずに、監査チームにだけ Office Activity テーブル全体へのアクセス権を付与するケースが考えられます。
設定は、カスタム RBAC を設定するため、細かなチューニング、設計が必要となります。詳細は以下を参考にしてください。
8.複数のワークスペースでのアクセスに関する考慮事項
組織内に異なるエンティティ、子会社、または地域があり、それぞれに Microsoft Sentinel へのアクセスを必要とする独自のセキュリティチームがある場合は、エンティティまたは子会社ごとに個別のワークスペースを使用します。単一の Azure AD テナント内、または Azure Lighthouse を使用して複数のテナントに個別のワークスペースを実装します。
中央の SOC チームは、追加のオプションの Microsoft Sentinel ワークスペースを使用して、分析ルールやワークブックなどの一元化された成果物を管理することもできます。
9. ワークスペースを作成するための技術的なベストプラクティス
Microsoft Sentinel に使用する LogAnalytics ワークスペースを作成するときは、次のベストプラクティスを検討しましょう。
-
命名規則：LogAnalytics ワークスペース名を分かり易くする
- ワークスペース名に Microsoft Sentinel またはその他のインジケーターを含めて、他のワークスペース間で簡単に識別できるようにします。
- Azure では CAF (クラウド適合フレームワーク）に命名規則ルールのサンプルが掲載されており、参考になると思います。
-
1TB/日以上のデータ量の場合は、「専用ワークスペースクラスター」を用いる
- 予測されるデータの取り込みが1日あたり約1TB以上の場合は、専用のワークスペースクラスターを使用します。
- 専用クラスターを使用すると、Microsoft Sentinelデータのリソースを保護できます。これにより、大規模なデータセットのクエリパフォーマンスが向上します。
- 専用クラスターは、組織のキーをさらに暗号化および制御するためのオプションも提供します。
10. 複数のワークスペースでの作業を簡素化する
複数のワークスペースを操作する必要がある場合は、各 Microsoft Sentinel インスタンスからのすべてのインシデントを1つの場所に凝縮して一覧表示することにより、インシデントの管理と調査を簡素化します。
クロスワークスペースブックなど、他の Microsoft Sentinel ワークスペースに保持されているデータを参照するには、クロスワークスペースクエリを使用します。
クロスワークスペースクエリを使用するのに最適なタイミングは、貴重な情報が別のワークスペース、サブスクリプション、またはテナントに格納されており、現在のアクションに価値を提供できる場合です。
まとめ
本記事では、Microsoft Sentinel の LogAnalytics 側の検討事項について、ベストプラクティスを概要で紹介いたしました。どなたかの参考になれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。