概況

  • 2020年9月の Azure Active Directory 認証障害は、アイデンティティが Microsoft 365および依存するクラウドサービスの共通ゲートであったため、復旧は単一コンポーネントの見かけ上の健全性ではなく、実際のアクセス復旧によって判断しなければならない点で重要です。
  • 公開された報告では、Azure Active Directory に影響を与える変更の後、Microsoft サービス全体で認証エラーが発生し、その後ロールバックと軽減作業が行われたと説明されています。公開ファイルは有用ですが、すべてのプライベートなデプロイ成果物、顧客固有の影響、または制御テストを公開しているわけではありません。
  • 説明責任の問題は、デプロイの安全性、ロールバックの検証、認証依存関係マッピング、管理者の可視性、顧客の回避策ガイダンス、復旧の順序付け、および依存するクラウドサービスが実際に使用可能になったことの証明について、誰が実質的な管理権を持っていたかです。
  • また、顧客には、自社の業務のどれだけが単一の ID プロバイダーに依存しているか、認証インシデント中にどの特権アクションが引き続き可能か、手動または代替アクセス経路が理論上のものではなく実際に機能するものかを理解する責任がありました。

アイデンティティがクラウドコントロールプレーンになった理由

Azure Active Directory（現在は Microsoft Entra ID の一部）は単なるログイン画面ではありません。電子メール、コラボレーション、Office 文書、管理、デバイス管理、SaaS アプリケーション、セキュリティツール、ワークフロー自動化、パートナー統合へのアクセスためのコントロールプレーンです。その ID 層が障害を起こすと、影響を受けるユーザーは「ID プラットフォーム」の問題とは見えないかもしれません。ユーザーには Outlook、Teams、SharePoint、Office.com、Azure ポータル、基幹業務アプリケーション、または統合 SaaS ワークフローにアクセスできないように見えます。依存関係はユーザーには抽象的であり、組織には具体的です。

2020年9月の障害は、その抽象性を可視化した点で重要です。公開されたステータス要約と同時代の報道は、Azure Active Directory に関連する Microsoft の変更後に Microsoft 365および関連サービスに影響を与える認証問題を説明しています。Microsoft はその後、ロールバックと軽減手順を実施しました。この記事は公開記録を慎重に扱います。Microsoft のプライベートなデプロイログ、コード変更、顧客テナントテレメトリ、または内部根本原因レビューへのアクセスを主張するものではありません。公開インシデント記録、Microsoft のステータスおよびサービス正常性文書、Microsoft の ID および復元力に関する文書、および第三者報道を、Microsoft 外部で知り得た証拠として使用します。

その証拠は説明責任の枠組みを特定するのに十分です。ID は多くのクラウドサービスの上流にあります。ID でのデプロイまたは設定の問題は、下流で広範な生産性障害として現れる可能性があります。ロールバックは、ユーザーが実際にサインインまたはセッションを更新でき、管理者がサービスの正常性を確認でき、依存するアプリケーションがトークンを受け入れ、カスタマーサポートがユーザーに指示を伝えられるようになるまでは、説明責任を果たしたとは言えません。プロバイダー側の復旧と顧客側の復旧は、必ずしも同時に発生するとは限りません。この区別がコントロールプレーン問題の核心です。

Microsoft の現在の Azure ステータス履歴エントリポイントであるhttps://status.azure.com/en-us/status/history/および Microsoft 365サービス正常性ガイダンスであるhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwideは、顧客がサービスインシデントを分類するための公開および管理者向けチャネルを示しています。Microsoft 365 Service Communications API の概要であるhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-service-communications-api-overview?view=o365-worldwideは、正常性とメッセージセンターのデータを自動化する経路を示しています。これらのソースはそれだけで2020年9月の詳細をすべて証明するわけではありません。それらは、サービス正常性の証拠が Microsoft クラウド顧客の運用モデルの一部であることを示しています。

ID の表面は現在の Microsoft 文書でも定義されています。Microsoft Entra ID の基本であるhttps://learn.microsoft.com/en-us/entra/fundamentals/whatisは ID プラットフォームを説明しています。認証文書であるhttps://learn.microsoft.com/en-us/entra/identity/authentication/overview-authenticationと多要素認証文書であるhttps://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-howitworksは顧客向け ID 制御を説明しています。監視と正常性のガイダンスであるhttps://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-healthは顧客に ID 状態を観察するための語彙を提供します。これらの文書は現在の製品コンテキストであり、遡及的なインシデントポストモーテムではありません。それでも、認証障害がコントロールプレーンイベントである理由を説明するために必要です。

