セキュア ブート証明書の更新: IT プロフェッショナルと組織向けのガイダンス

セキュア ブート証明書の有効期限

セキュア ブート インフラストラクチャの一部として Microsoft によって提供される証明書とも呼ばれる証明機関 (CA) の構成は、Windows 8とWindows Server 2012以降も変わりません。 これらの証明書は、ファームウェアの Signature Database (DB) 変数と Key Exchange Key (KEK) 変数に格納されます。 Microsoft は、デバイスのファームウェアに含めるために、元の機器メーカー (OEM) エコシステム全体で同じ 3 つの証明書を提供しています。 これらの証明書は Windows でのセキュア ブートをサポートし、サード パーティのオペレーティング システム (OS) でも使用されます。 Microsoft によって提供される証明書は次のとおりです。

• Microsoft Corporation KEK CA 2011

• Microsoft Windows Production PCA 2011

• Microsoft Corporation UEFI CA 2011

何が変化していますか?

現在の Microsoft セキュア ブート証明書 (Microsoft Corporation KEK CA 2011、Microsoft Windows Production PCA 2011、Microsoft Corporation UEFI CA 2011) は、2026 年 6 月から期限切れになり、2026 年 10 月までに期限切れになります。 

セキュア ブートのセキュリティと継続性を維持するために、新しい 2023 証明書がロールアウトされています。 デバイスは、2011 証明書の有効期限が切れる前に 2023 証明書に更新する必要があります。または、セキュリティ コンプライアンスが無効になり、危険にさらされます。  

2012 年以降に製造された Windows デバイスには、証明書の有効期限が切れている可能性があります。これは更新する必要があります。 

用語

証明書

フリート全体でセキュア ブートの状態を確認する: セキュア ブートは有効になっていますか? 

2012 年以降に製造されたほとんどのデバイスでは、セキュア ブートがサポートされており、セキュア ブートが有効になっている状態で出荷されます。 デバイスでセキュア ブートが有効になっていることを確認するには、次のいずれかの操作を行います。 

• GUI メソッド: [スタート > 設定] > [プライバシー] & [セキュリティ] >Windows セキュリティ >[デバイス のセキュリティ] に移動します。 [デバイスのセキュリティ] の [セキュア ブート] セクションに、セキュア ブートがオンになっていることを示す必要があります。

• コマンド ライン メソッド: PowerShell の管理者特権のコマンド プロンプトで、「Confirm-SecureBootUEFI」と入力し、 Enter キーを押します。 コマンドは、セキュア ブートがオンであることを示す True を返す必要があります。

デバイスのフリートに対する大規模な展開では、IT 担当者が使用する管理ソフトウェアで、セキュア ブートを有効にするチェックを提供する必要があります。 

たとえば、Microsoft Intune で管理されるデバイスでセキュア ブート状態をチェックする方法は、Intune カスタム コンプライアンス スクリプトを作成して展開することです。 Intune コンプライアンス設定については、「Microsoft Intune で Linux および Windows デバイスのカスタム コンプライアンス設定を使用する」を参照してください。  

更新プログラムの展開方法

セキュア ブート証明書の更新プログラムの対象となるデバイスには、複数の方法があります。 設定やイベントなど、展開の詳細については、このドキュメントの後半で説明します。 デバイスを更新対象にすると、デバイスが新しい証明書を適用するプロセスを開始する必要があることを示す設定がデバイスで行われます。 スケジュールされたタスクは、デバイスで 12 時間ごとに実行され、デバイスが更新プログラムの対象になっていることを検出します。 タスクの概要は次のとおりです。

1. Windows UEFI CA 2023 が DB に適用されます。

2. デバイスに MICROSOFT Corporation UEFI CA 2011 が DB にある場合、タスクは Microsoft Option ROM UEFI CA 2023 と Microsoft UEFI CA 2023 を DB に適用します。

3. 次に、Microsoft Corporation KEK 2K CA 2023 が追加されます。

