バックアップから復元した発注データの改ざん防止チェック— チェックサム・監査ログ・銀行突合

1. 復元直後の前提確認

1-1. 復元点の記録

復元したバックアップのタイムスタンプ、ファイル名、SHA-256、復元実行者、復元理由をインシデント票に固定します。
以降のチェック結果はすべてこの復元点IDに紐づけ、後から報告書を再構成できるようにします。

1-2. 書き込み停止

チェック完了まで本番への新規発注・支払バッチを停止し、読み取り専用モードまたはメンテナンスフラグを立てます。
停止中の入力は別キューに溜め、チェック合格後に時系列順で再投入します。

1-3. バックアップ運用との接続

定期バックアップの取得頻度と保管場所は発注データのバックアップ引き継ぎで設計している前提です。
復元チェックはその設計が機能したかを検証する工程です。

2. チェックサムと行単位ハッシュ

2-1. テーブル全体のハッシュ

復元直後の発注テーブル全行について、主キー順に正規化CSVを生成し、全体SHA-256を計算します。
バックアップ取得時に保存していた期待ハッシュと一致しない場合、転送破損か復元先ミスを疑います。

2-2. 行ごとの内容ハッシュ

po_id ごとに amount、status、payment_due、updated_at を連結した行ハッシュ列を再計算し、バックアップメタデータと比較します。
不一致行だけを「要人手確認」リストへ出力し、一括上書きはしません。

2-3. 添付ファイルの整合

発注行に紐づくPDFのオブジェクトストレージETagもバックアップ一覧と突合します。
DBだけ復元してファイルが古い、という部分復旧をここで検知します。

3. 監査ログの連続性

3-1. シーケンス番号

監査ログに monotonic な seq がある場合、復元後の最大 seq が復元点以前で止まっていないか確認します。
欠番があればログ自体が切れているか、復元後に不正削除があったかを調査します。

3-2. チェーン署名

前行ハッシュを次行に含めるチェーン方式なら、復元後に再検証スクリプトを走らせ、最初の断絶行を特定します。
断絶以降のログは信頼できないため、別ソースで補完する必要があります。

3-3. 発注・支払リンク

監査ログの po_id と支払イベントIDの対応は発注と支払の監査リンクの設計どおり復元されているかをサンプル100件で確認します。

4. 支払ステータスと銀行実績の突合

4-1. 復元点以降の出金

復元点以降に銀行で実行済みの振込一覧をCSV取込し、台帳上「未払い」のまま残っている行を抽出します。
該当行は支払済みへ訂正し、訂正理由=復元巻き戻しと監査ログに残します。

4-2. 二重支払リスク

台帳が「未払い」に戻った案件で、経理が再度支払バッチに載せないよう、復元後48時間は同一po_idの支払申請をブロックします。
ブロック解除は銀行突合と監査ログ訂正の両方完了後のみとします。

4-3. 60日起算への影響

支払日が巻き戻ると遅延利息計算も狂うため、支払60日の起算レビュー用に、復元前後の payment_due 差分レポートを必ず出力します。

5. 重複発注番号と幽霊行

5-1. po_id 一意性

復元後に po_id の重複がないか GROUP BY で検出します。
重複がある場合、新しい方を退避テーブルへ移し、採番ルールの max+1 を再設定します。

5-2. 復元後に再投入したキュー

停止中に溜めた入力を再投入する際、同じ po_id が二重作成されていないか、投入前後で件数を比較します。
外部システムからの再同期は idempotent キー必須にします。

5-3. 電子帳簿保存法との関係

タイムスタンプ付与済みデータを復元した場合、電子帳簿保存の二重保存要件を満たしているか法務と確認します。
トリカク（torikaku） 単体のチェックだけでは足りず、タイムスタンプ事業者側の記録も照合してください。

6. チェック完了と運用再開

