validating-backup-integrity-for-recovery

復旧に向けたバックアップの完全性検証

使用する状況

以下のような場合に、このスキルを使用してください。

• ランサムウェアからの復旧にバックアップを利用する前に、バックアップの完全性を検証する
• 各バックアップジョブの完了後に実行する、自動バックアップ検証パイプラインを構築する
• コンプライアンス（SOC 2、ISO 27001、NIST CSF RC.RP-03）に向けて、復旧可能性を確認するためにバックアップインフラストラクチャを監査する
• 災害が発生する前に、バックアップストレージ内のサイレントデータ破損（ビット腐敗）を検出する
• イミュータブルバックアップやエアギャップバックアップが改ざんされていないことを検証する

初回のバックアップ設定やスケジュール作成には使用しないでください。このスキルは、バックアップ後の検証に焦点を当てています。

前提条件

• バックアップストレージ（ローカル、NAS、S3、Azure Blob、GCS）へのアクセス
• hashlib（標準ライブラリ）を備えた Python 3.9+
• 比較用のバックアップマニフェストまたはベースラインのハッシュファイル
• 復元テスト用の隔離環境
• バックアップツールの CLI にアクセスできること（restic、borgbackup、rclone、またはベンダー固有のツール）

ワークフロー

ステップ 1：ベースラインハッシュマニフェストを生成する

バックアップ時に、すべてのファイルの暗号学的フィンガープリントを作成します。

# Generate SHA-256 manifest for a directory
find /data/production -type f -exec sha256sum {} \; > /manifests/prod_baseline_$(date +%Y%m%d).sha256

# Verify manifest format
head -5 /manifests/prod_baseline_20260319.sha256
# e3b0c44298fc1c149afbf4c8996fb924...  /data/production/config.yaml
# a7ffc6f8bf1ed76651c14756a061d662...  /data/production/database.sql

ステップ 2：バックアップアーカイブの完全性を検証する

バックアップアーカイブ自体が破損していないことを確認します。

# Restic: verify backup repository integrity
restic -r s3:s3.amazonaws.com/backup-bucket check --read-data

# Borg: verify backup archive
borg check --verify-data /backup/repo::archive-2026-03-19

# Tar with gzip: verify archive integrity
gzip -t backup_20260319.tar.gz && echo "Archive OK" || echo "Archive CORRUPTED"

# AWS S3: verify object checksums
aws s3api head-object --bucket backup-bucket --key daily/2026-03-19.tar.gz \
  --checksum-mode ENABLED

ステップ 3：隔離環境への復元テストを実行する

# Restore to isolated test directory
restic -r s3:s3.amazonaws.com/backup-bucket restore latest --target /restore-test/

# Generate hash manifest of restored data
find /restore-test -type f -exec sha256sum {} \; > /manifests/restored_$(date +%Y%m%d).sha256

# Compare baseline and restored manifests
diff <(sort /manifests/prod_baseline_20260319.sha256) \
     <(sort /manifests/restored_20260319.sha256)

ステップ 4：データの完全性を検証する

# Count files in original vs restored
echo "Original: $(find /data/production -type f | wc -l) files"
echo "Restored: $(find /restore-test -type f | wc -l) files"

# Check total size
echo "Original: $(du -sh /data/production | cut -f1)"
echo "Restored: $(du -sh /restore-test | cut -f1)"

# Database consistency check after restore
pg_restore --list backup.dump | wc -l  # Count objects in dump
psql -c "SELECT schemaname, tablename FROM pg_tables WHERE schemaname='public';" restored_db

ステップ 5：バックアップ内のランサムウェアの痕跡を検出する

復旧にバックアップを使用する前に、ランサムウェアの兆候をスキャンします。

# Check for common ransomware file extensions
find /restore-test -type f \( \
  -name "*.encrypted" -o -name "*.locked" -o -name "*.crypt" \
  -o -name "*.ransom" -o -name "*.pay" -o -name "*.wncry" \
  -o -name "*.cerber" -o -name "*.locky" -o -name "*.zepto" \
\) -print

# Check for ransom notes
find /restore-test -type f \( \
  -name "README_TO_DECRYPT*" -o -name "HOW_TO_RECOVER*" \
  -o -name "DECRYPT_INSTRUCTIONS*" -o -name "HELP_DECRYPT*" \
\) -print

# Check file entropy (high entropy = possible encryption)
# Files with entropy > 7.9 out of 8.0 are likely encrypted
python agent.py --entropy-scan /restore-test

ステップ 6：検証を自動化してスケジュールする

# cron-based validation schedule
# Run nightly after backup window
0 4 * * * /opt/backup-validator/agent.py --validate-latest --notify-on-failure
# Weekly full restore test
0 6 * * 0 /opt/backup-validator/agent.py --full-restore-test --config /etc/backup-validator/config.json

主な概念

用語	定義
ハッシュマニフェスト	データセット内のすべてのファイルについて、完全性のベースラインとして使用する暗号学的ハッシュ（SHA-256）を記録したファイル
ビット腐敗	ストレージメディア上のデータが徐々に破損し、ファイルの内容が気付かないうちに変化すること
イミュータブルバックアップ	定められた保持期間中、変更や削除ができないバックアップ
復元テスト	復旧可能性を確認するために、バックアップから隔離環境へデータを復元するプロセス
ファイルエントロピー	ファイル内容のランダム性を示す尺度。暗号化されたファイルのエントロピーは、通常 8.0 ビット／バイトに近い値になります
3-2-1 ルール	データを 3 個のコピーで保持し、2 種類の異なるメディアを使い、そのうち 1 個をオフサイトに保管すること
バックアップチェーン	復旧のためにすべてが正常である必要がある、フルバックアップと増分バックアップの連続した構成

ツールとシステム

ツール	目的
Restic	完全性検証機能を内蔵した、暗号化および重複排除対応のバックアップ
BorgBackup	アーカイブ検証機能を備えた重複排除対応のバックアップ
Rclone	チェックサム検証に対応したクラウドストレージ同期
AWS S3 Object Lock	WORM コンプライアンスに対応したイミュータブルバックアップストレージ
Azure Immutable Blob	コンプライアンス向けの改ざん防止バックアップストレージ
sha256sum	ファイルの完全性確認に使用する標準的なハッシュ計算ツール
pg_restore	PostgreSQL バックアップの検証と復元テスト

よくある落とし穴

• 復元テストを一度も実施しない：最もよくある失敗です。一度も復元されていないバックアップは、検証されていない想定にすぎません。
• アーカイブの完全性だけを確認し、データの完全性を確認しない：有効な tar.gz に、破損したファイルの内容が含まれていることがあります。必ず個々のファイルをハッシュ化してください。
• ランサムウェアをスキャンせずに最新のバックアップを信頼する：感染がバックアップより前に発生していた場合、バックアップに暗号化されたファイルが含まれている可能性があります。
• 増分バックアップチェーンの完全性を無視する：増分バックアップが 1 つ破損しただけで、復元チェーン全体が機能しなくなることがあります。
• 検証失敗時のアラートがない：バックアップ検証は、何も通知せずにログへ記録するだけでなく、アラートで監視する必要があります。
• 完全性確認に MD5 を使用する：MD5 の暗号学的安全性は破られています。完全性の検証には SHA-256 または SHA-3 を使用してください。

参考資料

• NIST SP 800-184：サイバーセキュリティインシデントからの復旧に関するガイド
• NIST CSF 2.0 RC.RP-03：バックアップの完全性検証
• CIS Controls v8：コントロール 11 - データ復旧
• CISA ランサムウェアガイド：https://www.cisa.gov/stopransomware