4. 最後に、スケジュールされたタスクにより、Windows ブート マネージャーが Windows UEFI CA 2023 によって署名されたものに更新されます。 Windows は、ブート マネージャーを適用する前に再起動が必要であることを検出します。 ブート マネージャーの更新プログラムは、再起動が自然に行われるまで遅延されます (たとえば、毎月の更新プログラムが適用されている場合など)、Windows はブート マネージャーの更新プログラムの適用を再度試みます。

スケジュールされたタスクが次の手順に移動する前に、上記の各手順を正常に完了する必要があります。 このプロセスでは、デプロイの監視に役立つイベント ログやその他の状態を使用できます。 監視とイベント ログの詳細については、以下を参照してください。  

セキュア ブート証明書を更新すると、2023 ブート マネージャーの今後の更新が可能になり、セキュリティが強化されます。 ブート マネージャーの特定の更新プログラムは、今後のリリースで予定されています。

デプロイ手順 

• 準備: インベントリとテスト デバイス。

• ファームウェアに関する考慮事項

• 監視: 監視が機能し、フリートのベースラインを確認します。

• 展開: 小さなサブセットから始まり、成功したテストに基づいて展開する、更新プログラムのターゲット デバイス。

• 修復: ログとベンダー サポートを使用して問題を調査して解決します。

準備 

ハードウェアとファームウェアのインベントリ。 広範な展開の前に、システム製造元、システム モデル、BIOS バージョン/日付、BaseBoard 製品バージョンなどに基づいてデバイスの代表的なサンプルを構築し、これらのサンプルの更新プログラムをテストします。  これらのパラメーターは、システム情報 (MSINFO32) でよく使用できます。 

情報を収集する PowerShell コマンドの例を次に示します。

ファームウェアに関する考慮事項

新しいセキュア ブート証明書をデバイスのフリートに展開するには、デバイス ファームウェアが更新プログラムを完了する役割を果たす必要があります。 Microsoft では、ほとんどのデバイス ファームウェアが期待どおりに動作することを想定していますが、新しい証明書を展開する前に慎重なテストが必要です。

ハードウェア インベントリを調べ、次のような固有の条件に基づいて、デバイスの小さな代表的なサンプルを作成します。 

• Manufacturer

• モデル番号

• ファームウェアのバージョン

• OEM Baseboard バージョンなど

フリート内のデバイスに広範に展開する前に、代表的なサンプル デバイス (製造元、モデル、ファームウェアのバージョンなどによって定義される) で証明書の更新プログラムをテストして、更新プログラムが正常に処理されていることを確認することをお勧めします。 一意のカテゴリごとにテストするサンプル デバイスの数に関する推奨ガイダンスは 4 つ以上です。

これにより、デプロイ プロセスに対する信頼度を高めるのに役立ち、より広範なフリートに予期しない影響が及ぶのを回避するのに役立ちます。 

場合によっては、セキュア ブート証明書を正常に更新するためにファームウェアの更新が必要になる場合があります。 このような場合は、デバイス OEM に確認して、更新されたファームウェアが利用可能かどうかを確認することをお勧めします。

仮想化された環境の Windows

仮想環境で実行されている Windows の場合、Secure Boot ファームウェア変数に新しい証明書を追加するには、次の 2 つの方法があります。  

• 仮想環境の作成者 (AWS、Azure、Hyper-V、VMware など) は、環境の更新プログラムを提供し、仮想化されたファームウェアに新しい証明書を含めることができます。 これは、新しい仮想化されたデバイスで機能します。

• VM で長期的に実行されている Windows の場合、仮想化されたファームウェアがセキュア ブート更新プログラムをサポートしている場合は、他のデバイスと同様に Windows を介して更新プログラムを適用できます。

監視とデプロイ 

デプロイの前にデバイスの監視を開始して、監視が正しく機能し、事前にフリートの状態を把握しておくことをお勧めします。 監視オプションについては、以下で説明します。 

