未来のSaaSアプリを守るには

ここ数年、高度に標的化された組織の脅威形態が根本的に変化していることを確認しています。

今日、攻撃者は、高度に標的化された組織のユーザー認証情報を窃取することができない場合、ユーザーの「認証の証明」（Proof of Authentication）を窃取することに軸足を移しています。

攻撃者はマルウェアを使って、ユーザーがサインインした後のブラウザからセッショントークンを窃取します。同様に、透過型プロキシを使用して、サインイン後にユーザーのブラウザからセッショントークンを窃取する可能性もあります。また、Okta の最近の経験が示すように、あらゆる種類のベアラートークンが保護されずに保存されている場合、攻撃者はそれを嗅ぎつけます。窃取されたセッショントークンは、多くの場合、ユーザーセッションの残りの期間、攻撃者が選んだブラウザで再生することができます。

Oktaは、数年前から、セッショントークンの盗難や再生を軽減することを目的としたインターネット標準に貢献してきました。Oktaがこのような取り組みを行っているのは、これらの問題に対する現在の解決策（エンドポイント保護とフィッシング耐性認証）が常に効果的に適用されるとは想定できないからです。エンドポイント保護ソリューションによって検出されないマルウェアが存在すること、あるいは、フィッシングに耐性のある認証機能によって保護されないままアプリケーションにサインインするユーザーが存在することを想定しておくことが賢明です。このような事態が発生した場合、防御側には、窃取されたセッショントークンからの攻撃範囲を制限する機能が必要です。

こうした状況を踏まえて次の3つの目標を考慮する必要があります。

1. 特定のデバイス、クライアント、および/または場所用のトークンの使用を制限する
2. アイデンティティのエコシステム（アイデンティティプロバイダーと SaaS アプリ）が、セッションリスクの変化について自律的にシグナルを交換する
3. 識別されたセッションリスクの変化に対して行動する（例えば、アプリのコンテキスト内でステップアップ認証を強制したり、ユーザーをすべてのアプリからサインアウトさせたりする）

Oktaは、昨年10月に発生したセキュリティインシデントを受け、OIDC（OpenID Connect）をサポートする最新のアプリがこれらの目標の多くを満たすことができることを実証しました。Oktaは現在、管理者セッションを場所（デフォルトではASN、オプションでIP）にバインドし、管理者ユーザーがセッションの途中で場所を変更したり、セキュリティ上重要なタスクを実行しようとした場合に、再認証を強制しています。

Oktaの次の課題は、Okta Admin Consoleで使用しているのと同じハードニングの技術を、Oktaの背後にある無数のサードパーティのSaaSアプリに適用することです。

Oktaは、ポスト認証攻撃の時代にユーザーを保護するために、すべてのエンタープライズSaaSアプリが取り入れる必要のある、いくつかの革新的な新機能の基礎を築きました。

今日のSaaSアプリのエンタープライズ対応要件

今日、最高セキュリティ責任者（CSO）が、SaaSアプリがエンタープライズ対応であるとみなす前に、それらのアプリが満たさなければならない要件がいくつかあります。例えば、以下の要件です。

• シングルサインオン（OIDCまたはSAMLのサポートによる）
• ユーザーのプロビジョニングとデプロビジョニング（SCIMのサポートによる）
• プログラムによるログへのアクセス（REST APIを使用）

しかし、ほとんどのCSOは、SaaSアプリに要求する要件を少なくとも5～10年間更新していません。その間に、保護するアプリの性質も、認証後の攻撃から SaaSアプリにもたらされる脅威も、根本的に変化しています。

未来のSaaSアプリに必要なエンタープライズ対応要件

今日のSaaSアプリは、一般的に単純なWebアプリ以上のものとなっています。例えば、Slackを考えてみましょう。Slackは、Webアプリとネイティブアプリの両方のエクスペリエンスを包含し、OAuthを使用して他のアプリ（Google Workspace、Atlassian Confluence、Jiraなど）と統合された、分散型のアプリとサービスのセットです。このような分散アプリを保護するには、より長い要件リストが新たに必要になります。SaaSアプリは、CSOの審査に合格するために、少なくとも以下の3つの機能をサポートする必要があります。

