要約
- OneLogin の2017年の AWS キー侵害は、アイデンティティプロバイダーのアカウンタビリティテストとなった。同時期の OneLogin の声明では、米国データリージョンでの不正アクセスが報告され、後に攻撃者が AWS キーを使用して AWS API にアクセスし、顧客に対してキー、証明書、トークン、シークレット、パスワードにわたる広範な修復手順を推奨した。
- AWS キーの保存、顧客データの暗号化、アイデンティティプロバイダーの分離、トークンの無効化、顧客の修復ガイダンス、開示タイミング、SSO 侵害が永続的なアカウント暴露を残さなかったという証明について、実際に誰が実用的なコントロールを持っていたのか？
- アカウンタビリティの問題は、アイデンティティプロバイダーが顧客アクセスリスクを集中させるため、クラウドキーの侵害がセグメンテーション、暗号化、顧客修復の証拠のガバナンステストとなることである。
- エンタープライズ顧客、従業員、管理者、ダウンストリーム SaaS プロバイダー、セキュリティチーム、監査人、規制当局は、アイデンティティ信頼連鎖が単に復旧が宣言されるのではなく、リセットされ検証されるという証拠を必要としていた。
- この記事では、OneLogin のセキュリティ通知と顧客ガイダンスを引用した同時期の報道を2017年のインシデント記録の証拠として、OneLogin および One Identity の資料を製品および地域在住の文脈の証拠として、AWS および標準資料を管理ボキャブラリーとして、サードパーティの分析をインシデント対応とクラウドキーの教訓のサポートとして扱う。
なぜこのケースがリスクとアカウンタビリティファイルに属するのか
OneLogin がリスクとアカウンタビリティファイルに属する理由は、このサービスが単一の狭いデータセットを保持する通常のアプリケーションではなかったからである。それはアイデンティティプロバイダーだった。企業はこれを使用して、他の多くのアプリケーションへのアクセスを仲介し、SAML アサーションを発行し、OAuth や OpenID Connect フローをサポートし、プロビジョニングとデプロビジョニングを自動化し、認証ポリシーを集中管理していた。アイデンティティプロバイダーにインフラキーのインシデントが発生した場合、害の質問は単に1つのデータベースが触られたかどうかよりも大きい。実際的な問題は、顧客が他のクラウドサービスに到達するために使用する信頼連鎖が、攻撃者がプロバイダー側の暴露を耐久性のあるダウンストリームアクセスに変換する前にリセットできるかどうかになる。
公開記録は、2017年5月31日の OneLogin の開示から始まり、Krebs on Security（https://krebsonsecurity.com/2017/06/onelogin-breach-exposed-ability-to-decrypt-data/）や SecurityWeek（https://www.securityweek.com/onelogin-shares-more-details-breach-customer-impact/）で報じられた。これらの記事は、OneLogin が米国データリージョンでの OneLogin データへの不正アクセスを検出し、アクセスをブロックし、法執行機関に報告し、独立したセキュリティ会社と協力したと述べた。後の OneLogin の更新では、脅威アクターが AWS キーを取得し、それを使用して米国の中間プロバイダーから AWS API にアクセスし、偵察用のインスタンスを作成し、ユーザー、アプリ、キーの種類に関する情報を含むデータベーステーブルにアクセスしたと述べられた。また、OneLogin は攻撃者がデータを復号する能力を得た可能性を排除できないとした。
この組み合わせにより、このケースはアカウンタビリティテストとなった。AWS キーは単なるパスワードではない。インフラストラクチャ・アズ・ア・サービス環境では、権限に応じてインスタンスを作成し、メタデータを読み取り、サービス間を移動し、データベースに到達できる。AWS の共有責任モデル（https://aws.amazon.com/compliance/shared-responsibility-model/）は線を明確にしている：AWS は基盤となるクラウドインフラを保護し、AWS を使用する顧客はアイデンティティ、アクセス、データ構成、アプリケーションコントロールに対して責任を負う。このケースでは、OneLogin が AWS の顧客であり、OneLogin のエンタープライズ顧客は依存関係のある当事者であった。したがって、アカウンタビリティの連鎖はクラウドプロバイダー、アイデンティティプロバイダー、顧客テナントの3つのレベルにまたがっていた。
質問は実用的である：AWS キーの保存、顧客データの暗号化、アイデンティティプロバイダーの分離、トークンの無効化、顧客の修復ガイダンス、開示タイミング、SSO 侵害が永続的なアカウント暴露を残さなかったという証明について、実際に誰が実用的なコントロールを持っていたのか？答えは「キーをローテーションする」で止まらない。ローテーションは必要だが、アイデンティティ修復の一部に過ぎない。顧客は、どの信頼オブジェクトが影響を受け、どのオブジェクトが潜在的に影響を受け、どれを直ちに交換し、どれを監視し、どの証拠がクロージャを示すかを知る必要があった。
OneLogin の現在の製品ポジショニング（https://www.onelogin.com/）は、従業員、顧客、パートナー向けの集中型アイデンティティ管理、数千ものアプリケーション統合、アダプティブ認証、自動化されたライフサイクル管理を重視している。このポジショニングは、2017年のイベントの重要性を説明している。集中化されたアクセスを提供するプロバイダーは、機能する場合には断片化を減らす。しかし、自身のコントロールプレーンが侵害されると、不確実性を集中させることもできる。アカウンタビリティ修復ファイルは、集中化が無制限の爆発半径にならないことを示さなければならない。
アイデンティティプロバイダーのインシデントは通常のデータ侵害ではない
多くの侵害分析は記録の数を数える。アイデンティティプロバイダーのインシデントは異なる測定を必要とする。アイデンティティプロバイダーは、ユーザーID、アプリケーション割り当て、フェデレーション設定、署名証明書、API クレデンシャル、MFA 統合、アプリコネクタ、セッションコントロール、管理ポリシーを保存または仲介する。これらのオブジェクトの一部はデータであり、一部は権限であり、一部は権限が受け入れられる場所のマップである。攻撃者がマップを見て、権限を証明するオブジェクトを見る可能性がある場合、ダウンストリーム顧客はインシデントがプロバイダー自身のアカウント境界を超えて拡大する可能性を想定しなければならない。
OneLogin の開発者ドキュメントはその理由を示している。API の概要（https://developers.onelogin.com/api-docs/1/getting-started/dev-overview）は、API が OAuth 2.0で保護され、顧客の OneLogin サブドメインを API ドメインとして使用することを述べている。API クレデンシャルのページ（https://developers.onelogin.com/api-docs/1/getting-started/working-with-api-credentials）は、API コールにはクレデンシャルペアで取得した OAuth ベアラーアクセストークンが必要であると説明している。トークン生成ページ（https://developers.onelogin.com/api-docs/2/oauth20-tokens/generate-tokens-2）は、リソース API のアクセストークンとリフレッシュトークンの生成を説明している。これらのドキュメントは現在の製品ドキュメントであり、2017年のインシデントのフォレンジック証拠ではない。しかし、一般的なアイデンティティプロバイダーの真実を示している：トークン、クライアント、シークレット、ドメイン、ロールは、受動的なメタデータではなく運用上の権限である。
フェデレーションについても同様である。OneLogin の SAML 概要（https://developers.onelogin.com/saml）は、OneLogin を SAML で SSO を有効にするツールとして説明している。OpenID Connect の概要（https://developers.onelogin.com/openid-connect）は、OpenID Connect を OAuth 2.0の上のアイデンティティ層として説明している。ログアウト API ページ（https://developers.onelogin.com/openid-connect/api/logout）は、OneLogin セッションを終了し、その SSO セッションで発行されたトークンを無効にすることを説明している。これらもインシデントの事実ではなく製品ドキュメントであるが、アイデンティティプロバイダーのイベント後の顧客の修復負担が大きくなりうる理由を説明している。フェデレーション信頼は、証明書、トークン、エンドポイント、メタデータがアイデンティティプロバイダーを権威あるものとしているため、サービスプロバイダーに受け入れられている。
同時期の顧客対応分析（Ryan McGeehan、https://magoo.medium.com/onelogin-breach-2017-retrospective-708305d83e2d）は、その実用的な負担を反映していた。記事は明示的に読者を OneLogin のサポート記事に真実の情報源として戻し、SAML 証明書、2FA 統合シークレット、Secure Notes の内容、非 SAML パスワード、API クレデンシャル、関連する信頼オブジェクトのローテーションなどのカスタマーアクションについて議論した。その記事は OneLogin のポストモーテムではないが、実務者が爆発半径として理解していたもの、すなわち狭いパスワード変更ではなく調整されたアイデンティティリセットが必要であることを示している点で貴重である。
したがって、この種のインシデントのアカウンタビリティ基準は「顧客データがアクセスされた」よりも高い。有用な公開記録は、どのアイデンティティ資料が確認されアクセスされたか、暗号化境界が証明できなかったためにどれが露出された可能性があるか、どれを予防的にローテーションする必要があったか、顧客が完了をどのように検証できるか、そして OneLogin が同様のインフラキー暴露が顧客の信頼オブジェクトに到達する可能性を低くするために何を変更したかを特定すべきである。
AWS キーがインシデントをクラウドコントロールプレーンに関連付けた
このインシデントはクラウドサービス依存のケースである。公開記録で述べられたトリガーは AWS キーへのアクセスだったからである。AWS キーは狭くまたは広くスコープできる。長寿命であるか、一時的なクレデンシャルに置き換えることができる。ポリシーによって監視、制約、ローテーション、拒否が可能である。また、過剰な権限が付与されていたり、アプリケーションや運用の侵害が到達可能な場所に保存されていたり、異なる障害境界を持つサービ間で再利用されたりすると危険になる。
AWS の IAM ベストプラクティス（https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html）と一時的クレデンシャルのドキュメント（https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html）は、最小特権、一時的クレデンシャル、ロール、特権アクセスに対する MFA、アクセスレビュー、慎重なアクセスキー取り扱いという現代の管理ボキャブラリーを提供している。これらのドキュメントは、OneLogin が2017年に AWS 環境をどのように構成したかを正確に公開していない。しかし、アカウンタビリティファイルが尋ねるべきコントロールクラスを定義している：キーは長寿命だったか？ユーザーまたはロールにアタッチされていたか？侵害されたキーはインスタンスを作成できたか？本番データベースに到達できたか？権限はデータリージョン、機能、環境によって分離されていたか？異常アラートは自動封じ込めに結びついていたか？
Nordcloud のクラウドセキュリティに関する同時期の議論（https://nordcloud.com/blog/design-aws-api-access-with-care-case-onelogin-copy/）は、OneLogin のケースを使用して、ロールベースのアクセス、MFA で強制されたロール切り替え、可能な場合の静的 API キーの回避を主張した。その記事は他の場所で引用された同じ OneLogin の更新に依存しているため、独立したフォレンジック権威ではない。その価値は、クラウドコントロールの教訓を枠組みすることにある：プロバイダーは、1つの露出したクレデンシャルが自由にインフラを作成したり、環境を探索したり、追加の境界なしにデータストアに到達できないように AWS API アクセスを設計すべきである。
クラウドコントロールプレーンの問題は、アイデンティティプロバイダー自身がクラウドテナントであるために重要である。エンタープライズ顧客は、運用すべき認証システムの数を減らすために OneLogin を購入するかもしれないが、OneLogin の AWS IAM ポリシー、キーストレージ設計、インシデントアラート、データベースセグメンテーション、暗号化キーの管理を直接検査することはできない。したがって、プロバイダーは隠されたコントロールを顧客が信頼できる証拠に変換しなければならない。認証とコンプライアンスのページは役立つが、キー暴露が発生した場合のインシデント固有の証拠を置き換えるものではない。
OneLogin のコンプライアンスページ（https://www.onelogin.com/compliance）と GDPR ページ（https://www.onelogin.com/compliance/gdpr）は、顧客が通常レビューするガバナンス表明の種類を示している：プライバシー、認証、データ処理、侵害通知の文言、データフロー、コンプライアンスサポート。これらのページはインシデント後の根本原因報告ではない。調達の約束を示している。2017年の侵害は、約束が実際のインフラキー侵害に耐えられるかどうか、そして顧客が正確な行動を取るのに十分な証拠を持っていたかどうかをテストした。
したがって、アカウンタビリティはキーの管理と爆発半径の設計に関連する。キーが偵察インスタンスを作成できる場合、プロバイダーはそのキーがどのようにスコープされ、どのように検出されたかを示すべきである。キーがデータベースに到達できる場合、プロバイダーはデータベースレベルの暗号化キーがアプリケーションやインフラクレデンシャルから分離可能かどうかを示すべきである。キーが検出後に無効にされた場合、プロバイダーは派生したセッション、作成されたインスタンス、スナップショット、一時的なクレデンシャル、データコピーが残っていないかどうかを示すべきである。クラウドキーのインシデントは、キーによって作成されたすべての権限パスがトレースされるか無効にされるまでクローズされない。
顧客の修復が実際のアイデンティティ修復だった
顧客の修復作業は OneLogin インシデントの中心だった。Krebs は、顧客メッセージが組織に対して新しい API キーと OAuth トークンの生成、新しいセキュリティ証明書とクレデンシャルの作成、Secure Notes に保存されたシークレットの再利用、エンドユーザーのパスワードの更新を指示したと報じた。Medium の実務者回顧は、SAML 証明書、2FA 統合トークン、非 SAML パスワード、Secure Notes、API クレデンシャルを実際の対応オブジェクトとして扱った。CSO の後の記事（https://www.csoonline.com/article/567155/how-onelogin-responded-to-its-breach-and-regained-customer-trust.html）も、このイベントを迅速な対応と透明性を必要とする顧客信頼問題として説明した。
この修復リストは、プロバイダーの封じ込めと顧客の修復の違いを示す点で重要である。プロバイダーの封じ込めは、不正アクセスをブロックし、侵害された AWS キーを無効にし、影響を受けたインフラをシャットダウンし、調査し、ガイダンスを発行する。顧客の修復は、ダウンストリームアプリケーションが OneLogin のアサーション、API コール、保存されたクレデンシャルを受け入れるために使用する信頼資料を変更する。顧客がこの第二のステップを完了しなければ、プロバイダーは技術的に復旧しても、顧客環境は露出されたままになる可能性がある。
SAML 証明書のローテーションは特に有用な例である。OneLogin の SAML 署名証明書ガイダンス（https://www.onelogin.com/blog/saml-signing-certificates）と SAML 構成ガイダンス（https://www.onelogin.com/blog/saml-configuration）は、証明書、フィンガープリント、エンドポイント、SSO 設定が SAML 統合管理の一部であることを説明している。署名証明書が侵害された可能性がある場合、その証明書を信頼する各サービスプロバイダーは、更新された証明書とメタデータを必要とする可能性がある。これは複雑なエンタープライズにとってワンクリックの修復ではない。数百から数千のアプリケーション、ビジネスオーナー、ベンダーポータル、テストウィンドウ、ダウンタイムリスク、どのアプリが新しいアイデンティティ資料を信頼しているかの検証が含まれる可能性がある。
OAuth と API トークンのローテーションは異なる運用形状を持つ。API クレデンシャルは自動化、スクリプト、プロビジョニングジョブ、レポートコネクタ、統合ミドルウェアに埋め込まれている可能性がある。ローテーションが不完全な場合、古いトークンやシークレットが忘れられたワークフローで機能し続ける可能性がある。在庫なしに急いでローテーションすると、ビジネスプロセスが壊れる可能性がある。そのため、セキュリティ自動化がこのケースのトピックである。顧客はアプリケーション、証明書、トークン、保存されたシークレット、特権コネクタの機械可読な在庫を必要としていた。古い資料がまだ使用されているかどうかを示すログが必要だった。アイデンティティリセットが実際にすべての受け入れシステムに到達したことを証明する方法が必要だった。
アカウンタブルなプロバイダーはその作業をサポートすべきである。修復ガイダンスは具体的で、優先順位付けされ、タイムスタンプが付けられ、テスト可能であるべきである。「直ちにローテーション必須」と「予防的ローテーション」、および「不審な使用の監視」を区別すべきである。可能な場合には検出クエリ、管理レポート、エクスポート可能なアプリ在庫、証明書の有効期限と交換ステータス、トークン発行と無効化ログ、リスクの高い統合のためのカスタマーサポートトリアージを含むべきである。これらの成果物がなければ、修復は手動のスクランブルになり、手動のスクランブルは耐久性のあるギャップを残す。
したがって、このインシデントはアカウンタビリティファイルに属する。修復の作業が分散されていたからである。OneLogin は侵害されたクラウド環境と製品ガイダンスを管理していた。顧客は自身のアプリ統合とダウンストリームの信頼アンカーを管理していた。ダウンストリームの SaaS プロバイダーは、SAML 証明書や OAuth クライアントがどの程度迅速に交換されるかを管理していた。アカウンタビリティは、単一の当事者がリセットを完了できるというふりをするのではなく、その連鎖に従わなければならない。
暗号化の主張は鍵の分離の証明を必要とする
OneLogin の引用された更新は、同社が特定の機密データを保存時に暗号化しているが、攻撃者がデータを復号する能力を得た可能性を排除できないと述べた。これは公開記録の中で最も重要な文である。すべての暗号化データが復号されたことを証明するものではない。しかし、保存時の暗号化だけでは、AWS キー暴露後の十分な公開保証ではなかったことを示している。顧客は、暗号化キー、キー暗号化キー、アプリケーションシークレット、データベーステーブル、アクセスパスが十分に分離されており、データベースアクセスが平文の露出にならないかどうかを知る必要があった。
これは一般的なアカウンタビリティギャップである。暗号化はしばしば二値のコントロールとして説明されるが、インシデント対応はそれを保管の連鎖に変える。保存時に暗号化されたデータは、攻撃者がそれを復号するために必要な素材やサービス権限も取得できない場合にのみ保護される。同じ運用環境に暗号文とキーまたはキーアクセス権限の両方が含まれている場合、インフラ侵害が境界を越える可能性がある。キーが厳格な権限、監査証跡、エンベロープ暗号化を持つ別のサービスに保持されている場合、爆発半径は小さくなりうる。公開記録は、2017年にどの設計が適用されていたかを証明するのに十分な詳細を提供していない。
データ主権と地域性のトピックもここに現れる。OneLogin の現在のステータスページ（https://www.onelogin.com/status）は、欧州経済地域の地理的に分散したデータセンターでホストされる欧州データレジデンシーオプションを提供していると述べている。対照的に、インシデント記録は米国データリージョンに関するものであった。アカウンタビリティの質問は、すべてのグローバル顧客が物理的に同じデータベースにいたかどうかではない。顧客がどのリージョンが自分たちをサービスしているか、そのリージョンにどのデータと信頼資料があるか、どのようなクロスリージョンまたはサポートパスが存在するか、インシデント通知が地域の露出にどのようにマッピングされるかを知ることができるかどうかである。
データレジデンシーは時に所在地としてマーケティングされる。インシデントでは、それは証拠にならなければならない。顧客は、認証データ、アプリケーションメタデータ、シークレット、ログ、バックアップ、サポートエクスポート、分析、管理アクセスが地域にバインドされているか、他の場所にコピーされているかを知る必要がある。米国データリージョンのインシデントが米国でホストされているテナントのみに影響するのか、グローバル管理システムにも影響するのかを知る必要がある。あるリージョンのキーやログが別のリージョンのデータをロック解除できるかどうかを知る必要がある。OneLogin の2017年の公開記録は地域のアンカーを提供したが、完全なデータフローマップは提供しなかった。
GDPR（https://eur-lex.europa.eu/eli/reg/2016/679/oj）は、データ保護のアカウンタビリティを所在地よりも広くしている。OneLogin の GDPR ページは、データフロー、侵害通知責任、プライバシーバイデザインについて議論している。アイデンティティプロバイダーにとって、プライバシーバイデザインには、保存されたシークレットの最小化、復号権限の分離、地域認識のサポートアクセス、インシデント対応を生き残るログ、約束された境界外にデータが複製されなかったという顧客向けの証拠が含まれるべきである。侵害後のアカウンタブルな質問は、これらの原則が測定可能なコントロールになったかどうかである。
教訓は、OneLogin が復号を排除できなかったために暗号化が失敗したということではない。教訓は、暗号化の主張はキー分離の証拠によって裏付けられなければならないということである。プロバイダーが盗まれたインフラクレデンシャルがキー素材に到達できないことを証明できる場合、顧客は修復範囲をより狭くできる。プロバイダーがそれを証明できない場合、顧客は広くローテーションし、保存されたクレデンシャルが露出した可能性があると想定し、インシデントを信頼連鎖のリセットとして扱わなければならない。
開示のタイミングと証拠の境界が重要
公開証拠は、OneLogin が2017年5月31日に不正アクセスを検出し、ブロックし、法執行機関に報告し、独立したセキュリティ会社と協力したことを示している。後の詳細によると、攻撃は太平洋時間の午前2時頃に始まり、スタッフは午前9時頃に警告を受け、影響を受けたインスタンスと AWS キーは検出から数分以内にシャットダウンされた。これらの事実は、Krebs、SecurityWeek、実務者回顧を含む同時期の報道で引用された OneLogin の声明を通じて伝えられた。OneLogin の元のインシデントページは現在も安定した情報源ではなく、One Identity の Web サイト内でリダイレクトされるため、公開記録は慎重に扱わなければならない。
この証拠の制限自体がアカウンタビリティの一部である。インシデント通知は、顧客、監査人、規制当局、研究者、調達チームが過去のプロバイダーの行動を評価する必要があるため、安定した場所に利用可能またはアーカイブされるべきである。現在のコンプライアンスページは古いインシデント通知を置き換えることはできない。通知を引用したサードパーティの記事は有用だが、元の通知、更新履歴、顧客ガイダンス、最終的な教訓を含む永続的なプロバイダーアーカイブよりも弱い。
したがって、記事は確認された事実、支持された推論、未知のものを分離する。確認された公開事実には、米国リージョンでの OneLogin データへの不正アクセス、引用された AWS キーパス、偵察インスタンスの作成、ユーザー、アプリ、キータイプを含むデータベーステーブルへのアクセス、復号能力を排除できないこと、顧客の修復推奨が含まれる。支持された推論には、AWS IAM スコーピング、暗号化キー分離、データリージョンマッピング、SAML 証明書ローテーション、OAuth トークン無効化、顧客側の在庫が中心的なコントロールオブジェクトであったという結論が含まれる。未知のものには、正確なキー権限、アクセスされた完全なデータベース内容、完全なキー管理アーキテクチャ、すべての顧客通信、すべてのフォレンジック調査結果、すべての顧客ローテーションの完了状況が含まれる。
この規律は、アイデンティティプロバイダーの侵害が憶測を招くため重要である。すべてのダウンストリーム SaaS アカウントが侵害されたと主張するのは簡単だが、公開記録はそれを証明していない。また、OneLogin が検出後にアクセスをブロックしたためインシデントを最小限に抑えるのも簡単だが、公開記録はそれも支持していない。正しいアカウンタブルな読み方は、プロバイダー側の AWS キー侵害が、顧客が広範な信頼資料をローテーションするように指示されるほど信頼性のあるアイデンティティ爆発半径を生み出したということである。
開示のタイミングには第二の目的がある：顧客がログを検索できるようにする。インシデントが午前2時頃に始まり、検出が午前9時頃だった場合、顧客はその時間帯およびその後のダウンストリームアプリケーションログ、OneLogin アクティビティログ、API 使用状況、SAML アサーション受け入れ、MFA プロバイダーイベント、管理者変更を調べることができる。時間に縛られた証拠は、プロバイダーが十分なタイムスタンプと成果物カテゴリを提供する場合にのみ価値がある。曖昧な開示は、顧客が自分たちの損害を探す能力を奪う。
したがって、アカウンタブルな修復記録には、保持されたタイムライン、影響を受けたコントロールカテゴリのリスト、顧客修復マトリックス、明確な「まだわからないこと」のセクションを含めるべきである。一般はすべてのプライベートフォレンジック成果物を必要としないが、顧客はリセットの自分の部分を実行するのに十分な詳細を必要とする。
セキュリティ自動化はアラートと爆発半径のギャップを埋めなければならない
OneLogin の引用されたタイムラインは、AWS API アクティビティの開始からスタッフへの警告まで数時間の検出ギャップを示唆している。公開記録は完全な監視アーキテクチャを示していないため、孤立したアラートを判断するのが目的ではない。アカウンタビリティの問題は、クラウドコントロールプレーンのクレデンシャルが高信頼のアイデンティティプロバイダー環境で異常な動作を開始した場合、セキュリティ自動化が何をすべきかである。
現代のクラウドインシデント対応は、異常な AWS API コールが即時の封じ込めをトリガーするかどうか、キーの使用がソース、アカウント、ロール、サービス、期待されるワークフローによって制限されているかどうか、デプロイメントシステム外でのインスタンス作成がブロックされるか重くアラートされるかどうか、データベースアクセスの異常がアイデンティティリスクスコアリングに結びついているかどうか、本番シークレットがコンピュートを管理する同じクレデンシャルで到達可能かどうかを尋ねるべきである。AWS、CISA、NIST の資料は言語を提供している。CISA のセキュアバイデザインガイダンス（https://www.cisa.gov/resources-tools/resources/secure-by-design）は、顧客が予防可能なリスクを吸収することを強いられないように製品を設計することを強調している。NIST サイバーセキュリティフレームワーク（https://www.nist.gov/cyberframework）は、特定、保護、検出、対応、回復の構造を提供している。
アイデンティティプロバイダーにとって、自動化は顧客も支援しなければならない。OneLogin の現在の製品資料は、アダプティブ認証、リスクスコア、SIEM およびクラウドコミュニケーションツールへのログインイベントのストリーミングについて述べている。現在のホームページ（https://www.onelogin.com/）は、プラットフォームが不審な動作を検出し、アダプティブ認証を実施できると述べている。開発者のクラウド脅威に関する記事（https://developers.onelogin.com/blog/cloud-threats）は、有効なアカウントの悪用、不審な指標、自動通知に関する検出および対応機能を議論している。これらの後の製品資料は2017年に何が存在したかを証明するものではないが、アイデンティティ企業から顧客が期待する自動化の種類を特定している。
プロバイダー侵害後、顧客向け自動化は4つの質問に迅速に答えるのに役立つべきである。どのアプリケーションがこのアイデンティティプロバイダーを信頼しているか？どの証明書と OAuth クライアントがアクティブか？どのユーザーがローテーションを必要とする可能性のある保存されたクレデンシャルまたは Secure Notes を持っているか？疑惑の期間中にどのダウンストリームアプリケーションがアサーションまたは API コールを受け入れたか？これらの回答がなければ、対応チームはプレッシャーの下でスプレッドシートを作成しなければならない。影響を受けたプロバイダーがアクセスの中核である場合、スプレッドシートはうまくスケールしない。
セキュリティ自動化はまた、有効期限と無効化のセマンティクスを必要とする。無効にされたトークンは機能を停止すべきである。ローテーションされた SAML 証明書は古い信頼アンカーを置き換えるべきである。パスワードリセットは可能な場合に古いセッションを無効化すべきである。MFA 統合シークレットは、ユーザーを孤立させたり緊急アクセスを無効にしたりせずに交換可能であるべきである。製品は顧客にどの古い資料がまだ受け入れられているかを示すべきである。アイデンティティプロバイダーがそれを示せない場合、修復を完全に運用化していない。
アカウンタビリティの教訓は、検出速度と修復ツールが連動していることである。プロバイダーはインシデントを検出し、迅速にガイダンスを発行するかもしれないが、顧客が安全かつ完全にガイダンスを実行できない場合、爆発半径は持続する。したがって、セキュリティ自動化はアラート生成だけでなく、プロバイダーと顧客がアイデンティティ信頼を無効化、交換、検証できる速度によって測定されるべきである。
データローカリティは顧客コミュニケーションの負担を変える
OneLogin のインシデントは米国データリージョンに影響を与えると説明されたが、OneLogin の現在のトラストページは欧州データレジデンシーオプションを説明している。この区別は、アイデンティティプロバイダーが異なる規制、契約、運用上の期待を持つグローバル顧客にサービスを提供するため重要である。地域の暴露通知は、顧客がその地域にいるかどうか、どのデータカテゴリが地域にバインドされているか、サポートまたはバックアップデータが地域をまたぐかどうか、アイデンティティ信頼オブジェクトがローカルかグローバルかを伝えるべきである。
データローカリティはプライバシーの問題だけではない。インシデント対応の問題でもある。顧客が自分のテナントが特定のリージョンからサービスされていることを知っていれば、規制上の通知義務、ログ保持検索、ダウンストリーム修復の優先順位をマッピングできる。プロバイダーのコントロールプレーンが共有グローバルサービスを使用している場合、地域ラベルは不十分かもしれない。2017年のイベントに関する公開記録は完全なアーキテクチャ説明を提供していなかった。これはセキュリティ上の理由から理解できるが、顧客は依然として実行可能なスコーピングを必要としていた。
GDPR ページ（https://www.onelogin.com/compliance/gdpr）は、データマッピング、データ処理契約、侵害通知、顧客のアクセス、ポータビリティ、デプロビジョニング、監査のためのツールについて議論している。これらのトピックはアイデンティティプロバイダーのインシデントと直接交差する。テナントが EU ユーザーを保持しているが米国リージョンからサービスされている場合、顧客は越境移転と通知の質問を評価する必要がある。テナントが EEA リージョンからサービスされている場合でも、顧客はサポートログ、分析、キー、バックアップが他の場所で影響を受けたかどうかを知る必要がある。依存関係マッピングなしのレジデンシーは不完全である。
顧客にとって、アイデンティティインシデント後のコミュニケーション負担には2つの層がある。最初に、OneLogin は顧客が自分の環境を保護するのに十分な情報を伝えなければならなかった。次に、それらの顧客は従業員、パートナー、監査人、規制当局、ダウンストリームサービスオーナーに伝えるかどうか、どのように伝えるかを決定しなければならなかった。広範な「すべてをローテーションする」指示は過小対応のリスクを減らすが、ビジネスの中断を増やす。狭い指示は中断を減らすが、未知の露出を見逃す可能性がある。最良の証拠は顧客が比例的に選択することを可能にする。
データローカリティは調達のアカウンタビリティにも影響する。企業はアイデンティティプロバイダーを地域、コンプライアンス態勢、稼働時間、サポート、統合の広さに基づいて部分的に購入する。ステータスページ（https://www.onelogin.com/status）とコンプライアンスページは調達記録の一部となる。インシデントが発生した場合、プロバイダーは調達の約束と実際の暴露マップを調和させることができるべきである。どのリージョンが影響を受けたか？どの顧客がそこにいたか？どの成果物がそこに保存されていたか？どのコントロールが他のリージョンやシステムを爆発半径外に保ったか？その結論を支持する証拠は何か？
したがって、2017年のケースは、クラウドアイデンティティが現在さらに地域的で規制されているため、依然として関連性がある。顧客は、プロバイダーが地域性をマーケティングフィールドではなくコントロールサーフェスとして扱うことを必要としている。地域ラベルには、インシデントに耐えられる応答証拠、データフローマップ、信頼オブジェクトのインベントリが伴うべきである。
顧客側には独自のアカウンタビリティファイルが必要だった
OneLogin はプロバイダー環境を管理していたが、顧客は多くのダウンストリーム結果を管理していた。数百の SaaS 統合に OneLogin を使用している顧客は、どのアプリが SAML に依存し、どのアプリが OIDC を使用し、どのアプリがパスワードを保存し、どのアプリが API クレデンシャルを保存し、どのアプリが MFA プロバイダー統合を使用し、どの管理者が特権を持ち、どのユーザーが保存されたシークレットを持っているかを知る必要があった。顧客がそのインベントリを欠いていた場合、プロバイダーのインシデントはベンダーのインシデントだけでなく、顧客のガバナンスの弱さも露呈した。
これがアイデンティティ集中化の不快な真実である。アイデンティティプロバイダーを購入しても、アイデンティティ依存関係を理解する顧客の義務はなくならない。その義務の形が変わる。顧客は、アプリケーションインベントリ、信頼オブジェクトインベントリ、証明書ローテーションプロセス、緊急フェデレーション手順、ブレークガラスアクセス設計、非 SAML クレデンシャルポリシー、Secure Notes ポリシー、トークン無効化ワークフロー、インシデント後のログ検索プロセスを維持すべきである。OneLogin はガイダンスとツールを提供できたが、各顧客は自身の環境内で実行しなければならなかった。
SAML および OIDC 統合は、ビジネスオーナーが各アプリケーションの技術的オーナーを知らない可能性があるため、ローテーションが特に難しい場合がある。サービスプロバイダーは移行期間中に古い証明書と新しい証明書の両方を受け入れる場合もあれば、計画されたダウンタイムを必要とする場合もある。一部の SaaS 管理者はもういないかもしれない。一部のアプリメタデータは古くなっているかもしれない。一部の統合はプロジェクト用に作成され、文書化されていない可能性がある。アイデンティティプロバイダーの侵害は、その管理上の負債を即時のリスクに変える。
Krebs によって報告された修復リストには、Secure Notes に保存されたシークレットと非 SAML パスワードも含まれていた。これはポリシーの問題を露呈する。アイデンティティプラットフォームがユーザーや管理者にシークレットを保存することを許可する場合、顧客は何を保存できるか、誰がそれをエクスポートできるか、どのように暗号化されるか、使用状況が報告可能か、影響を受けるすべてのシークレットをどれだけ迅速に特定できるかについてルールを必要とする。顧客が機能を使用した人をリストできない場合、対応は推測になる。プロバイダーの機能は通常運用では便利だが、在庫とライフサイクルコントロールがない場合、侵害対応では危険になる。
顧客はまた、ダウンストリームアプリケーションでの異常なアクセスを確認する必要があった。SAML 証明書侵害のリスクは証明書の問題だけではない。アクセスの問題である。どのサービスプロバイダーが異常なアサーションを受け入れたか？どの管理者ロールが変更されたか？どのユーザーセッションが持続したか？どの API クライアントが予期しないコールを行ったか？どの MFA プロバイダーが調査されるべきトークン使用を見たか？これらの質問には、複数のベンダーにわたって保持されたログが必要である。また、インシデント前に準備されたクロック、相関 ID、SIEM パイプラインが必要である。
したがって、OneLogin 顧客のアカウンタビリティファイルには、ベンダーの証拠と顧客の証拠の両方が含まれるべきである。ベンダーの証拠：何が起こったか、何が影響を受けたか、何をローテーションするか、何が変更されたか、何が未知のままか。顧客の証拠：何がローテーションされたか、いつ、誰によって、どのアプリが検証されたか、どのログが検索されたか、どの例外が残っているか、将来の爆発半径を減らすためにどのポリシーが変更されたか。
調達は機能リストだけでなく証拠を評価すべき
OneLogin インシデントは、顧客がアイデンティティプロバイダーを評価する方法を変えるべきだった。機能リストは重要だが、調達はインシデント証拠のプラクティスも質問すべきである。プロバイダーは古いインシデント通知を保持しているか？可能な場合にインシデント後の教訓を公開しているか？アプリ在庫、証明書、API クレデンシャル、MFA 統合、保存されたシークレット、ログ、管理者アクションのための顧客エクスポートツールを提供しているか？データリージョン境界を文書化しているか？大規模な緊急信頼ローテーションをサポートしているか？実際の顧客義務に一致する侵害通知の文言を提供しているか？
現在の OneLogin のコンプライアンスページとステータスページは有用な調達インプットであり、One Identity の買収コンテキストは2017年以降のガバナンスと製品アーキテクチャを変更している可能性がある。しかし、耐久性のあるアカウンタビリティレビューはストレス下での行動を見る。プロバイダーはどれだけ迅速に開示したか？ガイダンスはどの程度具体的だったか？顧客は可能性のある爆発半径を理解したか？プロバイダーは排除できないことを述べたか？プロバイダーはインシデントをアーキテクチャ変更に変換したか？後の資料はより強力な自動化、地域オプション、アイデンティティリスクコントロールを示しているか？
サードパーティの分析は役立つが、一次記録になるべきではない。CSO の回顧記事、Krebs の報道、SecurityWeek の報道、Nordcloud の AWS キーディスカッション、実務者の Medium 記事は、一般および対応コミュニティが知っていたことの有用なスナップショットを提供する。それらはプロバイダーが維持するポストモーテムを完全に置き換えることはできない。アイデンティティ権限を保持するプロバイダーは、そのインシデントアーカイブを顧客信頼の一部として扱うべきである。
調達はまた、出口とフォールバックをテストすべきである。アイデンティティプロバイダーが低下するか、一時的に信頼できない場合、重要なアプリケーションにブレークガラスアカウントを通じてアクセスできるか？それらのアカウントは監視され保護されているか？顧客は緊急アクセスのために SSO を安全に無効にし、新しい脆弱性を開くことなく実行できるか？新しい証明書とトークンで制御されたシーケンスで信頼を再確立できるか？古い信頼資料がもはや受け入れられていないことを証明できるか？これらは抽象的な質問ではない。これらは顧客が2017年に直面した実用的なタスクである。
経済的インセンティブは明確である。アイデンティティプロバイダーはすべてが機能するときに運用摩擦を減らす。コストは、信頼資料をエンタープライズ全体で交換しなければならないときに現れる。したがって、顧客は購読コストとログインの利便性だけでなく、緊急ローテーションのコスト、証拠レビュー、アイデンティティプロバイダー自身が疑わしくなった場合のダウンタイムも価格設定すべきである。緊急ローテーションを容易にするプロバイダーは顧客リスクを減らす。顧客を手動の在庫に任せるプロバイダーはより多くの隠れたコストを顧客に転嫁する。
アカウンタブルな調達基準は「決してインシデントを起こさない」ではない。「インシデントが境界設定され、開示され、修復され、そこから学ばれることができることを証明する」である。OneLogin の2017年の侵害は、アイデンティティプロバイダーの信頼が顧客が単独で生成できない証拠にどの程度依存しているかを示した点で有益である。
証拠は確認された事実、支持された推論、未知のものを分離すべき
確認された公開事実は限られているが重要である。OneLogin は米国データリージョンでの不正アクセスを開示した。公開報道は OneLogin の後の更新を引用し、攻撃者が AWS キーを取得し、AWS API を使用し、偵察用のインスタンスを作成し、ユーザー、アプリケーション、キーの種類を含むデータベーステーブルにアクセスしたと述べた。同じ公開記録は、OneLogin が攻撃者がデータを復号する能力を得た可能性を排除できないとした。報告された顧客ガイダンスには、API キー、OAuth トークン、証明書、クレデンシャル、シークレット、エンドユーザーパスワードの広範なローテーションが含まれていた。
支持された推論も重要である。AWS IAM スコーピング、キーストレージ、データベースセグメンテーション、暗号化キー分離、SAML 証明書管理、OAuth トークン無効化、MFA 統合シークレット、Secure Notes ガバナンス、顧客在庫が中心的なアカウンタビリティオブジェクトであったと推論するのは合理的である。インシデントが米国データリージョンに影響を与えると説明され、OneLogin が地域居住オプションをマーケティングしているため、データリージョンスコーピングが重要であったと推論するのは合理的である。プロバイダー側の封じ込めだけでは不十分であり、顧客がダウンストリームの信頼資料をローテーションしなければならなかったと推論するのは合理的である。
未知のものは残っており、名前を挙げるべきである。公開記録は、正確な AWS IAM ポリシー、公開されたキーの場所とライフサイクル、アクセスされた完全なデータベーススキーマ、特定の暗号化キーアーキテクチャ、顧客データカテゴリの完全なリスト、完全な独立したフォレンジックレポート、すべての顧客修復指示、インシデント後のすべてのアーキテクチャ変更、すべての顧客ローテーションの完了状況を明らかにしていない。また、外部の観察者がインシデントの結果として実際にダウンストリームの SaaS アカウントが悪用されたかどうかを証明することもできない。
これらの未知のものはアカウンタビリティを不可能にするわけではない。それらは証拠の境界を定義する。深刻なリスクファイルは、ガバナンスの問題を特定するためにプライベートログを必要としない。問題は、中央集権的なアイデンティティプロバイダーがクラウドキーインシデントを被り、顧客がプロバイダー管理の信頼オブジェクトを潜在的に侵害されたものとして扱わなければならなかったことである。それだけで、このケースを高影響のアイデンティティ依存イベントにするのに十分である。
証拠の境界はまた、不公平な主張から保護する。OneLogin が意図的に事実を隠した、すべての顧客クレデンシャルが復号された、すべてのダウンストリームアプリケーションがアクセスされたと証拠なく主張するのは間違いである。また、不正アクセスがブロックされたためインシデントの影響が低いと主張するのも間違いである。顧客の修復負担は、最終的な証明された悪用が不明確であっても、リスクが広範であったことを示している。
将来のプロバイダーにとってのアカウンタブルな質問は、それらの未知のものを狭めることができるかどうかである。より良いログがタイムラインを狭める。より良いキー分離が復号リスクを狭める。より良いアプリ在庫が証明書ローテーションを狭める。より良い地域マップが地域性の露出を狭める。より良いインシデントアーカイブが公共の不確実性を狭める。OneLogin のケースは、アイデンティティ信頼とクラウドインフラがストレス下で出会ったときに何が起こるかを示している：プロバイダーが境界を証明する能力は、システムを復元する能力と同じくらい重要になる。
修復基準は検証可能な信頼リセットである
最終的なアカウンタビリティテストは、OneLogin が不正アクセスをブロックしたかどうかではない。公開記録によれば、ブロックした。テストは、アイデンティティ信頼連鎖が検証可能な方法でリセットされたかどうかである。プロバイダーにとって、それは侵害された AWS キーの無効化、影響を受けたインフラの破壊または再構築、派生アクセスパスのトレース、データベースアクセスの分析、暗号化キー露出の評価、製品コントロールの強化、顧客ガイダンスの保持を意味する。顧客にとって、それは SAML 証明書のローテーション、OAuth トークンの交換、API クレデンシャルの再生成、保存されたシークレットのレビュー、必要な場合のパスワード変更、MFA 統合シークレットの更新、ダウンストリームログの確認、クロージャまでの例外の追跡を意味する。
検証可能な信頼リセットは測定可能でなければならない。プロバイダーは、影響を受けたテナント数、送信された通知数、ガイダンス更新数、サポートケース数、製品変更数、ローテーションされた資料のカテゴリ数を示すことができるべきである。顧客は、レビューされたアプリケーション数、変更された証明書数、無効化されたトークン数、通知されたユーザー数、ローテーションされたシークレット数、検索されたログ数を示すことができるべきである。どちらの側も機密詳細を広く公開する必要はないが、監査人、取締役会、規制当局、内部セキュリティリーダーのための証拠ファイルが必要である。
このケースはまた、将来のリセットをより小さくするアーキテクチャを主張する。長期有効な静的キーは最小化されるべきである。クラウドロールと一時的クレデンシャルが可能な限り優先されるべきである。本番データベースはコンピュートを管理する同じクレデンシャルを信頼すべきではない。復号権限はデータベース読み取り権限から分離されるべきである。顧客シークレットは最小化され、発見可能で、ライフサイクル管理されるべきである。フェデレーション信頼は緊急証明書ロールオーバーをサポートすべきである。ログは顧客に迅速に利用可能であるべきである。データリージョンの約束は実際のコントロール境界にマッピングされるべきである。
これが、このインシデントが2017年以降も長く関連性を保つ理由である。現代のエンタープライズはアイデンティティプロバイダーにより依存しており、減少していない。より多くのアプリケーションが SSO を使用している。より多くの API がトークンを使用している。より多くの自動化が非人間アイデンティティを使用している。より多くの規制制度がデータの処理場所と誰がそれを管理するかを尋ねている。したがって、プロバイダーの侵害は複合的なアカウンタビリティ問題を生み出す：クラウドサービス依存、データローカリティ、セキュリティ自動化のすべてが衝突する。
OneLogin の2017年の侵害は、AWS キーのケースとしてだけでなく、アイデンティティプロバイダーの爆発半径のケースとして記憶されるべきである。盗まれたり露出されたりしたキーは公開記録に記述された経路であった。本当のテストは、プロバイダーと顧客が数千のダウンストリームログインを可能にする権限をリセットできるかどうかであった。アカウンタビリティは、そのリセットが文書化され、未知のものが名前を挙げられ、アーキテクチャが変更されて次のプロバイダー側のキー露出がより小さく、より明確で、より迅速に封じ込められた爆発半径を持つようになったときに始まる。