分散したマシンのリモート構成証明

このコンテンツの最終更新日は 2024 年 5 月で、作成時点の状況を表しています。お客様の保護を継続的に改善するために、Google のセキュリティ ポリシーとシステムは変更される場合があります。

このドキュメントでは、データセンター マシンの構成証明に対する Google のアプローチについて説明します。このドキュメントで説明するアーキテクチャは、Trusted Platform Module（TPM）、Security Protocol and Data Model（SPDM）、Redfish などのオープン標準との統合を想定して設計されています。データセンター マシンの構成証明に関連して Google が提案する新しい標準またはリファレンス実装については、GitHub の Platform Integrity（PINT）プロジェクトをご覧ください。このドキュメントは、セキュリティ担当の経営幹部、セキュリティ アーキテクト、監査者を対象としています。

概要

Google では、分散したデータセンター マシンを設計し、デプロイしています。多くのマシンには、単一のルート オブ トラストではなく、測定のルート オブ トラスト（RTM）、ストレージ、更新、リカバリなど、個別のルート オブ トラストが含まれています。各 RTM は、マシン全体のサブセクションを提供します。たとえば、1 台のマシンに、メイン CPU で起動されたものを測定して証明する RTM と、PCIe スロットに差し込まれた SmartNIC で起動されたものを測定して証明する別の RTM が存在する場合があります。次の図に、マシンの例を示します。

マシンの例

1 台のマシンに複数の RTM が存在する複雑さは、データセンター マシンに対する期待を膨らませる一方で、人為的なミス、ハードウェアやソフトウェアの障害などにより、多くの複雑な問題が発生する可能性を含んでいます。フリートのファームウェアの整合性を維持するのは容易なことではありません。

このドキュメントで説明するシステムは、分散したマシンのリモート構成証明の問題を管理しやすくするように設計されています。この構成証明インフラストラクチャは拡張可能なため、データセンターに存在するような、より複雑なマシンにも対応できます。

Google では、この作業を共有することにより、分散マシンの構成証明を大規模に行う視点を提供することを目的としています。Google では、業界パートナーとの連携や、Distributed Management Task Force（DMTF）、Trusted Computing Group（TCG）、Open Compute Project（OCP）などの標準化団体への貢献を通じて、今後もこの分野でセキュリティ イノベーションのサポートを続けていく予定です。

このセクションでは、RTM に推奨されるプロパティをいくつか紹介します。

RTM ハードウェアの統合

プロセッサが RTM とペアになっている場合、RTM はそのプロセッサで実行される最初の変更可能コードの測定値をキャプチャします。後続の変更可能コードでは、そのコードが実行される前に測定値をキャプチャして、ルート オブ トラストに報告する必要があります。これにより、メジャード ブート チェーンが構築され、プロセッサのセキュリティ クリティカルな状態の堅牢な構成証明が可能になります。

RTM ハードウェアとファームウェア ID の構成証明

各 RTM には、外部検証のために構成証明を発行するために使用される署名鍵のペアが必要です。この鍵ペアの証明書チェーンには、RTM 固有のハードウェア ID の暗号的証拠と、RTM 内で実行される変更可能コードのファームウェア ID を含める必要があります。証明書チェーンは RTM メーカーを経由する必要があります。この方法により、マシンは RTM ファームウェアの重大な脆弱性から回復できます。

Device Identifier Composition Engine（DICE）仕様は、Google の構成証明ソリューションで使用されるパターンを形式化したものです。RTM メーカーは一意のデバイス鍵ペアを認定します。このペアで、RTM のハードウェア ID とファームウェア イメージに固有のエイリアスを認定します。エイリアス鍵の証明書チェーンには、RTM ファームウェアと RTM のシリアル番号の測定値が含まれています。検証ツールは、特定のエイリアス鍵によって署名されたデータが、そのエイリアス鍵の証明書チェーンに埋め込まれた暗号ハードウェアとファームウェアの ID 測定値によって記述された RTM から出力されたことを確認できます。

リモート構成証明のオペレーション

構成証明スキームは、意図したブートスタックを実行しているマシンにのみユーザーデータとジョブが発行されるようにしつつ、フリートのメンテナンスを大規模に自動化して問題を修正するよう設計されています。Google の内部クラウドでホストされているジョブ スケジューラ サービスは、マシン内の RTM のコレクションにチャレンジし、証明された測定値をそのマシンに固有のポリシーと比較できます。スケジューラは、証明済みの測定値がマシンのポリシーを遵守している場合にのみ、ジョブとユーザーデータをマシンに発行します。

