OKTA、サポートアーティファクトをアイデンティティ顧客向けのサードパーティ信頼境界に

概要

• OKTA は、攻撃者が同社のサポートケース管理システムへの不正アクセスを使用して134の顧客に関連するファイルを閲覧し、一部のファイルのセッションアーティファクトが5件の顧客セッションを乗っ取るために使用されたことを確認しました。
• 重要な説明責任の問題は、サポートアーティファクトをめぐる信頼境界です。ヘルプのためにアップロードされた診断ファイルには、機能的に特権的な ID 管理に属する Cookie、トークン、リクエストヘッダー、URL、その他の素材が含まれている可能性があります。たとえファイルが本番 ID サービスの外部に保存されていたとしてもです。
• サードパーティのサポートツールはコントロールマップを変えました。OKTA はサポートアクセス、ファイル保持、サービスアカウント、ログ、通知の仕組みについて説明責任を負い続ける一方、顧客は何をアップロードするか、アーティファクトをどのようにサニタイズするか、ありえない管理者アクティビティをどのように検出するかを管理しました。
• 永続的な教訓は、ID プロバイダーは管理者の診断アーティファクトを作成から削除まで資格情報素材として扱い、それに応じてサポートシステム、セッションコントロール、顧客ログを設計すべきであるということです。

証拠マップ

サポートはアイデンティティ境界の一部となった

OKTA のサポートシステム侵害から得られる最も強い教訓は、アイデンティティ境界がログインサービス、トークン発行元、ポリシーエンジン、管理コンソールの周囲にのみ引かれるわけではないということです。境界には、顧客がこれらのサービスを運用するのを支援するサポート経路も含まれます。管理者がブラウザ診断を収集し、ファイルをアップロードし、ケースを開き、サポートに行動の調査を依頼するとき、彼らはアイデンティティセッションの断片を別の運用環境に移しています。その環境は、サードパーティのケースシステム、サポートサービスアカウント、ファイルストア、検索インターフェース、レポートエクスポート、一連の人間のワークフローである可能性があります。

OKTA は、本番サービスは侵害されておらず、その区別は維持されるべきであると述べました。このインシデントは、攻撃者がコア認証プラットフォームを破ったり、任意の OKTA 資格情報を生成したりできることを示したわけではありません。しかし、サポート境界は依然として顧客のアイデンティティ管理に機能的に接続されていました。アップロードされたファイルの中にはセッションアーティファクトを含むものがありました。OKTA は、攻撃者がアクセスしたファイルのセッションアーティファクトを使用して5件の顧客セッションを乗っ取ったと述べています。これにより、サポートリポジトリは管理者権限の信頼境界の一部となるのに十分です。

これは、サポートがしばしば周辺的ではなく中心的に扱われるため重要です。本番アイデンティティシステムは、アーキテクチャの精査、侵入テスト、特権アクセス制御、顧客監査の質問を受ける可能性があります。ケース管理システムはエンタープライズワークフローツールとして扱われるかもしれません。しかし、そのワークフローツールが管理者セッションからの診断キャプチャを保存する場合、そのアクセス制御、保持ポリシー、ログ、サービスアカウント、サードパーティホスティングの取り決めは、アイデンティティ制御になります。システムのラベルがリスクを決定するのではありません。アーティファクトに埋め込まれた権限がリスクを決定します。

このインシデントはまた、信頼境界が組織図ではなく悪用可能性によって描かれるべき理由を示しています。サポートエンジニアは顧客の問題を解決するために証拠を必要とするかもしれません。顧客は正確なブラウザトラフィックをアップロードして障害を実証する必要があるかもしれません。サードパーティのプラットフォームがケースファイルを保存するかもしれません。サービスアカウントがそれらをインデックス化または取得するかもしれません。これらのステップのいずれかがライブの管理者セッションを露出させる可能性がある場合、境界は資格情報がその中を移動しているかのように管理されなければなりません。

それはサポートが診断の使用をやめるべきという意味ではありません。それは、特権セッションからの診断アーティファクトが管理されたライフサイクルを必要とすることを意味します。それらは可能な限り最小限の機密データで作成され、可能な場合はアップロード前にサニタイズされ、厳格に制限されたリポジトリに保存され、すべてのアクセス経路でログ記録され、簡潔に保持され、ケースに明確にリンクされ、資格情報リスクを反映したスケジュールで破棄されるべきです。アーティファクトがライブセッション素材を含む場合、サービスはその素材を無効化するか、再認証を強制できるべきです。

HAR ファイルは、より詳細なスクリーンショットではなかった

