リソース別に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 を使用して必要なアクセス許可を提供するワークスペースアーキテクチャの簡略化されたバージョンを示しています。

サンプルのリソースコンテキストRBACアーキテクチャ図では:

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

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

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

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

非Azureデータに対してリソースコンテキストRBACを設定するには、以下の手順を実行します。

リソースコンテキスト 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で収集されたイベントを特定のユーザーに利用したい場合は、「非Azureリソースに対して明示的にリソースコンテキストRBACを設定する」で設定したリソースグループのリソースIDを使用してください。

例えば、以下のLogstash設定ファイルは、Beats入力を通じてイベントを取り込み、Microsoft Sentinel出力プラグインを使ってLog Analyticsワークスペースに送信する方法を示しています。azure_resource_idフィールドはリソースコンテキストRBAC用の特定のリソースグループでイベントにタグ付けするように設定されています。

 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 の代替手段

組織で必要な権限によっては、リソースコンテキストRBACの使用がすべてのデータアクセス要件を完全に満たさない場合があります。例えば、リソースコンテキストRBACのシナリオで説明されている別サブスクリプションワークスペースアーキテクチャを使用する組織が、内部監査チームにも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-08-14

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

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

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