リソース別にMicrosoft Sentinelデータへのアクセスを管理する

ワークスペースへのアクセスは、AZURE RBAC を使用して管理されます。通常、Microsoft Sentinelが有効になっている Log Analytics ワークスペースにアクセスできるユーザーは、セキュリティコンテンツを含むすべてのワークスペースデータにもアクセスできます。管理者は、Azureロールを使用して、チームのアクセス要件に応じて、Microsoft Sentinelの特定の機能へのアクセスを構成できます。

ただし、ワークスペース内の特定のデータにのみアクセスする必要があるが、Microsoft Sentinel環境全体にアクセスできないユーザーがいる場合があります。たとえば、セキュリティ以外の操作 (SOC 以外) チームに、所有するサーバーの Windows イベントデータへのアクセスを提供できます。

このような場合は、ワークスペースまたは特定のMicrosoft Sentinel機能へのアクセスをユーザーに提供するのではなく、ユーザーに許可されているリソースに基づいてロールベースのアクセス制御 (RBAC) を構成することをお勧めします。このメソッドは、 リソースコンテキスト RBAC の設定とも呼ばれます。

ユーザーは、ワークスペースではなくアクセスできるリソースを介してMicrosoft Sentinelデータにアクセスできる場合、次の方法を使用してログとブックを表示できます。

Azure仮想マシンなど、リソース自体を介して。特定のリソースのみのログとブックを表示するには、このメソッドを使用します。
Azureモニター経由。複数のリソースやリソースグループにまたがるクエリを作成する場合は、このメソッドを使用します。 Azure Monitor のログとブックに移動する場合は、スコープを 1 つ以上の特定のリソースグループまたはリソースに定義します。

Azure Monitor でリソースコンテキスト RBAC を有効にします。詳細については、「Azure Monitor でログデータとワークスペースへのアクセスを管理する」を参照してください。

注:

データが Syslog、CEF、Microsoft Entra ID データなどのAzure リソースではない場合、またはカスタムコレクターによって収集されたデータである場合は、データを識別してアクセスを有効にするために使用されるリソース ID を手動で構成する必要があります。詳細については、「Azure以外のリソースのリソースコンテキスト RBAC を明示的に構成する」を参照してください。

また、関数と保存された検索は、リソース中心のコンテキストではサポートされていません。そのため、解析や正規化などのMicrosoft Sentinel機能は、Microsoft Sentinelのリソースコンテキスト RBAC ではサポートされていません。

リソースコンテキスト RBAC のシナリオ

次の表は、リソースコンテキスト RBAC が最も役立つシナリオを示しています。 SOC チームと SOC 以外のチームの間のアクセス要件の違いに注意してください。

要件の種類	SOC チーム	SOC 以外のチーム
アクセス許可	ワークスペース全体	特定のリソースのみ
データアクセス	ワークスペース内のすべてのデータ	チームがアクセスを許可されているリソースのデータのみ
エクスペリエンス	ユーザーに割り当てられた機能アクセス許可によって制限される可能性がある、完全なMicrosoft Sentinel エクスペリエンス	ログクエリとブックのみ

上記の表で説明した SOC 以外のチームと同様のアクセス要件があるチームの場合は、リソースコンテキスト RBAC がorganizationに適したソリューションである可能性があります。

たとえば、次の図は、セキュリティチームと運用チームがさまざまなデータセットにアクセスする必要があり、リソースコンテキスト RBAC を使用して必要なアクセス許可を提供するワークスペースアーキテクチャの簡略化されたバージョンを示しています。

この画像では:

Microsoft Sentinelに対して有効になっている Log Analytics ワークスペースは、アプリケーションチームがワークロードをホストするために使用するサブスクリプションからアクセス許可をより適切に分離するために、別のサブスクリプションに配置されます。
アプリケーションチームには、それぞれのリソースグループへのアクセス権が付与され、そこでリソースを管理できます。

この個別のサブスクリプションとリソースコンテキスト RBAC を使用すると、直接アクセス できない ワークスペースにログが格納されている場合でも、これらのチームはアクセス権を持つすべてのリソースによって生成されたログを表示できます。アプリケーションチームは、Azure portalの [ログ] 領域を介してログにアクセスし、特定のリソースのログを表示したり、Azure Monitor を使用して、アクセスできるすべてのログを同時に表示したりできます。

Azure以外のリソースのリソースコンテキスト RBAC を明示的に構成する

Azureリソースにはリソースコンテキスト RBAC のサポートが組み込まれていますが、Azure以外のリソースを操作する場合は、追加の微調整が必要になる場合があります。たとえば、リソースにAzureされていないMicrosoft Sentinelに対して有効になっている Log Analytics ワークスペース内のデータには、Syslog、CEF、または AAD データ、またはカスタムコレクターによって収集されたデータが含まれます。

リソースコンテキスト RBAC を構成するが、データがAzure リソースではない場合は、次の手順を使用します。

リソースコンテキスト RBAC を明示的に構成するには:

