Microsoft Defender for Cloud、Microsoft Sentinelの役割に応じた権限設定をやってみた

はじめに

Microsoft Defender for CloudはCSPM/CWPP、Microsoft SentinelはSIEM/SOAR/UEBAの機能を提供しますので、様々なログやデータを収集してセキュリティ態勢の向上やセキュリティ監視に利用していくことになります。
私がこれらのソリューションのご紹介の際に「利用者のロールに応じてデータの参照範囲制限したいんだけど可能？」とご質問いただくことがありますので、備忘録がてら手順をまとめておきます。

Microsoft Defender for Cloud : ロールベースのアクセス制御（RBAC）

ここでは、Windows管理チームにはWindowsリソースのMicrosoft Defender for Cloud推奨事項、アラートは確認できるようにしますが、それ以外のリソースの情報は参照させないケースを想定します。

こちらの記載の通り、Microsoft Defender for Cloud固有のロールとして用意されているセキュリティ閲覧者を利用します。
*あらかじめ、Windows管理者用に”WinSV-Admin1”というセキュリティグループを用意しておきます。

1. 対象のリソースグループ（ここではWinSV-GP1）のアクセス制御（IAM）から、「ロールの割り当ての追加」を選択し”セキュリティ閲覧者”ロールに”WinSV-Admin1”のセキュリティグループを割り当てる
   
   
   

2. 実際に"WinSV-Admin1"グループに所属しているメンバーでMicrosoft Defender for Cloudの画面を確認してみます。
   推奨事項ビューでリソースグループのフィルターを確認してみると、”winsv-gp1”しか選択できないようになっていました。
   （インベントリビュー、セキュリティアラートビューも同様です）
   これは、WinSV-admin1のメンバーはMicrosoft Defender for CloudポータルでWindowsリソースの情報のみ閲覧できることを意味します。
   

【補足１】サブスクリプションレベルでContributerレベルのアクセス権が付与されているユーザーでは、以下のように”winsv-gp1”を含む全リソースグループの情報が確認できます。

【補足２】今回追加したセキュリティ閲覧者ロールでは、こちらに記載の通りアラートと推奨事項の閲覧が可能です。よって、ロールを付与したリソースグループ内のリソースに関するデータであっても概要ダッシュボードや規制コンプライアンスビューなどは確認できません。付与したリソースで目的の情報が参照できるか、予めテストいただくことをおすすめします。

【補足３】AWS、GCPの環境もDefender for Cloudで監視している場合、それぞれの環境に限定して担当者に参照させたい場合にも同様の手法が利用できます。この場合、AWSやGCPの環境を接続する際に作成するコネクターのリソースグループを分けておくといった構成が必要になります。

Microsoft Sentinel (Azure Monitor) : ロールベースのアクセス制御（RBAC）

Microsoft Sentinelの場合は、Microsoft Defender for CloudのようにRBACの設定をしたからといってSentinel内の特定のデータのみ参照できるようになるわけではないので、注意が必要です。
Microsoft Sentinel環境全体にアクセスできる必要はなく、Microsoft Sentinelワークスペース内の特定のデータのみにアクセスできる必要がある場合は、下記の公開情報の通りリソースコンテキストRBACが利用可能です。
リソースによる Microsoft Sentinel データへのアクセスを管理する
こちらの公開情報にも記載がある通り、リソースコンテキストRBACを利用した場合に利用できるエクスペリエンスは「ログ クエリとブックのみ」となりますので、Microsoft SentinelビューからではなくAzure Monitorビューか対象リソースのログビューからクエリーを実行して確認することになります。

それではやってみます。今回は、こちら参考に、Windowsリソース用のリソースグループに関するログのみ参照できるカスタムロールを作成し、Windows管理者グループにロールを割り当てる手順でやってみます。