HTTP Archive ファイルは、コンテキストを保持するためサポートチームにとって魅力的です。スクリーンショットでは捉えられないリクエスト、レスポンス、ヘッダー、タイミング、ペイロード、リダイレクト、エラーを表示できます。その豊富さが有用である理由です。それが危険である理由でもあります。認証された管理者セッション中に生成された HAR ファイルは、サービスが後で既存のセッションの証拠として受け入れる可能性のある Cookie、認証ヘッダー、URL、リクエストボディ、またはその他の状態をキャプチャする可能性があります。

OKTA の初期勧告は、HAR ファイルに Cookie やセッショントークンを含む機密データが含まれる可能性があることを明示的に警告しました。同社のドキュメントは、ファイルを送信する前に機密情報や個人を特定する情報を削除するようユーザーに指示しています。Chrome の現在のドキュメントは、サニタイズされた HAR エクスポートと機密データを含むエクスポートを区別することで、制御設計を可視化しています。これは業界にとって有意義な方向性です。ファイルがユーザーのブラウザを離れる前に資格情報の価値を減らすことです。

このインシデントは、HAR 収集を低リスクのサポート儀式として扱う習慣を終わらせるべきです。ユーザーはどのフィールドが機密かを理解していないかもしれません。プレッシャー下の管理者はサポートの指示に迅速に従うかもしれません。ブラウザのエクスポートオプションは顧客が期待する以上に保持するかもしれません。サポートワークフローは、資格情報を含む素材を自動的に検出せずにファイルを受け入れるかもしれません。保存されると、ファイルは検索、ダウンロード、複製、バックアップ、または複数のオブジェクト識別子を通じて表現される可能性があります。

BeyondTrust の公開説明は、リスクを具体的に示しています。管理者がサポート問題のために HAR ファイルを生成してアップロードし、ファイルに API リクエストとセッション Cookie が含まれており、攻撃者がその後すぐにセッションをリプレイしようとしたと述べています。BeyondTrust のアクセスポリシーは一つの経路をブロックし、検出機能が試行を捉えましたが、アップロードされたアーティファクトはすでに境界を越えていました。この一連の流れは、サポートアーティファクトが証明されるまではベアラーシークレットとして扱われるべき理由を示しています。

より安全なサポートパターンは、生の機密キャプチャの必要性を減らすでしょう。製品には、デフォルトで Cookie やトークンを編集する組み込みの診断バンドルを含めることができます。ブラウザツールは、機密エクスポートを明示的な警告の背後に保つことができます。サポートポータルは、認識可能なセッションフィールドのアップロードをスキャンし、トークンの取り消しや顧客確認を強制できます。アイデンティティプロバイダーは、制限された権限を持つ一時的な診断セッションを提供できます。顧客は、可能な場合、専用の低特権サポートアカウントを使用できます。これらの制御のどれも完璧ではありません。それらは一緒になって、本番管理者のライブ権限がポータブルなサポート証拠になる可能性を減らします。

サードパーティツールは OKTA から説明責任を移さなかった

OKTA のその後の提出書類は、サポートケース管理システムがサードパーティのサービスプロバイダーによってホストされていると説明しました。その事実はコントロールマップを変えますが、インシデントを他人の問題にはしません。顧客はアイデンティティプロバイダーとして OKTA と関係がありました。OKTA はサポートシステムを選択、統合、管理、依存していました。サポート環境が顧客セッションに影響を与える可能性のあるアーティファクトを保存していた場合、OKTA はその環境がどのように管理されるかについて説明責任を保持しました。

サードパーティのサポートシステムは一般的です。それらはスケール、ワークフロー、レポーティング、顧客コミュニケーションを向上させることができます。また、追加の信頼の問題を導入します：誰が顧客ファイルにアクセスできるか、どのサービスアカウントが存在するか、どのログがファイルアクセスをキャプチャするか、オブジェクト識別子が可視のケースファイルにどのようにマッピングされるか、レポートがどのように生成されるか、ファイルがどの程度保持されるか、サードパーティスタッフや OKTA スタッフがどのようにプロビジョニングされるか、疑わしいアクティビティがすべてのケースにわたってどの程度迅速にスコープ化されるか。これらの質問はベンダー管理の書類手続きではありません。サポートアーティファクトがセッション権限を運ぶ場合、それらはアイデンティティリスクの制御です。

1Password によるインシデントの説明は、サードパーティシステムのデータモデルが調査を複雑にする方法を示しています。1Password は、OKTA の最初のログ分析では関連する HAR ファイルへの不正アクセスが示されなかったが、後の分析で2番目のオブジェクト識別子を通じたアクセスが見つかったと報告しました。重要な点は、オブジェクト識別子を技術的な好奇心として捉えることではありません。セキュリティの質問が単一のデータベースオブジェクトよりも広くなる可能性があることです。「このケースに添付されたファイルに誰がアクセスしたか？」という質問は、サポートプラットフォーム内のすべての経路、重複表現、添付ファイルオブジェクト、プレビュー経路、エクスポート経路、レポート経路を理解する必要があるかもしれません。

