リソースによる Microsoft Sentinel データへのアクセスを管理する
通常、Microsoft Sentinel 対応の Log Analytics ワークスペースにアクセスできるユーザーは、セキュリティ コンテンツを含め、ワークスペースのすべてのデータにもアクセスできます。 管理者は、Azure ロール を使用して、チームのアクセス要件に応じて、Microsoft Sentinel の特定の機能に対するアクセスを構成できます。
ただし、ワークスペース内の特定のデータにのみアクセスする必要があり、Microsoft Sentinel 環境全体にはアクセスする必要のないユーザーもいます。 たとえば、セキュリティ オペレーション以外 (非 SOC) のチームに、そのチームが所有するサーバーの Windows イベント データへのアクセスを提供することが必要な場合があります。
このような場合は、ワークスペースまたは特定の Microsoft Sentinel 機能へのアクセスを提供する代わりに、ユーザーに許可されるリソースに基づくロールベースのアクセス制御 (RBAC) を構成することをお勧めします。 この方法は、リソースコンテキスト RBAC とも呼ばれています。
ワークスペースではなくアクセスできるリソースを介して Microsoft Sentinel データにアクセスできるユーザーは、次の方法を使ってログとブックを表示できます。
リソース自体を使用する (Azure 仮想マシンなど): この方法を使用して、特定のリソースのみのログおよびブックを表示します。
Azure Monitor を使用する: この方法は、複数のリソースまたはリソース グループにまたがるクエリを作成する必要がある場合に使用します。 Azure Monitor でログおよびブックに移動して、スコープを 1 つ以上の特定のリソース グループまたはリソースに定義します。
Azure Monitor でリソースコンテキスト RBAC を有効にします。 詳細については、「Azure Monitor でログ データとワークスペースへのアクセスを管理する」を参照してください。
Note
Syslog、CEF、Microsoft Entra ID データなどの Azure リソースではないデータの場合、またはカスタム コレクターによって収集されたデータの場合は、データの識別とアクセスの有効化に使われるリソース ID を、手動で構成する必要があります。 詳しくは、「Azure 以外のリソース用にリソース コンテキスト RBAC を明示的に構成する」をご覧ください。
また、関数と保存された検索条件は、リソース中心のコンテキストではサポートされていません。 そのため、解析や正規化などの Microsoft Sentinel 機能は、Microsoft Sentinel のリソースコンテキスト RBAC ではサポートされません。
リソースコンテキスト RBAC のシナリオ
次の表は、リソースコンテキスト RBAC が最も役立つシナリオを示しています。 SOC チームと非 SOC チームの間のアクセス要件の違いに注意してください。
| 要件の種類 | SOC チーム | 非 SOC チーム |
|---|---|---|
| アクセス許可 | ワークスペース全体 | 特定のリソースのみ |
| データ アクセス | ワークスペース内のすべてのデータ | チームがアクセスを許可されているリソースのデータのみ |
| エクスペリエンス | 完全な Microsoft Sentinel エクスペリエンス (ユーザーに割り当てられている機能のアクセス許可によって制限される場合がある) | ログ クエリとブックのみ |
チームのアクセス要件が、上記の表で説明した非 SOC チームと同様である場合は、選択肢としてリソースコンテキスト RBAC が適している可能性があります。
たとえば、次の図で示されている簡略化されたバージョンのワークスペース アーキテクチャでは、セキュリティ チームと運用チームは異なるデータ セットにアクセスする必要があり、必要なアクセス許可を提供するためにリソース コンテキスト RBAC が使われています。
この画像の内容:
- Microsoft Sentinel 対応の Log Analytics ワークスペースは、アプリケーション チームがワークロードをホストするために使うサブスクリプションからアクセス許可をより適切に分離するために、別のサブスクリプションに配置されます。
- アプリケーション チームには、それぞれのリソース グループへのアクセス権が付与され、そこでリソースを管理できます。
この個別のサブスクリプションとリソース コンテキスト RBAC を使用すると、これらのチームは、直接アクセス "できない" ワークスペースにログが格納されている場合でも、アクセスできるすべてのリソースによって生成されたログを表示できます。 アプリケーション チームは、Azure portal の [ログ] 領域を使用して特定のリソースのログを表示したり、Azure Monitor を介してアクセスできるすべてのログを同時に表示したりして、ログにアクセスできます。
Azure 以外のリソース用にリソース コンテキスト RBAC を明示的に構成する
Azure リソースには、リソース コンテキスト RBAC のための組み込みサポートがありますが、Azure 以外のリソースを操作する場合は追加の微調整が必要な場合があります。 たとえば、Microsoft Sentinel 対応の Log Analytics ワークスペース内の Azure リソースではないデータには、Syslog、CEF、AAD などのデータ、またはカスタム コレクターによって収集されたデータが含まれます。
ソースコンテキスト RBAC を構成する必要があるが、データが Azure リソースではない場合、次の手順を実行します。
ソースコンテキスト RBAC を明示的に構成する場合:
Azure Monitor で、リソースコンテキスト RBAC を有効にしていることを確認します。
Microsoft Sentinel 環境全体を使用せずに、ご使用のリソースにアクセスする必要があるユーザーのチームごとに、リソース グループを作成します。
各チーム メンバーにログ閲覧者のアクセス許可を割り当てます。
作成したリソース チーム グループにリソースを割り当て、関連するリソース ID でイベントにタグを付けます。
Azure リソースによって Microsoft Sentinel にデータが送信されると、ログ レコードには、データ リソースのリソース ID で自動的にタグが付けられます。
ヒント
目的に合わせて作成された特定のリソース グループで、アクセスを許可するリソースをグループ化することをお勧めします。
グループ化できない場合は、チームが、アクセスさせたいリソースに対して直接アクセスできるログ閲覧者のアクセス許可を持っていることを確認してください。
リソース ID の詳細については、次のセクションを参照してください。
ログの転送を使用するリソース ID
Common Event Format (CEF) または Syslog を使用してイベントを収集する場合、複数のソース システムからイベントを収集するために、ログの転送が使用されます。
たとえば、CEF または Syslog を転送する VM が、Syslog イベントを送信するソースをリッスンし、それらを Microsoft Sentinel に転送する場合、転送されるすべてのイベントに、ログ転送 VM のリソース ID が割り当てられます。
複数のチームがある場合は、個別のチームごとに、イベントを処理する個別のログ転送 VM があることを確認してください。
たとえば、VM を分離すると、チーム A に属する Syslog イベントは、コレクター VM A を使用して収集されます。
ヒント
- ログ フォワーダーとして、オンプレミスの VM または別のクラウド VM (AWS など) を使用する場合は、Azure Arc を実装して、その VM が確実にリソース ID を持つようにしてください。
- ログ転送 VM 環境をスケーリングするには、CEF および Sylog ログを収集するための 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>
}
}
ヒント
異なるイベントに適用されるタグを区別するために、複数の output セクションを追加できます。
Log Analytics API コレクションを使用するリソース ID
Log Analytics データ コレクター API を使用して収集する場合、HTTP x-ms-AzureResourceId 要求ヘッダーを使用して、イベントにリソース ID を割り当てます。
リソースコンテキスト RBAC を使用しており、API によって収集されたイベントを特定のユーザーが使用できるようにする必要がある場合、ユーザー用に作成したリソース グループのリソース ID を使用します。
リソース コンテキスト RBAC の代替手段
組織で必要なアクセス許可によっては、ソースコンテキスト RBAC を使用しても完全に解決できない場合があります。 たとえば、前のセクションで説明したアーキテクチャを使用する組織が、内部監査チームに Office 365 ログへのアクセスを許可する必要もある場合について考えます。 この場合、テーブル レベルの RBAC を使って、他のテーブルへのアクセスを許可せずに、OfficeActivity テーブル全体へのアクセスを監査チームに許可できます。
次の一覧では、データ アクセスの他のソリューションの方が要件に適しているシナリオについて説明します。
| シナリオ | 解決策 |
|---|---|
| 子会社に、完全な Microsoft Sentinel エクスペリエンスを必要とする SOC チームがある。 | この場合は、マルチワークスペース アーキテクチャを使用して、データのアクセス許可を分離します。 詳細については、次を参照してください。 |
| 特定の種類のイベントへのアクセスを提供する必要がある。 | たとえば、Windows 管理者に対して、すべてのシステムで Windows セキュリティ イベントにアクセスできるようにします。 このような場合は、テーブルレベルの RBAC を使用して、各テーブルのアクセス許可を定義します。 |
| リソースに基づくのではなく、アクセスをより詳細なレベルに制限するか、またはイベント内のフィールドのサブセットのみに制限する | たとえば、ユーザーの子会社に基づいて Office 365 ログへのアクセスを制限することができます。 この場合、Power BI のダッシュボードおよびレポートで組み込みの統合を使用して、データへのアクセスを提供します。 |
| 管理グループでアクセスを制限する | Microsoft Sentinel をセキュリティ専用の別の管理グループの下に配置し、最小限のアクセス許可だけがグループのメンバーに継承されるようにします。 セキュリティ チーム内では、各グループの機能に従って異なるグループにアクセス許可を割り当てます。 すべてのチームはワークスペース全体にアクセスできるので、完全な Microsoft Sentinel エクスペリエンスにアクセスでき、割り当てられている Microsoft Sentinel のロールによってのみ制限されます。 詳細については、「Microsoft Sentinel のアクセス許可」を参照してください。 |
次のステップ
詳細については、「Microsoft Sentinel のアクセス許可」を参照してください。