AZ-305：Designing Microsoft Azure Infrastructure Solutions ID・ガバナンス・監視ソリューションの設計 問8
ID・ガバナンス・監視ソリューションの設計／ログと監視ソリューションの設計ある企業は、Microsoft Sentinel を有効にした Log Analytics ワークスペースの SecurityEvent テーブルに、1 日あたり数十 GB のログを取り込んでいます。直近 90 日分は Sentinel の分析ルールと日常的な KQL 調査の対象です。91 日目から 7 年目までのログは、年に数回の監査対応でのみ参照し、結果が出るまで数時間から数日待っても構いません。古いログも同じワークスペースに残し、保持コストを抑えつつ、監査時に KQL で検索できるようにしたい場合の設計として最適なものはどれですか。
当サイトのオリジナル問題（AZ-305：Designing Microsoft Azure Infrastructure Solutionsの出題範囲「ID・ガバナンス・監視ソリューションの設計」に対応。実際の試験問題ではありません）
- Aテーブルを分析ログ プランのまま、対話型保持期間を 90 日、合計保持期間を 7 年に設定し、監査時は検索ジョブまたは復元で長期保持期間のデータを参照する
- Bテーブルを基本ログ プランに変更して取り込みコストを下げ、分析ルールもそのテーブルに対して実行し、監査時は通常のクエリで 7 年分を直接検索する
- C連続データ エクスポートで全ログをストレージアカウントへ書き出し、ワークスペースの保持期間は 90 日にして、監査時はワークスペースの KQL でストレージ上のデータを検索する
- DAzure Data Explorer クラスターへ全ログを連続エクスポートして 7 年分を保持し、Sentinel の分析ルールは直近 90 日分だけワークスペースで実行して、監査時は Azure Data Explorer で検索する
正解：A
解説
Log Analytics のテーブルには、通常のクエリや分析ルールが使える対話型保持期間と、その後に低コストで残す長期保持（アーカイブ）期間があり、合計保持期間は最長 12 年まで設定できます。テーブルごとに設定できるため、直近 90 日だけを分析ログ プランの対話型保持にして 7 年まで残せば、同じワークスペースのままコストを抑えられます。長期保持されたデータは、検索ジョブで条件に合う行を取り出すか、復元で一時的にクエリ可能にして参照します。結果が出るまで待てる監査用途はこの条件に合います。基本ログ プランのテーブルは分析ルールの対象にできず、通常のクエリで検索できる期間も直近 30 日までに制限されます。
選択肢ごとの解説
- A正しい。テーブル単位で対話型保持 90 日・合計保持 7 年を設定でき、分析ルールと日常調査は直近分で維持しつつ、古いログは同じワークスペースで検索ジョブや復元により参照できます。
- B誤り。基本ログ プランのテーブルは Sentinel の分析ルールの対象にできず、通常のクエリで検索できるのは直近 30 日までです。7 年分を直接クエリで検索することも、直近 90 日の分析ルールの要件も満たしません。
- C誤り。エクスポート先のストレージアカウントのデータは、ワークスペースの KQL では直接検索できません。検索するには別途ツールや再取り込みが必要になり、ワークスペースに残して検索したいという要件に合いません。
- D誤り。Azure Data Explorer への連続エクスポートは実現可能ですが、クラスターの構築・運用と二重のデータ管理が必要です。同じワークスペースに残すという要件を満たさず、ワークスペースの長期保持で足りる要件には過剰な構成です。