4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

イミュータブル:「改ざんできない」を腹落ちするまで言語化する

4
Last updated at Posted at 2026-09-02

バックアップの話をしていると「うちはイミュータブルで取っているから大丈夫!」と言われることがあります。

イミュータブル

このかっこいい横文字だけ聞くと、「おぉ、、、なんか強そう」と雰囲気だけで堅牢な対策をしている印象を受けます。

イミュータブル(immutable)という英語を直訳すると「変更不可、不変」です。

では、ここで質問です。
あなたは、この「イミュータブルなバックアップ」は「何が変更不可・不変」なのか、具体的に説明できますか?

今回は、「うちはイミュータブルで取っているから大丈夫!」という言葉に厚みを持たせるために、用語の整理から実際の仕組みまで具体的に落とし込んで見ていきたいと思います。

「改ざんできない」には、いくつかの意味がある

「バックアップは改ざんできないようにしています」と聞くと、データがまるっと絶対に安全な金庫に入っているように思えますが、

実際には、どの仕組みを指しているかで、守っていることが違います。

たとえば、コンサートのチケットを考えてみましょう。

チケットの内容を他人に読ませないための封筒、
内容が書き換わっていないと確認するための整理番号、
発行元を証明するためのサイン、
そして、公演日まで捨てられない保管箱。

それぞれ役割が違いますよね。データでも同じです。

仕組み 主に守ること 一言でいうと
暗号化 内容を読まれにくくする 中身を読めなくする
ハッシュ 保存後に内容が変わったことを確かめる 変わったことを見つける
電子署名 発行者と、保存後の変更を確かめる 誰が出したかを確かめる
権限管理 操作を頼める人を絞る 操作の受付を分ける
イミュータブル 保存済みデータの変更・削除を制限する 消す・上書きする要求を断る

この中で、イミュータブルは「データを読めなくする鍵」そのものではありません。

多くの場合は、保存先が「このバックアップは○月○日まで変更・削除を受け付けない」と判断する仕組みのことを「イミュータブル」と表現します。

何が起きると、変更できないの?

イミュータブルなバックアップでは、保存するときに保持期間を決めます。

たとえば毎晩のバックアップを14日間保護するなら、月曜日に保存したバックアップには「14日間は処分禁止」というルールが付きます。

そのルールが有効化された後は、誰かが削除や上書きを依頼しても、保存先はまず保持期間を確認し、まだ14日が過ぎていなければ、その操作を拒否します。

ここが「改ざんされにくい」を実現する中心です。

製品ごとの実装は異なりますが、考え方は次のように一般化できます。

  1. バックアップやスナップショットを保存する。
  2. 保存先に、保持期限と変更・削除を制限するルールを記録する。
  3. 上書き・削除の依頼が来るたび、保存先がそのルールを確認する。
  4. 保持期間中なら操作を拒否し、期限後は設定したライフサイクルに従う。

この状態で、利用者から見える動きは、次のようになります。

操作 保持期間中にどうなるか
バックアップを読む・復元する 通常は許可する。読めないと復旧に使えないため
新しいバックアップを追加する 通常は許可する。古い世代を残したまま新しい世代を増やせる
保存済みバックアップを上書きする 拒否する、または新しい世代として保存する
保存済みバックアップを削除する 拒否する
保持期間を短くする・ルールを消す 製品とロック状態による。強い構成では拒否する

ここで見るべきなのは、どこが操作を拒否するかです。

バックアップ製品の画面だけが削除を止めていても、保存先へ直接アクセスできる人が削除できれば、別の入口から回り込めてしまいます。

そこで、もう一段階、保護を強める構成では、実際にデータを保存しているストレージ側が保持ルールを判定し、バックアップ製品以外から来た削除・上書き要求にも同じように応答するような仕掛けにします。

そして、それよりさらに強い保護が必要な構成では、保持期間を短くしたり保護ルール自体を消したりする操作もロックします。

ここまで設定して初めて、「バックアップを消す」だけでなく「消せるように設定を変える」操作にも壁を作れるのです。

鍵を使う仕組みと、使わない仕組み

「改ざんされにくい」と言っても、仕組みごとに担当が違います。

暗号化は、バックアップの中身を読める人を絞るための仕組みです。
正しい鍵がなければ、保存されたデータを読めません。

ハッシュは、データの指紋のようなものです。
バックアップを保存したときにハッシュ値を残し、あとで同じデータから計算した値と比べます。ファイルの中身が変われば、通常は指紋も変わるため、変更に気付けます。NIST: Secure Hash Standard (FIPS 180-4)

ただし、ハッシュだけでは「誰がその指紋を作ったか」までは分かりません。
バックアップ本体とハッシュ値を同じ場所に置いていると、書き換えた人が両方を差し替えられる可能性があります。ミステリー小説でいう証拠捏造です。

