Microsoft Storm-0558: トークン被害の運用管理が公的説明責任の試金石に

概要

• Storm-0558 は、Microsoft の一般消費者向け署名キーと検証の失敗を利用して、法人向け Exchange Online メールにアクセスした。これにより、顧客は Microsoft のキーをローテーションすることも、Microsoft のトークン検証機能にパッチを当てることも、Microsoft 内部の署名環境を調査することもできないため、運用上の被害管理は主にプロバイダー側の責務となった。
• 最も重要な公的説明責任の試金石は、信頼の失効後に訪れた。つまり、Microsoft がどれほど迅速に偽造トークンの経路を特定し、トークン更新を止め、当該キーの受け入れをブロックし、署名マテリアルを交換し、顧客ログを拡張し、未解決の部分を説明できたかという点である。
• サイバー安全審査会（CSRB）は後に、このインシデントは予防可能だったと結論付け、Microsoft のセキュリティ文化、キー管理、検証管理、ログアクセス、初期のキー取得説明の修正を批判した。Microsoft は CSRB の指摘を受け入れ、セキュアフューチャーイニシアチブ（Secure Future Initiative）の取り組みを発表したが、実施の証拠の多くは依然としてプロバイダーによる自己報告に留まっている。
• 未解決の取得経路は重要である。Microsoft のクラッシュダンプの説明は、影響を受けたキーを含むクラッシュダンプは発見されていないと同社が述べた後、単なる有力仮説へと絞り込まれた。したがって、説明責任は、完全に立証された窃取の連鎖ではなく、実証された管理体制の不備と残余の不確実性に基づくことになる。

証拠マップ

トークン被害はプロバイダーが管理する障害モード

Storm-0558 はよく、最もドラマチックな対象を通じて説明される。すなわち、2016年に作成された Microsoft の一般消費者向け署名キーである。このキーは重要だった。秘密の署名キーがあれば、検証ルールが不十分な場合にサービスが受け入れる可能性のあるトークンを、攻撃者が作成できる。しかし、説明責任の試金石はキーの盗難だけではない。それには、キーがどれだけ長く信頼され続けたか、サービスがトークンの発行者とスコープをどのように検証したか、更新経路の挙動、不可能なトークンの組み合わせが検出されたかどうか、そして顧客がメールボックスアクセスの証拠を確認できたかも含まれる。これらのコントロールは圧倒的に Microsoft の手中にあった。

これが、被害に対する運用管理が中心的視点となる理由である。顧客はアカウントを堅牢化し、多要素認証を必須とし、特権を削減し、ログを監視し、迅速に対応できる。しかし、Microsoft の内部署名キーをローテーションすることはできない。Exchange Online のサーバー側検証コードを変更することもできない。全ての内部トークン発行経路を目にすることもできない。Microsoft の内部クラッシュダンプや署名環境のログを保全することもできない。クラウドプロバイダーの信頼基盤が破綻した時、顧客が最初の被害を防ぐ能力は著しく制限される。

CISA と FBI の勧告は、この責任分担を異例なほど明確にした。勧告は、影響を受けたインフラがクラウドベースであるため、当該活動の緩和措置は Microsoft の責任であると述べた。この一文は重要である。これは顧客が検知や対応において何の役割もなかったことを意味するのではない。国務省の検知は極めて重要だった。決定的な封じ込め措置がプロバイダー側にあったということを意味する。すなわち、偽造経路の受け入れ停止、キーのブロック、署名マテリアルの交換、そして証拠の拡充である。これが被害に対する運用管理である。

この事象は通常のメールボックス侵害ではない。Storm-0558 は標的のパスワードを個別にフィッシングする必要がなかった。クラウドアイデンティティの信頼決定を悪用したのだ。このことは被害組織を超えて公的な問題となる。政府、規制対象企業、そして一般市民は、プロバイダーのアイデンティティ基盤を共有インフラとして依存している。プロバイダーが管理するトークンの境界が破綻した場合、説明責任を顧客の設定に矮小化することはできない。

公開情報は正確さも要する。このインシデントは主に機密性と信頼される通信の破綻であり、Exchange Online の可用性障害ではない。メールは引き続き機能した。被害は、メッセージへの秘匿アクセスと、サービスのアイデンティティ境界が保持されていたという信頼の喪失であった。公共部門の事業継続性にはこの種の被害も含まれる。外交用のメールボックスは、その内容が侵害されている間も到達可能であり続けうる。

キー取得の経緯は未解決のまま

