Okta のサポートシステム侵害が露呈した、クラウドアイデンティティの隠れた依存関係

要約

Okta は、攻撃者が侵害されたサポートシステムのサービスアカウントを使用して、134 社の顧客に関連するファイルにアクセスし、セッションアーティファクトを再生して 5 件の顧客セッションを乗っ取ったことを確認した。その後の調査で、攻撃者が影響を受けた Okta サポートシステムの全ユーザーの氏名とメールアドレスを含むレポートをダウンロードしていたことが別途判明した。
直接の引き金は盗まれた認証情報だったが、実質的な責任はその認証情報を有用にした管理策にまで及ぶ。それには、特権的なサポートアクセス、サニタイズされていない診断アーティファクト、不完全なログ解釈、譲渡可能な管理者セッション、遅延した顧客横断的エスカレーション、そして ID プロバイダーが自らの侵害を検出するために顧客の支援に依存する通知プロセスが含まれる。

Okta の 2023 年サポートシステム侵害において、最も重大な事実はヘルプデスクが侵害されたことではない。重要なのは、ヘルプデスクが特権的な ID 操作に極めて近い位置にあり、ブラウザのトラブルシューティングファイルが顧客の管理者のベアラー認証情報として機能し得た点である。

Okta は本番サービスが引き続き稼働し、侵害されなかったと述べた。その境界は重要だ。これは、攻撃者がコア認証プラットフォームを突破したり、Okta トークンを自由に偽造したり、全顧客のテナントを読み取ったりした証拠ではない。しかし、その境界は説明責任の逃げ道にはならない。顧客は無関係なチケットツールに無害なスクリーンショットをアップロードしたのではない。管理者が ID 統制プレーンを操作している間に作成されたブラウザ記録をアップロードしたのだ。一部の記録には有効なセッションアーティファクトが含まれていた。サポートリポジトリにアクセスされると、攻撃者はサプライヤー運用のサポート環境から、顧客運用の Okta テナントへ、元のセッションを作成した認証手順を繰り返すことなく移動できた。

この一連の流れは、クラウド依存の有用なテストケースとなる。ID プロバイダーのセキュリティ表面は、契約書やアーキテクチャ図に記載されたログインサービスよりも広い。それには、ケースポータル、そのポータルを管理する ID、サポートが顧客に収集を依頼する診断エビデンス、それを保管するサードパーティシステム、顧客がアラームを上げたときに利用可能なログ、そのアラームを受け取る人々とチャネル、プロバイダーが顧客テナント全体で露出したセッションを無効化するメカニズムが含まれる。サポート経路はシステムトポロジー上は本番環境に隣接していたが、顧客の管理者権限を通じて機能的に本番環境と接続されていた。

また、このインシデントは不正利用の連絡における経済的側面の試金石でもある。3 社の顧客が、Okta 自身が顧客横断的な診断を完了する前に、不審なアクティビティを検出したと公表した。各社の防御担当者はイベントの再構築、自社エンドポイントの除外、サポート経由でのエスカレーション、指標の提供に時間を費やした。その作業は他のすべての顧客にとって貴重な情報を生み出した。プロバイダーはサポートシステム全体でレポートを関連付けることができる唯一の立場にあったが、最初の有用な関連付けには時間がかかり、ある顧客から提供された IP アドレスに依存した。警告を生成するコストは分散していたが、それに基づいて行動する能力は集中していた。

2 つの露出、増え続ける数字ではない

公の説明では、Okta が当初は顧客の 1％が影響を受けたと発表し、後に全顧客が影響を受けたと認めた、と単純化されることが多い。この手短な表現は、2 つの異なるデータセットと 2 つの異なる種類のリスクを覆い隠している。

2023 年 10 月 20 日、Okta の最初の公開アドバイザリは、脅威アクターが盗んだ認証情報を使用してサポートケース管理システムにアクセスし、特定の顧客がアップロードしたファイルを閲覧したと述べた。HTTP Archive（HAR）ファイルには、なりすましを可能にする Cookie やセッショントークンが含まれる可能性があると警告した。アドバイザリは、影響を受けた顧客に通知済みであること、サポートシステムは本番の Okta サービスとは分離されていること、Auth0/CIC ケース管理システムは影響を受けていないことを伝えた。

2023 年 11 月 3 日、Okta の根本原因と修正措置に関する説明では、そのファイルアクセスの露出が定量化された。9 月 28 日から 10 月 17 日にかけて、攻撃者は Okta の 134 社の顧客（全顧客の 1％未満）に関連するファイルへの不正アクセスを取得した。一部はセッショントークンを含む HAR ファイルだった。Okta は、攻撃者がそれらのトークンを使用して 5 社の正規セッションを乗っ取ったと述べた。そのうち 3 社（1Password、BeyondTrust、Cloudflare）は後に独自の報告を公開した。

2023 年 11 月 29 日、Okta は攻撃者が実行したレポートを再作成した後、更新されたインシデント通知で 2 つ目の露出を開示した。攻撃者は、影響を受けたカスタマーサポートシステムの全ユーザーの氏名とメールアドレスを含むレポートをダウンロードしていた。影響を受けた利用者には、Workforce Identity Cloud と Customer Identity Solution の顧客が含まれ、別のサポートシステムを使用する FedRAMP High および Department of Defense Impact Level 4 環境の顧客は除外された。Auth0/CIC サポートケースシステムも再び除外された。Okta によると、レポート内のユーザーの 99.6％については、記録された連絡先情報はフルネームとメールアドレスのみだった。レポートテンプレートには他のフィールドもあったが、ほとんどは空欄だった。Okta は、ユーザー認証情報や機密性の高い個人データは含まれていなかったと述べた。

これらの事実は、次の 4 つの正確な記述を裏付けている。

134 社の顧客に関連するファイルがアクセスされた。
アクセスされた一部のファイルのセッションアーティファクトが、5 件の顧客セッションの乗っ取りに使用された。
氏名とメールアドレスを含む、はるかに広範なサポートユーザーレポートがダウンロードされた。
レポートのエントリは、その個人のテナントや管理者セッションがアクセスされたことを意味するわけではない。

