OKTA サポート侵害が示した、サポートアーティファクトがアイデンティティ顧客の第三者信頼境界となるリスク

概要

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

証拠マップ

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

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

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

この点は重要である。なぜならサポートは、中心的ではなく付随的なものとして扱われがちだからだ。本番のアイデンティティシステムは、アーキテクチャレビュー、侵入テスト、特権アクセス管理、顧客監査の対象になるかもしれない。ケース管理システムは、企業のワークフローツールとして扱われるかもしれない。しかし、そのワークフローツールが管理者セッションから取得した診断情報を保存する場合、そのアクセス制御、保持ポリシー、ログ、サービスアカウント、サードパーティのホスティング契約はアイデンティティ制御の一部となる。システムのラベルがリスクを決めるのではない。アーティファクトに埋め込まれた権限がリスクを決めるのだ。

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

これは、サポートが診断の使用をやめるべきだという意味ではない。特権セッションからの診断アーティファクトには制御されたライフサイクルが必要だということだ。可能な限り機密性の低いデータで作成され、アップロード前に可能な範囲でサニタイズされ、厳重に制限されたリポジトリに保存され、あらゆるアクセス経路でログが記録され、保持期間が短く、ケースに明確に関連付けられ、クレデンシャルリスクを反映したスケジュールで破棄されるべきである。アーティファクトに有効なセッション情報が含まれている場合、サービスはその情報を無効化するか再認証を強制できるべきである。

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

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

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

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

BeyondTrust の公開報告はこのリスクを具体的に示している。管理者がサポートの問題のために HAR ファイルを生成・アップロードし、そのファイルに API リクエストとセッション Cookie が含まれていた。攻撃者はその直後にセッションの再生を試みた。BeyondTrust のアクセスポリシーが1つの経路をブロックし、検出機能が試みを捕捉したが、アップロードされたアーティファクトは既に境界を越えていた。この一連の流れが示すのは、サポートアーティファクトは無害が証明されるまで保持者秘匿情報として扱われるべきだということだ。

より安全なサポートパターンは、生の機密キャプチャの必要性を減らすことだ。製品には、Cookie やトークンをデフォルトで削除する組み込みの診断バンドルを含めることができる。ブラウザツールは、明示的な警告の背後に機密エクスポートを置くことができる。サポートポータルはアップロードをスキャンして認識可能なセッションフィールドを検出し、トークンの失効や顧客の確認を強制できる。アイデンティティプロバイダーは、制限された権限を持つ一時的な診断セッションを提供できる。顧客は可能な場合、専用の低権限サポートアカウントを使用できる。これらの制御はいずれも完璧ではない。しかし組み合わせることで、本番管理者の有効な権限が持ち運び可能なサポート証拠になる可能性を減らす。

サードパーティツールが OKTA の説明責任を移すことはなかった

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

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

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

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

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

顧客が分散センサーになった

OKTA の顧客は中心的な検出役割を果たした。1Password、BeyondTrust、Cloudflare はそれぞれ、OKTA の公表前またはその頃に、自社環境内で疑わしいアクティビティを公に説明した。これは単に警戒心の強い顧客の話ではない。クラウド ID インシデントの構造的特徴である。プロバイダーは共有インフラストラクチャとサポートシステムへのアクセスを見る。各顧客はテナントアクティビティ、管理者の行動、デバイスポリシー、ローカルポリシー違反を見る。どちらの視点も単独では完全ではない。

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

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

この動的関係は、サポートエスカレーションの設計を変えるべきである。セッション再生、不可能な管理アクティビティ、またはサポートアーティファクトの相関に関する信頼できる証拠を提供する顧客は、通常のサポートの想定と格闘する必要があってはならない。ID プロバイダーは、顧客のテナント証拠をプロバイダー側のサポートシステムログと迅速に結合できる、信頼性の高いセキュリティエスカレーション経路を維持すべきである。最初の仮説が常に顧客のマルウェアやフィッシングであるべきではない。特に複数の顧客が同様のパターンを報告する場合はなおさらだ。

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

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

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

