はじめてのOkta Workflowsシリーズ 第7回 不審なプッシュチャレンジを検出する

今回のブログでは、OktaがOkta Workflowsのセキュリティテンプレートとして公開しているフローを取り上げて、ロジックを解説をしたいと思います。

※ なお、本投稿は、Using Workflows to Respond to Anomalous Push Requests（Okta Security Blog）の記事を参考に、日本語で解説している記事です。

「MFA疲労（または、プッシュ疲労）」という攻撃手法をご存知でしょうか。ユーザーのパスワードを何らかの手法で知り得た攻撃者が、被害者になりすまし、実際のウェブサイトへログインを試みます。その際にユーザーが多要素認証としてプッシュ通知を設定している場合、攻撃者は連続でログインを試みることで、プッシュ通知を大量に送りつけます。そこで、被害者は、通知を見てシステムエラーと思い込んでしまったり、プッシュ通知を許可することが習慣化されているためプッシュ通知の内容を確認せずに誤ってアクセスを許可してしまい、攻撃者はアカウントへの不正アクセスに成功するという攻撃手法です。

このような攻撃に対抗する手段として、Okta FastPass、FIDO2 WebAuthn 認証システム、またはスマートカードなどのフィッシング耐性のある認証器をつかうことが求められます。また、プッシュリクエストを使っている場合は、Number Challengeを組み合わせて利用することが有効な対策となります。

しかし、組織ではそれらの設定変更をすぐにおこなうことができない事情もあります。対応するまでの間、今回ご紹介するフローを使って、不審なプッシュリクエストを検出し、不審なイベントへの対応をほぼリアルタイムで自動化することができます。

元の記事では、Okta Verifyプッシュ通知リクエストの信頼性を評価する具体的なフローを2つご紹介しています。今回の投稿では、1つ目のフロー「不審なプッシュチャレンジを検出する」について解説します。

「不審なプッシュチャレンジを検出する」ロジック

今回ご紹介するフローはOkta Identity Engineの機能をもとに開発されています。どのように「不審」なプッシュチャレンジを認識するかといいますと、プッシュチャレンジのソース（Oktaにサインインする際に、Oktaサインインウィジェットによって生成されるソースイベント）が、チャレンジ（宛先イベント）を受けて許可または拒否のアクションを行うOkta Verifyのクライアント（正しいユーザーのデバイス）とは異なる場所からであるかどうかを判断しています。異なる場所からだった場合に、「不審」なプッシュチャレンジと判断し、イベントを特定する情報と共に、セキュリティ担当者に通知します。

具体的には、以下のようなイベント情報がSystem Logから確認することができますので、これらの情報をOkta Workflowsを活用して一致するか突合します。

各イベントの地理位置情報 (国、州、都市) は client.geographicalContext オブジェクトにあります。

フローの実装概要

フローは、Oktaが用意しているOkta Workflowsのセキュリティテンプレートからインポートして使うことが出来ます。フローの実装を行う場合、以下のステップでおこないます。

1. フローのインポート
2. Event Hookの構成
3. フローの設定
4. 通知に使用するコネクターを接続
5. テスト

各ステップを解説します。

1. フローのインポート

1. Workflows Consoleにログインし、テンプレート[Detect suspicious MFA push notifications]を検索し、[Add template]をクリックして、テンプレートをインポートします。

2. [Detect suspicious MFA push notifications]というフォルダが自動的に作られて、そのフォルダの中に同じ名前のフローが1つ作られていることが確認できると思います。

2. Event Hookの構成

このテンプレートは、Okta Verifyがプッシュ通知を送信したときにフローをトリガーするイベントフックを使用します。

EA（早期アクセス）機能（*）である[Event Hook filtering]の有効化