その後の発見は、セッションハイジャックの確定数ではなく、連絡先データの露出を拡大した。また、10 月の通知の意味を変えた。Okta の最初のアドバイザリは、別のメッセージで連絡を受けていない顧客は、その環境やサポートチケットに影響がないと述べていた。アクセスされたサポートファイルとテナントのアクティビティに関する記述として狭義に解釈すれば、134 社の調査結果と矛盾しない可能性がある。サポートシステム内のあらゆるデータ露出に関する記述として広義に解釈すれば、11 月のレポート再作成によって追い越された。優れたインシデントコミュニケーションは、顧客組織、サポートユーザー、サポートファイル、ライブセッション、標的テナント、確認された下流の侵害など、単位を定義しなければならない。

Okta は 11 月の更新を米国証券取引委員会に提出した Form 8-Kの添付資料として提供した。これにより、その開示は同社の公的な投資家向け記録の一部となった。これは同社の説明を SEC の判断に変えるものではなく、8-K 自体は、その情報が特定の責任目的で提出されたとはみなされず、提供されたものであると述べていた。この違いは重要である。なぜなら、最も詳細な公的事実の説明は、依然として Okta と影響を受けた顧客から得られており、規制当局の公表された裁定からではないからである。

管理者になりすますことができたサポートアーティファクト

HAR ファイルが有用なのは、それが豊富な情報を含むからである。ブラウザのリクエストとレスポンス、タイミング、URL、ヘッダー、ペイロードの詳細、そしてエクスポートとサニタイズの方法に応じて Cookie や認証情報を記録する。その豊富さにより、サポートエンジニアは正確な環境を再現しなくても、顧客のブラウザで何が起こったかを確認できる。また、それまでライブセッション全体に分散していたデータのコンパクトなコピーを作成する。

Okta 独自のHAR 生成ガイダンスでは、この形式をエンドユーザーや管理者のエラーを再現する方法として説明し、ファイルを送信する前に機密情報や個人を特定できる情報を削除または隠蔽するようユーザーに注意を促している。現在のChrome DevTools ドキュメントは、このリスクを異常なほど具体的にしている。デフォルトのサニタイズされたエクスポートではCookie、Set-Cookie、Authorizationヘッダーが除外され、機密データを含むエクスポートは別途有効化する必要がある。現在のブラウザの動作を、2023 年 9 月に顧客が見た正確なインターフェースの証拠として過去に投影すべきではない。しかし、HAR のサニタイズを、サポート記事の警告から収集ツールのデフォルト動作に移行できることを示している。

Okta のインシデントにおける関連するアーティファクトは、一部の Okta ログインフローで説明されているワンタイムのsessionTokenパラメーターではなかった。トークンに関する用語は曖昧になりやすい。Okta のセッション Cookie に関する開発者ガイドでは、ワンタイムセッショントークンを交換して HTTP セッション Cookie を確立でき、その後はブラウザリクエスト全体で Cookie が Okta 組織とアプリケーションへのアクセスを提供すると説明されている。顧客の報告では、アクティブな管理者セッションに紐付いた盗まれた Cookie や認証トークンについて述べられていた。運用上のポイントは、攻撃者がサービスが既存のセッションの証拠として受け入れる、認証後の秘密を取得したことである。

OWASP セッション管理チートシートは、これがなぜそれほど深刻なのかを説明している。認証後、セッション識別子は一時的に、ユーザーを認証するために使用された最も強力な方法と同等になる。FIDO2 キーは新たなフィッシングログインを極めて困難にするが、転送可能なベアラーセッションにより、攻撃者はそのチェックの後から入り込むことができる。このことは、フィッシング耐性のある認証が無駄であることを意味しない。認証の強度とセッションの強度は、別個の管理上の問題であることを意味する。

NIST のセッション管理実装ガイダンスも同様に、セッションハイジャックが認証の失敗と同程度の損害をもたらす可能性があると述べ、保護されたセッションシークレット、定義された有効期間、再認証を強調している。このインシデントでは、診断記録が信頼境界を越えたが、その内部のデータが表すセッションは有効なままだった。HAR ファイルをアップロードする行為は、埋め込まれたすべての秘密を自動的に使用不可にするわけではなかった。Okta は後で露出したセッショントークンを無効化したが、それは関連ファイルが特定された後の対応だった。

より安全な設計原則は、単に「HAR を決して使用しない」ことではない。サポートチームは正確なリクエストコンテキストを必要とする場合がある。原則は、認証された管理者からの診断キャプチャを、作成から削除まで認証情報素材として扱うことである。これには、可能な限り最小権限のアカウントでの収集、自動的なローカルサニタイズ、診断に不可欠なために保持されるフィールドの明示的な識別、転送中および保管中の暗号化とアクセス制限、短い保持期間、すべてのインターフェースをカバーするアクセスログ、機密性の高いキャプチャが受け入れられた場合の無効化または再認証が含まれる。サポートへのアップロードが、有効な管理者セッションがポータブルになる瞬間であってはならない。

顧客が最初の分散センサーだった

顧客の公開報告は、単なる裏付けとなる逸話以上のものだ。サプライヤーのサポートテレメトリがまだ顧客横断的な結論を出していないときに、どの管理策が機能したかを明らかにしている。

1Password：予期せぬ管理イベント

Okta のタイムラインによると、1Password は 9 月 29 日に不審なアクティビティを報告し、その後 10 月 2 日まで両社は繰り返し協議した。同時期の1Password のインシデントレポートは、Okta 環境における予期せぬ管理アクティビティを説明し、後に Okta の最初のファイルアクセスログセットでは、関連する HAR ファイルへの不正アクセスが示されなかったと付け加えた。Okta がサポートシステムの侵害を確認した後、追加のログにより、侵害されたサービスアカウントがそのファイルにアクセスしていたことが示された。1Password の補遺によると、そのファイルはサポートベンダーのシステム内で 2 つの異なるオブジェクト識別子の下に存在しており、最初の分析では 1 つしかカバーされていなかった。