OKTA 自身のタイムラインは関連する教訓を説明しています。脅威アクターが最初のクエリに含まれていなかったナビゲーション経路を通じてファイルにアクセスしたため、最初は一部のログイベントを見逃しました。後に、より広範なサポートユーザーレポートについて、OKTA は手動でレポートを再作成し、出力サイズをダウンロードテレメトリと比較しました。その手法は最終的に広範な露出を明らかにしました。また、サードパーティのサポート侵害のスコープ化には、単純なログ検索だけでなく再構築が必要になる可能性があることも示しています。

したがって、アイデンティティプロバイダーのサポートシステムに対する説明責任の基準には、経路完全なログ記録が含まれるべきです。ファイルがダウンロード、プレビュー、エクスポート、別のオブジェクトを通じて参照、レポートに含まれる、または API を通じてアクセスされる可能性がある場合、すべての経路がセキュリティ利用可能なテレメトリを生成するべきです。調査員は顧客中心の質問をして完全な回答を得られるべきです。内部オブジェクト構造を反映するが顧客リスク構造を反映しないログシステムは、このクラスのインシデントには不十分です。

顧客は分散型センサーとなった

OKTA の顧客は中心的な検出役割を果たしました。1Password、BeyondTrust、Cloudflare はそれぞれ、OKTA の公開開示の前後またはその頃に、自社環境での疑わしいアクティビティを公開しました。これは単に注意深い顧客の話ではありません。これはクラウドアイデンティティインシデントの構造的特徴です。プロバイダーは共有インフラとサポートシステムアクセスを見ます。各顧客はテナントアクティビティ、管理者行動、デバイス体制、ローカルポリシー違反を見ます。どちらの視点だけでは完全ではありません。

BeyondTrust は、予期しないコンテキストからのセッションリプレイ試行を検出し、管理デバイスポリシーを通じてインタラクティブアクセスをブロックし、API 経路を観察し、バックドアアカウント作成の試みを見て、OKTA にエスカレーションしました。Cloudflare は、OKTA サポートチケットに関連する管理セッショントークンを含むアクティビティを検出し、顧客システムが影響を受ける前にイベントを封じ込めました。1Password は予期しない管理アクティビティを報告し、後に調査経路の詳細を提供しました。これらの顧客は受動的な被害者ではありませんでした。彼らはサプライヤー側の問題を明らかにするのに役立った外部センサーでした。

そのセンサーの役割は、不正利用連絡先の経済問題を生み出します。顧客はイベントの調査、証拠の保存、サポートを通じたエスカレーション、プロバイダーに共通原因がプロバイダーの環境内にある可能性があると説得するために時間と専門家の労力を費やしました。その作業の価値は他の顧客にも及びました。なぜなら、サポートシステム全体を相関させることができたのは OKTA だけだからです。検出のコストは分散され、共通原因を確認する力は集中されていました。

このダイナミクスは、サポートエスカレーションの設計を変えるべきです。セッションリプレイ、ありえない管理アクティビティ、またはサポートアーティファクトの相関の信頼できる証拠を提供する場合、疑わしいアイデンティティプロバイダーアクティビティを報告する顧客は、通常のサポート前提と戦う必要があるべきではありません。アイデンティティプロバイダーは、顧客テナントの証拠をプロバイダー側のサポートシステムログと迅速に結合できる高信頼のセキュリティエスカレーション経路を維持すべきです。最初の仮説は、特に複数の顧客が同様のパターンを報告する場合、常に顧客のマルウェアやフィッシングであるべきではありません。

顧客はまた、サプライヤー起因のリスクを可視化するログを必要としています。OKTA のシステムログガイダンスは、サインイン、リカバリ、セッション、IP アクティビティを相関させる方法を説明しています。Cloudflare は、対応する認証イベントのないセッション、管理変更、ポリシー変更、MFA 変更、サプライチェーンプロバイダーアクセスを探すことを推奨しました。これらは正しいパターンです。なぜなら、セッションリプレイはサービス層では有効に見えても、顧客コンテキストでは不可能である可能性があるからです。Cookie は受け入れられるかもしれませんが、シーケンスは依然として間違っている可能性があります。

連絡先データは攻撃の経済性を変えた

2023年11月の範囲更新は、2番目の露出を追加しました：影響を受けたサポートシステムのユーザーの名前とメールアドレスを含むレポート。OKTA は、そのより広範なサポートユーザーレポートを、より狭い顧客ファイルとセッションハイジャックのセットと区別しました。その区別は重要です。レポート内の名前とメールアドレスは、その人のテナントがアクセスされたり、セッションが乗っ取られたことを意味しませんでした。しかし、サポートシステムユーザーの連絡先データは標的としての価値があります。

