多要素認証
多要素認証（MFA）は、Okta Privileged Accessによって保護されるリソースに対してアクセスを試みるユーザーのIDの検証に役立つセキュリティの追加レイヤーです。MFAを有効にすることで、orgは組織で使用されるOktaポリシーとOkta Privileged Accessに固有のSSOポリシーに加え、保護のより強力なレイヤーを追加してリソースに対する特権アクセスを保護できます。
Okta Privileged Accessセキュリティ管理者は、ポリシールール内でMFAを有効化し、サーバーとシークレットに対するアクセスを保護できます。これは、Okta Identity EngineとOkta Classic Engineの両方のorgで有効化できます。MFA認証が有効化されると、ユーザーはシークレットへのアクセスを試みるたびにMFA条件を満たすことが求められます。同様に、サーバーアクセスのMFAが有効化されると、Okta Privileged Accessは、ユーザーがSSHまたはRDPを使ってサーバーとの接続を試みるたびに、認証がMFA条件を満たすことを求めます。
MFAの有効化については、「セキュリティポリシー」を参照してください。
複数の認証および認可条件がユーザーアクセスにどのように影響するかを理解します。「ルール条件」を参照してください。
MFA構成時の考慮事項
- 相互に重複するポリシーのセットアップを回避する
- 異なるセキュリティポリシーで使用される複数のグループにユーザーが属している場合、または2つの異なるポリシーのセキュリティルールに同じリソースが含まれている場合、セキュリティポリシーは重複する可能性があります。リソースに対するアクセスを許可するセキュリティポリシーの作成では、MFA設定が異なるポリシーの重複を回避することが重要です。このようなポリシーが存在する場合、ユーザーがリソースにアクセスする際にシステムは最も厳しいMFA要件を強制適用します。
- MFA設定を変更すると既存のMFAチャレンジが無効になる
- セキュリティポリシールール内の既存のMFA設定が変更される場合、そのセキュリティポリシーによって管理されるリソースへのアクセスのためにユーザーが完了したMFAチャレンジは無効になります。結果として、リソースに対するアクセス権がユーザーに付与されるには、ユーザーは別のMFAチャレンジを完了する必要があります。ただし、これは一切のアクティブセッションに影響しません。
- 複数のポリシールールが存在するときは、フィッシング耐性が優先される
-
同一ポリシーまたは異なるポリシーのいずれかに複数のポリシールールが存在する場合、フィッシング耐性が優先されます。たとえば、ポリシー内のMFAが次のルールによって有効化されるとします。
- ルール1：フィッシング耐性
- ルール2：任意の2要素タイプ
このシナリオでは、システムはルール1を選択します。
- 複数のフィッシング耐性条件が存在するときは、再認証の頻度が最も少ない条件が選択される
-
複数のフィッシング耐性タイプのMFA条件が存在する場合、システムは、再認証の頻度設定が最も小さい条件を選択します。たとえば、ポリシー内のMFAが次のルールによって有効化され、再認証の頻度が構成されるとします。
- ルール1：フィッシング耐性、再認証頻度を3,600分に設定
- ルール2：フィッシング耐性、再認証頻度を600分に設定
- ルール3：任意の2要素タイプ、再認証頻度を4,200分に設定
このシナリオでは、システムはルール2を選択します。
- 期間が短いMFAでは、ユーザーが接続方法の選択に遅れるとエラーが生じる
- セキュリティポリシーのMFA期間が短い場合、接続方法とアカウントの選択が遅れたエンドユーザーがサーバーへの接続を試みると「サーバーが見つかりません」というエラーが生じる可能性があります。これは、MFA認証の期限切れが原因である可能性があります。この問題は、ユーザーがサーバーに接続し直してMFAチャレンジを再び完了することで解決できます。それ以後は、ユーザーはサーバーに接続できます。
- フィッシング攻撃を防止するために、FastPass、YubiKey、WebAuthnなどのデバイスをユーザーが登録できるようにする
- フィッシング攻撃を防止するために、フィッシング耐性AuthenticatorタイプでMFAポリシーをアクティブ化する前に、Okta orgレベルの管理者がOkta FastPass、YubiKey、WebAuthnなどのデバイスの登録をユーザーに許可したことを確認します。