この詳細は、証拠モデルの問題を示している。顧客は当然の質問をした：このケースに添付されたファイルに誰がアクセスしたのか？サポートシステムは、同じ基礎となるファイルを複数のオブジェクトや経路で表現することができた。ある識別子に対して技術的に有効なクエリは、セキュリティの質問に対しては不完全だった。エラーは生のイベントの欠如だけではなく、システムのデータモデルと調査者のオブジェクトモデルとの不一致だった。

1Password は、ユーザーデータや機密情報は一切アクセスされておらず、そのアクティビティは自社の Okta インスタンスに限定されていたと述べた。同社のレポートは、攻撃者が 1Password の本番 Google ID プロバイダーを含む接続を変更して再有効化し、その後 Google 環境へのアクセスに失敗したと説明している。これらの事実は、乗っ取られた ID 管理セッションの到達範囲と限界の両方を示している。攻撃者は ID 設定を調査または変更できたが、下流のアクセスは依然として顧客のアーキテクチャ、対応速度、その他の管理策に依存していた。

BeyondTrust：ポリシー拒否、API ピボット、永続的なエスカレーション

BeyondTrust のインシデント報告は、サポートファイル経路の最も明確な分刻みの説明を提供している。10 月 2 日、Okta サポートの依頼により、BeyondTrust の管理者がセキュリティ以外のサポート問題のために HAR ファイルを生成してアップロードした。そのファイルには API リクエストとセッション Cookie が含まれていた。30 分以内に、攻撃者が匿名化サービスに関連するマレーシアの IP アドレスから管理者のセッションを使用しようとした。

BeyondTrust のデフォルト以外のアクセスポリシーでは、管理コンソールに Okta Verify を使用した管理対象デバイスが必要だったため、最初のコンソールアクセスは拒否された。その後、攻撃者は認証済みセッションを Okta の API 経由で使用し、BeyondTrust によると同じポリシー制限が適用されなかったため、サービスアカウントを装った名前のバックドアアカウントを作成した。BeyondTrust はこのアクティビティを検出し、バックドアが使用される前にアカウントを無効化してアクセスを取り消した。同社は、自社のシステムや顧客へのそれ以上のアクセスの証拠はなかったと報告した。

ここでは、複数の管理策を個別に見ることができる。FIDO2 は管理者の元の認証を保護したが、それ自体では結果のセッションを管理者のデバイスにバインドしなかった。デバイスポスチャはインタラクティブなコンソール経路をブロックしたが、API 経路を同等に制約しなかった。行動検知は、予想される認証履歴なしに現れたセッション、プロキシの使用、稀な管理レポート、および特権的な外観のアカウント作成を捉えた。その後、人間の対応者が試みられた永続化が有用になる前にセッションを終了させた。

BeyondTrust は Okta にとっての外部センサーにもなった。10 月 2 日に Okta に連絡し、10 月 3 日にエスカレーションを依頼し、サポートおよびセキュリティ担当者と協議し、より完全なログを要求し、証拠が Okta のサポート組織内の侵害を示していると主張し続けた。10 月 13 日、同社は後に Okta が決定的な検索を可能にしたと述べた不審な IP アドレスを提供した。これは、顧客が自社のテナント内で影響を確認できる一方、Okta はサポート環境内で共通の原因を確認できたため、顧客が実施したコストのかかる調査作業だった。

Cloudflare：迅速な封じ込め、その後の不完全なローテーション

Cloudflare の最初の10 月のインシデント報告では、Okta サポートチケットから取得された管理者セッショントークンを含むアクティビティを 10 月 18 日に検出したと述べた。攻撃者は Okta プラットフォーム内で 2 つの Cloudflare 従業員アカウントを侵害した。Cloudflare は、Okta から通知を受ける 24 時間以上前にこのアクティビティを検出し、攻撃者が永続性を確立するか、顧客データ、顧客システム、本番ネットワークに到達する前に封じ込めたと述べた。

Cloudflare の対応は、自社のテレメトリとセグメンテーションに依存していた。同社は、対応する認証のないセッション、新規または再有効化されたユーザー、アカウントと権限の変更、MFA 変更、ポリシーオーバーライド、サプライチェーンプロバイダーアクセスの監視を推奨した。これらは、このインシデントの文脈において一般的なチェックリスト項目ではない。有効なセッションと有効なユーザーアクションの間のギャップに対応している。セッションがある場所で開始され、別の場所で再生された場合、サービスは認証された Cookie を認識するかもしれないが、顧客は不可能なシーケンスを目にすることになる。

その後、Cloudflare はサポートアーティファクト自体を管理対象に変えた。同社のHAR Sanitizer プロジェクトは、セッション関連の Cookie とトークンをクライアント側で削除し、一部のトラブルシューティングケースでは、トークン署名を削除しながら診断に有用な構造を保持することができた。これは、ファイルがサプライヤーの管理下に入る前にその価値を下げるため、重要な修正モデルである。トークンの再生を防ぐために、すべてのサポートリポジトリ、従業員アカウント、ログクエリが完璧に機能することを必要としない。

Cloudflare のケースは、迅速な初動封じ込めが完全な根絶と同じではないことも示している。2024 年 2 月、Cloudflare は別のサンクスギビングインシデントを開示し、攻撃者が 10 月の Okta 侵害の際に取得した 1 つのアクセストークンと 3 つのサービスアカウント認証情報を使用したことを明らかにした。Cloudflare は、これら 4 つの認証情報のローテーションに失敗したことを認めた。11 月 14 日以降、攻撃者は同社の自社ホストの Atlassian 環境にアクセスし、内部文書と限られた量のソースコードを閲覧し、まだ本番環境ではないデータセンターのコンソールサーバーへの到達を試みたが失敗した。Cloudflare は、顧客データ、顧客システム、グローバルネットワーク設定には影響がなかったと述べた。

