VPSディスクをLUKSで暗号化

暗号化は万能のプライバシー設定ではありません。それが答えるのはただ一つの問いです。鍵がなければこれらのブロックを読めるか？それ以外のこと――このサーバーを借りていることを誰が知っているか、通信があなたに帰属するかどうか、裁判所が何かを強制できるかどうか――は別の話です。

VPSにおいて、LUKSが有効に防ぐのは次のようなものです。

• 廃棄・故障したハードウェア。NVMeドライブは交換されます。故障したデバイスに対するセキュア消去は必ずしも可能とは限りません――コントローラーがコマンドを受け付けなくなるほど完全に壊れていることもあり、それでもラックからは運び出されます。
• オフラインのイメージ。サーバーの電源が切られている間にコピーされたボリューム――押収、移行、あるいは単なる操作ミスによるもの――は暗号文であり、暗号文のままです。
• 持ち出されるバックアップとスナップショット。マシンの外に出るものは、あなたの管理が及ばないブロック層から取得されたものであれば暗号化された状態で出ていき、それより上位のレイヤーから取得されたものであればクライアント側で暗号化すべきです。
• 残留ブロック。サーバーを破棄すると、背後にあるエクステントは最終的に再利用されます。暗号化は、残されたものをデータではなくノイズに変えます。

ただし、稼働中のマシンに対しては防御になりません。サーバーが稼働している間、マスターキーはカーネルメモリ上にあり、そのメモリをダンプできる者は誰でも、パスフレーズにかかわらずディスクを読み取れます。レンタルインフラにおいて、それはハイパーバイザーの運用者を意味します。私たちはこのことをプライバシー通知で述べていますし、ここでも繰り返します。どのプロバイダーのディスク暗号化機能も――私たちのものを含めて――これを変えることはできません。そうではないと主張するプロバイダーは、暗号技術ではなくマーケティングを語っています。

端末を開く前に、モデルを決めてください。手間のかかり方は大きく異なり、ほとんどの人には最初のモデルで十分です。

1. 暗号化されたデータボリューム。システムは通常どおり暗号化なしで起動し、maildir、データベース、アーカイブなど一つのディレクトリツリーだけがLUKSコンテナの中にあり、起動のたびに手動で開きます。作業時間は10分、レスキューモードも不要で、自分自身を締め出すリスクもありません。マシン全体ではなく一つのデータセットだけが重要なら、ここで止めて構いません。脆弱性をほとんど増やさずに、恩恵の大半を得られます。これは匿名メールサーバーのページで推奨しているパターンです。

2. リモート解除つきの暗号化ルートボリューム。/bootを除くすべてが暗号化され、起動のたびにinitramfsで停止し、SSHで接続してパスフレーズを入力するまで先に進みません。本ガイドの残りの部分が組み立てるのは、このモデルです。最初のセットアップに1時間、以降は再起動のたびにSSHコマンド一回のコストがかかりますが、ログ、パッケージキャッシュ、シェル履歴、スワップまでカバーされる唯一のモデルでもあります――誰も意図しないままデータが漏れがちな場所です。

3. 自分で管理する鍵サーバーに対して自動的に解除する暗号化ルート。モデル2と同じですが、Clevisが別の法域にあるマシン上のTangサーバーから解除に必要な情報を取得するため、再起動を無人で行えます。このトレードオフは正確に理解しておく価値があります。サーバーは鍵サーバーが応答を返す限り自分自身を復号できるようになり、これは秘密を取り除いたのではなく移動させただけだということを意味します――ただし、その代わりにリモートのキルスイッチを手に入れています。詳しくは後述します。

多くのホスティング事業者は「保管時暗号化」をチェックボックスの一項目として宣伝しています。しかし、その言葉が普段何を意味しているのかは正確に見ておく価値があります。まったく異なる二つのものがその裏に隠れているからです。

プロバイダーが鍵を保持する暗号化が守るのは、盗まれたドライブに対してだけです。プロバイダーが何も尋ねずにあなたのサーバーを起動できるなら、プロバイダーは何も尋ねずにあなたのサーバーを復号できます――そして、そのプロバイダーに開示を強制できる者もまた同様です。これは窃盗に対しては本物の防御ですが、法的手続きに対しては純粋に見せかけにすぎません。