サポートユーザーはしばしば管理者、エンジニア、セキュリティスタッフ、またはアイデンティティ運用に近い従業員である。レポートの大部分が名前とメールアドレスのみを含んでいたとしても、攻撃者が特権アクセスを持つ可能性が高い人々や、アイデンティティプロバイダーのワークフローに影響を与える可能性がある人々を特定するのに役立つ可能性がある。FINRA はその後、OKTA カスタマーサポートシステムに関連するフィッシング攻撃の可能性について加盟企業に警告した。この警告は、すべての連絡先レコードが積極的に悪用されていたことを証明するものではない。厳選されたサポートユーザーリストの経済的価値を認識したものだ。

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

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

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

セッションバインディングとアーティファクトサニタイゼーションは補完的

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

サニタイゼーションは、アーティファクトが顧客のデバイスを離れる前にその価値を低減させる。Cloudflare の HAR Sanitizer はこのモデルの一例である：可能な限りトラブルシューティングに十分な構造を保持しつつ、クライアント側でセッション Cookie とトークンを削除する。ブラウザのデフォルトや製品固有の診断ツールも同様の作業を行える。機密情報がサポートシステムに入らなければ、サポートシステムが侵害されても流出する権限は少なくなる。

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

アーティファクトサニタイゼーションとセッションバインディングは、短いセッション有効期間、機密アクションに対する管理者の再認証、最近の認証のないセッションの異常検出、診断アーティファクトがセッション情報を含むことがわかっている場合の迅速な失効と結びつけるべきである。OKTA のその後の推奨事項には、セッションバインディングとタイムアウト関連の措置が含まれていた。説明責任のテストは、そのような管理策が最も高度な顧客向けのオプションの強化ではなく、高権限のアイデンティティ管理のデフォルトの期待事項になるかどうかである。

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

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

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

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

OKTA は、カスタマイズされた影響レポートを提供し、条件付きで独立した法医学レポートを顧客とパートナーに利用可能にしたと述べた。これは建設的である。なぜなら一般的な投稿では顧客固有の質問に答えられないからだ。公開情報の限界は、部外者が完全な独立レポート、カスタマイズされた各調査結果の範囲、内部ログ再構築の完全性を評価できないことである。メカニクスに対する信頼度は高い。なぜなら OKTA と影響を受けた顧客は主要な事実で一致しているからだ。改善策の有効性に対する信頼度は低いままである。なぜならその多くが自己報告されているか、非公開で共有されているからだ。

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

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

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

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

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

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

保持がサポートアップロードを持続的なクレデンシャルリスクに変えた

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

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

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

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

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

API の同等性は現実のセキュリティ問題だった

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

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

したがって、セッションバインディングはインタフェース全体で評価されなければならない。高リスクのアクションがコンソールで管理対象デバイスまたは新鮮な認証を必要とするなら、同等のアクションを実行する API 呼び出しにも同等の制御が適用されるべきである。API が同じ相互作用パターンをサポートできない場合、スコープ付きトークン、より短い有効期間、明示的な管理者許可、より強力な異常検出など、異なる制御を要求すべきである。顧客は、盗まれたブラウザセッションが管理 API に到達できるか、できるならどの制御がまだ適用されるかを尋ねられるべきである。

これはプロバイダーの開示問題でもある。サポートアーティファクトのインシデントがセッション情報を露出させた場合、顧客はどのサーフェスがその情報を受け入れる可能性があるかを知る必要がある。リスクは Web コンソールにのみ適用されるのか。API にも適用されるのか。シングルサインオンを介して到達する下流アプリケーションにも適用されるのか。OKTA セッションの取り消しは、関連するすべての経路を取り消すのか。これらの答えが調査計画を決定する。Cloudflare の監視推奨事項と BeyondTrust の報告は、顧客がセッション再生後に管理変更、ポリシーオーバーライド、MFA 変更、アカウント作成、API アクティビティを探す理由を示している。

