Okta FastPassとTrusted App Filtersでセキュリティを強化
このブログはこちらの英語ブログ（2025年4月4日公開）の機械翻訳です。
フィッシング耐性を最優先に
フィッシング耐性のある認証が、現在の安全な認証のベースラインです。つまり、FIDO/WebAuthn、Okta FastPass、PIV/CACなどがそれに該当します。本記事では、このベースラインをすでに満たしている方々が、さらにセキュリティレベルを引き上げる方法に焦点を当てます。
パスワード、SMS、プッシュ通知、ワンタイムコードなどは、この記事で説明するよりもはるかに単純な攻撃に対しても脆弱です。そのため、私たちはそれらの使用を推奨しません。
フィッシング耐性がカバーしきれない領域
前述の通り、Okta FastPassやPasskeys、その他の FIDO認証器は、フィッシング攻撃から組織を守る非常に優れた手段です。これらは、攻撃者がユーザーのデバイス上で何らかの形で存在感を持つ（あるいはキーを物理的に盗む）必要があるためです。
フィッシング耐性のある認証器は、NISTによって定義された2つの要件、Verifier Name BindingとChannel Binding（この仕様はドラフトで、コメント受付は終了）に基づいており、これにより大半のフィッシング攻撃が防止されます。FIDOとOkta FastPassはどちらも Verifier Name Bindingを使用しています。
これらに加え、フィッシング耐性のある認証機は、ブラウザと認証器の間に保護されたチャネルを確立する必要があります。これにより盗聴やリモートデバイスへのリレー攻撃を防ぐことができます。しかし、これらの要件は、ユーザーのデバイス上に存在する悪意あるコードについては考慮していません。そのため、より高度な攻撃が成立してしまう余地があります。そしてそれが成功すれば、攻撃者はフィッシング耐性の要件を満たすことができます。
攻撃例：SOCKSを用いたクロスデバイス認証
ユーザーが悪意あるリンクをクリックし、マルウェアがシステムにインストールされたと想像してください。この攻撃の前提として、攻撃者はすでにユーザーのマシン上でユーザーとしてコードを実行できる状態にある必要があります。
SOCKS経由のクロスデバイス認証の流れ
|
1 |
攻撃者は、感染したデバイスと自分のデバイスの間に SOCKSリバースプロキシを作成します（図のステップ1）。適切に設定すれば、攻撃者はOkta FastPassやFIDO2のチャレンジを自分のデバイスから感染デバイスにリレーできるようになります。 |
|
2-3 |
攻撃者は自分のデバイスからユーザーのリソースにアクセスを試み、認証チャレンジをプロキシ経由でユーザーのデバイスにリレーします |
|
4 |
攻撃者のデバイス上のブラウザが、Oktaサーバーから直接ポーリングし、認証チャレンジが満たされるのを待機します。 |
|
5 |
攻撃者は、感染デバイスにTPMを使ってチャレンジレスポンスに署名させる必要があります。 ポリシーが適切に設定されていれば、ユーザーの存在確認が求められ、ユーザーには生体認証やパスコードのプロンプトが表示されるため、不審に思われるかもしれません。しかしマルウェアが存在する前提なら、攻撃者がパスコードを入力したり、ユーザーが席を外しているときやプロンプトが表示されるタイミングを狙って違和感なく実行することも可能です |
|
6-8 |
最終的に、感染デバイスから Oktaサーバーにレスポンスが送られ、TPMキーのチェック、フィッシング耐性、デバイストラストの保証をすべてクリアします。 その結果、攻撃者のデバイスには有効なセッションが確立され、攻撃者はブラウザと感染デバイス上の認証器間の認証を透過的にプロキシした形になります。 |
Trusted App Filtersの登場
2024年8月、OktaはOkta FastPass向けにこの種の攻撃を軽減する機能であるTrusted App Filtersをリリースしました。この高度なセキュリティ設定により、管理者が許可リストに含まれていないアプリ、署名がないアプリ、または信頼できないコード署名証明書で署名されたアプリからの認証試行を自動的にブロックできます。
仕組み
たとえば ChromeなどのアプリがOkta FastPassを使って認証を試みるとき、Oktaのサインインウィジェットはデバイス上で実行されている Okta Verifyに接続し、Oktaのバックエンドから認証チャレンジを送信します。
この接続がアクティブな間、Okta Verifyはデバイス上でその接続を作成したポートとプロセスをトレースします。ポートやプロセスが特定できない場合、それはリモート起点である可能性を示しており、接続は破棄されます。
プロセスが特定できれば、Okta Verifyは実行ファイルの署名情報を詳細に収集し、署名がコード署名証明書と一致し、またその証明書がローカルトラストチェーンによって信頼されているかを検証します。
macOS ではSecCodeCopySigningInformation、Windows ではWinVerifyTrustを使用してプロセス情報を取得します。この情報は、管理証明やデバイスシグナルと一緒にチャレンジレスポンスに含まれ、ハードウェアにバインドされたキーで署名されます。
モニタリング
macOSまたはWindowsでOkta FastPassを使用している場合、この情報はSysLogに出力されます。
こちらは macOSのChromeを使用してOktaダッシュボードにログインした例です：
ログを確認すれば、ユーザーがどのアプリで認証しているかを把握でき、新しいアプリの使用を警告するワークフローを構築できます。組織内でどのバイナリがどのアプリに紐づくかを把握しておくとよいでしょう。たとえば、Slackの認証はブラウザまたはSlackネイティブアプリからのみ許可するのが適切です。
適用（Enforcement）
特定の認証ポリシーに適用するアプリのリストを完全に整備できたら、Trusted App Filtersを使って攻撃を未然に防ぎましょう。設定はやや複雑なので、OSごとにポリシールールを分けて（例：macOSまたはWindows用のデバイス保証ルールを作成）、それぞれに適用するのが簡単です。
Expression Languageが構成されたら、署名チェックを通過できないアプリ（例：未署名のマルウェア）はブロックされ、SysLogに記録されます。署名されていてもリストに含まれないアプリ（例：SSH デーモン）も同様にブロックされます。
例1：macOS上のChrome、Firefox、Safari
この例では、macOS上でサポートされている主要ブラウザすべてを許可します。SSOエクステンションまたは Loopbackバインディングを使用します。つまり、フィッシング耐性のある2つのバインディングのみがOkta FastPassのルールをトリガーします。O365など独自のWebViewを持つネイティブアプリはこのルールを満たさないので、許可したい場合は識別子を追加しましょう。
例2：Windows上のEdgeとChrome
WindowsはLOOPBACKのみが有効なバインディングなのでややシンプルです。CUSTOM_URLバインディングによるフィッシング耐性のないフローも防止されます。
Trusted App FiltersをFIDOその他の認証器と組み合わせる
Okta FastPassではなく、たとえばFIDOセキュリティキーなど別の認証器を使用したい場合でも、Trusted App Filtersを適用することができます（対象デバイスにOkta Verifyが登録されている必要があります）。
その場合、以下をすべて含むルールを作成します：
- 登録済みまたは管理された条件
- Trusted App FiltersのExpression Language
- 使用を許可したい認証器の許可リスト、または「すべてのメソッドを許可」
Okta FastPassをmacOSまたはWindowsで使っているなら、どのネイティブアプリがOkta FastPass認証をトリガーしているかを今日からモニタリングできます。信頼されたアプリの使用状況を把握したら、それらを許可リストに追加し、それ以外のアプリからのOkta FastPass使用をブロックしましょう。
さらに詳しく知りたい方は、Zach Newton によるデモも含む Oktane 2024 のセッションをご覧ください（無料登録が必要です）。
以上の内容は、原文（英語）の機械翻訳であり、原文と内容に差異がある場合は、原文が優先されます。