Managed HSM のキー主権、可用性、パフォーマンス、スケーラビリティ

[アーティクル]
02/20/2024

暗号キーは、クラウドであろうとオンプレミスであろうと、最新のコンピューターシステムを保護するための信頼の基点です。したがって、これらのキーに対する権限を誰が持つかを制御することは、安全で準拠したアプリケーションを構築するために重要です。

Azure での、クラウドでキー管理を行う方法に関するビジョンは "キー主権"です。 "キー主権" は、誰がキーにアクセスできるか、誰がキー管理ポリシーを変更できるか、また、どの Azure サービスがこれらのキーを使用できるかを、お客様の組織が完全かつ排他的に管理できることを意味します。お客様がこれらについての決定を行った後は、Microsoft の担当者が技術的な手段によってこれらの決定を変更することはできなくなります。キー管理サービスのコードは、これらのお客様の決定を、お客様から変更の指示が出されるまで実行します。Microsoft の担当者が介入することはできません。

それと同時に、クラウドのすべてのサービスはフルマネージドであるべきだと Microsoft は考えます。サービスは、サービスレベルアグリーメント (SLA) に基づき、必要な可用性、回復性、セキュリティ、クラウドの基本的な約束を提供する必要があります。マネージドサービスを提供するためには、Microsoft はキー管理サーバーにパッチを適用し、ハードウェアセキュリティモジュール (HSM) ファームウェアをアップグレードし、障害のあるハードウェアを修復し、フェールオーバーを実行し、その他の高権限の操作を行う必要があります。ほとんどのセキュリティ専門家が知っているように、システムに対する高いアクセス許可または物理的なアクセス権を持つユーザーによるシステム内のデータへのアクセスを拒否することは、困難な問題です。

この記事では、Azure Key Vault Managed HSM サービスにおけるこの問題をどのように解決したのかについて説明します。これにより、HSM と組み合わせて機密コンピューティングテクノロジーを使用することで、顧客に完全なキー主権と完全なマネージドサービス SLA の両方を提供することができます。

Managed HSM ハードウェア環境

任意の Azure リージョンにある顧客のマネージド HSM プールは、セキュリティで保護された Azure データセンターにあります。 3 つのインスタンスが複数のサーバーに分散されています。冗長性を確保するために、各インスタンスは異なるラックにデプロイされます。各サーバーには、FIPS 140-2 レベル 3 で検証された Marvell LiquidSecurity HSM アダプターがあり、複数の暗号化コアがあります。このコアは、完全に分離された資格情報、データストレージ、アクセス制御などを含む、完全に分離された HSM パーティションを作成するために使用されます。

データセンター内のインスタンスを物理的に分離することは、単一コンポーネント (例えばトップオブラックスイッチやラック内の電源管理ユニット) の損失がプールのすべてのインスタンスに影響を及ぼすことがないようにするために重要です。これらのサーバーは、Azure Security HSM チーム専用です。これらのサーバーは他の Azure チームと共有されず、顧客ワークロードはデプロイされません。サーバーへの不正アクセスを防ぐために、ロックされたラックなどの物理的なアクセス制御が使用されます。これらの制御は、FedRAMP-High、PCI、SOC 1/2/3、ISO 270x、およびその他のセキュリティおよびプライバシー標準を満たしており、Azure のコンプライアンスプログラムの一部として定期的に独立して検証されています。 HSM は、FIPS 140-2 レベル 3 の要件を満たすことが検証された、強化された物理セキュリティを備えています。マネージド HSM サービス全体は、高度な持続的脅威から保護するトラステッド起動を含む標準の安全な Azure プラットフォーム上に構築されています。

HSM アダプターは、数十の分離された HSM パーティションをサポートできます。各サーバーで実行されるのは、"ノードサービス" と呼ばれる制御プロセスです。ノードサービスは各アダプターの所有権を取得し、アダプターの所有者 (この場合は Microsoft) の資格情報をインストールします。 HSM では、顧客のパーティションに保存されているデータへのアクセス権限が、アダプターの所有権によりMicrosoft に与えられることがないように設計されています。 Microsoft は顧客パーティションの作成、サイズ変更、削除のみを行えるようになっています。 HSM は、任意の顧客パーティションのブラインドバックアップをサポートしています。 "ブラインドバックアップ" は、顧客が提供したキーでラップされたバックアップであり、顧客が所有するマネージド HSM インスタンス内でのみサービスコードによって復元でき、Microsoft はその内容を読み取ることはできません。