リモート構成証明には、次の 2 つのオペレーションが含まれます。

  • 構成証明ポリシーの生成。これはマシンの目的のハードウェアまたはソフトウェアが変更されるたびに行われます。

  • 構成証明の検証。これは、マシン管理フローの定義されたポイントで行われます。これらのポイントの一つは、マシンで処理がスケジュールされる直前にあります。マシンは、構成証明の検証に合格した後にのみ、ジョブとユーザーデータにアクセスできます。

構成証明ポリシー

Google では、マシン内で読み取り可能な署名付きドキュメント（ポリシー）を使用して、マシン内での実行が想定されるハードウェアとソフトウェアを記述します。このポリシーは、マシンの RTM のコレクションによって証明できます。ポリシーには各 RTM の次の詳細が含まれます。

  • RTM が発行した構成証明を検証できる、信頼された ID のルート証明書。
  • RTM を一意に識別するグローバルに一意のハードウェア ID。
  • RTM で想定されるバージョンを記述するファームウェア ID。
  • RTM から報告されるブートステージごとの測定値の目標。
  • RTM の識別子。Redfish リソース名に似ています。
  • マシン内の RTM と物理的な場所をリンクする識別子。この識別子は Redfish リソースの名前に似ており、自動化されたマシン修復システムで使用されます。

また、ポリシーには、不正なポリシーのロールバックを防ぐため、失効用のグローバルに一意のシリアル番号も含まれています。次の図にポリシーを示します。

構成証明ポリシーの例。

この図は、ポリシーの次の項目を表しています。

  • 署名はポリシーの認証に使用します。
  • 失効用のシリアル番号は、ロールバックの防止に役立つポリシーの鮮度を提供します。
  • RTM の期待値は、マシン内の各 RTM の詳細を示します。

以降のセクションでは、これらのステップについて詳しく説明します。

ポリシーの組み立て

マシンのハードウェアを組み立てたり、修理した場合、そのマシンで想定される RTM を定義するハードウェア モデルが作成されます。Google のコントロール プレーンを使用すると、パーツの交換やハードウェアのアップグレードを伴う修理などのイベントが発生したときに、この情報を常に最新の状態に保つことができます。

また、コントロール プレーンは、マシンにインストールすることを目的とするソフトウェアに関する一連の期待値と、どの RTM がどのソフトウェアを測定するかについての期待値を維持します。コントロール プレーンは、これらの予測をハードウェア モデルとともに使用して、マシンに想定される状態を記述する構成証明ポリシーを生成します。このポリシーは署名付きで、取り消し可能です。

署名付きのポリシーは、ポリシーに記述されたマシンの永続ストレージに書き込まれます。このアプローチにより、マシンの構成証明を行う際にリモート検証ツールで必要となるネットワークとサービスの依存関係の数を減らすことができます。検証ツールは、データベースにポリシーのクエリを行うのではなく、マシン自体からポリシーを取得できます。このアプローチは重要な設計機能です。ジョブ スケジューラには厳格な SLO 要件があり、高可用性を維持する必要があります。他のサービスに対するこれらのマシンのネットワーク依存関係を減らすことで、停止のリスクを軽減できます。次の図に、このイベントのフローを示します。

ポリシーの組み立てフロー

この図は、コントロール プレーンがポリシーの組み立てプロセスで完了する次の手順を示しています。

  • ソフトウェア パッケージの割り当てとマシン ハードウェア モデルから構成証明ポリシーを取得します。
  • ポリシーに署名します。
  • データセンター マシンにポリシーを保存します。

ポリシーの取り消し

特定のマシンのハードウェアとソフトウェアの目的は時間とともに変化します。目的が変更されたら、古いポリシーを取り消す必要があります。署名済みの構成証明ポリシーには失効用の一意のシリアル番号が含まれています。検証ツールは、署名付きポリシーを認証するための適切な公開鍵と、ポリシーの有効性を確認するための適切な証明書失効リストを取得します。

鍵サーバーまたは失効データベースにインタラクティブにクエリを実行すると、ジョブ スケジューラの可用性に影響します。このため、Google では非同期モデルを使用しています。署名済みの構成証明ポリシーの認証に使用される公開鍵のセットは、各マシンの基本オペレーティング システム イメージの一部として push されます。CRL は、Google が他の認証情報タイプで使用しているのと同じ一元化された失効デプロイ システムを使用して非同期に push されます。このシステムはすでに、通常の状況下における信頼性の高いオペレーションを念頭に置いて設計されており、インシデント対応中に迅速な緊急 push を実施できます。

検証ツールは、検証ツールのマシンのローカルに保存されている検証用の公開鍵と CRL ファイルを使用して、外部からのクリティカル パスのないリモートマシンからの構成証明ステートメントを検証できます。

構成証明ポリシーの取得と測定の検証

