今回は、 Okta と Jamf Security Cloud を用いて、継続的な条件付きアクセスを構築、検証してみましたのでご紹介いたします。

1. はじめに

1.1 Okta Identity Threat Protection とは？

Identity Threat Protection は、ユーザーとそのセッションを継続的に評価し、Okta Risk Engine やセキュリティイベントプロバイダーからリスクシグナルを受信します。ITP は、ユーザーのリスク、ネットワークゾーン、デバイス、動作の変化を識別すると、org のセキュリティ要件に応じて構成できる自動化された緩和および修復アクションを開始します。　この継続的かつリアルタイムのリスク評価は、ID管理セキュリティに対するゼロトラストアプローチを提供します。

Identity Threat Protection with Okta AI

要するに 「Okta Identity Threat Protection (ITP)」は、不正ログインやアカウント悪用を自動で見抜き、リスクに応じて認証やブロックをかけてくれる仕組み です。

1.2 検証の背景

ゼロトラストの考え方が広がる中で、「一度サインイン時にリスク評価しているから安全」というモデルから「利用中も継続的にリスクを評価する」モデルへの移行が求められています。
今回、Okta Identity Threat Protection と Jamf Security Cloud を組み合わせて、Continuous Conditional Access（継続的な条件付きアクセス）がどのように動作するのかを検証しました。

1.3 実現したいこと

Okta と Jamf Security Cloud を統合して、デバイス状態や脅威シグナルをもとに、Okta で動的にアクセス制御できるかを確認します。
これにより、利用中にリスクが高いと判断された場合に、自動でログアウトするという環境を構築していきます。

全体の大きな流れとしては、以下の通りです。
・デバイスのリスク状態を Jamf Trust が検知し Jamf Security Cloud へ連携
・Jamf Security Cloud から SSF で Okta に通知
・Okta がリスクポリシーに基づいてセッション制御

概要図

1.4 参考資料

今回は以下の資料を元に検証しております。

Offer Safe and Continuous Network Access with Jamf and Okta

Leverage protocols like the Shared Signals Framework (SSF) and Continuous Access Evaluation Profile (CAEP) using Jamf and Okta to offer your employees safe, simple network access from anywhere.

“Enhancing Zero Trust with Okta Identity Threat Protection and Jamf Security: Continuous Access Evaluation Through Shared Security Signals” – IAMSE

Introduction In today’s rapidly evolving threat landscape, identity is the new security perimeter. Organizations face sophisticated cyber threats that target user credentials, exploit access gaps, and challenge traditional security measures. To stay ahead, IT and security teams need a proactive, intelligent approach to identity protection—one that not only detects threats but also responds in real … Continue reading “Enhancing Zero Trust with Okta Identity Threat Protection and Jamf Security: Continuous Access Evaluation Through Shared Security Signals” →

1.5 用語集

ITP
Okta Identity Threat Protection の略。継続的なリスク評価機能。
SSF
Shared Signals Framework の略。システム間のセキュリティイベント共有プロトコル。
Entity Risk Level
ユーザーやデバイスに対するリスクの評価レベル。 Low / Medium / High の3段階で管理される。
Entity Risk Policy
Entity Risk Level に応じて実行するアクション（ログアウト、MFA要求等） を定義する Okta のポリシー設定。

2. 要件

各システムでの要件を一部抜粋いたしました。詳細は参考資料をご確認ください。

Okta（Okta Identity Engine）の要件

• Okta Identity Threat Protection の有効化
• エンティティリスクポリシーの設定
• Shared Signals Framework（SSF）の有効化

Jamf Security Cloud の要件

• Jamf Pro との統合設定（今回は割愛します）
• Shared Signals Framework（SSF）の有効化

3. 設定

早速設定していきます。今回は、リスクに応じてアプリケーションからログアウトされる設定をします。

Okta の設定 – Jamf SSO アプリケーション –

1) Okta 管理コンソールへログイン
2) Applications > Applications と進み、Create App Integration をクリックします。
3) Create a new app integration にて以下の通り設定します。
・Sign -in method：OIDC – OpenID Connect
・Application type：Native Application

Create a new app integration 設定画面

4) New Native App Integration にて以下の通り設定して、保存します。
・App integration name：任意（検証では、Jamf End User SSO と設定）
・Grant type：Refresh Token を追加で選択
・Sign-in redirect URIs：以下の3つを追加
com.jamf.trust-auth://login
wandera-auth://login
http://localhost:4566/
・Sign-out redirect URIs：以下の2つを追加
com.jamf.trust-auth://logout
wandera-auth://logout
・Assignments：Skip group assignments for now（後に設定するため）

New Native App Integration 設定画面

5) General > General Settings にて、Edit をクリックします。
6) USER CONSENT にて、Require consent のチェックを外します。
7) Authentication > Claims にて、Edit をクリックします。
8) Groups claim filter を以下の通り設定し、保存します。
・groups Matches regex .*
9) Assignments にて検証用のユーザー or グループをアサインします。
10) General > Client Credentials にて、Client ID を控えます。

Jamf Security Cloud の設定 – IdP Connection –

1) Jamf Security Cloud にログインします。
2) Integrations > Identity providers にて、Okta のセクションで、Add connection をクリックします。
3) Add connection を以下の通り設定して保存します。
・Connection name：任意の名前（検証では、Okta Organization Domain を設定）
・Your organization domain：Okta Organization Domain を設定します。
・Client ID：「Okta の設定 – Jamf SSO アプリケーションの作成 -」の手順10 で控えた Client ID

Jamf Security Cloud の設定 – UEM Connect –

今回は割愛します。詳細は Jamf のドキュメントをご確認ください。

