Okta FastPassによるコンテキストの再評価

このブログはこちらの英語ブログ(2024年3月27日公開)の翻訳、池山 邦彦によるレビューです。

サイバー攻撃者は絶えず進化し、より洗練された方法を開発しています。フィッシング攻撃やソーシャルエンジニアリング攻撃は増加の一途をたどっており、組織がより高度な認証システムを実装すると、攻撃者はそれらに急速に適応します。新たな戦略のひとつは、ユーザーのWebブラウザから直接セッショントークンを盗み出すことです。これは、デジタルセキュリティの戦いにおいて新たな挑戦となっています。

Oktaでは、攻撃者がユーザーのデバイス上の機密情報にアクセスするのを防ぐことを最優先事項としています。Okta FastPassは、コンテキストの再評価によって、この種の攻撃を阻止するのに役立ちます。

コンテキストの再評価とは? そのメリットとは?

Okta FastPassは、新しいアプリにアクセスするたびにセキュリティチェックをサイレントに実行し、Oktaがデバイスのアイデンティティやポスチャに重大な変化があったと判断した場合、それ以降のアクセスを防止します。デバイスとユーザーのリスクの変化を処理するこの機能は、盗まれたセッションがダウンストリームアプリケーションにアクセスするのを防ぐという大きなメリットをもたらします。

V0 6xsyUOy P3JGr2Tiw ggFcBO7UmINv93MBjVonOey21ny4BqZKuqeZGr0SZh8 7tYBEtH3nAdOIxF50mozB1uHJXxbAWgk6zW9zF3pZNZzFKv5trODPyW4GeGWjbsRcsEfPtZtbCShOldAJgyS10

コンテキストの再評価を使ってOkta FastPassを構成するには?

ステップ 1: Okta Verifyを認証システムとして追加

ステップ 2: 認証システムの登録ポリシーを作成。 「Eligible authenticators(対象認証システム)」セクションで、Okta Verifyが「Required(必須)」に設定されていることを確認してください。

ステップ 3: 認証ポリシーを作成し、アプリケーションを割り当てる。

  1. 認証ポリシー規則を次の設定で追加。
    1. 「Device state(デバイス状態)」を「Registered(登録済)」に設定。
    2. 「 User must authenticate with(認証時に要求)」を「Possession(所有)」に設定。
    3. 「Phishing Resistant(フィッシング耐性)」チェックボックスをチェック。
    4. 「Hardware Protected(ハードウェアの保護)」チェックボックスをチェック(推奨)。
    5. また、「User's group membership includes(ユーザーのグループメンバーに以下を含める)」 をテスト目的で特定のグループに設定することもできます。
    6. 「Re-authenticate frequency(再認証の頻度)」セクションで、「Re-authenticate after(再認証開始時間)」を2時間に設定します。この値は、ビジネスニーズに基づいて変更できます。
  2. デフォルトのCatch-all Rule(キャッチオールルール)を編集し、「Access(アクセス)」を「Denied(拒否)」に設定。

ステップ 4にある手順に従って、ユーザーがロックアウトされないようにしてください。

  1. ダウンストリームアプリケーションをポリシーに追加。
    1. 「Applications(アプリケーション)」タブを選択し、 「Add app(アプリを追加)」をクリック。
    2. それぞれのアプリで「Add(追加)」をクリックし、このポリシーに追加。
    3. 「Close(閉じる)」をクリック。

ステップ 4: Access Testing Tool(アクセステストツール)で検証。(推奨)

Access Testing Toolは、アプリケーションへのアクセスに対する実際のユーザーからのリクエストのシミュレーションを実行できます。その結果、ユーザーにアプリへのアクセスが許可されるかどうか、また、認証と登録の要件の作成に構成のどのルールと設定が一致したかが表示されます。

  1. Admin Console(管理コンソール)で、「Reports(レポート) > Access Testing Tool(アクセステストツール)」に移動。
  2. Application(アプリケーション): ステップ 3で使用したアプリケーションを選択。
  3. Username(ユーザー名):アクセスをテストするユーザーのユーザー名を入力。表示されたら、リストから選択。
  4. Device State(デバイスの状態)を「Registered(登録済)」に設定。
  5. 必要に応じて他のオプションを変更します。
  6. 「Run Test(テスト実行)」をクリック。

そのページの「Results(結果)」セクションで結果を確認します。Matching Policies(マッチングポリシー)セクションに、テストが成功した場合は、条件に一致するすべてのポリシーが表示されます。「Sign-in journey(サインインジャーニー)」オプションで「Authenticate(認証)」タイルを選択してください。このオプションは、シミュレーターに構成した条件に一致する認証システムと認証要件を含むポリシーを表示します。ここには、ステップ 3で作成した認証ポリシーが表示されます。

ステップ 5: その他のダウンストリームアプリケーションを認証ポリシー(オプション)に追加。

ステップ 6: デバイス保証ポリシーを追加(推奨)。

デバイス保証チェックには、セキュリティ関連のデバイス属性のセットが含まれています。デバイス保証チェックを認証ポリシーのルールに追加することで、組織内のシステムやアプリケーションにアクセスするデバイスの最低要件を確立することができます。

  ステップ 6.1: デバイス保証ポリシーを追加

   ステップ 6.2: 認証ポリシーにデバイス保証を追加

では、コンテキストの再評価を実際に見てみましょう。

以上の内容は、原文(英語)の参考和訳であり、原文と内容に差異がある場合は、原文が優先されます。

次のステップは?

Oktaは、Okta FastPassが組織により高いセキュリティを提供できるよう、継続的な改善に取り組んでいます。現在、Oktaはブラウザベンダーと協力し、セッションCookieが盗まれたり、許可された元のデバイス以外のデバイスで使用されたりするのを防ぐための標準的なソリューションに取り組んでいます。

Okta FastPassやDevice Securityについてご質問がある場合には、Okta Devices and Mobilityコミュニティボードに参加して、会話を開始しましょう。

このブログ記事についてのご質問は、[email protected]までご連絡ください。