Microsoft、メンテナンスバグが原因でMicrosoft 365が大規模障害と発表

Microsoftによると、自動ネットワークメンテナンス要求システムのバグにより、想定より多くのデバイスからIPルートが誤って削除され、これが木曜日に発生した大規模障害の原因となり、AzureおよびMicrosoft 365サービスに障害が生じました。

障害は7月23日木曜日、米東部時間午前10時44分に始まり、主にMicrosoftのWest US AzureリージョンにつながるネットワークインフラストラクチャからMicrosoft 365サービスにアクセスしていた顧客に影響を及ぼしました。

米東部時間午前11時11分の時点で、Downdetectorには2,403件の障害報告が寄せられており、通常時の基準値である29件を大きく上回りました。苦情の78%はSharePointに関するもので、次いでExcelが11%、Microsoft 365 Admin Centerが6%を占めました。

MicrosoftはこのMicrosoft 365障害をインシデントID MO1437424として追跡し、複数のMicrosoft 365サービスに影響が及んだことを確認しています。

  • Microsoft OneDrive – OneDriveへのアクセスが断続的に不安定になった。
  • SharePoint Online – ユーザーに「問題が発生しました」というエラーが表示された。
  • Microsoft Teams – 画像の読み込み不可を含め、チャット機能が低下した。
  • Microsoft 365 Admin Center – Admin Centerの読み込みが遅くなる、または全く読み込まれなかった。
  • Power Automate – Automateフローが読み込まれなかった。
  • Copilot Chat – アクションやクエリの実行時に断続的な遅延や失敗が発生した。
  • Microsoft Loop – Loopページを開いたり読み込んだりできなかった。

そのほか、Fabric・Power BI、Power Apps、Copilot Studio、Windows 365、Microsoft Defenderといったサービスにも影響が及びました。

一部のDefender顧客では、Microsoft Defender Expertsからの応答に遅延が発生したほか、Threat ExplorerやAdvanced Huntingを通じて実行される調査、ワークフロー、修復アクションが失敗する場合もありました。

Microsoftは当初、トラフィックを代替ネットワーク経路に迂回させることで障害の緩和を試み、これは一部顧客には効果があったものの、多くのサービスは引き続き影響を受けていました。

Microsoftは障害の原因を特定する前の段階で、顧客に対し事業継続計画・災害復旧計画を見直し、それぞれの環境に応じた対策を講じるよう呼びかけていました。

その後、同社は直近に行ったネットワーク変更が原因であることを特定し、その変更のロールバックに着手しました。

Microsoftは米東部時間午後2時26分にロールバックを完了し、サービステレメトリと顧客からの報告により、Microsoft 365のインシデントが解消されたことを確認しました。

メンテナンスのバグが障害の原因に

Azureインシデントに関する暫定的なPost Incident Reviewの中でMicrosoftは、この障害がWest US Azureリージョンにおける特定のネットワーク経路を切り離す通常のデバイスメンテナンス作業中に発生したと説明しています。

Microsoftによると、同社のメンテナンスプロセスはこの種の要求をシステムが読み取れる指示に変換し、作業を開始する前に、冗長化された2つの経路のうち少なくとも一方が正常であることを確認する仕組みになっています。

しかし、この要求変換システムに存在したバグにより、追加のネットワークデバイスが誤ってメンテナンス対象としてマークされてしまいました。

その結果、MicrosoftのWest USデータセンターとワイドエリアネットワークの間で、想定より多くのデバイスからIPルートが削除される事態となりました。

削除されたルートにより、West USリージョンに出入りするネットワークトラフィックに支障が生じました。ただし、Microsoftによれば、同リージョン内で完結するトラフィックには影響がなかったとのことです。

今回のAzureインシデントでは、接続障害、レイテンシの増大、そして数多くのクラウドサービスへのアクセス障害が発生しました。影響を受けたサービスには、Azure App Service、Application Gateway、Azure AD B2C、Azure AI Search、Azure API Management、Azure Cosmos DB、Azure Databricks、Azure Firewall、Azure Kubernetes Service、Azure Monitor、Azure Virtual Desktop、ExpressRoute、Log Analytics、Microsoft Graph、Microsoft Sentinel、Power BI Embedded、Virtual WAN、VPN Gatewayが含まれます。

Microsoftによると、同社のエンジニアは障害発生直後の米東部時間午前10時44分から調査を開始したとのことです。

問題は当初、MicrosoftのWAN内で大規模なルートの変動(churn)として現れました。その後エンジニアは、ルート削除の発生源をWest USリージョン内のデータセンターまでたどり、直近のメンテナンス作業との関連を突き止めました。

Microsoftは米東部時間午後1時45分にメンテナンス変更のロールバックを開始し、午後2時26分に完了させました。

このロールバックにより、影響を受けていたネットワークインフラストラクチャが復旧し、Microsoft 365サービスも回復に向かいました。一部のAzureサービスは対処後も復旧作業が続き、Microsoftは午後3時41分までに影響を受けたすべてのサービスが完全に復旧したと報告しています。

Microsoftは現在、メンテナンス要求の実行に用いられる安全確認プロセスや自動化された仕組みに焦点を当てた、社内全体での見直しを進めています。

「事後緩和策に関する社内の振り返りを進める中で、安全確認、自動化されたメンテナンス要求の変更プロセスなどに焦点を当てた全面的な分析を実施していきます」とMicrosoftは説明しています。

同社は、調査完了後(通常は14日以内)に最終版のPost Incident Reviewを公開するとしています。

攻撃者に先んじて、すべてのレイヤーをテストする

セキュリティチームが記録できている攻撃成功例は54%にとどまり、アラートが上がるのはわずか14%です。残りは環境内を見過ごされたまま通過していきます。

Picusのホワイトペーパーでは、breach and attack simulation(侵害・攻撃シミュレーション)によってSIEMやEDRのルールをテストし、脅威の検知漏れを防ぐ方法を解説しています。

ホワイトペーパーを入手する

翻訳元: https://www.bleepingcomputer.com/news/microsoft/microsoft-blames-massive-microsoft-365-outage-on-maintenance-bug/

ソース: bleepingcomputer.com