サイバー脅威が複雑さと頻度を増すにつれて、堅牢なアイデンティティセキュリティの必要性はかつてないほど重要になっています。IDベースの攻撃（侵害された認証情報や不正アクセスなど）は、組織に重大なリスクをもたらします。これらの脅威から保護するには、疑わしいアクティビティを検出し、対応し、既存のセキュリティ対策とシームレスに統合する、プロアクティブでインテリジェントなアプローチが必要です。
Okta Identity Threat Protection with Okta AIをご紹介します。これは、組織のアイデンティティセキュリティを強化するために設計された最先端のソリューションです。人工知能（AI）の力と包括的なアイデンティティ保護を組み合わせたOkta Identity Threat Protectionは、最新のサイバーセキュリティの独自の課題に対処するために調整された、リアルタイムの継続的な脅威検出および対応機能を提供します。
Okta AIを搭載したOkta Identity Threat Protectionの最も強力な機能の1つは、Okta Workflowsとの連携です。これらのワークフローは、自動化を構築し、セキュリティインフラストラクチャが脅威に動的かつ効果的に対応できるようにします。カスタマイズ可能なポリシー駆動型のアクションにより、Okta Workflowsを使用して、侵害されたアカウントを非アクティブ化または隔離したり、高リスクのアクティビティに対して多要素認証（MFA）を強制したり、セキュリティチームに潜在的な侵害を警告したりできます。これにより、防御をアクティブで応答性の高いものにすることができます。
Okta AIを搭載したOkta Identity Threat Protectionと、ローコード自動化プラットフォームであるOkta Workflowsが、セキュリティとビジネスの目標達成にどのように役立つかをご紹介します。
Okta Identity Threat Protectionのためのオーダーメイドの自動化
以下は、Okta AIによるOkta Identity Threat Protectionの簡略化されたビューです。Oktaとパートナーからのシグナルとイベントは常にOktaに供給され、Identity Threat Protectionリスクエンジンがリスクを判断し、関連するポリシーを実行します。
これらのポリシーは、Universal Logout の実行や、Okta Workflows でのデリゲートフローの呼び出しなど、是正処置をトリガーできます。この記事では、これらをポリシーによって開始されるワークフローと呼びます。
リスク評価により、ユーザーリスクレベル（エンティティリスクレベルと呼ばれる）の引き上げなど、Okta内でアクションがトリガーされる場合もあります。ユーザーリスクレベルの変更は、ポリシーの再評価、セッションコンテキストの変更、サードパーティベンダーからのリスクシグナルの受信などとともに、Oktaシステムログに書き込まれるIdentity Threat Protectionに関連する多くのイベントの1つにすぎません。Okta内のほとんどすべてのアクティビティがシステムログに記録されます。イベントフックまたはWorkflows内の組み込みのOktaコネクタを使用して、対象となるイベントからワークフローをトリガーするのが一般的です。この記事では、これらをイベント開始ワークフローと呼びます。
ポリシー開始ワークフロー
製品ドキュメントより：Okta AIによるIdentity Threat Protectionがリスクを発見し、修復イベントがユニバーサルサインアウトを超える追加のアクションを必要とする場合、委任されたワークフローを自動的に実行できます。
Okta Workflowsコネクタを通じて提供されるサードパーティのアプリとサービスは、多数の可能な修復アクションを提供します。
- Slackまたはメールでユーザーまたは管理者に通知
- ユーザーを無効にする
- 特権グループからユーザーを削除する
- ユーザーを新しい制限付きグループに移動する
- デバイスを隔離する
- インシデントチケットをキューに送信する
- 要件に基づいて、リスクシナリオごとに異なるフローを構成する
さらに、ほぼすべてのコネクターに含まれているCustom API Actionカードを使用して、サードパーティのAPIエンドポイントと連携できるカスタムアクションを作成できます。
Okta Identity Threat Protectionのドキュメントでは、特定のポリシーから開始できるいくつかのWorkflowの例を示しています。
- ポリシー違反を示すSlackメッセージを送信する
- リスクを軽減するために、ユーザーセッションをクリアし、メール通知を送信します。
- すべてのメンバーシップからユーザーを削除し、アカウントを無効にします
したがって、ポリシーによって開始されるワークフローは、ワークフローが特定のポリシーに関連付けられているため、Identity Threat Protectionによって生成された特定のリスクに関連する自動化に役立ちます。ユーザーリスクレベルの変更など、より一般的な状況に基づいて自動化を推進する場合は、イベントによって開始されるワークフローがより適切です。
イベント開始型ワークフローの例
以下は、Oktaシステムログのイベントからワークフローをトリガーし、さまざまなユースケースをカバーする3つの例です。
- ユーザーリスクレベルの変更により、ServiceNowでチケットがトリガーされ、Oktaの高リスクグループに割り当てられます。
- ユーザーが高リスクアプリケーションに割り当てられると、ワークフローはユーザーのリスクをチェックし、新しいアクセスを許可またはロールバックします。
- ユーザーが高リスクのアプリケーションに割り当てられると、ワークフローはユーザーのリスクをチェックし、User Access ReviewをOkta Identity Governanceで許可またはトリガーします。
1. ServiceNowのチケットを記録し、高リスクグループにユーザーを割り当てる
この例では、 user.risk.detect にサブスクライブされたイベントフックを使用しますワークフローをトリガーするイベント。このシナリオでは、セキュリティチームにSlackでイベントに関する有用な詳細を通知し、リスクレベルが変更されたユーザーのマネージャーにメールを送信します。
ユーザーのリスクレベルがHIGHの場合、ServiceNowインシデントを作成し、Oktaの高リスクグループにユーザーを追加し、ServiceNowインシデントへのリンクを通知に追加し、ユーザーがグループに追加されたことを示します。ユーザーのリスクレベルが下がると、高リスクグループから削除されます。
このWorkflowは次のことを行います。
- Oktaシステムログの「user.risk.detect」イベントによってトリガーされます。Oktaシステムログの「user.risk.detect」イベントによってトリガーされます。APIエンドポイントフローを指すイベントフックを使用します。（詳細については、WorkflowsでのOktaイベントフックの処理を参照してください。）
- イベントの詳細を解析する
- IDでユーザーを読み取り、プロファイルから情報を返し、イベントに関連するシステムログクエリへのリンクを生成します
- ユーザーのリスクレベルを特定します。
- 現在「HIGH」の場合
- ServiceNowインシデントを作成する
- 高リスクのOktaグループにユーザーを追加する
- ユーザーのマネージャーにメールを送信する
- 上記の操作に関するコンテキストを含むチャット通知を充実させる
- 「HIGH」から減少した場合：
- 高リスクのOktaグループからユーザーを削除する
- 上記の操作に関するコンテキストを含むチャット通知を充実させる
- 現在「HIGH」の場合
- すべてのuser.risk.detectで通知を送信イベント：
- すべての user.risk.detect のセキュリティチャネルへのSlack（またはTeams）メッセージイベント
- グループの追加/削除に関する情報を追加し、該当する場合はServiceNowインシデントにリンクします。
フローを見ていきましょう。まず、user.risk.detectからペイロードを解析しますイベントが発生し、後でフローで使用するいくつかの値を割り当てます。次に、ステータスコード200でイベントフックへの接続を閉じます。
次に、いくつかのヘルパーフローを呼び出します。1つは、debugData.riskイベントをさらに解析して、現在および以前のリスクレベルを取得するのに役立ちます。もう1つは、リスクレベルが上がったユーザーに関するプロファイル情報を取得し、イベントに関するシステムログクエリへのリンクを構築します。
ユーザーのリスクが「HIGH」になった場合、
- それらを高リスクのOktaグループに追加します。
- ユーザーのマネージャーにメールを送信
- ServiceNowでインシデントを作成する
- すべてのリスクレベルの変更で送信されるSlack通知をカスタマイズして、ユーザーがグループに追加されたことをチームに通知し、ServiceNowインシデントへのリンクを含めます。メッセージには、ServiceNowの「インシデントの作成」アクションが失敗した場合も表示されます。
最後に、動的に構築されたメッセージを取得し、
- ユーザーが高リスクのOktaグループに追加または削除されました
- ServiceNowインシデントとリンク（または、インシデントの作成に失敗した場合は調査へのリンク）
すべてのuser.risk.detectでデフォルトで送信する他のリスクイベントの詳細と組み合わせてイベントを送信し、通知を送信します。
このようなフローを実装すると、WorkflowsとOkta Identity Threat Protectionの力を活用して、Oktaテナントで検出されたリスクシグナルをチームが継続的にリアルタイムで可視化できます。これにより、通知の送信、チケットの作成、および高リスクグループでのユーザーの隔離や、別のプラットフォームでの対応のためのSLAによるインシデントのトリガーなど、応答を自動化するために使用するさまざまなプラットフォームを統合できます。「高リスク」のOktaグループは、チームが調査する機会を得るまで、ユーザーのアクセスを制限する厳格なポリシーの対象となる可能性があります。グループにユーザーを追加すると、他のフローがトリガーされる可能性があります。または、Identity Threat Protection内でグループに適用されるより厳格なポリシーを設定することもできます。
2. 高リスクアプリケーションの割り当てに対するユーザーリスクのチェック
この例では、Oktaに高リスクのアプリケーションがあります（PAM製品、Okta Advanced Server Accessなど）。ユーザーがこのアプリケーションに割り当てられると、ユーザーリスクレベルをチェックします。ユーザーのリスクレベルが低い場合、アプリへのアクセスが許可されます。リスクが中程度の場合、アクセスは許可されますが、これを強調するためにSlackメッセージが書き込まれます。リスクが高い場合、アプリケーションアクセスはロールバックされます。
このWorkflowは次のことを行います。
- Oktaシステムログのapplication.user_membership.addイベントによってトリガーされます。これはOkta Workflowsコネクタに組み込まれている標準イベントです。
- Slackメッセージが必要な場合に詳細を取得するために、IDでユーザーを検索します
- ユーザーリスクを判断します。この場合、ユーザーがHighまたはMediumリスクグループに属しているかどうかを確認するために、ユーザーのグループのルックアップを実行しています。
- ユーザーリスクが低い場合、アプリへのアクセスが許可されます（つまり、何も行いません）。
- ユーザーリスクが中程度の場合、アプリへのアクセスを許可しますが、管理者チームにSlackメッセージをフォーマットして送信します
- ユーザーリスクが高い場合、アプリケーションへのユーザー割り当てを削除します。
フローを見ていきましょう。まず、ユーザーJohn SmithがOkta Advanced Server Accessアプリに追加されたことを示すイベントがあります。
Johnの詳細と、彼が所属するグループを検索して、彼の危険度を判断します。
Johnが中リスクであり、対応する中リスクグループに属している場合（Workflowsによって、彼のリスクが何らかのIdentity Threat Protectionイベントから中リスクに変更されたときに割り当てられた）、Slackにメッセージが書き込まれます。
Johnが高リスクで、対応する高リスクグループにいる場合、彼の割り当ては別のOkta actionを使用して元に戻されます。
これは、アプリケーション（またはユーザー）のOktaシステムログイベントで確認できます。
これは、ユーザーリスクを使用してアプリケーションリスクを管理する、非常にシンプルで強力な例です。
3. ユーザーアクセスレビューによる高リスクアプリケーション割り当て時のユーザーリスクの確認
次に、前のシナリオを拡張します。高リスクユーザーが高リスクアプリケーションにアクセスできるようになったときに自動的にアクセスを取り消すのではなく、Okta Identity Governanceでユーザーアクセスレビューを提起します。
フローは基本的に以前と同じですが、最後のステップでアプリへのアクセスを削除するのではなく、ワークフローはOkta Identity GovernanceのCampaigns APIとOkta ConnectorのCustom APIアクションカードを使用して、ユーザーアクセスレビュー（アクセス認証）を作成および開始します（詳細はヘルパーフローに埋め込まれています）。
前述のように、ユーザーがアプリに割り当てられると、ユーザーリスクレベル（High）は、Access Certificationキャンペーンを作成および起動するために必要な相対URLとrequestBodyを構築するヘルパーフローにワークフローをルーティングします。
これはユーザーのマネージャーにレビューのために割り当てられ、マネージャーがOktaにログインすると、レビューするキャンペーンがあることがわかります。
詳細を確認すると、John Smithに割り当てられているすべてのアプリケーションが表示されます。
彼らはアクセスをレビューし、JohnがOkta Advanced Server Accessアプリを必要としないと判断し、[取り消し]ボタンをクリックします。
これにより、システムログイベントに示されているように、アプリケーションが削除されます。
このアプローチは、より柔軟性を提供します。ユーザーが正当な理由で高リスクアプリケーションにアクセスする必要がある場合があるため、マネージャーによるユーザーアクセスレビューを行うことは、監査に準拠した管理方法です（もちろん、アクセスリクエストフローを適用することもできますが、それは別の記事での会話です）。
脅威の状況を常に把握する
これらのOktaの機能を活用することで、より高いセキュリティと運用効率を実現し、セキュリティプロトコルをビジネス目標に合わせることができます。疑わしいアクティビティに対してMFAを強制したり、侵害されたアカウントを非アクティブ化または隔離したり、潜在的な侵害をセキュリティチームに通知したりするなど、Okta Identity Threat ProtectionとWorkflowsを使用すると、組織はアイデンティティベースの攻撃に対して回復力を維持できます。
現代のサイバーセキュリティの複雑さをナビゲートする中で、Okta AIによるOkta Identity Threat Protectionは、セキュリティアーセナルにおける重要なツールとして際立っています。組織をより適切に保護し、脅威に迅速かつ効果的に対応する能力を高めます。これらのサービスを統合することで、進化する脅威の状況に対応するだけでなく、それを先取りすることができます。
Oktaでアイデンティティセキュリティの未来を受け入れ、組織が今日と明日の課題に対処できるようにします。Okta Identity Threat ProtectionとOkta Workflowsを使用すると、デジタル環境をより安全にし、貴重な資産を保護し、自信を持ってビジネス目標を追求することができます。
Okta Identity Threat Protection with Okta AIとOkta Workflowsの詳細をご覧ください。
本資料は一般的な情報提供のみを目的としたものであり、法務、プライバシー、セキュリティ、コンプライアンス、またはビジネス上の助言を目的としたものではありません。
