所有していないマシンのディスク暗号化

プライバシーを謳うホストはどこも、ディスクは暗号化されていると言います。それはたいてい事実であり、たいてい誰も尋ねていない問いに答えています。暗号化には気にすべき三つの状態があり、サーバーはその稼働期間のすべてを、フルディスク暗号化が対象としない状態で過ごします。実際の境界線がどこにあるのか、その両側に何があるのか、そして同じ四語で売られる二つの仕組みのうち、どちらが自分で鍵を持つ方なのか — それがこの記事の主題です。

三つの状態と、誰も暗号化しない一つ

データは三つの状態のいずれかにあるとされ、業界はそのうち二つをすでに解決しています。保存時とは、今どのプロセスも読み取っていないディスク上のデータであり、フルディスク暗号化と、その上に重ねるデータベースやオブジェクトストレージの暗号化によって解決済みです。転送中とは、ネットワークを移動中のデータであり、TLS によって解決済みです — 誤発行された証明書がニュースになるほど徹底的にです。使用中とは、稼働中のプロセスのメモリに読み込まれたデータであり、サーバーが配信するすべてのバイトは、どれほど短時間であれ、配信されるためにこの状態を通ります。

保存時の暗号化という表現は正確ですが、読み流してしまいやすいほど正確です。この表現が指しているのは、マシンが電源を切っている間のデータの状態です。サーバーとは、電源を切らないことこそが仕事のマシンです。稼働している何か月もの間、ボリュームは開かれたままであり、データベースファイルは正しいユーザーとして動くどのプロセスからも読み取り可能であり、暗号化は停電を待つ以外、何もしていません。

その四語が隠しているもう一つのことは、鍵を誰が持っているかです。同じ四語のもとで、まったく異なる二つの仕組みが売られています。プロバイダーが自ら管理する鍵でストレージ層を暗号化する場合、それはプロバイダー自身の廃棄プロセスを守り、プロバイダー自身の情報漏えいリスクを減らし、ドライブが建物の外に持ち出される事態からも確かに守ります — しかし鍵を持っているのは、まさに問われていた当事者自身です。あるいはボリュームは、自分自身のマシンの内部で暗号化することもでき、その鍵は自分の頭の中と、稼働中のカーネルのメモリの中にしか存在しません。第三者が入手できるものを変えるのは後者だけであり、本ガイドの以下の内容が指すのも後者だけです。

ここまでの話は、ディスクを暗号化することへの反論ではありません。以下の八つのシナリオのうち、どれをカバーしていてどれをカバーしていないかを知るべきだという主張です。一つの実在する脅威を防ぐ暗号化には価値があります。八つすべてを防いでいると思い込んでいる暗号化は、何もしていないより悪いものです。なぜなら、その思い込みが検討を終わらせてしまうからです。

マシンの稼働中、鍵はどこにあるのか

LUKS ボリュームのロックを解除するとき、入力するパスフレーズそのものは鍵ではありません。パスフレーズはボリュームヘッダーに保存されたマスターキーを復元するために使われ、そのマスターキーはボリュームが閉じられるかマシンの電源が失われるまで、カーネルメモリに保持され続けます。すべての読み取りとすべての書き込みがそこを経由します。ディスクが使用中である間、鍵がどこか別の場所にあるような、動作する暗号化ディスクの構成は存在しません — これは誰かが直せる実装上の細部ではなく、暗号化ディスクを使うということそのものの意味です。

自分が所有するハードウェアであれば、そのメモリは自分が管理する部屋の中の筐体に収まっており、それに対する攻撃は特殊なものに限られます — 物理的な立ち会いや、電源を切った後もメモリチップに数秒間残る残留データなどです。仮想サーバーでは、状況は程度の違いではなく種類の違いになります。自分のカーネルのメモリは、ホストのメモリの一領域です。ハイパーバイザーはそれを定義上アドレス指定できます。なぜなら、そもそもアドレス指定することによってハイパーバイザーがそれを自分に与えたからです。まったくありふれた三つの操作が、それを読み取ります。