したがって、最初の説明責任の教訓は基本的です。組織はクラウドリスクをアプリケーション名だけで棚卸しすることはできません。アクセス経路を棚卸しする必要があります。電子メール、会議、ファイル共有、ヘルプデスク、セキュリティアラート、デバイス管理、アプリケーションランチャー、ビジネスプロセス自動化、管理者コンソールがすべて同じ ID テナントに依存している場合、それらは独立した継続性リスクではありません。それらは単一の ID 依存関係クラスターです。そのクラスターは、ストレージ、コンピューティング、ネットワークが正常であっても混乱する可能性があります。

ステータス記録はアクセス復旧と同じではない

ID 障害においてステータスコミュニケーションは不可欠です。顧客は、サインイン失敗がローカル設定ミス、ユーザーエラー、テナント固有のポリシー、ネットワーク障害、期限切れの資格情報、MFA の摩擦、条件付きアクセスの動作、またはプロバイダー側のインシデントのいずれかを知る必要があるからです。2020年9月のイベントは、その区別を大規模に強制しました。管理者が確実に認証できなければ、診断とコミュニケーションを担当する人々が最も必要とする瞬間に可視性が低下する可能性があります。

ステータスページは、プロバイダーが問題を特定し、変更をロールバックし、または回復の兆候を見ていると述べることができます。それらの記述は重要です。しかし、それらはすべての顧客ワークフローが復旧したことを自動的に証明するわけではありません。ユーザーはアクティブなセッションを持ち生産的であり続ける一方で、新しいサインインは失敗するかもしれません。別のユーザーはトークン更新に失敗してロックアウトされるかもしれません。管理者はステータス投稿を見てもテナント変更を実行できないかもしれません。アプリケーションは一部のトークンを受け入れても特定の統合パスで失敗するかもしれません。セキュリティチームは、ID 依存関係が通常対応するツールの上流にあるため、アラートの遅延や自動化の失敗を見るかもしれません。

これが、復旧証拠が実際のアクセスのレベルで測定されなければならない理由です。プロバイダーにとって、復旧は認証エラー率がベースラインに戻る、デプロイがロールバックされる、またはサービステレメトリが安定することを意味するかもしれません。顧客にとって、復旧はユーザーがサインインできる、MFA フローが完了する、管理者がポータルに到達できる、依存アプリケーションがトークンを受け入れる、サポートチケットが減少する、キューに入れられた作業がクリアされることを意味するかもしれません。両方の尺度が真実である可能性があります。それらは同一ではありません。

Microsoft の ID 復元力に関する資料は、顧客にこの区別のための語彙を提供するために関連します。復元力の概要であるhttps://learn.microsoft.com/en-us/entra/architecture/resilience-overviewと資格情報の復元力ガイダンスであるhttps://learn.microsoft.com/en-us/entra/architecture/resilience-in-credentialsは、ID システムを可用性と復旧のために設計する方法を議論しています。アプリケーションと ID の復元力に関する Microsoft ガイダンスであるhttps://learn.microsoft.com/en-us/entra/architecture/resilience-with-microsoft-entra-idは、継続性設計への別のエントリポイントを提供します。これらのソースは2020年9月に何が起こったかを主張するものではありません。それらは、ID 復元力が設計された制御であり、サインインが機能することを期待するだけの問題ではないことを示しています。

顧客側の証拠には、サインインログ、トークンエラーパターン、影響を受けたユーザーグループ、影響を受けたアプリケーション、失敗した管理者アクション、非常用アカウントテスト、サポート問い合わせのタイミング、ローカルステータスメッセージ、復旧確認が含まれるべきです。プロバイダー側のステータスだけでは十分ではありません。「Microsoft がサービスを復旧した」という報告だけを受け取る取締役会は、組織が遅延した承認を処理したか、会議を再スケジュールしたか、自動化タスクを調整したか、特権アクセスの継続性をレビューしたかを知ることはできません。

この区別は公共部門の継続性にとっても重要です。学校、大学、自治体、公的機関、請負業者、裁判所、医療サービス、市民プログラムは、日常業務に Microsoft 365と Microsoft ID サービスを使用する可能性があります。多くの使用は生命に関わるものではありません。一部は期限に敏感であったり、公的な側面を持ちます。サービスウィンドウ中にサインインが失敗した場合、組織はグローバルなステータス更新以上のものを必要とします。それはローカルな決定を必要とします。どの機能を一時停止するか、既存のセッションを通じて継続できるもの、代替連絡先を必要とするユーザー、保存しなければならない記録、必要な公的通知です。

デプロイの安全性にはロールバックの証明が含まれなければならない