マネージド HSM プールのアーキテクチャ

図 1 は、HSM プールのアーキテクチャを示しています。HSM プールは 3 つの Linux VM で構成され、それぞれが可用性をサポートするために独自のデータセンターラック内の HSM サーバー上で実行されます。重要なコンポーネントは次のとおりです。

HSM ファブリックコントローラー (HFC) は、このサービスのコントロールプレーンです。 HFC は、プールの自動パッチ適用と修復を推進します。
FIPS 140-2 レベル 3 準拠の暗号化境界。各顧客専用で、それぞれが HSM インスタンスに接続された 3 つの Intel Secure Guard Extensions (Intel SGX) 機密エンクレーブを含みます。この境界のルートキーが生成され、3 つの HSM に保存されます。この記事で後述するように、Microsoft に関係のあるユーザーは、この境界内にあるデータにアクセスできません。 Intel SGX エンクレーブ (ノードサービスエージェントを含む) 内で実行されているサービスコードのみが、顧客の代理としてアクセス権限を持ちます。

Diagram of a Managed HSM pool that shows TEEs inside a customer cryptographic boundary and health maintenance operations outside the boundary.

高信頼実行環境 (TEE)

マネージド HSM プールは、3 つのサービスインスタンスで構成されます。各サービスインスタンスは、Intel SGX 機能と Open Enclave SDK を使用する高信頼実行環境 (TEE) として実装されます。 TEE 内で実行することにより、サービスをホストしている VM または VM のホストサーバーのいずれのユーザーも、顧客の秘密、データ、または HSM パーティションへアクセスできなくなります。各 TEE は特定の顧客専用であり、TLS 管理、要求処理、HSM パーティションへのアクセス制御を実行します。この TEE の外部に資格情報や顧客固有のデータ暗号化キーが平文で存在することはありません。ただし、セキュリティドメインパッケージの一部としての場合を除きます。このパッケージは顧客が提供したキーで暗号化され、プールが最初に作成されるときにダウンロードされます。

TEE 間相互の通信には、構成証明済み TLS を使用します。構成証明済み TLS は、Intel SGX プラットフォームのリモート構成証明機能を TLS 1.2 と組み合わせたものです。これにより、TEE 内のマネージド HSM コードは、同じマネージド HSM サービスコードの署名キーで署名された他のコードのみに通信を制限できるため、中間者攻撃を防ぐことができます。マネージド HSM サービスのコード署名キーは、Microsoft Product Release and Security Service (Windows コード署名キーなども格納している) に格納されます。このキーは、マネージド HSM チームによって制御されます。変更管理に関する規制およびコンプライアンス義務の一環として、このキーを他の Microsoft チームがコードへの署名に使用することはできません。

TEE 間通信に使用される TLS 証明書は、TEE 内のサービスコードによって自己発行されます。この証明書には、サーバー上の Intel SGX エンクレーブによって生成される "プラットフォームレポート" が含まれています。プラットフォームレポートは、製造時に Intel によって CPU に組み込まれたキーから派生したキーで署名されます。このレポートは、コード署名キーとバイナリハッシュによって、SGX エンクレーブに読み込まれたコードを識別します。このプラットフォームレポートが与えられると、サービスインスタンスは、ピアもマネージド HSM サービスコード署名キーによって署名されていることを判断でき、プラットフォームレポートを介した暗号もつれにより、自己発行の証明書署名キーも TEE 内で生成されたものであると判断でき、外部の偽装を防止できます。

完全なカスタマーマネージドキー制御による可用性 SLA の提供

高可用性を確保するために、HFC サービスは、顧客が選択した Azure リージョンに 3 つのプールを作成します。

マネージド HSM プールの作成

マネージド HSM プールの高可用性プロパティは、自動的に管理され、常に同期状態に維持された (または、マルチリージョンレプリケーションを使用している場合は、6 つすべてのインスタンスが同期状態に維持された) 三重冗長 HSM インスタンスによってもたらされます。プールの作成は、顧客が選択した Azure リージョン内の利用可能なハードウェア全体にプールを割り当てる HFC サービスによって管理されます。

