最近発生したSalesloft Driftに関連するセキュリティインシデントでは、人気のマーケティングオートメーションツールが侵害され、多くの組織に影響が及びました。この攻撃において、脅威アクターは、DriftツールをSalesforce、Google Workspace、その他多くのアプリケーションに接続するOAuthトークンを窃取し再利用することで、広範なデータ流出を引き起こしました。
このインシデントは、私たちの多くのテクノロジーパートナーにも影響を与えました。このような出来事は当然ながら、お客様やパートナーの皆様から次のような疑問を生むことになります：
- 「Oktaは影響を受けたのか？」
- 「Oktaは自社のデータをどのように守っているのか？」
私たちは明確にお伝えします：Oktaはこのインシデントによる影響を受けていません。
私たちのセキュリティチームは、自社のシステムを徹底的に調査し、盗まれたトークンを使用してOktaのリソースにアクセスしようとする試みの痕跡は確認されたものの、防御が設計通りに機能して侵害は防がれたことを確認しました。
実際の防御：1つのコントロールが果たした役割
私たちのチームがSalesloft Driftの侵害を把握した際、直ちにログを確認しました。調査の結果、侵害されたSalesloft Driftトークンを使用してOktaのSalesforceインスタンスにアクセスしようとする試みがあったことを突き止めました。これらの試みは失敗しました。その後、Google Mandiantのブログ投稿にあるインジケーター（IOC）と照合したところ、Oktaも明確に攻撃対象となっていたことが確認されました。
この侵害を防いだ最大の要因は、受信IP制限を強制適用していたという一点に尽きます。脅威アクターは侵害されたトークンを使ってSalesforceインスタンスへのアクセスを試みましたが、その接続元のIPアドレスが許可された範囲外だったため、アクセスは拒否されました。このセキュリティレイヤーが極めて重要であることが証明されました。正面玄関でアクセスを阻止することで、攻撃を未然に防ぐことができたのです。
私たちは、この基本的なコントロールをすべてのSaaSアプリケーションに適用することをセキュリティ戦略としています。しかし、その実装は多くの場合、SaaSベンダー側がこの機能を提供しているかどうかに完全に依存しています。残念ながら、クラウドファーストの世界ではこの基本的なセキュリティ機能すら提供していないプロバイダーが多く、システム間連携を守る上で大きな課題となっています。
Salesforceのようにこの機能をサポートしている重要なアプリケーションについては、APIとユーザーの両方に対して制限を構成するための多大な作業を実施しました。この取り組みは、Okta Secure Identity Commitmentの一環として実行されたものであり、すべてのOkta社員がプライベートIPの出口ノードを備えたクラウドベースのVPNを使用するようにするなど、信頼された社内ネットワークを構築するための基盤整備を含んでいます。これにより、この機能をサポートする最重要アプリケーションにおいて、ネットワークレベルでのセキュリティ制御を適用でき、今回のような攻撃からの防御が可能になります。
IP制限を超えて：DPoPによるトークンの保護
Okta Secure Identity Commitmentのもう一つの柱は、業界をリードするセキュアなアイデンティティ製品とサービスを構築することでした。この取り組みの結果として、Auth0とOktaの両方は、サービスを利用するアプリケーション開発者向けにDPoP（Demonstrating Proof of Possession）のサポートを構築しました。
IP許可リストがトークンの使用をIPに制限するのに対し、DPoPはトークンの使用を特定のクライアントに制限します。このセキュリティ機構は、アクセストークンをそれをリクエストしたクライアントと暗号的に結びつけます。簡単に言えば、これは「鍵（トークン）と鍵穴（クライアント）が一対になっているようなもの」です。仮に攻撃者がトークンを盗んだとしても、その鍵は攻撃者のシステムという「間違った鍵穴」では機能しないため、使用できません。このコントロールは、今回のサプライチェーン攻撃の核心であったトークンの再利用（リプレイ）を防ぎます。
IPSIEでレジリエントなSaaSエコシステムを築く
このインシデントは、1つのサービスの侵害が、今日の相互接続されたSaaSエコシステム全体に波及効果をもたらすことを明確に示しました。こうした攻撃に対抗するには、個別のアプリケーションを守るだけでは不十分で、すべてのアプリケーションが統合されたアイデンティティセキュリティの基盤の中にある必要があります。このような基盤は、オープンスタンダードに基づいて構築されることで、組織がアイデンティティベースの脅威をスピードと規模の両面で検知・対応できるようになります。
この考えから、Oktaは約1年前に、OpenID Foundationの他のメンバーとともに、Interoperability Profile for Secure Identity in the Enterprise（IPSIE）という新たな業界標準の策定に取り組むことを発表しました。IPSIEは、SaaSアプリケーション全体でのセキュリティと相互運用性のベースラインを確立することを目的としています。
今回のSalesloft Driftインシデントに特に関連するIPSIEの基本的な制御項目のうち、重要な2つは以下です：
共有シグナル（Shared Signals）: アプリケーション間でセキュリティイベントをリアルタイムで通信できる仕組みです。たとえば、あるアプリでユーザーアカウントが侵害された場合、その情報を他の接続済みアプリにも即座に共有でき、ユーザーデータを守るための対応が可能になります。
トークンの失効（Token Revocation）: アクセストークンを標準的な方法で無効化する仕組みです。Salesloft Driftのようなインシデントでは、トークンが侵害されたと判明した際に、それをすべての統合アプリで即座に失効させ、攻撃者のアクセスを遮断できます。
これらは、IPSIEがよりセキュアでレジリエントなSaaSエコシステムを構築するために貢献する方法のほんの一例にすぎません。
SaaS業界への行動呼びかけ
Salesloft Driftのインシデントは、SaaS業界全体に対する警鐘です。もはやサイロ化された状態で運用することは許されません。私たちは共に共通のセキュリティ基準を確立・採用していく必要があります。
SaaSセキュリティの未来はすでに到来しています。ただ、それがまだ均等に行き渡っていないだけなのです。
OktaはすべてのSaaS企業に、IPSIEの推進に参加するよう呼びかけます。共に行動することで、SaaS全体のエコシステムをより安全なものに変えることができます。
組織を守るために今できること
これはベンダーだけの課題ではありません。あらゆる組織が、このエコシステム全体のセキュリティ水準を引き上げるために重要な役割を担っています。以下は、今すぐ取るべきアクションです。
ベンダーに対してIPSIEの対応を求める：相互接続されたSaaSのセキュリティは共有責任です。お客様の声は、変化を起こす最も強力な原動力です。ベンダーに対して、IPSIEのようなオープンスタンダードの導入計画を尋ねてください。セキュリティと相互運用性が購買判断の鍵であると伝えれば、ベンダーはそれを優先するようになります。お客様の要望こそが、業界標準を現実のものに変える力です。
アイデンティティセキュリティ基盤を導入する：業界標準の向上を進める一方で、自社の環境を今すぐ保護することが不可欠です。もはやアイデンティティはアプリごとに個別管理する時代ではありません。アクセス制御・脅威検知・対応・ガバナンスをアプリやアイデンティティタイプを問わず一元化することで、一貫性のある防御レイヤーが実現し、組織全体を内側から能動的に保護できます。
IPSIEについて詳しくは、OpenID Foundationのウェブサイトをご覧ください。
以上の内容は、原文（英語）の機械翻訳であり、原文と内容に差異がある場合は、原文が優先されます。