API 同等性は、ID プロバイダーのデフォルトの保証パッケージに組み込まれるべきである。ログイン時の強力な認証だけでは不十分だ。認証後の情報がサポートチャネルを介して移動し、その後管理 API を実行できるなら、不十分である。セキュリティの主張は、セッションの生涯とそれを受け入れるすべてのインタフェースをカバーすべきである。

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

顧客報告は、サプライヤー側のインシデント発見が証拠をめぐる議論として始まりうることを示している。顧客は疑わしいテナント行動を見て、プロバイダーにサポートファイルアクセスを説明するよう求める。プロバイダーは当初、顧客側の侵害を疑うかもしれない。顧客はエスカレーションし、痕跡指標を提供し、より多くのログを要求し、プロバイダーがシステムを調査する間待つ。複数の顧客が同時にこれを行っている場合、プロバイダーだけが共有原因を相関付けられる唯一の当事者かもしれない。

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

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

これはアカウンタビリティの管理策である。なぜなら初期の顧客証拠が他の顧客を保護できるからだ。BeyondTrust が提供した IP アドレスは、OKTA が関連するサポートサービスアカウントを特定するのに役立った。これは通常のサポート成果ではない。エコシステム全体の検出である。プロバイダーは顧客のテレメトリから利益を得ており、その貢献にふさわしいエスカレーション経路を作るべきである。信頼できる証拠を持ち込む顧客は、プロバイダーが複数顧客にわたるパターンを調査する前に過度の摩擦を負うべきではない。

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

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

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

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

顧客は契約の自分たちの側を受け入れるべきである。可能な場合、低リスクのキャプチャが可能なところでは、生の管理者キャプチャのアップロードを避けるべきである。問題が許す場合、再現に一時的または低権限のアカウントを使用すべきである。サポートシステムの露出後には、アップロードされたアーティファクト内で見つかったクレデンシャルをローテーションまたは失効させるべきである。不可能なシーケンスについて管理セッションと API アクションを監視すべきである。サポートユーザーのインベントリを維持すべきである。なぜなら、それらのユーザーは連絡先データの露出後にはフィッシングの標的になるからだ。

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

インシデントは限定されていたが、管理の教訓は広範

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

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

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

その分類は顧客に見えるべきである。プロバイダーが診断ファイルを要求する場合、そのファイルにクレデンシャルが含まれる可能性があるかどうか、それをサニタイズする方法、盗まれた場合にどのような権限が露出する可能性があるか、どのような保持が適用されるかが要求に示されるべきである。この平易な運用開示は、多くのサポートアップロードが後で驚きのリスクオブジェクトになるのを防ぐだろう。

タイポグラフィと読みやすさに関する注記

タイポグラフィは、書かれた言語を読みやすく、可読性が高く、視覚的に魅力的にするために文字を配置する技術と技法である。これには、書体、ポイントサイズ、行長、行間、文字間隔の選択が含まれる。

• タイポグラフィは、15世紀にヨハネス・グーテンベルクが活版印刷を発明したことに端を発する。
• 主要な要素には、フォント選択、カーニング、トラッキング、リーディングが含まれる。
• 優れたタイポグラフィは可読性を高め、デザインのムードやトーンを伝える。

アカウンタビリティのテスト

OKTA は、サポートワークフローが本番サービスの外に保存していたファイルとセッションを通じて、サポートアーティファクトをサードパーティの信頼境界にした。これは、侵害が顧客の ID 権限に達したからだ。コアのアイデンティティプラットフォームが侵害される必要はなかった。サポート経路それ自体が重要なだけの権限を持っていた。

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

永続的なアカウンタビリティのポイントは正確だ：クラウド ID において、信頼はログインページで止まらない。それは、チケット、添付ファイル、レポート、サポートサービスアカウント、そして顧客の検出ログへとセッションを追いかける。それらのアーティファクトが管理者になりすますことができるなら、それらはアイデンティティ境界の一部である。