サポートユーザーは、多くの場合、管理者、エンジニア、セキュリティスタッフ、またはアイデンティティ運用に近い従業員です。レポートがほとんどのエントリについて名前とメールのみを含んでいたとしても、攻撃者が特権アクセスを持っている可能性が高い人や、アイデンティティプロバイダーのワークフローに影響を与える可能性のある人を特定するのに役立つ可能性があります。FINRA は後に、OKTA のカスタマーサポートシステムに関連する可能性のあるフィッシング攻撃について会員企業に警告しました。その警告は、すべての連絡先記録の活発な悪用を証明したわけではありません。厳選されたサポートユーザーリストの経済的価値を認識したものです。

サポートユーザーレポートはまた、インシデントの範囲が影響の単位を定義しなければならない理由を示しています。OKTA には134件の顧客ファイル露出、5件のハイジャックされたセッション、より広範な連絡先データレポートがありました。それらを1つの数字にまとめると混乱を招きます。顧客は、盗まれたファイル、リプレイされたセッション、ダウンロードされたレポートエントリ、フィッシングリスクのある集団のいずれにさらされているかを知る必要があります。各単位は異なる対応を要求します。セッション露出は取り消しとフォレンジックレビューを必要とします。サポートユーザーの連絡先露出はフィッシング認識とモニタリングを必要とします。ファイル露出はアーティファクト固有の評価を必要とします。

したがって、適切な開示は、顧客組織、サポートユーザー、サポートファイル、セッション素材、テナントアクティビティ、下流の侵害を分離すべきです。OKTA の後のコミュニケーションは、集団を区別することでその方向に進みました。連絡を受けていない顧客は自分たちの環境やサポートチケットに影響がないとする最初の顧客向け声明は、より広範なレポートが再構築された後には読みにくくなりました。問題は、最初の声明が意図的に誤解を招くものだったかどうかではありません。「影響」という言葉は、開示がどの種類かを言わない限り、あまりにも伸縮自在であるということです。

アイデンティティプロバイダーにとって、サポート連絡先リストは通常の企業アドレス帳を超えた保護に値します。それらは高価値の役割と関係経路を特定します。それらへのアクセスは監視され、エクスポートは制限され、レポート生成はログ記録され、異常なレポートダウンロードはレビューをトリガーするべきです。サポートメタデータは、パスワードが含まれていなくても機密性が高くなる可能性があります。

セッション結合とアーティファクトサニタイズは補完的

このインシデント後の魅力的な答えの1つは、すべてのサポートアーティファクトをサニタイズすることです。それは必要ですが十分ではありません。別の魅力的な答えは、すべてのセッションをデバイス体制、ネットワークコンテキスト、または再認証に緊密に結合することです。それも必要ですが十分ではありません。より安全な設計は両方を必要とします。なぜなら、各制御が異なる障害モードを捉えるからです。

サニタイズは、アーティファクトが顧客のデバイスを離れる前にその価値を減らします。Cloudflare の HAR Sanitizer はこのモデルの例です：トラブルシューティングに必要な構造を可能な限り保持しながら、クライアント側でセッション Cookie とトークンを削除します。ブラウザのデフォルトと製品固有の診断ツールは同様の作業を行うことができます。機密素材がサポートシステムに入らなければ、サポートシステムの侵害はそれを漏洩する権限が少なくなります。

セッション結合は、露出後の盗まれたセッションアーティファクトの価値を減らします。BeyondTrust の管理デバイスポリシーは攻撃者のインタラクティブアクセス試行をブロックしましたが、攻撃者はその後 API 経路を試みました。その詳細は、結合がコンソールと API 経路の両方で一貫して適用されなければならないため重要です。ブラウザコンソールがデバイス体制を要求するが、API が同等のチェックなしに同じセッションを受け入れる場合、攻撃者は弱い経路をたどります。

アーティファクトサニタイズとセッション結合は、短いセッションライフタイム、機密アクションに対する管理者再認証、最近の認証のないセッションの異常検出、診断アーティファクトがセッション素材を含むことが知られている場合の迅速な取り消しによって結合されるべきです。OKTA の後の推奨事項には、セッション結合とタイムアウト関連の対策が含まれていました。説明責任のテストは、そのような制御が高特権アイデンティティ管理のデフォルトの期待となり、最も洗練された顧客向けのオプションの強化ではないかどうかです。

顧客にも責任があります。彼らはアップロード前に HAR ファイルをサニタイズし、可能な場合は診断再現に低特権アカウントを使用し、サポートファイル侵害後に露出したシークレットをローテーションし、管理者アクションを監視し、サポートアップロードを機密記録として扱うべきです。Cloudflare の後の感謝祭インシデントは、強力な対応者でも露出後の資格情報ローテーションを逃す可能性があることを示しています。サポートアーティファクトが取得されたことが知られると、それに埋め込まれたすべての資格情報がリカバリ範囲の一部になります。