Microsoft の2023年9月のキー取得に関する投稿は当初、詳細なクラッシュダンプの説明を提供した。それによれば、2021年4月に一般消費者向け署名システムで発生したクラッシュ、企業のデバッグ環境に移動したクラッシュダンプ、キー素材を見逃した認証情報スキャン、その後のエンジニアアカウントの侵害が記述されていた。この話が公的な根本原因の説明となった。2024年3月、Microsoft は主張を狭める修正を追加した。すなわち、影響を受けたキーを含むクラッシュダンプは発見されておらず、クラッシュダンプによる経路は立証された事実ではなく有力仮説に留まる、と。

CSRB はこの不確実性を中心的な問題とした。Microsoft が多くの仮説を調査したものの、Storm-0558 がどのように、そしていつ2016年の MSA 秘密キーを入手したのか正確には未だ分かっていない、と報告した。この未解決の経路は単なる注記ではない。取得経路が不明であるならば、プロバイダーは同じ経路が完全に閉鎖されたことを公に証明できない。キー管理を強化し、署名システムを隔離し、ログを改善し、ローテーションを自動化し、将来の被害範囲を縮小することは可能だ。それらは実際の管理策である。しかし、窃取の連鎖を遡及的に確立するものではない。

したがって、説明責任は二つのカテゴリーに基づくべきである。第一は、立証された、または強く支持される障害である。すなわち、古いキーが信頼され続けたこと、一般消費者と法人の境界を越えて検証が失敗したこと、強化されたログが顧客に広く利用可能でなかったこと、そして Microsoft の初期の公開説明が取得経路の確実性を誇張していたことである。第二は残留する不確実性である。すなわち、キーがどのようにして Microsoft の管理から離れたのか、関連する機密素材が露出したかどうか、そして完全な内部証跡がそもそも存在したのかどうかである。

この区別は細かい話ではない。顧客は根本原因の説明を用いて、修復が障害に見合うかを判断する。もしクラッシュダンプ経路が立証されていれば、クラッシュダンプの取り扱いと企業デバッグ環境が直接の閉鎖点となる。経路が不明であれば、修復はより広範になる。キーの隔離、ローテーション、資産管理、ログ、トークン検証、最小特権、開発者環境の統制、そして独立した検証が必要となる。経路が未解決のままならば、公的な保証の負担はより重い。

タイミングのせいで、Microsoft の修正も説明責任の記録の一部となった。CSRB は、Microsoft が3月の公開訂正より前に、9月の説明が不正確であることに気付いていたと報告した。プロバイダーはインシデント説明において誠実な誤りを犯すことがある。誤りを発見した後の義務は、それを迅速かつ明確に訂正することだ。クラウドの信頼基盤において、不正確な根本原因の説明は、主要な被害経路が閉鎖されたかどうかについて顧客をミスリードする可能性がある。

被害の管理は検証とキー操作から始まった

公表された緩和措置の順序は、封じ込めが単一のスイッチではないことを示している。Microsoft は、OWA が GetAccessTokenForResource で発行されたトークンを更新のために受け付けるのを停止し、取得された MSA キーで署名されたトークンの OWA での使用をブロックし、キーを交換し、インシデント期間中有効だった MSA 署名キーを失効させ、強化されたシステムから新しいキーを発行し、影響を受けた一般消費者向け顧客のトークン利用を禁止することで過去に発行されたトークンが使われないようにした、と述べた。これは段階的な被害管理プログラムだった。

この順序はトークン被害の性質を示している。偽造トークンの活動は、更新の挙動、キャッシュされたメタデータ、下流サービス、過去に発行されたトークン、そして一般消費者と法人の信頼境界を通じて存続しうる。プロバイダーは、誤った信頼決定が生き残っているあらゆる場所を見つけなければならない。一つの経路をブロックすることは将来の生成を止めるかもしれないが、既存のトークンは有用なまま残る。キーをローテーションしても、サービスがキーやトークンをキャッシュしている場合、即座に全てのアーティファクトを無効化できないかもしれない。更新エンドポイントは、閉鎖されなければ被害を拡大しうる。

顧客はこの順序を理解する必要がある。なぜならそれが調査に影響するからだ。キー交換前にアクセスされたメールボックスは、経路が後に閉鎖されてもレビューが必要かもしれない。あるサービスでは受け付けられ別のサービスでは拒否されるトークンは、対象範囲を狭めることができる。更新経路はアクセス期間を変化させる。したがって、公開情報では、単に問題が緩和されたと述べるだけでなく、どの信頼決定が変更され、顧客にとってどのような残余証拠が関連し続けるかを説明すべきである。

