Shielded VM インスタンスの整合性モニタリング

このトピックでは、Stackdriver を使用して Shielded VM インスタンスの起動時の整合性をモニタリングする方法、整合性検証の失敗原因を特定する方法、整合性ポリシー ベースラインを更新する方法を説明します。

始める前に

Stackdriver を使用して VM 起動時の整合性をモニタリングする

Stackdriver Monitoring を使用して、整合性検証イベントを表示し、それらのイベントに基づくアラートを設定します。また、Stackdriver Logging を使用して、整合性検証イベントの詳細を確認します。

整合性検証イベントを表示する

  1. Stackdriver Monitoring に移動します。
  2. Stackdriver Monitoring コンソールの右上にあるプルダウン メニューを使用して、VM インスタンスが存在する GCP プロジェクトが含まれる Stackdriver アカウントを選択します。
  3. 左側のナビゲーションで、[Resources]、[Metrics Explorer] の順に選択します。
  4. [Find resource type and metric] フィールドに「instance」と入力し、[GCE VM Instance] リソースタイプを選択します。
  5. 次のいずれかの指標を選択します。

    • [Early Boot Validation] には、最後のブート シーケンスのアーリーブート部分の合否ステータスが示されます。アーリーブートとは、UEFI ファームウェアが起動してから、制御がブートローダーに渡されるまでのブート シーケンスです。
    • [Late Boot Validation] には、最後のブート シーケンスのレイトブート部分の合否ステータスが示されます。レイトブートとは、制御がブートローダーに渡されてから起動が完了するまでのブート シーケンスです。これには、オペレーティング システム カーネルの読み込みが含まれます。
  6. 必要に応じて、フィルタを適用して表示される指標情報を絞り込んだり、表示される指標情報をグループ化したりできます。また、指標データを集計することもできます。詳しくは、追加構成をご覧ください。

整合性検証イベントに基づくアラートの設定

VM インスタンスでブート検証失敗が発生した場合に通知を受け取るには、[Early Boot Validation] 指標と [Late Boot Validation] 指標の値に基づくアラートを設定します。アラートの構成方法について詳しくは、アラートの概要をご覧ください。

  1. Stackdriver Monitoring に移動します。
  2. Stackdriver Monitoring コンソールの右上にあるプルダウン メニューを使用して、VM インスタンスが存在する GCP プロジェクトが含まれる Stackdriver アカウントを選択します。
  3. 左側のナビゲーションで、[Alerting]、[Create a Policy] の順に選択します。
  4. [Add Condition] をクリックします。
  5. [Try our new UI for creating alerting conditions] メッセージが表示されたら、[Opt in] を選択して新しいアラート条件インターフェースを使用します(必須)。
  6. [Metric Threshold/Rate Change/Absence] に対応する [Select] をクリックします。
  7. [Find resource type and metric] フィールドに「instance」と入力し、[GCE VM Instance] リソースタイプを選択します。
  8. 次のいずれかの指標を選択します。

    • [Early Boot Validation] には、最後のブート シーケンスのアーリーブート部分の合否ステータスが示されます。アーリーブートとは、UEFI ファームウェアが起動してから、制御がブートローダーに渡されるまでのブート シーケンスです。
    • [Late Boot Validation] には、最後のブート シーケンスのレイトブート部分の合否ステータスが示されます。レイトブートとは、制御がブートローダーに渡されてから起動が完了するまでのブート シーケンスです。これには、オペレーティング システム カーネルの読み込みが含まれます。
  9. [Filter] には、フィルタ条件「status=failed」を指定します。

  10. [Group By] には、「status」を基準にグループ化するよう指定します。

  11. [Condition triggers if] には、[Any time series violates] を選択します。

  12. [Condition] には、「is above 0 for 1 minute」と指定します。

  13. [Save Condition] をクリックします。

  14. 1 つ以上の通知を追加します。

  15. 必要に応じて、通知の受信者がアラートの処理方法を理解できるようにドキュメントを追加します。

  16. ポリシーの名前を指定します。

  17. [Save Policy] を選択します。