開示は組織の境界を越えなければならなかった

このインシデントは、OKTA が影響を受けた顧客、登録されたセキュリティ連絡先、より広範なサポートユーザー集団、規制当局、法執行機関、投資家、場合によってはその後自社の従業員に通知しなければならなかった顧客に通知することを要求しました。これは複雑な開示経路です。影響を受けたシステムが本番アイデンティティではなく、サードパーティホスティングと複数の影響単位を持つサポートプラットフォームである場合、より困難になります。

登録されたセキュリティ連絡先は不可欠ですが、サポートインシデントはケース所有者、テナント管理者、法的連絡先、サプライヤーリスクチームも必要とする場合があります。サポートユーザーの名前とメールがレポートに表示された顧客は、HAR ファイルにライブセッショントークンが含まれていた顧客とは異なるメッセージを必要とします。テナントアクティビティが観測された顧客は即時のフォレンジック詳細を必要とします。連絡先データが露出した顧客はフィッシングガイダンスとモニタリングアドバイスを必要とします。1つの通知ですべての集団に等しく適切に対応することはできません。

OKTA は、カスタマイズされた影響レポートを提供し、独立したフォレンジックレポートを条件付きで顧客やパートナーが利用できるようにしたと述べました。これは建設的です。なぜなら、一般的な投稿では顧客固有の質問に答えられないからです。公開上の制限は、部外者が完全な独立レポート、すべてのカスタマイズされた調査結果の範囲、または内部ログ再構築の完全性を評価できないことです。メカニズムに対する信頼度は高く、OKTA と影響を受けた顧客が主要な事実で収束しているためです。是正効果に対する信頼度は低いままです。その多くは自己報告または非公開で共有されているためです。

将来のインシデントのために、アイデンティティプロバイダーはアーティファクトクラスに基づいて開示トラックを事前に定義すべきです。サポートファイルにセッション素材が含まれる可能性がある場合、顧客はセッション取り消しとテナントフォレンジックパッケージを受け取ります。サポートユーザーのレポートがダウンロードされた場合、顧客は連絡先データとフィッシングリスクガイダンスを受け取ります。サードパーティのサポートプラットフォームアカウントが悪用された場合、プロバイダーはファイルにアクセスできる経路と照会されたログを開示します。目標は、顧客の対応を露出メカニズムに一致させることです。

責任はアーティファクトの権限に従う

OKTA のインシデントは、責任がシステムラベルに従うと誤配分されやすいです。本番は侵害されなかったので、顧客のアイデンティティリスクは限定的だったと言うかもしれません。または、顧客が HAR ファイルをアップロードしたので、プロバイダーの責任は少ないと言うかもしれません。どちらの声明も部分的な真実を含み、制御の問題を見逃しています。責任は、アーティファクトに埋め込まれた権限とそれを保護する実践的な能力に従うべきです。

OKTA は、サポートシステムの設計、サービスアカウント、サードパーティ統合、ファイルアクセス、保持、ログ記録、レポート生成、顧客通知、プロバイダー側から利用可能なセッション取り消しアクション、将来の制御の推奨事項を管理しました。顧客は、生の HAR ファイルをアップロードするかどうか、それらをサニタイズするかどうか、トラブルシューティングに特権セッションを使用するかどうか、テナントアクティビティを監視する方法、露出した資格情報をローテーションする方法を管理しました。サポートプラットフォームプロバイダーは、自社のインフラと製品動作を管理しましたが、ここでレビューされた公開記録は契約上の過失や法的判断を確立するものではありません。

共有モデルはプロバイダーの役割を希釈すべきではありません。管理者診断をアップロードするよう顧客に求めるクラウドアイデンティティプロバイダーは、資格情報が含まれている可能性があるかのように受信システムを設計しなければなりません。ドキュメントの警告だけでは十分ではありません。ワークフロー自体が機密キャプチャを減らし、危険なアップロードにフラグを立て、アクセスを制限し、アーティファクトを期限切れにするべきです。プロバイダーのサポートプロセスが、認証後のライブシークレットを保持することでフィッシング耐性認証の経路を作り出す場合、プロバイダーはそのリスクの大部分を負います。

共有モデルはまた、顧客の義務を消去すべきではありません。管理者はブラウザキャプチャが機密であることを知るべきです。セキュリティチームはセッション異常を監視すべきです。サポートファイルは埋め込まれたシークレットについて棚卸しされるべきです。サポートアーティファクトで露出した資格情報は、たとえ最初のインシデントがサプライヤーで始まったとしても、ローテーションされるべきです。アイデンティティ管理は十分に強力であるため、両側が規律ある取り扱いを必要とします。