Azure Monitor でリソースコンテキスト RBAC が有効になっていることを確認します。
Microsoft Sentinel環境全体を使用せずにリソースにアクセスする必要があるユーザーの各チームのリソースグループを作成します。

各チームメンバーにログ閲覧者のアクセス許可を割り当てます。
作成したリソースチームグループにリソースを割り当て、関連するリソース ID でイベントにタグを付けます。

リソースAzure Microsoft Sentinelにデータを送信すると、ログレコードにデータソースのリソース ID が自動的にタグ付けされます。

ヒント

目的のために作成された特定のリソースグループの下で、アクセス権を付与するリソースをグループ化することをお勧めします。

アクセスできない場合は、チームにアクセスするリソースに対するログリーダーアクセス許可がチームに直接付与されていることを確認します。

リソース ID の詳細については、次を参照してください。

ログ転送を使用したリソース ID

共通イベント形式 (CEF) または Syslog を使用してイベントを収集する場合、ログ転送を使用して複数のソースシステムからイベントを収集します。

たとえば、CEF または Syslog 転送 VM が Syslog イベントを送信するソースをリッスンし、それらをMicrosoft Sentinelに転送すると、転送するすべてのイベントにログ転送 VM リソース ID が割り当てられます。

複数のチームがある場合は、個別のチームごとにイベントを処理する個別のログ転送 VM があることを確認します。

たとえば、VM を分離すると、チーム A に属する Syslog イベントがコレクター VM A を使用して収集されます。

ヒント

オンプレミス VM または AWS などの別のクラウド VM をログフォワーダーとして使用する場合は、Azure Arc を実装してリソース ID を持っていることを確認します。
ログ転送 VM 環境をスケーリングするには、CEF ログと Syslog ログを収集する VM スケールセットを作成することを検討してください。

Logstash コレクションを使用したリソース ID

Microsoft Sentinel Logstash 出力プラグインを使用してデータを収集する場合は、azure_resource_id フィールドを使用して、出力にリソース ID を含むようにカスタムコレクターを構成します。

リソースコンテキスト RBAC を使用していて、API によって収集されたイベントを特定のユーザーが使用できるようにする場合は、ユーザー用に作成したリソースグループのリソース ID を使用します。

たとえば、次のコードは、Logstash 構成ファイルのサンプルを示しています。

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

ヒント

複数の output セクションを追加して、異なるイベントに適用されるタグを区別することができます。

Log Analytics API コレクションを使用したリソース ID

Log Analytics データコレクター API を使用して収集する場合は、HTTP x-ms-AzureResourceId 要求ヘッダーを使用して、リソース ID を持つイベントに割り当てることができます。

リソースコンテキスト RBAC の代替手段

organizationで必要なアクセス許可によっては、リソースコンテキスト RBAC を使用しても完全なソリューションが提供されない場合があります。たとえば、前のセクションで説明したアーキテクチャを持つorganizationでも、Office 365ログへのアクセス権を内部監査チームに付与する必要があるかどうかを検討してください。この場合、 テーブルレベルの RBAC を 使用して、他のテーブルにアクセス許可を付与することなく、 OfficeActivity テーブル全体へのアクセス権を監査チームに付与できます。

次の一覧では、データアクセスの他のソリューションが要件に適合する可能性があるシナリオについて説明します。

シナリオ	ソリューション
子会社には、完全なMicrosoft Sentinelエクスペリエンスを必要とする SOC チームがあります。	この場合は、マルチワークスペースアーキテクチャを使用してデータアクセス許可を分離します。詳細については、以下を参照してください: ワークスペースとテナント間でMicrosoft Sentinelを拡張する > 多くのワークスペースでインシデントを一度に操作する
特定の種類のイベントへのアクセスを提供する必要があります。	たとえば、Windows 管理者にすべてのシステムのWindows セキュリティイベントへのアクセス権を付与します。このような場合は、テーブルレベルの RBAC を使用して、各テーブルのアクセス許可を定義します。
リソースに基づいていない、またはイベント内のフィールドのサブセットのみに、より詳細なレベルへのアクセスを制限する	たとえば、ユーザーの子会社に基づいてOffice 365 ログへのアクセスを制限できます。この場合は、 Power BI ダッシュボードとレポートとの組み込みの統合を使用して、データへのアクセスを提供します。
管理グループによるアクセスの制限	Microsoft Sentinelセキュリティ専用の別の管理グループの下に配置し、最小限のアクセス許可のみがグループメンバーに継承されるようにします。セキュリティチーム内で、各グループ関数に応じて異なるグループにアクセス許可を割り当てます。すべてのチームはワークスペース全体にアクセスできるため、割り当てられているMicrosoft Sentinelロールによってのみ制限される、完全なMicrosoft Sentinelエクスペリエンスにアクセスできます。詳細については、「Microsoft Sentinelのアクセス許可」を参照してください。

詳細については、以下を参照してください:

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-23

リソース別にMicrosoft Sentinelデータへのアクセスを管理する

リソース コンテキスト RBAC のシナリオ

Azure以外のリソースのリソース コンテキスト RBAC を明示的に構成する