この記事の明示的な枠組みがデプロイのロールバック失敗を強調するのは、2020年9月の障害に関する公開記録が認証の失敗だけではなかったからです。変更とその後の軽減策が影響を受けたユーザーの期待される動作を直ちに回復しなかったことが問題でした。説明責任の原則はこの単一のインシデントよりも広範です。技術的な意味でロールバックできるからといってデプロイが安全であるとは限りません。デプロイが壊す可能性のあるユーザーとサービスの動作に対してロールバックが検証されている場合にのみ安全です。

ID デプロイは特に保守的な安全規則を必要とします。認証は多くのサービスの上流に位置するからです。変更はトークン発行、トークン検証、セッション更新、条件付きアクセス、MFA、フェデレーション、デバイスコンプライアンス、サービス間認証、または管理者アクセスに影響を与える可能性があります。ロールバック計画は同じ経路をテストしなければなりません。ロールバックが一つの経路を復旧しても別の経路が劣化したままなら、顧客は依然として障害を経験します。ロールバックに管理者がテナント側のアクションを実行する必要があるが、管理者が認証できない場合、回避策は弱いものになります。監視がコンポーネントの健全性に焦点を当てているが、依存サービスのアクセスに焦点を当てていない場合、復旧が早期に宣言される可能性があります。

Microsoft のより広範な信頼性とアーキテクチャ文書は基準を枠組みするのに役立ちます。Azure 信頼性ガイダンスであるhttps://learn.microsoft.com/en-us/azure/reliability/と Azure Well-Architected 信頼性の柱であるhttps://learn.microsoft.com/en-us/azure/well-architected/reliability/は、信頼性を設計、監視、障害対応、継続的改善として扱います。Azure Architecture Center の復元力資料であるhttps://learn.microsoft.com/en-us/azure/architecture/framework/resiliency/overviewは、復元力と障害モード計画のための一般的な言語を提供します。これらは広範な現在の参照であり、特定の2020年9月の RCA ではありません。関連する点は、デプロイの安全性とロールバックの証明が信頼性の内部に属し、外部ではないということです。

ID プロバイダーにとって、ロールバックの証明にはいくつかの層が含まれるべきです。第一に、主要な顧客セグメント全体で新しいサインインが完了できるか。第二に、既存のセッションが安全に更新または継続できるか。第三に、管理者が正常性、サポート、ポリシーインターフェースに到達できるか。第四に、Microsoft 365アプリケーション、Azure ポータル操作、サードパーティ統合アプリケーションなどの依存サービスが ID を正常に使用できるか。第五に、顧客が有害な回避策を作成するのを避けるために十分なステータス詳細を確認できるか。第六に、プロバイダーが問題を軽減したことを証明し、顧客側の復旧作業を隠さないか。

公開記録は部外者がすべての Microsoft 内部制御を判断することを許しません。しかし、顧客が自社環境でより良い証拠規律を求めることを可能にします。顧客は独立した非常用アカウントを保持し、通常の条件付きアクセス経路外の特権アクセスをテストし、どのアプリケーションが Microsoft ID に依存するかを文書化し、サインインテレメトリを保存し、サービス正常性チャンネルに購読し、ユーザー向けのコミュニケーションプランを作成できます。これらのアクションは、プロバイダー側の変更に対する Microsoft の責任を排除するものではありません。それらは、顧客のインシデント対応全体が障害のある ID プレーンに依存することを防ぎます。

デプロイの教訓はエンタープライズソフトウェア自動化にも関連します。多くの組織は、Microsoft ID を承認、ボット、スケジュールジョブ、SaaS コネクタ、デバイスコンプライアンス強制、データ損失防止、セキュリティ対応のためのエントリポイントとして使用します。サインイン障害は、ユーザーが電子メールを開くのを止めるだけでなく、請求書の承認、チケットのルーティング、セッションの更新、ポリシーの適用、またはダウンストリームサービスへの連絡といった自動化ビジネスプロセスを停止させる可能性があります。したがって、ロールバックの証明は人間のサインインだけでなく、自動化の健全性にも目を向けるべきです。

管理者の可視性は同じ ID 依存関係で失敗する可能性がある

ID 障害は、インシデント管理に必要なチャネル自体を損なう可能性があります。管理者は Microsoft 365管理センター、Azure ポータル、Entra 管理センター、サービス正常性ページ、サポートチャネル、テナントログに到達する必要があるかもしれません。それらの経路が障害のある ID 層に依存している場合、管理者の可視性は継続性リスクになります。顧客は、プロバイダーのステータスを確認できる前にユーザーからの苦情を見るかもしれません。サポートデスクは不完全な情報で対応しなければならないかもしれません。セキュリティチームは、障害がプロバイダー側かテナント側かを証明できないため、ポリシーの変更を躊躇するかもしれません。