1. Proof-of-Possession（所有の証明）

Proof-of-Possessionは、OAuthアクセストークンの使用を許可されたクライアント（ブラウザベースのアプリ）に限定する方法です。

攻撃者が盗んだトークンを他のクライアントから再生することを防ぎます。

Oktaは、OAuth 2.0拡張機能であるDemonstrating Proof-of-Possession（DPoP）をサポートすることで、この要件に対応しました。この拡張機能は、SaaSアプリの開発者がトークンを認可されたクライアントに暗号的にバインドするために使用できます。あるクライアントに発行されたアクセストークンが攻撃者によって傍受され、他のクライアントで再生された場合、SaaSアプリはアクセスを拒否することができます。

この問題をDPoPを使ってアプリレベルで解決すべき論理的な理由はいくつかあります。この問題を解決しようとするこれまでの取り組み（mTLSベースのトークンバインディングを使用）では、スケール、デプロイメント、ユーザビリティの課題がありました。Trusted Platform Modules（TPM）は歴史的にHTTPリクエストごとに証明に署名するのに十分な速度を持っておらず、プロキシや他の仲介者がTLSを終了させる企業環境ではエンドツーエンドの証明にも問題があります。

これに対してDPoPは、最新のネイティブアプリの可能な限り広い範囲で、トークンが盗まれるリスクを低減します。Oktaは、Oktaの管理APIにアクセスするすべてのAPIサービス統合でDPoPをデフォルトで有効にしています。一旦設定されると、Okta APIエンドポイントは、トークンの所有者が認可されたクライアントにこの暗号的関係を証明することを要求します。

CSOは、SaaSアプリにも同じことを要求する必要があります。ベンダーのセキュリティ質問表で次の要件を検討してください。

「SaaSアプリは、アクセストークンを提示するクライアントが認可されたことを暗号的に証明すること（Proof-of-Possessionの実証）を要求しなければならない。」

2. 継続的アクセス評価プロファイル（CAEP）

Oktaは最近、「セキュアバイデフォルト」の原則に業界をシフトさせるため、Oktaの管理セッションのデフォルトの最大継続時間とアイドル時間を短縮しました。

直感に反して、ほとんどのSaaSアプリのデフォルトセッションは長くなっています。

セキュリティの観点から、セキュリティチームが、セッションの途中でユーザーリスクの変化をほぼリアルタイムで検出し、正当なユーザーに過度な摩擦を生じさせない方法で、そのシグナルに対する即時の対応を編成できると確信できる場合にのみ、企業はアプリセッションの時間を延ばすことができます。

CAEP（Continuous Access Evaluation Profile：継続的アクセス評価プロファイル）は、新たな未来への道筋を提供します。CAEP は、1 つの SaaS アプリで識別されたセッションリスクの変化が、アイデンティティプロバイダーを介してユーザーがアクセスする他のすべての SaaS アプリで自律的にレスポンスを生成することを保証する標準化された方法を提供します。

今日、Okta のようなアイデンティティプロバイダーは、ユーザーとセッションリスクの変化に関連する数多くのリスクシグナルを観察することができます。しかし、これらのシグナルは、Oktaセッション中にアクセスされる下流の SaaSアプリが常に観察できるとは限りません。SaaSアプリもユーザーとセッションのリスクの変化を観察することができますが、その多くはアイデンティティプロバイダーが常に観察できるわけではありません。

OpenID Foundationによって標準化されたShared Signals Frameworkを使用するCAEPは、ユーザー、デバイス、セッションのリスクの変化を記述するためのパブリッシュ/サブスクライブメカニズムです。Oktaは、アプリ間のリスクシグナルの送信、受信、集約に必要なコンポーネントを構築し、シグナルを交換するSaaSアプリとセキュリティプロバイダーのエコシステムを構築しています。