Microsoft の技術報告書は、多くのインシデント開示よりも明確な緩和の順序を提供した。それは強みである。公開情報の限界は、顧客が依然としてサービス側の証明を Microsoft に頼らざるを得なかったことだ。顧客は内部の検証変更やキー失効の影響を全て独立して検証することはできない。それがクラウド信頼基盤の性質である。それにより、プロバイダーには正確で、検証可能で、訂正された説明を公表する負担が増す。

このインシデントはまた、なぜキーのライフタイムが、単なる暗号衛生だけでなく運用リスクとして重要なのかを示している。意図されたライフサイクルを超えて信頼され続ける長寿命のキーは、攻撃者により大きな価値目標とより長い有用期間を与える。CSRB は、Microsoft の一般消費者向け署名キーのローテーションが手動化され、その後停止に関する懸念から一時停止され、自動化された代替手段が完了していなかったことを発見した。それは可用性とセキュリティのトレードオフであり、その先送りのコストは機密性のインシデントとして現れた。被害の運用管理には、キーロールオーバーを退屈なものにし、サービス停止の恐怖がセキュリティライフサイクルを凍結させないようにすることが含まれる。

ログが公的説明責任の要だった

国務省は強化されたメールボックスアクセスログを通じて不審な活動を検知した。この事実がインシデントを変えた。それは、プロバイダーが緩和を主導していても、顧客が重要なシグナルを提供できることを示した。同時に、ライセンスの問題も浮き彫りにした。当時、CISA と FBI の勧告は MailItemsAccessed 監査イベントの重要性を強調し、関連するログが上位のライセンスに紐付いていると指摘した。CISA は後に、Microsoft が重要なログを追加費用なしで拡大するとコミットしたことを公に賞賛した。

ログは単なる顧客向け機能ではない。それは被害管理の基盤である。もし顧客がメールボックスアイテムへのアクセスを見ることができなければ、プロバイダー起因のトークン障害の悪用を確実に検知することはできない。もしログの保存期間が短すぎれば、事後の発見は残存するものに制限される。もし重要なイベントがプレミアム機能として課金されていれば、プロバイダーの説明責任が最も必要な時に、下位層の顧客はより弱い証拠しか持てないかもしれない。

2023年7月の Microsoft のログに関する発表は、標準顧客向けに詳細なメールアクセスログと30以上のその他の監査イベントへのアクセスを拡大し、デフォルトの Audit Standard 保存期間を90日から180日に延長することを約束した。CISA、OMB、ONCD、および Microsoft は後に、連邦機関向けのログを拡張し、自動有効化と180日のデフォルト保存を発表した。これらの変更は、証拠を有料アドオンからベースラインのセキュリティ期待へと移行させたため、実質的なものだった。

この説明責任の教訓は、ある一つのログ種別よりも広範だ。クラウドプロバイダーは、プロバイダー側の管理不全を検知するために必要なログを、サービスの安全層の一部として扱うべきである。顧客は、プロバイダーのキーや検証の欠陥が悪用されたことを発見するために、プレミアムな可視性を購入する必要があってはならない。プロバイダーは高度な分析、ストレージ、管理された検知に課金することはできる。しかし、顧客データへのアクセスを再構築するために必要な生のセキュリティイベントは、よりベースラインに近いところにあるべきだ。

このインシデントは、検知が顧客からもたらされ得ることも示した。国務省が異常を察知し、Microsoft が後に調査して偽造トークンの経路を特定した。この流れが健全であるためには、顧客がアラームを上げるための十分なログを持ち、それをエスカレーションする十分なチャネルを持っていなければならない。国務省の強化されたログと調査がなければ、公共のタイムラインはもっと悪化していたかもしれない。プロバイダー主導の緩和は、顧客による検知の成功を消し去るものではない。

公共部門の事業継続には信頼される通信が含まれる

影響を受けたアカウントには、公共部門や政府関連のメールボックスが含まれていた。国務省は後に約6万通のメールが10のアカウントからダウンロードされ、侵害されたシステムは非機密扱いであり、機密メールはハッキングされていないと述べた。CSRB は、世界中で22組織と500人以上の個人が影響を受けたと特定した。これらの詳細は被害を慎重に捉えている。それは政府メールの可用性の崩壊ではなく、公開記録はメッセージの内容を開示していない。それでも、重大な信頼される通信の破綻であった。

現代の公共部門の業務は、外交、商取引、政策、日程調整、交渉、そして行政の調整をクラウドメールに依存している。機密性の喪失は、サービスがオンラインのままであっても行動を変化させうる。担当者は通信が読まれたものと想定せざるを得ず、情報源や計画は保護を必要とし、将来の通信は別のチャネルに移行するかもしれない。サービスが停止しなくとも、運用上のコストが課せられるのである。

