はじめに

近年幅広い業種で Azure, AWS, GCP などパブリッククラウドサービスを活用する動きが高まっています。その一環として金融機関など高度なセキュリティ対策が求められる企業もパブリッククラウドを選択するケースが増えてきています。
しかしセキュリティ対策は最新の攻撃といたちごっこの状態です。その中で内部や外部からの攻撃に対して通常クラウドサービスでは「データを暗号化」して、データを保護しています。
ただ HTTPS, TLS などは浮かんでも、「使用中のデータの暗号化」に関してあまり理解が進んでいない方も多いのではないでしょうか？

そこで本ブログでは使用中のデータの暗号化の技術として Confidential Computing の基礎を紹介します。
まとめるにあたって、O'Reiliy の Azure Condifential Computing and Zero Trust が 2023 年 11 月 15 日に出版されたので、参考にしています。
(そもそもとても読みやすいので是非一読してみてください)

今回まとめた内容としては

Confidential Computing の概要
暗号化の仕組み
Zero-trust を実現する上での Confidential Computing の役割
Azure の Confidential Computing
Confidential AI とは？

です。Confidential Computing の概要を知りたい方は「Zero-trust を実現する上での Confidential Computing の役割」まで読むことをお勧めします。

Confidential Computing の概要

前述しましたが Confidential Computing は「使用中のデータを暗号化できる技術」になります。実際に Confidential Computing Consortium (CCC) によって定義された業界用語で、CCC では以下のように Confidential Computing を定義しています。

本文:
The protection of data in-use by performing computation in a hardware-based, attested trusted execution environment (TEE).
日訳:
ハードウェアベースの認証された信頼できる実行環境（TEE）で計算を実行することにより、使用中のデータを保護する。

つまり TEE の内部で計算することにより、ハイパーバイザーレベルで外部からデータを保護できる技術となっています。

TEE とは？という方はここをクリック

TEE とは Trusted Execution Envirnment の略で、ハードウェア方式とも呼ばれる、通常の OS とは異なる Trusted OS 上の環境で「秘密計算技術」と呼ばれます。この技術を利用して、メインプロセッサの中になる安全な領域内で検査言いさせ、その中のデータや、コードは外部から読み取りや改ざんができなくなります。
例えば「銀行の金庫」が挙げられます。銀行の金庫は外部から盗難や破壊できないようになっています。金庫室内では、銀教員など適切に認証された人だけがお金の持ち出しなどできる環境になっています。

それではデータの暗号化の 3 種類に関して以下の図を参考にし、ふりかえります。

保管時のデータ
- SQL Server Transparent Database Encryption(TDE) など
転送中のデータ
- TLS, HTTPS など
使用中のデータ
- Confidential Computing

アプリケーションは、メモリ内のデータを処理するためには、データを一時的に復号化する必要があります。しかし、このプロセス中にデータは一時的に暗号化されていないため、攻撃者によって読み取られる可能性があります。そのため「使用中のデータの暗号化」という観点からクラウド利用を安全に進めるために、Confidential Computing は注目されています。

暗号化の仕組み

では Confidential Computing の内部に迫っていきましょう。ここでは暗号化がどうなっているのか？どのように外部からデータを保護するのか？それには Confidential Computing 3 つの特徴が重要になります。

Hardware root of trust
Memory protection
Attestation

まず Hardware root of trust に関してです。

Hardware root of trust

ここでは CPU が製造された時点でのマスターキーが肝になります。
まず製造の段階で CPU が作られたときに CPU シリコンにユニークなマスターキーが保存されます。このマスターキーは CPU からエクスポートができなく、CPU ハードウェアの外からはアクセスができない仕様になっています。

このマスターキーが基になってメモリ内のデータを暗号化するためのキーが生成されるわけです。ここがクラウドオペレーターが操作できないところであり、つまりオペレーターでさえ信頼させない構造になります。

メモリ内のデータを暗号化するために使用されるキーは、基盤となる信頼された実行環境 (TEE) のハードウェア上で実行されるファームウェアによって生成されます。これらのキーは、CPU のファームウェアによって管理され、外部のソフトウェアからはアクセスできないようになっています。
よってこの特徴をもって TEE の外は信頼ができないといった設計になります。

Memory protection

メモリ保護は、データがメモリに書き込まれる際に常に暗号化されることを保証することです。先ほども述べましたが、これは TEE のハードウェア上で実行されるファームウェアによって生成されたキーを使用します。