あなた自身が鍵を保持する暗号化こそが意味のある方式であり、その構造上、無人での再起動を不可能にします。これは設計で取り除くべき欠陥ではなく、まさにその働きを担う性質そのものです。

私たちが提供するのは後者の選択肢だけです。設定は行わず、判断はあなたに委ねます。私たちが実際に保持しているものはより限定的で、かつ公開されています。サーバーのrootパスワードは行単位でAES-256-CBC暗号化されて保存され、フローログやパケットキャプチャは保持せず、署名付きのワラントカナリアを定期的に公開しています。そのいずれも、あなた自身の鍵の代わりにはなりません――それは、その間だけ私たちが責任を問われうる部分にすぎません。

既定値は優れています。ただし、上書きする価値があるものが二つあります。

暗号方式。512ビット鍵のaes-xts-plain64が既定値であり、正解でもあります。512ビットは256ビット鍵二つ分であるため、これはXTSモードのAES-256であり、私たちが使っているすべてのCPUにはAES-NIが搭載されています。AESアクセラレーションのないマシンではxchacha20,aes-adiantum-plain64の方が望ましいでしょうが、それは私たちのハードウェアではありませんし、おそらくあなたのものでもないでしょう。

鍵導出。LUKS2は既定でArgon2idを使用します。これは意図的にメモリハードに設計されています。cryptsetupはフォーマット時にマシンをベンチマークし、見えているRAMからメモリコストを決定します――そしてここに、「暗号化したサーバーが起動しない」という報告の大半を生む落とし穴があります。initramfsが使えるメモリは、稼働中のシステムより少ないのです。対象のプランよりRAMの多いレスキュー環境でボリュームをフォーマットすると、起動時に解除が失敗したり、途中で強制終了されたりすることがあります。明示的に固定してください。Argon2メモリ1GiBは攻撃者にとって相当なコストとなる一方、4GBのS1でも十分に許容できる範囲です。

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memoryの単位はKiBなので、1048576は1GiBです。実際にヘッダーへ書き込まれた値は、後からcryptsetup luksDump /dev/vda2で確認できます――keyslotのセクションに、使用されるメモリ量と反復回数が表示されます。これを一度確認しておく方が、起動の失敗を経験するよりも安上がりです。

パスフレーズ。Argon2は弱いパスフレーズに対して時間を稼ぎますが、それを救うことはできません。最低でも6単語のdiceware形式のフレーズを使ってください。これはシステム内で唯一の秘密であり、どんな鍵導出関数も、悪いパスフレーズの埋め合わせをすることはできません。

ルートを暗号化したLinuxの起動には、鶏と卵の問題があります。パスフレーズを尋ねられるようになる前に、カーネルとinitramfsが読み込まれていなければなりませんが、それらは解除しようとしているそのディスクの上にあります。標準的な答えは、カーネル、initramfs、ブートローダーを収めた小さな暗号化されていない/bootパーティションです。それ以外のすべてはLUKSの中に入ります。

その後、initramfsは処理を止めてパスフレーズを尋ねます。ノートパソコンならその場で入力すればよいのですが、3,000キロメートル離れたサーバーでは、次の二つのうちどちらかが必要です。

• コンソール。ダッシュボード上のすべてのサーバーにはnoVNCコンソールがあり、実際に機能します――ただし、キー入力は私たちのインフラを経由します。これはまさに、あなたの鍵が締め出すべき相手そのものです。一回限りの復旧作業には十分ですが、日常の手段としては不適切です。
• initramfsの中で動くSSHサーバー。dropbear-initramfsは約200KBで、ネットワークを立ち上げ、選んだポートで待ち受け、あなたの公開鍵のいずれかを受け入れ、そのまま解除プロンプトへと導きます。パスフレーズはあなたのノートパソコンからinitramfsまでエンドツーエンドで暗号化されます。これが正しい答えです。

