Fortanix Confidential Computing ManagerとRuntime Encryption™（RTE）を使用したセキュアコンテナの管理
問題：クラウドにおける信頼性と完全性
コンテナベースのソフトウェア開発と展開は、次の大きな技術トレンドとなっています。Dockerのようなコンテナ技術はクラウドコンピューティングを再定義し、企業や開発者に一貫性、信頼性、効率性、コスト削減、そしてDevOpsプロセス全体にわたるスケーラビリティなど、非常に大きなメリットを提供します。しかし、Dockerを使って大規模に機密性の高いアプリケーションを運用する企業にとって、クラウド上のコンテナのセキュリティ確保と完全性の維持は重要な課題です。
現在、「静止データ」と「転送中データ」の保護に関しては、さまざまな暗号化方式や戦略があります。しかし、より大きな疑問があります：「使用中のデータ」はどうでしょうか？
データが静止時やTLSのような安全なチャネルを通じて交換される際に慎重に保護されていても、使用中やマーシャリング中にはデータは復号されます。これにより、ソフトウェアコンテナは悪意ある攻撃者にとって良い攻撃対象となります。現在のコンテナセキュリティ技術では、OS、ハイパーバイザー、またはルート権限で動作するその他のソフトウェアの脆弱性を防ぐことはできません。
Intel® Software Guard Extensions
Intel® Software Guard Extensions（SGX）は、ソフトウェア開発者が実行時にアプリケーションのデータを暗号化できる技術です。これは、アプリケーションが「エンクレーブ」と呼ばれる特別な保護されたソフトウェアコンテナを起動できるようにすることで実現されます。これらのエンクレーブは、ルート権限を持つ攻撃者やメモリバスへの物理的アクセスを持つ者からアプリケーションのデータを保護するために使用されます。
SGXエンクレーブ内でセキュリティクリティカルなサービスを実行することは、開発者に様々な課題をもたらします：
- SGXで実行する際にはシステムコールの代わりに「OCALL」を行うため、エンクレーブ内で動作するアプリケーションは大幅なリファクタリングが必要であり、JavaやPythonのような高水準プログラミング言語で書かれたアプリケーションではほぼ不可能です。
- アプリケーション（またはその機密部分）をエンクレーブ内で実行するだけでは不十分です。SGXのセキュリティ保証を完全に活用するには、ユーザーは自分が構築したアプリケーションが改変されずに安全なエンクレーブ内で動作していることを検証する必要があります。Intelはリモート認証を用いてこれを実現する方法を提供しています。
Intelのリモート認証は複雑なフローであり、使いやすさに関する課題もあります：
- マイクロサービスのインスタンスがデプロイされるたびに、リモート認証のフローを繰り返す必要があり、その中にはIASへの外部呼び出しも含まれます。
- ほとんどのマイクロサービスは機密情報の交換にTLSを使用しています。SGXのセキュリティ保証を活用するためには、TLSスタックもSGX認証を検証する必要があります。
- IASのAPIが変更された場合、すべてのアプリケーションエンクレーブをアップグレードする必要があります。また、監視・制御サービスもSGX認証を検証する必要があります。
- IASは登録ユーザーによって署名された安全にデプロイされたエンクレーブを認証します。ユーザーがエンクレーブがサービスのクラスタに参加する際のポリシーを制御したい場合は、追加のインストルメンテーションが必要です。
ソリューション – Fortanix コンフィデンシャル・コンピューティング・マネージャー
Fortanix Runtime Encryption技術により、アプリケーションを変更せずにSGXエンクレーブ内で実行できます。さらに、Fortanix Confidential Computing Managerは、上記のすべての課題を数回のクリックで解決するのに役立ちます。Confidential Computing Managerが提供するものと、そのサービスを利用する際のユーザーフローを見てみましょう：
Confidential Computing Managerノードエージェントはユーザーのノードに展開されます。これにより、ノードが必要なセキュリティクリティカルなマイクロコードパッチがすべて適用された有効なSGXマシンであることが保証されます。
- Confidential Computing Managerコンバーターは、ユーザーが数回のクリックまたはAPIコールでアプリケーションコンテナをSGX環境内で実行できるように変換します。
- 変換されたアプリケーションが展開されると、RTEとEMは自動的にローカル認証を行い、各アプリケーションごとにIASを呼び出すことなくTLS証明書を提供します。X.509証明書を使用したTLSは広く使われているプロトコルであるため、マイクロサービスはConfidential Computing Managerのルート証明書を信頼のルートとして使用し、暗号スタックを変更することなくエンクレーブ間の安全な通信を実現できます。これにより、安全なSGX環境で実行されているエンクレーブのみが必要なTLS証明書を取得できることが保証されます。
- Confidential Computing Managerはまた、証明書発行前にエンクレーブの測定値（特にロード時のエンクレーブメモリのハッシュ）がホワイトリストに登録されていることを要求し、ユーザーが展開を意図したエンクレーブのみがTLS証明書を発行されるようにします。エンクレーブが意図した通りに展開されたことが保証されると、プロセッサハードウェアはエンクレーブが改ざんされず、実行時のメモリが読み取られないことを保証します。
- RTEエンクレーブは、Confidential Computing Managerバックエンドに対して定期的にハートビートを送信し、安全な監視を行うこともできます。
以下にConfidential Computing Managerの使用の大まかなフローを示します：
1. ユーザーがConfidential Computing Managerを展開します。
- 展開時に、バックエンドエンクレーブはIAS認証を取得し、それを用いて高可用性サービスクラスター（マルチノードバックエンド展開用）を安全に確立します。
- バックエンドは、ノードの有効なIAS認証を取得できた場合、ノードエージェントの各インスタンスにX.509証明書を発行します。このフローはノードプロビジョニングと呼ばれ、ノードエージェントプロセスのライフサイクル中に一度だけ行われます。
- ノードプロビジョニングは展開後に自動的に行われます。
2. ユーザーはUIまたはConfidential Computing ManagerのAPIを使ってエンクレーブをホワイトリストに登録し、その後展開します。
3. アプリケーションエンクレーブはノードエージェントと通信してローカル認証を取得し、バックエンドサービスが検証した後にTLS証明書を発行します。EnclaveOSを使用して展開されたエンクレーブの場合、このフローは自動化され、証明書関連のマニフェストオプションでトリガーされます。
4. アプリケーションエンクレーブは、エンクレーブ内で署名された定期的なハートビートを提供して安全な監視を行うことも選択できます。EnclaveOSアプリケーションの場合、これはアプリケーションマニフェストのハートビート関連オプションでトリガーされます。
