さくらのクラウド「ディスク暗号化機能」のアップデート

この記事は さくらインターネット Advent Calendar 2025 1日目の記事です。

さくらインターネットの大久保です。お久しぶりです。
毎年この時期にしかブログを書けてませんね(もっと頑張らないと)。

IaaS基盤開発チームについて

最近自分は、さくらのクラウドを支えるバックエンド組織の1つである「IaaS基盤開発チーム」で仕事をしています。 強々のエンジニアに囲まれて非常に楽しいです。

我々のチームでは、クラウドAPIからホストサーバ、ストレージ、ネットワークといったデータセンターに設置されている物理機器をプロビジョニングするソフトウェアの開発、運用を主に行っています。併せて、バックエンドを構成するAPIサーバ、データベース、ログ基盤、バッチ、ワークフローなどの各種サーバと、その上で動作するミドルウェア群の開発、運用も担当しています。

以前、オープンソースカンファレンス2025 Hokkaidoでうちのチームメンバーが取り組みを紹介しました。以下に発表内容が記事化されていますので、ぜひご覧ください。

さくらのIaaS基盤を支えるしくみと課題＠廣瀬 崇人
https://knowledge.sakura.ad.jp/45070/

さくらのIaaS基盤のOSSの活用事例 内部利用のNFSサーバー＠滝澤 隆史
https://knowledge.sakura.ad.jp/45108/

さくらのIaaS基盤のモニタリングとOpenTelemetry＠藤原 俊一郎
https://knowledge.sakura.ad.jp/45164/

ディスク暗号化機能のアップデートを紹介します

さて、以前さくらのクラウドで「ディスク暗号化機能」をリリースした時に下記の記事を書いてました。

気づいたら、それからちょうど2年経過していました。当時、この機能はベータ版として提供していましたが、その後、正式サービスへ移行しました。また、暗号鍵管理方式を引き続き改善しています。本稿ではこの2年間のアップデートと実装の変遷を紹介したいと思います。

そもそもディスク暗号化機能とは？

ディスク暗号化機能は、お客さまのサーバ(VM)からディスクへのアクセスに対し、ホストサーバ側で透過的に暗号化、復号処理を行う機能です。この処理は透過的に行われるため、サーバからは暗号化されていることを意識する必要はありません。通常のディスクと同様にアクセスすることが可能です。

ストレージ装置内のデータに加え、ホストサーバからそこに至る経路上の通信も暗号化の対象となります。主に物理的なデータ漏えいのリスクを低減させることができます。具体的にどのようなリスクに対応できる or できないかについては前回のエントリを参照ください。

ディスク暗号化機能における暗号鍵の関係

こちらは若干おさらいとなります。暗号化機能を実装する上では、データを暗号化するための暗号鍵以外に、内部的に管理上必要な暗号鍵がいくつか存在します。それらの種類と関係は以下のようになります。

暗号鍵の種類	役割
データ暗号鍵(DEK)	お客さまのディスクのデータを暗号化するための暗号鍵
鍵暗号化鍵(KEK)	DEKを暗号化するための暗号鍵
マスターキー	KEKを暗号化するための暗号鍵 信頼の起点(root of trust)となる

初期の暗号鍵管理方法(2023/12)

前回のエントリでも紹介した通り、リリース初期の時点では、Hashicorp Vault OSS版(以下Vaultと表記)を使って暗号鍵の管理を行っていました。KEKとDEKは両者ともVaultに格納していました。

暗号鍵の種類	保管場所	生成・分離単位
DEK	VaultのKey value storeに格納	お客さまのディスク単位
KEK	VaultのTransit secret engineを利用	ゾーン単位 (全てのお客さまで共通)
Unsealkey	人手で管理	ゾーン単位 (ゾーン毎にVaultクラスタを構築)

この時点ではHardware Security Module(HSM)は導入できておらず、VaultのUnsealkeyがroot of trustという扱いになっていました。UnsealkeyはVaultが扱うデータベース全体を暗号化するための暗号鍵です(正確な説明はHashicorp Vaultのドキュメントを参照してください)。

Vaultを利用した暗号鍵管理はうまくいき、結果的にノートラブルで運用することができました。一方で、以下のような潜在的な課題もありました。

Unsealkeyの管理が煩雑

HSMが未導入の状態ではUnsealkeyは人手で管理せざるを得ません。そのため、鍵の管理者間での共有、ローテート、監査対応など、その扱い自体が煩雑性の一因となっていました。

また、可用性の観点からも課題がありました。Vaultは社内のプライベートクラウド上のVM上で動作させていました。稼働しているホストサーバの障害やメンテの際、Unsealkeyを手入力してVaultを再起動させる必要があります。クラスタを組んで冗長化しているとはいえ、都度管理者の対応が必要な状況でした。

事業継続性の懸念

暗号鍵管理はサービスの運営上、非常に重要なコンポーネントです。これを特定のソフトウェアに依存することのリスクがありました。OSSのライセンス変更などで将来利用できなくなる可能性を想定し、代替手段の確保が必要でした。

HSMを導入し暗号鍵管理基盤を内製化しました(2025/3)

上記のような課題を解決するため、HSMの導入に加え、Vaultに依存しない内製の鍵管理システムを開発しました。社内ではこの内製システムを "Secure Operation System(SOS)" と呼んでいます。SOSは2025/3から本番運用を開始しています。

SOSはデータセンターに設置されたHSMと、その機能をREST APIとして利用できるようにするためのAPIサーバから構成されます。

若干話がそれますが、HSMを直接利用するのは非常にハードルが高いんですね。

HSMとクライアント間の通信は、ベンダ独自のプロトコルで行われる

クライアントにはドライバのインストールが必要となります。また、HSM側でも個々にクライアント認証の設定が必要となります。

アプリケーションからPKCS#11のインターフェイスを利用する必要がある

HSMベンダから提供されるライブラリをアプリケーションから動的/静的リンクして関数を呼び出す必要があります。基本的にC言語で処理が書かれることを想定されており、利用できるプログラミング言語は限られます。pkcs11-toolなどのOSSもありますが、ベンダのサポート対象外です。手軽には利用できるものではありません。

なお、PKCS#11はインターフェイス(関数や構造体)は標準化されているものの、細かいパラメータについてはHSMベンダ毎に癖があります。エラーが発生した際、 メッセージのバイナリをダンプしてにらめっこ する必要があるなど、原因を特定するのが難しいです。

--

こうした理由により、SOSは一般的なREST APIを備え、社内システムからHTTPSにて叩けるように開発されました。また、Vault互換のAPIも副次的に実装したため、これまでVaultを利用していた連携システムは一切修正することなくSOSへの切り替えができました。

SOSへの切り替え後の、各暗号鍵の管理方法は以下の通りです。それまでのVaultの管理、運用(特にUnsealkey)にまつわる面倒がなくなりました。加えて、HSMがroot of trustとなることで安全性が向上しました。

※ 太字は前回からの変更箇所

暗号鍵の種類	保管場所	生成・分離単位
DEK	SOSのKey value storeに格納	お客さまのディスク単位
KEK	HSM内で生成・保管する暗号鍵	ゾーン単位 (全てのお客さまで共通)
マスターキー	HSMそのもの (ハードウェアに書き込まれている暗号鍵)	リージョン単位 (東京と石狩DCにHSMを設置)

KMS機能の提供を開始しました(2025/9)

ディスク暗号化機能で扱われる暗号鍵は、いわゆる「フルマネージドキー」と呼ばれる提供形態でした。暗号鍵の生成から破棄に渡るライフサイクル全般を弊社が管理するものです。お客さまは暗号鍵管理の手間が一切かからない、というメリットがあります。一方で、お客さま自身で暗号鍵のライフサイクル管理を行うことはできません。

そこで、それを可能とする「KMS機能」を開発し、2025/2よりベータ版として、2025/9より正式サービスとして提供開始しました。これは前者と対比し、一般的に「カスタマーマネージドキー」と呼ばれる提供形態になります。

KMS機能とは？

KMS機能は、ざっくりいうとAESなどの対称暗号鍵(これをKMSキーと呼びます)を当社でお預りするサービスです。KMSキーを用いてbase64エンコードしたデータの暗号化/復号操作が可能です。ただし、大量のデータを扱う用途には向いていません。そういった用途では、データを暗号化する暗号鍵(DEK)を別途作成し、DEK自体をKMSキーで暗号化するような使い方(KEK用途)を想定しています。

KMSキーはFIPS140-2 Level3認証を受けたHSMと連携して保護されます。また、Bring Your Own Key(BYOK)にも対応しています。お客さま自身でキーマテリアル(生の暗号鍵のビット列)の指定が可能です。

BYOKによりKMSキーを作成するコンパネイメージ

もちろん「自動生成」を選択いただいてもセキュリティ上問題なくご利用いただけます。コンプライアンス要件など特別な理由がなければ自動生成をお勧めします。

KMS機能で可能な操作は以下の通りです。