したがって、Microsoft のサービス正常性ガイダンスは説明責任の情報源です。サービス正常性文書であるhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwideは、管理者がインシデントと勧告を表示する方法を説明しています。Service Communications API であるhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-service-communications-api-overview?view=o365-worldwideは、組織がサービス通信を自社のシステムに統合する方法を提供します。API の価値は単なる利便性ではありません。顧客のインシデントワークフローが影響を受けるポータル経路に依存しないチャネルにプロバイダーの正常性メッセージを取り込むことができれば、より復元力のある可視性を持つことになります。

顧客の可視性にはローカル監視も含まれるべきです。Microsoft Entra の監視と正常性の資料であるhttps://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-healthと、Microsoft 文書におけるサインインレポートの概念は、顧客がテナント内で ID イベントを確認するのに役立ちます。しかし、テナントログはアクセス可能で保持され、理解されている場合にのみ有用です。プロバイダー全体のインシデント中、ローカルログはプロバイダーのステータスページが十分に具体的になる前に症状を示すことがあります。復旧後、ローカルログはどのユーザーとアプリケーションが影響を受けたかを証明するのに役立ちます。ローカル証拠がなければ、組織は逸話と公開ステータスメッセージしか持たないかもしれません。

非常用アクセスは関連する制御です。Microsoft の緊急アクセスガイダンスであるhttps://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-accessは、特権操作のために緊急アクセスアカウントを維持することを推奨しています。このガイダンスは2020年9月に関する所見ではありません。ID インシデントが、緊急アクセスが文書化され、監視され、訓練された制御であるかどうかをテストするから関連します。誰もテストしたことがなく、同じ条件付きアクセス障害でブロックされているか、インシデント指揮官が利用できない非常用アカウントは、信頼できる制御ではありません。

管理者の可視性にはコミュニケーションの側面もあります。ユーザーは障害中に詳細な ID アーキテクチャ図を必要としません。再試行するか、待つか、既存のセッションを使用するか、電話に切り替えるか、代替ツールを使用するか、ワークフローを一時停止するか、サポートに連絡するかを知る必要があります。管理者はその指示を正直に与えるために十分なプロバイダーとローカルの証拠を必要とします。公開プロバイダーステータスが曖昧でローカルテレメトリが弱い場合、顧客のコミュニケーションは推測になります。

公共部門および規制対象組織にとって、その推測は記録管理と公平性の問題を生み出す可能性があります。学習ツールにアクセスできない学校は期限を調整する必要があるかもしれません。電子メールに到達できない公的機関は別の連絡チャネルを必要とするかもしれません。承認を処理できない規制対象企業は遅延を文書化する必要があるかもしれません。管理ポータルに到達できないセキュリティチームは決定の軌跡を保存する必要があるかもしれません。ID 復旧はしたがって記録保持の問題でもあります。

回避策は障害のある ID の下で実際に機能しなければならない

多くの継続性計画は、ユーザーがクラウド障害を回避できると述べています。ID 障害では、その主張はテストを必要とします。既存のセッションは一部のユーザーには使用可能かもしれませんが、新しくサインインするユーザー、トークンが期限切れになるユーザー、再認証が必要なデバイス、新しいトークンを必要とするアプリケーションには使用できません。電話会議は会議の代わりになるかもしれませんが、文書アクセスの代わりにはなりません。ローカルコピーは役立つかもしれませんが、アクセス制御、共有、または最新バージョンにクラウド認証が必要な場合は役立ちません。代替 SaaS ツールは存在するかもしれませんが、同じ ID プロバイダーにフェデレーションしている場合は役立ちません。

実際の回避策は具体的です。既存のセッションを継続できるユーザー、一時停止しなければならない機能、独立したチャネル、サポートに到達できる管理者、利用可能な緊急アカウント、ローカルまたは代替認証を持つアプリケーション、ポリシーに違反せずに使用できるデータを特定します。また、遅延よりも多くのリスクを生み出すために組織がいつ回避策を試みるのをやめるかも述べます。例えば、ID 制御をバイパスしてワークフローを維持することは、短い障害よりも悪い監査またはセキュリティエクスポージャーを生み出す可能性があります。

