Microsoftは、Windows Server 2025環境で発生した深刻な不具合を受け、緊急のOut-of-Band(OOB)修正プログラムをリリースした。直近のセキュリティ更新を適用した一部のサーバーで、起動時にBitLockerの回復キー入力を求められる、あるいは再起動を繰り返すループ状態に陥る事象が報告されている。海外メディアComputingが報じたもので、日本語圏での情報はまだ少ない。

何が起きたのか

報告されている症状は大きく2つある。1つは、更新適用後の再起動時にBitLockerの回復画面が表示され、回復キーを持たない管理者が起動不能に陥るケース。もう1つは、更新の適用そのものが完了せず、サーバーが再起動を繰り返すケースだ。いずれもWindows Server 2025を対象とした報告で、Microsoftは影響を確認したうえでOOB修正を配布している。

BitLocker回復キー要求はなぜ起こるのか

BitLockerはTPM(Trusted Platform Module)が記録するブート構成の測定値をもとに、ディスクの暗号化キーを解放するかどうかを判断している。セキュリティ更新でブートローダーやカーネル、UEFIファームウェアの構成に関わる部分が変更されると、TPMが測定するハッシュ値が変わり、「不正な変更があった」と誤検知して回復キー入力を要求することがある。今回のケースも、更新に含まれるブート関連コンポーネントの変更がTPMの測定値に影響した可能性が高い。再起動ループについても、ドライバーやブート構成ファイルとの整合性が崩れることが典型的な原因になる。

実務への影響

サーバー環境でBitLocker回復キーが求められる事態は、単なる不便では済まない。回復キーがEntra IDやAD DS、あるいは組織のキー管理システムに正しくエスクローされていなければ、最悪の場合ディスクへのアクセスができなくなる。日本のIT管理者にとっての実務ポイントは次の通りだ。

  • BitLocker回復キーがEntra ID/AD DSに確実にバックアップされているか、今のうちに確認する
  • 本番のWindows Server 2025環境には、Windows Update for BusinessやWSUSでリング展開を組み、検証環境を経てから適用する
  • 今回のOOB修正が配布されたら、既知の不具合を再現しないか確認したうえで、まず一部サーバーに適用する
  • 再起動ループに備え、緊急時に安全モードやWinREからアクセスできる復旧手順を事前に整備しておく

筆者の見解

Windows ServerはBitLockerによる暗号化を含め、セキュリティを既定で強く効かせる方向に進化してきた。この設計思想自体は正しいし、応援したい方向性だ。一方で、直近のWindows Update関連では「更新を当てたら壊れた」という報告が増えており、今回のようにOOB修正が必要になる事態が続くと、管理者の信頼を損ないかねない。Microsoftには、品質保証のプロセスをもう一段引き締めてほしいというのが率直な感想だ。

サーバー管理者にとっては、「更新をすぐ当てる」ことだけがセキュリティ対応ではない。リング展開で数日様子を見る、回復手段を事前に確保しておく、といった地道な備えこそが、結果的にセキュリティを守ることにつながる。Microsoftの改善を待つ一方で、自分たちの側でも「壊れても復旧できる」体制を整えておくことが、今の環境では現実的な防御策だと言える。

出典: この記事は Microsoft issues emergency fixes after Windows Server failures の内容をもとに、筆者の見解を加えて独自に執筆したものです。