セキュリティログの保管設計：何を何のために残すか

この記事の結論

大量のログを保存していても、必要な出来事を追えなければ調査に使えません。調べたい質問を決め、対象と期間、検索方法、取扱権限を設計します。

不審なサインイン、管理設定の変更、外部共有、端末検知など、調査したい出来事を挙げます。一つのログだけでは利用者、端末、通信を結び付けられない場合があります。サービスごとのIDや端末名を対応付け、取得できる項目と未取得の情報を把握します。

タイムゾーンが混在すると時系列を誤りやすくなります。原本の時刻情報を保持し、分析時の基準を決めます。利用者ID、端末ID、送信元、対象リソース、結果などを使って出来事を追えるか試します。ログの生成時刻と収集時刻が違う場合も区別します。

直近の監視と数か月後の調査では求める応答時間が違います。Azure Monitorにも分析向けと長期の保持の区別があります。安い保存先へ移す場合は取り出し方法、検索にかかる時間、取得費用を確認します。保存期間は業務・契約・調査要件から決め、一律の正解を置きません。

ログには利用者情報や操作内容が含まれるため、閲覧と削除の権限を制限します。必要のない認証情報や本文を記録しない設定も確認します。一定時間ログが来ない状態を検知し、障害なのか利用がなかっただけかを判断します。月次などで実際の検索例を試すと収集漏れを発見しやすくなります。

参照確認：2026年9月21日。参照範囲は各資料の説明に記載しています。手順・比較軸・設計例は編集上の提案です。価格や個別契約条件を保証せず、実環境での動作・性能は未検証です。製品選定・設定変更の前に、契約先の最新条件を確認してください。

制作にはAIによる原稿作成の補助を使用しています。公式資料の説明と編集上の提案を区別し、具体例は設計上の仮定として掲載しています。