2026.10.22 セキュリティ

イミュータブルバックアップとは：S3 Object Lock・Vault Lockの実装手順と保持期間の決め方

イミュータブルバックアップは、決めた保持期間のあいだ、管理者権限を持つ人でも削除・上書きできない状態でバックアップを置く方式です。ランサムウェアの攻撃者は暗号化の前にバックアップを消しにくるため、取得しているだけでは戻せません。本記事では、Amazon S3 Object Lock・AWS Backup Vault Lock・Azure・Google Cloudの方式の違い、Terraformで消せない保管庫を作る設定例、保持期間の決め方、鍵や権限が原因で戻せなくなる落とし穴までを、2026年10月22日時点の公式ドキュメントに沿って整理します。

まとめ：イミュータブルバックアップは本番と別の権限で消せない複製を持つこと

守るべき条件は1つです。本番環境の管理者権限を攻撃者に奪われても、消せない場所に複製が残っていること。AWSなら論理エアギャップ保管庫かVault Lockのコンプライアンスモード、S3に直接置くならObject Lockのコンプライアンスモードがこの条件を満たします。

導入でつまずくのは設定そのものより、保持日数と料金、鍵の管理、復元の練習です。まずガバナンスモードか猶予期間つきで動作を確かめ、保持日数を検知にかかる日数から逆算してからロックを確定します。復元テストを月1回自動で回し、戻せることを記録に残すところまでを1つの工程として組みます。

イミュータブルバックアップの仕組み：通常のバックアップが消される理由とWORM

イミュータブル（immutable）は「変更できない」という意味です。ストレージ側が書き込みは1回、読み出しは何度でもというWORM（Write Once Read Many）の規則で動き、期限前の削除や上書きの要求をAPIの段階で拒否します。

警察庁の集計で復元40件中29件が失敗した理由とバックアップの置き場所

警察庁の令和8年上半期の集計では、ランサムウェア被害でバックアップからの復元を試みた有効回答40件のうち、戻せたのは11件でした。戻せなかった29件の理由で最も多いのが、バックアップ自体の暗号化・消去で14件です。

原因は置き場所にあります。バックアップサーバーやNASを本番と同じActive Directoryの管理者で操作できる構成では、攻撃者は乗っ取った権限でそのままバックアップを消せます。暗号化の範囲を広げる前に復旧手段を断つのが、攻撃側の定石です。NASが暗号化された事案の初動は佐賀大学のランサムウェア被害と事務NASの暗号化で、仮想化基盤ごと止まった事案は大阪公立大学のランサムウェア被害と仮想化基盤のバックアップを守る設定で扱っています。

WORM・論理エアギャップ・オフライン保管で防げる攻撃の範囲の違い

WORMは「消す操作」を拒否します。ただし、同じアカウントの中にあれば、アカウントの閉鎖や鍵の削除で間接的に読めなくされる余地が残ります。論理エアギャップは、WORMに加えて保管庫を別の管理単位に切り離し、本番のアカウントを失っても別アカウントから戻せるようにする考え方です。テープなどのオフライン保管は物理的に切り離しますが、復旧に日数がかかります。

実務の優先順位ははっきりしています。まずWORMで消せない複製を1つ作り、次に管理単位を分ける。オフライン媒体は、法令で長期保管が求められるデータに限って足せば足ります。サーバーを作り直して更新するイミュータブルインフラは名前が似ていますが、守る対象がサーバー構成で、バックアップの話ではありません。

クラウド別の実装方式比較：4方式のロック単位・解除権限・保持期間の違い

比較対象はS3 Object Lock・AWS Backup・Azure・Google Cloudです。主要クラウドはいずれもWORMのストレージ機能を持っています。違いはロックの単位と、ロックを外せる人の範囲です。

4方式の比較表：ロックの対象単位・解除できる人・保持期間の上限

方式	ロックの単位	確定後に解除できる人	保持期間の上限
S3 Object Lock	オブジェクトのバージョン	コンプライアンスでは誰もいない	可変保持で36,500日
AWS Backup Vault Lock	バックアップ保管庫	猶予期間後は顧客もAWSも不可	36,500日
Azure Blob 不変ストレージ	アカウント・コンテナー・バージョン	ロック後は削除不可・延長のみ	146,000日
Google Cloud Bucket Lock	バケットの保持ポリシー	ロック後は削除・短縮不可	100年

