2023年末以降、Oktaは自社の業務を支えるすべての重要なSaaSプロバイダーに対し、いくつかのセキュリティ管理項目の実施を義務づけました。
これらの管理項目は、2025年8月に発生したSalesloft Driftの侵害からOktaとそのお客様を守るうえで極めて重要な役割を果たし、さらにその後発生したカスタマーサクセスマネジメントソフトウェアプロバイダーであるGainsightの侵害においても、Oktaとお客様を保護しました。
本記事を通じて、Oktaとお客様の間のやり取りが安全であることをお伝えすると同時に、将来のソフトウェアサプライチェーン攻撃の影響範囲を最小限に抑えるために、すべての最高情報セキュリティ責任者（CISO）が取り組むべき課題について指針を示したいと考えています。
2025年8月：Salesloft Drift攻撃
2025年8月、AI搭載のチャットボットプロバイダーであるSalesloft Driftからアクセストークンを窃取・再利用した脅威アクターによって、700以上の組織の重要な業務アプリケーションが侵害されました。
この攻撃は、高度に相互接続されたシステム環境において、特定のサプライヤーが侵害されると、最も防御力の高い組織であってもデータ漏えいにつながりうることを証明しました。
OktaもDriftアプリケーションを利用していましたが、影響を受けた組織には含まれていませんでした。脅威アクターは、DriftアプリケーションがOktaのCRM環境へアクセスするために使用していたトークンを取得し、再利用を試みましたが、後述する管理項目により、その試みは失敗に終わりました。
2025年10月：Gainsight攻撃
2025年10月下旬、脅威アクターはもう一つの人気アプリケーションであるGainsightを侵害し、200以上の組織に有効なトークンを盗み出し再利用しました。
Salesloft Driftのケースと同様に、OktaもGainsightの顧客ですが、今回も影響は受けておりません。GainsightはOAuthトークンを使用して、OktaのSalesforceインスタンスと接続しています。
Oktaの重要SaaS管理項目
Oktaのセキュリティアーキテクチャチームは、脅威に基づき、すべてのSaaSプロバイダーが満たすべき標準と設定要件を定義しています。これらの要件は、対象となるシステムやデータの機密性に応じて異なりますが、すべての環境に共通する基本要件も存在します。
多くのテクノロジープロバイダーはこれらの基本的な対策を採用していますが、残念ながら未対応の企業も存在します。Oktaは、現代のSaaS時代において不可欠と考えるセキュリティ機能を提供するよう、継続的に働きかけています。
これらの要件の一部はアイデンティティとアクセス管理に関連しており、今回の2つのサプライチェーン攻撃に特に関係しています。
強固な認証（SSO）：Oktaは、アプリがシングルサインオン（SSO）による集中型のアイデンティティフェデレーションと認証をサポートすることを求めています。
強固なアイデンティティガバナンス（SCIM）：Oktaは、アプリが自動化されたアクセスのプロビジョニング、解除、権限管理をサポートすることを求めています。
対話型セッションのセキュリティ：Oktaは、アプリがユーザーアクセスに対してIPによる許可リスト（アローリスト）をサポートすることを求めています。
非対話型セッションのセキュリティ：Oktaは、APIアクセスを含むマシン間通信において、IPおよびクライアントごとの許可リストをサポートすることを求めています。
強力な監査性：Oktaは、リアルタイム検知やモニタリングのための指定されたログおよびアラートのサポートを求めています。
強固な認証
これらのソフトウェアサプライチェーン攻撃を行った脅威アクターたちは、標的への初期侵入にさまざまな手法を用いますが、その中でも一般的な手口のひとつが、インフォスティーラーによって盗まれたアカウントのパスワードを再利用する攻撃です。
2024年には、攻撃者がインフォスティーラーによって得たパスワードをSnowflakeの顧客テナントに対して再利用する事例が多数発生しました。多くのケースでは、多要素認証（MFA）が要求されなかったため、これらのアカウントへのアクセスが容易になっていました。その理由は、対象アカウントがアイデンティティプロバイダー（IdP）とフェデレーションされていなかったか、シングルサインオン（SSO）を介さず直接アクセスできるエンドポイントが存在していたためです。
このことから、SaaSプロバイダーがアイデンティティフェデレーション標準であるSSOをサポートすること、そして顧客側のセキュリティチームが非フェデレーションアカウントを発見し、対処できるツールを持つことが極めて重要であることがわかります。
SSOは、IPSIE（Interoperability Profiling for Secure Identity in the Enterprise）に含まれる主要な管理項目のひとつです。IPSIEは、エンタープライズ向けアプリが備えるべき中核的なセキュリティ機能の設計図とも言えるものです。
強固なアイデンティティガバナンス
攻撃に悪用された非フェデレーションアカウントの多くは、インフォスティーラーやクレデンシャルスタッフィングによって不正利用されたもので、退職済みユーザーや過去のサービスアカウントなど、管理が不十分なものが多く含まれていました。
これらのアカウントは明確な所有者がいなかったり、強固なパスワードポリシーやMFAなどの認証要件が適用されていなかったりすることがよくあります。
そのため、アカウントの自動プロビジョニングおよびデプロビジョニングを実施することが、セキュリティ上極めて重要です。SCIMに基づくプロビジョニングを導入することで、SaaSアプリケーションにアクセスするすべてのアカウントを常に最新の状態に保ち、保護することができます。
SCIMプロビジョニングも、IPSIEに含まれる主要な管理項目のひとつです。
対話型セッションのセキュリティ
Oktaの脅威インテリジェンスチームが調査したアカウント乗っ取り事例の大多数では、攻撃者が正規ユーザーとは異なるネットワークやサービスから盗んだ認証情報を再利用していました。
したがって、重要な業務アプリケーションへのユーザーアクセスは、信頼できるネットワークに制限すべきです。
ユーザーアクセスは、アイデンティティプロバイダー側で制限できます（たとえばOktaのNetwork ZonesやAuth0のTenant Access Control Listsを使用）。しかしそれだけでは、SaaSアプリケーションに対する直接的な非フェデレーションアクセスを完全に制限することはできません。攻撃者は正規のルートではなく、最も脆弱な経路から侵入します。
したがって、SaaSアプリケーションもまた、直接サインインイベントに対するIP許可リストをサポートする必要があります。管理者は、アプリケーションへの直接アクセスを自社ネットワーク内に限定できるようにすべきです。
たとえばOktaでは、Salesforceなどの重要アプリケーションへの対話型アクセスを、Okta従業員が利用する企業VPNに紐づく特定のプライベートIPノードに限定しています。
非対話型セッションのセキュリティ
同じ「多層防御（defence-in-depth）」の考え方は、マシン間通信にも適用されます。
現在の脅威環境では、アクセスキーやトークンなど、あらゆる秘密情報が攻撃者に発見される可能性があると想定する必要があります。したがって、「秘密情報は漏洩するもの」と仮定してシステムやプロセスを設計しなければなりません。言い換えれば、マシンアクセスにもゼロトラストの考え方を適用する必要があります。
キーやトークンは、特定の既知のコンテキスト内でのみ使用できるようにするべきです。
これはそれほど難しいことではありません。ユーザーと異なり、リソースサーバーやAPIにアクセスするクライアントは、通常、固定されたIPレンジから接続します。
このアクセスに対して信頼できる場所を許可リストに登録するためには、以下の対応が必要です。
アクセスを要求するクライアントアプリケーションが、利用するネットワーク範囲を宣言すること（Salesloft DriftやGainsightはいずれも、攻撃前にこれらのIP範囲を公開していました）
サーバー側のアプリケーションは、APIアクセスをIPアドレスで制限できる機能を備えること（Salesforceでは、資料にあるように、接続アプリケーション向けにこの機能が提供されています）
さらに、有効なトークンの使用を、発行対象となったクライアントに限定することも可能です。これにより、Salesloft DriftやGainsightのように攻撃者が有効なトークンを入手した場合でも、そのトークンを攻撃者の環境で再利用することはできません。
このように、特定のクライアントにトークンの使用を制限するための仕組みは複数存在します。たとえば、相互TLS（mTLS）は公開鍵基盤（PKI）を用いてクライアントとサーバーを相互認証します。
また、OAuthの拡張仕様であるDemonstrating Proof of Possession（DPoP）は、暗号的にトークンを要求元クライアントに結び付ける仕組みです。
このような対策は、攻撃のコストを引き上げます。攻撃者が一度に数百もの組織のトークンに不正アクセスできる「標的が多い環境（target-rich environment）」においても、こうしたコントロールは防御側に対応時間を与え、検知の機会を増やすことができます。
強固な監査性
エンタープライズ市場を対象とするすべてのSaaSアプリケーションは、ログ記録および監視要件をサポートする必要があります。
マシン間通信の観点に戻ると、統合されるシステムのネットワークや位置情報のコンテキストが比較的安定している場合、異常なアクセスを検知しやすくなります。言い換えれば、強力な監査性は前述の4つの対策の成果であり、それらがなければ達成は難しいのです。
また、ソフトウェアサプライチェーン攻撃への有効な対応には、侵害されたソフトウェアパートナーの顧客が迅速に自社への影響の有無とその範囲を把握できることも求められます。
最低限、SaaSプロバイダーは次の点を提供すべきです。
セキュリティおよびアクティビティログへのプログラム的アクセス
すべてのログイベントに関する包括的なコンテキスト情報
OpenID IPSIEプロファイルで定義されたShared Signals Frameworkのサポート
まとめ
このエコシステムに関わるすべての参加者（アプリケーションプロバイダーとその顧客）の双方に対し、これらの管理項目を最低限のセキュリティ衛生要件として採用することを強く推奨します。
Oktaの使命は、こうしたシンプルかつ効果的な管理項目を、お客様が容易に導入できるようにすることです。Auth0とOktaはいずれも、SSO、自動プロビジョニングおよびデプロビジョニング、ローカル（非SSO）アカウントの検出、そしてIPやクライアント単位でのトークン使用制限といった機能を幅広くサポートしています。
私たちは、この重要な取り組みを共に進めるパートナーとして、皆さまを支援してまいります。
