外部からの侵入やランサムウェア被害は、いまや「感染させる」だけで終わりません。攻撃者はバックアップやスナップショットまで狙い、データを削除・改ざんして「復旧手段を奪う」ことがあります。

こうした背景から注目されているのが、一定期間、運用者や管理者でもデータを変更・削除しにくくする仕組みである「イミュータブル（Immutable）」です。

ただし、イミュータブルは侵入や感染を防ぐものではなく、復旧性を高めるための仕組みです。運用設計が不十分だと効果が出ないだけでなく、保持期間や権限設定のミスにより復旧不能などのトラブルにつながることもあります。

この記事では、イミュータブルの基本と「効く条件・効かない条件」、導入前に決めるべき運用設計のポイントを整理します。

この記事を読むとわかること

• イミュータブルが守れるものと守れないもの
• ランサムウェア対策における効く条件・効かない条件
• 導入前に決めるべきこと（保持期間・権限・削除フロー・復旧）
• 既存環境でも進めやすい段階導入の考え方

イミュータブルとは？「一定期間、変更・削除できない」状態

イミュータブルは直訳すると「不変」。IT領域では、主に一定期間、データの変更・削除をできない状態に固定する仕組みを指します。

ポイントは、イミュータブルが「暗号化」や「侵入防止」のように攻撃を止める機能ではないことです。
イミュータブルは、被害が起きても復旧できる可能性を高めるための仕組みです。

ランサムウェアの「バックアップ破壊」対策

ランサムウェア対策というと「侵入を防ぐ」イメージが強いかもしれません。ですが現実には、侵入後に権限を奪われ、社内の共有領域やバックアップ基盤が操作されるケースがあります。

攻撃者の狙いは明確で、復旧手段（バックアップ）を消せば、身代金交渉で優位に立てるからです。

イミュータブルは復旧手段を守る観点で有効になります。バックアップや重要データが「変更・削除できない状態」で残っていれば、被害を受けても復旧のカードが残ります。
言い換えると、イミュータブルは「最後の砦」を成立させるための要素です。

イミュータブルが効く条件

イミュータブルが効果を発揮するのは、設計と運用の両方が揃っているときです。
たとえば「保持期間を決めて設定した」「対象データを保護した」だけでは不十分で、権限分離や監査、復旧訓練まで含めて初めて復旧手段として機能します。

ここでは、情シス・セキュリティ担当が押さえるべき条件を「設計」と「運用」に分けて整理します。

設計の条件

守りたいデータが対象に入っている

バックアップ対象から漏れているデータは守れません。優先順位を決めて“守る範囲”を明確にします。

保持期間が復旧目標（RPO/RTO）に合っている

発見が遅れた場合でも戻せるように、必要な日数・世代を確保します。

権限が分離されている

バックアップの削除・解除などの強い操作が、単独の管理者で完結しない設計が重要です。

運用の条件

監査・ログが取れている

いつ、誰が、何をしたかが追える状態にします。

復旧手順が現実的で、定期的に復元テスト（リストア演習）をしている

バックアップ（復元点）が残っていても、必ずしもすぐに復旧できるとは限りません。リストア手順と所要時間を確認し、実際に復元できる状態かを定期的にテストします。

効かない条件：イミュータブルだけでは不足するケース

イミュータブルにも限界があります。イミュータブルの限界を誤解すると、導入してもバックアップ（復元点）を守れず、復旧に使えない状態になります。

侵入・感染そのものは防げない

イミュータブルは「データ保全」であり、侵入を防ぐ入口対策（認証、脆弱性対策、EDR等）とは役割が違います。

情報窃取（漏えい）は止められない

攻撃者が先にデータを持ち出した場合、改ざん不可でも漏えいリスクは残ります。アクセス制御や監視など、別レイヤーの対策が必要です。

権限設計が甘いと「イミュータブルのロック（保持）を解除される」

削除・解除ができる管理者権限が同一人物・同一アカウントに集中していると、ロック解除やバックアップ削除が可能になり、復旧手段が失われます。

保持期間が短い・保護対象が不足している

イミュータブルでも、必要な世代（感染前に戻すためのバックアップ・復元ポイント）が残っていなければ復旧できません。守る対象と保持日数の見直しが必要です。

運用ルールがないと事故が起きる

解除フローが不明確だと、復旧点を失ったり、保持を誤って逼迫したりします。

導入前に決めること（チェックリスト）

イミュータブルは、技術よりも先に運用設計を詰めると失敗しにくくなります。最低限、以下の項目を決めてから進めるのがおすすめです。