このキーはクラウドオペレーターからアクセスできないようになっていて、
そのメモリを所有するTEE内のソフトウェアだけが、それを書き換えたり読み取ったりできるため、不正なアクセスや変更からデータを保護します。
以下がこのメモリ保護を有効にしている特徴です。

Data and code confidentiality
- TEE メモリ内のコードやデータに関しては認証されていないエンティティはアクセスできません。
- AI モデルやトレーニングデータなど Sensitive data の漏洩を防げます。
Data and code integrity
- 認証されていないエンティティは TEE メモリ内のデータを書き換えることはできません。

最後に Attestation です。

Attestation

そもそも TEE も信頼できるの？といった観点が Attestation の肝になります。(もう本当に誰も信頼しませんね笑) つまり TEE のソフトウェアとコンポーネントとハードウェアの信頼性を確かめるものと言えます。ここではハードウェアとソフトウェアの妥当性と信頼性が重要になります。

TEE のハードウェアの妥当性と信頼性
- TEE は、製造元、バージョン、ファームウェアなどの期待されるハードウェアに基づいていることが確認されます。また、関連するメモリ保護機能が有効であることも確認されます。このようにして、データの整合性と機密性、およびコードの整合性を提供します。
TEE 内で実行されるソフトウェアの妥当性と信頼性
- TEE 内で実行されるソフトウェアが信頼性のあるものであることも確認する必要があります。TEE はメモリ内のデータを隔離し、基盤となる CPU ファームウェアによって管理されたキーを使用してメモリ内のデータを暗号化します。また、TEE外で実行されるソフトウェアからメモリ内のデータが変更されることを防ぎます。

以上の 3 つの特徴によって Confidential Computing の使用中のデータが CPU 製造時からなるキーを基にして暗号化し、また TEE のコンポーネント自体の信頼性も確かめることでデータを保護します。

実際 Confidential Computing の定義はベンダーに対して中立的で、 TEE の保護されたメモリに含まれるものや除外されるものを具体的には指定していません。しかし TEE のメモリの隔離レベルは求められていて、CPU ベンダーによって 3 つのメモリ隔離レベルが提供されています。それが次のセクションの内容になります。

TEE のメモリ隔離レベル

O'Reiliy の図から引用したものになりますが、今回は Level of isolation (隔離レベル) と Protection from Insider threat (内部的脅威からの保護)この観点に絞ってまとめます。

表から見ても分かるようにメモリ隔離レベルには 3 段階あります。

仮想マシンレベル
コンテナレベル
アプリケーションコードレベル

それぞれのレベルには、基盤となるCPUファームウェアによって割り当てられた固有のメモリ暗号化キーがあります。

ではどのレベルで守ればいいのか？？気になりますね。結論はコンテナレベルの隔離が一番簡単に扱えると記載されています。その理由として以下が挙げられます。

仮想マシンレベル
- デフォルトでは内部の脅威から守ることができない
アプリケーションコードレベル
- コードのリファクタリングが必要で、コストが高い
- OSS の SDK を使用する必要がある

つまりコンテナレベルの固有のメモリ暗号化キーを使用し、コードも変更せず、デフォルトで内部の脅威から守れることにより、一番簡単にクラウドネイティブワークロードを保護することができます。

では Zero-trust の概念の中の Confidential Computing の位置づけに関して迫っていきます。

Zero-trust を実現する上での Confidential Computing の役割

まず Zero-trust の定義からおさらいしていきます。その名の通り、「信頼は(Trust) 何に対してもしない(Zero)」という前提で成り立つ考え方です。Zero-turst は Forresterによって 2009 年に発表されたものになります。
ゼロトラストの基本的な考え方は次の点です

侵害を想定する
明示的に検証する
最小限の特権アクセスを使用する

具体的には

許可されたユーザーからのアクセスであるか: すべてのアクセスは明確に認証され、許可されたユーザーによるものである必要があります。
通常と異なるロケーションからアクセスがないか: 不審な場所からのアクセスを検出し、適切に制御します。
不審な振る舞いが発生していないか: ユーザーの行動を監視して、不正なアクティビティを特定します。
利用しているクラウドサービスにリスクがないか: クラウドサービスのセキュリティも考慮します。

を考慮する考え方です。