• ライブマイグレーション。稼働中の仮想マシンを物理ホスト間で移動させる際には、動作したままメモリがコピーされます。これは機能であり — 再起動せずにホストをメンテナンスする方法です — コピーされるページの中に、自分のマスターキーも含まれています。
• メモリを含むスナップショット。自分で暗号化したボリュームのディスクのみのスナップショットには、暗号文以外は何も含まれません。マシンをまさに元あった状態で再開できるスナップショットには、鍵も含まれます。「元あった状態」を構成する一部が鍵そのものだからです。
• メモリダンプ。ゲストのメモリは、ホスト上のプロセスのアドレス空間の中に存在します。そのプロセスのメモリを読み取ることは日常的なデバッグ操作であり、そのためのツールは持ち込む必要すらなく、仮想化スタックに標準で付属しています。

以上のいずれも、プロバイダーが実際にそれを行っていると主張するものではありません。主張しているのは、これらの操作が自分側の協力を一切必要とせず、自分に見える範囲に痕跡を残さず、通常のプラットフォームのメンテナンスと見分けがつかないということです。脅威モデルに書き込む価値があるのはその一点だけです。誰かが何をしているかではなく、気づかれずに何をできるかです。もう一段外側でも同じ論理が成り立つからこそ、目の前のレジストリやプロキシも、ホストと同じ一覧に載せるべきなのです。

再起動の問題と、それを台無しにする近道

暗号化された root ボリュームは、システムが SSH 接続を受け付けられるところまで起動する前に、ロックを解除しなければなりません。ノート PC であればキーボードでパスフレーズを入力すれば済みます。二千キロメートル離れた、足を踏み入れたこともない建物にあるマシンでは、必要な瞬間に手の届くキーボードはありません。この問題への実際的な答えはどれもトレードオフです — ただし以下の四つのうち一つだけは、トレードオフですらなく、トレードオフをしたように見せかける方法にすぎません。

リモートマシンで暗号化された root ボリュームを解除する四つの方法

方法	無人再起動	盗まれたディスクを防げるか	代償
起動イメージへの SSH 接続	いいえ	はい	initramfs 内の最小限の SSH サーバーに接続し、パスフレーズを入力できます。マシンは、人が起きていて連絡が取れる状態になるまで停止したままです。これは誠実な選択肢であり、代償も現実のものです。午前四時の再起動は、誰かが気づくまで障害であり続けます。
ネットワーク経由の鍵	はい	一部	マシンは起動時に、自分が別の場所で運用するサーバーから解除鍵を取得します。移動したマシンや、自分が再起動していないマシンには鍵の提供を拒否できます。鍵サーバーは稼働し続けなければならず、しかも同じ命令が届かない場所に置く必要があります — そうでなければ、一つの錠に対して鍵を二つの扉に分けただけになってしまいます。
起動イメージ内の鍵ファイル	はい	いいえ	鍵は initramfs の中にあります。initramfs は暗号化されていない起動パーティションの中にあり、その起動パーティションは、まさに守ろうとしていたディスクの中にあります。ディスクを持ち去る者は、鍵も一緒に持ち去ります。この構成はよくあるもので、問題なく起動しますが、何一つ守っていません。
TPM への封印	はい	一部	自分が所有するハードウェアであれば、実物のセキュリティチップは、改ざんされていない起動チェーンに対してのみ鍵を渡します。仮想サーバーでは、そのチップはホストによってエミュレートされているため、そこに鍵を封印することは、まさにその相手から鍵を遠ざけようとしていた当人に、鍵を渡すことになります。

三番目の行はじっくり見る価値があります。これは、要件がディスクは暗号化されていなければならないとだけ書かれ、何のためかを誰も問わなかった場合に行き着く先です。監査は通ります。ブロックデバイスは確かに暗号化されています。しかし鍵は同じ金属の上に乗ったまま、リカバリーシェルが四秒ほどで読み取れるファイルの中に置かれています。

これは、借りた仮想マシンと自分自身のマシンとの、最も分かりやすい実務上の違いでもあります。専用サーバーであれば、帯域外管理インターフェースが再起動を生き延びるコンソールを提供するため、一行目は障害ではなく二分間の中断で済みます — そして四行目のエミュレートされたチップの問題も消えます。チップは、守ろうとしている相手がソフトウェアで書いたものではなく、基板にはんだ付けされているからです。

フルディスク暗号化が実際に買っているもの

同じ問いを、八通りの形で尋ねます。重要なのは最後の列です。暗号化が役に立たないどの行にも、代わりに役立つ何かがあるからです — その何かに名前を付けることこそが、この作業のすべての価値です。

八つのシナリオと、フルディスク暗号化が結果を変えるかどうか