Microsoft では、セキュア ブート証明書の更新プログラムを展開および監視するための複数の方法が用意されています。

自動デプロイの支援 

Microsoft では、2 つの展開支援を提供しています。 これらの支援は、新しい証明書をフリートにデプロイするのに役立つ場合があります。 どちらの支援にも診断データが必要です。

• 信頼バケットを使用した累積的な更新のオプション: Microsoft は、診断データを共有できないシステムや組織に利益をもたらすよう、最新の診断データに基づく毎月の更新プログラムに高信頼度のデバイス グループを自動的に含める場合があります。 この手順では、診断データを有効にする必要はありません。

  • 診断データを共有できる組織やシステムの場合、デバイスが証明書を正常に展開できる可視性と信頼度が Microsoft に提供されます。 診断データの有効化の詳細については、「organizationで Windows 診断データを構成する」を参照してください。 一意のデバイスごとに "バケット" を作成しています (製造元、マザーボードのバージョン、ファームウェアの製造元、ファームウェアのバージョン、追加のデータ ポイントを含む属性によって定義されます)。 バケットごとに、複数のデバイスで成功の証拠を監視しています。 十分な更新が成功し、失敗が発生しなかった場合は、バケットを "高信頼" と見なし、そのデータを毎月の累積更新プログラムに含めます。 信頼性の高いバケット内のデバイスに毎月の更新プログラムが適用されると、Windows はファームウェアの UEFI セキュア ブート変数に証明書を自動的に適用します。

  • 信頼性の高いバケットには、更新プログラムを正しく処理しているデバイスが含まれます。 当然、すべてのデバイスが診断データを提供するわけではありません。これにより、更新プログラムを正しく処理するデバイスの機能に対する Microsoft の信頼が制限される可能性があります。

  • この支援は、信頼度の高いデバイスに対して既定で有効になっており、デバイス固有の設定で無効にすることができます。 詳細については、今後の Windows リリースで共有する予定です。

• 制御された機能ロールアウト (CFR):  診断データが有効になっている場合は、デバイスを Microsoft が管理する展開にオプトインします。

  • 制御された機能ロールアウト (CFR) は、organizationフリートのクライアント デバイスで使用できます。 これには、デバイスが必要な診断データを Microsoft に送信しており、デバイスで CFR を許可することをデバイスがオプトインしていることを通知している必要があります。 オプトインの方法の詳細については、以下で説明します。

  • Microsoft は、診断データが利用可能で、デバイスが制御された機能ロールアウト (CFR) に参加している Windows デバイスで、これらの新しい証明書の更新プロセスを管理します。 CFR は新しい証明書の展開に役立つかもしれませんが、組織は CFR を利用してフリートを修復することはできません。 自動化された支援の対象にならない展開方法に関するセクションのこのドキュメントで説明されている手順に従う必要があります。

  • 制限： CFR が環境内で機能しない理由はいくつかあります。 次に例を示します。

    • 診断データが使用できないか、診断データが CFR デプロイの一部として使用できません。

    • デバイスは、サポートされているクライアント バージョンのWindows 11および拡張セキュリティ更新プログラム (ESU) を使用したWindows 10ではありません。

自動支援の対象外のデプロイ方法

環境に合った方法を選択します。 同じデバイスでメソッドを混在しないようにします。 

• レジストリ キー: デプロイを制御し、結果を監視します。
  証明書の展開の動作を制御したり、結果を監視したりするために、複数のレジストリ キーを使用できます。 さらに、上記のデプロイ支援のオプトインとオプトアウトには、2 つのキーがあります。 レジストリ キーの詳細については、「Secure Boot のレジストリ キー Updates - IT で管理された更新プログラムを使用した Windows デバイス」を参照してください。

