会社情報
採用情報
お問い合わせ
Article

ログの保存期間と管理方法の決め方

高田晃太郎
ログの保存期間と管理方法の決め方

PCI DSSは「最短1年のログ保持」と「少なくとも3カ月は即時参照可能」を求めます¹。 一方でGDPRや日本の個人情報保護法は保存期間を必要最小限に限定する「保存制限」の原則を明示しています²³。セキュリティの現場データでは、大規模侵害の発見から封じ込めまでの平均期間が約287日と報告されており⁴、長期の調査が必要になる現実もあります。つまり、長短どちらにも正当性があり、組織は法規制、リスク、コスト、分析要件を両立させる設計を迫られています。

システム管理におけるログ保存期間は、慣習やツールのデフォルトではなく、検知・調査のための分析窓、監査・法令の拘束、そして運用コストのトレードオフから合意形成しなければなりません。本稿では、方針の決め方を数値の言葉に落とし込み、クラウドとオープンソースで無理なく運用できる実装パターンまでを示します。

ログ保存期間はビジネス要件から逆算する

保存期間は「長く取るか短くするか」ではなく、「どのユースケースに、どの温度帯で、どの期間応えるか」に分解すると意思決定が容易になります。まずは法規制と監査の拘束、次に検知・調査の分析窓、最後にコストモデルを重ね合わせる順で考えると、関係者の合意が得やすくなります。

法規制・監査要件のマッピング

クレジットカード情報を扱う場合はPCI DSSにより1年の保持が前提となり、3カ月は即時参照可能であることが求められます¹。個人データを含む場合、GDPR（EU一般データ保護規則）および日本の個人情報保護法が定める保存制限と目的限定の原則を満たし、必要な期間を超えて保管しない設計が不可欠です²³。上場企業や金融機関では、内部統制や監査証跡として変更管理やアクセス記録の長期保存が求められることがあり、会計関連の帳簿・証憑などは税法等により7年程度の保存義務が定められる書類が存在します⁵。ただし、これらはすべての技術ログに機械的に適用されるものではありません。ログの種別ごとに、法的拘束があるもの、内部規程で支持されるもの、ビジネス判断に委ねられるものを明確に切り分けることが重要です。

検知と調査の“分析窓”を数値化する

実運用では、検知ルールの学習やアラートの相関分析、異常なユーザー行動のベースライン化に時間軸が必要です。侵害の発見から封じ込めまでの平均期間が約287日という報告がある以上⁴、重大インシデントの司法鑑定には180〜365日相当の参照が必要になるケースがあります。一方で、日々の運用監視やSREの回帰分析では30〜90日で十分なことが多い。ここで「ホット分析窓」と「ディープ調査窓」を用語として分け、たとえばホットは30〜60日、ディープは365日、といった水準を先に宣言すると、技術選定とコスト見積もりが揃います。

コストモデルの作り方

コストは「保存日数×データ量×単価×圧縮率」で一次近似できます。具体的には、月間コストは日次平均の受信データ量に保持日数を掛け、ストレージ単価と圧縮・重複排除の効率を掛け合わせて見積もります。たとえばホットを90日から30日に短縮すれば、ホット層の容量は約66%削減になります。検索課金型のプラットフォームでは、保存ではなくクエリや取り込みの課金が支配的になるため、要約とフィールド選択が最も効くコントロールになります。費用の重心がどこにあるかを把握したうえで、温度帯の配分と要約率を調整すると無駄撃ちが減ります。

データ階層化で「必要十分」を形にする

保存期間の議論は、データの温度帯（ホット＝即時検索、ウォーム＝準即時、コールド＝長期保管）を設けると現実解に落ちます。ホットは即時検索とダッシュボードの土台であり、アラートの一次調査がストレスなく回ることが要件です。ウォームは日次の遡及調査や相関の検証に使い、クエリの待ち時間が多少伸びても許容する層です。コールドは法規制や監査、事後鑑識のための長期保管で、取り出し時間や費用の増加を受け入れる代わりに単価を抑えます⁶。

ホット・ウォーム・コールドの方針例

ホットは30〜60日を標準とし、SOCのワークフローが回る速度を最優先に設計します。監査ログや管理者操作の記録は、誤検知のトリアージや変化点の確認に役立つため60〜90日を選ぶ価値があります。ウォームは90〜180日を目安に、相関や季節性の分析、脅威ハンティングの反復に充てると、検知の質が一段上がります。PCI DSSの対象範囲であれば、コールドに1年の保持を配し、少なくとも3カ月分はホットもしくはウォームで即時参照可能にして整合させます¹。さらに、内部統制上の要請で長期保持が必要なログ種別は、コールドを年単位に延長します。ただし個人データを含むログは、保存制限の原則から目的が消滅した時点で不可逆に削除できる仕組みを必ず備えるべきです²³。