この後の事象は、インシデント全体を顧客に転嫁することなく、説明責任の分析を変える。Okta は認証情報が露出したサポートシステムを管理していた。Cloudflare は、露出したファイルが危険にさらしたシークレットのインベントリとローテーションを管理していた。Cloudflare は自社のサポートアーティファクトが取得されたことを知った時点で、そのアーティファクト内のすべてのシークレットをローテーションする実質的な能力を持っていた。数千のうち 4 つの認証情報を見逃したことで、2 つ目の利用可能な経路が生まれた。Cloudflare はその失敗を公に認め、5,000 以上の本番認証情報のローテーションや広範なフォレンジックレビューを含む、はるかに大規模な強化の取り組みを説明した。責任は各段階の管理に従うものであり、元の侵害に付された単一のラベルではない。

検知と通知のシーケンス

顧客が既に症状を報告している間に攻撃者がアクセスを維持していたため、このシーケンスが中核となる。

Okta の 11 月 3 日のタイムラインによると、脅威アクターの不正アクセスは 9 月 28 日から 10 月 17 日まで続いた。1Password は 9 月 29 日に不審なアクティビティを報告した。Okta はその日調査を開始したが、当初は 1Password 側のマルウェアやフィッシングを疑った。BeyondTrust は 10 月 2 日に不審なアクティビティを報告した。3 社目の顧客が 10 月 12 日に報告した。BeyondTrust は 10 月 13 日に不審な IP アドレスを提供した。10 月 16 日、Okta はその指標を使用して、それまで観測されていなかったサポートシステムのログイベントに関連するサービスアカウントを特定した。10 月 17 日、Okta はそのサービスアカウントを無効化し、セッションを終了させ、アクセスされたファイルを調査し、特定した HAR ファイルに埋め込まれていたトークンを無効化した。

Okta は、その後ログの欠落が範囲を複雑にしたと述べた。10 月 18 日、サポートシステムのログから攻撃者のアクセスの最後の数時間が欠落していることが判明した。クエリを繰り返すと、より完全な記録が返された。10 月 19 日、追加のダウンロードされたファイルを発見し、新たに特定された埋め込みトークンを無効化し、5 番目の標的顧客として Cloudflare を特定し、当時既知のインシデントによって組織が影響を受けたかどうかについて、登録されたセキュリティ連絡先に顧客ベース全体に通知した。公開アドバイザリは 10 月 20 日に発表された。根本原因と修正情報は 11 月 2 日に登録されたセキュリティ連絡先に送信され、11 月 3 日に公開された。

11 月 29 日の範囲拡大は、異なる調査手法によるものだった。Okta は攻撃者が実行したレポートを手動で再作成し、結果のファイルサイズをダウンロードのテレメトリと比較した。調査者の初期フィルターで生成されたテンプレート化されたレポートは、ログ記録されたダウンロードよりも小さかった。フィルターを外すと、出力ははるかに大きくなり、テレメトリとよりよく一致した。Okta は、攻撃者がサポートシステムユーザーのフィルターなしリストをダウンロードしたと結論付けた。その方法は理にかなっており、最終的には生産的だった。その遅れた到着はまた、インシデントの範囲特定が、オブジェクトレベルのアクセスログ、レポートパラメータ、出力サイズ、ユーザーインターフェース経路、アカウントの振る舞い、独立した再構成を最初から組み合わせるべき理由を示している。

この時系列は、原因の異なる少なくとも 4 つの遅延を特定している。

仮説の遅延：最初の顧客報告は、当初顧客側の侵害に起因するとされた。
相関の遅延：複数の顧客報告が、即座にサポートシステムのインシデントに結び付けられなかった。
テレメトリ解釈の遅延：調査員はケースにリンクされたイベントを検索したが、攻撃者はシステムの「ファイル」タブを使用しており、異なるイベントタイプとレコード識別子が生成されていた。
範囲再構成の遅延：ダウンロードされたサポートユーザーレポートの広範さは、フィルターなしの出力を再作成し、ファイルサイズを一致させた後に初めて推測された。

これら 4 つを単一の「通知遅延」と呼ぶのは不正確だろう。Okta は事象を理解する前に完全な通知を出すことはできなかったが、調査と顧客へのコミュニケーションチャネルを管理していた。高信頼度の別々の顧客報告が同じサポートワークフローを指した時点で、詳細がすべて確定する前に予防的アラートを出すかどうかの管理も行っていた。Cloudflare と BeyondTrust は、そのペースを公に批判するか、より迅速な対応を促した。彼らの批判は顧客体験の証拠であり、法的な義務違反の証明ではない。

通知経路にも構造上の弱点があった。サポートシステムはインシデントの一部でありながら、顧客のエスカレーションの通常の経路でもあった。サポート自体が侵害されていると主張する顧客は、プロバイダーのインシデントコマンドに到達するために、通常のサポートケースだけに頼るべきではない。プロバイダーには、テナント全体のレポートを統合する権限を持つ、認証された帯域外のセキュリティチャネルが必要である。顧客には、放置されたメールボックスに行き着かない最新の登録済みセキュリティ連絡先が必要である。双方とも、「当社のテナントに不審なアクティビティがある」と「貴社のサポート環境が共通の発生源である可能性がある」を区別する重大度の表現を必要としている。

トリガー、根本原因、促進条件

確認されたトリガーは、侵害されたサービスアカウントの認証情報の使用だった。Okta によると、このサービスアカウントはサポートシステムに保存されており、カスタマーサポートケースの閲覧と更新の権限を持っていた。調査中、Okta は従業員が Okta 管理のラップトップで Chrome の個人用 Google プロファイルにサインインし、サービスアカウントのユーザー名とパスワードが従業員の個人用 Google アカウントに保存されていたことを発見した。

