【公開情報】
◆Azure status history (2021/03/15) (Microsoft, 2021/03/16)
https://status.azure.com/en-us/status/history/
【詳細】
Preliminary RCA - Authentication errors across multiple Microsoft services (Tracking ID LN01-P8Z)
Summary of impact: Between 19:00 UTC (approx) on March 15, 2021, and 09:25 UTC on March 16, 2021 customers may have encountered errors performing authentication operations for any Microsoft and third-party applications that depend on Azure Active Directory (Azure AD) for authentication.
Azure Admin Portal, Teams, Exchange, Azure KeyVault, SharePoint, Storage and other major applications have recovered. Any customers experiencing residual impact will continue to receive updates regarding these via their Azure Service Health notifications.
Preliminary Root Cause: The preliminary analysis of this incident shows that an error occurred in the rotation of keys used to support Azure AD’s use of OpenID, and other, Identity standard protocols for cryptographic signing operations. As part of standard security hygiene, an automated system, on a time-based schedule, removes keys that are no longer in use. Over the last few weeks, a particular key was marked as “retain” for longer than normal to support a complex cross-cloud migration. This exposed a bug where the automation incorrectly ignored that “retain” state, leading it to remove that particular key.
Metadata about the signing keys is published by Azure AD to a global location in line with Internet Identity standard protocols. Once the public metadata was changed at 19:00 UTC, applications using these protocols with Azure AD began to pick up the new metadata and stopped trusting tokens/assertions signed with the key that was removed. At that point, end users were no longer able to access those applications.
Mitigation: Service telemetry identified the problem, and the engineering team was automatically engaged. The key removal operation was identified as the cause, and the key metadata was rolled back to its prior state at 21:05 UTC.
Applications need to pick up the rolled back metadata and refresh their caches with the correct metadata. Time to mitigation for individual applications varies due to a variety of server implementations that handle caching differently. Azure Admin Portal, Teams, Exchange, Azure Key Vault, SharePoint and other major applications have recovered. A subset of Storage resources experienced residual impact due to cached metadata, and we pushed an update to invalidate these entries and force a refresh. This process completed and mitigation for the residually impacted customers was declared at 09:25 UTC
Azure AD is in a multi-phase effort to apply additional protections to the backend Safe Deployment Process (SDP) system to prevent a class of risks including this problem. The first phase does provide protections for adding a new key, but the remove key component is in the second phase which is scheduled to be finished by mid-year. A previous Azure AD incident occurred on September 28th, 2020 and both incidents are in the class of risks that will be prevented once the multi-phase SDP effort is completed.
Next Steps: We understand how incredibly impactful and unacceptable this is and apologize deeply. 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 the September incident we indicated our plans to “apply additional protections to the Azure AD service backend SDP system to prevent the class of issues identified here."
The first phase of those SDP changes is finished, and the second phase is in a very carefully staged deployment that will finish mid-year. The initial analysis does indicate that once that is fully deployed, it will prevent the type of outage that happened today, as well as the related incident in September 2020. In the meantime, additional safeguards have been added to our key removal process which will remain until the second phase of the SDP deployment is completed.
In that September incident we also referred to our rollout of Azure AD backup authentication. That effort is progressing well. Unfortunately, it did not help in this case as it provided coverage for token issuance but did not provide coverage for token validation as that was dependent on the impacted metadata endpoint.
The Root Cause Analysis investigation relating to this incident is ongoing, and a full RCA will be published when this is completed, or if any other substantive details emerge in the interim.
【翻訳】
予備的RCA - 複数のMicrosoftサービスにおける認証エラー (トラッキングID LN01-P8Z)
影響の概要 2021年3月15日19:00 UTC（概算）から3月16日09:25 UTC（概算）の間に、Azure Active Directory（Azure AD）に認証を依存しているMicrosoftおよびサードパーティのアプリケーションで認証操作を行うと、エラーが発生する可能性があります。
Azure Admin Portal、Teams、Exchange、Azure KeyVault、SharePoint、Storageなどの主要アプリケーションは復旧しています。影響が残っているお客様には、Azure Service Health 通知を通じて、これらに関する最新情報が引き続き提供されます。
予備的な根本原因 この問題の予備的な分析によると、Azure ADがOpenIDやその他のIdentity標準プロトコルを使用して暗号署名操作を行う際に、そのサポートに使用される鍵のローテーションにエラーが発生したことが判明しました。標準的なセキュリティ衛生の一環として、自動化されたシステムが時間ベースのスケジュールで、使用されなくなった鍵を削除します。ここ数週間、複雑なクロスクラウドの移行をサポートするために、ある鍵が通常よりも長く「保持」とマークされていました。これにより、自動化がその「保持」状態を誤って無視し、特定の鍵を削除してしまうというバグが発生しました。
署名鍵に関するメタデータは、インターネットアイデンティティの標準プロトコルに沿って、Azure ADによってグローバルな場所に公開されます。19:00 UTC に公開メタデータが変更されると、Azure AD でこれらのプロトコルを使用するアプリケーションは、新しいメタデータを受け取り始め、削除されたキーで署名されたトークン/アサーションを信頼しなくなりました。この時点で、エンドユーザーはこれらのアプリケーションにアクセスすることができなくなりました。
対策 サービスの遠隔測定によって問題が特定され、エンジニアリングチームが自動的に参加しました。鍵の削除操作が原因であると特定され、鍵のメタデータは21:05 UTCに以前の状態にロールバックされました。
アプリケーションはロールバックされたメタデータを受け取り、正しいメタデータでキャッシュを更新する必要があります。アプリケーションによっては、キャッシュの処理方法が異なる様々なサーバーが実装されているため、ミティゲーションまでの時間が異なります。Azure Admin Portal、Teams、Exchange、Azure Key Vault、SharePoint などの主要アプリケーションは復旧しました。 一部のストレージリソースでは、キャッシュされたメタデータによる影響が残っていたため、これらのエントリを無効にして更新を強制するアップデートを実施しました。このプロセスが完了し、残存する影響を受けた顧客に対する緩和措置がUTC 09:25に宣言されました。
Azure ADは、この問題を含む一連のリスクを回避するために、バックエンドの安全な展開プロセス（SDP）システムに追加の保護を適用するための、複数のフェーズにわたる取り組みを行っています。第1フェーズでは、新しい鍵を追加するための保護を提供していますが、鍵の削除コンポーネントは第2フェーズにあり、今年半ばまでに完了する予定です。以前のAzure ADのインシデントは、2020年9月28日に発生しており、どちらのインシデントも、複数フェーズのSDPの取り組みが完了した時点で防止されるリスクのクラスに属します。
次のステップ 私たちは、今回の事態がいかに大きな影響を与え、受け入れがたいものであるかを理解しており、深くお詫び申し上げます。今後このような問題が発生しないように、Microsoft Azure Platformとプロセスを改善するための措置を継続的に講じています。9月のインシデントでは、「今回確認された問題を防ぐために、Azure ADサービスのバックエンドSDPシステムに追加の保護機能を適用する」という計画を示しました。
このSDPの変更の第1段階は終了し、第2段階は今年半ばに終了する予定で、非常に慎重に段階的に展開しています。初期の分析によると、このシステムが完全に導入されれば、今日起きたような障害や、2020年9月に起きた関連事故を防ぐことができると考えられます。それまでは、SDPの第2フェーズが完了するまでの間、鍵の取り外しプロセスに追加の保護措置を講じています。
9月に発生した事件では、Azure ADバックアップ認証の導入についても言及しました。この取り組みは順調に進んでいます。しかし、残念ながら今回のケースでは、トークンの発行をカバーすることはできても、トークンの検証をカバーすることはできず、影響を受けるメタデータのエンドポイントに依存していたため、役に立ちませんでした。
今回の事件に関する根本原因分析の調査は継続中であり、完全なRCAは、これが完了した時点で、あるいはその間に他の重要な詳細が明らかになった時点で発表されます。
【関連まとめ記事】
◆全体まとめ
◆インシデント (まとめ)
◆2021年のインシデント (まとめ)
◆2021年3月のインシデント (まとめ)
◆Azure AD の障害 (まとめ)
https://malware-log.hatenablog.com/entry/Azure_AD_210316