Jamf Security Cloud の設定 – アクティベーションプロファイル –

1) Devices > Activation profiles にて、Create profile をクリックする。
2) Capabilities and Routing にて、以下の3つを選択する。
・Network access
・Network security
・Content controls

Capabilities and Routing 設定画面

3) Authentication > User credentials (SSO) にて、IdP Connection で設定した設定を選択します。
4) Advanced settings にて、プロファイルの追加パラメータを設定します。
5) Naming and grouping にて、任意の名前や Device group の割り当てを設定します。
6) Review にて、各種設定の内容を確認し、問題なければ保存します。

Jamf Security Cloud の設定 – Jamf Trust とアクティベーションプロファイルの配布 –

今回は割愛します。詳細は Jamf のドキュメントをご確認ください。

Jamf Security Cloud の設定 – Threat Prevention Policy の設定 –

任意の設定をしてください。詳細は Jamf のドキュメントをご確認ください。

Jamf Security Cloud の設定 – Shared Signals Framework の設定 –

1)  Integrations > SSF Streams にて、Create new SSF stream をクリックします。
2) Audience に、https://< Okta ドメイン >.okta.com を入力します。
例：https://hogehoge.okta.com
3) トークンが作成されるのでメモしておきます。
4) 作成された設定で、Well known セクションの Well known URL をメモしておきます。
5) Integrations > SSF Streams にて、作成した設定を Actions > Configure と進み、Configure をクリックします。
6) Endpoint URL に以下の URL を入力します。
https://< Okta ドメイン >.okta.com/security/api/v1/security-events
7) Events に、RISK_LEVEL_CHANGED を設定します。
8) 保存します。

この設定により、Jamf Security Cloudは、デバイスのリスクステータスが変更されるたびに、上記設定を通じて、「リスクレベルの変更」というイベントを生成します。

Okta の設定 – Threat Protection の設定 –

1) Security > Device Integrations にて、Receive Shared Signals のタブへと進みます。
2) Create Stream より以下の内容で作成します。
・Integration name ：任意の名前（検証では、Jamf Security Portal と設定）
・Set up integration with：Well-Known URL
・ Well-Known URL：Jamf Security Cloud の設定 – Shared Signals Framework の設定 – の手順4でメモした Well-Known URL

Receive Shared Signals 設定画面

Okta の設定 の設定 – Entity Risk Policy の設定 –

Risk レベルに応じた対応をこちらで設定します。
1) Security > Entity Risk Policy にて、Add rule をクリックします。
2) 検証用に以下のルールを設定します。
・Rule name：任意の名前（検証では「Jamf Signal Provider Reported Risk」と設定）
・Detection：Include at least one of the following detections / Security Events Provider Reported Risk
・Entity risk level：Medium （ 4.1 の動作確認時は High で確認します）
・Take this action： Logout and Revoke Tokens

Entity Risk Policy の設定画面

4. 動作確認

今回は2パターンで動作確認してみます。
検証前の前提条件として、以下を確認、設定しておきます。
・検証のユーザーは Entity risk level が Low となっていること
・iPad で事前にダッシュボードにサインインしていること

4.1 Okta の Entity risk level 操作による動作確認

Okta 管理コンソールにて、手動で Entity risk level を上げて、iPad での動作確認をしてみます。

4.1.1 Directory > People にて、動作確認用のユーザーを選択します。
4.1.2 More Action > Elevate Entity Risk Level を選択します。

Elevate Entity Risk Level 操作画面

4.1.3 画面の指示に従い、Entity Risk Level を High に引き上げます。

Elevate Entity Risk Level 操作確認画面

4.1.4 iPad 側では、ダッシュボードで画面をリロードすると、以下のように Okta からログアウトします。

Entity Risk Policy によってサインアウトした画面

4.2 iPad でデバイスリスク変化による動作確認（パスコード削除）

次に、iPad でデバイスのパスコードを削除して、リスクレベルを上げてみました。

4.2.1 デバイス側でパスコードをオフにします。
4.2.2 Jamf Trust で保護の状態が変更されていることを確認します。

Jamf Trust の保護の状態

4.2.3 iPad 側で、ダッシュボードで画面をリロードすると、4.1.4 の画像のようにサインアウトすることを確認します。

4.3 ログ確認

Okta 管理コンソールでも以下のようにログが確認が取れました。 

Jamf Signal Provider のログ

ログ確認

5. 考察

従来は「サインイン時のリスク評価」が中心でしたが、今回の検証により、Jamf Security Cloud からのリアルタイムなシグナルを Okta が取り込み、セッション中でもアクセス権を取り消せることが確認できました。

一方で、実際の運用に組み込んでいくには以下の内容を検討する必要があると思います。

• セッション中に突然アクセスが切れる場合の通知やガイドライン（セッションが切れた後の対処法等）の作成
• リスク判定基準をどのレベルに設定するか（Mediumで拒否するのか、Highのみなのか）の方針設計
• サインイン時とセッション中のリスク評価によるアクセス方針の整合性

上記を考慮した上で運用に組み込んでいくと、よりゼロトラストの原則に近づいた運用が可能になると思います。

6. 最後に

今回は、利用中のリスク評価に応じた対応を実施いたしました。
個人的には、Jamf Security Cloud と Okta の統合による利用中のリスク評価は、環境に導入する価値が高いと感じました。
特に、既に Jamf 製品 や Okta Identity Threat Protection を導入済みの組織では、比較的スムーズに PoC が可能です。
一方で、導入においてはきちんとしたセキュリティ設計が必要となるとも思いました。
本記事が、皆様の環境での検討・評価のきっかけとなれば幸いです。

最後まで読んでいただき、ありがとうございました。
以上、今回の記事は住吉が担当しました。