出典は各社の公式文書です。S3 Object Lockの解説によると、コンプライアンスモードのオブジェクトを期限前に消す手段はAWSアカウントの削除しかありません。AWS Backup Vault Lockは追加料金なしで、猶予期間（3日以上）を過ぎると保管庫とロックが変更不能になります。AzureはBlobの不変ストレージで、ロック前の状態をテスト用とする位置づけです。Google CloudはBucket Lockのロック時にプロジェクト削除を防ぐlienを自動で付けます。

ガバナンスモードとコンプライアンスモードの違いと本番で選ぶ側

S3とAWS Backupはどちらも2つのモードを持つ仕組みです。ガバナンスモードは、S3ならs3:BypassGovernanceRetention権限を持つ人が専用ヘッダを付ければ削除できます。S3のコンソールはこのヘッダを既定で付けるため、権限を持つ管理者がコンソールから消すと、そのまま成功します。

本番のランサムウェア対策ではコンプライアンスモードを選びます。攻撃者が狙うのはまさに強い権限を持つアカウントで、そこで解除できる設定は対策になりません。ガバナンスモードは、保持日数と料金を確かめる検証期間に限って使います。

TerraformでAWSに消せないバックアップ保管庫を作る手順と設定例

AWS Backupを使うなら、日次のバックアップを通常の保管庫に取り、そのコピーを論理エアギャップ保管庫へ送る構成が組みやすい形です。製品の基本と対応サービスはAWS Backupとはで解説しています。

論理エアギャップ保管庫とコピー設定をTerraformで書く設定例

論理エアギャップ保管庫は、作った時点でコンプライアンスモードのVault Lockを備え、既定ではAWS所有のキーで暗号化されます。最小保持は7日以上が必須です。リソース名と引数はTerraform AWS Providerのドキュメントに沿っています。

# 通常の保管庫（日次バックアップの一次置き場）
resource "aws_backup_vault" "primary" {
  name = "prod-primary-vault"
}

# 論理エアギャップ保管庫（コンプライアンスモードのロックを内蔵）
resource "aws_backup_logically_air_gapped_vault" "lag" {
  name               = "prod-lag-vault"
  min_retention_days = 7
  max_retention_days = 90
}

resource "aws_backup_plan" "daily" {
  name = "daily-with-lag-copy"

  rule {
    rule_name         = "daily"
    target_vault_name = aws_backup_vault.primary.name
    schedule          = "cron(0 17 * * ? *)" # 毎日 02:00 JST

    lifecycle {
      delete_after = 14
    }

    # 消せない保管庫へコピー（保持日数は min〜max の範囲内に置く）
    copy_action {
      destination_vault_arn = aws_backup_logically_air_gapped_vault.lag.arn
      lifecycle {
        delete_after = 35
      }
    }
  }
}

resource "aws_backup_selection" "tagged" {
  name         = "backup-tagged"
  plan_id      = aws_backup_plan.daily.id
  iam_role_arn = var.backup_role_arn

  selection_tag {
    type  = "STRINGEQUALS"
    key   = "backup"
    value = "daily"
  }
}

コピーの保持日数が保管庫の最小・最大から外れると、コピージョブは失敗します。保管庫を作った後にterraform destroyで消そうとしても、復旧ポイントが残る限り削除できません。Terraformの初期設定と状態管理はTerraformでAWSを構築する手順にまとめています。

S3 Object Lockを既存バケットに後付けする順序と既定の保持

Object Lockの設定手順によると、既存のバケットにも後から有効化できます。ただし一度有効にすると、Object Lockの無効化もバージョニングの停止もできません。サーバーアクセスログの出力先にも使えなくなるため、ログ用のバケットとは分けます。

# 1. バージョニングを先に有効化する
aws s3api put-bucket-versioning --bucket example-backup-copy \
  --versioning-configuration Status=Enabled

# 2. まずガバナンスモード14日で既定の保持を入れて動作を確かめる
aws s3api put-object-lock-configuration --bucket example-backup-copy \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":14}}}'

# 3. 検証が済んだらコンプライアンスモードに切り替える
aws s3api put-object-lock-configuration --bucket example-backup-copy \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":35}}}'

既定の保持は、設定した後に置かれたオブジェクトだけに掛かります。既存のファイルを守るには、バックアップソフトから書き直すか、オブジェクトごとに保持を付け直します。

ロックが効いているかをCLIで確かめる：削除が403になるまで

設定の画面表示だけで済ませず、実際に消せないことを確かめます。S3では、バージョンIDを付けない削除は200で成功したように見え、削除マーカーが1つ積まれるだけです。確認すべきはバージョンを指定した削除が拒否されるかどうかです。

