多要素認証

多要素認証(MFA)は、Okta Privileged Accessによって保護されるリソースに対してアクセスを試みるユーザーのIDの検証に役立つセキュリティの追加レイヤーです。MFAを有効にすることで、orgは組織で使用されるOktaサインオン(SSO)Okta Privileged Accessに固有のSSOポリシーに加え、保護のより強力なレイヤーを追加してリソースに対する特権アクセスを保護できます。

Okta Privileged Accessセキュリティ管理者は、ポリシールール内でMFAを有効化できます。これは、Okta Identity EngineOkta Classic Engineの両方のorgで有効化できます。MFA認証を有効にすると、ユーザーがSSHまたはRDPを使ってサーバーへのアクセスを試みるたびにOkta Privileged Accessは、認証がMFA条件を満たしていることを確認します。

MFAの有効化については、「セキュリティポリシー」を参照してください。

MFA構成時の考慮事項

  • 相互に重複するセキュリティポリシーのセットアップを避けることをお勧めします。異なるセキュリティポリシーで使用される複数のグループにユーザーが属している場合、または2つの異なるポリシーのセキュリティルールに同じリソースが含まれている場合、セキュリティポリシーは重複する可能性があります。ただし、このようなポリシーの実装を判断したときは、次の事項を考慮してください。
    • リソースに対するアクセスを許可するセキュリティポリシーの作成では、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チャレンジを再び完了することで解決できます。それ以後は、サーバーに接続できるようになります。
  • フィッシング耐性AuthenticatorタイプによってMFAポリシーをアクティブにする前に、フィッシング攻撃を防止するためにOkta orgレベルの管理者がFastPass、YubiKeys、WebAuthnなどのデバイスの登録をユーザーに許可していることを確認してください。

次の手順

セキュリティポリシー