保持はサポートアップロードを持続的な資格情報リスクに変えた

サポートアーティファクトの有用な寿命は、その保存寿命よりも短いことがよくあります。HAR ファイルはアップロードされた日にケースの解決に役立つかもしれません。ケースが解決された後も利用可能で、セッション素材が含まれている場合、それは残留資格情報リスクになります。アクセス可能なままである期間が長ければ長いほど、アカウント侵害、サービスアカウントの誤用、エクスポート、バックアップコピー、または調査クエリがそれを露出させる機会が増えます。

OKTA の終了通知は、サポートシステムのプロビジョニングと保持のレビューを説明しました。それは正しい制御ファミリーです。保存されたオブジェクトが管理者権限を運ぶことができる場合、保持はハウスキーピングの詳細ではありません。システムは、ファイルが診断アーティファクトであるかどうか、トークンを含む可能性があるかどうか、関連ケースがいつ閉じるか、ファイルがいつ削除されるべきか、削除がプレビュー、重複オブジェクト参照、エクスポートされたレポート、バックアップをカバーするかどうかを知るべきです。そうでなければ、保持ポリシーは可視の添付ファイルを削除しても、同じコンテンツへの別の経路を残す可能性があります。

顧客も保持の証拠を必要とします。顧客がサポートファイルがアクセスされたことを知った場合、ファイルがいつアップロードされたか、最後にいつ閲覧されたか、まだ存在していたかどうか、コピーが存在したかどうか、埋め込まれたセッションがアクセス時にまだ有効だったかどうかを知る必要があります。その証拠は、取り消しだけで十分か、顧客が過去のテナントアクティビティを調査しなければならないかを決定します。不正アクセスの前に期限切れになったセッションアーティファクトは、アクセス中にライブだったものとは異なるリスクを生み出します。

短い保持はサポートの有用性と組み合わせるべきです。一部のケースは、より長い診断レビューを正当に必要とします。より安全なモデルは盲目的な削除ではありません。それは明示的な延長です。機密セッション素材を含むサポートファイルは、デフォルトで迅速に期限切れになるべきです。サポートがより長く必要とする場合、延長は正当化され、顧客に可視化され、ログ記録され、可能な場合は再認証またはトークン無効化と組み合わせられるべきです。顧客は、古いトラブルシューティングファイルがサードパーティシステムに残っているかどうかを推測する必要があるべきではありません。

同じ原則が連絡先レポートにも適用されます。サポートユーザーのレポートはアカウント管理に運用上有用かもしれませんが、一括エクスポートは制限され、監視されるべきです。なぜなら、それは可能性の高い管理者の厳選されたリストを作成するからです。保持とレポートのルールは、データの標的価値を反映すべきであり、プライバシー分類だけではありません。名前とメールアドレスはあるコンテキストでは低機密性であり、別のコンテキストでは高価値の標的データになり得ます。

API パリティは実際のセキュリティ問題だった

BeyondTrust のレポートは、微妙だが重要な問題を浮き彫りにしました：攻撃者は管理デバイスポリシーによって一つの経路を拒否され、その後、同じ制限が同じように適用されない API 経路を通じてアクティビティを試みました。これは単に BeyondTrust のテナントの詳細ではありません。それは繰り返し発生するアイデンティティ制御の問題です。Web コンソールのみを保護する管理ポリシーは、API 経路を実質的な執行境界として残す可能性があります。

アイデンティティプラットフォームは、自動化、統合、セキュリティ運用がそれらに依存するため、ますます API を通じて管理能力を公開しています。それは必要です。しかし、同等のデバイス、リスク、再認証、アクションレベルの制御なしにリプレイされたセッションやトークンを受け入れる API は、コンソールの見かけの強さを損なう可能性があります。攻撃者は、ポリシーがブラウザで良く見えるかどうかを気にしません。彼らはどの経路が権限を受け入れるかを気にします。

したがって、セッション結合はインターフェース間で評価されなければなりません。高リスクアクションがコンソールで管理デバイスまたは新鮮な認証を必要とする場合、同等のアクションを実行する API 呼び出しにも同等の制御が適用されるべきです。API が同じインタラクションパターンをサポートできない場合、スコープ付きトークン、短いライフタイム、明示的な管理者付与、またはより強力な異常検出などの異なる制御を必要とするべきです。顧客は次の質問ができるべきです：盗まれたブラウザセッションは管理 API に到達できるか、もしそうなら、どの制御がまだ適用されるか？