Okta は、従業員の個人用 Google アカウントまたは個人用デバイスの侵害が、認証情報が露出した最も可能性の高い経路であると説明した。「最も可能性が高い」は、フォレンジック的に証明されたことと同じではない。公の記録は、どの個人アカウントまたはデバイスが侵害されたか、どのように侵害されたか、誰が認証情報を入手したか、あるいはサポートシステム侵入の原因となった攻撃者が、露出した顧客認証情報のその後の使用すべての背後にいる同じ攻撃者であるかどうかを立証していない。権威ある公的な帰属表示は、サポートシステムの攻撃者を名指ししていない。

認証情報の露出は、アクセスがどのように始まったかを説明するが、インシデントの期間や影響を完全に説明するものではない。いくつかの促進条件が、1 つの認証情報を複数顧客の ID イベントに変えた。

再利用可能な非人間の認証情報が広範なケースアクセスを持っていた。サービスアカウントはサポートケースの閲覧と更新が可能だった。公の説明では、各アクセスにフィッシング耐性のある認証、ジャストインタイムの承認、またはデバイスにバインドされたシークレットが必要だったとは述べていない。盗まれたユーザー名とパスワードだけで、動作するサポートシステムセッションを作成するのに十分だった。

個人のブラウザプロファイルが仕事用のサービス認証情報を保持できた。Okta のその後のポリシーでは、管理対象ラップトップ上の Chrome で個人の Google プロファイルをブロックした。これが修正措置だったという事実は、以前の設定では個人の同期境界が管理対象の仕事用デバイスと交差することを許可していたことを示している。

機密性の高い顧客のアーティファクトがサポートリポジトリに入った。Okta は顧客に HAR ファイルをサニタイズするよう警告したが、有効なセッション素材を含むファイルが存在した。警告は、問題を解決するというプレッシャーの下にある管理者に実行を委ねる。サポートフローは、危険なフィールドがアップロード前に確実に削除されることを保証していなかった。

攻撃者は別のネットワークから管理者権限を再生できた。セッションアーティファクトは、使用されるのに十分な時間、有効でポータブルなままだった。一部の顧客の管理策は地理的、デバイス、または行動の不連続性を検出したが、基本セッションは依然として API アクティビティを認証できた。

サポートシステムは意味的に一貫性のない監査経路を露出した。サポートケースを通じてファイルを開く場合と、ファイルタブを通じて開く場合で、異なるイベントと識別子が生成された。調査員は予想される経路をたどったが、攻撃者は別の経路を使用した。セキュリティログは、同じ保護対象オブジェクトへのすべての経路が関連付けられて初めて有用になる。

顧客横断的なエスカレーションが遅かった。顧客の証拠は当初、別々のケース内で評価された。Okta は、一見無関係に見えるテナントイベントが、同じサポートプラットフォームへの最近の HAR アップロードに続いているかどうかを尋ねるために必要な共有ビューを持っていた。

範囲特定ツールが攻撃者のアクションを直ちに表現しなかった。最後の数時間のログの欠落と、フィルターなしのサイズが当初再構成されなかったレポートが、完全な説明を遅らせた。

したがって、根本原因は従業員の過失というより、管理の連鎖として述べる方が適切である。すなわち、仕事用の認証情報が個人の同期ドメインに流出し、その認証情報が機密性の高いサポートリポジトリへの耐久性のある有用なアクセスを提供し、顧客提供のアーティファクトが再利用可能な権限を保持し、監視と調査がすべてのアクセス経路を迅速に関連付けず、セッション管理により認証後の秘密がそれを作成した管理者よりも遠くまで移動することを許した。これらの条件のいずれか 1 つを取り除けば、結果を縮小できた可能性がある。いくつかを取り除けば、最初の窃取の価値ははるかに低くなっていただろう。

誰が被害を防止、検出、制限、または短縮する能力を持っていたか

説明責任は、管理能力に紐付けるとより明確になる。

Okta は、サービスアカウント、従業員のブラウザポリシー、サポートシステムの設定、サポートベンダーに付与されたアクセス、顧客のアップロードの保持と取り扱い、プロバイダー側の監視、インシデントの相関、テナント間のトークン無効化、顧客通知を管理していた。そのため、最初のサポートシステムアクセスを防止し、サービスアカウントの異常な使用を検出し、すべてのファイル経路を特定し、影響を受けたセッションを無効にし、顧客ベース全体に警告するのに最も適した立場にあった。ケースプラットフォームがサードパーティによってホストされていたという事実は、Okta の役割を排除するものではない。Okta はサービス関係を選択して設定し、顧客がアップロードワークフローで信頼していた当事者だった。同社の2024 会計年度の Form 10-Kでは、カスタマーサポートシステムがサードパーティのサービスプロバイダーによってホストされていると説明し、このインシデントが評判と顧客関係に損害を与え、財務結果に悪影響を及ぼし、追加の負債を生じさせる可能性があることを認めた。これらは企業のリスク開示であり、顧客の損失を定量化した調査結果ではない。

未特定のサポートシステムベンダーは、基盤となる製品、オブジェクトモデル、ログ配信の一部を管理していた。公の証拠は、異なるファイルアクセス経路が異なるイベントを生成し、ログが当初不完全だったことを示しているが、ベンダーの契約、どの当事者がそれらの機能を設定したか、どのような警告が存在したか、またはベンダーが特定の義務に違反したかどうかは立証していない。ベンダーに過失の割合を割り当てることは、公の記録を超えるだろう。

顧客は、診断情報を取得するために使用されるアカウントの権限レベル、ファイルをサニタイズするかどうか、自社の Okta テナントポリシー、独立したログと検出、セッションの有効期間、管理者の行動監視、下流のセグメンテーション、通知後の認証情報ローテーションを管理していた。BeyondTrust は、デフォルト以外のデバイスポリシーと行動分析が再生セッションを制限できることを示した。Cloudflare は、ネットワークセグメンテーションが本番環境を保護できることを示し、次に不完全なシークレットインベントリが遅延経路を開く可能性があることを示した。1Password は、予期せぬ管理レポートに対するアラートと迅速な設定レビューの価値を示した。