# 対象オブジェクトの保持状態を見る（Mode と RetainUntilDate）
aws s3api get-object-retention --bucket example-backup-copy \
  --key db/2026-10-22.dump --version-id "$VERSION_ID"

# バージョン指定の削除が AccessDenied で失敗すれば正しくロックされている
aws s3api delete-object --bucket example-backup-copy \
  --key db/2026-10-22.dump --version-id "$VERSION_ID"

# AWS Backup の保管庫は Locked と LockDate を確かめる
aws backup describe-backup-vault --backup-vault-name prod-lag-vault

AWS BackupのLockedがtrueでも、LockDateより前は猶予期間中でロックを外せます。猶予期間の終わりを台帳に書いておき、その日までに保持日数と月額を見直します。

保持期間の決め方：検知までの日数・RPO・保管料金から日数を逆算

保持日数は短すぎると守れず、長すぎると解約できない固定費になります。決める材料は、侵入に気づくまでの日数、戻したい時点の粒度、払える保管料金の3つです。

侵入から検知までの日数を上回る保持日数を置く理由とログ保管の目安

攻撃者は侵入してから暗号化するまでの間に、バックアップへ不正な変更を混ぜたり、古い世代が期限切れになるのを待ったりできます。保持日数が検知までの日数より短いと、残っている世代はすべて侵入後のもので、どれに戻しても安全とは言い切れません。

目安は、自社でログを遡れる日数と同じかそれ以上です。CloudTrailやVPNのログを90日保管しているなら、保管庫の最大保持も90日まで取り、日次を35日・週次を90日と世代で分けると費用を抑えられます。戻したい時点の考え方はDR対策のRPO・RTOの目安を参照してください。保持日数がまだ決めきれないデータには、S3の可変保持（イベントホールド）も選択肢です。公式は用途として、ランサムウェアや誤削除に備えた復旧期間の調整を挙げています。

保持日数×容量で決まる保管料金と「無期限」設定で残り続ける固定費

AWS Backup Vault LockとAzureの不変ストレージは、ロック自体に追加料金がかかりません。費用の大半は保管料金です。月額はおおむね「1世代の容量×保持する世代数×単価」で決まり、増分バックアップなら2世代目以降は差分の容量で計算します。単価はAWS Backupの料金ページでリソース種別ごとに確かめます。

最も避けたいのは、保持期間を「常に保持」にした復旧ポイントをロック済みの保管庫に入れることです。Vault Lockの公式文書は、猶予期間後はその復旧ポイントが永久に残り、変更も削除もできないと警告しています。ロックを確定する前に、プランのライフサイクル設定に無期限のルールが紛れていないかを確認します。

イミュータブルでも戻せない落とし穴：鍵・アカウント・復元テストの抜け

データが消えなくても、読めなければ戻せません。消せないことと戻せることは別に確かめる必要があります。

KMSキーの削除とアカウント閉鎖で復元できなくなる経路と権限管理

自分で管理するKMSキーで暗号化したバックアップは、そのキーを削除されると復号できません。論理エアギャップ保管庫が既定でAWS所有のキーを使うのは、この経路を断つためです。顧客管理キーを使う場合は、キーの削除権限を本番の管理者から外します。

もう1つはアカウントの閉鎖です。Vault Lockの文書によると、ロック済みの保管庫を持つアカウントを閉じると90日間停止され、再開しなければロック中でも中身は削除されます。論理エアギャップ保管庫は、複数の承認者で別アカウントから復元するマルチパーティ承認との組み合わせが可能です。管理アカウントには多要素認証（MFA）を必ず掛け、AWSの規範ガイダンスが勧めるSCPでの操作制限も足します。

AWS Backupの復元テストで戻せることを月次で確かめる設定

AWS Backupの復元テストは、決めた日時に復旧ポイントを選んで実際に復元し、終わったら復元したリソースを自動で削除します。選び方は期間内の最新かランダムで、古い世代が壊れていないかを見るにはランダムが向きます。

aws backup create-restore-testing-plan --restore-testing-plan '{
  "RestoreTestingPlanName": "monthly_restore_test",
  "ScheduleExpression": "cron(0 1 ? * 2#1 *)",
  "ScheduleExpressionTimezone": "Asia/Tokyo",
  "StartWindowHours": 24,
  "RecoveryPointSelection": {
    "Algorithm": "RANDOM_WITHIN_WINDOW",
    "IncludeVaults": ["*"],
    "RecoveryPointTypes": ["SNAPSHOT"],
    "SelectionWindowDays": 35
  }
}'