Microsoft の信頼およびサービス関係の資料は、これらの質問に対する契約上および保証上のコンテキストを提供します。Microsoft Trust Center であるhttps://www.microsoft.com/en-us/trust-centerは、セキュリティ、プライバシー、コンプライアンス、および信頼資料の公開エントリポイントを提供します。Microsoft Customer Agreement ページであるhttps://www.microsoft.com/licensing/docs/customeragreementは、クラウドサービスの関係コンテキストを提供します。これらのソースは2020年のインシデントの救済策を決定するものではありません。それらは、サービス依存性が公開ステータス証拠、契約条件、保証資料、顧客アーキテクチャ、およびローカル継続性計画の組み合わせによって管理されることを購入者に思い出させます。

顧客は二つの反対の誤りを避けるべきです。第一の誤りは、ID インシデントが発生したら、Microsoft がすべての下流のビジネス中断に対して責任があると仮定することです。顧客は ID がどの程度深く埋め込まれているか、どれだけの冗長性を購入するか、どのように通信するか、非常用アクセスをテストするかを選択します。第二の誤りは、顧客がそれらを設計すべきだったため、ID 障害を純粋に顧客の責任として扱うことです。Microsoft は ID サービス、デプロイの安全性、ロールバックメカニズム、公開ステータス言語、およびプロバイダー側の障害を理解するために必要な証拠の多くを制御します。説明責任は両方の車線を必要とします。

この二重車線構造は、ステータスとローカルテレメトリが一緒に保存されるべき理由です。顧客は次のように言えるべきです。プロバイダーステータスは特定の時間に認証インシデントを報告しました。当社のサインインログはこれらのユーザーグループとアプリケーションが失敗したことを示しています。既存のセッションは新しいセッションとは異なる動作をしました。緊急アクセスは使用されたか使用されませんでした。サポートはこれらのメッセージを送信しました。ビジネス業務はこれらの方法で遅延しました。復旧はこれらのテストによって確認されました。その記録は一般的なベンダーリスクノートよりもはるかに強力です。

2020年9月のイベントは、組織がすべてのサポートおよびインシデント機能を同じ ID 経路の背後に代替手段なしに集中化すべきでない理由も示しています。サポートポータル、文書、インシデントブリッジ、緊急連絡先リスト、経営陣報告がすべて ID プレーンの障害でアクセス不能になる場合、組織はコモンモード障害を構築しています。修正は控えめかもしれません。エクスポートされた連絡先リスト、代替会議、独立したステータスホスティング、サービス正常性 API の取り込み、訓練された緊急アカウントです。制御は明示的でなければなりません。

公開報道は不確実性を保持すべきである

同時代の公開報道は有用ですが限界があります。メディア報道は、Outlook、Teams、Office.com、管理アクセスなどのサービスへの影響を含む、広範な Microsoft 365および Azure Active Directory の認証問題を説明しました。例えば、BleepingComputer は Microsoft 365の認証問題をhttps://www.bleepingcomputer.com/news/microsoft/microsoft-365-outage-causes-authentication-issues-globally/で報告し、The Verge は Microsoft 365のサービス中断をhttps://www.theverge.com/2020/9/28/21492361/microsoft-365-office-outage-down-outlook-teamsで報告しました。これらの報告は公的な影響と公的メッセージングの有用な証拠です。それらは Microsoft の内部ログや顧客固有のテレメトリの代わりにはなりません。

公開の不確実性は可視のままであるべきです。障害が Azure Active Directory 認証と Microsoft の変更および軽減シーケンスに関連していたと言うのは妥当です。それは公的イベントが報告された方法だからです。公開報道のみから、テナントごとの正確な影響、すべての内部デプロイ制御の失敗、すべてのビジネス損失、またはすべての成功した回避策を主張することは妥当ではありません。成熟した説明責任記事は、公開障害を法廷の結論に変えることを避けるべきです。

不確実性を保持することは教訓を弱めません。それを強化します。教訓は、部外者がすべての Microsoft 内部の事実を知っているということではありません。教訓は、顧客が依然として制御クラスを特定し、自社の証拠を改善できるということです。ID プロバイダーの可用性はシステム全体の依存関係です。デプロイのロールバックは実際のアクセス復旧によって判断されなければなりません。サービス正常性は障害のある経路の外部で可視でなければなりません。非常用アクセスはテストされなければなりません。ビジネスワークフローは ID が劣化したときに何をすべきかを知っていなければなりません。これらの結論はプライベートソースコードを必要としません。

同じ抑制が法的および契約上の言語にも適用されます。この記事は損害賠償、サービス credit、過失、規制違反、または契約上の fault を決定するものではありません。これは運用上の説明責任を評価します。すなわち、制御、証拠、コミュニケーション、フォールバック、復旧証明、依存関係マッピングです。これは取締役会、公的機関、学校、企業がプライベート訴訟や機密ベンダーレビューを待たずに行動できるレベルです。