新しいプールが要求されると、HFC は、HSM アダプターに空きスペースがある複数のラックから 3 台のサーバーを選択し、プールの作成を開始します。

HFC は、一連のパラメーターを使用してサービスコードの新しいインスタンスを起動するように、3 つの各 TEE 上のノードサービスエージェントに指示します。パラメーターは、顧客の Microsoft Entra テナント、3 つのインスタンスすべての内部仮想ネットワーク IP アドレス、およびその他のサービス構成を識別します。パーティションの 1 つが、プライマリの役割がランダムに割り当てられます。
3 つのインスタンスが開始されます。各インスタンスは、ローカル HSM アダプター上のパーティションに接続し、ランダムに生成されたユーザー名と資格情報を使用してパーティションをゼロ化し、初期化します (人間のオペレーターや他の TEE インスタンスがパーティションにアクセスできないようにするため)。
プライマリインスタンスは、HSM で生成された秘密キーを使用してパーティション所有者ルート証明書を作成します。このルート証明書を使用して HSM パーティションのパーティションレベルの証明書に署名することで、プールの所有権を確立します。プライマリは、サービス内に保存されているすべての顧客データの保護に使用されるデータ暗号化キーも生成します。キーマテリアルには、HSM によってキーマテリアル自体も保護されるため、ダブルラッピングが使用されます。
次に、この所有権データが 2 つのセカンダリインスタンスに同期されます。各セカンダリは、構成証明済み TLS を使用してプライマリに接続します。プライマリは、パーティション所有者のルート証明書と秘密キー、およびデータ暗号化キーを共有します。セカンダリはパーティションルート証明書を使用して、自身の HSM パーティションにパーティション証明書を発行するようになりました。これが完了すると、同じパーティションルート証明書に所有された 3 つの別々のサーバー上に HSM パーティションが作成されます。
構成証明済み TLS リンク経由で、プライマリの HSM パーティションは、HSM ベンダーが提供する安全な API を使用し、生成されたデータラッピングキー (3 つの HSM 間のメッセージの暗号化に使用される) をセカンダリと共有します。この交換中に、HSM は互いに同じパーティション所有者証明書を持っていることを確認し、Microsoft サービスコードがメッセージを読み取れないように Diffie-Hellman スキームを使用してメッセージを暗号化します。サービスコードで実行できるのは、HSM 間で不透明な BLOB を転送することのみです。

この時点で、3 つのインスタンスはすべて、顧客の仮想ネットワーク上のプールとして公開する準備ができました。これらは、同じパーティション所有者証明書と秘密キー、同じデータ暗号化キー、および共通のデータラッピングキーを共有しています。ただし、各インスタンスには、HSM パーティションに対する一意の資格情報があります。これで最後の手順が完了しました。
各インスタンスは、RSA キーペアと、公開 TLS 証明書の証明書署名要求 (CSR) を生成します。 CSR は Microsoft 公開ルートを使用して Microsoft 公開キー基盤 (PKI) システムにより署名され、署名された TLS 証明書はインスタンスに返されます。
3 つのインスタンスはすべて、ローカル CPU から独自の Intel SGX シールキーを取得します。キーは、CPU 独自の一意のキーと TEE のコード署名キーを使用して生成されます。
プールは、SGX シーリングキーから一意のプールキーを取得し、このプールキーを使用してすべてのシークレットを暗号化し、暗号化された BLOB をディスクに書き込みます。これらの BLOB は、同じ物理 CPU 上で実行され、同じ SGX シーリングキーで署名されたコードによってのみ復号化できます。シークレットは、その特定のインスタンスにバインドされています。

これで安全なブートストラッププロセスが完了しました。このプロセスにより、三重冗長 HSM プールの作成と、顧客データの主権の暗号化保証の作成の両方が可能になりました。

機密サービス修復を使用して実行時に可用性 SLA を維持する

この記事に示したプール作成のストーリーでは、マネージド HSM サービスが、サービスの基盤となるサーバーを安全に管理することによって、どのようにして高可用性 SLA を実現できるかを説明できます。サーバー、HSM アダプター、さらにはラックへの電源に障害が発生したと想像してください。マネージド HSM サービスの目標は、顧客の介入や TEE 外部で平文のシークレットが公開される可能性を伴わずに、プールを修復して 3 つの正常なインスタンスに戻すことです。これは、機密サービスの修復を通じて実現されます。