合格条件: 全体ハッシュ一致、行ハッシュ不一致ゼロまたは全件人手解決、監査ログ断絶なし、銀行未反映ゼロ、po_id重複ゼロ。
合格後、インシデント票にチェック実行者2名のサインを付け、書き込み停止を解除します。
不合格のまま再開した事例は内部監査で必ず指摘されるため、例外運用は記録しない方針が安全です。

7. ドリルと runbook 整備

7-1. 月次リストアドリル

本番以外の環境で、直近バックアップを意図的にリストアし、チェックスクリプトを毎月実行します。
ドリル結果は本番復元と同じ報告書フォーマットで残し、手順の陳腐化を防ぎます。

7-2. 関係者連絡網

復元中の問い合わせ窓口、経理の支払停止判断者、取引先へ送る遅延テンプレを runbook 先頭に置きます。
インシデント中にテンプレを探す時間が、二重支払リスクを広げます。

7-3. クラウド署名付きURLの失効

復元でオブジェクトストレージのキーが変わる場合、旧URLを参照する発注行へのリンク切れを一括検出します。
リンク切れだけでは支払は止まりませんが、監査時に証跡不在として指摘されます。

8. 復元後のコンプラ再確認

8-1. 書面交付ログ

復元点以降に交付したはずの電子書面が台帳から消えていないか、交付ID単位で件数比較します。
欠落がある場合は、クラウド発注システムの書面保管側の保管ログから再リンクします。

8-2. 週次レビューのやり直し

復元で消えた期間分の60日レビューを、銀行・監査ログ・メール証跡を使って再構成します。
再構成不能な週は「データ欠損週」として経営報告に明示し、隠さない方針が後 Trust を守ります。

8-3. 再発防止タスク

チェック合格後1週間以内に、バックアップ頻度見直し、PITRテスト追加、権限分離の再点検をチケット化します。
インシデント報告だけで終えると、同型障害が四半期内に再発しがちです。

よくある質問

Q. 部分復元だけできませんか

テーブル単位の部分復元は整合性リスクが高いです。
どうしても行う場合は、関連テーブルすべてを同じ復元点に揃え、チェックサムをテーブルごとに取ります。

Q. クラウドのPITRとバックアップファイルはどちらを正にしますか

銀行実績と監査ログが残っている方を正とし、もう一方は参照に留めます。
二系統が食い違う場合は、より新しい外部証跡を優先するルールを事前に決めてください。

Q. チェックにどれくらい時間がかかりますか

10万件規模で自動チェック30分、銀行突合と人手確認半日が目安です。
スクリプトは平時のドリルで月1回実行し、復元当日に初実行しないようにします。

Q. 改ざん検知と復元ミス検知の違いは

手順は同じです。
復元ミスは意図がなくても結果としてデータが信頼できなくなるため、改ざん防止チェックと同じゲートを通します。

Q. チェック合格後にまた障害が出たら

二度目の復元では前回の復元点ID以降の差分だけをマージする方式に切り替え、全件再復元を避けます。
マージ手順も別紙の runbook に用意してください。

Q. 復元チェックを外注できますか

スクリプト実行は外注可能ですが、合格判断と運用再開ボタンは社内担当2名が行います。
外注だけに任せると、銀行突合の責任分界が曖昧になります。

運用で詰まりやすい点

復元後に「直した」手修正が入る

復元直後の手修正は、改ざん検知のベースラインを壊します。
修正が必要なら復元検証サインオフ後に別トランザクションとして記録し、理由コードを必須にします。

バックアップ世代の取り違え

昨日のバックアップと先週のバックアップを取り違えると、支払済フラグが巻き戻ります。
復元ジョブのログにバックアップID・取得時刻・検証ハッシュを必ず残します。

まとめ

• 復元点IDを固定し、チェック完了まで書き込み停止する
• 全体ハッシュと行ハッシュで転送・復元ミスを検知する
• 監査ログの seq とチェーン署名で断絶行を特定する
• 銀行実績で未払い巻き戻しと二重支払を防ぐ
• po_id 重複と再投入キューの idempotent キーを確認する

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。