NIST によると Confidential Computing における Hardware Root of Trust はImplicitly Trusted のスタートポイントなるとされています。
パブリッククラウドの拡大により以下のことが言えます。

プライベートクラウドで運用するならこのハードウェアの制御ができます。
パブリッククラウドの場合はその依存性をクラウドプロバイダーにゆだねることになります。
- その際 Hardware root of trust for TEEs は顧客データがプライベートに保管できていることをパブリッククラウドを用いても保証することができます。

これはシリコンチップやその他のチップは一度作成されると非代替になることで、一度デプロイされるとその信頼性は侵害されないということが理由になります。

この信頼は、シリコンチップがまず暗号化された方法を使用して自分自身を測定し、改ざんされていないことを保証します。そしてその状態をいつでも検証できるためです。

またハードウェアとソフトウェアの分離が、チップは製造者、ソフトウェアはクラウドオペレーターという観点から、クラウドオペレーターがメモリ内のデータへのアクセス権を得て侵害するなどといった脅威から守ることができます。

これは CPU のファームウェアによって生成される鍵でメモリ内のデータを暗号化しているためです。

さらに Attestation プロセスにおいて、データとコードの整合性および機密性を保証し、メモリ保護が有効でないハードウェアに移行された場合にそのワークロードが実行されないようにします。この Attestation が Zero-trust において重要な役割になります。

Attestation の Zero-trust における重要性

TEE は信頼できるといわれますが、その言葉だけで信頼するのは "明示的に検証する" を満たしていません。
そこで重要なのが Attestation になります。

Attestation によって明示的に暗号化されているかの確認の証拠を要求でき、以下の2つのことを証明することができます。

TEE の妥当性
コードが改ざんされていないことの確認

これによって組織はクラウドオペレーターさえ信頼しないことを実現することができます。
以上より Confidential Computing における

侵害を想定する
明示的に検証する
最小限の特権アクセスを使用する

のカバー範囲をまとめたのが以下の図になります。

次に Azure における Confidential Computing を紹介します。

Azure の Confidential Computing

Azure Confidential Computing (ACC) は、前述で紹介した定義と原則に従って、使用中の機密データを保護するための製品とサポートサービスのポートフォリオです。このポートフォリオには、VM、コンテナベースの PaaS、およびその他の PaaS と SaaS が含まれます。2023 年 11 月時点でのポートフォリオの概要を以下に示します。

今回は PaaS に関しては触れませんが、コンテナレベルのメモリ隔離が可能な Azure Container Instance (ACI) や、仮想マシン・アプリケーションコードレベルでのメモリ隔離が可能な Azure Kubernetes Service (AKS) など Confidential Computing 対応の AMD SEV-SNP VM, Intel TDX VM 上での PaaS 製品があります。詳しくは以下を参照してください.

Confidential VMs

Azure Confidential VM（ACC）は、セキュリティ要件を満たすために、強力なセキュリティと機密性、およびハードウェアによる境界を提供しています。Confidential VM は、既存のワークロードを移行し、コードを変更せずにアプリケーションをリフトアンドシフトするシナリオで特に有用です。

Confidential VM を使用することの利点として以下が挙げられます

仮想マシン、ハイパーバイザー、およびホスト管理コードの間の堅牢なハードウェアベースの分離
デプロイ前にホストのコンプライアンスを確認するためのカスタマイズ可能なアテステーションポリシー
初回起動前のクラウドベースの Confidential OS ディスク暗号化
プラットフォームまたはカスタマー（オプションで）が所有および管理するVM暗号化キー
プラットフォームの成功したアテステーションと VM の暗号化キーの間の暗号的バインディングによるセキュアキーリリース
仮想マシン内のキーとシークレットを Attestation および保護する専用の仮想 Trusted Platform Module（TPM）インスタンス

では Confidential VM がどのようにしてハイパーバイザーからの読み取りと改ざんを防ぐ方法を表した図が以下になります。

この様にしてハイパーパイザーは TEE 外となるため、前述したようにアクセスができなくなります。

次にコードレベルの隔離に関してです。

VM 内のアプリケーション enclave は、Intel Software Guard Extensions（SGX）技術を使用してコードレベルの隔離をサポートしています。
では enclave 内でどの部分のアプリケーションが動作しているかを理解していきます。