そのため、Storm-0558 はサイバーセキュリティだけでなく公共部門の事業継続の問題にも属する。継続性はしばしば可用性によって定義される。すなわち、組織は業務を継続できるか？ より成熟したモデルは信頼された運用を含む。すなわち、組織は敵対者による可視性なしに、本来の公的機能のためにサービスを使い続けられるか？ 技術的には機能しているが、敵対者に秘かに読めるメールボックスは、劣化したインフラである。

政府が依存的な顧客であるため、公的説明責任の問題はより先鋭化する。政府は理論上、調達要件を設定し、ログを要求し、監視を実施し、ワークロードを移行できる。実際には、中核的なアイデンティティと通信を少数のクラウドプロバイダーに依存している。この依存は、プロバイダーによる修復が単なる顧客サービスではないことを意味する。それは公共基盤の修理である。

議会の書簡、公聴会、そして CSRB のレビューはこの依存を反映していた。それらは裁判所の判決や規制上の責任認定を確立したわけではないが、プロバイダーのセキュリティ文化、キー管理、そしてログの選択を公共の視野に晒した。それは、公的機関が使用する共有クラウドアイデンティティ基盤の障害に対して適切なことである。

セキュリティ文化が運用管理となった

CSRB の報告書は一つのコードの欠陥に留まらなかった。それは Microsoft のセキュリティ文化を批判し、一連の回避可能な障害だったと述べた。この捉え方は重要である。なぜなら、署名キーのライフサイクル、トークン検証、ログのデフォルト、企業ネットワークの侵害、根本原因の訂正、顧客の可視性は、孤立したバグではないからだ。それらは組織の優先順位、エンジニアリングシステム、リスク受容、そしてガバナンスの結果である。

セキュリティ文化という言葉は漠然と聞こえるかもしれない。このインシデントでは具体的な形をとった。手動のキーローテーションプロセスが停止の懸念から一時停止され、自動化された代替手段は完成しなかった。検証の前提が一般消費者と法人の境界を越えた。プレミアムログが顧客の可視性を制限した。初期の公開説明は、Microsoft が修正が必要だと認識した後も長く、過度に確定的であり続けた。これらは態度ではなく、運用上の決定と管理状態である。

Microsoft は Secure Future Initiative とその後の拡大で応えた。同社は、自動化されたキー管理、ハードウェアセキュリティモジュール、コンフィデンシャルコンピューティング、標準のアイデンティティ SDK、ステートフルな検証、キー分割、拡張ログ、ガバナンスの変更、副 CISO の配置、業績評価の変更、幹部報酬との連動について説明した。ブラッド・スミスの議会証言は、CSRB が提起した全ての問題を受け入れ、推奨事項の実施に向けたステップを述べた。

これらのコミットメントは実質的である。しかし、本稿でレビューした公開情報源では、その多くがプロバイダーによる自己報告でもある。したがって、説明責任の基準は、発表されたプログラムと、独立して検証された運用の有効性を区別すべきである。顧客と政府は、キーがインベントリ化され、ローテーションされ、隔離され、緊急ロールオーバーが可能であること、検証ライブラリが発行者とスコープの境界を強制すること、サービスが標準の検証を回避できないこと、ログが保存され利用可能であること、証拠が変化した際に根本原因の訂正が速やかに公表されること、の証拠を求めるべきである。

プロバイダーによる自己報告は無意味ではない。それによって多くのクラウド管理が初めて可視化される。しかし、予防可能だった信頼基盤の障害の後では、自己報告は測定可能な保証へと成熟すべきである。公衆は内部の細部全てを必要としない。インシデントにちなんで名付けられた管理策が、機能し、テストされ、統治されていることを知るための十分な証拠を必要とする。

トークン検証は退屈で、中央化され、回避困難であるべき

一つの技術的教訓は、トークン検証が、各サービスチームが個別に全ての境界条件を覚えていることに依存すべきではない、ということだ。Microsoft の事後説明は、共通のメタデータエンドポイントと、影響を受けた経路において発行者やスコープを正しく検証できなかったことを説明した。現代のアイデンティティシステムは複雑だが、その複雑さこそが、検証を十分に保守されたライブラリと堅牢化されたサービスパターンに中央化すべき理由である。

Microsoft の現在のアイデンティティドキュメントは、発行者、オーディエンス、署名キー、ディスカバリーメタデータ、アクセストークン、キーロールオーバーといった概念を説明している。これらの文書は顧客向けのリファレンスであり、2023年のコード状態の証明ではない。それでもなお、管理ロジックを示している。すなわち、有効な署名だけでは不十分で、トークンが異なるアイデンティティレルム、オーディエンス、テナント、またはサービスに対して発行された場合には問題がある。暗号的な有効性は一つの問いに答える。認可の文脈は別の問いに答える。