• 鍵の生成、削除(※)
• 鍵のステータス変更(有効/制限中/一時停止中)
• 鍵のローテート
• データの暗号化/復号

※ 削除する際、誤操作を防ぐため最低7日間の保留中期間を経る必要があります

暗号化や復号は、APIを用いて簡単に行うことが可能です。以下にコマンド例を記載します。

KMSキーを用いてデータを暗号化する例

まず平文をbase64エンコードする

$ echo 'hello world' | base64
aGVsbG8gd29ybGQK

$ curl -sSf -u 'APIアクセストークン:APIアクセストークンシークレット' \
  -H 'Content-Type: application/json' -X POST \
  -d '{"Key":{"Plain":"aGVsbG8gd29ybGQK","Algo":"aes-256-gcm"}}' \
  https://secure.sakura.ad.jp/cloud/zone/is1a/api/cloud/1.1/kms/keys/XXXXXXXXXXXX/encrypt | jq .
{
  "Key": {
    "Cipher": "g6NhbGerYWVzLTI1Ni1nY22ja2V5g6JpZKwxMTM3MDA1NzEyNzmia3YAo2(省略)"
  }
}

KMSキーを用いてデータを復号する例

$ curl -sSf -u 'APIアクセストークン:APIアクセストークンシークレット' \
  -H 'Content-Type: application/json' -X POST \
  -d '{"Key":{"Cipher":"g6NhbGerYWVzLTI1Ni1nY22ja2V5g6JpZKwxMTM3MDA1NzEyNzmia3YAo2(省略)"}}' \
  https://secure.sakura.ad.jp/cloud/zone/is1a/api/cloud/1.1/kms/keys/XXXXXXXXXXXX/decrypt | jq .
{
  "Key": {
    "Plain": "aGVsbG8gd29ybGQK"
  }
}

$ echo aGVsbG8gd29ybGQK | base64 -d
hello world

詳細はマニュアルをご参照ください。
https://manual.sakura.ad.jp/cloud/appliance/kms/index.html

また、KMSの活用事例について、弊社メンバーが本アドベントカレンダーで紹介予定です。こちらも併せて参考にしていただければと思います。

ディスク暗号化機能をKMSに対応しました(2025/9)

KMS機能の正式サービス化と同時に、ディスク暗号化機能で扱う暗号鍵をKMSと連携する方式に移行しました。いわゆるフルマネージドキーからカスタマーマネージドキーへ移行した形になります。

コンパネで暗号化ディスクを作成する際、KMSキーを選択できるようになっています。(KMSキーは事前に作成しておく必要があります)

暗号化ディスクを作成すると、ディスクの情報画面にて、連携しているKMSキーのIDと名前が表示されます。操作の詳細はマニュアルを参照ください。
https://manual.sakura.ad.jp/cloud/storage/disk-encryption.html

この時指定するKMSキーは、他の暗号化ディスクと共用可能です。もし、暗号化ディスク毎に連携するKMSキーを個別に分けたい場合は、それぞれの用途に応じたKMSキーを複数作成することも可能です。

なお、KMSキー連携前(2025/9/17以前)から存在する暗号化ディスクについては、対象のディスクを保有するお客さまのプロジェクト内に、弊社側でKMSキー1つを自動的に作成させていただきました。このKMSキーは種別が「レガシー」になっており区別可能です。レガシーキーは課金対象外となりますが、新規作成される暗号化ディスクに利用することはできません。

レガシーキーの例(新規の暗号化ディスクには使えません)

KMSキー連携による暗号鍵管理方法の変更

KMSキー連携により、暗号鍵の配置も見直しました。これまでKEKとDEKは同じシステムに格納していました。今回、DEKはKMSキーで暗号化したものをIaaS側の構成管理データベースに保存することとしました。2025/12現在、下記のような構成になっています。

※ 太字は前回からの変更箇所

暗号鍵の種類	保管場所	生成・分離単位
DEK	IaaSの構成管理データベース	お客さまのディスク単位
KEK	HSM内に格納される暗号鍵(KMSキー)	お客さまごとに分離
マスターキー	HSMそのもの	リージョン単位

結果的に、root of trust、KEK、DEK、ストレージ機器の物理的/論理的な距離が保たれ、安全性を一層高めることができたと考えています。

まとめ

本稿では、さくらのクラウド「ディスク暗号化機能」について、2年間のアップデートを紹介させていただきました。今後も国産クラウドとして安心、安全に利用できるようサービス拡充を続けて参ります。

また、明日以降も引き続き、弊社のアドベントカレンダーをお楽しみください！