これはまたプロバイダーの開示問題です。サポートアーティファクトインシデントがセッション素材を露出させたとき、顧客はどの表面がその素材を受け入れる可能性があるかを知る必要があります。リスクは Web コンソールのみに適用されるか？API に適用されるか？シングルサインオンを通じて到達する下流のアプリケーションに適用されるか？OKTA セッションの取り消しはすべての関連経路を取り消すか？答えが検索計画を決定します。Cloudflare のモニタリング推奨事項と BeyondTrust の説明は、セッションリプレイ後に顧客が管理変更、ポリシーオーバーライド、MFA 変更、アカウント作成、API アクティビティを探す理由を示しています。

API パリティは、アイデンティティプロバイダーのデフォルトの保証パッケージに属します。ログイン時の強力な認証だけでは不十分です。認証後の素材がサポートチャネルを移動し、その後管理 API を行使できる場合。セキュリティの主張は、セッションのライフとそれを受け入れるすべてのインターフェースをカバーすべきです。

顧客証拠の引き渡しにはより迅速なセキュリティレーンが必要だった

顧客レポートは、サプライヤー側のインシデント発見が証拠に関する議論として始まる可能性があることを示しています。顧客は疑わしいテナント行動を見て、プロバイダーにサポートファイルアクセスを説明するよう求めます。プロバイダーは最初に顧客側の侵害を疑うかもしれません。顧客はエスカレーションし、指標を提供し、より多くのログを求め、プロバイダーがシステムを検索するのを待ちます。複数の顧客が並行してこれを行っている場合、プロバイダーだけが共通原因を相関させることができるかもしれません。

そのパターンは、アイデンティティプロバイダーと顧客のセキュリティチーム間の専用の証拠引き渡しレーンを主張します。通常のサポートキューはトラブルシューティングとケース解決に最適化されています。サプライヤー侵害の報告は異なるリズムを必要とします：ケースアーティファクトの保存、テナントイベント ID の収集、サポートケース ID の特定、プロバイダーセキュリティへのエスカレーション、顧客とプロバイダーのテレメトリの結合、顧客のリスク質問に答える文書化された調査結果の返却。セッションリプレイの可能性に関するケースは、日常的な設定質問のように動くべきではありません。

引き渡しはまた、証拠フォーマットを指定すべきです。顧客はセッション ID、IP アドレス、イベント ID、ケース番号、ファイル名、アップロード時間、管理者アカウント、疑わしいサポートアーティファクトを構造化された方法で提出できるべきです。プロバイダーは、チェックされたアクセス経路、カバーされた時間枠、使用されたログ、制限事項を返すべきです。1Password のオブジェクト識別子の問題は、これが重要である理由を示しています：ファイルは複数の方法で表現される可能性があるため、プロバイダーの回答はすべての経路が含まれていたかどうかを説明すべきです。

これは説明責任の制御です。なぜなら、初期の顧客証拠が他の顧客を保護できるからです。BeyondTrust が提供した IP アドレスは、OKTA が関連するサポートサービスアカウントを特定するのに役立ちました。それは通常のサポート結果ではありません。それはエコシステム検出です。プロバイダーは顧客テレメトリから利益を得ており、その貢献に値するエスカレーション経路を提供すべきです。信頼できる証拠を持ち込む顧客は、プロバイダーが顧客間パターンを検索する前に過度の摩擦を負うべきではありません。

顧客は、登録されたセキュリティ連絡先を維持し、ログを保存し、物語的な懸念ではなく正確な証拠を使用することで、相互に応答するべきです。アイデンティティプロバイダーは、セキュリティ連絡先の登録を可視化し、テストし、請求やサポート所有権と区別することで支援できます。サポートシステム侵害が発生したとき、適切な人々が営業やヘルプデスクの連鎖を待たずに適切なメッセージを受け取る必要があります。

より良いサポートアーティファクト契約

このインシデントは、アイデンティティプロバイダーと顧客の間の具体的なアーティファクト契約を示唆しています。第一に、プロバイダーはどのような種類の診断ファイルを要求する可能性があるか、およびそれらのファイルにどのような機密フィールドが含まれる可能性があるかを示すべきです。第二に、プロバイダーは、可能な場合、資格情報を削除しながら診断価値を保持するサニタイズ経路を提供または推奨すべきです。第三に、プロバイダーは、アップロードがセッション素材についてスキャンされるかどうか、およびそのような素材が検出された場合に何が起こるかを特定すべきです。第四に、プロバイダーはデフォルトの保持期間と顧客の削除オプションを明示すべきです。

第五に、プロバイダーは特権診断ファイルへのアクセスをセキュリティイベントとして扱うべきです。すべてのダウンロード、プレビュー、エクスポート、レポートへの包含、API アクセス、代替オブジェクト経路は、顧客、ケース、ファイル、アクター、時間、アクセス経路によってログ記録され、検索可能であるべきです。第六に、プロバイダーは露出したセッションの取り消しワークフローを定義すべきです。セッション素材を含むサポートアーティファクトが不正なアクターによってアクセスされた場合、顧客は取り消しと調査に十分なトークンまたはセッションの詳細を受け取るべきです。第七に、サードパーティのサポートシステムリスクは、調達書類に隠されるのではなく、プロバイダーの公開信頼性の物語の一部であるべきです。