• グループ ポリシー オブジェクト (GPO): 設定を管理し、レジストリとイベント ログを使用して監視します。
  Microsoft では、将来の更新プログラムでグループ ポリシーを使用してセキュア ブート更新プログラムを管理するためのサポートを提供する予定です。 グループ ポリシーは設定用であるため、デバイスの状態の監視は、レジストリ キーやイベント ログ エントリの監視などの別の方法を使用して行う必要があることに注意してください。

• WinCS (Windows 構成システム) CLI: ドメインに参加しているクライアントにコマンド ライン ツールを使用します。
  ドメイン管理者は、Windows OS 更新プログラムに含まれる Windows 構成システム (WinCS) を使用して、ドメインに参加している Windows クライアントとサーバー間でセキュア ブート更新プログラムを展開することもできます。 これは、一連のコマンド ライン ユーティリティ (従来の実行可能ファイルと PowerShell モジュールの両方) で構成され、セキュア ブート構成をクエリしてコンピューターにローカルに適用します。 詳細については、「セキュア ブート用の Windows 構成システム (WinCS) API」を参照してください。

• Microsoft Intune/Configuration Manager: PowerShell スクリプトをデプロイします。 Intune を使用した展開を可能にするために、今後の更新プログラムで Configuration Service Provider (CSP) が提供される予定です。

イベント ログの監視

セキュア ブート証明書の更新プログラムの展開に役立つ 2 つの新しいイベントが提供されています。 これらのイベントについては、Secure Boot DB および DBX 変数の更新イベントに関するページで詳しく説明します。 

• イベント ID: 1801
  このイベントは、更新された証明書がデバイスに適用されていないことを示すエラー イベントです。 このイベントは、デバイス属性など、デバイスに固有の詳細を提供します。これは、更新が必要なデバイスの関連付けに役立ちます。

• イベント ID: 1802
  このイベントは、デバイスのファームウェアに必要な新しいセキュア ブート証明書が適用されていることを示す情報イベントです。

デプロイ戦略 

リスクを最小限に抑えるには、一度にすべてではなく、段階的にセキュア ブート更新プログラムをデプロイします。 デバイスの小さなサブセットから始め、結果を検証してから、追加のグループに展開します。 デバイスのサブセットから開始し、それらのデプロイに自信を持つにつれて、デバイスのサブセットを追加することをお勧めします。 複数の要因を使用して、サンプル デバイスのテスト結果やorganization構造など、サブセットに入るものを判断できます。 

展開するデバイスの決定はユーザーの判断です。 考えられるいくつかの戦略を次に示します。 

• 大規模なデバイス フリート: 最初に、管理する最も一般的なデバイスに対して上記の支援に依存します。 並行して、organizationによって管理されるあまり一般的でないデバイスに焦点を当てます。 小さなサンプル デバイスをテストし、テストが成功した場合は、同じ種類のデバイスの残りの部分にデプロイします。 テストで問題が発生した場合は、問題の原因を調査し、修復手順を決定します。 また、フリートの価値が高いデバイスのクラスを検討し、テストと展開を開始して、それらのデバイスが保護を早期に更新したことを確認することもできます。

• 小さい艦隊、大きい変化: 管理しているフリートに、個々のデバイスのテストが禁止されるさまざまなマシンが含まれている場合は、特に市場で一般的なデバイスである可能性が高いデバイスについては、上記の 2 つの支援に大きく依存することを検討してください。 最初は、日常的な操作に不可欠なデバイスに焦点を当て、テストしてからデプロイします。 引き続き優先度の高いデバイスの一覧を下に移動し、フリートの監視中にテストとデプロイを行い、支援がデバイスの残りの部分に役立っていることを確認します。

メモ 

• 古いデバイス、特に製造元によってサポートされなくなったデバイスに注意してください。 ファームウェアが更新操作を正しく実行する必要がある一方で、一部が実行されない場合があります。 ファームウェアが正しく動作せず、デバイスがサポートされなくなった場合は、デバイスを交換して、フリート全体でセキュア ブート保護を確保することを検討してください。