二つ、つまずきやすい点があります。initramfs内のDropbearは専用のホスト鍵を持つため、そのフィンガープリントは普段使っているSSHデーモンのものとは異なります――これは想定内であり、中間者攻撃ではありません。習慣的にyesと入力するのではなく、専用のknown_hostsファイルを用意する価値があります。そして、インターフェース名も正しく指定する必要があります。Debian 13上のvirtio NICは通常ens3かenp1s0として認識され、eth0ではありません。設定を書く前にip -br linkで確認してください。間違えると、ネットワークのないinitramfsになり、コンソールに頼るしかなくなります。

カーネル更新、ホストの再起動、電源イベントの後などに、マシンが自力で復帰しなければならない場合、パスフレーズを入力するという方法は現実的ではありません。Clevisは外部のポリシーにLUKSキースロットを結び付け、Tangはそのうち最もシンプルで実用的なものを実装した小さな鍵交換サーバーです。

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

起動時、initramfsはTangとの間でMcCallum-Relyea鍵交換を行い、Tangサーバー側にその鍵やパスフレーズを一切知られることなく鍵を復元します。この仕組みの性質は、正確に述べておく価値があります。

• VPSはTangに到達できる間だけ自分自身を復号します。Tangを停止するか、その鍵をローテーションすれば、次の起動はそこで完全に止まります。これは正真正銘のリモートキルスイッチであり、珍しくかつ有用な性質です。
• Tangを公共のインターネットに置いてはいけません。WireGuard経由か、Torのオニオンサービスとして到達させてください。トンネルの張り方はWireGuardガイドで扱っています。
• Tangはデータとは異なる法域に置いてください。当社の法域ページは、まさにこの種の切り分けのために存在します。
• 別のキースロットにもパスフレーズを保持してください。Clevisは利便性のための層であり、唯一の入り口にしてはいけません。

自分が何を構築したのかを理解してください。無人のマシンは、代理という形で自分自身の鍵を保持することになります。そのため、稼働中にVPSを押収した攻撃者、あるいはあなたのTangサーバーに到達できる攻撃者は、データを手に入れます。これはパスフレーズを自分の頭の中だけに置いておく場合と比べて、実質的な弱体化です。可用性が秘匿性の最後の一片よりも重要な場合にこれを選んでください。既定の選択にはしないでください。

暗号化されたルートは表面のほとんどを覆いますが、いくつかの経路はその外に書き出されるか、暗号化を生き延びます。

• スワップ。RAM上にあるものは何でもディスクにページアウトされる可能性があります――鍵、メッセージ本文、復号済みのバッファなどです。スワップが暗号化ボリュームの内部にスワップファイルとして存在していれば、それはカバーされます。独立したスワップパーティションはカバーされません。ただし、起動のたびに変わるランダムな鍵を使って/etc/crypttabに追加すれば別です。例えばcryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256のように指定します。VPSではスワップファイルのほうが単純であり、パーティションを選ぶ理由はありません。
• /tmp。（tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0）のようにtmpfsとしてマウントすれば、ディスクには一切触れません。速度も向上します。
• ハイバネーション。マスターキーを含むRAMの内容全体をスワップデバイスに書き出します。有効にしないでください。当社のイメージでは既定で無効になっています。
• 暗号化されていない/boot。カーネル、initramfsイメージ、GRUBの設定は、ディスクにオフラインでアクセスできる者なら誰でも読み取れ、さらに重要な点として書き換えもできます。LUKSが与えてくれるのは機密性であり、ブートの完全性ではありません。ブートローダーへの改ざんが脅威モデルに含まれるなら、暗号化だけではそれを検知できません。カーネル更新のたびに/bootのハッシュを記録し、外部から確認するか、そのギャップを意識したうえで受け入れてください。
• 既存のスナップショットと古いボリューム。今日暗号化しても、昨日取得したイメージには何の効果もありません。重要なデータを含んだまま暗号化されていない状態でサーバーを稼働させたことがあるなら、そのデータは露出したものとして扱い、そこから派生するものはすべてローテーションしてください。

オーバーヘッドは判断を左右するほど大きくはありませんが、ゼロでもありません。推測する前に測定してください。

cryptsetup benchmark

私たちのEPYCノードでは、512ビット鍵のaes-xtsは1コアあたり毎秒数ギガバイトというベンチマーク結果になり、単一のNVMeボリュームが要求する速度を余裕で上回ります。実際に現れるコストはスループットではなく、小さなランダム書き込みにおけるレイテンシとCPU負荷です。

