1 ログの真正性の概要
ログの真正性とは、記録されたログが、記録内容の改変がなく、生成者や生成時刻などの出所情報が信頼でき、かつ保管・受け渡しの各段階で整合性が維持されていることを、技術的・手続的に根拠づけて確認できる性質である。監査や不正調査、障害解析などでログを証拠として扱う際の前提条件となる。
1.1 定義と目的
1.1.1 真正性が担保されるべき対象（内容・出所・時刻）
真正性の検証対象は大きく三要素に整理できる。第一に、ログ本文の内容が記録時から変更されていないこと（改ざんの不在）。第二に、ログの生成者、生成主体、生成経路といった出所が意図した対象に結び付くこと（誰が、どの仕組みで、どの条件下で作ったか）。第三に、生成時刻や時系列順序が運用上の前提を満たすこと（いつ発生したか、他の事象との並びが破綻していないこと）。
1.1.2 利用シーン（監査、調査、障害対応）
監査では、設定変更や権限付与、操作履歴が運用ルールに沿っているかを説明可能にすることが目的となる。不正調査では、疑義のある操作を行った主体と、その前後関係を示す根拠が求められる。障害対応では、障害発生の前後でシステムがどのように振る舞ったかを時系列として復元し、原因仮説の検証に使う。いずれも「ログが後から作られた」「内容が書き換えられた」「時間関係が崩れている」という疑念を最小化する必要がある。
1.2 真正性を損なう要因
1.2.1 改ざん
攻撃者や不正な管理者が、ログの保存前または保存後に内容を書き換える、あるいは一部を削除することで、事実関係の解釈が変わる。改ざんは本文だけでなく、付随するメタデータ（記録形式、イベント区分、参照IDなど）にも及びうるため、検証は単一項目ではなく整合性全体を対象にする必要がある。
1.2.2 すり替え・欠落
ログは、別ファイルとの取り違え、同名ファイルへの上書き、転送失敗後の再送方針が不適切な場合に、すり替えや欠落が発生する。さらに、収集側の条件によりイベントが間引かれることがあり、その場合は「欠落が正当な運用によるものか」「異常時の損失か」を区別しないと真正性評価ができない。
1.2.3 記録経路や保管の破綻
生成から保管、検証までの経路において、途中で信頼境界が崩れると真正性は弱まる。例えば、収集装置が同一の権限で改ざん可能、または不変保管が成立していない環境で、ログが編集・再構成されると、検証可能性が損なわれる。経路上の障害や移送手順の欠落も、整合性の維持に直接影響する。
1.3 真正性と関連概念
1.3.1 完全性
完全性は、ログが欠けず、必要な範囲が漏れなく記録・保存される性質を指す。真正性が「改変の不在」「出所や時刻の妥当性」にも踏み込むのに対し、完全性は主として「欠落や欠損がないこと」に焦点がある。したがって、完全性が高くても出所情報が誤っていれば真正性は損なわれる。
1.3.2 信頼性
信頼性は、ログが継続的に生成・収集され、運用上の期待に対して安定して機能する度合いを含む概念である。真正性は「証拠として成り立つ根拠」に重心があるため、単なる可用性向上だけでは足りない。逆に、真正性の仕組みを導入しても、障害で生成不能になれば利用可能性が下がるため、両者は補完関係にある。
1.3.3 非否認性
非否認性は、特定の主体がある操作や生成を行ったことを、その主体が後から否定しにくい性質である。ログの真正性には出所の保証が含まれるが、非否認性は「否定の困難さ」をより強い形で扱う。署名や証明書により、生成主体の識別と整合性が成立することで、否認が実務的に困難になる。
2 真正性を実現する技術手段
真正性を支える技術は、改ざん検知、出所の保証、時刻の整合、保管・受け渡しの保全という観点で整理できる。単一の手段ではなく、複数の層が連携することで「検証できる根拠」が形成される。
2.1 改ざん検知の仕組み
2.1.1 ハッシュとチェックサム
2.1.1.1 チェーン化・改ざん耐性の考え方
ハッシュ関数でログの内容に指紋を付与し、その値を検証することで、内容の変更を検出できる。さらにチェーン化（連結や前値参照）を行うと、ある時点の記録を改変した場合に後続の検証にも影響が波及し、部分的な修正や挿入が露見しやすくなる。チェーンは「順序の整合」を補強し、検証側が過去から一貫性を追跡できる構造を提供する。
2.1.2 メッセージ認証コード
メッセージ認証コード（MAC）は、共有鍵を用いてログ本文から一意なタグを生成する。検証者が同じ鍵を用いることで、改変の有無を判定できる。MACは計算効率が高い一方、鍵を誰が保持し、どの境界で管理するかが成否を左右する。鍵漏えいは検証の意味を薄めるため、運用上の統制とセットで設計する。
2.1.3 デジタル署名
デジタル署名は公開鍵基盤などを通じて、生成主体の秘密鍵で署名し、検証者は公開鍵で真正性を確認する。署名は出所と改ざん耐性を同時に高める手段として使われる。鍵失効や証明書の期限、更新運用が組み込まれていることが重要である。
2.2 出所の保証
2.2.1 署名鍵の管理
出所の保証は署名鍵の管理状態に強く依存する。鍵の保管場所（専用デバイス、セキュア領域、鍵管理サービスなど）、アクセス制御、利用手続き（承認フロー、監査ログ）、ローテーション、失効手順が設計対象となる。鍵の扱いが曖昧だと、署名があっても「本当に正しい主体が生成した」と言い切れない。
2.2.2 信頼できる発行者の設計
信頼できる発行者とは、署名や出所情報を発行する主体として組織が信頼境界を設計し、責任を割り当てた存在である。発行者の識別方法、証明書の発行経路、複数発行者を扱う場合の優先順位や合成ルールを定めることで、検証側がログの出所を合理的に評価できる。
2.3 時刻と整合の担保
2.3.1 タイムスタンプ付与
タイムスタンプ付与は、イベントが発生した時刻情報をログに結び付ける行為である。付与方式には、生成側での付与、収集側での付与、第三者的サービスによる付与などがある。目的に応じて、どの時点の時刻を採用するか、どの粒度で記録するかを明確にする必要がある。
2.3.2 時刻同期（誤差の扱い）
時刻の一致は完全一致を前提にしないことが多い。ネットワーク遅延やドリフトが存在するため、許容誤差（許容範囲）を定義し、その範囲内で整合性を評価する。補正の可否や記録方式（補正前後の保持、補正係数の記録）も、後から整合性判断を行う際に重要になる。
2.4 保管・受け渡しでの保全
2.4.1 WORM領域や不変ストレージの活用
不変ストレージ（WORM領域など）は、一定期間または条件を満たすまで上書きや削除を困難にする仕組みである。これにより、保存後の改ざん機会を減らし、検証時に「内容が保存後に変わっていない」という主張を強化できる。運用上は、保持期間、アクセス権、契約上の責任分界を明確化する。
2.4.2 移送時の完全性検証
受け渡し時には、転送中の破損、途中での取り違え、再送による重複などが起こりうる。移送前後でハッシュ値を照合したり、転送プロトコルに検証機構を組み込んだりすることで、保存先に届いたデータの同一性を確認する。さらに、到着順や欠落の検出に関するメタデータ設計も含めて整合性を守る。
3 ログ生成から検証までの運用設計
技術は運用により初めて有効化される。収集、保持、アクセス、検証タイミング、異常時対応の設計が一体となって、真正性の主張を支える。
3.1 ログ収集基盤の設計
3.1.1 ログ粒度と重要度の分類
収集粒度が細かすぎると負荷が増え、粗すぎると因果関係の復元が難しくなる。用途（監査、調査、解析）に応じてイベントの重要度を分類し、重要領域はより厳格な保全手段を適用する設計が現実的である。粒度と保持方針はセットで決める。
3.1.2 収集経路の分離と冗長化
ログが生成される経路と、保存・検証に向かう経路を分離すると、誤操作や権限逸脱が広がりにくくなる。加えて、収集経路に冗長性を持たせることで、単一点障害で欠落が生じる可能性を下げる。冗長化は、同一イベントの重複をどう扱うか（重複除外ルール）も併せて設計する必要がある。
3.2 監査可能な手続き
3.2.1 ログ保持ポリシー
保持期間、削除条件、アーカイブ手順、復元可能性の範囲などを定めることが監査可能性につながる。保持期間は規制や契約に左右され、例外時（法的要請、調査継続）には運用変更の記録が必要になる。保持ポリシーは技術設定と照合可能であることが望ましい。
3.2.2 アクセス制御と証跡
ログへのアクセスは、閲覧、エクスポート、復号、メタデータ閲覧などに分解し、権限を細かく付与する。アクセスの実行履歴もログとして別経路に記録し、後から誰がいつ何を行ったかを追えるようにする。これにより「検証者が改ざんしたのでは」という疑義を抑制できる。
3.3 検証プロセス
3.3.1 検証タイミング（保存時・定期・調査時）
検証は一度だけでは不十分である。保存時検証は受け渡し直後の破損や誤格納を早期に検出する。定期検証は長期保存中の劣化や設定誤りを継続監視する。調査時検証は、特定期間の整合性を集中的に確かめる工程として位置付けると、手戻りが減る。
3.3.2 失敗時の扱い（隔離・再収集・通報）
検証失敗には優先順位と対応手順を用意する。まず該当データを隔離し、原因が転送エラーか生成側の不整合かを切り分ける。必要に応じて再収集や別経路からの復元を行い、根本原因が運用またはシステムの欠陥にある場合は関係者へ通知する。報告には、失敗範囲、検出根拠、影響評価を含める。
4 検証・評価方法
真正性は「検証できること」に価値があるため、指標と手順を定義し、第三者が追試可能な形で提示することが重要である。
4.1 真正性指標
4.1.1 改ざん耐性の観点
改ざん耐性は、改変可能性の削減と検出容易性の両面から見積もる。チェーン構造がどこまで連鎖するか、署名鍵の管理状態、保存先の不変性など、攻撃に対する弱点がどこに残るかを評価する。
4.1.2 検証可能性（証拠性）
検証可能性は、検証者が必要な情報（公開鍵、検証用パラメータ、時刻根拠、保持ポリシー、整合性計算条件）に到達できるかに依存する。抽出したログだけでは判断できない場合、補足データの保全方針も含めて評価対象にする。
4.2 代表的な検証手順
4.2.1 署名検証とチェーン整合性
まず署名を検証し、署名対象が正しいログ要素に結び付いていることを確認する。その後、連結されたハッシュや順序情報によりチェーンの整合を確かめる。検証エラーが出た場合は、どの段の不一致かを特定し、単発の欠損と広域の改変を区別する。
4.2.2 抽出ログと保管ログの突合
抽出ログ（調査用に取り出したデータ）と、保管時のログやメタデータ（格納時ハッシュ、保存先の索引、移送記録）を突合し、同一性を確認する。ここで一致が取れれば「取り出し時点での改変」や「参照先の取り違え」を抑えられる。
4.3 監査・報告書への落とし込み
4.3.1 根拠の明確化（技術・手続き）
報告書には、どのアルゴリズムや検証手順を用いたか、鍵や時刻の前提が何か、運用手続きがどのように裏付けるかを明記する。技術だけでなく手続きの根拠（保持ポリシー、アクセス権、失敗時対応）が揃うことで、主張が一貫する。
4.3.2 説明責任と再現性
説明責任は、検証者が判断を再現できる程度の情報を残すことにより支えられる。検証条件、対象期間、例外処理、計算結果の要点を記録しておくことで、後日の監査や追加調査に耐えられる。
5 よくある課題と対策
実運用では、鍵・時刻・性能・ネットワークの問題が真正性評価を揺らす。代表的な課題ごとに、設計と手順で吸収する。
5.1 鍵管理・権限運用の落とし穴
5.1.1 鍵漏えい時の影響
署名やMACの鍵が漏えいすると、攻撃者が正当な形式のログを生成できる可能性がある。そのため、漏えい検知、鍵の失効、証明書更新、影響範囲の評価（いつから問題か）をあらかじめ手順化しておく必要がある。鍵の使用ログも合わせて追跡する。
5.1.2 権限過多によるリスク
ログ生成装置や検証基盤に過剰な権限が付与されると、内部者による改変の機会が増える。最小権限の原則により、署名生成、検証実行、設定変更、閲覧を分離し、各操作に監査証跡を紐付けるとリスクを下げられる。
5.2 タイムスタンプのズレ
5.2.1 NTP等の誤差と運用設計
時刻同期サービスの遅延や一時不調により、記録時刻が期待範囲から逸脱する場合がある。許容誤差を設定し、逸脱があった場合の扱い（隔離、補正前後の記録、再同期後の基準点）を明確にすることが重要である。
5.2.2 後追い補正の可否
後から時刻を補正すると、改ざん疑義を招くことがある。補正を行う場合でも、補正式の根拠や補正に使った観測値を保存し、「補正によって順序が変わりうる」点を評価可能にする設計が求められる。
5.3 コストとパフォーマンス
5.3.1 署名・検証の負荷
署名や検証は計算資源を要し、ログ量が増えると処理遅延が顕在化する。バッチ検証とリアルタイム検証の役割分担、重要度に応じた方式選択（高優先度だけ署名、低優先度はMACなど）により、真正性要件と性能要件のバランスを取る。
5.3.2 保持期間による最適化
長期保管では検証コストが積み上がる。保持期間を段階化し、短期では高頻度検証、長期では要点検証や整合性の要約情報（メタハッシュ）で負荷を抑えるなど、運用コストの最適化を行う。
5.4 ネットワーク障害時の整合性
5.4.1 バッファリングと再送
転送経路が不安定な場合、バッファリングで一時保留し、接続回復時に再送する。再送は重複を生みやすいため、イベントIDや連番に基づく重複排除、欠落検出の仕組みが必要になる。真正性の観点では、バッファ中のデータが改変されない前提も重要である。
5.4.2 欠落検出と補完方針
欠落を完全に回避できない状況もあるため、欠落検出の指標と補完方針を決める。例えば、別経路のログがあるなら突合して補う、なければ「不確実性」を明示した上で評価する。欠落を隠すような補完は、後から真正性主張を弱める。
6 ケーススタディ（身近な例で理解する）
ここでは、技術の考え方を日常的にイメージできる形で整理する。具体的な攻撃や対象組織の特定は避け、検証の流れに焦点を当てる。
6.1 監査ログの真正性確認
6.1.1 アクセス履歴の検証
会計システムの閲覧ログについて、署名検証により保存時点の整合を確認し、チェーン構造で順序も含めた破綻がないかを確認する。加えて、閲覧者のアクセス制御履歴と突合し、「権限のない人が見た」という主張が整合するかを点検する。
6.1.2 改ざん疑義の切り分け
改ざんが疑われる場合、最初に検証失敗の位置（どの区間で不一致が始まったか）を特定する。単一期間の不一致であれば転送・保管の問題の可能性が高く、広範な連鎖の破綻なら生成側または保全系の深刻な破綻が疑われる。証拠性の強さは、切り分け後に追加で確かめる情報量で変わる。
6.2 不正調査でのログ活用
6.2.1 いつ・誰が・何をしたか
調査では、出所情報（生成主体）と時刻根拠を中心に、操作の前後関係を再構成する。署名が成立するログ断片を優先し、欠落や時刻誤差がある部分は不確実性として扱う。これにより、疑いの強弱をログの性質に応じて説明できる。
6.2.2 因果の組み立てと限界
ログは観測結果であり、必ずしも直接の原因を示すとは限らない。例えば、同時刻近傍に多数の事象があると、因果は複数候補になりやすい。真正性が高いログほど時系列の信用度が上がるが、それでも「原因を確定するには追加情報が必要」という限界を明記することが、報告の質を左右する。
6.3 障害解析における証拠の扱い
6.3.1 時系列復元と整合性
障害の前後で複数コンポーネントのログを突合し、同一イベントIDや相互参照で結び付ける。各ログの真正性が確認できれば、イベント順序の矛盾が減り、推定モデルの誤差も小さくなる。結果として、最初に異常が観測された箇所に焦点を絞りやすくなる。
6.3.2 追加調査の判断
真正性の検証で不一致が出た領域は、原因分析から一旦切り離して、取得経路や保管設定の確認へ切り替える。逆に、整合が取れている部分は、再現試験や設定変更履歴の照合へ進む。この振り分けが、調査コストの節約につながる。
7 関連用語
7.1 監査証跡
監査証跡とは、操作や状態変化を追跡するための記録群であり、真正性の評価では改ざん耐性とアクセス制御の整合が重要になる。
7.2 署名検証
署名検証とは、デジタル署名の妥当性を公開情報で確かめ、ログが改ざんされていないことと出所が期待通りであることを確認する手順である。
7.3 不変ストレージ
不変ストレージとは、上書きや削除を制限し、保存後の改変機会を減らす保存方式である。真正性の主張を強化する役割を持つ。
7.4 チェーンハッシュ
チェーンハッシュとは、複数の記録を連結したハッシュ参照により、順序や欠落を含む整合性を検出しやすくする仕組みである。