これは、障害が発生したサーバー上のインスタンスがどのプールにあるかを HFC が認識することから始まります。 HFC は、プールのリージョン内で新しい正常なサーバーを見つけて、置換インスタンスをデプロイします。新しいインスタンスが起動され、最初のプロビジョニング手順で正確にセカンダリとして扱われます。つまり、HSM を初期化し、そのプライマリを見つけて、証明された TLS 経由で安全にシークレットを交換し、HSM に署名して所有権階層に追加し、そのサービスデータを新しい CPU にシールします。このサービスは現在、完全に自動的かつ完全に機密に修復されています。

セキュリティドメインを使用した障害からの復旧

セキュリティドメインは、HSM パーティションを最初から再構築するために必要なすべての資格情報 (パーティション所有者キー、パーティション資格情報、データラッピングキー、および HSM の初期バックアップ) を含むセキュリティで保護された BLOB です。サービスを開始する前に、顧客はセキュリティドメインを保護するための RSA 暗号化キーのセットを提供してセキュリティドメインをダウンロードする必要があります。セキュリティドメインデータは TEE で生成され、生成された対称キーと、顧客が選択したクォーラムパラメーターに従って顧客が提供した RSA 公開キー間でキー共有を分割する Shamir の秘密共有アルゴリズムの実装によって保護されます。このプロセスの間に、TEE 上で実行されているサービスコードの外部で、サービスキーや資格情報が平文で公開されることはありません。顧客が RSA キーのクォーラムを TEE に提示した場合にのみ、復旧シナリオ中にセキュリティドメインの暗号化を解除できます。

セキュリティドメインが必要になるのは、何らかの大惨事により Azure リージョン全体が破壊され、Microsoft がプールの 3 つのインスタンスすべてを同時に失った場合のみです。インスタンスが 1 つまたは 2 つだけ失われた場合には、機密サービス修復により、3 つの正常なインスタンスへの復旧が顧客の介入なしで自動的に行われます。領域全体が失われた場合には、Intel SGX シーリングキーは各 CPU に固有であるため、Microsoft は HSM 資格情報とパーティション所有者キーを回復する方法がありません。それらは、インスタンスのコンテキスト内にのみ存在します。

非常にまれにこのような大惨事が発生した場合、顧客は新しい空のプールを作成し、それをセキュリティドメインに挿入し、RSA キークォーラムを提示してセキュリティセキュリティドメインの所有権を証明することで、以前のプールの状態とデータを回復できます。顧客がマルチリージョンレプリケーションを有効にしている場合には、両方のリージョンで同時に完全な障害が発生するというさらに可能性の低い大惨事が発生した場合にのみ、セキュリティドメインからプールを回復するために顧客の介入が必要になります。

サービスへのアクセスの制御

前述したように、必要な認証情報が顧客にもその他の人にも与えられないため、TEE 内のサービスコードは HSM 自体にアクセスできる唯一のエンティティです。代わりに、顧客のプールは Microsoft Entra インスタンスにバインドされ、これは認証と承認に使用されます。初期プロビジョニング時に、プールの管理者ロールを割り当てる従業員の初期グループを選択できます。これらの個人と、顧客の Microsoft Entra テナント全体管理者ロールの従業員は、プール内でアクセス制御ポリシーを設定できます。すべてのアクセス制御ポリシーは、サービスにより、マスクされたキー (これも暗号化されている) と同じデータベースに保存されます。 TEE 内のサービスコードのみがこれらのアクセス制御ポリシーにアクセスできます。

まとめ

Managed HSM では、最先端のハードウェア支援の機密エンクレーブテクノロジーを使用することで、顧客が可用性と暗号キーの制御の間でトレードオフを行う必要がなくなります。この記事で説明したように、この実装では、Microsoft 担当者はマネージド HSM のホストマシンや HSM に物理的にアクセスできても、カスタマーマネージドキーのマテリアルや関連シークレットにはアクセスできません。このセキュリティにより、金融サービス、製造、公共部門、防衛、その他の業種の顧客は、自信を持ってクラウドへの移行を加速できるようになりました。