外部フレームワークはレビューを規律正しく保つのに役立ちます。NIST サイバーセキュリティフレームワークであるhttps://www.nist.gov/cyberframeworkは、ガバナンス、識別、保護、検出、対応、復旧のための公開語彙を提供します。NIST コンティンジェンシープランニングガイダンスであるhttps://csrc.nist.gov/pubs/sp/800/34/r1/finalは、コンティンジェンシープランニングとテストのライフサイクルを提供します。NIST SP 800-53であるhttps://csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalは、アクセス制御、コンティンジェンシープランニング、監査、インシデント対応、構成管理のための制御ファミリーを提供します。これらのソースは Microsoft インシデントの所見ではありません。それらは顧客にクラウド ID 障害を監査可能な制御レビューに変換する方法を提供します。

レビューにはエンタープライズソフトウェア自動化も含めるべきです。自動化ワークフローがサービスアカウント、委任された権限、コネクタ、管理 API に Microsoft ID を使用する場合、障害はサイレントバックログを生み出す可能性があります。人間のユーザーはすぐに苦情を言うかもしれません。自動化ジョブは静かに失敗し、再試行し、作業を重複させ、またはトークンを待つかもしれません。インシデント後のレビューは自動化ログを調査し、ユーザーのサインインチケットだけでなくすべきです。ID は従業員のアクセス層であるだけでなく、マシン間ワークフローの依存関係でもあります。

テナント証拠はサインイン、セッション、アプリケーションの失敗を分離しなければならない

ID インシデントは、ユーザーが自分が使用しようとしていたアプリケーションを報告し、それらをブロックしたコントロールプレーンを報告しないため混乱します。ヘルプデスクは、電子メールがダウンしている、会議に参加できない、文書を開けない、ワークフロー承認が失敗した、デバイスを登録できない、アプリケーションポータルが読み込めなくなったという苦情を受け取るかもしれません。それらの苦情はサインイン原因を共有するかもしれません。また、ローカルデバイスの問題、テナントポリシーの問題、ネットワークの問題、期限切れのパスワード、MFA 疲れ、または無関係のアプリケーション欠陥を含むかもしれません。顧客証拠ファイルはこれらの可能性を迅速に分離しなければなりません。

最初の分割は新しいサインイン対既存のセッションです。一部のユーザーはインシデントの前に認証したため作業を続けられるかもしれません。他のユーザーは新しいセッションを開始している、新しいデバイスに移動している、またはトークンを更新しているため失敗するかもしれません。組織がこれらの経験を一貫性のない逸話として扱う場合、コミュニケーションに苦労するでしょう。セッション状態、トークン更新動作、ユーザーグループ、アプリケーション、エラーカテゴリを記録すれば、なぜ一部のユーザーが影響を受け、他のユーザーが影響を受けないかを説明できます。その説明は不要なパスワードリセット、リスクの高いポリシー変更、重複するサポート作業を減らします。

第二の分割はユーザー認証対アプリケーション依存関係です。ユーザーはサインインできても、アプリケーションが別の ID クレーム、グループメンバーシップ、API 権限、条件付きアクセス結果、またはサービス間トークンに依存しているため、依存アプリケーションにアクセスできないかもしれません。エンタープライズ自動化では、影響を受ける主体は人物でさえないかもしれません。コネクタ、サービスプリンシパル、スケジュールジョブ、セキュリティツール、デバイス管理プロセス、または承認ワークフローである可能性があります。したがって、インシデント後のファイルにはアプリケーションログと自動化の失敗を含めるべきであり、ユーザーチケットだけではありません。

第三の分割は管理者の可視性対管理者の権限です。管理者は Microsoft のインシデントがあることを見ても、ルーティングの変更、テナントメッセージの送信、サインインログの検査、サポートケースの開始に必要な特権アクションを実行できないかもしれません。別の管理者は緊急アクセスを持っていても、組織が非常用アクティベーションを誰が承認するかを定義していないため使用を躊躇するかもしれません。テストされた緊急アクセス制御は、アカウントが機能するか、誰がどの条件下で使用を許可されるかの両方の質問に答えるべきです。

第四の分割はプロバイダー復旧対ローカル復旧です。Microsoft はプラットフォームテレメトリが改善したときに軽減を報告するかもしれません。顧客は依然として、ユーザーが認証できるか、重要なアプリケーションがトークンを受け入れるか、自動化ジョブがクリアされたか、サポートチケットが減少しているか、遅延したビジネス作業が調整されたかを確認する必要があります。ローカル復旧テストは事前に名前を付けるべきです。例えば、組織は新しいユーザーサインイン、MFA フロー、管理者ポータルログイン、重要な SaaS アプリケーション、サービスプリンシパルジョブ、デバイス管理アクション、サポートチャネルメッセージをテストするかもしれません。名前付きテストがなければ、復旧は感覚になります。