プロバイダーの仕事は、安全な経路を容易な経路にすることだ。サービスがアイデンティティトークンを受け入れる必要があるならば、発行者、オーディエンス、テナント、スコープ、キーの来歴、そしてメタデータ更新ルールを強制する標準ライブラリを使用すべきである。逸脱は稀であり、レビューされ、ログに記録され、テストされるべきである。緊急のキーロールオーバーは訓練されるべきである。サービスはデフォルトでありえない組み合わせを拒否すべきである。監視は、署名キー、発行者、リソース、テナントの関係が理にかなわないトークンを検出すべきである。

プロバイダーの検証が退屈なものになれば、顧客は利益を得る。顧客は、Microsoft の各サービスチームがトークン検証を正しく実装したかどうかを尋ね回る必要がなくなる。中央のアイデンティティ管理と独立した保証に依拠できるべきである。Storm-0558 インシデントは、体系的であるべき境界がサービス固有になりすぎて、欠陥が重大な影響を及ぼしたときに何が起こるかを示した。

この教訓は Microsoft を超えて広がる。あらゆる大規模クラウドプロバイダーは、製品、テナント、アイデンティティレルム、API をまたぐトークン基盤を運用している。中央化された検証、自動化されたキーライフサイクル、そして顧客に可視な証拠は、共通の安全要件である。このインシデントは、その障害が政府のメールに及んだために、これらの要件を公のものとした。

残余の不確実性が保証の負担を変える

一部のインシデントは、正確な根本原因と正確な終結をもって終わる。Storm-0558 は、少なくとも公開記録ではそうではない。キー取得の経路は未解決のままである。CSRB は、Microsoft がキーがどのように、そしていつ取得されたのかを特定できなかったと報告した。この不確実性は修復を妨げない。保証の負担を変えるのである。

窃取の経路が不明である場合、プロバイダーはより広範なクラスの潜在的な障害を想定しなければならない。キー素材が操作上のミスで署名環境から持ち出されたかもしれない。企業の侵害を通じて露出したかもしれない。残存するログに捕捉されていないプロセスで誤って扱われたかもしれない。その答えは、証拠を超えた公的な推測ではない。答えは、ライフサイクル全体を強固にすることである。すなわち、生成、保管、使用、ローテーション、廃棄、ログ、デバッグ、バックアップ、インシデント対応、そして特権アクセスである。

残余の不確実性は顧客の信頼にも影響する。顧客は全ての事実が回復可能ではないことを受け入れられる。しかし、曖昧な終結を受け入れるよう求められるべきではない。プロバイダーは、何が未解明か、どの証拠が欠けていたか、不確実性にもかかわらずどの管理策が強化されたか、将来の証拠がどのように保全されるかを述べるべきである。透明性のある未知は、後に訂正が必要になる過信した説明よりも多くの信頼を築きうる。

CSRB のプロセスは、立証された事実と仮説を公的に区別させることで、その透明性の創出を助けた。また、証拠の大部分がプロバイダー内部に存在するクラウドインシデントに対する独立したレビューの価値を示した。顧客は Microsoft の署名環境について独自に完全な調査を行うことはできない。官民の独立したレビューは裁判所ではないが、プロバイダーが管理する事実を公的説明責任のために十分に可視化させることができる。

将来の保証は継続的であるべきだ。重大なインシデント後の単発の報告書は有用だが、キーライフサイクルとトークン検証は継続的な管理策である。政府と企業顧客は、緊急キーロールオーバーテスト、検証ライブラリの採用、ログのカバレッジ、根本原因の訂正プロセスについて、定期的な証拠を求めるべきである。管理の破綻は静的ではなかった。保証も静的であってはならない。

証拠の非対称性が顧客の上限を規定した

Storm-0558 はまた、顧客側の調査に硬い上限があることを露呈した。顧客はメールボックスの監査イベントを調査し、不審なアクセスを相関分析し、テナントログを保全し、Microsoft にエスカレーションすることができる。しかし、署名環境を調査したり、内部の全ての Microsoft キーの信頼決定を一覧したり、そのキーが他のサービスに対しても使われたかどうかを証明したり、攻撃者がキーをクラッシュダンプ、企業侵害、あるいは他の経路で入手したのかを特定したりすることはできない。最も重要な証拠はプロバイダーの内部に存在した。

