何が起きたか

日経クロステックの連載「当事者が語る！トラブルからの脱出」で、三井情報の事例が紹介されている。同社は新型コロナウイルスの流行前から社内システムのクラウドサービス対応を進めており、認証基盤は、社内に置いたActive Directoryとクラウド側のID基盤（現在のMicrosoft Entra ID）を併用していた。

Microsoft 365への移行は完了し、MDMであるMicrosoft Intuneへの端末登録も済んでいた。更新プログラムの適用も、社内のWSUS（Windows Server Update Services）に接続させず、リモート環境のまま適用できるようにしていた。場所を問わず管理できる体制が、一通り整っていた状態である。

そこへ、Windows Updateの不具合が重なる。証明書の定例更新のタイミングで証明書が削除され、端末がIntuneへ接続できなくなった。リモートワークの前提が、更新プログラムの副作用で崩れた格好である。

厄介だったのは原因ではなく「範囲」

この事例で注目すべきは、原因の特定が難しい障害ではなかったという点だ。記事が強調しているのは、修復すべきデバイスの把握が難しかったことである。

証明書が消えた端末は、症状としては「つながらない」だけである。どの端末が該当するのかは、一覧がなければ分からない。台帳があっても最終接続日が古ければ、その端末がいま電源の入っていないのか、壊れているのか、それとも既に廃棄されたのかは判別できない。1台ずつ確認する作業は、台数に比例して伸びる。

クラウド前提の管理は、平常時は「場所を選ばない」強みを発揮する。だが障害時には、管理対象の全体像を別の手段で持っていなければ、強みだったはずの構成がそのまま見えにくさに転じる。

明日から増やせる備え

事例から引き出せる備えは、特別な製品を買う話ではない。

  • 端末台帳に「人・現場・最終接続日」を持たせる: 機種とシリアル番号だけの台帳では、障害時に誰へ連絡するかが決まらない。
  • 証明書の有効期限を一覧で持つ: 更新を自動化していても、「消えたことに気づく」監視は別に要る。
  • 更新を段階的に当てる: 全社一斉ではなく、まず少人数の群で当ててから広げる。今回のような副作用は、この一手間で被害の広がり方が変わる。

出典記事は有料部分を含むため、構成の詳細や復旧の手順は原文で確認されたい。