そこで使うのが電子署名になります。
作成者が秘密鍵で署名し、受け取る側は対応する公開鍵で確認します。秘密鍵を持たない人は、新しいデータに対して正しい署名を作れません。そのため電子署名では、誰が署名したかと、署名後に内容が変わっていないかを確かめられます。NIST: Digital Signature Standard (FIPS 186-5)

一方、イミュータブルは、保存先が削除や上書きの依頼を受け付けない仕組みです。
変更されたことを後から見つけるのではなく、変更そのものを起こりにくくします。

つまり、

データそのものを改ざんされにくくするには、二つの考え方を組み合わせます。

イミュータブルや権限管理で変えさせない

ハッシュや電子署名で変わっていないことを確かめる

暗号化は、そこに読ませない保護を加える仕組みという位置付けになります。

何をイミュータブルにするの?

「イミュータブル」にする対象は、バックアップファイルだけとは限りません。

たとえば次のようなものがあります。

  • データベースのバックアップ
  • データベースのスナップショット
  • OSや仮想マシンのスナップショット
  • アプリケーションの設定ファイル、デプロイ用のファイル

ここで混ぜないほうがよい言葉が、スナップショットイミュータブルです。

スナップショットは「ある時点の状態を切り取ったもの」、
イミュータブルは「切り取ったものを、保持期間中に変更・削除しにくくするルール」です。

前者はどの時点を残すか、後者は残したものをどう守るかを決めます。
スナップショットを取っただけで、消されにくくなるわけではありません。

特にデータベースは厄介です。

データベースは、データを一つのファイルだけで管理しているわけではなく、複数のデータやログを同時に更新しています。

そのため、OSや仮想マシンと同じ感覚で、好きなタイミングにスナップショットを取得すれば、データベースとして正しく戻せるとは言い切れません。

データベースを守るときは、製品が案内するバックアップ/リカバリ方法を使い、そのバックアップや必要なスナップショットをどこまで保護するかを決めましょう。

また、ここでもう一つ重要なのは、イミュータブルが守れるのは保存した後だということです。

壊れたデータや、ランサムウェアなどで暗号化されて利用できなくなったデータをバックアップしてから「イミュータブル!」と保護しても、その内容は変わりません。壊れているものは壊れたまま保存されるのです。

だからデータを正常な状態で複数の世代を残し、いつ正常だったかを見つけ、実際に復元する、という一連の流れを別で考える必要があります。

まとめると、

イミュータブルは「きれいな復旧ポイントを作る」仕組みではなく、「作れた復旧ポイントを残す」仕組みです。

つまり、

復旧できるかは、正常な世代が残っていること、必要な鍵や設定がそろうこと、復元手順を検証していることまで含めて決まります。

「うちは大丈夫」と言う前に、考えて欲しいこと

イミュータブルという言葉を聞いたら、次の5つを想像してみてください。
製品名を知らなくても聞ける質問です。

  1. 何を保護している?
    DBバックアップ、OSスナップショット、設定ファイルなど、復旧に必要なものをちゃんと保護できているか?

  2. どこが削除を断る?
    イミュータブルは削除変更をお断りする仕組みです。その操作はどのレベルでお断りされていますか?

  3. いつまで守られる?
    何日、何週間、何か月前まで戻れるようにしている?
    障害に気付くまでの時間より、保持期間が短いと、正常だった時点のコピーが残らないことがあります。

  4. 誰がルールを変えられる?
    バックアップを作る人、保管場所を管理する人、保持ルールを変える人をどう分けている?
    一つの強いアカウントで、データと保護ルールの両方を消せる構成になっているかもしれません。

  5. 本当に戻せる?
    バックアップは保存できていても、復元に必要な設定、暗号鍵、アプリケーションの情報がそろわなければ、利用者は仕事を再開できません。

「強そう」を説明できる言葉に変えてみよう

イミュータブルは、なんでも守ってくれる魔法の金庫ではありません。保存先が、保持期間中の削除や上書きを拒否する、データ保護の仕組みの一部です

ここで、役割を混ぜずに考えてみましょう。
先ほど整理したように、OSスナップショットは取得時点のOSやVMの状態を残し、イミュータブルはそのスナップショットを保護期間中に消したり変更したりしにくくします。そして暗号化は中身を読める人を絞り、復元テストは本当に戻せるかを確かめます。

このようにそれぞれの仕事を分けて考えると、「うちはイミュータブルだから大丈夫」という言葉を、次のように具体的に説明できるのではないでしょうか。

私たちは、復旧に使うOSスナップショットを14日間保護しています。
保護期間中に削除が試みられても、保存先がその操作を拒否します。
また、保持期間を短くしたり保護ルールを外したりする権限は、バックアップ担当者とは分けています。

暗号化を使う場合は復元用の鍵も残し、隔離した環境で実際に復元できることを定期的に確かめています。

そのため、私たちはイミュータブルで取っているから大丈夫です。

ここまで説明できれば、「私たちはイミュータブルで取っているから大丈夫!」は横文字の強そうな印象ではなく、どう守り、どう復旧するかまで解像度を上げて理解できている人の言葉になるのではないでしょうか。

参考資料

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?