この非対称性はクラウドサービスに内在するものだが、障害がプロバイダーのアイデンティティ基盤に関わる場合には深刻になる。通常のアカウント侵害では、顧客はユーザーデバイス、フィッシングメッセージ、MFA プロンプト、条件付きアクセスポリシー、ローカルログをレビューできるかもしれない。Storm-0558 では、決定的な問いは、なぜ Microsoft サービスが偽造トークンを受け入れたのか、そして攻撃者が Microsoft 管理の署名素材をどのように入手したのか、であった。その問いは顧客の手の届かないところにあった。

したがって、顧客の可視性が低下するほど、プロバイダーの証拠に関する義務は増大する。Microsoft は内部システムを調査し、利用可能な証拠を保全し、欠落を説明し、公開された主張を訂正し、顧客向けログをより利用しやすくしなければならなかった。顧客はストーリーの内部の半分を Microsoft に信頼せざるを得なかった。CSRB のレビューは、プロバイダーが保持する事実に独立した公的調査の目を向けさせることで、その信頼ギャップを縮小したが、全ての未知を排除したわけではない。それは Microsoft や他の参加者が再構築できたことを報告することはできたが、存在しないログを作り出すことはできなかった。

証拠の非対称性は設計上のインプットであるべきだ。クラウドプロバイダーは、緩やかに発見されるアイデンティティの悪用の調査を支援できるよう、セキュリティ関連の内部ログを十分長く保存すべきである。キー管理記録、署名システムのアクセスログ、デバッグ環境の制御、緊急ローテーションの記録を維持すべきである。顧客には、プロバイダー起因の信頼アーティファクトの悪用を検知するのに十分なテナントログを提供すべきである。ログが欠落している場合や保存期間が切れた場合には、その制限も公表すべきである。証拠の限界について沈黙することは、顧客に自信あるいは隠蔽のいずれかを推測させる。どちらも有用ではない。

顧客は、調達やリスクレビューに証拠に関する期待を盛り込むことで対応できる。デフォルトでどの監査イベントが含まれるか、プロバイダー側のログはどれだけ保存されるか、プロバイダーが管理する障害後にどのようなインシデントサマリーが共有されるか、主要な信頼インシデントに対して独立したレビューが利用可能かを尋ねるべきである。その回答が顧客に完全な内部アクセスを与えることは決してない。それでも、プロバイダーが証拠を製品の一部として扱っているかどうかを確かめることはできる。

緊急キーロールオーバーは事業継続能力である

キーロールオーバーはしばしば暗号のメンテナンスタスクとして論じられる。Storm-0558 はそれが事業継続能力でもあることを示した。署名キーが侵害されたと疑われるか確認された場合、プロバイダーは許容できない規模で正規の認証を破綻させることなく、それをローテーションもしくは失効させなければならない。すなわち、アプリケーション、サービス、メタデータエンドポイント、キャッシュ、クライアント、検証ライブラリはキーの変更に耐えなければならない。ロールオーバーの経路が脆弱であれば、セキュリティチームはためらい、遅れ、古いキーを本来よりも長く信頼したままにするかもしれない。

CSRB の一般消費者向け署名キーのローテーションに関する議論はこの点を具体的にした。Microsoft はサービス停止の懸念から手動のローテーションを一時停止し、自動化された代替を完了していなかった。その決定は短期的な可用性リスクを低減したかもしれないが、古いキーを信頼されたままにした。より深い問題は、単にキーの年齢ではない。定常時と緊急時の両方の変更を扱える、安全で、自動化され、測定可能なロールオーバー経路が存在しなかったことである。

顧客向けの現在の Microsoft 署名キーロールオーバーガイダンスは、キー変更のプログラマティックな扱い、メタデータの更新、標準ライブラリを強調している。同じエンジニアリング原則がプロバイダー内部にも適用される。サービスはキーの変更を想定し、検証ライブラリは安全に更新され、緊急ロールオーバーは現実的な条件でテストされるべきである。ローテーションが停止の引き金として恐れられるならば、そのシステムはセキュリティ管理を可用性リスクに変換している。成熟した基盤は、ローテーションを実行するのに十分普通のものにする。

緊急ロールオーバーには顧客コミュニケーションの要素もある。侵害の疑いの後にプロバイダーがキーをローテーションする際、顧客は自分のアプリケーションや統合が対応を必要とするか、トークンキャッシュが影響を受けるか、認証の失敗が予期されるか、古いトークンが有効であり続けるかを知る必要があるかもしれない。Storm-0558 の間、Microsoft は影響を受けた Exchange Online 経路を制御していたが、より広範な原則はクラウドアイデンティティ全体に当てはまる。キーの安全性と顧客の事業継続は結びついている。