ブラウザと診断ツールの設計者はデフォルトを管理する。Cookie と認証ヘッダーを省略するサニタイズされたエクスポートは、ユーザーが手動で JSON を編集することを覚えている必要性を減らす。サポートポータルは、既知の認証情報パターンを拒否したり、フィールドレベルのプレビューを表示したり、サニタイズされていないアップロードを隔離したり、意図的に部分的なトレースを受け入れたりすることができる。これらの管理は、トークンが異常なヘッダー、URL、ボディに現れる可能性があり、サニタイズによってデバッグに必要な事実が削除される可能性があるため、不完全である。しかし、デフォルトで安全なツールは経済性を変える。例外的な選択は、権限を削除することではなく、保持することでなければならない。

インシデント外の顧客も、リスク情報の受信者として限定的な役割を担った。11 月のレポートは、Okta を管理する可能性が高い人々のディレクトリを作成した。Okta は、当時コンタクトデータが積極的に悪用されているという直接的な証拠はないと述べたが、フィッシングやソーシャルエンジニアリングのリスク増大を警告した。後に FINRA はサイバーセキュリティアラートを発行し、会員企業にエクスポージャーの評価、プロバイダー利用の見直し、管理者およびサポート担当者への標的化を警戒するよう伝えた。このアラートは、リストに掲載されたすべてのユーザーが攻撃された証拠ではなく、潜在的な下流の悪用に関するガイダンスだった。

ID プロバイダー依存にはリカバリとサポートが含まれる

組織は、認証ポリシー、ライフサイクル管理、多数のアプリケーションへのアクセスを一元化するためにクラウド ID プロバイダーを採用する。一元化はセキュリティを向上させることができる。強力な認証手段を一貫して強制でき、アカウントの停止が迅速に伝播し、ID イベントを 1 か所でログに記録できる。同じ集中は、障害モードも変える。ID レイヤーでの管理者セッションは多くの下流アプリケーションに影響を与える可能性があり、サプライヤーの運用システムは顧客の信頼チェーンの一部となる。

2023 年の侵害は、3 つの依存形態を露呈した。

第一に、顧客はアクティブセッションの有効性を Okta に依存していた。Okta が盗まれたアーティファクトを受け入れた時点で、顧客側のハードウェアキーは、Cookie を提示した人物が依然としてキーに触れた人物であることを遡及的に証明することはできなかった。顧客はデバイスとネットワークポリシーを通じてコンテキストを追加できたが、Okta はセッションバインディングやグローバルな無効化などの製品機能を管理していた。

第二に、顧客はサポートリポジトリに関する証拠を Okta に依存していた。顧客は不可能な管理者アクションを見ることができたが、誰がプロバイダーのケースシステムからその添付ファイルをダウンロードしたかは分からなかった。1Password と BeyondTrust は、テナントイベントをサポートファイルに結び付けるために Okta からのログを必要とした。プロバイダーは、どのサポートイベントが悪意のあるものであるかを発見するために、顧客のテレメトリに依存していた。証拠は組織の境界を越えて分断されていた。

第三に、顧客は Okta の通知と修復のシーケンスに依存していた。Okta だけが、ファイルにアクセスされた 134 社の顧客を特定し、関連する埋め込まれた Okta セッショントークンを大規模に無効にし、広範なサポートユーザーレポートを再構成し、影響を受けていない顧客に何がチェックされたかを伝えることができた。この集中は、顧客全体にとってスピードを貴重なものにする。各レポートを孤立したエンドポイント問題として扱うことに費やされた 1 日は、プロバイダーのコストであるだけでなく、サポートファイルが露出した可能性のあるすべてのテナントにとって不確実性のウィンドウを拡大する。

インシデント発生時に単純な代替策はない。ID プロバイダーの交換は、アプリケーション統合、グループマッピング、ライフサイクルルール、認証手段、ヘルプデスクプロセス、ユーザー行動を含む大規模なプロジェクトである。マルチプロバイダーフェイルオーバーは、それ自身のセキュリティと一貫性の問題を生み出す可能性がある。現実的な対抗策は、即時のベンダー交代ではなく、依存の制限である。すなわち、独立したテレメトリ、高リスクアプリケーションアクセスに対するローカル権限、短くコンテキストに応じた管理者セッション、同じコントロールプレーンに依存しないブレークグラスアカウント、テストされた認証情報ローテーション、ID プロバイダーやそのサポートチャネルが調査中の間も重要なサービスを運用する能力だ。

エスカレーションチャネルの経済学

セキュリティ報告は、インセンティブの乏しい情報市場である。1 つの異常な管理イベントを見た顧客は、当初それがエンドポイントマルウェアなのか、内部関係者なのか、盗まれたブラウザセッションなのか、プロバイダーの侵害なのか、誤検知なのかを知ることができない。調査は希少な対応者の時間を消費する。サプライヤーへのエスカレーションは、繰り返しの会議やログの要求を意味する場合がある。その粘り強さの利益は、報告が共通の原因を明らかにした場合、主に他の顧客に帰属するかもしれない。

BeyondTrust の報告は具体的な例である。同社は自社のシステムを除外し、サポート環境が侵害された可能性が高いと主張し、エスカレーションとより詳細なログを要求し、IP 指標を提供した。Okta の説明は、その指標が侵害されたサービスアカウントに関連するこれまでに見られなかったイベントを特定した功績を認めている。1 社の顧客の私的コストが、プロバイダー全体の検出利益を生み出した。

プロバイダーのインセンティブも難しい。顧客横断的なインシデントをあまりに早く宣言すると、不必要なローテーション、サポート負荷、風評被害を生む可能性がある。確実性を待つことは、攻撃者をアクティブなままにし、検出コストを顧客に転嫁する可能性がある。答えは、異常なログイン後の自動的な公表ではない。それは、非公開の予防的通知を発行し、文言に不確実性を残し、帰属が確定する前に顧客が取るべき行動を明示できる段階的エスカレーションシステムである。

11 月の連絡先レポートの露出は、もう 1 つの層を追加する。サポートディレクトリ自体が、特権的な ID 責任を持つ可能性が高い人々の氏名、メールアドレス、会社、一部のレコードでは役割関連のメタデータを特定していた。パスワードがなくても、攻撃者の検索コストを下げる。説得力のある発信者は、誰が ID プラットフォームを管理しているかを推測する必要がなくなる。Okta は、多くのサポートユーザーが管理者であり、同じアカウントがサポートシステムと顧客の Okta 組織へのサインインに使用されていると明確に警告した。

ここで、不正利用の連絡に関する経済学と ID セキュリティが交差する。連絡可能性は必要である。プロバイダーは通知する信頼できる人物を必要とし、顧客は不正利用を報告する信頼できる場所を必要とする。しかし、集中された連絡先ディレクトリは偵察データでもある。それは、特定する人々の権限に応じて最小化され、セグメント化され、監視され、保護されるべきである。通知は、同じインシデントで露出した単一のアドレスに依存すべきではない。組織は、登録されたセキュリティ連絡先、個別に認証されたポータルメッセージ、帯域外の緊急チャネルを維持し、メッセージが実際にプロバイダーからのものであることを検証する明確なルールを持つかもしれない。

効果的なプロバイダーのエスカレーション設計は、5 つの能力を観察可能にするだろう。

通常のケース処理から独立し、顧客全体のレポートを集約する権限を持つセキュリティ経路。
懸念がインシデント対応者に届いたかどうかを報告者に伝える受領および重大度の確認。
通常のケースビューだけでなく、オブジェクト識別子、タイムスタンプ、完全なアクセス経路を保存する証拠要求。
何が疑われ、何が確認され、顧客が何を保存またはローテーションすべきかを伝えることができる予防的通知段階。
各カウントの背後にある母集団、データオブジェクト、信頼性を定義する最終的な影響声明。

これらの能力は、報告の私的コストを削減し、3 社目の顧客が決定的なシグナルとなる前にプロバイダーが共有パターンを発見する可能性を高める。

修復：何が変わり、何が検証困難なままか

Okta の 11 月 3 日の説明では、4 つの完了したステップが挙げられた。侵害されたサービスアカウントを無効化した。Chrome Enterprise 設定を使用して、従業員が Okta 管理のラップトップで個人の Google プロファイルにサインインすることをブロックした。サポートシステムの監視と検出ルールを追加した。管理者セッショントークンをネットワークロケーションにバインドし、検出されたネットワーク変更後に再認証を要求する早期アクセス機能をリリースした。

11 月 29 日の更新では、顧客向けの管理策が追加された。Okta は、管理者向けのフィッシング耐性のある認証手段、自律システムの変更に基づく管理者セッションバインディング、より厳格な管理コンソールのタイムアウトを推奨した。デフォルトの最大 12 時間のセッションと 15 分のアイドルタイムアウトを発表し、2024 年 1 月にロールアウトした。また、パスワードや認証要素のリセット前にヘルプデスクの確認を見直すよう顧客に要請した。これらの対策は、再生の持続時間とソーシャルエンジニアリングリスクに対処するものだが、ASN 変更は暗号化されたデバイスバインディングではなく、リスクシグナルである。正規のモバイルまたはリモートユーザーはネットワークを変更できるが、攻撃者は同じネットワークコンテキストでインフラを見つける可能性がある。

2024 年 2 月 8 日、Okta は調査終了通知を公開した。Stroz Friedberg が独立した調査を完了し、Okta の以前の結論を超える悪意のあるアクティビティの証拠は見つからなかったと述べた。Okta は、規制当局と法執行機関に通知し、影響を受けた顧客にカスタマイズされた影響レポートを提供し、ヘルプセンターのセキュリティを見直し、管理者のプロビジョニングとデータ保持を変更したと述べた。また、管理者に対するゼロスタンディング特権、保護された管理コンソールアクションに対するステップアップ MFA、動的ゾーンによる匿名化ツールのブロック、より広範な IP バインディング、API アクセスに対するネットワークゾーン制限を指摘した。

これらの修復策は、複数のレイヤーをカバーしている。

トリガー管理：アカウントの無効化と個人プロファイルのサインインのブロック。
検出管理：新しいサポートシステムの監視と独立したフォレンジックレビュー。
セッション管理：ネットワークバインディング、より短いライフタイム、保護されたアクションの再認証。
権限管理：期間限定の管理者ロール割り当て。
露出管理：ヘルプセンターのプロビジョニングと保持の変更。
顧客管理：影響レポート、指標、設定ガイダンス。

最も強力な変更は、秘密が盗まれた後の攻撃者の利用可能な権限を減らす。より短いセッション、危険なアクションに対する再認証、一時的な管理者ロール、API ネットワーク制限はすべて、ウィンドウを狭める。HAR サニタイザーモデルは、アップロード前にキャプチャされたファイルを不活性化することで、さらに早い段階で対処する。予防と封じ込めが組み合わさることで、サポートストレージが安全であるという単一の約束よりも信頼性が高くなる。

公開検証は依然として限定的である。Okta は独立したフォレンジックレポートを公開せず、顧客とパートナーに利用可能にした。終了通知は、サポートシステムの改訂された保持期間、正確なサービスアカウント認証の設計、監視のしきい値、機密性の高いアップロードが自動的にスキャンまたはサニタイズされるかどうか、すべてのファイルオブジェクト識別子がどのように関連付けられるか、高信頼度の顧客報告が顧客横断的なインシデントチームにどれだけ早く到達しなければならないかを開示していない。また、利用可能なすべてのインターフェースを通じてアクセスされたファイルが、完全でタイムリーな監査証跡を生成することを示すテスト結果も提供していない。

それは、管理策が存在しなかったか、効果がなかったことを意味するわけではない。外部の読者は、Okta が対策を実施したと述べたことを確認できるが、各対策の設定や耐久性を独立して評価することはできない。成熟した説明責任の記録は、これらの主張の多くをテスト可能な証拠に変えるだろう。すなわち、監査カバレッジ指標、サービスアカウントインベントリと認証ポリシー、サポートファイルの保持基準、エスカレーションまでの時間の演習、トークン無効化の訓練、代替ファイルアクセス経路のレッドチームテストだ。

ID サポートケースの管理標準

このインシデントは、ID プロバイダーとその顧客が共有できる実践的な標準を示唆している。

より少ない権限を収集する。問題を再現できる最小権限のアカウントからトレースを生成する。テストテナントや短期間のサポートセッションを優先する。失敗したリクエストウィンドウのみを記録する。Cookie、認証ヘッダー、ボディが必要ない場合は、ファイルの作成またはエクスポート前に削除する。

サニタイズをローカルかつデフォルトにする。顧客は、何が削除され、どのような診断価値が残るかを検査できるべきである。機密性の高いエクスポートには、明示的な例外、説明、失効計画が必要であるべきだ。サポートポータルは、一般的な警告を表示するだけでなく、一般的な認証情報形式をスキャンし、危険なアップロードを拒否または隔離すべきである。

受け入れた機密ファイルをアクティブなシークレットとして扱う。サポートが本当にライブセッションアーティファクトを必要とする場合、ワークフローは短い処理ウィンドウを設定し、指名された担当者に制限し、一括閲覧を防ぎ、すべてのアクセス経路をログに記録し、ケースステップが完了したら無効化をトリガーすべきである。顧客は、ファイル、機密クラス、予想消去時間、アップロード後に必要なアクションを特定する受領書を受け取るべきである。

インターフェースイベントではなく、オブジェクトを関連付ける。ファイルがケース、ファイルタブ、レポート、API、管理者ツールから開かれた場合でも、テレメトリは同じ基礎オブジェクトと顧客に解決されるべきである。セキュリティ検索は、読み取り、プレビュー、エクスポート、コピー、レポート生成、メタデータアクセスをカバーすべきである。ファイルサイズとレポートパラメータは、調査者が出力を再構成できるように保持されるべきである。

認証なしの権限を検出する。Okta のシステムログガイダンスは、顧客がユーザー、IP、外部セッション識別子で検索し、セッション、認証、MFA、リカバリイベントを確認する方法を説明している。顧客の教訓は、特権アクションが予想される認証シーケンスなしに、新しいネットワークから、通常とは異なるクライアントを介して、またはめったに使用されない管理機能に対して現れた場合にアラートを出すことである。成功したセッションは、そのセッションが何をするかの精査を抑制すべきではない。

高リスクセッションをバインドし再チェックする。ネットワーク、デバイス、行動コンテキストは再生を識別できる。保護されたアクションには新たな証明が要求されるべきである。管理者ロールは可能な限り一時的にすべきである。API 経路は、デバイスポリシーによってブロックされたコンソール経路の、より制約の少ない代替手段を黙って提供すべきではない。

診断エビデンス内のすべての秘密をインベントリする。ファイルが露出した後は、明らかな Okta Cookie だけでなく、API トークン、サービスアカウント認証情報、下流アプリケーションの秘密、認証情報を含む URL もローテーションする。Cloudflare の後のインシデントは、見逃した認証情報が機密性の高いコラボレーションシステムに到達した場合、ほぼ完全なローテーションでも不十分であることを示している。

独立したリカバリパスを保持する。プライマリ ID パスの外に、ブレークグラスアクセス、プロバイダーのセキュリティ連絡先、ログを維持する。中央の ID セッションを広範囲に無効化しなければならない場合に、重要なアプリケーションがどのように動作するかをテストする。目標は ID プラットフォーム全体を複製することではなく、侵害されたプロバイダーを証拠とリカバリの唯一の情報源にしないことだ。

報告経路を訓練する。顧客は、疑わしいサプライヤー侵害にラベルを付ける方法を知っておくべきであり、プロバイダーは異なるケース番号で到着するレポートを統合する練習をすべきである。セキュリティ連絡先は、監視され、認証され、エスカレーションする権限が与えられて初めて管理手段となる。

セッション終了後の説明責任

Okta の本番サービスは侵害されておらず、すべての顧客テナントがアクセスされたという主張を裏付ける公的記録はない。これらの限界は引き続き強調されるべきである。確認された被害も同様に強調されるべきだ。134 社の顧客にわたる不正なサポートファイルアクセス、5 件の乗っ取られた顧客セッション、広範なサポートユーザー連絡先レポート、下流の顧客の調査およびローテーションコスト、そして元の露出後に顧客がローテーションしなかった認証情報を使用した少なくとも 1 回のその後の侵入である。

インシデントのトリガーは、それが到達したシステムと比較するとありふれたものだった。個人のブラウザプロファイルを通じて保存されたサービス認証情報である。その結果はアーキテクチャによって形作られた。その認証情報は、認証されたアクティビティの顧客生成コピーを含むリポジトリを開いた。リポジトリのログは、ナビゲーション経路に応じてファイルアクセスを異なる形で表現した。アクティブセッションは、それを確立した管理者から離れて再生される可能性があった。顧客が最初に異常な影響を確認し、プロバイダーは共有の原因を証明できる唯一のビューを保持していた。

これが中心的な説明責任の結論である。ID 保証は、本番認証サービスで止めることはできない。それは、管理者権限を収集、保存、再生、無効化、または説明できるすべての運用プロセスに拡張されなければならない。サポートは、その通常の成果物に ID 秘密が含まれている場合、ID 境界の外側ではない。

Okta のその後の管理策は連鎖の重要な部分に対処し、同社の開示は最終的に調査の誤りについて異常なほど詳細になった。顧客の報告も、階層化されたポリシー、独立したテレメトリ、迅速な対応が影響を大幅に軽減したことを示した。したがって、教訓はクラウド ID が本質的に信頼できないということではない。集中された信頼は、集中された証拠、迅速なエスカレーション、ログインセレモニーが終わった後も強力であり続けるセッション管理と釣り合わなければならないということだ。