【入門編】インシデントレスポンスにおけるログの保持期間と法的要件 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！セキュリティチームで日々インシデントの調査やログ解析を担当しているアナリストです。

「インシデントレスポンス」や「デジタルフォレンジック」なんて聞くと、なんだか映画のワンシーンみたいで、自分には関係のない遠い世界の話に思えてしまうかもしれませんよね。新人のIT担当者さんや、日々の開発に夢中になっているエンジニアさんなら、「サーバーが動いていれば、ログなんていつ消えても困らないでしょ？」と思ってしまうのも無理はありません。

でも、ちょっと待ってください。実はこの「ログの保存期間」こそが、いざという時に会社やあなた自身を救う、いわば「防犯カメラの映像」なんです。

今回は、このログの保管と法的要件について、身近な例えを交えながら、一歩ずつ分かりやすく紐解いていきましょう！

—

1. なぜログは「家の防犯カメラ」と同じなのか？

まずは想像してみてください。あなたが大切にしている自宅に、ある日突然、泥棒が入ってしまいました。幸いにも、玄関には防犯カメラが設置されています。

ここで、警察からこう言われたとします。
「防犯カメラの映像を確認させてください。いつ、どこから侵入されたのか特定する必要があります」

もし、このカメラが「容量がもったいないから、昨日の夜の映像は自動で消しました」という設定になっていて、泥棒が入ったのが3日前だったとしたらどうでしょう？犯人の顔も、逃げた方向も、すべて闇の中です。これでは悔やんでも悔やみきれませんよね。

サイバー世界における「ログ」も、まさにこれとまったく同じなんです。
攻撃者は、あなたが寝静まった夜間や、誰も気づかない隙を突いてサーバーに侵入し、データを盗み出したり、悪意あるプログラム（バックドア）をこっそり仕掛けたりします。

インシデント（セキュリティ事件）が発覚したその瞬間、私たちの仕事は「泥棒はどこから入って、何を持ち去ったのか？」を突き止めること、つまりデジタルフォレンジックから始まります。その時、もしログが消えていたら……？犯人の足跡を追う手がかりがすべて消えてしまっているのと同じなのです。

—

2. 「ログはいつまで残すべき？」法規制と現実のギャップ

「じゃあ、ログは一生涯残しておけば完璧ですね！」と思ったそこのあなた、非常に鋭い着眼点です。しかし、現実問題としてそれは少し難しいんです。

なぜなら、サーバーのディスク容量は無限ではありませんし、大量のログをずっと保存し続けるには莫大なお金（ストレージコスト）がかかります。また、プライバシーの観点から、不要になった個人情報が含まれるログをいつまでも持っていることは、法律上も好ましくありません。

そこで、国や業界団体が「最低これくらいの期間はログを保管しなさい」というルール（ガイドライン）を定めています。例えば、クレジットカード業界のセキュリティ基準である PCI DSS では、次のようなルールが有名です。

直近のログ（3ヶ月〜6ヶ月程度）：

すぐに取り出して調査ができる「ホットストレージ」と呼ばれる場所に保存し、異常があれば即座に検知できるようにする。

全体のログ（最低1年間、またはそれ以上）：

過去のインシデントの遡り調査や、法的監査に備えて、安全な場所にしっかりと保管しておく。

「1年」と聞くと長く感じるかもしれませんが、実は巧妙な攻撃者の中には、侵入してから数ヶ月間は息を潜めて社内ネットワークに隠れ続け、タイミングを見計らって牙をむく者もいます。そのため、短すぎるログ保存期間は、セキュリティにおいて「穴だらけの防犯カメラ」と言わざるを得ないのです。

—

3. 実務で役立つ！ログローテーションと保存設定のサンプル

それでは、実際にインフラや開発の現場で、どのようにログのライフサイクルを管理していけばよいのでしょうか？ Linuxサーバーなどでよく使われるログ管理ツール logrotate を例に、具体的な設定を見てみましょう。

「なんだか設定ファイルが難しそう……」と思うかもしれませんが、安心してください。日本語のコメント付きで丁寧に解説しますので、一歩ずつ見ていきましょう。

以下のコードは、ウェブサーバーのアクセスログが無限に膨れ上がってディスクを圧迫するのを防ぎつつ、適切な期間だけ過去のログを綺麗に残すための設定例です。

# /etc/logrotate.d/webapp_access
# ウェブアプリケーションのアクセスログ管理設定

/var/log/webapp/access.log {
    # 毎日ログを新しいものに切り替える（ローテーションする）
    daily

    # 過去30日分（約1ヶ月）のログを手元に残す設定
    rotate 30

    # ログファイルが空っぽの場合は、無理にローテーションしない
    notifempty

    # 古いログファイルに gzip形式で圧縮をかけ、ディスク容量を節約する
    compress

    # 圧縮されたログのファイル名に日付を付与する（例: access.log-20231025.gz）
    dateext
    dateformat -%Y%m%d

    # ローテーションが終わったら、ウェブサーバーに「新しいログファイルに書き込んでね」と合図を送る
    sharedscripts
    postrotate
        /bin/systemctl reload nginx > /dev/null 2/&1 || true
    endscript
}

このように設定しておけば、直近の調査に必要なログを自動で綺麗に整理しながら、ディスク容量のパンクを防ぐことができます。もちろん、これらをさらに長期保存（1年以上）する場合は、AWS S3や専用のログ保管サーバーへ安全に転送する仕組みが必要になってきます。

—

4. セキュリティに初めて触れる開発者へのメッセージ

ここまで、ログの保持期間がいかに重要か、そしてそれが「防犯カメラ」の役割を果たしているというお話をさせていただきました。

「ログを取る」「ログを残す」という作業は、普段の派手なアプリ開発や新機能のリリースと比べると、どうしても地味で裏方の仕事に感じられてしまうかもしれません。エラーが起きなければ誰も見向きもしない世界です。

しかし、ひとたびインシデント（セキュリティ事故）が起きた時、あなたの書いた丁寧なログや、適切に設計されたログの保存期間が、会社を救い、ユーザーの信頼を守る最大の武器になります。

「難しそうだな」と感じた部分もあったかもしれませんが、まずは身の回りのシステムで「このログ、今いくつ残っているだろう？」と気にかけてみることから始めてみませんか？その小さな気づきこそが、あなたを優秀なセキュリティ・エンジニアへと導く第一歩です。

一歩ずつ、確実に、安全なシステム作りを学んでいきましょう！