Okta Secure Identity Commitment : 提供される新機能 - 前半

目次

• 「Okta Secure Identity Commitment」とは？
• Admin ConsoleのセッションへASNまたはIPアドレスをバインド
• Admin Consoleの特権アクションの実行にMFAを必須化
• 最後に

「Okta Secure Identity Commitment」とは？

こちらのブログで、弊社CEO兼共同創業者のTodd McKinnonより、アイデンティティ攻撃との戦いで業界をリードするための長期計画「Okta Secure Identity Commitment」を発表しました。Oktaは独立した中立的なアイデンティティ企業のリーディングカンパニーとして、「すべての人があらゆるテクノロジーを安全に使うことができる世界を実現する」というビジョンを目指しており、セキュリティの強化が重要な役割を担います。

この長期計画の一環として、お客様に「市場をリードするアイデンティティ製品とサービスを提供する」ことを掲げております。Oktaの中で特権ユーザーに該当する管理者は、必然的にその特権の悪用を狙ったアイデンティティ攻撃の対象となるリスクが高まります。これらの管理者がOktaのテナントに対する設定を行う「Admin Console」はOktaのテナントから見ると一つのアプリケーションの位置付けであり、今回のブログではAdmin Consoleに纏わる新機能を取り上げます。何れも、簡易操作で大幅なセキュリティ強化の効果が見込める内容となっております。

Admin ConsoleのセッションへASNまたはIPアドレスをバインド

概要

Admin ConsoleへのAPIまたはWebリクエストのソースのASN (Autonomous System Number) またはIPアドレスがセッション確立時に記録されたものと異なる場合、セッションを失効する機能となります。ASNとは通信事業者やインターネットサービスプロバイダにより統一された制御に基づくインターネット上のネットワークの単位であり、IPアドレスにはASNが紐付きます。ASNが郵便番号であれば、IPアドレスは番地といった関係性として捉えることができます。

セッションの期間中にソースのASNまたはIPアドレスが変更した場合はセッション侵害の可能性が高いため、この類の攻撃を未然に防ぐことが可能です。認証済みの有効なセッショントークンが脅威者に窃取された場合、MFA（MFAとは？）をバイパスしてAdmin Consoleへの不正アクセスを許してしまうため、こちらの機能はセッション侵害のリスクに対する有効な手段となり得ます。

設定方法

ASNをバインドする機能は全てのテナントに対してデフォルトで有効化されており、管理者の操作によって無効化することはできません。無効化する場合は、弊社サポートまでお問い合わせ下さい。

IPアドレスをバインドする機能は同じく全てのテナントに対してデフォルトで有効化されておりますが、管理者の操作によって無効化することが可能です。Admin Consoleの [Security（セキュリティ）] > [General（一般）] > [Organization Security（組織のセキュリティ）] より [IP binding for admin console（Admin ConsoleのIPバインディング）] の項目を編集する形で、機能の有効化と無効化を切り替えます。

こちらの機能によってAdmin Consoleに対するセッションが失効した場合、システムログに以下の情報が含まれるイベントが生成されます。

• Event : 
  • DisplayMessage : Roaming session detected for user
  • EventType : security.session.detect_client_roaming
  • Outcome : 
    • Reason : IP address changed from <IP_ADDRESS_1> to <IP_ADDRESS_2>
    • Result : DENY

端末のマルウェア感染やフィッシング攻撃を発端としたセッション侵害によるAdmin Consoleへの不正アクセスというセキュリティインシデントの可能性として、Okta Workflowsを利用した管理者への通知やチケット作成などのプロセスを自動化することも可能です。

上記のイベントは2024年8月末の時点でEvent Hookの対象としてサポートされていないため（Event Hookのサポート対象はこちらの一覧のうち”event-hook-eligible”がタグ付けされたもの）、設定可能の最短間隔の5分おきにシステムログを検索するフローとして構築する必要があります。対象のイベントをSlackに通知する簡易的なフローはこちらのページからFlow Folderファイルとしてダウンロードし、Okta Workflowsにインポートすることで試すことが可能です。ページ下部の「その他のブログ」項目より「疑わしいIPアドレスのローミングを検知」のzipファイルをお手元にダウンロードし、解凍したファイルをご利用下さい。

