ホスト ガーディアン サービスの構成証明の計画

  • [アーティクル]

適用対象: SQL Server 2019 (15.x) 以降 - Windows のみ

構成証明は、セキュリティで保護されたエンクレーブで Always Encrypted を使用する場合に、クライアント アプリケーションが SQL Server プロセス内で信頼できるエンクレーブと通信していることを確認できるようにするワークフローです。

SQL Server では、セキュア エンクレーブを使用した Always Encrypted は、仮想化ベースのセキュリティ (VBS) エンクレーブ (仮想セキュア モードまたは VSM エンクレーブとも呼ばれます) を使用します。これは、Windows ハイパーバイザーに依存し、特別なハードウェアを必要としないソフトウェア ベースのテクノロジです。 VBS エンクレーブを構成証明するには、エンクレーブ内のコードが有効であり、SQL Server をホストしているコンピューターが信頼できるものの両方を確認する必要があります。 構成証明では、SQL Server コンピューターの ID (および必要に応じて構成) を検証できるサード パーティを導入することによって、この目標が達成されます。 SQL Server でエンクレーブを使用してクエリを実行するには、事前に、その動作環境に関する情報を構成証明サービスに提供して正常性証明書を取得しておく必要があります。 その後、この正常性証明書はクライアントに送信され、クライアントでは構成証明サービスを使用してその信頼性を個別に確認できるようになります。 クライアントでは、正常性証明書を信頼したら、信頼できる VBS エンクレーブと通信しているものと認識し、そのエンクレーブを使用するクエリを発行します。

構成証明は、悪意のある OS 管理者による一部の攻撃 (たとえば、エンクレーブ内で実行されている SQL Server ライブラリの改ざんを含む攻撃) を検出するために重要です。 このような攻撃について心配がない場合 (たとえば、非運用環境でセキュリティで保護されたエンクレーブを持つ Always Encrypted を使用している場合)、「構成証明なしで SQL Server でセキュリティで保護されたエンクレーブを使用して Always Encrypted を計画する」を参照してください。

Windows Server 2019 以降のホスト ガーディアン サービス (HGS) ロールには、VBS エンクレーブが設定された Always Encrypted 向けのリモート構成証明機能が用意されています。 この記事では、VBS エンクレーブが設定された Always Encrypted と HGS 構成証明を使用するための、展開前の決定事項および要件について説明します。

注意

SQL Server が VM にデプロイされている場合、VBS エンクレーブは VM 内の攻撃からデータを保護するのに役立ちます。 ただし、ホストからの特権システム アカウントを使用した攻撃からは保護されません。 たとえば、ホスト コンピューターで生成された VM のメモリ ダンプには、エンクレーブのメモリが含まれている場合があります。

アーキテクチャの概要

ホスト ガーディアン サービス (HGS) は、Windows Server 2019 以降で実行されるクラスター化された Web サービスです。 一般的な展開では、HGS サーバーが 1 台から 3 台、SQL Server を実行するコンピューターが少なくとも 1 台、および SQL Server Management Studio などのクライアント アプリケーションまたはツールを実行するコンピューターが必要になります。 HGS は、SQL Server を実行しているコンピューターが信頼できるかどうかを判断する役割を担っているため、保護対象の SQL Server インスタンスとは物理的にも論理的にも分離している必要があります。 HGS と SQL Server コンピューターの両方にアクセスできる管理者は、悪意のあるコンピューターが SQL Server を実行できるように構成証明サービスを構成することが可能であり、これにより VBS エンクレーブを侵害できるようになります。

HGS ドメイン

HGS の設定では、HGS サーバー、フェールオーバー クラスター リソース、および管理者アカウント用に新しい Active Directory ドメインが自動的に作成されます。

SQL Server を実行しているコンピューターはドメイン内に存在する必要はありませんが、その場合は、HGS サーバーで使用されているものとは別のドメインである必要があります。

高可用性

HGS 機能では、フェールオーバー クラスターが自動的にインストールおよび構成されます。 運用環境では、高可用性を実現するために HGS サーバーを 3 台使用することをお勧めします。 クラスター クォーラムの決定方法と、外部監視付きの 2 つのノード クラスターを含む代替の構成の詳細については、フェールオーバー クラスターのドキュメントを参照してください。

