サイバー攻撃者は絶えず進化し、より洗練された方法を開発しています。フィッシング攻撃やソーシャルエンジニアリング攻撃は増加の一途をたどっており、組織がより高度な認証システムを実装すると、攻撃者はそれらに急速に適応します。新たな戦略のひとつは、ユーザーのWebブラウザから直接セッショントークンを盗み出すことです。これは、デジタルセキュリティの戦いにおいて新たな挑戦となっています。
Oktaでは、攻撃者がユーザーのデバイス上の機密情報にアクセスするのを防ぐことを最優先事項としています。Okta FastPassは、コンテキストの再評価によって、この種の攻撃を阻止するのに役立ちます。
コンテキストの再評価とは？ そのメリットとは？
FastPassは、新しいアプリにアクセスするたびにセキュリティチェックをサイレントに実行し、Oktaがデバイスのアイデンティティや態勢に重大な変化があったと判断した場合、それ以降のアクセスを防止します。デバイスとユーザーのリスクの変化を処理するこの機能は、盗まれたセッションがダウンストリームアプリケーションにアクセスするのを防ぐという大きなメリットをもたらします。
コンテキストの再評価を使ってOkta FastPassを構成するには？
ステップ1：Okta Verifyを認証アプリとして追加する。
ステップ 2： 認証システムの登録ポリシーを作成。 「Eligible authenticators（対象認証システム）」セクションで、Okta Verifyが「Required（必須）」に設定されていることを確認してください。
ステップ 3： 認証ポリシーを作成し、アプリケーションを割り当てる。
- 認証ポリシー規則を次の設定で追加。
- 「Device state（デバイス状態）」を「Registered（登録済）」に設定。
- 「 User must authenticate with（認証時に要求）」を「Possession（所有）」に設定。
- 「Phishing Resistant（フィッシング耐性）」チェックボックス を チェック。
- 「Hardware Protected（ハードウェアの保護）」チェックボックスを チェック （推奨）。
- また、「User's group membership includes（ユーザーのグループメンバー に以下を含める）」 をテスト目的で特定のグループに設定することもできます。
- 「Re-authenticate frequency（再認証の頻度）」セクションで、「Re-authenticate after（再認証開始時間）」を2時間に設定します。この値は、ビジネスニーズに基づいて変更できます。
- デフォルトのCatch-all Rule（キャッチオールルール）を編集し、「Access（アクセス）」を「Denied（拒否）」に設定。
ステップ 4にある手順に従って、ユーザーがロックアウトされないようにしてください。
- ダウンストリームアプリケーションをポリシーに追加する。
- 「Applications（アプリケーション）」タブを選択し、 「Add app（アプリを追加）」をクリック。
- それぞれのアプリで「Add（追加）」をクリックし、このポリシーに追加。
- 「Close（閉じる）」をクリック。
ステップ4： [推奨] Access Testing Toolを使用して検証します
Access Testing Toolを使用すると、アプリケーションにアクセスするための実際のユーザーリクエストのシミュレーションを実行できます。結果は、ユーザーがアプリへのアクセスを許可されるかどうか、および認証と登録の要件を作成するために構成のどのルールと設定が一致したかを示します。
- Admin Console（管理コンソール）で、「Reports（レポート） > Access Testing Tool」に移動。
- Application（アプリケーション）: ステップ 3で使用したアプリケーションを選択。
- Username（ユーザー名）：アクセスをテストするユーザーのユーザー名を入力。表示されたら、リストから選択。
- Device State（デバイスの状態）を「Registered（登録済）」に設定。
- 必要に応じて他のオプションを変更します。
- 「Run Test（テスト実行）」をクリック。
そのページの「Results（結果）」セクションで結果を確認します。Matching Policies（マッチングポリシー）セクションに、テストが成功した場合は、条件に一致するすべてのポリシーが表示されます。「Sign-in journey（サインインジャーニー）」オプションで「Authenticate（認証）」タイルを選択してください。このオプションは、シミュレーターに構成した条件に一致する認証システムと認証要件を含むポリシーを表示します。ここには、ステップ 3で作成した認証ポリシーが表示されます。
ステップ 5. その他のダウンストリームアプリケーションを認証ポリシー（オプション）に追加。
ステップ 6: デバイス保証ポリシーを追加します（推奨）。
デバイス保証チェックには、セキュリティ関連のデバイス属性のセットが含まれます。認証ポリシー規則にデバイス保証チェックを追加することで、組織内のシステムおよびアプリケーションへのアクセスを持つデバイスの最小要件を確立できます。
ステップ6.1：デバイス保証ポリシーを追加する。
ステップ 6.2: 認証ポリシーにデバイス保証を追加。
では、コンテキストの再評価を実際に見てみましょう。
次のステップは？
Oktaは、FastPassが組織により高いセキュリティを提供できるよう、継続的な改善に取り組んでいます。現在、Oktaはブラウザベンダーと協力し、セッションCookieが盗まれたり、許可された元のデバイス以外のデバイスで使用されたりするのを防ぐための標準的なソリューションに取り組んでいます。
—
FastPassやDevice Securityについてご質問がある場合には、Okta Devices and Mobilityコミュニティボードに参加して、会話を開始しましょう。
このブログ記事についてご質問がありますか？eng_blogs@okta.comまでご連絡ください。
Oktaの洞察力に富んだエンジニアリングブログで、知識をさらに深めてください。
Oktaの情熱的で優秀なエンジニアチームで働きませんか？採用情報ページをご覧ください。
組織向けの最新かつ高度なID管理の可能性を解き放ちます。
詳細は、セールス担当者にお問い合わせください。
