フィッシング耐性を高めるためのOktaソリューション

Oktaフィッシング耐性では、組織をIDベースの攻撃から保護できます。

ユーザー名とパスワードを使用する従来の認証モデルでは、高度なフィッシング手法に対するセキュリティは提供されません。SMS、プッシュ、ワンタイムパスワードなどのより安全な要素にもリスクがあります。それらの要素は、フィッシング試行を検出するユーザーの能力に依存しているからです。

IDベースの攻撃が広範かつ頻繁に発生しているにもかかわらず、多くの組織はフィッシング耐性のある認証方法を実装することに消極的です。フィッシング耐性のある方法は、導入するのが困難であるか、ユーザーに受け入れてもらうのが難しいとお考えかもしれませんが、現時点ですでに多くのソリューションがOkta orgで利用できます。

IDベースの攻撃

IDベースの攻撃では、悪意のあるアクターがユーザーの資格情報をフィッシングしてユーザーのアプリケーションとリソースにアクセスします。

  • 資格情報スタッフィングとは、ある組織から盗まれた資格情報が別の組織にアクセスするために使用される攻撃のことです。

  • メール、電話、SMSのフィッシングメッセージには通常、攻撃者がユーザー資格情報を取得できる偽のサインインページを指すURLが含まれています。

  • ボットは、一時的なワンタイムパスワードを傍受し、それを盗んだ資格情報と一緒に使用できます。

  • 中間者攻撃の実行者は、クライアントリクエストを傍受して別のサーバーに転送することで、資格情報とセッションクッキーを取得できます。

  • MFAプッシュ消耗攻撃は、多数のプッシュ通知がユーザーの認証アプリに送信される攻撃です。

  • OAuth同意フィッシングは、アプリにすでにサインインしているユーザーをだましてデータへのアクセスを許可するよう仕向ける攻撃です。

IDベースの攻撃は、デバイスまたはブラウザーがマルウェアまたはランサムウェアに侵害されたり、ネットワークが乗っ取られたりするエンドポイント攻撃とは異なります。Oktaはエンドポイント攻撃からは保護しません。

orgのフィッシング耐性

フィッシング耐性を高めるためのOktaソリューション

orgを準備する

  1. 必要なセキュリティレベルに基づいてアプリを分類します。

    • 低セキュリティアプリ：このようなアプリは機密情報を含んでおらず、特別なユーザー権限を必要としません。不正アクセスまたは情報の開示の影響は最小限にとどまります。

    • 中セキュリティアプリ：不正アクセスまたは情報の開示は深刻な影響を与えます。

    • 高セキュリティアプリ：不正アクセスまたは情報の開示は壊滅的です。

  2. org内のすべてのエンドユーザーが適切なグループに属していることと管理者が権限別にグループ化されていることを確認します。「グループを管理する」を参照してください。

  3. ユーザーに今後のフィッシング耐性要件について通知します。コミュニケーションテンプレートについては、「Okta管理者向けローンチキット」を参照してください。

フィッシング耐性を実装する

  1. フィッシング耐性のあるAuthenticatorを有効化してセットアップします。まず、WebAuthn（FIDO 2）とOkta Verifyをセットアップします。次に、Okta FastPassを構成します。

  2. Okta FastPassとWebAuthnのAuthenticator登録ポリシーを構成します。「Authenticator登録ポリシーを作成する」を参照してください。

  3. 低/中/高セキュリティアプリ用のフィッシング耐性のある認証ポリシーを構成します。可能な場合はフィッシング耐性のあるAuthenticatorを選択します。「認証ポリシーを作成する」と「認証ポリシールールを追加する」を参照してください。

  4. セキュリティ分類に基づいてアプリをフィッシング耐性のあるポリシーに割り当てます。「認証ポリシーにアプリを追加する」を参照してください。

  5. 新規ユーザーがアプリに初めてアクセスするときにそれらのユーザーにフィッシング耐性を提供します。「事前登録されたYubiKeyを使用したフィッシング耐性のある認証を必須とする」を参照してください。

詳細な手順とユーザーエクスペリエンスについては、「フィッシング耐性のある認証」を参照してください。

orgをモニタリングする

フィッシング耐性を展開したら、アプリケーションとAuthenticatorをモニタリングします。必要に応じて認証ポリシーを改良します。

  • システムログでフィッシング耐性のあるサインインイベントをモニタリングします。「システムログのフィルターと検索」を参照してください。

  • ユーザーがフィードバックを提出できる通信チャネル（メールや内部チケットシステムなど）を確立します。

  • セキュリティを強化するため、ユーザーが追加のAuthenticatorに登録する際にフィッシング耐性のある認証を必須とします。「フィッシング耐性のあるAuthenticatorの登録」を参照してください。