エンクレーブは、そのコードの一部をアプリケーションの残りから分離します
Enclave を作成します
Attest をしてそのEnclave が信頼できるかを確かめます
Enclave 内の信頼されたコードを実行し、戻り値を Call bridge を介して受け取ります

以上が Confidential VM の仕組みになります。

最後に Microsoft の Attestation サービスに関してです。

Microsoft Azure Attestation

Microsoft Azure Attestationは、ハードウェアプラットフォームとそれ上で実行されているソフトウェアの信頼性を検証するサービスです。

このサービスは、Trusted Platform Modules (TPMs) でサポートされるプラットフォームの検証と、TEE（Trusted Execution Environments）の状態の検証の両方を可能にします。

これにより、シークレットマネージャーなどの信頼する側は、シークレットがリリースされ、機密のワークロードが処理される前に、意図したソフトウェアが信頼できるハードウェア上で実行されていることを保証できます。

Attestation は、次の 2 つのパターンに従うことができます：

パスポートモデル：TEE 内のアプリケーションは、証拠を直接検証者（Azure Attestation またはサードパーティの証明サービス）に渡し、検証者からの確認を受けてから、信頼する側からシークレットを要求します。
バックグラウンドチェックモデル：TEE 内のアプリケーションは最初に証拠を信頼する側に渡してシークレットを要求し、信頼する側が証拠が信頼できるかどうかを検証した後にTEEにシークレットを提供します。

Confidential AI とは？

近年、生成 AI は革新と変革の重要な領域として浮上しています。特に、大規模言語モデルの人気が急速に高まっています。これは GPU に強く依存しており、また機密データの取り扱いに関しても懸念が生まれます。そこで考えられるのが Confidential AI です。 Azure における Confidential Computing 対応の GPU はこちらを参照してください。

Confidential AI は、ハードウェアベースの技術のセットであり、AI ライフサイクル全体でデータとモデルを暗号的に検証可能な方法で保護できます。前述した通りデータとモデルが使用中である場合でも保護が可能です。

例として競合する 2 つの銀行が共有データセットでモデルをトレーニングすることで、顧客を詐欺から保護し、両者にとって Win-Win の状況を生み出す方法を示します。

このシナリオでは、機密計算を活用することで、組織は Confidential AI のすべての利点を享受できる一方で、パフォーマンスやデータプライバシーを犠牲にすることなく、最大限の利益を得ることができます。
なんとなく Confidential AI が分かってきましたでしょうか？最後に Confidential AI のシナリオに関してまとめます。

Confidential Training: トレーニングデータ、モデルアーキテクチャ、およびモデルの重みを、ローグ管理者や内部者などの高度な攻撃者から保護できます。このモデルの重みを保護することは、トレーニングデータが公開されている場合でも、リソースが豊富であるか、モデル IP が機密である場合に重要です。
Confidential Fine-tuning: ドメイン固有のプライベートデータを使用して汎用 AI モデルを微調整することは一般的だとと思います。ここで Confidential AI は、微調整中にプロプライエタリデータとトレーニングされたモデルを保護するために使用できます。
Confidential Multi-party Training: 複数の組織がモデルを相互に公開せずに共同でトレーニングするシナリオを実現します。結果の共有方法についてもポリシーを適用できます。先ほどの例で示しましたね。
Confidential Federated Learning: データの集約ができないシナリオで、分散トレーニングの代替として提案されています。Federated Learning と組み合わせることで、機密性とプライバシーを強化できます

まとめ

今回の記事では以下のことに関してまとめました。

Confidential Computing は使用中のデータを暗号化できる技術で、TEE というハードウェアベースの信頼できる実行環境で計算を行うことを確認しました
Confidential Computing は Zero-trust の原則に沿って、データとコードの整合性と機密性を保証し、内部や外部からの攻撃に対して強固なセキュリティを提供することを確認しました
Azure Confidential Computing は、仮想マシン、コンテナ、PaaS、SaaS などの製品とサービスで Confidential Computing を実現し、Attestation サービスで信頼性を検証することを確認しました
Confidential AI は、Confidential Computing を活用して、AI ライフサイクル全体でデータとモデルを保護し、プライバシーとパフォーマンスを両立することを確認しました

以上、 Confidential Computing と Azure での Confidential Computing に関してでした。
アドバイスや質問はいつでも受け付けております。

Confidential Computing の概要 ~Confidential AI も少し~