1. カスタムロールの作成

   1. 対象のリソースグループ（ここでは”WinSV-GP1”）のアクセス制御（IAM）ビューから、「カスタムロールの追加」を選択
      

   2. 「基本」タブでカスタムロール名を入力（説明は任意）、ベースラインのアクセス許可で「最初から始める」を選択
      

   3. 「アクセス許可」タブで「アクセス許可の追加」をクリックし、検索窓で”Microsoft.Insights/logs/”を検索してMicrosoft Azure Monitorを選択
      

   4. 「読み取り」にチェックを入れて追加
      

   5. 「割り当て可能なスコープ」で対象のスコープを確認し次へ

   6. 「JSON」タブで「編集」をクリックし、"actions"のフィールドを”Microsoft.Insights/logs/*/read”に修正して保存
      

   7. 定義内容を確認し、カスタムロールを作成

2. 作成したカスタムロールに"WinSV-Admin1"セキュリティグループを割り当てします。

3. 実際に"WinSV-Admin1"グループに所属しているメンバーで、リソースグループ”WinSV-GP1”のログを確認してみます。

   1. "WinSV-Admin1"グループに所属するメンバーでAzureポータルにログインし、リソースグループビューから”WinSV-GP1”リソースグループを選択します
   2. ”ログ”ビューから、任意のテーブルをクエリーしてみます。ここではAzureActivityテーブルをクエリーしてみました。WinSV-GP1のリソースに関するログが確認できました。（画面ショットは割愛しますが、Azureモニター - ログからでも同様に確認可能です）
      

【補足】上記のようにロールを割り当てたリソースグループからのログクエリは可能ですが、今回対象のアカウントにはLog AnalyticsワークスペースやSentinelに関するロールは割り当てていないため、それらに関する参照はできません。
完全なSentinelエクスペリエンスが必要で、かつ特定のデータソースのみ扱えるようにする場合はワークスペースの分離もご検討ください。（手弁当で恐縮ですが別Qiita記事のこちらでもMicrosoft Sentinelのワークスペースディシジョンツリーにおけるアクセス制御の考慮点について触れています）

Microsoft Sentinel (Azure Monitor) : テーブルベースのアクセス制御

Microsoft Sentinel、Azure Monitorでは特定のテーブルに限ってアクセス制御できるテーブルベースのRBACがサポートされています。
特定のリソース種別に限るというよりかは、リソース全般にわたってあるイベントログのみ参照する必要がある場合に利用できます。（例：監査目的でAzureアクティビティログやOffice 365ログのみ参照が必要だが、SOC用途のセキュリティイベントは不要の場合など）

こちらのブログにも詳細に紹介されていますが、Azureポータルベースの手順で実施してみます。
ここでは監査メンバーがAzureアクティビティログのみにアクセスが必要なケースを例に定義します。

1. カスタムロールの作成
   1. Microsoft Sentinel (Azure Monitor) : ロールベースのアクセス制御（RBAC）の手順でも実施したように、対象のリソースググループのアクセス制御（IAM）からカスタムロールを作成します。今度はSentinelワークスペースが存在するリソースグループに対してカスタムロールを作成します。
   2. 追加するアクセス許可に以下3つのActionを追加します。
      カスタムロールに定義するactionの例についてはこちらにも記載がありますのでご参考までに。

"Microsoft.OperationalInsights/workspaces/read"
"Microsoft.OperationalInsights/workspaces/query/read"
"Microsoft.OperationalInsights/workspaces/query/AzureActivity/read"

2. 作成したカスタムロールに監査メンバーが所属するセキュリティセキュリティグループを割り当てします。（ここでは”AzureAuditor-1”というセキュリティグループを作ってみました。
3. 実際に"AzureAuditor-1"グループに所属しているメンバーで、リソースに限らずAzureアクティビティログが参照できるか確認してみます。

1. "AzureAuditor-1"グループに所属しているメンバーでAzureポータルにログインし、確認対象のLog Analytics Workspaceを開く
2. 「ログ」ビューで、AzureActivityテーブルをクエリーする。複数のリソースグループに渡ってクエリーが返ってきていることがわかります。
   

【補足】なお、他のテーブル（例えばAzureDiagnostics）をクエリーしても結果は表示されません。

おわりに

本記事ではMicrosoft Defender for Cloud、Microsoft Sentinelに対する様々なアクセス制御を設定手順を紹介しました。
最小権限の原則に基づき、必要な人・必要なリソース（データ）に限って権限をセットすることはセキュリティ事故防止、影響軽減の意味でも重要なポイントかと思います。
上記のように様々なアクセス制御手法が用意されておりますので、ご利用環境のアクセス制御実施の際に本記事が少しでも参考になりましたら幸いです。