これが、キー管理がレジリエンスの指標として報告されるべき理由である。プロバイダーは、集約レベルで、キーがインベントリ化されているか、オーナーが割り当てられているか、スケジュール通りにローテーションされているか、ハードウェア支援の管理で保護されているか、緊急訓練の対象か、年数やポリシー逸脱が監視されているかを開示できる。顧客は成熟度を評価するのに秘密キーの素材を必要としない。キーが忘れられた信頼アンカーになることを許されていないことの証拠を必要とする。

ベースラインログが不確実性のコスト負担を変えた

Microsoft のログ拡大以前は、最も有用なメールボックスアクセス証拠は全ての顧客に等しく利用可能ではなかった。それは単なる製品パッケージの詳細ではない。不確実性を割り当てているのだ。関連するログを持たない顧客は、侵害を想定するか、外部調査により多くの費用をかけるか、より弱い結論を受け入れざるを得ないかもしれない。ログを持つ顧客は不審なアクセスを特定し、対象範囲を狭め、証拠をもってエスカレーションできる。

国務省は異常なメールボックスアクセスを検知するのに必要な強化されたログを持っていた。その成功は良好なテレメトリが成しうることを示した。同時に、公平性の問題を提起した。プロバイダー起因のアイデンティティ障害を検知する能力が、なぜライセンス階層に依存すべきなのか。重要なログは追加費用なしで利用可能であるべきという CISA の公的声明は、製品決定を説明責任の問題へと変えた。

したがって、Microsoft が Audit Standard のイベントと保存期間を拡大するというコミットメントは、単なる顧客満足のジェスチャーではなかった。それは被害配分のモデルを変えた。ベースライン顧客がより多くのログを受け取れば、プロバイダーの管理が破綻した際に検知と範囲特定に参加できる。連邦機関が自動有効化とより長い保存期間を得れば、事後再構築への依存が減る。より多くのログがキー侵害を防ぐわけではない。顧客が盲目である期間を減らすのだ。

ログは法的・運用上の確実性にも影響する。どのメールアイテムがアクセスされたかを証明できる組織は、通知、内部修復、外交対応、事業継続措置を適切に調整できる。ログがない組織は、より広い範囲の関係者を被害対象と見なさざるを得なくなるかもしれない。その意味で、ログは二次的被害を減らす。攻撃者を見つける助けになるだけでなく、過度に広範な不確実性を避ける助けにもなる。

ベースライン標準は明確であるべきだ。特に根本原因がプロバイダー管理のインフラにある可能性がある場合に、顧客データへの不正アクセスを検知するために必要なイベントは、サービスの一部として含まれるべきである。高度な相関分析、マネージド検出、長期アーカイブ、分析はプレミアムな提供であり続けてよい。顧客データがアクセスされたかどうかを知るために最低限必要な証拠が、贅沢品であってはならない。

プロバイダーによる訂正はインシデント対応の一部である

Storm-0558 はまた、公的訂正を運用上の説明責任の一部とした。Microsoft は初期のインシデント通知、技術分析、そしてキー取得調査の投稿を公開した。9月の投稿は詳細な説明を提供したが、後に絞り込む必要が生じた。2024年3月の訂正は、単なる歴史的な脚注の編集ではなかった。それは、顧客が根本原因について責任を持って信じうることを変えた。

インシデント対応ではしばしば、公開コミュニケーションが技術的修復とは別物として扱われる。クラウドの信頼インシデントでは、それらは結びついている。プロバイダーの収束を信用するかどうか判断する顧客は、どの管理策が破綻したかについて正確な説明を必要とする。もし取得経路がクラッシュダンプとして説明されれば、顧客はクラッシュダンプとデバッグ環境の管理によって問題が閉じられることを期待する。もし取得経路が不明なら、顧客はより広範なキーライフサイクルの強化と、より強固な証拠保全を期待する。その言葉が保証要求を決定づける。

したがって、訂正は迅速で、目に見え、明示的であるべきだ。プロバイダーは、何がなぜ変わったのかを明確に述べずに、バージョン管理された投稿の中で変更された根本原因の確信度を埋没させるべきではない。Microsoft は実際に2024年3月のアップデートを追加し、CSRB は後にその訂正のタイミングと重要性を議論した。説明責任の教訓は、根本原因に対する確信度そのものが開示された事実である、ということだ。確信度が「これが起きた」から「これが我々の有力な仮説に留まる」に低下した時、顧客はそれを知る必要がある。

この基準はプロバイダーと顧客の双方を守る。誠実な訂正は、公開記録が誤った説明の周りで硬直化するのを防ぐ。それは修復が適切に拡大されることを可能にする。それは、プロバイダーが証拠と物語上の都合を区別する意思があることを示す。高い信頼を要するクラウド基盤において、その区別はサービスの信頼性の一部である。

