共有信号レシーバーを構成する
Oktaを共有信号レシーバーとして構成すると、Oktaがセキュリティ関連のイベントをセキュリティイベントプロバイダーのアプリから受信できるようになります。この統合は、OpenID Shared SignalsとEvents Frameworkの仕様を基にしています。
統合をセットアップするには、管理者は、Oktaに信号を送信するセキュリティプロバイダーから構成の詳細情報を収集する必要があります。Admin Consoleでストリームを構成すると、Oktaは信号をイベントとして取り込めるようになります。リスク信号をセキュリティイベントトークン（SET）としてOktaに送信するようにトランスミッターを構成するには、「SSFセキュリティイベントトークンAPI」を参照してください。
これらの信号はリスクエンジンに情報を伝え、Oktaではエンティティリスクの検出（user.risk.detectイベント）としてレポートされます。Oktaは、受信したShared Signals Framework（SSF）およびContinuous Access Evaluation Protocol（CAEP）イベント（security.events.provider.receive_eventというSystem Logイベントにカプセル化）のパブリッシュも行います。user.risk.detectイベントで伝達されるリスク評価は、Workflows、セッション取り消し、またはUniversal Logoutを使ってエンティティリスクポリシーがアクションを構成する際に使用されます。これにより、デバイス上、ネットワーク上、アプリケーション内のアクティビティのようなIDのスコープ外の脅威面とのインタラクションやデータとのインタラクションによってエンティティのリスクが確実に通知されます。
SSFの統合により、Oktaとインタラクションしていない場合でもOktaユーザーを保護できます。
開始する前に
セキュリティイベントプロバイダーからリスク信号を受信するには、SSFトランスミッターを構成する必要があります。これは、セキュリティプロバイダーのアプリで行われ、セキュリティプロバイダーのアプリとの統合をAdmin Consoleで構成する際に使用されるJWKS（JSON Webキーセット）が提供されるようになります。SSFトランスミッターの構成については、セキュリティプロバイダーのドキュメントを参照してください。
セキュリティイベントプロバイダー
Identity Threat Protection with Okta AI（ITP）はデフォルトでOkta Verifyを継続的にポーリングして、信号を取得します。また、ITPはCrowdStrike FalconやWindowsセキュリティセンター（構成されている場合）など、対応のエンドポイントセキュリティ統合からも信号を取得します。
Oktaソースの信号に加えて、ITPは以下のセキュリティイベントプロバイダー（構成されている場合）から信号を受信することができます。
| セキュリティプロバイダー |
アプリ |
|---|---|
| Cloudflare | Cloudflare One Enterprise |
| CrowdStrike Falcon | Okta Verify |
| Jamf | Jamf Security Cloud（Jamf Radar） |
| Netskope | Netskope Cloud Exchange |
| Okta | Okta Verify |
| Palo Alto Networks | Cortex XSIAM |
| Rubrik | Rubrik Security Cloud（RSC） |
| SGNL | 全製品 |
| Windowsセキュリティセンター | Okta Verify |
| Zimperium | Mobile Threat Defense（旧称「zIPS」） |
| Zscaler | Deception |
セキュリティイベントプロバイダーのアプリを構成する
Oktaでセキュリティイベントを表示するには、事前にOktaと情報を共有するようにセキュリティプロバイダーのアプリを準備する必要があります。
CrowdStrike FalconやWindowsセキュリティセンターからOktaに信号を送信するには、それらをOkta Verifyに統合する必要があります。「エンドポイントセキュリティ統合」を参照してください。
セキュリティプロバイダーのアプリで発行者とJWKSのURLを生成してOkta orgへの信号の送信を保護します。
次の手順に従ってOktaをSSFレシーバー、Jamfをトランスミッターとしてセットアップします。信号ソースとSSF（Shared Signals and Events Framework）の詳細、および信号をOktaと共有するためのセキュリティプロバイダーアプリケーションの構成については、セキュリティプロバイダーのアプリのドキュメントを参照してください。
- Jamfにスーパー管理者としてサインインします。
- を開きます。
- ［Create new SSF stream（新規SSFストリームを作成）］をクリックします。
- オーディエンスを入力します。これは、ストリームを識別するURLです。この場合のオーディエンスは、Oktaテナントのアドレス（たとえば、https://your-org.oktapreview.com、https://your-org.okta.comなど）です。
- ［Create（作成）］をクリックします。
ストリームが作成されると、Jamfはトークンを返します。SSFレシーバーは、自動検出のサポートにこのトークンを使用します。このトークンは、Oktaでは使用されません。代わりに良く知られたURL（Well-known URL）をコピーしてAdmin Consoleに入力します。
共有信号を受信する
Okta orgがSSFを使ってプロバイダーアプリからのセキュリティ信号を受信できるようにします。SSFはセキュリティプロバイダーアプリケーション間にネットワークを作成し、セキュリティ情報を継続的にOktaと共有してユーザーに対するセキュリティ脅威を防止および緩和する上で役立ちます。
- Admin Consoleでに移動します。
- ［Receive shared signals（共有信号を受信）］タブをクリックします。
- ［Add stream（ストリームを追加）］をクリックします。
- ［Integration name（統合名）］を入力します。
- Oktaによる受信を構成している信号のトランスミッターから送信される、良く知られたURLまたは発行者とJWKS（JSON Webキーセット）のURLとの統合をセットアップできます。統合（この例では良く知られたURL）を選択します。
- セキュリティプロバイダーアプリケーションからのURLを［Well-known URL（良く知られたURL）］フィールドに貼り付けます。
- ［Create（作成）］をクリックします。
ストリームが正しく作成されると、Admin Consoleのストリームリストに表示されます。デフォルトでは、ステータスは［Active（アクティブ）］に設定されます。
エラーによってOktaがストリームを作成できない場合、ストリームを追加し直すように求めるメッセージが表示されます。ストリームの再接続を試みる前に、入力したURLが正しいことを確認してください。
ストリームアクション
ストリームが作成されると、ストリームリストに表示されます。デフォルトでは、追加されたすべてのストリームは［Active（アクティブ）］です。ストリームを編集、非アクティブ化、または削除するには、［Actions（アクション）］をクリックしてドロップダウンメニューからオプションを選択します。
ストリームイベントを監視する
SSFストリームを構成すると、OktaはCAEPに準拠するセキュリティイベントトークン（SET）を受信するようになります。SETはエンティティリスクの計算方法をOktaに伝えます。これは、security.events.provider.receive_eventというSystem Logイベントで確認できます。
管理者は、いくつかの方法でSSFストリームを監視できます。
- security.events.provider.receive_eventというSystem Logイベント内のSETコンテンツを表示します。
- それがuser.risk.detectイベントでカプセル化されていることを確認します。
- Oktaで受信または表示できる、送信がサポートされるリスクイベントのタイプについては、セキュリティプロバイダーのドキュメントを参照してください。
- Oktaが検出したエンティティリスクを表示するには、エンティティリスクレポートを使用します。