Oktaの [Search System Logs] のカードで403エラーが発生する場合はこちらのKnowledge Baseに記載の通り、Admin Console側で [Okta Workflows OAuth] のアプリに付与されたスコープを確認し、それでもエラーが解消されない場合はOkta Workflowsコンソール側でOkta Connectionの再作成をお試し下さい。また、インポート後にはSlackの [Send Message to Channel] のカードでチャンネルの手動設定など、フローの起動に先立って各カードの内容を事前にご確認下さい。なお、こちらの内容はあくまでもサンプルの位置付けであり、動作を保証するものではなく、またフロー全体としての動作やロジックはサポート対象とはならない点につき予めご了承下さい。

Admin Consoleの特権アクションの実行にMFAを必須化

概要

Admin Console内における重要な設定変更、即ち特権アクションの実行に際してステップアップ認証として追加要素による認証を要求する動作を実現する機能となります。こちらのドキュメントに記載の通り、現時点で特権アクションの位置付けとなる設定変更は以下の通りです。

• スーパー管理者ロールを割り当てる/取り消す
• 保護対象アクションを構成する
• 外部IdPを作成または変更する
• スーパー管理者ロールの付与および取り消しを行う
• スーパー管理者の認証要素をリセットする
• スーパー管理者のパスワードをリセットする（およびスーパー管理者をサインアウトする）
• スーパー管理者のパスワードを期限切れにする（およびスーパー管理者をサインアウトする）
• 管理者のパスワードを一括で期限切れにする
• 管理者のパスワードを一括でリセットする
• Admin Consoleの認証ポリシーを更新する

セッション侵害やソーシャルエンジニアリングの攻撃をもとに脅威者がAdmin Consoleへのアクセスに成功した場合、例えばこちらのブログで紹介されている手口では「成りすましアプリ」として外部IdPを作成し、インバウンドフェデレーションの仕組みを悪用してOktaと連携された業務アプリケーションへの不正アクセスが試みられる可能性が高いと言えます。

こちらの機能を利用することによってこのような重要な設定変更の際にはステップアップ認証を要求する動作フローを実現することが可能となるため、万が一Admin Consoleへの不正アクセスが発生した際にもその影響を最小限に抑えることができます。

設定方法

Admin Consoleの [Applications（アプリケーション）] > [Applications（アプリケーション）] より [Okta Admin Console] のアプリケーションを選択し、[Protected Actions（保護対象アクション）] のタブを開きます。 [Edit（編集）] ボタンをクリックすると、ステップアップ認証を要求する間隔とその対象となる特権アクションを選択することができます。

こちらの機能によってAdmin Console内の特権アクションの実行に際してステップアップ認証が失敗した場合、システムログに以下の情報が含まれるイベントが生成されます。

• Event : 
  • DisplayMessage : Protected action attempted
  • EventType : security.protected_action.attempt
• Target : 
  • DisplayName : <設定された保護対象アクションの名称>
  • ID : <設定された保護対象アクションのID>
  • Type : Protected Action

こちらも「Admin ConsoleのセッションへASNまたはIPアドレスをバインド」の機能と同様にシステムログ上のイベント発生を起点としたOkta Workflowsによる通知やチケット作成の自動化フローを作成することができますが、こちらの機能では標準でメール通知の機能が準備されています。Admin Consoleの [Settings（設定）] > [Account（アカウント）] より [Admin email notifications（管理者メール通知）] の項目を編集し、[Admin performs a protected action（管理者が保護対象アクションを実行）] にチェックを入れて保存します。

最後に

OktaのAdmin ConsoleはOktaのテナントに対する設定を行う重要なアプリケーションであり、セッション侵害やフィッシングをはじめとするアイデンティティ攻撃への対策は非常に重要なポイントです。今回のブログで紹介されている機能はいずれも簡易操作で設定することが可能であり、是非とも前向きにその活用をご検討下さい。次回のブログでは、API連携をはじめとするセキュリティ強化の新機能を紹介します。