責任共有には管理サーフェスマップが必要

Storm-0558 は、曖昧な責任共有の言葉に対する有効な解毒剤である。「責任共有」というフレーズは、管理サーフェスを明示しなければ霧となりうる。このインシデントにおいて、Microsoft はキーライフサイクル、トークン検証、サービス側の緩和、ベースラインログの可用性、内部証拠の保全、そしてほとんどの根本原因の証明を管理していた。顧客はテナント監視、インシデントエスカレーション、メールボックスレビュー、アカウント衛生、ポリシー設定を管理していた。政府は調達圧力、監視、公的レビューメカニズムを管理していた。これらの役割は異なる。

管理サーフェスマップは二つの悪い主張を防ぐ。第一の悪い主張は、顧客は自身のクラウドセキュリティに責任があり、したがってインシデントを防ぐべきだったというものだ。これは、顧客が Microsoft 管理の素材で署名された偽造トークンを Microsoft サービスが受け入れるのを防げなかったため、破綻する。第二の悪い主張は、プロバイダーが根本原因を管理していたため、顧客には意味のある役割がなかったというものだ。これも、国務省の検知、顧客ログ、エスカレーションが公的な対応を実質的に変えたため、破綻する。

より良いモデルは四つの問いを立てる。このクラスの障害を誰が防げたか？ 誰がそれを最初に検知できたか？ 誰がそれを封じ込められたか？ 誰がその範囲を証明できたか？ Storm-0558 に対しては、Microsoft が最も強力な予防と封じ込めの管理を持っていた。顧客、この場合は国務省は、強化されたメールボックスログを所持し使用したため、決定的な検知の役割を担った。範囲の証明は共有されていたが非対称的だった。顧客はログが存在すれば自分のテナントを調査できたが、Microsoft はプロバイダー側の信頼とキーの証拠を説明しなければならなかった。

調達はそのマップを反映すべきだ。クラウドメールとアイデンティティを購入する顧客は、稼働時間とコンプライアンス認証だけでなく、キーロールオーバー、トークン検証、発行者境界テスト、デフォルトの監査イベント、プロバイダー側のログ保存、インシデント訂正ポリシー、独立したレビューの選択肢についても尋ねるべきである。これらは難解な管理策ではない。それらは、プロバイダーの信頼ファブリックが破綻したときに何が起こるかを決定する管理策である。

公的機関には追加の義務がある。なぜなら、その依存が市場標準を形成しうるからだ。政府顧客が重要なログをベースラインとするよう主張すれば、プロバイダーはより広範なユーザー向けに提供内容を変更するかもしれない。Storm-0558 後のログ拡大は、公的説明責任がデフォルトのセキュリティ態勢を改善できることを示している。課題はその改善をインシデント主導ではなく体系的にすることである。

タイポグラフィと可読性に関する注記

タイポグラフィは、書き言葉を読みやすく、理解しやすく、視覚的に魅力的にするために文字を配置する技術と技法である。書体の選択、ポイントサイズ、行長、行間、文字間隔の調整を含む。

• タイポグラフィは、15世紀にヨハネス・グーテンベルクによる活版印刷の発明と共に始まった。
• 主要な要素は、フォント選択、カーニング、トラッキング、行送りである。
• 良いタイポグラフィは可読性を高め、デザインにおいて雰囲気やトーンを伝える。

説明責任の試金石

Microsoft Storm-0558 は、トークン被害における運用管理を公的説明責任の試金石とした。なぜなら、決定的な管理策は Microsoft のクラウド内部に存在したからだ。顧客は自分のメールボックスを検知、エスカレーション、調査することはできたが、Microsoft だけがキーを交換し、検証を修正し、トークン更新の挙動を変更し、ベースラインログを拡大し、内部の証拠の欠落を説明することができた。

より良い基準は、プロバイダーが検証可能な被害管理である。クラウドアイデンティティプロバイダーは、全てのアクティブな署名キーを把握し、自動化されテストされた経路でキーをローテーションし、標準ライブラリを通じてトークン検証を強制し、ありえないトークンの使用を検知し、遡及分析のために証拠を十分長く保存し、プロバイダー起因の管理不全を検知するために必要なベースラインログを顧客に提供すべきである。根本原因の仮説が変わった際には、プロバイダーは速やかに記録を訂正すべきである。

未解決のキー取得経路は、隠蔽すべき不面目ではなく、教訓の一部である。クラウド顧客は、被害の全クラスが縮小されていることをプロバイダーが証明すれば、正直な不確実性と共に生きていける。最も特権的な障害が、顧客が被害を発見した後でなければ説明されないような信頼システムと安全に共存することはできない。