要約・フィルタ・サンプリングの設計

保存期間を伸ばしつつコストを抑える実務的な手段が要約です。ホットでは生データを保持し、ウォームでは不要フィールドを落としてスキーマを細くし、コールドでは集計系列やBloom Filterなどの確率的データ構造を併置して先読みを高速化します。個人情報や機密フィールドは、収集時点でマスキングやトークナイゼーションを施し、復号鍵は監査統制の下で分離管理します。こうしたデータ最小化の原則は、プライバシー遵守とコスト最適化の両方に効きます²³。

{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0d",
        "actions": { "rollover": { "max_size": "50gb", "max_age": "30d" } }
      },
      "warm": {
        "min_age": "30d",
        "actions": { "forcemerge": { "max_num_segments": 1 } }
      },
      "cold": {
        "min_age": "90d",
        "actions": { "set_priority": { "priority": 0 } }
      },
      "delete": { "min_age": "365d", "actions": { "delete": {} } }
    }
  }
}

上はElasticsearchのILM（Index Lifecycle Management）を用いた一例で、30日でロールオーバー、90日でコールド、365日で削除という方針をコード化しています。保持日数を変える場合も、ポリシーのmin_ageを差し替えるだけで全クラスタに即時反映できます。

主要プラットフォームでの実装パターン

方針が決まれば、コードとポリシーで仕組みに落とし込みます。重要なのは、人手の運用ではなく宣言的な設定で一貫性を担保することです。

AWS CloudWatch Logs / CloudTrail と S3 ライフサイクル

CloudWatch Logsの各ロググループに保持期間（Retention Policy）を設定し、アーカイブはS3へエクスポートしてライフサイクルでコールドへ移行すると管理がシンプルになります。保持のドリフトを避けるため、CLIやSDKで全グループを定期的に是正します⁷。

aws logs put-retention-policy \
  --log-group-name "/aws/eks/cluster-1/cluster" \
  --retention-in-days 30

{
  "Rules": [
    {
      "ID": "logs-archive-to-glacier",
      "Status": "Enabled",
      "Filter": {"Prefix": "cloudtrail/"},
      "Transitions": [
        {"Days": 90, "StorageClass": "GLACIER"}
      ],
      "Expiration": {"Days": 365}
    }
  ]
}

上記のS3バケットライフサイクル設定は、90日でS3 Glacier層へ移行し、365日で期限切れにする例です。PCI DSS対象であれば、少なくとも3カ月はS3 Standardもしくは即時検索可能な層に残して整合させます¹。

BigQuery のパーティションと自動期限

時系列ログを日付パーティションで管理し、テーブルやパーティションの有効期限を設定すると、保持の自動化（データ保持ポリシー）とクエリコストの最適化が同時に実現します。

CREATE TABLE `prod.logs_app`
PARTITION BY DATE(timestamp)
OPTIONS (
  partition_expiration_days = 180
) AS
SELECT * FROM `raw.logs_app_ingest`;

分析窓を延ばしたい場合は、有効期限を変更するだけで再取り込みは不要です。サマリーテーブルを併設し、長期の傾向は集計済みデータで見ると費用対効果が上がります。

Elasticsearch/OpenSearch の ILM

前段で示したILMポリシーをインデックステンプレートにひも付けると、投入される全てのセキュリティログ／監査ログが自動的に同じ保持戦略（ホット／ウォーム／コールド）に従います⁶。

{
  "index_templates": [
    {
      "name": "logs-app-template",
      "index_template": {
        "index_patterns": ["logs-app-*"],
        "template": {
          "settings": { "index.lifecycle.name": "logs-365d" }
        }
      }
    }
  ]
}

導入後は、テンプレート名とポリシー名の整合性をCIで検査し、手動作成インデックスの混入を防ぎます。

Kubernetes Audit Log の粒度とローテーション

クラスタの監査ログは粒度が広すぎるとコストに跳ね、狭すぎると鑑識に耐えません。必要な動詞やリソース群に絞り、ノード側で安全にローテーションします。

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    verbs: ["create", "update", "delete", "patch"]
    resources:
      - group: "*"
        resources: ["deployments", "statefulsets", "configmaps", "secrets"]

ノードのlogrotateやコンテナランタイムの設定で世代数とサイズを制御し、集約先（例：Fluent Bit経由での転送）で温度帯に応じたストレージに配分します。Secretの本文は収集しない設計とし、必要な場合もハッシュやトークン化した値で代替します。

ポリシーの自動是正とエビデンス化

