バックアップ戦略：3-2-1ルールとイミュータブルバックアップ

バックアップがセキュリティ制御である理由

3-2-1バックアップルール

# 3-2-1 backup rule example:
# Copy 1 (primary): Production database server
#   Location: Primary data center, local SSD

# Copy 2 (local backup): Backup appliance
#   Media: Network-attached storage (different media type)
#   Location: Same data center (different failure domain)

# Copy 3 (offsite backup): Cloud storage
#   Media: Cloud object storage (S3, Azure Blob)
#   Location: Different geographic region (offsite)

# Single failure scenarios that DON'T lose all copies:
# - Production disk fails -> 2 copies remain
# - Data center flood -> offsite cloud copy survives
# - Local NAS failure -> production + cloud remain

3-2-1-1-0ルール：ランサムウェア対策の強化

# 3-2-1-1-0 extended backup rule:
# 3 copies of data
# 2 different media types
# 1 offsite copy
# 1 OFFLINE or air-gapped copy (new addition)
# 0 backup errors - all restores tested successfully

# Offline copy options:
# - Tape backups stored in a separate secured location
# - Detached USB/NAS drives (connected only during backup window)
# - Cloud backup with immutable storage (logically air-gapped)
# - Object lock with object versioning and delete protection

# Ransomware scenario: encrypts online storage
# -> Offline/immutable copy is intact -> restore succeeds

イミュータブルバックアップ：ランサムウェアに強いストレージ

# AWS S3 Object Lock configuration:
# Bucket: company-backups-immutable
# Object Lock: ENABLED (must be set at bucket creation)

# Retention mode options:
# GOVERNANCE mode: admins CAN override with special permission
# COMPLIANCE mode: NO ONE can delete or override (even root)

# Apply retention to backup objects:
# aws s3api put-object-retention \
#   --bucket company-backups-immutable \
#   --key db-backup-2026-06-20.tar.gz \
#   --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2026-09-20T00:00:00Z"}'

# Ransomware operator (even with AWS keys) cannot delete this
# object before 2026-09-20.

バックアップの種類：フル、増分、差分

# Backup schedule comparison:
# Full backup only:
# Mon: Full (100GB)  Tue: Full (100GB)  ...  Sun: Full (100GB)
# Total storage/week: 700GB | Restore: 1 file

# Full + Daily Incremental:
# Mon: Full (100GB)  Tue: Inc (5GB)  Wed: Inc (5GB) ...
# Total storage/week: ~130GB | Restore: Full + all Incrementals

# Full + Daily Differential:
# Mon: Full (100GB)  Tue: Diff (5GB)  Wed: Diff (10GB) ...
# Total storage/week: ~200GB | Restore: Full + latest Diff only

バックアップの暗号化と鍵管理

バックアップの分離とセグメンテーション

クラウドバックアップサービス

バックアップのテスト：欠かせない重要な手順

# Automated backup verification (conceptual):
# Daily: randomly select 10 backup files
# Restore each to temp location
# Verify SHA-256 checksum matches original
# Log: timestamp, file name, status (PASS/FAIL)
# Alert: if any file FAILS verification -> investigate immediately

# Monthly: restore last week's full database backup
# Spin up application in isolated test environment
# Run smoke tests: can users log in? Is data current?
# Log: restore time (compare vs RTO), data age (compare vs RPO)
# Alert: if restore exceeds RTO -> escalate DR infrastructure review

Grandfather-Father-Son (GFS)保持方式

バックアップの監視とアラート

# Backup monitoring alert conditions:
# Alert: CRITICAL if backup job has not started by scheduled time + 30 min
# Alert: HIGH    if backup job fails with non-zero exit code
# Alert: HIGH    if backup size < 80% of previous backup (partial failure?)
# Alert: MEDIUM  if backup did not replicate to offsite destination
# Alert: MEDIUM  if backup encryption verification failed
# Alert: INFO    if backup completed successfully (daily digest)

# Backup dashboard metrics to review weekly:
# - Jobs succeeded vs failed (7-day trend)
# - Average backup duration (performance trend)
# - Storage consumption (capacity planning)
# - Last successful restore test date

クイックチェック

レッスンのまとめ