チェック項目	補足
何を守るか（対象と優先順位）	重要データ、基幹システム、共有領域、メール、ログなど、守る対象を棚卸しします。
保持期間（何日・何世代）	発見までの遅れ、監査要件、業務復旧の目標に合わせて決めます。
削除・解除の権限と承認フロー	「誰が解除できるか」が最重要です。多段承認や別管理者など、分離を前提にします。
復旧手順と訓練	どこから戻すか、どの順番で戻すか、どれくらいで戻るかを「机上」ではなく現場で確認します。
監査・証跡（ログ／アラート）	解除操作や権限変更を検知できる状態にし、異常の早期発見につなげます。

よくある質問

イミュータブルは注目度が高い一方で、用語や使い分けが分かりにくく、誤解されやすいポイントもあります。
そこでこちらでは、情シス・セキュリティ担当からよくある質問を3つに絞って整理します。

イミュータブルとスナップショット（またはWORM）の違いは？

• スナップショットは「復旧を速くするための保存点」
• イミュータブル（WORM）は「一定期間、削除・改ざんされない状態を作り、復旧手段を守る仕組み」

スナップショットは「ある時点の状態を保存する」仕組みで、復旧を速くできる利点があります。一方、運用や権限設計によっては、バックアップ基盤の管理権限を奪われた場合に削除されるリスクが残ることがあります。

イミュータブルは一定期間の変更・削除を制限し、バックアップ破壊への耐性を高めます。現場では、スナップショットで復旧を速くしつつ、イミュータブルで復旧手段を守る形で併用するのが一般的です。

保持期間は何日が正解？

保持期間に「唯一の正解」はありません。基本は、業務に必要な復旧ラインから逆算して決めます。
保持期間を決める目安は次の通りです。

1. 侵害に気づくまでの期間（発見の遅れ）
2. 復旧目標（RPO/RTO）
3. 監査・業務要件

最悪なのは、保持が短すぎて「被害前に戻すための復元ポイント」が残らないことです。まずは「発見が遅れた場合」を想定して保持期間を決め、段階導入の中で実運用に合わせて調整すると現実的です。

既存環境でも後付けできる？

既存環境でも後付けできるケースは多いです。
最初から全社一括を狙うより、以下の順に、段階的に適用範囲を広げる方が運用事故を抑えられます。

1. 重要データ
2. 影響範囲が大きい領域（例：共有ファイルや基幹データ）
3. 全体

特に保持期間・権限・解除フローは、まず限定した範囲で運用し、問題がないことを確認してから固めるのが安全です。

これからの時代に必要な「復旧手段の強化」

イミュータブルは、侵入や感染を防ぐ対策ではありません。被害が起きたときに「復旧できる状態」を守るための仕組みです。
だからこそ、守る対象・保持期間・権限設計・復旧手順といった運用設計とセットで整備することが重要になります。

株式会社サイバーウェイブジャパンの導入機器でも、現段階で一部イミュータブルに対応しており（新規導入サーバは対応）、今後は運用状況や要件に合わせて対象範囲を広げていく予定です。現状のバックアップ運用を踏まえた進め方の整理からご相談いただけますので、お気軽にお問い合わせください。

この記事のポイント

• 1.イミュータブルとは？

  イミュータブルは、一定期間データを変更・削除できない状態にし、被害が起きても復旧できる可能性を高めるための仕組みです。

  社用スマホは「業務遂行」のために利用し、業務に無関係なサイトの閲覧を避けることが重要です。
  詳しくは「イミュータブルとは？「一定期間、変更・削除できない」状態」をご覧ください。

• 2.イミュータブルは万能？有効な条件は？

  イミュータブルは「一定期間、変更・削除できない状態にする」仕組みですが、万能ではありません。イミュータブルが効く・効かない条件は以下の通りです。

  • 効く条件：対象・保持期間・権限分離が設計され、ログと復旧訓練が運用されている
  • 効かない条件：侵入防止ではない、情報窃取は別対策が必要、権限や保持の設計ミスがある

  詳しくは「イミュータブルが効く条件」をご覧ください。

• 3.導入前に決めることは何？

  イミュータブル導入前に決めるべきことは以下の通りです。

  • 守る対象と優先順位
  • 保持期間（何日・何世代）
  • 削除・解除の権限と承認フロー
  • 復旧手順と訓練
  • 監査・証跡（ログ／アラート）

  詳しくは「導入前に決めること（チェックリスト）」をご覧ください。

株式会社サイバーウェイブジャパンでは、社内外で利用できる高度なセキュリティシステムを備えたクラウドメールをご用意しています。お気軽にご相談ください。

お問い合わせはこちら