NVMeでは、LUKS2の二つのフラグが重要になります。カーネルのdm-cryptワークキューが、レイテンシを取り除くどころか追加してしまうためです。これらを設定し、ヘッダーに固定してください。

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

三つ目のフラグである--allow-discardsは、TRIMを下層のデバイスへとそのまま通します。ボリュームの寿命を通じて書き込み増幅を抑えられますが、その代償として、どのブロックが未使用かが露見します――これは、生のデバイスを読む者に対して、データのおおよそのサイズと形状を漏らすことになります。汎用サーバーでは有効にし、ボリュームの使用率が3%であること自体が機微な情報である場合は無効のままにしてください。普遍的に正しい答えはなく、意図的に下すべき判断があるだけです。

LUKSヘッダーはパーティションの先頭にあるおよそ16MBの領域で、マスターキーの暗号化されたコピーを保持しています。これを壊すと――ddの打ち間違いや、親切にもデバイスの先頭を書き換えてしまうパーティションツールなど――その背後にあるバイトはすべて失われます。復旧サービスは存在しません。私たちも控えを持っていません。

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

そのバックアップについて、二つ知っておくべきことがあります。それはディスクと同じくらい機密性が高いということです。キースロットを含んでいるため、パスフレーズを変更した後に古いヘッダーを復元すると、古いパスフレーズがそのまま通ってしまいます。パスフレーズと同じように保管し、ローテーションした際には古いコピーを破棄してください。もう一つ、LUKS2は32個のキースロットを提供します――少なくとも二つは使い、予備のほうは日常使いのものとは別の場所に保管した長いランダムなパスフレーズにしてください。これが防ぐ失敗は地味でありながらよくあるものです。パスフレーズをローテーションする際に、二回とも同じように打ち間違え、それに気づくのが次のログイン時ではなく次の再起動時になる、というものです。

戻る手段も用意してください。レスキューモードは、あなたのSSH鍵が注入された状態で当社のISOからサーバーを起動し、暗号化されたボリュームには手を触れません。つまり、cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mntを実行し、壊れたcrypttabや不具合のあるinitramfsを、データを失うことなく修復できるということです。これは何も壊れていないうちに、一度は意図的に試しておいてください。

このようなガイドが果たせる最も有用な役割は、自らの限界を明示することです。

• 稼働中のサーバーは守りません。マスターキーは、解除されてからシャットダウンされるまでの間、カーネルメモリ上にあります。ハイパーバイザーレベルでのメモリアクセスは、これを無効化します。メモリ暗号化――AMDのSEV-SNPやそれに類する技術――だけが、この点を実質的に変えうる唯一の技術ですが、私たちは現時点でそれを提供していません。SEVなしであなたの稼働中のVMを不透明にできると主張するプロバイダーがいれば、それは誤解しているか、嘘をついています。
• 匿名にはしてくれません。Zürichにある暗号化されたディスクにも、IP、課金記録、どこかから始まったSSHセッションがあります。これは別の問題であり、そこで何がうまくいかなくなるかは匿名性を失わせるミスにまとめてあります。
• 裁判所が命じられることを変えはしません。強制力を左右するのは法域であり、読み取り可能性を左右するのは暗号化です。法域によっては、パスフレーズを個人として開示するよう命じられることがあります。当社の法的手続きガイドで、私たちが対応することと対応しないことをまとめています。
• 失ったパスフレーズを生き延びさせることはできません。これは設計上そうなっており、繰り返す価値があります。手伝ってほしいというサポートチケットが月に一度ほど届きますが、答えはいつも同じだからです。
• ブートチェーンを認証しません。機密性は完全性ではありません。/bootはオフラインで読み取りも書き換えも可能です。

暗号化が実際にすることは、露出の一分野をまるごと取り除くことです――ディスクが稼働していないときに起きること、つまりディスクの身に起きることの大半です。それだけでも1時間かける価値があります。no-KYCでの登録、Monero決済、そして意図的に選んだ法域を組み合わせれば、それぞれの層が異なる失敗をカバーします。そのどれか一つがすべてをカバーすることはありません。