これらの分割はレビューを両側に対してより公平にします。それらは顧客がローカルポリシーの欠陥について Microsoft を非難することを防ぎます。また、プロバイダーステータスがローカル影響証拠の代わりとして使用されることも防ぎます。目的はできるだけ早く fault を割り当てることではありません。目的は、何が起こったか、何が不確かなままか、どの作業が遅延したか、どの制御を変更すべきかを意思決定者が知ることができる記録を構築することです。

調達はアイデンティティ集中を明示的に価格設定すべきである

ID 集中はしばしば間接的に購入されます。組織は生産性ソフトウェア、コラボレーション、デバイス管理、セキュリティツール、ワークフロー自動化、SaaS 統合を購入します。時間の経過とともに、ID プロバイダーはそれらすべての共有ゲートになります。購入者は「このビジネスのこれだけのために一つの ID コントロールプレーンを受け入れる」という単一の明示的な決定を決して行わないかもしれません。2020年9月の障害は、なぜその暗黙の決定が明示的になるべきかを示しています。

調達およびアーキテクチャレビューは、更新、拡張、または主要な統合の前に、どの機能が Microsoft ID に依存するかを特定すべきです。レビューには、人間のアクセス、特権アクセス、アプリケーションアクセス、サービスアカウント、外部パートナー、学校または公共ユーザー、自動化ジョブ、セキュリティアラート、復旧チャネルを含めるべきです。また、どの機能が遅延に耐えられるか、既存のセッションを通じて継続できるか、緊急アクセスを必要とするか、ID 制御をバイパスするよりも停止しなければならないかを分類すべきです。その分類は ID を背景の前提から価格設定された運用依存関係に変えます。

ID 集中に価格を設定することは、Microsoft ID を放棄したりすべてのシステムを複製したりすることを意味しません。第二の ID プロバイダーは、慎重に設計されなければ、複雑性、一貫性のないポリシー、弱いガバナンス、新しい攻撃経路を追加する可能性があります。ポイントは継続性制御をリスクに一致させることです。重要度の低いコラボレーションワークフローはプロバイダー障害リスクを受け入れるかもしれません。セキュリティ運用ワークフロー、公共サービスチャネル、支払い承認、または規制対象記録システムは、より強力な証拠を必要とするかもしれません。緊急アクセス、独立したステータスコミュニケーション、代替連絡経路、文書化された手動プロセス、訓練された復旧チェックです。

レビューはまた、影響を受ける経路の外部に残るコミュニケーションチャネルを尋ねるべきです。組織のインシデントブリッジ、経営陣メッセージング、ユーザー通知ドラフト、サポート知識ベース、管理者連絡先リストがすべて同じ ID プロバイダーを必要とする場合、組織は障害中に調整を失う可能性があります。小さな独立したコミュニケーションキットで十分な場合があります。オフラインの連絡先リスト、事前承認された公的通知、代替会議手順、別の依存関係を通じてホストされるステータスページ、誰が更新を送信するかの明確なルールです。その制御は、それが避ける混乱に比べて安価です。

契約および保証レビューも同様に正確であるべきです。サービス契約または信頼ポータルは義務を枠組みできますが、特定のテナントのワークフローが復元力があることを証明できません。調達は、サービス正常性通知がどのように受信されるか、履歴インシデントがどのように保存されるか、ID 障害中にサポートエスカレーションがどのように機能するか、緊急アクセスがどのように文書化されるか、プロバイダーID が障害の場合に顧客がどのようにローカル証拠を収集するかを尋ねるべきです。これらの質問はプライベートな Microsoft 内部を必要としません。それらは購入者が自社の依存関係を理解することを必要とします。

最終的な調達の質問は残存リスクの受容です。組織が主要な ID 障害が一部の作業を一時停止すると決定した場合、それは許容可能かもしれません。決定は影響を受ける作業、期待される許容度、ユーザーコミュニケーションプラン、所有者を指名すべきです。サイレントリスク受容は異なります。サイレント受容は、ユーザー、管理者、取締役会に障害中に依存関係を発見させるままにします。2020年9月の Azure AD インシデントは、そのサイレント依存関係を具体的なガバナンス項目に変えるため、依然として価値があります。

