複数のワークスペースで SAP 向け Microsoft Sentinel ソリューション アプリケーションを使用する
Microsoft Sentinel ワークスペースを設定するときは、複数のアーキテクチャ オプションと考慮すべき要因があります。 地域、規制、アクセス制御、その他の要因を考慮して、組織にに複数の Microsoft Sentinel ワークスペースを含めることができます。
この記事では、複数のワークスペースでさまざまなデプロイ シナリオの SAP 向け Microsoft Sentinel ソリューション アプリケーションを使用する方法について説明します。
SAP 向け Microsoft Sentinel ソリューション アプリケーションは、ワークスペース間のアーキテクチャをネイティブにサポートし、次に関する柔軟性の向上を支援しています。
- マネージド セキュリティ サービス プロバイダー (MSSP)、またはグローバルまたはフェデレーション セキュリティ オペレーション センター (SOC)。
- データ所在地の要件。
- 組織階層と IT 設計。
- 1 つのワークスペースでロールベースのアクセス制御 (RBAC) が不十分である。
重要
複数のワークスペースの操作は、現在プレビュー段階です。 この機能は、サービス レベル アグリーメントがなくても提供されます。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。
SAP セキュリティ コンテンツをデプロイするときは、複数のワークスペースを定義できます。
組織での SOC チームと SAP チーム間のコラボレーション
一般的なユース ケースは、組織内の SOC チームと SAP チームの間でのコラボレーションに複数のワークスペースのセットアップが必要であるというケースです。
組織の SAP チームは、SAP 向け Microsoft Sentinel ソリューション アプリケーションを正常かつ効果的に実装するために重要な技術的知識を持っています。 そのため、SAP チームでは、関連データを確認するとともに、必要な構成とインシデント対応プロシージャについて SOC と共同作業することが重要になっています。
SOP チームと SAP チームのコラボレーションには、組織のニーズに応じて 2 つのシナリオが考えられます。
シナリオ 1: SAP データと SOC データが別々のワークスペースに保持されている。 どちらのチームも、ワークスペース間クエリを使用して SAP データを確認できます。
シナリオ 2: SAP データが SOC ワークスペースにのみ保持されている。 SAP チームは、リソース コンテキスト クエリを使用してデータのクエリを実行できます。
シナリオ 1: SAP データと SOC データが別々のワークスペースに保持されている
このシナリオでは、SAP チームと SOC チームには、チーム データが保持されている別々の Microsoft Sentinel ワークスペースがあります。
組織が SAP 向け Microsoft Sentinel ソリューション アプリケーションをデプロイすると、各チームは SAP ワークスペースを指定します。
一般的には、一部またはすべての SOC チーム メンバーに SAP ワークスペースの Sentinel 閲覧者ロールを提供する方法を取ります。
SAP データと SOC データ用に個別のワークスペースを作成すると、次の利点があります:
Microsoft Sentinel では、SOC データと SAP データの両方を含むアラートをトリガーすることができ、SOC ワークスペースでそれらのアラートを実行できます。
Note
大規模な SAP ランドスケープの場合、SOC によって SAP ワークスペースからデータに対してクエリが実行されると、パフォーマンスに影響が及ぶ可能性があります。 SAP データは、クエリの実行時に SOC ワークスペースに移動する必要があります。 パフォーマンスとコストの最適化を改善するには、同じ 専用クラスターに SOC と SAP の両方のワークスペースを用意することを検討してください。
SAP チームには、SOC データと SAP データの両方を含め、検出を除くすべての機能を含む、独自の Microsoft Sentinel ワークスペースがあります。
柔軟性。 SAP チームは、そのランドスケープ内にある内部脅威の制御に集中でき、SOC は外部脅威に集中できます。
データが Microsoft Sentinel に取り込まれるのは 1 回のみなので、インジェスト料金が追加で請求されることはありません。 ただし、各ワークスペースには、独自の価格レベルがあります。
SOC では、SAP インシデントを確認および調査できます。 既存のデータを使用して説明できないイベントが SAP チームで発生した場合、チームは SOC にインシデントを割り当てることができます。
次の表は、このシナリオでの SAP チームと SOC チームのデータと機能のアクセスを示しています。
機能 | SOC チーム | SAPチーム |
---|---|---|
SOCワークスペース アクセス | ✅ | ❌ |
SAP ワークスペース のデータ、分析ルール、関数、ウォッチリスト、ブックへのアクセス | ✅ | ✅1 |
SAP インシデントのアクセスとコラボレーション | ✅ | ✅1 |
1 SOC チームは、両方のワークスペースでこれらの機能を確認できます。 SAP チームは、SAP ワークスペースでのみ、これらの機能を確認できます。
シナリオ 2: SAP データが SOC ワークスペースにのみ保持されている
このシナリオでは、すべてのデータを 1 つのワークスペースに保持して、アクセス制御を適用する必要があります。 これを行うには、Azure Monitor で Log Analytics を使用して、リソースごとにデータへのアクセスを管理します。 また、SAP リソースを Azure リソース ID に関連付けるには、SAP システムから Microsoft Sentinel にデータを取り込む際に使用するデータ コレクターのコネクタ構成セクションで、必須の azure_resource_id
フィールドを指定します。
データ コレクター エージェントが正しいリソース ID で構成されると、SAP チームは、スコープ付きリソース クエリを使用して SOC ワークスペース内にある特定の SAP データにアクセスできます。 SAP チームは、SAP 以外の他のデータ型を読み取ることができません。
データが Microsoft Sentinel に取り込まれるのは 1 回のみなので、この方法に関連するコストはありません。 このアクセス モードを使用すると、SAP チームには未加工のデータと書式設定されていないデータのみが表示されます。 SAP チームは、Microsoft Sentinel 機能を使用できません。 SAP チームは、Log Analytics 経由で生データにアクセスするだけではなく、Power BI 経由で同じデータにアクセスできます。
次のステップ
この記事では、複数のワークスペースでさまざまなデプロイ シナリオの SAP 向け Microsoft Sentinel ソリューション アプリケーションを使用する方法について説明しました。 次は、ソリューションをデプロイする方法について説明します。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示