HGS ノード間に共有記憶域は必要ありません。 構成証明データベースのコピーは各 HGS サーバーに格納され、クラスター サービスによってネットワーク経由で自動的にレプリケートされます。

ネットワーク接続

SQL クライアントと SQL Server は両方とも、HTTP 経由で HGS と通信できる必要があります。 SQL クライアントと HGS の間、および SQL Server と HGS の間のすべての通信を暗号化するため、TLS 証明書を使用して HGS を構成します。 この構成は中間者攻撃から保護するのに役立ち、正しい HGS サーバーと通信していることを保証します。

HGS サーバーでは、構成証明サービス データベースの同期を維持するために、クラスター内の各ノード間の接続が必要です。フェールオーバー クラスターのベスト プラクティスは、クラスター通信用に 1 つのネットワーク上の HGS ノードを接続し、他のクライアントが HGS と通信するために別のネットワークを使用することです。

構成証明モード

SQL Server を実行しているコンピューターが HGS を使用して証明を試みる場合、そのコンピューターはまず必要な証明方法を HGS に問い合わせます。 HGS では、SQL Server で使用する構成証明モードとして次の 2 つがサポートされています。

構成証明モード 説明
TPM トラステッド プラットフォーム モジュール (TPM) 構成証明では、HGS で証明するコンピューターの ID と整合性について、最も強力な保証が提供されます。 この場合、SQL Server を実行するコンピューターには、TPM バージョン 2.0 がインストールされている必要があります。 各 TPM チップには、特定のコンピューターを識別するのに使用できる一意で不変の ID (保証キー) が含まれています。 また、TPM では、コンピューターの起動プロセスが測定され、セキュリティに影響する測定値のハッシュがプラットフォーム制御レジスタ (PCR) に格納されます。この情報は、オペレーティング システムによって読み取ることはできても変更することはできません。 これらの測定値は、コンピューターのセキュリティ構成が自らが主張する状態にあることを暗号で証明する構成証明時に使用されます。
ホスト キー ホスト キーの構成証明の形式はよりシンプルであり、非対称キー ペアを使用してコンピューターの ID を検証するだけです。 秘密キーは SQL Server を実行しているコンピューターに格納され、公開キーは HGS に提供されます。 コンピューターのセキュリティ構成は測定されず、SQL Server を実行しているコンピューター上で TPM 2.0 チップは必要ありません。 SQL Server コンピューターにインストールされている秘密キーを保護することが重要です。このキーを取得した者はだれでも、正当な SQL Server コンピューター、および SQL Server 内で実行されている VBS エンクレーブを偽装できるからです。

一般に、次の推奨事項があります。

  • 物理的な運用サーバーの場合は、提供される追加の保証に TPM 構成証明を使用することをお勧めします。
  • 仮想運用サーバーの場合は、ほとんどの仮想マシンに仮想 TPM とセキュア ブートがないため、ホスト キー構成証明をお勧めします。 オンプレミスのシールドされた VM のようなセキュリティが強化された VM を使用している場合は、TPM モードの使用を選択できます。 すべての仮想化されたデプロイでは、構成証明プロセスでは VM 環境のみが分析され、VM の下の仮想化プラットフォームは分析されません。
  • Dev/Test シナリオの場合は、設定が簡単なため、ホスト キー構成証明をお勧めします。

信頼モデル

VBS エンクレーブ信頼モデルでは、ホスト OS から保護されるように、暗号化されたクエリとデータはソフトウェアベースのエンクレーブで評価されます。 このエンクレーブへのアクセスはハイパーバイザーによって保護されていて、同じコンピューター上で稼働している 2 つの仮想マシンが互いのメモリにアクセスできないのと同じ方法が使用されます。

自身が VBS の正当なインスタンスと通信していることをクライアントが信頼できるようにするには、TPM ベースの構成証明を使用して、SQL Server コンピューター上に信頼のハードウェア ルートを確立する必要があります。

起動プロセス中にキャプチャされた TPM 測定値には、VBS インスタンスの一意の ID キーが含まれているため、正常性証明書はそのコンピューター上でのみ有効になります。 さらに、VBS を実行しているコンピューター上で TPM を使用できる場合、VBS ID キーのプライベート部分は TPM によって保護されるため、だれもその VBS インスタンスを偽装することはできません。