(* 本ブログ公開時点では早期アクセス機能として提供）

1. Okta Admin Consoleにて、[Settings]-[Features]をクリックします。
2. [Event Hook filterling]を有効化します。

Event Hookの作成

1. Workflows Consoleにて、先程インポートした[Detect suspicious MFA push notifications]フロー内にある[API Endpoint]カードの一番下のEndpoint settingsアイコン[</>]をクリックします。

2. [Invoke URL]の右横にある[copy]をクリックし、URLをコピーします。

3. Okta Admin Consoleにて、[Workflow]-[Event Hooks]をクリックします。
4. [Create Event Hook]ボタンをクリックします。

5. [Endpoint URL]にWorkflow Consoleでコピーした[Invoke URL]を貼り付けます。また、[Event Hook name]に名前をつけます。例では、[Filter Successful Okta Verify push notifications]としています。

6. [Select all events that apply]にて[Authentication of user via MFA.]を選択します。

7. 設定が完了したら、[Create hook & Continue]ボタンをクリックします。
8. [Apply filter]をチェックし、フィルターの設定をおこなうため、[Use Okta Expression Language (advanced)]をクリックします。

9. [Expression language]に、以下の式をコピー＆貼り付けをおこないます。

event.target.?[displayName eq 'Okta Verify'].size() > 0 && event.outcome.result eq 'SUCCESS'

この式でフィルターをかけることによって、Okta Verifyのプッシュが成功した後にのみワークフローが実行されるように、イベントフックを限定することができます。

10. 設定が完了したら、[Save & Continue]をクリックします。
11. [Preview]では内容を確認し、[Skip this step]をクリックします。
12. [Activate hook by verifying endpoint ownership]の画面で、[Verify]ボタンをクリックし検証が成功したら、[Event Hooks]のページに戻ります。これで、Event Hookの作成は完了です。

3. フローの設定

[Detect suspicious MFA push notifications]テンプレートに含まれる各カードの処理内容を解説します。

On Demand - API Endpoint

[API Endpoint Settings]の[Invoke URL]にEventがPOSTされたら、フローが実行されます。

JSON - Parse

[API Endpoint]カードで取得したbodyの内容はJSON形式です。Parse処理をおこない、dataオブジェクトの中にあるeventsオブジェクトを取得します。

List - At

取得したeventsの中からリストの0番目のデータに入っているログ情報を取得します。このログには、Okta Verifyプッシュ通知が成功した際の詳細な内容が含まれています。

JSONペイロードのサンプルはOkta Developerのこちらのページを参照してください。

Object - Get

[List]カードで取得したItemの中から、認証ファクターの情報を取得するため、debugContext.debugData.factorの内容を取得します。

Branching - Continue If

[Get]カードで取得した認証ファクターがOkta Verifyプッシュ通知かどうかを確認します。Okta Verifyプッシュ通知だった場合のみ、処理を継続します。

Object - Get Multiple

Okta Verifyプッシュ通知での認証だった場合に、取得したログから、地理位置情報（国、州、都市）やユーザー情報など複数の値を取得します。

Text - Compose

System Logを検索するためのフィルターを作成します。

Okta Verifyプッシュ通知を使用した認証の場合、プッシュ通知チャレンジの発行元（ソース）に対応するシステムログイベントがあります。その対応したイベントには、Event Hookで取得したものと同じexternalSessionIdが使われています。

Okta - Search System Logs

[Compose]カードで作成したフィルターを使って、System Logを検索します。

Object - Get Multiple

[Search System Logs]カードで該当したログから、地理位置情報（国、州、都市）を取得します。

Branching - Continue If

Okta Verifyプッシュ通知の送信元（ソース）と、プッシュ通知の承認をおこなう受け入れ先（宛先）の地理位置情報（国、州、都市）を比較し、一致しなかった場合に、処理を継続します。

Text - Compose

[Continue If]カードで一致しなかった場合に、不審なプッシュチャレンジと判断し、担当者へ通知するため、通知内容のメッセージを生成します。

4. 通知に使用するコネクターを接続

テンプレートでは、不審なプッシュチャレンジを知らせるためのメッセージ生成までしか用意されていませんので、必要に応じて、担当者へチャットやメールなどで通知するよう設定を行います。

まず最初に、必要に応じて、[Compose]カードの通知メッセージを日本語にします。

次に、Slackに通知する方法についてご紹介します。

Slack - Send Message to Channel

Slackの指定したChannelへ[Compose]カードで作成したメッセージを投稿します。

Slack以外にも、メールやPagerDutyへ起票するといったこともできます。

5. テスト

次に、フローをテストで実行するための手順をご紹介します。

Okta API Scopesにて同意の付与

[Search System Logs]カードを使ってSystem Logを検索するときには、事前に[okta.logs.read]というScopeに対して同意を付与する必要があります。

1. Okta Admin Consoleにて、[Applications]-[Applications]をクリックし、[Okta Workflows OAuth]をクリックします。
2. [Okta API Scopes]タブをクリックします。
3. Scope [okta.logs.read]に対し、[Grant]をクリックし、同意を付与します。

Okta Connectionの接続

[Search System Logs]カードは、Okta Connectionを利用しています。フローを実行する前に、接続設定をする必要があります。

設定方法は、「はじめてのOkta Workflowsシリーズ 第４回 日付を指定したユーザーの自動作成と削除」の第2章「Oktaへの接続（Connection)」にて解説しています。

注意：Oktaと接続後に、前手順[Okta API Scopesにて同意の付与]を行った場合は、Scope変更後に必ず、[Reauthorize]をクリックして再認証をおこない、フローを[Save]する必要があります。

フローの有効化

フローを有効化します。

該当フローの画面上部に [Flow is OFF]となっている箇所をクリックすると、有効化されます。有効化されると、[Flow is ON]と表示されます。

実行結果の確認

Okta Verifyプッシュ通知を使って、Okta環境へログインします。ログイン後に、このフローが実行されていることが確認できます。

実行結果は、[HISTORY]欄のアイコンと数字をクリックすると確認することができます。

最後に

本投稿では、OktaがOkta Workflowsのセキュリティテンプレートとして公開しているフローを取り上げて、ロジックの解説を行いました。System Logの検索をおこなうことで、セキュリティーポリシーに合わせてアラートを作成し、ほぼリアルタイムに通知をおこなうことが可能です。今回の内容が、運用を考える上で参考になれば幸いです。