リスクシグナルはすでに公開され、Okta Identity Threat Protectionを利用するお客様に限定的な早期アクセスで提供しています。今こそ CSO は、SaaSアプリが同じリスク共有標準をサポートすることを要求する時です。ベンダーのセキュリティ質問票で次の要件を検討してください。

「SaaSアプリは、オープンで業界標準のフレームワークを使用してリスクシグナルを送信およびサブスクライブできなければならない。」

3. Universal Logout

CAEPを使用してすべての信号が交換されるため、セキュリティチームは、セッションリスクの高まりに対する応答を自動化する機能も必要とします。

可能な対応策の1つは、セッションリスクの変化に対応するときに、SaaSアプリが再認証をトリガーすることです。

観察されたリスクが適切な高いしきい値に達した場合、ユーザーの IdPセッションと、SaaS アプリとの各ユーザーの個別セッションを失効させる必要があります。

これまで、これを行う簡単な方法はありませんでした。Single Logout（SLO）は部分的なソリューションを提供しました。ユーザーは、SLO をサポートする SaaS アプリからログアウトすると、自動的にIdPセッションからサインアウトされます。欠けていたのは、ネイティブアプリやSaaS統合を含め、ユーザーがIdPセッション中に許可したすべての接続SaaSアプリを取り消す方法でした。

Universal Logoutは、Oktaが「シングルサインアウト」問題を処理するために提案した標準化された方法です。Universal Logoutにより、セキュリティ運用担当者は、リスクのあるセッション中にアクセスした各SaaSアプリからユーザーを手動で特定してサインアウトする手間を省くことができます。

CSO は、このプロセスを容易にするために、SaaS アプリがUniversal Logoutエンドポイントを公開することを要求する必要があります。ベンダーのセキュリティ質問表で、次の要件を検討してください。

「SaaS アプリは、OAuthトークンを含め、アプリへのアクセスを取り消すための標準インターフェースを公開しなければならない。」

これらの要件でどのようなことが可能になるのか？

より多くのアプリがこれらの要件を満たしている場合、以下のことが可能になります。

• ユーザーは、適切なデバイスからフィッシング耐性のある認証機能を使ってのみ、企業リソースに認証することができる
• アプリは、適切な権限を持つ適切なユーザーからの要求のみを受け付ける
• ウェブアプリやネイティブアプリのセッション/トークンは、アクセスが許可された同じデバイスからのみ使用できる
• 長期間のセッションは、企業とアプリからのシグナルを使用して、継続的にリスクの再評価が行われる
• すべてのデバイスからのアクセスをリアルタイムで停止し、盗まれたセッションの影響範囲を制限することができる

Oktaは、ベンダーニュートラルなアプリとの幅広い連携を築いているアイデンティティプロバイダーとして、組織とアプリサービス開発会社がこれらの要件を満たすのを支援する立場にあります。

Oktaは、次世代SaaSアプリがOkta Customer Identity Cloudのボックスにチェックを入れるだけで、これらの機能を有効にでき、Okta Integration Networkを通じて、次世代のB2B SaaSアプリがOkta Workforce Identity Cloudのユーザーにリーチできる市場を提供できるというユニークな立場にあります。また、SaaSアプリがこれらの機能を後付けできるように、アプリ統合ウィザードを有効にしています。

セキュリティチームは、このような根本的なセキュリティ課題を解決するために、SaaSエコシステムにさらなる要求をする必要があります。

未来のSaaSアプリ - 要件記述

SaaSアプリの要件について、より広範なリストを以下に示します。

​

Oktaは、セキュリティチームがまだ実行可能でないことを考慮して、このリストから意図的に除外した他のアイデンティティ標準のインキュベーションも支援しています。W3Cで進められているDevice Bound Session Credentialsは、ブラウザベースのセッションクッキーに所有証明のプロパティをもたらすもので、モダンアプリを保護するためのパズルの最後のピースとなるものです。