TPM 構成証明の場合は、セキュア ブートが必要になります。これは、Microsoft が署名した正当なブートローダーが UEFI によって確実に読み込まれ、ルートキットによってハイパーバイザー起動プロセスがインターセプトされないようにするためです。 さらに、既定では IOMMU デバイスが必要です。これは、メモリに直接アクセスできるハードウェア デバイスを使用してもエンクレーブ メモリを検査または変更できないようにするためです。

これらの保護はいずれも、SQL Server を実行しているコンピューターが物理マシンであることを前提としています。 SQL Server を実行しているコンピューターを仮想化する場合、VM のメモリがハイパーバイザーまたはハイパーバイザー管理者による検査から安全であることを保証できなくなります。たとえば、ハイパーバイザー管理者は、VM のメモリをダンプし、エンクレーブ内のクエリとデータのプレーンテキスト バージョンにアクセスできます。 同様に、VM に仮想 TPM が用意されている場合でも、VM のオペレーティング システムおよび起動環境の状態と整合性を測定できるだけです。 VM を制御しているハイパーバイザーの状態を測定することはできません。

ただし、SQL Server が仮想化されている場合でも、エンクレーブは VM オペレーティング システム内からの攻撃から引き続き保護されます。 ご利用のハイパーバイザーまたはクラウド プロバイダーを信頼し、主にデータベース管理者および OS 管理者による機密データへの攻撃を心配している場合は、仮想化された SQL Server がその要件を満たす可能性があります。

同様に、SQL Server を実行しているコンピューターに TPM 2.0 モジュールがインストールされていないシナリオ、またはセキュリティが最重要ではない開発/テスト シナリオでは、ホスト キーの構成証明が依然として有用です。 これまでに説明した多くのセキュリティ機能 (セキュリティで保護された起動や TPM 1.2 モジュールなど) を使用して、VBS とオペレーティング システム全体をより適切に保護することもできます。 ただし、コンピューターのこれらの設定がホスト キー構成証明で実際に有効にされていることを HGS で確認する方法はないため、クライアントでは、使用可能なすべての保護がホストで実際に使用されているかどうかを確認できません。

前提条件

HGS サーバーの前提条件

ホスト ガーディアン サービス ロールを実行しているコンピューターは、次の要件を満たしている必要があります。

コンポーネント 要件
オペレーティング システム Windows Server 2019 以降、Standard または Datacenter Edition
CPU 2 コア (最小)、4 コア (推奨)
RAM 8 GB (最小)
NIC 静的 IP が設定された 2 枚の NIC を推奨 (1 枚はクラスター トラフィック用、もう 1 枚は HGS サービス用)

HGS は、暗号化と暗号化の解除を必要とするアクション数が多いため、CPU にバインドされたロールとなります。 暗号化アクセラレータ機能を備えた最新のプロセッサを使用すると、HGS のパフォーマンスが向上します。 構成証明データの記憶域の要件は、一意のコンピューター証明ごとに最小で 10 KB から 1 MB の範囲です。

開始する前に、HGS コンピューターをドメインに参加させないでください。

SQL Server コンピューターの前提条件

SQL Server を実行しているコンピューターは、SQL Server のインストール要件と Hyper-V ハードウェア要件の両方を満たしている必要があります。