そのガバナンス項目は、主要な ID または生産性スイートの変更ごとに再検討されるべきです。新しい SaaS 統合、デバイスポリシー、条件付きアクセスルール、自動化コネクタ、合併、学期、公共サービスの期限、セキュリティプログラムはすべて、正式なアーキテクチャプロジェクトなしに爆発半径を拡大する可能性があります。前四半期に正確だった依存関係マップはすぐに古くなる可能性があります。説明責任のあるプラクティスは、どの新しいワークフローが Microsoft ID に依存するようになったか、どの緊急経路がまだ機能するか、どの所有者が変更されたか、どのログが保持されているか、次の障害が隠れた ID 前提をビジネス中断に変える前にどの復旧テストを繰り返す必要があるかを軽量で定期的にレビューすることです。

復旧パッケージには、プロバイダーのサービス正常性クローズアウトとは別のテナントレベルのクローズアウトも含めるべきです。そのクローズアウトは、テストされた重要なアプリケーション、テストされた管理者経路、チェックされた自動化ジョブ、調整された遅延承認またはメッセージ、まだサインイン問題を報告しているユーザー、通常の保管に戻された緊急アクセスアカウントをリストすべきです。プロバイダーは軽減を正しく報告しても、あるテナントにはまだ古いトークン、失敗したコネクタ、またはバックログのあるワークフローがあるかもしれません。逆に、テナントにはプロバイダー復旧後も続くローカル設定 fault があるかもしれません。それらの状態を分離することで、不当な非難と早期の終了の両方を防ぎます。

規制対象および公共サービス組織にとって、クローズアウトは監査可能であるべきです。誰がローカル復旧を宣言したか、どの証拠をレビューしたか、どのユーザーグループが依然として影響を受けたか、どのコミュニケーションが送信されたか、手動回避策がフォローアップリスクを生み出したかどうかを示すべきです。ID 障害はシャドウプロセスを生み出す可能性があります。共有受信トレイ、一時承認、電話ベースの承認、紙の記録、緊急アカウントです。それらのプロセスは必要かもしれませんが、調整されなければなりません。さもなければ、障害は技術的に終了しても、ガバナンスの負債は残ります。

最も有用なクローズアウトは、組織が変更しないことを選択したものも記録します。ほとんどのコラボレーションワークフローに対して単一の Microsoft ID 依存関係が許容可能であり、緊急アクセスと独立したコミュニケーションで十分であると決定するかもしれません。それは明示的で、日付が付けられ、障害からの証拠に結びつけられていれば、防御可能な決定です。同じ隠れた依存関係が、所有者、テスト、訓練、または受容されたリスク記録なしに次のインシデントに再出現する場合、防御可能ではありません。

読者証拠ファイル

この記事は以下の公開ソースを、Azure Active Directory 2020年9月認証障害、Microsoft 365依存関係、ステータスコミュニケーション、ID 復元力、管理者可視性、顧客フォールバック設計、エンタープライズ/公共部門継続性の証拠ファイルとして使用します。Microsoft 作成のソースはプロバイダー文書およびサービス正常性コンテキストとして扱われます。メディアソースはインシデントに関する公開報道として扱われ、完全なフォレンジック証拠ではありません。

取締役会レビュー質問

取締役会またはリスク委員会は、Microsoft が2020年9月に Azure Active Directory 障害を経験したかどうかだけを尋ねるべきではありません。どのビジネスプロセスが Microsoft ID に依存しているか、サインインが失敗したときにどのアプリケーションと自動化ワークフローが失敗するか、どの管理者経路が利用可能のままか、どのユーザーが既存のセッションを通じて作業できるか、どのサービス正常性チャネルが影響を受ける経路の外部で監視されているか、どのローカルテストが復旧を証明するかを尋ねるべきです。

取締役会は証拠の分離を要求すべきです。プロバイダーステータスは Microsoft が公に報告したことを証明できます。テナントサインインログはローカル影響を証明できます。サービス正常性 API 記録は組織が受信したものを証明できます。非常用アクセステストは管理者の継続性を証明できます。サポート記録はユーザーコミュニケーションを証明できます。ワークフローログは自動化が復旧したかどうかを証明できます。契約および信頼資料は義務を枠組みできます。これらの記録はいずれも他の記録の役割を果たすことを強制されるべきではありません。

この特定のケースでは、支配的な質問は変わりません。デプロイの安全性、ロールバックの検証、認証依存関係マッピング、管理者の可視性、顧客の回避策ガイダンス、復旧の順序付け、および ID 復旧が依存クラウドサービスに到達したことの証明について、誰が実質的な管理権を持っていたか。完全な回答は、Microsoft の制御、顧客の制御、証拠のギャップ、影響を受けた聴衆、および将来の ID アーキテクチャまたは調達決定を変更する修復証拠を名前で示すべきです。