re:Invent 2025: 暗号化アテステーションとNitro Enclavesで実現する機密コンピューティング
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Demystify attestation: Cryptographically verify execution environment (CMP317)
この動画では、EC2のPrincipal EngineerであるAlex GrafとSenior Solutions ArchitectのSudhirが、暗号化アテステーションと機密コンピューティングの実装方法を解説しています。AIモデルの知的財産と顧客の機密データを同時に保護するマルチパーティコラボレーションのユースケースを例に、EC2 Instance AttestationとNitro Enclavesの2つのアプローチを詳説。KIWI-NGやNixを使用したattestable AMIの構築方法、PCR値を用いた実行環境の検証、AWS KMSとの統合によるシークレット管理の仕組みを実演しました。LLMモデルの重みをエンベロープ暗号化してシールし、正しいattestation documentを提示する環境でのみ復号化を許可する実装例を通じて、AWS Operatorからも顧客のOperatorからもアクセスできない真の機密コンピューティング環境の構築手法を示しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
暗号化アテステーションの概要：AI企業が直面する機密データとモデル保護の課題
こんにちは、午後のセッションへようこそ。本日は「暗号化アテステーションの謎を解く：暗号化アテステーションを機能させ、実行環境を検証して、実行したいものだけを実行していることを確認する方法」というセッションです。私は EC2 組織のプリンシパルエンジニアの Alex Graf です。そして一緒に来ているのは Sudhir で、彼は EC2 関連のトピック、特に私と同じように機密コンピューティングに取り組んでいるシニアソリューションズアーキテクトです。
さて、あなたが AI 企業だと想像してください。AI モデルを構築していて、それに深く投資しているわけです。基本的にそのような AI モデルを構築するのにすべてのお金を使っています。非常に高額なものです。だからお客様にそれを使ってもらいたいわけです。どうやってお客様に使ってもらうのか？まず、何か操作を実行してもらいたいデータを持っているお客様を見つけます。それは、あなたと AI モデルが彼らのためにできることです。 その操作を実行すると、そのデータに影響を与えて、モデルが結果を出力し、お客様は満足します。
このようなアーキテクチャを設計する際に、最初に明らかにやることは、それをサービスとして構築することですよね？お客様がそのデータをあなたのところに送信して、あなたがそれを処理して結果を生成します。これはほとんどの環境では本当に満足のいくケースです。ただし、お客様が実は非常にセンシティブなデータを持っていて、それをあなたに渡したくないということに気づくまでは。 では、その問題をどう解決するのか？お客様はそのデータをあなたの環境に渡すことはできませんが、むしろそれを自分たちの環境に保ちたいわけです。 まあ、簡単ですよね？基本的には、環境をお客様に提供するだけです。なぜ単にお客様が自分たちのオンプレミスまたは自分たちのアカウントで AI モデルを実行できるようにしないのか。そうすれば、実行に関して私たちを信頼する必要がなくなります。
ただし、その問題は、この AI モデルの訓練は安くはなく、それは知的財産のようなものなので、誰もそれを見ることができないようにしたいわけです。 では、何ができるのか？機密コンピューティングの出番です。それの周りにボックスを置けば、ボックスの周りに置くことで物事がより見栄え良くなるので、そのボックスの周りに素敵なシールドで保護して、それを機密コンピューティングと呼べば、問題は解決します。
このプレゼンテーションに参加している理由は、それが実際にはどのように機能しているのかを見て、その下で何ができるのか、そして実際にそれをどのようにできるのかを理解するためです。 つまり、機密コンピューティングを一言で言うと、環境内で実行されているものに誰もアクセスできないようにするということです。このシールド、ボックスとシールドで何をするかというと、本当のところ、外の世界への通信があるときはいつでも、そのインターフェースを、漏らしたくないデータが漏れない点まで定義するということです。一言で言うと非常に簡単に聞こえますが、詳細は、もちろん悪魔は細部に宿るわけです。
Confidential Computingの2つの次元：AWSオペレーターとアカウントオペレーターからの隔離
ここで構築しようとしている Confidential Computing の基本的な考え方は、アカウントオペレーターが、実際にあなたの機密ワークロードを実行している Trusted Execution Environment というインスタンスやエンティティにアクセスできないということです。 しかし、それだけではありません。この Confidential Computing 環境は、テクノロジーのスタックの上で動作しています。AWS の場合、それは Nitro スタックです。そして Nitro では、まったく同じモデルに従っています。明確に定義された API があり、顧客データへのアクセスパターンやアクセスパスを含まないようにしているので、そのスタックの上で実行されるあらゆるワークロードは、それでも艦隊を運用する必要がある AWS オペレーターから保護されています。
この問題を考える別の方法は、それを次元で見ることです。 私たちが AWS オペレーターがアクセスできない環境を呼ぶのは第1次元です。私を含めて、私たちは日々この艦隊を運用していますが、顧客データへのアクセスを可能にするような API アクセスは一切ありません。 第2次元は、その反対側で、あなたのアプリケーションがあなた自身のオペレーターからのアクセスや、先ほどの AI モデルの例で示したような、この実行環境を運用している誰かからのアクセスを防ぐ場合についてです。
そして、このコンセプト全体がどのように機能するかについてもっと知りたい場合は、Nitro モデルがどのように機能するか、そしてシステム全体がどのように設計されているかについて、私たちが書いた非常に素晴らしいホワイトペーパーがあります。
私たちはこのアプローチを設計し、外部の評価者である NCC Group と一緒に設計全体を検証して、Nitro システムに私が先ほど説明したセキュリティ主張を損なうようなギャップがないことを確認しました。私たちはこのスタンスについてとても自信を持っているので、利用規約に EC2 インスタンスなどへのオペレーターアクセスがないことを含めました。まとめると、Confidential Computing とは、AWS オペレーターがあなたの EC2 インスタンスデータにアクセスできないということです。 それは常にオンになっており、あなたが何もする必要はありません。それだけが気になるのであれば、安心して眠ることができます。
しかし、これはさらに先に進みます。私の意見では、真の Confidential Computing とは、AWS オペレーターだけでなく、他のエンティティからも環境を隔離することを意味します。それはあなたのワークロードをあなたのオペレーターから、または可能性としてそれにアクセスできる他のオペレーターから隔離することを意味します。それは顧客の責任の一部です。しかし、私たちはこれを簡単で達成可能なタスクにするための非常に優れたツールを提供しており、それはこのプレゼンテーションの残りの部分で説明します。
ここまで触れていなかった重要な点が1つあります。このデータにアクセスできないと言うのは良いことですが、それを証明したいですよね。つまり、あなたが話しかけているものが実際にこのコードを実行しているのか、単に私の言葉を信じているだけなのか、それを検証するメカニズムが必要です。そこについても掘り下げることができます。
暗号化アテステーションの仕組み：共有シークレットとKMSによる実行環境の検証
データの使用方法について話すときは、ここまでデータの処理について見てきました。実行環境、つまり confidential computing の実行環境があって、それがデータを処理します。でもそのデータはどこから来るのでしょうか。データは空から降ってくるわけではなく、どこかから来る必要があります。通常は保存されているデータか、あるいは 転送中のどこかから来ます。つまり誰かと通信しているということです。データを保存する場所があるか、あるいは誰かとリアルタイムで通信するかのどちらかです。そのデータは、この実行環境だけが知っている暗号化キーで暗号化される必要があります。そうすることで、信頼できるエンティティだけがストレージと通信できるか、ネットワーク経由で通信できるかを確認できます。
そこに到達するには、何らかの共有シークレット、つまり共有シークレットを認証して確保する方法が必要です。それは実行環境の内部にだけ存在し、外部には存在しません。 でもどうやってそれを取得するのでしょうか。もしそれが起動の一部として見えるなら、実行中の元のイメージを誰もが見て確認できる可能性があるため、公開されたシークレットになる可能性があります。ですから、それを実行時に行う必要があります。
では、実際にこれらの環境をどのようにビルドして実行するのか見てみましょう。Confidential computing の実行環境は常に何らかの説明から始まります。このイメージがどのように見えるか、環境がどのように見えるかを説明するものがあります。その説明からイメージを生成し、その説明から実際の環境を起動します。当然、複数の環境を起動することができます。理想的には、説明からイメージへの再現可能な方法が必要なので、常に同じ結果を得ることができます。
しかし、イメージを生成するときに本当に重要なことが1つ起こります。イメージを生成するだけではなく、 そのイメージの完全な内容を説明する暗号化ハッシュも生成します。これは本当に重要なポイントです。これらのハッシュが必要な理由は、後で実行環境を実行するときに、 信頼できる Nitro スタックが同じハッシュを再生成し、attestation ドキュメントを提供してくれるからです。そのドキュメントを使って、その特定の時点でその特定の環境のインスタンスで実際に何が実行されていたのかを特定することができます。その後、イメージ生成ハッシュと実行ハッシュを比較して使用すれば、 私たちが持っている環境は、私たちがビルドした環境であることがわかります。これが私たちがここで探している主な特性です。
では、まだシークレットは手に入っていませんが、望んでいた環境と同じように見える環境があることは分かっています。これは Key Management Service という名前のサービスを使うことで、かなり簡単に実現できます。Key Management Service に統合された機能により、ポリシーを定義することができます。
KMS はキーマテリアルを保存し、それに対して操作を実行できるサービスです。ポリシーが一致する場合にのみ、このキーに対して操作を実行することが許可されるように指定できます。基本的には、実行環境が検証済みのイメージとまったく同じであり、信頼できるコードで実際に構築されている場合、アクセス権が得られるということです。
まとめると、暗号化アテステーションとは 構築したイメージに対して実行環境を検証することを意味しています。その検証は Key Management Service に統合されています。AWS KMS を使う必要はありませんが、使うことで作業がずっと簡単になります。このメカニズムを使用して、転送中または保存中のデータへのアクセスを得ることができます。
EC2 Instance Attestation：attestable AMIとNitro TPMによる新しいアプローチ
通常、これらの confidential computing 環境では、コードは公開されており、データはプライベートであると想定しています。プライベートコードが必要な場合は、それをデータのように扱います。誰にも見られたくないプライベートコードが必要な場合は、それを暗号化するので、基本的にはデータとして再度扱われることになります。このすべてのアテステーションを実行するには、アテステーション可能な AMI が必要です。アテステーション可能な AMI は、単なる通常のイメージと同じではありません。
これはブートスタックが実際にコンテンツについて推論することを可能にする測定値とハッシュを提供する特性を得るために構築する必要がある、非常に特殊なタイプのイメージです。そのために、私たちは 2 つのメカニズムを提供しています。1 つは非常に新しいもので、今年の初めに立ち上げたばかりで、この新機能についてとても興奮しています。それは EC2 Instance Attestation と呼ばれています。
EC2 Instance Attestation というのは、説明があるということです。説明のフォーマットにはいろいろな種類がありますが、その説明は attestable AMI の中に何を入れたいかを表しています。Dockerfile のようなものだと考えてください。そして attestable AMI を生成します。これは特別な種類の AMI で、特別なブートフローを持っており、ハッシュのセットも生成されます。イメージが既にある場合でも、後からこれらのハッシュを生成することはいつでもできますが、通常は AMI を生成するときに一緒に生成します。
その後は、他の EC2 インスタンスと同じように AMI を起動できます。もし手動で EC2 インスタンスを起動したことがなければ、試してみてください。本当に楽しいですよ。基本的には、いつでも非常に素早く簡単に仮想マシンを手に入れることができるということです。このメカニズムで、機密コンピューティングを含む実際のワークロード適応を EC2 エコシステム全体に組み込んでいます。
EC2 インスタンスを起動すると、このインスタンスは ブートコンテンツをハッシュ化して Nitro TPM に保存します。これは、私たちが既にしばらくの間これらの EC2 インスタンスで提供している仮想 Trusted Platform Module です。今年私たちが新しく立ち上げたのは、この Nitro TPM が Nitro TPM attestation document を発行できるようになったということで、これにより先ほど話した KMS 統合がすべて得られるので、ブートフローに基づいてシークレットをアンロックできます。
Unified Kernel ImageとPCR測定：ブートコンテンツの完全性を保証する技術
attestable AMI がそんなに異なる理由の秘密は、それが完全に異なるブート環境を含んでいるということです。つまり Nitro スタックが仮想マシンを起動し、UEFI ブート環境、低レベルのファームウェアを実行し、その後 Unified Kernel Image、つまり UKI と呼ばれるものを起動します。これは標準的なアップストリーム Linux の概念ですが、私たちは attestable AMI で再利用しています。なぜなら、それが非常に良い特性をもたらすからです。
これはカーネル、init、そしてターゲットシステムのコマンドラインを含む単一のバイナリです。つまり UEFI がこれを起動するとき、その UKI の内容、完全な内容をハッシュ化して PCR 4 に測定します。その後 UKI は PCR 12 を見て、その UKI の一部であるカーネルコマンドラインにはルートファイルシステムのハッシュが含まれています。PCR 4 のその 1 つの数字を見るだけで、すべてが 1 つの数字に集約されているため、その 1 つのシステムのすべてのコンテンツについて推論することができます。
Nitro TPM attestation ドキュメントのおかげで、Nitro スタック上で実行されているという事実について推論することもできます。なぜなら、このドキュメントは Nitro 環境のみがアクセスできる AWS キーで署名されているからです。つまり、基本的にこれら 2 つの数字と、ドキュメント内の AWS 署名を見ることで、この 2 つの側面について推論することができるわけです。
Nitro 上で実行されている、つまり AWS オペレーターがアクセスできない環境で実行されている、そして自分がビルドした正確なイメージで実行されているということが分かります。デフォルトで提供されるテンプレートにはオペレーターアクセスが全く含まれていないため、オペレーターアクセスを追加しなければ、オペレーターアクセスも含まれていない環境で実行されているということになります。
EC2 Instance Attestation の本当に素晴らしいところは、 EC2 インスタンスのすべての機能と性能を備えながら、これらすべてのプロパティを得られるということです。Elastic Network Adapter を使用できますし、Elastic Fabric Adapter を使用することもできます。インスタント ストレージを使用することもできますし、uranium のようなアクセラレーターも使用できます。好きなものは何でも使えます。EC2 で慣れ親しんでいるすべての機能が、Auto Scaling グループと同じように機能します。EC2 の観点からすると、これらのものは単なる AMI、つまり通常のマシンイメージです。
Nitro TPM attestation ドキュメントはこの 2 つの側面を証明します。Nitro スタック上で実行されており、AWS オペレーターアクセスがないことを証明し、自分がビルドした正確なイメージで実行されていることを証明します。私が話したインタラクティブアクセス、つまりオペレーターがデータを抽出する可能性がある場合は、当社のサンプルに従い、そのアクセスを追加しない限り、除外されます。そのアクセスがないことを知ることができ、キーハッシュを使用して再度それを証明することができます。Amazon Linux 2023 および NIOS 用のサンプル説明を提供しています。
この QR コードをスキャンすると、すぐに始められるウェブページに移動できます。ぜひやってみることをお勧めします。実は非常に楽しく、簡単にできます。この attestation は、リフト・アンド・シフトしたいアプリケーションがある場合に本当に役立ちます。アプリケーション全体を取得して、完全に attestation され、検証された EC2 インスタンスに配置すれば、正確に自分のコードで実行されていることが確実になります。
Nitro Enclaves：アプリケーションを信頼できる部分と信頼できない部分に分割する
ただし、私たちが持っている2番目のメカニズムがあります。それは Nitro Enclaves と呼ばれるものです。 Nitro Enclaves についてですが、これは私たちがかなり前からある機能なんですけど、Nitro Enclaves に詳しい人はいますか？EC2 インスタンスよりも手が上がってますね。Nitro Enclaves は私たちが最初に立ち上げた機能なんですが、実はある意味ではより複雑な機能なんです。
Nitro Enclave では、通常こんなふうに言うんです。自分のアプリケーションはいろいろなものから構成されている。サードパーティのアプリケーションがどこかで動いている。フルブローンのオペレーティングシステムがあって、いろいろなことをやっている。アプリケーションの大きな部分があって、ランダムなデータを処理したり、外部のエンティティと通信したりしている。そしてそれは完全には信頼できないかもしれない。でも、この小さなコードの一部があって、それを隔離したい、シールドしたい、そしてこの特定の小さなコードが、他の誰も他のものもアクセスできない環境で安全に動作していることを確認したい。それが Nitro Enclaves の目的であり、それが本当に輝く場面なんです。
アプリケーションを取って、アプリケーションを2つに分割したい、信頼できる部分と信頼できない部分に分割したいけれど、それでも一緒に動作する、手と手を取り合って単一のエンティティとして一緒に動作する場合は、Nitro Enclave がソリューションです。Nitro Enclave は、EC2 インスタンスのリソースから即座にスポーンできる小さな独立した仮想マシンを提供します。その後、エンクレーブ内で非常にセンシティブなデータを処理できます。
エンクレーブは親とのみ VSOC チャネルを使用して通信します。これは特別な低レベルのトランスポートのようなものです。これは、エンクレーブに出入りするすべての通信を啓発する必要があることを意味します。これは Nitro Enclaves の特別な特性であり、エンクレーブに出入りするすべての通信について常に推論できることを保証します。なぜなら、私が言ったように、親アプリケーションとエンクレーブの間でのみ通信するように構築されているからです。Enclaves は親の代わりに ISA 操作を実行したい場合の選択肢です。つまり、アプリケーションを2つに分割しているわけです。
エンクレーブを構築する場合、それは私が前に説明した画像と同じように見えます。イメージの説明にソースコード属性がある代わりに、ここでは実際のコンテナイメージ、つまり構築されたコンテナイメージを取得して、それを変換します。エンクレーブイメージファイル、つまり EIF ファイルを生成します。生成中または事後に、イメージのハッシュを生成して、後でブート時に何を期待するかを知ることができます。そのイメージから、Nitro Enclave も起動します。
Nitro Enclave を起動すると、Nitro ハイパーバイザーが実際のイメージのすべてのコンテンツをハッシュ化して 、PCR 値を提供します。その PCR 値は Nitro Enclave の attestation ドキュメントに入力されます。これは以前とまったく同じフローに従っています。実際の測定自体はもう少しシンプルです。なぜなら、ブートフローのチェーンを持つ代わりに、EIF ファイルを取得して EIF 自体をブートし、PCR ゼロ値をシードする Nitro スタックだけを持つからです。つまり、EIF ファイルのすべてのコンテンツです。もっと多くの PCR がありますが、興味があればオンラインで読むことができます。
これら 2 つの値、つまり Nitro Enclave attestation ドキュメント上の AWS 署名と PCR ゼロを使用することで、同じ 2 つの側面について推論できます。正確にあなたのイメージが実行されていることがわかります。つまり、VSOCK の背後に SSH サーバーを置かない限り、対話的なアクセスはないはずです 。そして Nitro スタック自体も、ドキュメントが Nitro attestation キーで署名されているからです。Nitro Enclaves は非常に便利な機能ですが、制限された機能セットを持っています 。CPU、メモリ、VSOCK だけが利用可能です。これは監査を劇的に簡素化します。なぜなら、環境の周囲にはたくさんのコードとアクセスメカニズムがないからです。
しかし、これはまた、例えば GPU にアクセスできないということも意味します。そのためには、EC2 Instance Attestation を代わりに使用することをお勧めします。なぜなら、通常の EC2 インスタンスと同じように、完全な環境を提供するからです。Nitro Enclaves の attestation ドキュメントは、Nitro と Nitro Enclave のブートコンテンツの両方を証明します。Nitro Enclave から外の世界と通信したい場合、KMS へのアクセスを含むすべてが VSOCK を通過します。セットアップは少し複雑かもしれませんが、通常はそれだけの価値があります。
マルチパーティ協業のデモ：LLMモデルオーナーとコンシューマーの課題を解決する
Nitro Enclaves は、親アプリケーションに依存するテスト済みで分離されたエフェメラルワークロードを実行したい場合に使用するものです。エフェメラルというのは、通常は永続ストレージがないからです。もう一度その上に構築しない限り 。実は、Sudhir が構築した本当にクールなデモアプリケーションがあります。彼は、私が今説明したすべてのテクノロジーを使用して、私が最初に話した初期の問題を解決する方法を示すつもりです。それは、どうすれば、あなたが私の AI モデルに対して可視性を持たずに起動して操作する環境を実行できるようにあなたに提供できるかということです。
あと数枚スライドがあると約束しますが、その後はコードに入るだけです。実は、EC2 Instance Attestation を使用して解決できるクールなユースケースの 1 つを見てみましょう 。これは一例です。ちなみに、次の数分間に示すすべてのことについて、あなたも一緒に進めることができます。QR コードと、私が示すサンプルアプリケーションを取得してください。コードサンプルは、Alex が言及した KIWI-NG と NX というツールを使用して、サンプルアプリケーションを attestable AMI にパッケージ化する方法を示しています。すべてがすでにオープンソースなので、これらの QR コードを取得してください。
では、サンプルアプリのセットアップについて説明します。繰り返しになりますが、これは最初の Alex の説明を続けたものなのですが、皆さんが AI/ML モデルのオーナーだと想像してください。ここでは LLM モデルのオーナーの例を挙げます。生成 AI アプリケーションについて話しましょう。例えば、私がドメイン固有の LLM モデルをファインチューニングして、その後、顧客にそれを使ってもらいたいというビジネスをしているとします。私はそれらの LLM モデルのファインチューニングとトレーニングにかなりの量のリソースを投資しています。では、顧客が私の LLM モデルを使用できるようにしながら、モデルの重みの流出について心配しないようにするにはどうすればよいでしょうか？これは、モデルのオーナーとして軽減したい可能性のある脅威を見る一つの方法です。
同様に、モデルの消費者、つまりこのマルチパーティ協業セットアップのもう一方の側は、別のことについて心配するでしょう。実は、プロンプトやクエリ、あるいは大規模言語モデルに提供するコンテキストで、非常に機密性の高いデータを送信しているとしたらどうでしょうか？最近では、LLM に送信するものを充実させて、LLM からより文脈に適した回答を得たいというのは非常に一般的です。組織のデータ、エンタープライズデータ、個人情報など、様々なものを送信するかもしれません。つまり、非常に機密性の高いデータが送信されており、相手方がそれを流出させることができないようにしたいというユースケースがあるわけです。
これを解決する一つの方法があります。非常にシンプルなセットアップを見てみましょう。
デプロイ方法はこのようになります。これが AWS で LLM モデルを使用する唯一の方法だと言っているわけではありません。他のサービスもありますが、この会話の目的のために、暗号化アテステーションと Amazon EC2 インスタンスについて話しているので、LLM モデルをホストする一つの方法はこのようになります。モデルサーバーを使用して提供され、その後、その LLM API を使用している UI またはフロントエンドがあります。ここまでは良いですね。これは、マルチパーティ協業と呼ぶものの古典的でシンプルな例です。これはマルチパーティ競争ではなく、マルチパーティ協業です。ここには 2 つのパーティがあります。LLM モデルを所有するパーティと、LLM モデルを使用するパーティです。
このことについてのスライドがあると思います。そこです。説明したように、LLM モデルを使用するパーティは、LLM モデルに提供されている特定のものを保護したいと考えています。もう一方のパーティはモデル自体を保護したいと考えています。このようなパターンに対してどのように対処しますか？ここに別のビジュアルがあります。 プロンプトとクエリが機密であることを示しています。LLM モデルは LLM モデルを所有するパーティの知的財産であるため、それも機密です。
さらに多くのパターンがあります。これが唯一の解決策というわけではありません。もっと多くのデザインパターンと生成型アプリケーションがあって、アプリケーションのコンポーネントをスタックして、プロンプトと機密情報を匿名化または仮名化してから LLM モデルに送信することができます。RAG コンポーネントを持つことができて、それが追加のコンテキストを追加します。これはおそらく保護したいものです。なぜなら RAG は組織の情報にアクセスできるからです。もっと多くのことがあります。推測することはできますが、このような問題を解決するための基本要素は同じままです。
これらの基本要素を見てみましょう。 まず最初に、モデルオーナーとして、LLM モデルの重みを暗号化したいと思うでしょう。 AWS KMS または独自のキー管理システムを使用したエンベロープ暗号化と呼んでいます。それを他の当事者に公開する前に。思い出してください、私たちは問題ステートメントから始めました。顧客に機密データを送信するよう求める代わりに、なぜデプロイメントトポロジーを反転させて、LLM モデルの重みをパッケージ化して、顧客の AWS アカウントまたは消費ポイントで実際にデプロイできるようにしないのかということです。
LLM モデルへの入力として送信される機密情報は、そのままの場所に留まります。それが属する AWS アカウントの境界を超えることはありません。エンベロープ暗号化は、LLM モデルの重みをコンシューマーが利用できるようにパッケージ化する1つの方法です。しかし、次のステップが最も重要なステップです。単に暗号化するだけでなく、機密コンピューティング環境について話しているので、そして attestation という素晴らしいツールが自由に使えるので、Alex のトークで見た測定値にモデルの重みをシールします。
これらの測定値は、機密コンピューティング環境、構築した分離されたコンピューティング環境を表しています。ビルドフローを実行して、attestable AMI を構築しました。ビルドプロセスから出てくる1つのことは、この AMI を表す測定値です。ここで、実行環境、EC2 インスタンスを想像してください。これも attestation ドキュメント内で同じ測定値を提示します。モデルオーナーとして、私がすることは、暗号化するだけでなく、モデルの重みをシールして、その attestation ドキュメント内で同じ測定値を提示する実行環境でのみアンシールされるようにすることです。
実際にサンプルアプリケーションを見てみましょう。デザインパターンと基本要素は十分です。これらの基本要素とデザインパターンがどのようにサンプルアプリに結果をもたらしたか、そしてそれを EC2 インスタンスとしてパッケージ化してデプロイする方法を実際に見ます。instance attestation を使用して、これが機密コンピューティング環境になります。ここを見てください。 確認してください。これの一部が明確に読めない場合は知らせてください。
サンプルアプリケーションの実装：暗号化されたMistral 7Bモデルの配信と検証
では、まず最初にサンプルアプリ自体をちょっと見てみましょう。
ここがサンプルアプリです。今のところ大丈夫そうですか？ズームアップしてほしいですか？ちょっとズームアップしてみますね。これは先ほどスライドで見たのと同じコンセプトです。ここに2つのパーティがあります。一方のパーティはモデルオーナーで、もう一方はモデルコンシューマーです。モデルオーナーはモデルの重みを暗号化してシールし、それをモデルコンシューマーに公開したいと考えています。ここで言っているのはインスタンスアテステーション付きのEC2インスタンスのことです。彼らはそれを消費したいので、このEC2インスタンスに、つまり私たちがこのEC2インスタンスにパッケージ化するアプリケーションに推論リクエストを送信することになります。すると、チャットインターフェースが出てきて、それとチャットすることができます。
どのように組み合わさるのかをお見せしましょう。このデモの目的のために、私たちはいくつかのコンセプトを簡略化しました。非常にシンプルにしました。実は、サンプルアプリケーションのフロントエンドとバックエンドの両方を同じEC2インスタンス内で実行しています。これは決して良いアーキテクチャではありません。これらのコンポーネントを、それぞれ独自の実行環境、独自のアテステーション、独自のメジャーメントを持つ環境に分割することもできます。それを妨げるものは何もありませんが、これは単に簡潔さのためです。
ここに2つのビューがあります。これは LLM モデルオーナーとしての私ができることです。先ほど述べたように、モデルの重みをエンベロープして暗号化し、それを公開してシールすることができます。Hugging Face で入手可能なオフザシェルフの LLM モデルの重みを使用するつもりです。これらが私の知的財産、高度に微調整されたドメイン固有の LLM モデルなどであると想像してください。この LLM モデルの重みを KMS キー ID を使って暗号化し、S3 バケットに公開するつもりです。
ローディングのデモで退屈させたくないので、ここに座ってそれを見ていてほしくありません。実は、すでに公開してしまいました。ここにあります。暗号化されたモデルの重みで、この場合は Mistral 7B モデルです。ディスク上では約 4 ギガバイトです。また、これはエンベロープ暗号化の素晴らしく重要な部分ですが、バッキング KMS キーがあります。これが、この ID が表すものです。舞台裏で行ったことは、データキーを生成したことです。これがエンベロープ暗号化の基本です。マスターキーを使ってデータキーを生成し、そのデータキーを使って GGUF ファイルを暗号化します。コンシューマーに公開するのは 2 つのものです。1 つは暗号化された GGUF ファイルで、ここで見えているものです。GGUF は LLM モデルの重みの 1 つの表現に過ぎず、他にもいくつかあります。簡潔さのために、私のシンプルな LLM サーバーである Ollama が提供できる最も一般的なフォーマットを使用しました。詳細は後で見ますが、はい、これが公開する 2 つのものです。暗号化された LLM モデルの重みと、LLM モデルの重みを暗号化するために使用した暗号化されたデータキーです。
これまで LLM モデルのオーナーとして、私たちがやってきたことは 1 つ、つまりモデルの重みを公開することです。では、シーリングのステップに進みますが、 この KMS キー ID を使用します。ここで attestation が登場します。実は、sealing モデルに入る前に attestation をお見せしましょう。PCS が何かと疑問に思っているかもしれません。EC2 インスタンスの attestation タブに行くと、attestation ドキュメントがどのような見た目かについて、かなり高レベルまたは詳細なビューが表示されます。 これは NitroTPM によって生成された attestation ドキュメント、つまり EC2 インスタンスの attestation ドキュメントです。 これには、皆さんにとって興味深いかもしれないいろいろなものが含まれています。その 1 つが nonce です。 nonce は通常、セッションで freshness を保つために使用されます。同じ attestation ドキュメントが再生されないようにしたいだけです。しかし重要なのは、重要なことの 1 つは PCR 値です。
PCR が何であるか、そしてそれらのいくつかがビルドプロセスからどのように出力されるかについては、先ほど説明しました。興味深いものをお見せします。PCR 4、PCR 7、これは secure boot ポリシーを実行するもの、そして重要なことに PCR 12 もあります。 これらはおそらく、最低限でも attestation ドキュメント内で検証して調査したい 3 つのことです。 attestation ドキュメント自体の整合性を検証するためにも重要な他のいくつかのことがあります。それが、ここに示しているサーティフィケートチェーンです。
まず、TPM 自体を表すリーフサーティフィケートが何かというところから始めます。 この attestation ドキュメントに署名したルートサーティフィケートまで、すべての方法で。EC2 インスタンスが attestation ドキュメントを提示している場合、 署名を検証して、それが本物の Nitro による署名付き attestation ドキュメントであることを確認してから、これらの PCR を使用して推論を行いたいでしょう。
これらが重要な理由は、まさにこれが私たちがやっていることだからです。verification、semantic validation、certificate chain validation という名前のものがあることをお見せします。 非認証化のようなもの、そういったものは、このサンプルアプリケーションではすべて通過しました。しかし、今、モデルのオーナーとして、LLM モデルの重みを暗号化するために所有して使用している KMS キーに行くと、 体験がどのように見えるかを示します。 いくつかの部分は事前に行いましたが、この KMS キーの KMS キーポリシーがあります。ここで、単純に条件を追加しました。これは、Nitro enclaves に対して行ったのと同じように、EC2 インスタンス attestation と AWS KMS の out-of-the-box 統合を行ったからです。このインスタンスまたはこの confidential computing 環境とインターフェースしたい独自のマイクロサービスや他のコンポーネントに対して、まったく同じことを行うことができます。何も止めるものはありません。
これが単純な理由は、out of the box で行ったからです。KMS キーポリシーを使用すると、単純に条件を追加することができます。それは、このアクション、つまり decrypt を許可するだけということです。顧客の観点から GGUF または LLM モデルの重みを復号化しようとしているからです。オーナーとして、これらの正確な PCR 値を提示する EC2 インスタンスからリクエストが来た場合にのみ、モデルの重みに対して decrypt を許可するつもりだと言っています。attestation ドキュメントを提示しない通常の EC2 インスタンスから decrypt リクエストを発行しようとすると、単純に失敗します。それだけです。
では、これでモデルオーナーとしてお客様に利用してもらう前に必要なことが完了しました。実際にお客様をオンボードする方法や、お客様とのハンドシェイクの詳細については説明しませんが、つまり、お客様に対して「これが信頼する必要がある PCR 値です、そしてこれが私がこの環境を構築するために使用したレシピです」と伝えるプロセスですね。そういったことはすべてお客様のオンボーディングの一部となり、ハンドシェイクをどのように確立するかによって異なります。しかし、シンプルなレベルでは、こんな感じになります。
では、コンシューマーの観点からは、私はこのようなことをします。繰り返しになりますが、サンプルアプリケーションは単に使いやすくしているだけで、プリミティブは同じです。ここで私がやっていることは、パブリッシャーが暗号化されたファイルが利用可能な S3 バケットをくれたので、それを指します。パブリッシャーから提供された KMS キー ID を使用して、復号化を許可してくれるかどうかを尋ねます。これらのステップを実行します。暗号化されたファイルをダウンロードして、データを復号化しようとします。キー。正しい attestation ドキュメントと正しい PCR 測定値を提示したため、データキーの復号化が成功した場合、実際のモデルウェイトを復号化する機会が得られます。
これにも時間がかかります。ここでライブでやるつもりはありませんが、最終的な結果はEC2 インスタンス内でローカルに実行されている Ollama サーバーに LLM をロードすることになります。さらに、これが行うことは、サンプルアプリに組み込んだ機能ですが、LLM モデルのコンシューマーとして、特定のモデルと話していることを確認したい場合、単なる他の LLM ではなく。この場合、脅威モデルが「Mistral 7B と話していることを確認してください、他の LLM モデルではなく」と言っている場合、私がやっていることはモデルウェイトをハッシュして、それらのハッシュを利用可能な PCR の 1 つに拡張することです。この場合、実際に PCR 15 にハッシュしています。
それはどういう意味ですか？attestable AMI の特定の興味深いプロパティを追跡する既製の PCR レジスタがあり、それは PCR 4、7、12 などです。しかし、お客様のワークロードにとって興味深いものを測定し、attestation ドキュメント内の利用可能な PCR プラットフォーム構成レジスタの 1 つを Nitro TPM で使用する柔軟性があります。
それらを拡張して、後で検証できるようにします。私が示した例の 1 つは LLM モデルハッシュでした。もっと多くあるかもしれません。合計で、約 24 個のPCR レジスタがあります。それらの一部は予約されており、一部はお客様独自のカスタムハッシュに使用できます。これにより、コンシューマーの利用体験がどのようなものかがわかります。繰り返しになりますが、パブリッシャーとコンシューマーの両方の体験はattestation ドキュメントが AWS KMS とのハンドシェイクで交換されるという事実に基づいています。しかし、アーキテクチャの他のコンポーネントでもまったく同じことができます。
マイクロサービスがあって、マイクロサービス A がマイクロサービス B とこのアテステーション ハンドシェイクを行いたいとしましょう。両者がアテステーション ドキュメントを交換して、作業を完了することができます。これが基本的な考え方です。ここで、私たちが言及した機能の 1 つをお見せします。 エンクレーブとは異なり、アタッチされた GPU を使用する機能があります。これはまさに私がここでやっていることです。この特定のインスタンスでは、 G5 インスタンスにデプロイしました。これにより NVIDIA A10G 環境が得られます。 つまり、そのような追加機能があるわけです。どのパスを選ぶかという選択、エンクレーブにするか EC2 インスタンス アテステーションにするか、その決定は一方と他方で利用可能な機能に基づいて行うことができます。
KIWI-NGとNixによるパッケージング：attestable AMIとEnclave環境の構築方法
これがサンプル アプリケーションについての簡単な説明です。では、パッケージング自体の詳細に入りましょう。 ちなみに、QR コードを取得したら、サンプル アプリケーションに移動して、各 UI コンポーネントとバッキング API がエンドツーエンド暗号化やアテステーション ドキュメントの取得などをどのように実装しているかを確認できます。 では、サンプル アプリケーションが EC2 インスタンスにデプロイされた結果である KIWI レシピをお見せします。ここでいくつかの主要な機能を指摘します。KIWI レシピを見ると、KIWI には どのパッケージを AMI に含めるべきか、どのパッケージを無視すべきかを指定する独自の宣言的な方法があります。ここでお見せする 1 つのことは、これらの数行のコードです。
私たちが現在見ている多者間協業の問題を解決するための興味深いプロパティの 1 つは、サンプル アプリケーションが顧客のアカウントでホストされているということです。これは、顧客がアクセスできず、モデルの重みを流出させる可能性がない隔離されたコンピュート環境にしたいのです。彼らができることは、API を使用して LLM モデル サーバーを使用して LLM モデルを使用することだけです。私にとって興味深いのは、これらのプロパティを追加したいということです。「KIWI よ、このために AMI をビルドするときは、これらのパッケージを絶対に含めないようにしてくれ」と言っているわけです。これが ignore ステートメントが言っていることです。インタラクティブ アクセスは一切できないようにしていると言っています。 EC2 Instance Connect、Systems Manager コンソール、SSM セッション アクセスを提供する SSM エージェント、OpenSSH、SSHD など、EC2 インスタンスへのすべてのインタラクティブ パスは、これらの数行のコードで軽減され、削除されます。
サンプル コードで再度確認できます。このコードの QR コードもお見せします。ここで、必要なすべてのパッケージを指定しています。TPM 2 tools、 AWS Nitro TPM tools など、アテステーション ドキュメントを取得したり、PCR を拡張したりするために必要なパッケージが見えます。 これが、先ほど見たサンプル アプリケーションをもたらした KIWI レシピについての説明です。同じサンプル アプリケーション は、Nix を使用してアテステーション可能な AMI としてもパッケージできます。Nix はマシン イメージをビルドするもう 1 つの方法です。 KIWI とは異なり、Nix は再現可能なビルドを行うことができるという非常に重要で興味深いプロパティを提供します。つまり、Nix が作成したサンプル アプリケーションをお見せします。異なるツールを使用してパッケージングしているだけなので、見た目と感じは同じになります。アプリケーションは同じです。異なる方法でパッケージングして、アテステーション可能な AMI を生成しているだけです。バリエーションを示すために、Nix レシピで行ったことは、すべての GPU ドライバーを削除しました。
ここでの意図は、GPU がアタッチされていない CPU のみのインスタンス タイプに同じサンプル アプリケーションをデプロイすることです。 環境を見ると、GPU がないことがわかります。考え方は、同じサンプル アプリケーションを AMI にパッケージできて、正しい方法でビルドすれば、複数のインスタンス タイプにデプロイできるということです。NitroTPM ドキュメントを見ると、ワークロードに適したサイズに合わせるために利用可能なインスタンス タイプが多くあることがわかります。エンクレーブもワークロードに必要な CPU とメモリを提供する柔軟性を提供します。これはすぐに確認します。サンプル アプリケーションは同じで、アテステーション ドキュメントも同じに見えます。これも NitroTPM アテステーションだからです。ただし、レシピを見ると、少し異なります。 コードの興味深い部分をいくつかお見せします。 これは言及する価値があります。KIWI-NG では、サンプル アプリケーションを AMI にベイクする方法は、overlays と呼ばれるものを使用することでした。KIWI に対して、ここに私のサンプル アプリケーションがあります。おそらく別の GitHub リポジトリにあります。それを取得して、レシピがある基本イメージの上に重ねて、その後 AMI を出力してくれと言いました。 サンプル アプリケーションはベイクされています。Nix では、少し異なります。 Nix では、Nix Flake と呼ばれるものを書き出す必要があります。ここで、アプリケーションをパッケージしてビルドする方法を Nix に伝えます。 Nix の場合、フロントエンドのビルド方法、バックエンドのビルド方法をここで指定して、実行してくれと言っています。Nix は KIWI-NG と同じことをします。AMI を作成するとともに、後でアテステーションで使用できる PCR のセットを提供します。
では、パズルの最後のピースを見てみましょう。同じサンプルアプリケーションを Enclave 内で実行するようにパッケージ化することです。 これは事前に済ませておきました。 Nitro Enclaves に関しては、セマンティクスが少し異なります。Enclave 用にアプリケーションをパッケージ化する方法に違いがあり、attestation にも違いがあります。 こちらが Nitro Enclave の attestation ドキュメントです。似ているように見えるかもしれません。nonce、module ID、user data、public key などはまだあります。PCR もありますが、これらの PCR は異なる意味を持っています。例えば、PCR 0 は Nitro Enclave イメージ全体のハッシュです。 より高次の PCR の 1 つを取得しました。この場合、モデルを複数回ロードしたようなので、PCR 16 から 22 までのどこかを取得して、モデルの重みのハッシュで拡張しました。つまり、Nitro Enclaves でも、PCR を使用してワークロード内で興味深いものを測定および拡張する機能が得られます。同じ証明書チェーンがあり、attestation に関してはそれくらいです。Enclave attestation に関しては、attestation 内のほぼすべての他の概念は同じままです。 モデルオーナーとコンシューマー、これらの機能は何も変わりません。
では、Enclave に関して何が異なるかを見てみましょう。vSOC について言及しました。Enclave で得られるもののひとつは、ENI が接続されていないということです。 外部世界と通信したい場合、KMS と通信したり、S3 からモデルの重みを取得したり、最終的に API、つまり LLM を提供する OpenAI API をフロントエンドに公開したりするには、すべてのためにプロキシが必要です。これがこのアプリケーションをパッケージ化する際の 1 つの違いです。もう 1 つの違いは、Enclave を書き出すときに、ブートストラップスクリプトを与える必要があるということです。Enclave 内でこの特定のアプリケーションをどのように実行するかを指定する必要があります。 そのために、追加のスクリプトがあります。これらはいくつかの違いですが、ここでのアイデアは、attestation 機能を使用して解決しようとしていた同じアプリケーション、マルチパーティコラボレーションアプリケーションを、これらの両方の環境に対して使用できるということです。 Nix と KIWI-NG を使用してそれをパッケージ化して EC2 Instance Attestation を使用する方法を見てきました。また、Nitro Enclaves 用にパッケージ化する方法も見てきました。
これがデモの部分です。後でこの正確なアプリケーションに従うことができるように、QR コードをいくつか残しておきます。 プレゼンテーションに戻ります。 こちらが KIWI-NG の QR コードです。これにより、サンプルアプリケーションを取得して、KIWI-NG を使用して attestable AMI にパッケージ化する方法を示すサンプルパッケージングコードが得られます。 こちらは GitHub リポジトリでも利用可能なクイックアーキテクチャです。スクリーンショットを撮る心配はありません。 こちらが次のサンプルリポジトリです。これは、あなたが見たのと同じサンプル MPC アプリケーションであり、これにより、どのように進めるかを示す次の flake が得られます。
ちなみに、これをワークショップにパッケージ化しました。attestable AMI を実際に構築する方法を学ぶことに興味がある場合は、明日のセッション CMP 410 があります。これは短い suite builder セッションです。興味があり、attestable AMI を構築する方法についてのハンズオントレーニングを受けたい場合は、ぜひ参加してください。あなたが見たばかりの正確なサンプル PC アプリを使用します。 最後に、Nitro Enclaves ソリューションがあります。 この QR コードは、Nitro Enclaves を使用して LLM モデルの重みを提供する方法を示すハンズオンワークショップにつながります。これが私のデモの終わりです。
これにより、EC2 環境でさまざまなメカニズムを使用して機密コンピューティングを行う方法を学びました。 アンケートを見て、ぜひ記入してください。私たちがどのようにしたかをお知らせください。これで質問を受け付けます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion