Okta のサポートシステム侵害が露呈したクラウド ID 基盤の隠れた依存関係

概要

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

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

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

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

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

2つの露出 ― 拡大する数字ではない

公の説明ではしばしば、Okta が当初1％の顧客が影響を受けたと述べ、後に全顧客が影響を受けたと認めたという主張に単純化されます。その省略形は、2つの異なるデータセットと2種類のリスクを曖昧にしています。

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

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

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

これらの事実は、4つの正確な記述を裏付けます：

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

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

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

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

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

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

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

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 リクエストとセッションクッキーが含まれていました。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月のインシデント報告では、10月18日に Okta サポートチケットから取得された管理者セッショントークンを含む活動を検知したと述べています。攻撃者は Okta プラットフォーム内の Cloudflare 従業員アカウント2件を侵害しました。Cloudflare は、Okta からの通知より24時間以上前に活動を検知し、攻撃者が永続化を確立するか顧客データ、顧客システム、本番ネットワークに到達する前に封じ込めたと述べました。

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

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

Cloudflare のケースはまた、迅速な初期封じ込めが完全な根絶と同じではないことも示しています。2024年2月、Cloudflare は別のThanksgiving インシデントを開示し、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日には、追加のダウンロードファイルを発見し、新たに特定された埋め込みトークンを無効化し、Cloudflare を5社目の標的顧客として特定し、登録済みセキュリティ担当者に、当時判明していたインシデントによって自組織が影響を受けたかどうかを顧客ベース全体に通知しました。公開アドバイザリーは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 活動を認証できました。

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

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

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

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

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

説明責任は、管理能力に結びつけると明確になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロバイダーのインセンティブもまた困難です。顧客横断的なインシデントをあまりに早期に宣言すると、不必要なローテーション、サポート負荷、風評被害を引き起こす可能性があります。確実性を待つことは、攻撃者をアクティブなままにし、検知コストを顧客に転嫁し得ます。答えは、奇妙なログインがあれば自動的に公表することではありません。それは、機密の予防的通知を発行し、文言に不確実性を残し、帰属が最終決定する前に顧客が取るべき行動を述べることができる段階的エスカレーションシステムです。

11月の連絡先レポート露出は、別の層を追加します。サポートディレクトリ自体が、特権的な 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 プロバイダーと顧客が共有できる実用的な基準を示唆しています。

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

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

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

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

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

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

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

独立した復旧パスを保持する。緊急用アクセス、プロバイダーのセキュリティ担当者、主要な ID パス外のログを維持します。中央の ID セッションが広範に無効化されなければならない場合に、重要なアプリケーションがどのように動作するかをテストします。目標は ID プラットフォーム全体を複製することではなく、侵害されたプロバイダーを証拠と復旧の唯一のソースにしないことです。

報告ルートを訓練する。顧客はサプライヤー侵害の疑いをどのようにラベル付けするかを知っておくべきであり、プロバイダーは異なるケース番号で到着する報告を結合する練習をすべきです。セキュリティ担当者は、監視され、認証され、エスカレーションする権限を与えられている場合にのみ管理策となります。

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

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

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

これが中心的な説明責任の所見です。ID 保証は本番認証サービスで止まることはできません。管理者権限を収集、保持、再生、無効化、または説明できるすべての運用プロセスに拡張されなければなりません。サポートは、その通常の作業成果物に ID シークレットが含まれる場合、ID 境界の外側ではありません。

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