保持期間は設定して終わりではなく、継続的に是正されるべき性質です。クラウドではAPIで現状を列挙し、想定から外れた対象に対して機械的に修正をかけます。変更履歴と実行ログを保存すれば、監査への説明責任も果たせます。

import boto3

logs = boto3.client('logs')
TARGET_DAYS = 30

paginator = logs.get_paginator('describe_log_groups')
for page in paginator.paginate():
    for g in page.get('logGroups', []):
        name = g['logGroupName']
        days = g.get('retentionInDays')
        if days != TARGET_DAYS:
            logs.put_retention_policy(logGroupName=name, retentionInDays=TARGET_DAYS)

このようなジョブを週次で走らせ、結果をチケットに自動添付すると、是正のトレーサビリティが担保されます。

運用ガバナンスと継続的見直し

保持戦略は環境の変化に追従する必要があります。新規プロダクトの導入や脅威モデルの更新、事業のスケールに応じて、分析窓と温度帯の配分を3〜6カ月ごとに見直すサイクルを回すと、無駄なコストや盲点が早期に検知されます。

KPI/SLOで管理する

運用の健康状態を測る指標として、保持遵守率、即時参照できるデータ日数の中央値、アラートから一次調査完了までの所要時間、検索のP95レイテンシ、ストレージ単価当たりの有効クエリ数などを定義すると、コストと価値の両輪を同じメトリクス空間で議論できます。保持遵守率は常に100%を目標とし、逸脱が発生した際は自動是正の実行と原因の恒久対策をセットで記録します。

削除の証跡とリーガルホールド

削除は“やったはず”ではなく証跡で語れる状態が重要です。削除ジョブの実行ID、対象範囲、件数、所要時間を不変ストアに保存し、監査時に提示できるようにします。係争や調査のために一時的な保存停止（リーガルホールド）が必要な場合は、対象範囲をタグで限定し、ホールド解除の承認フローを明文化します。WORM（Write Once Read Many）対応のストレージを活用する場合は、ホールドの開始・終了のメタデータを併せて管理し、解除不能な設定を安易に採用しない慎重さが求められます。

検証クエリで“実際に消えているか”を確かめる

設定上は期限切れでも、実データが残っているケースは現場で珍しくありません。S3 Inventoryやデータウェアハウスのメタデータに対する検証クエリを定期的に走らせ、しきい値を超える残骸があれば即座に是正します。

-- Athena に取り込んだ S3 Inventory から 365日超のオブジェクトを検出
SELECT bucket, key, last_modified
FROM s3_inventory
WHERE last_modified < date_add('day', -365, current_date);

この種の検証結果はダッシュボードで可視化し、逸脱ゼロの状態を保てているかを日常的に確認します。

まとめ：保存期間は“足りるだけ、長すぎない”へ

ログの保存期間は、感覚やベンダーの初期値ではなく、分析窓、法的拘束、コストという三点から合意形成し、ホット・ウォーム・コールドの階層に落とし込むとブレません。PCI DSSの1年保持・3カ月即時参照という具体的な要件、GDPRや個人情報保護法の保存制限の原則¹²³、そして現場が必要とする調査の時間軸⁴を同じ土俵で数値化し、宣言的なポリシーと自動是正で運用に埋め込むのが近道です。

“必要十分で長すぎない”設計は、セキュリティとプライバシー、コストの均衡点にあります。自組織のログを三つの温度帯に並べ替え、ホットの分析窓、コールドの保持年数、削除の証跡を今日から言語化してみませんか。次のスプリントでは、1系統で良いので保持の自動是正ジョブを動かし、ダッシュボードに遵守率を載せるところまで進めると、チームの意思決定が一段引き締まります。

参考文献

  1. PCI Security Standards Council. PCI DSS v4.0, Requirement 10.4.1.1. https://www.pcisecuritystandards.org/document_library
  2. EUR-Lex. GDPR Article 5(1)(e) – Storage limitation. https://eur-lex.europa.eu/eli/reg/2016/679/oj
  3. 個人情報保護委員会. 個人情報の保護に関する法律についてのガイドライン（通則編）. https://www.ppc.go.jp/files/pdf/guidelines01.pdf
  4. IBM Newsroom (2021). IBM Report: Cost of a Data Breach Hits Record High During Pandemic. 平均287日の特定・封じ込め期間を報告。https://newsroom.ibm.com/2021-07-28-IBM-Report-Cost-of-a-Data-Breach-Hits-Record-High-During-Pandemic
  5. 国税庁. 帳簿書類の保存期間（法人税）. https://www.nta.go.jp/taxes/shiraberu/qa/hojin/09.htm
  6. Elastic Docs. Data tiers. https://www.elastic.co/guide/en/elasticsearch/reference/current/data-tiers.html
  7. AWS CLI Command Reference. logs put-retention-policy. https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html