2024年8月に一般リリースされたIdentity Threat Protection with Okta AIを触ってみました！
このブログは？
- Identity Threat Protectionについてざっと解説
- 超目玉機能、Universal LogoutとSSFの検証したよ
- どう設定するの？どこ見ればいいの？がわかるようになる（？）
OktaのIdentity Threat Protectionとは？
Identity Threat Protectionの概要
以前から認証時に端末情報・IPアドレス・ロケーションなどでスコアリングはしていましたが、認証後もポリシー・ネットワークゾーン・挙動などIDaaSへのアクセスを評価しつづけ、端末の状態が安全ではないと判定した際には、IDaaSからログアウトさせたり、追加認証を強制したりできるようになります。また、SASE、EDRなどセキュリティ製品からOktaへシグナルを受信・検知できるようになります。
既存のプランに、Identity Threat Protection オプションを追加すると利用できるようになります。※2024/10/11 追記
Identity Threat Protectionで追加される機能の紹介
継続的モニタリングと自動修復
ユーザーがOktaに認証した後もユーザーセッションを継続的にモニタリングし、ノイズの検知、リアルタイムでリスク再評価をし、セッションの終了やユーザーへのMFAの要求などのアクションを実行します。
ユーザーリスクインサイト
ブルートフォース攻撃、セッションハイジャックによる残留セッションリスクなど、エンティティリスクの変化に対してポリシーを設定し、ログアウトしたりOkta workflowsの実行をします。
また、DashbordやReportsから全体的なセキュリティランドスケープを確認できるようになります。
Universal Logout
リスクの変化が識別されたときにサポート対象アプリのユーザーセッションを終了します。Okta Admin Console、End-User Dashboard、End-User SettingsやGoogle Workspace、Google Cloud Platform、Microsoft製品、Salesforce、Box、Slack Enterprise、Zendesk、Zoomなどのアプリケーションに対応しています。認証後セッションとエンティティリスクポリシーの評価への応答として追加できます。
Shared Signals Framework（SSF）
サードパーティのセキュリティプロバイダーからリスクシグナルを受信します。
Jamf Security Cloud（Jamf Radar）、Netskope Cloud Exchange、Zscaler Deception、Cloudflare One Enterprise、CrowdStrike Falconなどと連携できます。
Identity Threat Protectionの設定や前提条件
まずはOkta FastPassの有効化と、Okta Verifyのサポート対象バージョンにします。
- Android：Okta Verify 7.26以降
- iOS：Okta Verify 9.9以降
- macOS：Okta Verify 9.8以降
- Windows：Okta Verify 4.9.1以降
SASEなどの影響でOktaへのリクエストがプロキシされるときは、クライアントIPの変化を許容できるようにします。
- 発信元のクライアントIPを特定する
- Oktaに送信されるリクエストのX-Forwarded-For HTTPヘッダーに発信元のクライアントIPが含まれるようにプロキシサービスを構成する
- OktaのNetworksでLegacyIpZoneを編集、Trusted proxy IPsセクションにこれらのプロキシのIPアドレスが含まれるようにする
Universal LogoutでOktaと対象アプリケーションのログアウト検証
まずはRiskを検知したらOktaとアプリケーションのログアウトをする流れを作ってみます！
Universal Logoutの設定をする
- まずはリスクを識別するためにEntity Risk Policyを作成します！Securityタブからアクセスし、Add ruleボタンを押下します。
- 今回は検証なので、引っかけやすいルールを作成します。Admin Reported User RiskとLogout and revoke tokensを選択しSaveボタンを押下します。（ここでRun a Workflowを選択すると、Delegated Flowのトリガーにできます。）
- 今回はMicrosoft Office 365 アプリケーションのUniversal Logoutの設定をします。ApplicationsのAuthenticationタブの下方で設定できます。
Entity Risk Policyに引っかけてみる
- 検証端末でブラウザからOktaにログインします。Universal Logoutを設定したアプリケーションにログインします。
- 管理画面の該当ユーザーのリスクを変更します。LowからHighに変更しました。
- OktaからログアウトはされましたがMicrosoft Office 365からはまだ追い出せてません。設定が足りないのかもしれません。
- OktaのSystemLogを見てみます。Entity Risk Policyに引っかかりTerminateされていますね。
- Universal Logoutのドキュメントをよく読んだら、Microsoft系は、
These apps share an identity stack and only provide a partial Universal Logout. Universal Logout only revokes their refresh tokens. User sessions aren't terminated until the user's existing access tokens expire or the user signs out. The token expiration timeout is different for each app. See Revoke user access in Microsoft Entra ID.とのことでした。Oh no！！！
Azure AD が発行するトークンの有効期間と考え方 (2023 年版)の「トークンの更新タイミングの考え方」に詳しく仕様が書かれれているので、気になる方は読んでみてください。
1時間以内にアクセストークンが期限切れになるようなのでちょっと待ってみます。 - ☕️
- Microsoft Office 365でリロードを繰り返したらOktaのログイン画面に戻されました。トークンが更新されなかったので追い出されたようですね！
- 尚、People画面のClear User SessionsでOptionalにチェックを入れてセッション削除もしくはEntity Risk Policyなどでログアウトすると、User Entity Risk LevelがLowに戻ります。
iOS端末でSSFを用いたUniversal Logoutの検証
次に、Shared Signals Framework（SSF）でシグナル検知でUniversal Logoutを検証します！
今回はJamf Security Cloudを使います！Jamf Security Cloudは、デバイスに対するリアルタイムのセキュリティ管理と脅威検出をするエンドポイントセキュリティプラットフォームです。
共有信号レシーバーの構成（Jamf Security Cloud）
まずはJamf Security Cloudの共有信号レシーバーを構成します。
- Jamf Security CloudのIntegrationsから、SSF streamsを選択し、Create new SSF streamボタンを押下します。
- Audienceに、
https://xxx.okta.comと入力し、Createボタンを押下します。次のポップアップに出てくるTokenはスルーしConfirmボタンを押下します。
- Well known URLを控えておきます。
- ActionsからConfigreを選択します。
- Endpoint URLに
https://xxx.okta.com/security/api/v1/security-eventsと入力し、Saveボタンを押下します。StatusがEnabledになっているか確認します。
共有信号レシーバーの構成（Okta）
つづいてOkta側の共有信号レシーバーを構成します。
- Okta Admin ConsoleでSecurityを選択し、Device Integrationsに移動します。Receive shared signalsタブをクリックし、Create streamボタンを押下します。
- Integration nameを入力します。Well-known URLを選択し、先ほど控えたJamf Security CloudのWell known URLを貼り付けてCreateボタンを押下します。
- ストリームが正しく作成されると、ストリームリストにActiveで表示されます。
OktaとJamf Security CloudをConnectionする（Okta）
- Okta Admin ConsoleでApplicationsを選択し、Applicationsに移動します。Create App Integrationボタンを押下します。
- OIDC – OpenID ConnectとNative Applicationを選択しNextボタンを押下します。
- Refresh Tokenを選択します。
- Sign-in redirect URIsに
com.jamf.trust-auth://login、Sign-out redirect URIsにcom.jamf.trust-auth://logoutを追加し、Skip group assignment for nowを選択しSaveボタンを押下します。
- 作成したアプリケーションに戻ります。GeneralタブのGeneral SettingsをEditし、User consentのRequire consentのチェックを外しSaveボタンを押下します。
- AuthenticationタブのOpenID Connect ID TokenをEditし、Groups claim filterを
Matches regexに変更、.*を入力しSaveボタンを押下します。
- Assignmentsタブで検証ユーザーもしくはグループを追加します。
OktaとJamf Security CloudをConnectionする（Jamf Security Cloud）
- Jamf Security CloudのIntegrationsから、Identity providersを選択し、Oktaの欄でAdd Connectionボタンを押下します。
- 接続名と組織ドメインのホスト名、さきほど作ったOkta OpenID ConnectアプリケーションのClient IDしTest and saveボタンを押下します。
検証デバイスを登録する（Jamf Security Cloud）
- Jamf Security CloudのDevicesから、Activation profilesを選択し、CreateProfilesボタンを押下します。
- 今回はiOS端末で検証するため、Network access、Network security、Content controlesにチェックマークを入れNextボタンを押下します。
- User credentialsは先ほど作ったOktaのIdentity providersを選択し、Nextボタンを押下します。
- プロファイルのAdvanced設定は今回はせずNextボタンを押下します。
- プロファイル名を記入してNextボタンを押下します。
- 確認画面で設定内容を確認し、問題がなければSave and createボタンを押下します。
- Create profileボタンを押下します。
- QRコードが生成されるので、検証端末で読み込みます。Jamf Trust Appが無いとインストール画面に遷移します。
- Oktaログインを求められるので、先ほど作ったOkta OpenID Connectアプリケーションにアサインしたユーザーでログインをします。デバイス保護のページまで辿り着けばデバイス登録完了です。
アラートを検知してUniversal Logoutしてみる
- OSアップデートをしていない端末で設定したので早速アラートがでていました。
- PeopleのRiskタブとSystemLogにもRiskとしてログが出力されていました。
- Jamf Security CloudのDeviceレポートにもLow riskで検出されております。このアラートを活用してEntity Risk Policyに引っ掛けてみます。
- SSFのアラートを検知してポリシーを実行したいので、Entity Risk PolicyのSecurity Events Provider Reported Riskを選択し、Saveボタンを押下します。
- SSFのアラートを無理やり飛ばすため、Jamf Security CloudのPoliciesからOut-of-date OSのSecurity Riskを一時的にHighに変更します。
- 検証端末を再起動したらOktaでログが出力されました。Riskが検知され、先ほど作成したEntity Risk Policyがスケジュールされ無事Universal Logoutしました。
レポート・ログの見方
Dashboard widgetに以下が新しく追加されます。
- Post auth session violations
- 認証後のセッション違反の統計情報とステータスが表示されるウィジェットです。
- At-risk users
- リスエンティティリスクレベルが過去7日間にわたって高または中のユーザーの人数と、高または中リスクレベルに達した最新のユーザーを表示するウィジェットです。
- Entity risk detections
- 高リスクの検出、ソース、トリガーされたエンティティリスクポリシールールが表示されるウィジェットです。
Reportsに以下が新しく追加されます。
- Session Violation Report
- 認証後セッション機能によってセッションが評価された回数、コンテキストの変化が検出された回数、イベントへの対応としてトリガーされたアクションのレポートです。
- Entity Risk Report
- エンティティリスクレベルに変化があった回数、変化への対応、リスク情報のソースに関するレポートです。
- At-Risk User Report
- エンティティリスクレベルが中または高のユーザーに関するレポートです。
System Logに新しいイベントが追加されます。
| 認証ポリシーの認証後セッション | policy.auth_reevaluate.fail | 認証・グローバルセッションポリシーが再評価され、違反が見つかると記録されます |
policy.continuous_access.action | Oktaがユーザーを構成済みアプリからログアウトもしくは認証・グローバルセッションポリシー違反への対応としてワークフローが実行した場合に記録されます | |
policy.continuous_access.evaluate | 認証後セッションの評価が行われると記録されます | |
| エンティティリスクポリシー | policy.entity_risk.action | Oktaがエンティティリスクポリシーを評価しアクションを呼び出すと記録されます |
policy.entity_risk.evaluate | Oktaがエンティティリスクポリシーを評価し、エンティティリスクレベルの変化が特定されると記録されます | |
| エンティティリスク | user.risk.change | エンティティのリスクレベルが変更されたときに記録されます （Peopleからユーザーのリスクレベルを手動で引き上げた場合も含む） |
user.session.context.change | OktaがユーザーのセッションコンテキストまたはIPアドレスの変更を特定したときに記録されます | |
| 管理者フィードバック | analytics.feedback.provide | Super Administratorがユーザーリスクの検出に関するフィードバックを提供すると記録されます |
| Universal Logout | user.session.end | アクセス違反への対応としてOktaがUniversal Logoutを呼び出したときに記録されます |
user.session.clear | 管理者がユーザーのセッションをクリアしたときに記録されます | |
user.session.universal_logout | Oktaまたは管理者がユーザーのUniversal Logoutを呼び出したときに記録されます | |
user.authentication.universal_logout | アプリケーションインスタンスに対してOktaまたは管理者がUniversal Logoutを呼び出したときに記録されます | |
user.authentication.universal_logout.scheduled | アプリケーションインスタンスに対して管理者がUniversal Logoutを手動でトリガーしたときに記録されます | |
| Shared Signals Framework（SSF） | security.events.provider.receive_event | Oktaがセキュリティイベントプロバイダーからリスク信号を受信したときに記録されます |
device.signals.status.timeout | ユーザーと関連付けられている登録済みデバイスが、求められる間隔内にOktaと通信しなかった場合に記録されます | |
| Okta Workflows | workflows.user.delegatedflow.run | セッション違反への対応としてOktaがDelegated Flowを呼び出したときに記録されます |
ハマりポイント
- Activation porofilesをデバイスで読み込む時に一度失敗したので別のActivation porofilesを作ったのですが、エラーで読み込めなくなりました。検証端末のJamf Trust Appを一度消して再インストールしたら無事承認が通りました。
おわりに
Identity Threat Protectionで実装された機能を確認しながら一通り手順を追って見てきました。
今回の例はiOS端末を対象にJamf Security CloudでSSFを試したので、BYODのスマホなどで業務用のSlackやGoogle Workspaceを開きたい場合に応用しやすいのではと思いました。
端末の挙動をOktaで追ってくれて、更にセッション切りも自動でしてくれるのはとても便利ですね！さらなるセキュリティ強化に興味があればお声かけください〜！
それではまた別の記事で！！！
