ある大企業が 5 つの事業部門を持ち、各部門が独自の Azure サブスクリプションで操業している。セキュリティチームはすべてのサブスクリプションのアクティビティログと VM ログを一元管理し、クロスサブスクリプション分析を実現したいと考えている。また、各部門の Log Analytics データは部門外からはアクセスできないようにする必要がある。最も適切なワークスペース設計はどれか。
- A. 単一の Log Analytics ワークスペースを作成し、Azure Policy でワークスペースへの書き込み権限を全部門に与えたうえで、データはリソースコンテキストアクセスモード（Resource-context access mode）で各部門のリソースオーナーがアクセスする
- B. 単一の Log Analytics ワークスペースをセキュリティチームのサブスクリプションに作成し、全部門のログをそこに集約。テーブルレベルの RBAC（Table-level RBAC）で各部門のアクセス範囲を制御する
- C. 各部門に専用の Log Analytics ワークスペースを作成し、クロス分析には Azure Data Explorer クラスターを別途構築してデータをエクスポートする
- D. 各部門のサブスクリプションにそれぞれ Log Analytics ワークスペースを作成し、さらにセキュリティチーム用の集約ワークスペースを作成して Azure Monitor のデータ収集ルールで集約する
解答と解説を見る
正解: B
テーブルレベルの RBAC は、同一の Log Analytics ワークスペース内で特定のテーブル（例：SecurityEvent、Syslog など）への読み取りアクセスを部門ごとに制限できる機能である。単一ワークスペースへの集約でセキュリティチームのクロスサブスクリプション分析が容易になり、テーブルレベル RBAC で部門間のデータ分離が実現できる。この組み合わせが集約性・アクセス制御・運用コストのバランスが最も優れている。選択肢Dは部門ごとのワークスペース＋集約ワークスペースという二層構造であり、管理するワークスペース数が 6 つ以上になって運用コストが大きい。選択肢Aのリソースコンテキストアクセスモードは、ユーザーが自分のリソースのログのみを見るシナリオに適しているが、テーブル単位の制御には劣る。選択肢CのData Explorer への別途エクスポートは構成の複雑さとコストが増大し、要件に対して過剰である。
📚 関連サービスの解説: Log Analytics ・ Azure RBAC