整合性検証イベントの詳細を表示する

  1. [VM インスタンス] ページに移動します。
  2. インスタンス ID をクリックして、[VM インスタンスの詳細] ページを開きます。
  3. [ログ] で、[Stackdriver Logging] をクリックします。
  4. 確認する earlyBootReportEvent ログエントリまたは lateBootReportEvent ログエントリを見つけます。
  5. ログエントリ > jsonPayload > earlyBootReportEvent または lateBootReportEvent のうち、該当するものを展開します。そのセクション内にある policyEvaluationPassed 要素が、ブート シーケンスの該当する部分が整合性ポリシー ベースラインに対する検証に合格したかどうかを識別します。
  6. actualMeasurements セクションを展開します。その中にある番号付きの要素を展開して、前回のブート シーケンスで保存されたプラットフォーム構成レジスタ(PCR)値を確認します。PCR 値は、番号付きの要素内の pcrNum 要素に保存されています。PCR 値は、前回のブート シーケンスで使用されたブート コンポーネントとコンポーネント読み込み順を識別します。この PCR 値が整合性ポリシー ベースラインと比較されて、VM インスタンスのブート シーケンスに変更があったかどうかが判別されます。PCR の意味について詳しくは、整合性モニタリング イベントをご覧ください。
  7. policyMeasurements セクションを展開して、整合性ポリシー ベースライン用に保存された PCR 値を確認します。

整合性検証イベントに対するレスポンスの自動化

Cloud Functions などの別のサービスに Stackdriver のログをエクスポートして処理することで、ブート検証イベントに対するレスポンスを自動化できます。詳細については、ログのエクスポートの概要整合性検証の失敗に対するレスポンスを自動化するをご覧ください。

起動時の整合性検証の失敗原因を特定する

  1. [VM インスタンス] ページに移動します。
  2. インスタンス ID をクリックして、[VM インスタンスの詳細] ページを開きます。
  3. [ログ] で、[Stackdriver Logging] をクリックします。
  4. 最新の earlyBootReportEvent ログエントリと lateBootReportEvent ログエントリを見つけて、どちらのエントリで policyEvaluationPassed 値が false になっているかを確認します。
  5. ログエントリ > jsonPayload > earlyBootReportEvent または lateBootReportEvent のうち、該当するものを展開します。
  6. actualMeasurements セクションと policyMeasurements セクションを展開します。それぞれのセクション内にある番号付きの要素を展開して、前回のブート シーケンスと整合性ポリシー ベースラインのそれぞれで保存されたプラットフォーム構成レジスタ(PCR)値を確認します。PCR 値は、前回のブート シーケンスと整合性ポリシー ベースラインで使用されている、ブート コンポーネントとコンポーネント読み込み順を識別します。
  7. actualMeasurements セクションと policyMeasurements セクションの PCR 値を比較して、前回のブート シーケンスと整合性ポリシー ベースラインとの間の差異がどこにあるのかを判断します。どちらの比較であっても、異なる値を示したものが検証を失敗させた原因です。これらのセクション内の要素の番号が PCR の番号に対応することはほとんどないという点に注意してください。また、actualMeasurementspolicyMeasurements で同じように番号が付けられている要素が、異なる PCR を表す場合があります。たとえば Windows と Linux のアーリーブート シーケンスでは、actualMeasurements 内の要素 3policyMeasurements 内の要素 2 はどちらも PCR7 を表します。

  8. 整合性モニタリング イベントを確認して、変更された PCR が表す内容を判断し、それが予想される変更かどうかを調査します。

整合性ポリシー ベースラインの更新

初期の整合性ポリシー ベースラインは、インスタンスの作成時に、暗黙的に信頼されているブートイメージから導出されます。ベースラインを更新すると、現在のインスタンス構成を使用して整合性ポリシー ベースラインが更新されます。ベースラインを更新するときは、VM インスタンスが実行中でなければなりません。

インスタンス構成で、予定されていたブート固有の変更(カーネルの更新、ドライバのインストールなど)を行った後、ベースラインを更新しないと、整合性検証が失敗することになります。予期せずに整合性検証が失敗した場合は、VM インスタンスを停止して、失敗した理由を調査してください。

整合性ポリシー ベースラインを更新するには、setShieldedInstanceIntegrityPolicy 権限が必要です。

整合性ポリシー ベースラインを更新する手順は次のとおりです。

gcloud

--shielded-learn-integrity-policy フラグを指定した compute instances update コマンドを使用して、VM インスタンスの整合性ポリシー ベースラインを更新します。

次の例では、my-instance VM インスタンスの整合性ポリシー ベースラインをリセットします。

gcloud compute instances update my-instance \
    --shielded-learn-integrity-policy

API

本文の項目として setShieldedInstanceIntegrityPolicy メソッドを含めた updateAutoLearnPolicy リクエストを使用して、VM インスタンスの整合性ポリシー ベースラインを更新します。

次の例では、VM インスタンスの整合性ポリシー ベースラインをリセットします。

PATCH https://www.googleapis.com/compute/alpha/projects/my-project/zones/us-central1-b/instances/my-instance/setShieldedInstanceIntegrityPolicy?key={YOUR_API_KEY}
{
  "updateAutoLearnPolicy": true
}

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Compute Engine ドキュメント