マシンのリモート構成証明プロセスは、次のステージから構成されています。

  • 構成証明ポリシーの取得と検証。
  • マシンの RTM からの証明済みの測定値の取得。
  • ポリシーに対する証明済みの測定値の評価。

次の図とセクションでは、これらのステージについて詳しく説明します。

リモート構成証明のステージ。

構成証明ポリシーの取得と検証

リモート検証ツールは、マシンの署名済み構成証明ポリシーを取得します。ポリシーの組み立てで説明したように、可用性の理由から、ポリシーはターゲット マシンに署名付きドキュメントとして保存されます。

返されたポリシーが本物であることを確認するため、リモート検証ツールは、検証ツールにある関連する CRL のローカルコピーを参照します。このアクションにより、取得したポリシーが信頼できるエンティティによって暗号で署名され、ポリシーが取り消されていないことを確認できます。

証明済みの測定の取得

リモート検証ツールはマシンにチャレンジし、各 RTM からの測定をリクエストします。検証ツールは、リクエストに暗号ノンスを含めることで鮮度を保証します。ベースボード管理コントローラ（BMC）などのマシン上のエンティティは、各リクエストをそれぞれの RTM にルーティングし、署名付きレスポンスを収集してリモート検証ツールに返します。このマシン上のエンティティは RTM の署名付き測定値の転送のみに使用されるため、構成証明の観点からは権限は付与されていません。

Google では、測定の構成証明に内部 API を使用しています。また、Redfish を強化して、マシン外の検証ツールが SPDM を使用して RTM の測定値に対して BMC にチャレンジできるようにしています。内部マシン ルーティングは、次のような実装固有のプロトコルとチャネルを介して行われます。

  • サブネット経由の Redfish
  • Intelligent Platform Management Interface（IPMI）
  • i2c/i3c を介した Management Component Transport Protocol（MCTP）
  • PCIe
  • シリアル ペリフェラル インターフェース（SPI）
  • USB

証明済みの測定の評価

Google のリモート検証ツールは、各 RTM が生成した署名を検証し、マシンの証明書ポリシーに含まれる RTM の ID にルートバックしていることを確認します。RTM の証明書チェーンに存在するすべてのハードウェアとファームウェアの ID がポリシーに対して検証され、各 RTM が正しいインスタンスであり、正しいファームウェアが実行されることが保証されます。鮮度を確保するため、署名付きの暗号ノンスがチェックされます。最後に、証明済みの測定値が評価され、そのデバイスがポリシーで想定している内容に対応していることが確認されます。

リモート構成証明の結果への対応

構成証明が完了したら、その結果に基づいて、証明するマシンの状態を判断します。図に示すように、考えられる結果は 2 つあります。構成証明が成功した場合はマシンにタスクの認証情報とユーザーデータが発行されます。構成証明が失敗した場合は修復インフラストラクチャにアラートが送信されます。

リモート構成証明の結果。

以降のセクションでは、これらの違いについて詳しく説明します。

構成証明が失敗した場合

マシンの構成証明が失敗すると、Google はお客様のジョブに対してそのマシンを使用しません。代わりに、修復されたインフラストラクチャにアラートが送信され、自動的にマシンにイメージが再適用されます。構成証明の失敗は悪意のあるインテントが原因の可能性がありますが、ほとんどはソフトウェアのロールアウトが原因です。そのため、構成証明の失敗が増加しているロールアウトは自動的に停止し、より多くのマシンで構成証明が失敗することがないようにします。このイベントが発生すると、SRE にアラートが送信されます。イメージの自動再適用で修正されないマシンの場合、ロールアウトはロールバックされるか、修正済みのソフトウェアのロールアウトが行われます。マシンがリモート構成証明に再び成功するまで、そのマシンはお客様のジョブに使用されません。

構成証明に成功した場合

マシンのリモート構成証明が成功した場合、Google は、そのマシンを使用して Google Cloud の VM や Google フォトの画像処理などの本番環境ジョブを処理します。Google では、ネットワーク サービスに関係する有効なジョブ アクションは、有効期間の短い LOAS タスク認証情報で制限することを求めています。これらの認証情報は、構成証明チャレンジが成功した後に安全な接続を介して付与され、ジョブに必要な権限となります。これらの認証情報の詳細については、Application Layer Transport Security をご覧ください。

ソフトウェア構成証明は、そのソフトウェアを構築するインフラストラクチャの状態に依存しません。生成されるアーティファクトが目的を正確に反映するように、Google ではビルド パイプラインの整合性に多額の投資を行ってきました。ソフトウェア サプライ チェーンの整合性と信頼性に対処するために Google が提案した標準の詳細については、ソフトウェア サプライ チェーンの整合性をご覧ください。

次のステップ

Google データセンター マシンの安全な接続を確立する BeyondProd の仕組みを確認する。