Text＝上田 陽平、稲垣 達氏 日本IBM
クラウドのセキュリティを向上させる新技術であるコンフィデンシャル・コンピューティングが注目されている。本稿ではIBM Secure Executionを例にコンフィデンシャル・コンピューティングがどのようにクラウド上のデータを保護するか、その仕組を紹介する。
クラウドでのデータ保護の重要性
近年、従来のオンプレミス環境から、クラウド・ネイティブ・コンピューティングと呼ばれるアジャイル開発による高い生産性とスケーラブルで堅牢なアプリケーションをクラウド上で構築・運用するアプリケーション・アーキテクチャへの移行が加速している。
しかし、一部のアプリケーションの開発者や運用者はクラウド・ネイティブへの移行を実現できていない。クラウドへの移行をためらう大きな理由の1つとなっているのがセキュリティに対する懸念である。アプリケーションが取り扱う個人情報などの機微情報やビジネス価値に直結する機密情報などは、データ流出を引き起こす攻撃から保護される必要がある。そういったデータを組織外部のクラウドで安全に保存・利用できる仕組みが既存のクラウドに備わっておらず、特に重要なデータを扱うアプリケーションのクラウド移行が進まない要因の1つとなっている。
データ流出を引き起こす攻撃は、ソフトウェアの脆弱性等を利用した外部からの攻撃と、内部のシステム管理者がアクセス権限を悪用してデータを窃取する内部からの攻撃が考えられる。外部からの攻撃はオンプレミス環境であってもクラウド環境であっても十分な対策が必要である。一方、内部からの攻撃への対応は、組織外のクラウド・プロバイダーが運用するクラウド環境においては、特に対策が難しい領域となっている。このクラウド管理者からの攻撃の懸念を抜本的に軽減する仕組みがクラウドに求められている。
アプリケーションが取り扱うデータは、(1) Data at rest、(2) Data in transit、(3) Data in use に大別される。Data at restはディスク装置などのストレージに保存されるデータであり、ディスクやファイル、データベースの暗号化技術によって保護される。Data in transitはネットワーク通信で伝送されるデータのことであり、Transport Layer Security（TLS）やSecure Shell（SSH）などの通信暗号化技術によって保護される。Data in useは、実行中のアプリケーションが利用しているデータのことであり、主にメモリ上に保存されているデータである。
従来のクラウド環境ではData at restとData in transitの保護は行われるが、これらの保護だけでは悪意のあるシステム管理者がData in useにアクセスしてしまう攻撃を防ぐことはできない。
次に、クラウドで用いられているワークロード仮想化技術を紹介し、なぜ既存の仮想化技術がData in useを十分に保護できないかを解説する。
コンテナ技術はクラウド・ネイティブ・コンピューティングを支える基礎技術であり、アプリケーションを隔離して実行できることから、クラウドセキュリティを担保する要素技術となっている。しかし、従来のコンテナ技術は、(1)コンテナからホスト側への攻撃および(2)コンテナから他のコンテナへの攻撃を防御するが、(3)ホスト側からコンテナへ攻撃に対してアプリケーション側を保護する仕組みはない。このため、コンテナ技術によってクラウド管理者によるアプリケーションのデータの窃取を防ぐことは難しいと考えられる。
たとえば、DockerやKubernetesで標準的に利用されているruncと呼ばれるコンテナ技術は、ネームスペースやcgroupsといったLinuxオペレーティングシステムの機能を利用してコンテナ隔離を実現している。これらの保護技術の組み合わせにより悪意のあるコンテナ・アプリケーションからホスト側のオペレーティング・システムや同じホストで稼働している他のコンテナを保護している。この保護の仕組みは一方向のみであり、ホスト側からの攻撃は防ぐことはできない。
より高いコンテナ隔離を実現するために、ハイパーバイザー技術を利用したコンテナも提案されている。Kata Containersはそういったハイパーバイザーを利用したコンテナ技術であり、コンテナのアプリケーションは仮想マシンのゲストOS内で稼働する。このハイパーバイザーを利用した手法はruncなどのプロセスを利用したコンテナ技術と比べて、より高いアプリケーション隔離を実現すると考えられるが、依然としてホスト側のシステム管理者からの攻撃には脆弱である。仮想マシンで稼働するゲストOSはホストOSからみると通常のプロセスであり、ホストOSの特権ユーザーはゲストOSのメモリ空間にアクセス可能である。そのため、悪意のあるシステム管理者はコンテナが利用するデータにアクセスできてしまう。
コンフィデンシャル・コンピューティングとは
コンフィデンシャル・コンピューティングとは、アプリケーションが処理中のデータ (Data in use)を主にハードウェア支援によるTrusted Computing Environment（TEE）によって直接的に保護する技術である。既存のコンテナやハイパーバイザー技術だけでは防御できなかったホスト側からの攻撃に対してデータを保護することを目的としている。
コンフィデンシャル・コンピューティングでは、ハードウェア・ベンダーを信頼することは依然として必要であるが、適切に用いれば悪意のあるシステム管理者からデータを保護することが可能となり、クラウドでアプリケーションを稼働させる際の攻撃ベクトルを削減できる。
コンフィデンシャル・コンピューティングを実現する手法は既に各社から提案されており、下記の表は各社の最新プロセッサで利用可能なコンフィデンシャル・コンピューティングの実現するためのハードウェア支援機構の例である。
Intel SGXはプロセス単位でのコンフィデンシャル・コンピューティングの実装である。プロセッサの支援により特定のプロセスのメモリエリアを他のプロセスから参照されるのを制限する機能を提供する。プロセスを用いたコンテナ実行環境で利用することができ、コンテナ管理システムとの親和性も高く、商用でのクラウドサービスの提供もなされている。しかし、プロセスのメモリサイズの制限など制約が多く、大規模アプリケーションを稼働するためのクラウド・コンテナ・サービスとしては広くは利用されていない。
一方、AMD SEV、Intel TDX、IBM Secure Executionなどは、プロセス単位ではなく、ハイパーバイザー技術を用いたコンフィデンシャル・コンピューティングの実装である。ホストOSが提供するハイパーバイザー機能を利用して仮想マシンを作成し、ゲストOSを稼働させる構成となっており、ハードウェアによるメモリ保護機構や暗号化により、ホストOSからゲストOSのメモリ領域へのアクセスを制限している。たとえホストOS側のプロセスが特権モードであったとしても、ゲストOSのメモリ上のデータにはアクセス不可能となっている。
ハイパーバイザー技術を用いたコンフィデンシャル・コンピューティングでは、ホスト側からの攻撃を防ぐために、仮想マシンのディスクイメージ自体も暗号化や電子署名などの対策がされている必要がある。この暗号化されたディスクイメージから仮想マシンをセキュアにブートするには、ハードウェアの支援が必要になる。IBM Secure Executionを例にその仕組みを以下に紹介する。
IBM Secure Executionの仕組み
IBM Secure Executionとは最新のIBM Zプロセッサで利用可能なIBMによるコンフィデンシャル・コンピューティング技術の実装で、IBM z15以降の世代のプロセッサを搭載するIBM Zサーバーで利用可能である。IBM Zサーバーにはホストキーとよばれる公開鍵暗号の鍵ペアが紐付けられており、工場での生産時に物理サーバー1台ごとに異なるホストキーが生成される。ホストキーの秘密鍵は、耐タンパー性のあるハードウェアによって保護された領域に保存されていて、サーバーの外部に取り出すことはできない。一方、ホストキーの公開鍵は、電子証明書の形式でIBMのWebサイトで公開されており、サーバーのシリアル番号を指定して誰でもダウンロードすることができる。
ホストキーの公開鍵は、Secure Execution Headerと呼ばれる仮想マシンの起動に必要なデータを含むファイルの暗号化に用いられる。Secure Execution HeaderにはLinuxのカーネル・イメージおよびInitial RAM Filesystemイメージ、カーネル・パラメーターの情報が含まれている。さらに、ルート・ファイルシステムを含むディスクイメージを暗号化するための鍵を含めることもできる。ホストキーはサーバーごとに異なるため、Secure Execution Headerはデプロイ対象のサーバーに合わせて用意する必要がある。
IBM Zサーバーのディスク上に保存されたSecure Execution HeaderはQEMU/KVMの仮想マシンとして起動することができる。Ultravisorと呼ばれる特殊なファームウェアがサーバー内部に保存されているホストキーの秘密鍵を利用してSecure Execution Headeを復号し、平文でメモリ領域に展開する。この時、仮想マシンのメモリ領域はメモリ保護機構により保護されるため、ホスト側のプロセスは平文のSecure Execution Headerの内容にアクセスすることはできない。そして、保護されたメモリ領域に展開されたカーネル・イメージから仮想マシンを起動し、保存されたディスク暗号化鍵を利用してディスク・イメージにアクセス可能となる。
このようにして起動されたセキュアな仮想マシンのメモリおよびディスク上のデータはホストOS側のプロセスからは盗み見ることが不可能となる。悪意があるシステム管理者がホストOSの特権ユーザーとしてアクセスしようとしても、Ultravisorによるメモリ保護機構が働き、アクセスが拒否される。
コンフィデンシャル・コンピューティングのクラウド・ネイティブへの適用
IBM Secure Executionなどのハイパーバイザーを用いたコンフィデンシャル・コンピューティングは仮想マシン単位の保護が行われるため、コンテナ技術を基盤とするクラウド・ネイティブ・コンピューティングにそのまま適用することはできない。
このギャップを解決する手法として、ハイパーバイザーを用いたコンテナ技術を応用することが考えられる。Confidential ContainersプロジェクトではKata Containersをもとに、コンフィデンシャル・コンピューティングコンテナ実行環境の開発が進められている。
筆者らは、Confidential Containersプロジェクトの一員として、Peer Pod VMと呼ばれるIaaSクラウドを用いてコンフィデンシャル・コンピューティングを有効化したKubernetesサービスを実現する仕組みの開発に貢献している。この活動に興味を持たれた方は、プロジェクトコミュニティにてぜひご意見をいただきたい。
著者
上田 陽平 氏
日本アイ・ビー・エム株式会社
東京基礎研究所
スタッフ・リサーチ・サイエンティスト
IBM Zのソフトウェアスタックに関する性能・セキュリティ向上に関する研究に従事。Docker等のオープンソース・プロジェクトにも貢献。
著者
稲垣 達氏 氏
日本アイ・ビー・エム株式会社
東京基礎研究所
スタッフ・リサーチ・サイエンティスト
TEC-J「プログラミング言語動向」WG、「金融サービス入門」WGの各リーダー
Kubernetesのセキュリティに関する研究開発に従事。過去にコンテナ、IBM Z、Javaの性能解析を担当。
＊本記事は筆者個人の見解であり、IBMの立場、戦略、意見を代表するものではありません。
当サイトでは、TEC-Jメンバーによる技術解説・コラムなどを掲載しています。
TEC-J技術記事：https://www.imagazine.co.jp/tec-j/
［i Magazine・IS magazine］