シナリオ	暗号化は役立つか	実際に結果を左右するもの
ドライブが廃棄・転売、または保証で返却される	はい	これをカバーできるものは他にありません。ドライブは常にデータセンターの外に出ていきますし、消去作業はあくまでプロセスであり、プロセスは静かに失敗するものです。これはフルディスク暗号化が発明された、まさにそのシナリオであり、これに対しては謳い文句どおりに機能します。
マシンの電源が切られ、ディスクが取り外される	はい	同じ保護が、同じ境界線とともに働きます。その境界線とは電源オフという言葉そのものです。稼働中に持ち去られたマシンは、ロックが解除されたまま、ボリュームが開いたまま、鍵が存在したまま持ち去られたマシンです。
バックアップのコピーがどこか別の場所にある	一部	元のボリュームの暗号化は、データのコピーには何の効果もありません。決め手となるのは、バックアップが送り出される前に、バックアップ対象のマシン上には保存されない鍵で暗号化されていたかどうかです。
プラットフォームがスナップショットを取得する	一部	自分で暗号化したボリュームのディスクのみのスナップショットは暗号文であり、パスフレーズを持たない者には無価値です。メモリの状態を含めて取得するスナップショットは、鍵も一緒に取得してしまいます。どちらも「スナップショット」と呼ばれます。
稼働中のマシンでシェルを取得される	いいえ	ボリュームはすでに開かれており、侵入者はブロックではなくファイルを読み取ります。この行を左右するのはパッチ適用、最小権限、そしてサービス間で使い回さない認証情報であり、暗号化はここに何も貢献しません。
ホスト運営者、またはホスト運営者のアクセス権を持つ者	いいえ	鍵が一切マシンに入らない暗号化だけが効きます。ハードウェアによるメモリ暗号化が唯一の例外ですが、どこでも標準では無効になっており、これは次の節で扱います。
プロバイダーに命令が送達される	一部	誰が何を示せば尋ねられるかを決めるのは司法管轄であり、答えに何が含まれ得るかを決めるのは暗号化です。当社が公表している立場は二つの独立した文からなり、そのどちらも重要です。当社はお客様の暗号鍵を保持しておらず、提出することもできません。そして仮想サーバー上の暗号化されていないボリュームであっても、そのサービスを名指しした命令が必要であることに変わりはありません。
侵害を開示しなければならない	一部	利用者が EU にいる場合、GDPR 第 32 条は暗号化を、求められる対策の一つとして名指ししています。そして第 34 条は、データが判読不能な形にされていた場合、本人への通知義務を免除します — 監督機関への通知義務が免除されることは決してありません。これが当てはまるかどうかは、データが流出した時点で鍵がどこにあったかだけで決まります。

ディスクの上位層：敵対的なホストに何が残るか

ここまでの話はすべて、ブロックデバイスで止まる層に関するものです。その上には三つのものがあり、それらを合わせたものが、先ほどの表の五行目・六行目・七行目に対する唯一の答えになります。

アプリケーションの下ではなく、上で暗号化する

フィールドレベルの暗号化とは、値がデータベースに届く前にアプリケーションが暗号化し、読み出した後に復号することを意味します。データベースのダンプを取得すれば、誰がどんな経路で取得しようと、得られるのは暗号文です。代わりに、暗号化した列を検索したりインデックスを張ったりする能力を失うため、これはメッセージ本文やアップロードされた文書、サードパーティのトークンなど、それに値する少数のフィールドに限って行うべきで、すべてに適用するものではありません。この延長線上にあるのがエンドツーエンドです。鍵は利用者本人のものであり、サーバーは平文を一切保持せず、敵対的なホストは何も得られません。そこに得るべきものが何もないからです。これはこのページで唯一、誰が物理的なマシンを運用しているかに本当の意味で左右されないアーキテクチャであり、インフラの決定である以前に、プロダクトの決定です。

バックアップは結果ではなく独立した決定

暗号化されたマシンからデータが出ていく、最もよくある経路はバックアップです。オブジェクトストレージに送られるスナップショット、別のプロバイダーに同期されるデータベースダンプ、ワークステーションに引き出されるアーカイブ — そのいずれも、元のボリュームから何かを引き継ぐことはありません。データがバックアップに書き込まれる瞬間に、マシン自身が到達できない場所に保管された鍵で暗号化してください。そうすれば、侵害されたサーバーが自分自身の履歴を復号することはできなくなります。そのうえで、必要になる前に、別のマシンへ一度復元しておいてください。開けない暗号化バックアップは、すべてを一度に失う、驚くほど整った方法です。別の国にあるコピーは、別の規則の下にあるコピーでもあり、それは気づかないうちに選んでしまった第二の司法管轄です。