aws backup create-restore-testing-selection \
  --restore-testing-plan-name monthly_restore_test \
  --restore-testing-selection '{
    "RestoreTestingSelectionName": "rds_daily",
    "ProtectedResourceType": "RDS",
    "IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
    "ProtectedResourceArns": ["*"]
  }'

この例は毎月第1月曜の午前1時（日本時間）から24時間以内に、過去35日の中からランダムに1世代を選んでRDSを復元します。テスト対象はAurora・RDS・EC2・EBS・EFS・DynamoDB・S3などで、AWS Backup Audit Managerと組み合わせると復元にかかった時間が目標内かも判定できます。

導入判断：イミュータブルバックアップを入れるべき組織と過剰な場面

判断の軸は2つです。本番の管理者がバックアップを消せる構成か、データを作り直すのに業務の許容停止日数を超える時間がかかるか。両方に当てはまるなら導入を先送りにしません。

採用すべき条件：本番と同じ管理者権限でバックアップを消せる構成

基幹システムのデータベース、会計・人事給与のデータ、顧客情報を持つWebシステムは対象です。バックアップサーバーやNASの管理者が本番と同じドメイン管理者で、保管先も同じ認証で操作できるなら、今の構成は警察庁の集計で最多だった「暗号化・消去」の条件にそのまま当てはまります。オンプレミスの環境でも、AWS Backupのゲートウェイやバックアップソフトの出力先をObject Lock付きのS3にすれば、クラウド側で消せない複製を持てる構成です。方式の基本はシステムバックアップとはで確認できます。

再生成できるデータで導入を見送ってよい場面と外部に構築を任せる範囲

Gitやインフラのコードから数時間で作り直せる検証環境、他システムから再生成できる集計データは、イミュータブルにしても費用が増えるだけです。この場合はスナップショットと作り直しの手順書で足ります。逆に、保持日数を決めないままコンプライアンスモードを確定するのは最悪の選び方で、解約できない保管料金だけが残ります。

保持日数の設計、アカウントの分割、Terraformでの保管庫と復元テストの構築は、一度決めると後から変えられない部分を含みます。一創ではAWS・Google Cloud・Azureのインフラ構築として、既存環境の棚卸しから消せない保管庫の設計・構築、復元テストの運用までを受けています。

イミュータブルバックアップのよくある質問：料金・既存環境・保持期間

導入を検討する担当者から寄せられやすい質問に答えます。

S3のバージョニングだけではランサムウェア対策になりませんか？

なりません。バージョニングは上書き前の版を残しますが、権限を持つ人は古い版もバージョンIDを指定して削除できます。攻撃者が管理者の資格情報を手に入れれば、全バージョンを消せます。Object Lockはバージョニングを前提に、その版の削除自体を期限まで拒否する仕組みです。両方を有効にし、Object Lockはコンプライアンスモードで使うことが条件になります。

保持期間を設定した後で短くすることはできますか？

コンプライアンスモードやロック済みのポリシーでは短縮できません。S3 Object Lock・Azure・Google Cloudのいずれも、延長はできても短縮はできない設計です。AWS Backup Vault Lockは猶予期間中であれば設定を変えたりロックを外したりできます。短縮できない前提で、最初はガバナンスモードや猶予期間を使い、保持日数と料金を確かめてから確定します。

オンプレミスのNASやファイルサーバーでも使えますか？

使えます。方法は2つあります。1つはNAS製品が持つイミュータブルスナップショットを使う方法で、復旧は速い一方、NAS本体の管理画面を奪われると同じ箱の中で守れません。もう1つは、バックアップソフトやAWS Backupのゲートウェイを経由してObject Lock付きのクラウドストレージへ複製する方法です。業務停止の影響が大きい組織は両方を併用します。

イミュータブルにすると追加の料金はかかりますか？

ロック機能自体はAWS Backup Vault Lock、Azureの不変ストレージとも追加料金なしと公式に明記されています。かかるのは保持期間中の保管料金です。消せない分だけ世代が積み上がるため、その容量が課金の対象になる仕組みです。S3 Object Lockはバージョニングが前提のため、上書きで増えた旧版の容量にも料金が発生します。月額は容量と保持日数で見積もり、ロックの確定前に確かめます。

3-2-1ルールとイミュータブルバックアップはどう関係しますか？

3-2-1ルールは、データを3つ持ち、2種類の媒体に置き、1つを別の場所に置くという配置の原則です。イミュータブルバックアップはその「1つ」を消せない状態にする手段にあたります。別の場所に置いた複製でも、本番と同じ権限で消せればランサムウェアには耐えられません。配置の原則に加え、消せない複製を1つ持つと考えると整理しやすくなります。