これらの要件の内容は次のとおりです。

  • SQL Server 2019 (15.x) 以降
  • Windows 10 バージョン 1809 以降 - Enterprise Edition、Windows 11 以降 - Enterprise Edition、Windows Server 2019 以降 - Datacenter Edition。 Windows 10 または 11 および Windows Server の他のエディションでは、HGS を使用した構成証明はサポートされていません。
  • 仮想化テクノロジの CPU サポート:
    • Extended Page Tables を備えた Intel VT-x。
    • Rapid Virtualization Indexing を備えた AMD-V。
    • VM で SQL Server を実行している場合:
      • Azure では、第 2 世代 VM サイズ (推奨) を使用するか、入れ子になった仮想化が有効になっている第 1 世代 VM サイズを使用します。 個々の VM サイズに関するドキュメントを参照して、入れ子になった仮想化がサポートされている第 1 世代 VM サイズを確認してください。
      • Hyper-V 2016 以降 (Azure の外部) では、VM が第 2 世代 VM (推奨) であるか、入れ子になった仮想化が有効になっている第 1 世代 VM であることを確認してください。 詳細については、「Hyper-V では、第 1 世代と第 2 世代の仮想マシンのどちらを作成するべきですか?」と「入れ子になった仮想化の構成」を参照してください。
      • VMware vSphere 6.7 以降では、VMware のドキュメントの説明に従って、仮想化ベースのセキュリティによる VM のサポートを有効にします。
      • 他のハイパーバイザーおよびパブリック クラウドでは、VBS エンクレーブが設定された Always Encrypted を有効にする入れ子になった仮想化機能がサポートされている場合もあります。 互換性と構成手順については、仮想化ソリューションのドキュメントを確認してください。
  • TPM 構成証明を使用する予定がある場合は、サーバーで使用できる TPM 2.0 rev 1.16 チップが必要です。 現時点で、TPM 2.0 rev 1.38 チップでは HGS 構成証明は機能しません。 さらに、TPM には有効な保証キー証明書が必要です。

HGS で構成証明を構成する場合のロールと責任

HGS で構成証明を設定するには、HGS、SQL Server コンピューター、SQL Server インスタンス、エンクレーブ構成証明をトリガーするアプリケーションなど、さまざまな種類のコンポーネントを構成する必要があります。 それぞれの種類のコンポーネントの構成は、以下の異なるロールのいずれかを引き受けるユーザーによって実行されます。

  • HGS 管理者 - HGS をデプロイし、SQL Server コンピューターを HGS に登録し、SQL Server コンピューター管理者およびクライアント アプリケーション管理者と HGS 構成証明 URL を共有します。
  • SQL Server コンピューター管理者 - 構成証明クライアント コンポーネントをインストールし、SQL Server コンピューターで VBS を有効にします。また、SQL Server コンピューターを HGS に登録するために必要な情報を HGS 管理者に提供し、SQL Server コンピューターで構成証明 URL を構成し、SQL Server コンピューターにより HGS で正常に証明書を検証できることを確認します。
  • DBA - SQL Server インスタンスでセキュリティで保護されたエンクレーブを構成します。
  • アプリケーション管理者 - HGS 管理者から取得した構成証明 URL でアプリケーションを構成します。

(実際の機密データを扱う) 運用環境では、構成証明を構成するときに組織がロールの分離に従うことが重要です。その場合、異なるユーザーがそれぞれ個別のロールを引き受けます。 特に、Always Encrypted を組織にデプロイする目的が、SQL Server コンピューター管理者および DBA が機密データにアクセスできないようにすることにより攻撃対象領域を減らすことである場合、SQL Server 管理者と DBA が HGS サーバーを制御すべきではありません。

開発/テスト環境に関する考慮事項

開発環境またはテスト環境で、VBS エンクレーブが設定された Always Encrypted を使用している場合に、SQL Server を実行しているコンピューターの高可用性または強力な保護を必要としないときは、次に示すいずれかまたはすべての譲歩を行って展開の簡略化を図ることができます。

  • 構成証明なしでセキュリティで保護されたエンクレーブで Always Encrypted を使用する - 「構成証明なしで SQL Server でセキュリティで保護されたエンクレーブを使用して Always Encrypted を計画する」を参照してください。
  • または、次のようにします。
    • HGS のノードを 1 つだけ展開します。 HGS によってフェールオーバー クラスターがインストールされても、高可用性が問題にならない場合、ノードを追加する必要はありません。
    • 設定エクスペリエンスをよりシンプルにするために、TPM モードではなくホスト キー モードを使用します。
    • HGS や SQL Server を仮想化して物理リソースを節約します。
    • セキュリティで保護されたエンクレーブが設定された Always Encrypted を、SQL Server と同じコンピューター上で構成する場合は、SSMS またはその他のツールを実行します。 この場合、列マスター キーは SQL Server と同じコンピューター上に残されるので、運用環境ではこれを実行しないでください。

次のステップ