Azure の状態
|
2021年3月16日 に発生しましたAzure AD (Active Directory) で障害について、RCA (Root Cause Analysis) レポートの日本語版の抄訳を紹介いたします。
影響の概要
2021 年 3 月 15 日の 19:00 UTC (日本時間 3 月 16 日 AM 4:00) から 2021 年 3 月 16 日の 09:37 UTC (日本時間 3 月 16 日 18:37) の間で、認証を Azure Active Directory (Azure AD) に依存する Microsoft サービスおよびサードパーティ アプリケーションにおいて、認証処理を行う際にエラーが発生した可能性があります。Azure AD サービスに対する対処策は、2021 年 3 月 15 日 21:05 UTC (日本時間 3 月 16 日 6:05) に完了しました。これにより各サービスへのトラフィックが順次回復しました。以下に、主なサービスとその回復までの時間を示します。
2021 年 3 月 15 日 22:39 UTC (日本時間 3 月 16 日 07:39): Azure Resource Manager が回復しました。
2021 年 3 月 16 日 01:00 UTC (日本時間 3 月 16 日 10:00): Azure Key Vault (ほとんどのリージョン) が回復しました。
2021 年 3 月 16 日 01:18 UTC (日本時間 3 月 16 日 10:18): セーフ デプロイメント プロセス (SDP) の一環として、Azure Storage の構成アップデートを最初の運用テナントに適用しました。
2021 年 3 月 16 日 01:50 UTC (日本時間 3 月 16 日 10:50): Azure Portal の機能が完全に回復しました。
2021 年 3 月 16 日 04:04 UTC (日本時間 3 月 16 日 13:04): Azure Storage の構成変更がほとんどのリージョンに適用されました。
2021 年 3 月 16 日 04:30 UTC (日本時間 3 月 16 日 13:30): 残りの Azure Key Vault リージョン (West US、Central US、East US 2) が回復しました。
2021 年 3 月 16 日 09:25 UTC (日本時間 3 月 16 日 18:25): Azure Storage が復旧を完了し、障害が完全に解消したことを報告しました。
根本原因と緩和策
Azure AD は、OpenID およびその他の ID 標準プロトコルの利用をサポートするために、暗号鍵を使用して暗号的な署名処理を行います。セキュリティを高める標準的な対策の一環として、自動化されたシステムが、スケジュールに従い使用されなくなった鍵を自動的に削除します。過去数週間にわたり、複雑な複数のクラウドにまたがる移行を行うために、特定の鍵を通常よりも長い期間にわたり「保持」とマークしていました。この対応において、自動化処理がその「保持」状態を誤って無視してしまう不具合が顕在化し、その特定の鍵が削除される状態が生じました。
署名鍵に関するメタデータは、インターネットの ID 標準プロトコルに沿い、Azure AD によってインターネット上でアクセス可能な場所に公開されます。この公開されたメタデータが 2021 年 3 月 15 日 19:00 UTC (日本時間 3 月 16 日 AM 4:00) に変更されたことにより、Azure AD と連携してこれらのプロトコルを使用するアプリケーションは、順次新しいメタデータを取得し始めました。結果として、削除された鍵で署名されたトークン/アサーションが信頼されなくなりました。この時点で、エンド ユーザーはこれらのアプリケーションにアクセスすることができなくなりました。
サービスのテレメトリによって問題が検知され、エンジニアリング チームが問題の対応を開始しました。2021 年 3 月 15 日 19:35 UTC (日本時間 3 月 16 日 AM 4:35) に、進行中だった直近のバックエンドの基盤変更を元の状態に戻しました。鍵の削除処理が根本的な原因であることが判明したため、21:05 UTC (日本時間 AM 6:05) に鍵のメタデータを以前の状態にロールバックしました。
アプリケーションはロールバックされたメタデータを取得し、正しいメタデータでキャッシュを更新する必要があります。キャッシュの処理方法が様々なサーバーでそれぞれ異なって実装されているため、個々のアプリケーションが復旧するまでの時間もそれぞれ異なるものとなりました。一部のストレージ リソースでは、キャッシュされたメタデータによる影響が長く続きました。このため、これらのキャッシュを無効化して更新するための更新プログラムを展開しました。このプロセスが完了し、2021 年 3 月 16 日 9:37 UTC (日本時間 3 月 16 日 18:37) に、残存する影響を受けたお客様に対しても問題の解消が報告されました。
Azure AD は、この問題を含む一連のリスクを防ぐため、バックエンドのセーフ デプロイメント プロセス (SDP) システムに追加の保護を適用するという複数フェーズの取り組みを進めていました。第 1 フェーズでは、新しい鍵の追加を保護する対応を行いましたが、鍵の削除への対応は第 2 フェーズにあり、今年半ばまでに完了する予定でした。以前の Azure AD の障害は 2020 年 9 月 28 日に発生しており、複数フェーズの SDP の取り組みが完了すれば、どちらの障害も再発を防止できる類いのリスクとなります。
次のステップ
今回の障害がどれほど深刻な影響を与えたか、また容認しがたいものであったか弊社としても認識しており、深く陳謝いたします。今後このような問題が発生しないように、Microsoft Azure プラットフォームとプロセスの改善に継続的に取り組んでまいります。9 月の障害では、「今回確認された一連の問題を防ぐため、Azure AD サービスのバックエンド SDP システムに追加の保護機能を適用する」という計画を示しました。
-
この SDP の変更の第 1 段階は終了し、第 2 段階は非常に慎重かつ段階的に展開を進めており、今年半ばに終了する予定です。初期の分析では、このシステムが完全に導入されれば、今回起きたような障害や 2020 年 9 月に起きた関連する障害も防止が可能です。それまでは、SDP の第 2 フェーズが完了するまでの間、鍵の削除プロセスに追加の保護措置を講じます。
-
9 月に発生した障害では、Azure AD バックアップ認証システムの導入についても言及しました。この取り組みは順調に進んでいます。しかし、残念ながら今回のケースでは、Azure AD バックアップ認証システムはトークンの発行を保護できても、トークンの検証までは保護できませんでした。これはトークンの検証処理が今回影響を受けたメタデータのエンドポイントに依存しているためです。
-
本障害では、Azure Active Directory を使用しているお客様にはサービス正常性を通じて通知を行いました。しかし、影響を受けた関連するサービスすべてに対しての通知を行うことができませんでした。この点については、ツールの不備があると判断し、今後適切に通知が行われるよう対応していく予定です。
-
調査と進捗状況について、お客様により最新の情報を提供すべきでした。今回、Azure、Microsoft 365、Dynamics 365 の間で情報提供の詳細やタイミングに差異があったことを確認しており、複数の Microsoft サービスを利用しているお客様の混乱を招きました。このためサービス間で一貫性と透明性を高めるために、修復項目を設けています。
フィードバックのお願い
Azure カスタマー・コミュニケーション・エクスペリエンスの向上のためのアンケートにご協力ください: https://aka.ms/AzurePIRSurvey
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
■ MS社より以下の情報が公開されています。
RCA - Azure Key Vault - Intermittent failures (Tracking ID 5LJ1-3CZ)
Summary of impact: Between 23:00 UTC on 18 Mar 2021 and 02:15 UTC on 19 Mar 2021, a subset of customers experienced issues and/or encountered error message "InternalServerErrors" when accessing their vaults in West Europe and North Europe regions. These errors were directly impacting customers performing operations on the Control Plane or Data Plane for Azure Key Vault or for supported scenarios that used Customer Managed Keys for encryption at rest for Azure resource providers, in which case those resources were unavailable.
Timeline:
- 3/18/2021 23:00 UTC - First Impact Observed in West Europe.
- 3/18/2021 23:10 UTC - West Europe Key Vault service fails over to North Europe.
- 3/19/2021 00:00 UTC - North Europe Vaults impacted by same issue.
- 3/19/2021 01:50 UTC - Mitigations completed by deploying new VMs. North Europe fully recovered.
- 3/19/2021 02:15 UTC - West Europe fully recovered.
Root Cause: Azure Key Vault's microservice that handles storage transactions in the West Europe region was impacted by a high CPU usage event in one of the processes that runs on the VMs. The resource utilization of the process was not constrained and it impacted underlying machines supporting Azure Key Vault service at 23:00 UTC.
This increased CPU utilization led to connection drops to other backend systems. The monitoring system detected the failures and triggered an automatic failover of the West Europe services to North Europe at 3/18/2021 23:10UTC, and Vaults in West Europe region were then limited to read-only operations. West Europe VMs for the microservice continued to be unhealthy and North Europe served the traffic for both regions.
At 3/19/2021 00:00 UTC the same background process experienced high CPU usage in North Europe. At this point the failures across both regions caused an outage for both read and write availability of Vaults in both regions. While working on the mitigation, the automated system triggered a series of failovers and failbacks which led to the service switching traffic between West Europe and North Europe as each region alternately became healthy and then unhealthy with the shifting traffic.
Mitigation: As a first measure to remediate the situation underlying VMs supporting Azure Key Vault were rebooted. However, the CPU usage continued to be high in the VMs. Engineers then deployed new VMs with higher capacity to handle the increased CPU usage and redirected traffic to them. Once this was completed both regions recovered. Also as a preliminary measure to prevent recurrence in other regions, the capacity was increased globally.
Next Steps: We apologize for the impact to affected customers. We are continuously taking steps to improve the Microsoft Azure Platform and our processes to help ensure such incidents do not occur in the future. In this case, this includes (but is not limited to):
- The first precautionary measure taken was to increase the number of VMs and capacity for the microservice globally to prevent outages from a similar issue.
- New monitors have been added to watch for increased resource usage from processes.
- Failover and failback is being constrained to prevent "ping-pong" between paired regions, which extended recovery times.
- The team is working on modifying the failover pattern for the service so that the paired region is not affected by failover traffic from another region.
- We are looking into resource usage by processes on the underlying VMs that support Azure Key Vault and working to build a capacity model and restrict high resource usage by any single process.
Provide Feedback: Please help us improve the Azure customer communications experience by taking our survey: https://aka.ms/AzurePIRSurvey