こんにちは！インシデントレスポンスの現場を渡り歩いているSOCアナリストの私です。
日々、様々なサイバー攻撃の痕跡を追いかけていますが、調査の現場で一番頭を悩ませる瞬間っていつだと思いますか？それは、「いざ攻撃者を見つけようとログを見たとき、肝心のデータがすでに消えていた」という瞬間なんですよね。まるで、事件が起きたあとに防犯カメラの映像が上書きされてしまっていたような絶望感です。
今回は、新人のIT担当者や開発者の方に向けて、「ログの保持期間と法的コンプライアンス」についてお話ししていきます。
「コンプライアンス」や「法律」と聞くと、なんだか難しそうだな……って身構えてしまいますよね。でも大丈夫です。身近な「家の防犯」に例えながら、一緒に一歩ずつ優しく学んでいきましょう！
—
1. なぜログを残すの？家で例える防犯の仕組み
突然ですが、みなさんのお家には玄関の鍵がありますよね。では、鍵を閉めるだけで「我が家は絶対に安全！」と言い切れるでしょうか？
残念ながら、世の中には巧みなピッキングをしたり、窓ガラスをこじ開けたりする泥棒（サイバー攻撃者）がいます。どれだけ頑丈な鍵をつけても、100%の安全はありません。だからこそ、多くの家では「防犯カメラ」を設置したり、「誰がいつ訪ねてきたか」を確認できるようにしたりしますよね。
ITの世界でも同じです。ファイアウォールという「鍵」をかけるだけでは不十分で、次のような「防犯カメラの映像」にあたるものが絶対に必要になります。
- 誰がシステムにログインしたのか？
- どのファイルにアクセスしたのか？
- 変な動き（不正なアクセス）はなかったか？
これらを記録したものが「ログ」です。そして、この防犯カメラの映像を「どれくらいの期間、保存しておくべきか」というのが今回のメインテーマになります。
—
2. 「ログは多ければ多いほどいい」の落とし穴と現実
「じゃあ、防犯カメラの映像みたいに、ログは無限にずーっと残しておけば完璧じゃないですか！」と思いますよね。
理論上はその通りなのですが、現実には大きな問題が2つあります。
1. コスト（お金と容量）: ログは膨大なデータ量になります。全部を何年も保存しようとすると、サーバーのディスク容量がパンクして、高額なストレージ代がかかってしまいます。
2. 法律のルール（コンプライアンス）: 実は、「プライバシー保護の観点から、不要になった個人情報入りのログはいつまでも持っていてはいけない」という厳しいルール（GDPRなど）もあります。
つまり、「短すぎても犯人を追えない、長すぎてもお金がかかるし法律違反になる」という、絶妙なバランスを取る必要があるのです。ここで基準になるのが、各国や業界が定める「最小保持期間」という考え方になります。
—
3. 最低限どれくらい残せばいいの？法規制と現場のリアル
フォレンジック（デジタル鑑識）の現場から言うと、攻撃者は侵入したあと、すぐに悪さをすることは稀です。しばらくシステムの中に潜伏し、会社の秘密を盗み出すタイミングをじっと伺っています。
そのため、最低でも「過去数ヶ月〜1年間」のログを遡れないと、攻撃の全貌を暴くのは非常に難しくなります。
代表的なルールをいくつか見てみましょう。
- PCI DSS（クレジットカード業界のセキュリティ基準）:
クレジットカードを取り扱うシステムでは、少なくとも1年間のログを保持し、そのうち直近の3ヶ月分はすぐに取り出せる状態にしておくことが義務付けられています。
- GDPR（EU一般データ保護規則）:
個人情報を扱う企業が対象です。セキュリティ確保のためにログ残すことは認められていますが、「目的が終わったら速やかに削除・匿名化しなさい」とされています。そのため、やみくもに何年も残すのはNGです。
このように、法律や業界のルールによって「最低これだけは残しなさい」「長く持ちすぎてはいけない」という線引きがされています。
—
4. 実務で役立つ！ログローテーションと保持設定のサンプル
それでは、実際にシステムを構築する際、どのようにログの保存期間を管理すればよいのでしょうか。Linuxサーバーなどでよく使われるログ管理ツール logrotate を例に見てみましょう。
以下の設定ファイルは、「ログを毎日1回整理し、それを4週間（28日）分だけ手元に残して、古いものは自動で圧縮・削除する」という設定のサンプルです。
# /etc/logrotate.d/app_access
# アプリケーションのアクセスログを管理する設定ファイルです
/var/log/app/access.log {
weekly # 毎週ログをローテーション（新しいファイルに切り替え）する
rotate 4 # 過去4世代分のログを手元に残す（実質約1ヶ月分の保持）
compress # 古くなったログは容量を節約するために圧縮する
delaycompress # 最新の過去ログだけはすぐに圧縮せず、デバッグしやすく残しておく
missingok # ログファイルがなくてもエラーを出さずに処理を続行する
notifempty # ログが空っぽの場合はローテーションを行わない
create 640 root adm # 新しいログファイルの権限を設定（所有者: root, グループ: adm）
}このように、自動化の仕組み（スクリプトやミドルウェアの設定）を使って、容量を圧迫しないように計画的に古いログを整理していくのが、インフラエンジニアや開発者の大切な仕事になります。
—
5. まとめ：今日から始める第一歩
ログの保持期間と法的コンプライアンスについて、イメージは湧いてきたでしょうか？
「難しそうな法律の話だな」と感じたかもしれませんが、要するに「家の防犯カメラの映像を、いつまで保管しておくべきか、ルールとコストのバランスを考えてあらかじめ決めておこうね」ということです。
インシデント（事件）が起きたとき、過去のログがあなたの会社を救う決定的な証拠になります。一歩ずつ、まずは自社のシステムが「いまログを何日分残しているか」を確認することから始めてみましょう！
コメント