セキュリティチェックシート：監査証跡（誰が・いつ・何を）をどう残す？

### このページの目的 セキュリティチェックシートの「監査証跡」「ログ取得」に関する設問に対し、迷わずコピペまたは微調整だけで答えられる回答案を提供します。 ### 得られるもの - SaaS/EC/金融など業界別の回答パターン - 具体的に記録すべき5W1Hの定義 - 突き返されないための「最低限の構成」基準 --- ### 回答テンプレート #### パターンA：SaaS・一般業務システム向け（標準） ```text 当社のシステムでは、すべての利用者（管理者を含む）の操作履歴を監査ログとして記録・保存しています。 ログには以下の情報が含まれ、セキュリティインシデント発生時の追跡が可能な状態を維持しています。 ・取得項目：実行日時、実行ユーザーID、接続元IPアドレス、操作内容（作成/更新/削除）、対象リソース、操作結果（成功/失敗） ・対象範囲：認証（ログイン/ログアウト）、権限変更、個人情報を含むデータの閲覧・操作 ・保存期間：1年間（オンライン検索可能期間） ・保護措置：ログへのアクセス権限はシステム管理者に限定し、ログ自体の変更・削除はシステム仕様上不可能（または制限）としています。 ``` #### パターンB：ECサイト・Webサービス向け（大量アクセス前提） ```text システムの重要操作（決済、会員情報変更、商品データ操作）および管理者操作について、アプリケーションログおよびデータベースログを取得しています。 AWS CloudWatch Logs（または同等の基盤）へ集約し、改ざん不可能な状態で保管しています。 ・主な記録対象：管理画面へのログイン、顧客データのDL、決済処理のエラー、システム設定変更 ・トレーサビリティ：リクエストごとにユニークなIDを付与し、API呼び出しからDB処理までを一意に追跡可能です。 ``` #### パターンC：金融・医療・高セキュリティ要件向け ```text NIST SP800-53等のセキュリティ基準に準拠し、以下の監査証跡要件を満たす包括的なロギングを実施しています。 1. 識別と認証：全てのシステムアクセスを一意のユーザーIDに紐付け記録 2. イベント詳述："いつ(NTP同期)" "誰が" "どこから" "何を" "どうした" を完全記録 3. 整合性保護：ログデータは即時にWORM（Write Once Read Many）ストレージへ転送され、管理者であっても削除・改ざんが不可能な措置を講じています。 4. 定期レビュー：特権IDによるアクセスログは、月次で第三者（監査担当）がレビューを実施しています。 ``` --- ### 添付・証跡として用意すべきもの 「本当に取っているか証拠を出せ」と言われた場合に備え、以下のスクショを用意しておきましょう。 1. **ログ一覧画面のスクショ**: 時刻、ユーザー、IP、Actionが並んでいる実際の画面（個人情報は黒塗り）。 2. **クラウド設定画面**: AWS CloudTrailやGoogle Cloud Audit Logsの「有効化」スイッチがONになっている画面。 ### やってはいけないNG回答 - ❌ 「ログはサーバーに残っています」（具体的になにが残っているか不明確） - ❌ 「適宜取得しています」（頻度や範囲が曖昧） - ❌ 「開発担当者がDBを見れば分かります」（運用プロセスとして確立されていないとみなされる） ### 最小構成 vs 推奨構成 | 項目 | Minimum（最低ライン） | Recommended（推奨ライン） | |---|---|---| | **取得項目** | ログイン/ログアウト、失敗ログ | + データ操作（作成/更新/削除）、権限変更 | | **保存場所** | アプリサーバー内（テキストファイル） | 外部ストレージ（S3/CloudWatch等）へ転送 | | **検索性** | grepコマンド等で手動検索 | ログ管理ツールでGUI検索可能 |