• 過去 1 年から 2 年間に製造された新しいデバイスでは、既に更新された証明書が設定されている可能性がありますが、Windows UEFI CA 2023 署名付きブート マネージャーがシステムに適用されていない可能性があります。 このブート マネージャーの適用は、各デバイスの展開の重要な最後の手順です。

• 更新プログラムのデバイスが選択されると、更新が完了するまでに少し時間がかかる場合があります。 証明書が適用される場合は、48 時間と 1 回以上の再起動を見積もります。

一般的な問題と推奨事項

このガイドでは、セキュア ブート証明書の更新プロセスのしくみについて詳しく説明し、デバイスへの展開中に問題が発生した場合のトラブルシューティング手順について説明します。 このセクションにUpdatesは、必要に応じて追加されます。

セキュア ブート証明書の展開のサポート 

セキュア ブート証明書の更新プログラムをサポートするために、Windows は 12 時間に 1 回実行されるスケジュールされたタスクを維持します。 タスクは、処理が必要な AvailableUpdates レジストリ キー内のビットを検索します。 証明書の展開に使用される目的のビットを次の表に示します。 Order 列は、ビットが処理される順序を示します。

各ビットは、上記の表に示した順序でスケジュールされたイベントによって処理されます。

ビットの進行は次のようになります。 

1. 開始: 0x5944

2. 0x0040 → 0x5904 (Windows UEFI CA 2023 が正常に適用されました)

3. 0x0800 → 0x5104 (必要に応じて Microsoft UEFI CA 2023 を適用)

4. 0x1000 → 0x4104 (必要に応じて Microsoft Option ROM UEFI CA 2023 を適用)

5. 0x0004 → 0x4100 (Microsoft Corporation KEK 2K CA 2023 を適用)

6. 0x0100 → 0x4000 (Windows UEFI CA 2023 署名済みブート マネージャーを適用)

メモ

• ビットに関連付けられた操作が正常に完了すると、そのビットは AvailableUpdates キーからクリアされます。

• これらの操作のいずれかが失敗した場合、イベントがログに記録され、スケジュールされたタスクが次回実行されるときに操作が再試行されます。

• ビット 0x4000が設定されている場合、クリアされません。 他のすべてのビットが処理されると、AvailableUpdates レジストリ キーが 0x4000に設定されます。

問題 1: KEK 更新エラー: デバイスは証明書を Secure Boot DB に更新しますが、新しいキー交換キー証明書を Secure Boot KEK に展開した後は進行しません。 

注 現在、この問題が発生すると、 イベント ID: 1796 がログに記録されます (「セキュア ブート DB および DBX 変数更新イベント」を参照してください)。 この特定の問題を示す新しいイベントは、後のリリースで提供されます。 

デバイスの AvailableUpdates レジストリ キーは0x4104に設定されており、複数回の再起動とかなりの時間が経過しても、0x0004 ビットはクリアされません。 

問題は、デバイスの OEM の PK によって署名された KEK がない可能性があります。 OEM は、デバイスの PK を制御し、新しい Microsoft KEK 証明書に署名し、それを Microsoft に返して、毎月の累積的な更新プログラムに含めることができます。 

このエラーが発生した場合は、OEM にチェックして、「Windows セキュア ブート キーの作成と管理に関するガイダンス」で説明されている手順に従っていることを確認します。  

問題 2: ファームウェア エラー: 証明書の更新プログラムを適用すると、証明書がファームウェアに渡され、セキュア ブート DB または KEK 変数に適用されます。 場合によっては、ファームウェアからエラーが返されます。 

この問題が発生すると、Secure Boot は イベント ID 1795 をログに記録します。 このイベントの詳細については、「 セキュア ブート DB および DBX 変数更新イベント」を参照してください。 

この問題を解決するために、デバイスで使用可能なファームウェア更新プログラムがあるかどうかを OEM に確認することをお勧めします。