顧客は契約の自分の側を受け入れるべきです。彼らは、低リスクのキャプチャが可能な場合は生の管理者キャプチャのアップロードを避けるべきです。問題が許す場合は、再現に一時的または低特権のアカウントを使用するべきです。サポートシステム露出後は、アップロードされたアーティファクトに見つかった資格情報をローテーションまたは取り消すべきです。管理セッションと API アクションを不可能なシーケンスについて監視するべきです。連絡先データ露出後のフィッシング対象となるため、サポートユーザーインベントリを維持すべきです。

この契約は、将来のインシデントをより曖昧でなくするでしょう。顧客はプロバイダーがサポートアーティファクトに対して何をすることを約束したかを知るでしょう。プロバイダーは、不正アクセス後にどの証拠を生成しなければならないかを知るでしょう。両側は、診断アップロードがアイデンティティ境界の一部になる可能性があることを知るでしょう。目標はサポートを遅くすることではありません。それは、扱う権限に対してサポートを安全にすることです。

インシデントは限定されていたが、制御の教訓は広い

公開記録は、OKTA のインシデントをすべての顧客テナントの侵害として扱うことを支持していません。OKTA は134件の顧客ファイル露出と5件のハイジャックされたセッションを報告しました。より広範なサポートユーザーレポートは連絡先データの露出であり、リストされた全員のテナントアクセスの証拠ではありません。これらの境界は、過大評価が説明責任を弱めるため重要です。正確な影響単位により、顧客は正しく対応できます。

同時に、限定された影響が教訓を小さくするべきではありません。アイデンティティサポートは、何千もの組織にわたって特権運用に近い位置にあります。このインシデントを可能にした同じサポートワークフローは、SaaS 管理、クラウドインフラ、エンドポイントセキュリティ、金融プラットフォーム、開発者ツールにわたって異なる形で存在します。診断アーティファクトは、しばしばサービスが信頼する状態を含んでいます。ケースシステムはしばしばサードパーティです。サポートユーザーはしばしば管理者です。レポートはしばしば高価値の連絡先を特定します。これらは構造的なパターンであり、OKTA だけの事実ではありません。

より広い制御の教訓は、サポートアーティファクトを権限によって分類することです。スクリーンショットは低リスクかもしれません。ログバンドルにはホスト名やユーザーID が含まれている可能性があります。HAR ファイルにはセッション素材が含まれている可能性があります。設定エクスポートにはシークレットが含まれている可能性があります。クラッシュダンプにはトークンやキーが含まれている可能性があります。各アーティファクトクラスは取り扱いルールを必要とします。すべてのサポート添付ファイルを一般的なファイルとして扱うことは、アイデンティティプロバイダーにとってはもはや防御可能ではありません。

その分類は顧客に可視化されるべきです。プロバイダーが診断ファイルを要求するとき、リクエストはファイルに資格情報が含まれる可能性があるかどうか、サニタイズ方法、盗まれた場合にどの権限が露出する可能性があるか、どの保持が適用されるかを示すべきです。その平易な運用開示は、多くのサポートアップロードが後で驚きのリスクオブジェクトになるのを防ぐでしょう。

説明責任のテスト

OKTA は、サポートアーティファクトをサードパーティの信頼境界にしました。なぜなら、侵害が顧客のアイデンティティ権限に、サポートワークフローが本番サービスの外部に保存していたファイルとセッションを通じて到達したからです。コアアイデンティティプラットフォームが侵害される必要はなく、顧客が管理者セッションリスクに直面するためには十分でした。サポート経路自体が重要な権限を運びました。

より良い基準は、アーティファクト認識型のアイデンティティサポートです。管理者診断はアップロード前にサニタイズされ、アップロード後に制限され、すべてのアクセス経路を通じてログ記録され、簡潔に保持され、セッション素材についてスキャンされ、取り消しまたは再認証ワークフローに結び付けられるべきです。サードパーティのサポートシステムは、アイデンティティアーティファクトを保存する場合、アイデンティティ隣接インフラとして管理されるべきです。顧客は、すべての特権診断キャプチャを一時的な資格情報として扱うべきです。

永続的な説明責任のポイントは正確です：クラウドアイデンティティにおいて、信頼はログインページで止まりません。それはセッションを追跡してチケット、添付ファイル、レポート、サポートサービスアカウント、顧客の検出ログに入ります。それらのアーティファクトが管理者を偽装できる場合、それらはアイデンティティ境界の一部です。