バックアップがイミュータブル(Immutable)でなければならない理由

イミュータブル（immutable: 不変性）という言葉をよく見かけるようになりました。イミュータブルというカタカナ表記が一般化していますが、変更不可とか不変的という訳語も見かけます。前回のブログで言及しましたが、ランサムウェアが本番環境だけでなく、バックアップにも狙いを定めるようになってから特にイミュータブルなバックアップの重要性が注目されるようになりました。

ランサムウェア対策ソリューションのベンダーの中には、「100%イミュータブル」を謳うサービスも存在します。ランサムウェアがバックアップを暗号化して、それを解く鍵の代わりに身代金を要求する犯罪であること、その防止策の一環として、バックアップをイミュータブルなメディア（WORMストレージなど）に保存すべきとことは、前回のブログに書いたとおりです。

しかし、そのようなバックアップを「100%イミュータブル」と言えるかどうかについては、いささか疑問が残ります。

なぜなら、2つ問題があります。

1. 対ランサムウェア限定のイミュータブルは100%イミュータブルではない。
2. この世に100%イミュータブルなど存在しない。

2のほうが根本的な問題なので、まず2から先に説明します。

この世に100%イミュータブルなど存在しない

そもそもイミュータブルかイミュータブルでないか（immutable or mutable）は、表か裏、白か黒のように、二極化された属性です。バックアップがイミュータブルであれば、そのバックアップは誰も一切の変更や削除ができません。システム管理者は削除できるけど一般ユーザーは削除できない、というのはイミュータブルではありません。バックアップがイミュータブルであることの意義は、たとえば、万が一システム管理者が産業スパイであっても、そのバックアップは安全であると言い切れることにあります。

ユーザーの権限に応じた編集機能を備えながら、100%イミュータブルを謳うシステムも存在しますが、厳密には、イミュータブルの意図からずれていると言わざるを得ません。

しかし残念ながら、この世の誰もが手出しできない鉄壁バックアップであっても、イミュータブルの名のとおりに「永久不変」というわけにはいきません。

WORM （write once, read many） ストレージに誰かが火をつければ、それはイミュータブルではなくなるし、WORMディスクに雷が落ちてもダメです。いや、そんな特別な出来事ではなく、WORM DVDをクルマのダッシュボードに置きっ放しにして熱で曲がっても、はいイミュータブル終了―！です。

本来、終了しないはずのイミュータブルがこんな些細なことで終了してしまうなんて・・・ 諸行無常の鐘の響きが聞こえてきそうです。

そう、永遠に終わらないものなんて、実際には、この世に1つもないのです。ここで、しばし黙祷！

結局、イミュータブルとは、本来は「永久不変」を指すはずですが、現実的には、どのくらいイミュータブルかの度合の問題になってしまいます。100%イミュータブルはありえないけれど、95％ぐらいは可能かもしれません。

バックアップなら、隕石のディープインパクトから逃れるための米軍の秘密地下シェルターの中で耐火金庫に保管されたWORMストレージは99％イミュータブルに近いかもしれません。

昔々、パソコンデータをカセットテープに保存する方法がありましたが、あのカセットテープのツメはミュータブルをイミュータブルに変える装置なので、忘れずにツメを折っておけば、0.1%イミュータブルぐらいでしょうか。

もちらん、折ったツメの上からセロテープを貼れば、再びミュータブルですが、現代人はそれを知らないので、今なら微増の0.3％イミュータブルかもしれません。

しかし、前述のダッシュボードに置きっ放しのDVDではないですが、カセットテープなんて、何もしなくても長年放っておけば自然に劣化してイミュータブルではなくなります。

対ランサムウェア限定のイミュータブルは100%イミュータブルではない

もうお気付きかもしれませんが、イミュータブルなものをイミュータブルでなくさせる要因はこの世に溢れています。これまで挙げただけでも、放火あるいは火事、落雷、直射日光、経年劣化、カセットテープのツメを塞ぐセロテープなどなど、枚挙に暇がありません。

ストレージに保存されたバックアップでも、ランサムウェアに暗号化されてしまう場合もあれば、誰かがミスで（あるいは悪意を持って）削除または変更してしまう場合もあります。

あるいは、昔のカセットテープではなく、現代のハードディスクだって、磁気記録が弱まって読み取れなくなる経年劣化（bit rot）がないわけではありません。

100%イミュータブルを謳うバックアップシステムのユーザーインターフェースにも、権限のあるユーザーがバックアップファイルを期限切れに指定する機能があったりします。これは、業務上、システムの重要度が低下したなどの理由で、元々設定されたリテンション期間を早めるための機能です。この機能だって、それこそ産業スパイのシステム管理者が悪用したり、おっちょこちょいのシステム管理者が誤用したりする可能性があります。

つまり、堅牢に設計されたバックアップシステムでさえ、たとえあらゆるランサムウェア対策を講じていたとしても、100%イミュータブルではないのです。

裏を返せば、バックアップを強化するには、ランサムウェア対策はもちろんのこと、上記のようなイミュータブルの邪魔をするあらゆる事象を考慮しなければなりません。それこそが、真のイミュータブルを目指すことであり、すべてのバックアップはそれを目指さなければならないのです。

関連トピックス

• Veeam ONE V12で強化されたイミュータビリティ・モニタリング
• ExaGrid Ver7のリリース：「ダブルロック」セキュリティのためのS3オブジェクトロックのサポートを含む最新アップデート
• CloudBerry Backupを使用してのブータブルなISOイメージ作成方法
• ランサムウェア対策としてWasabi Cloud Storage を利用したCloudBerry Backup とのイミュータブル設定方法
• Veeam Backup & ReplicationのSNMPトラップによるジョブ完了通知
• Veeam ONEのアラーム、監視情報をSNMPにより通知
• Immutable(書き換え不能)レポジトリーバックアップによるランサムウェア対策
• イミュータブル（Immutable）を使用してAWSをランサムウェアから保護する2つの方法：N2WS
• Zerto 9.0: LTR(Long-Term Retention)のAmazon S3との新たな強化
• ブータブルファイルを使用したイメージベースバックアップからの復旧 : Cloud Berry Backup