メモリ暗号化と、おそらく自分が持っていない理由

誰も暗号化しない状態にも、ハードウェアによる答えは存在します。コンフィデンシャルコンピューティング拡張機能 — AMD の SEV-SNP や Intel の TDX — は、ゲストのメモリとレジスタ状態を、ハイパーバイザーではなく独立したセキュリティプロセッサが保持する鍵で暗号化するため、メモリをダンプしたホストが得るのは暗号文です。これは実在し、実際に提供されています。ただし対象は狭く、SEV-SNP には第 3 世代以降の EPYC シリコンが必要で、ホスト側も意図的にこれ向けに構成しなければならず、ゲスト側もそれを得たことをアテステーションで証明する必要があります。汎用の仮想サーバーでこれを提供しているものはほとんどなく、また黙って提供しているものは一つもありません。プロバイダーが書面でそう明言し、アテステーションを自分で検証する方法を教えてくれない限り、自分には備わっていないと考えてください。

自らの限界に正直な構成

ここまでの話は、やっても無駄だという結論には至りません。行き着く先は、その限界を臆せず言葉にできる構成です。

1. 自分が守ろうとしている、たった一つのシナリオを書き出す（5 分）。廃棄されたドライブ、稼働中に押収されたマシン、敵対的なホスト、裁判所命令、開示しなければならない侵害。これらには異なる答えがあり、五つすべてを狙った構成は、まず間違いなくどれも達成できません。
2. 自分の鍵がある場所に暗号化を置く（決定）。プロバイダーが鍵を持っているなら、買っているのはドライブが建物の外に出る事態への保護だけであり、それ以上ではありません。それ以上を望むなら、ボリュームはゲストの内部で、自分自身が、プラットフォームには決して見えないもので解除しなければなりません。
3. root ではなくデータボリュームを暗号化する（設定）。root を暗号化すると、再起動のたびに自分を待つことになります。データベースディレクトリやアップロード、機密情報を収めた別の暗号化ボリュームを用意すれば、機微な部分は開けるまで閉じたまま、マシン自体は自力で復帰できます。これは、ほとんどの小規模プラットフォームが選ぶべき妥協点でありながら、ほとんど誰も書き留めていません。
4. 暗号化されていない起動パーティションに鍵ファイルを残さない（原則）。鍵サーバーもコンソールもなくマシンが無人で起動するなら、鍵はディスクの上にあります。第三の可能性はありません。盗まれたドライブこそが自分の脅威モデルのすべてであるなら、それは十分に理にかなったトレードオフですが、それ以外のあらゆる場合には自己欺瞞にすぎません。
5. バックアップは書き込まれる時点で、別の場所に保管された鍵で暗号化する（設定）。そのうえで、何も燃えていない日に、別のマシンへ一度復元してみてください。
6. 自分がカバーした範囲を、一文で言い切る（5 分）。たとえばこう言えるはずです。このディスクをラックから引き抜いた攻撃者は何も得られないが、稼働中のマシンやそのホストで root を得た者はすべてを得る、と。この一文を書くのが気まずいなら、それは真実だからです。

六つのうち二つは決定であり、四つは設定です。決定には半日かかり、設定には一時間かかりますが、半日なしの一時間には何の価値もありません。順序を逆にすると、監査は通っても誰からも守ってくれないマシンという、最初の表の三番目の行に行き着くことになります。

自分がどのシナリオを守ろうとしているかは、暗号化の問いである前に脅威モデリングの問いであり、1 時間でできる版のその演習を行えば、ほとんど副産物のようにステップ六の一文が得られます。答えがドライブではなく裁判所命令だった場合、結果を左右する層はディスクの上にはまったくなく、どの国の法律がプロバイダーに届くかという話になります。それを信頼する前にどう確認するかも参照してください。

このプラットフォームを運用するエンジニアが執筆し、本日 に見直しました。内容に誤りがある、または古くなっている場合は、顧客パネルからお知らせください。実際、ここに載っている内容の半分ほどはそこから届いたものです。