Citrix Gateway

nFactor 認証の要素としての EPA スキャン

以下は、nFactor EPA の基本エンティティの一部です。

EPA アクション -EPA アクションは、nFactor EPA 用に導入されたアクションタイプです。次の内容が含まれています。

  • クライアントセキュリティ式 — この式は、評価のためにゲートウェイ EPA プラグインに送信されます。
  • Success Group — このグループは、設定されている場合、EPA の結果が true の場合にゲートウェイセッションに継承されます。
  • 検疫グループ — このグループは、設定されている場合、EPA の結果が false の場合にゲートウェイセッションに継承されます。
  • killProcess — これは、EPA プロセスが終了する必要があるプロセスの名前を表します。
  • deleteFiles — EPA プロセスで削除する必要があるファイルへのカンマ区切りのパスを指定します。

グループは、セッションの存続期間中に使用して、クライアントが特定の EPA 条件を満たしているかどうかを判断できます。 特定の要素で EPA が失敗し、最後のアクションに「検疫グループ」が含まれていない場合、そのユーザーの認証は終了します。 「検疫グループ」が存在する場合、認証は継続され、管理者は制限付きアクセスを許可するグループを確認できます。詳細については、「 EPA の実行」を参照してください。

EPA ポリシー -nFactor では、すべてのポリシーが同じ構文「認証ポリシーの追加」で追加されます。ただし、アクションのタイプによって、ポリシーが EPA ポリシーとして認定されます。

EPA ファクター -EPA ファクターは通常のポリシーラベルです。EPA ファクターと呼ばれるエンティティはありません。EPA ポリシーがファクタにバインドされると、EPA ファクタにする特定のプロパティが継承されます。 注:「EPA ファクター」という用語は、このドキュメントでは EPA ポリシーのファクターを指す場合によく使用されます。

EPA — 隔離 -特定のファクタで、すべてのアクションのすべてのクライアントセキュリティ式が失敗し、最後のアクションに「隔離グループ」が含まれている場合、そのグループがセッションに追加され、NextFactor が検索されます。つまり、失敗にもかかわらず、「検疫グループ」の存在は、セッションを次の段階に認定します。ただし、特別なグループの継承により、管理者はセッションを制限されたアクセスまたは追加の認証ポリシー(OTP や SAML など)に降格させることができます。

最後のアクションで検疫グループが存在しない場合、認証は失敗して終了します。

nFactor の EPA は、次のエンティティも使用します。

  • loginSchema — ログオンフォームの XML 表現。ログオンフォームの「ビュー」を定義し、「ファクタ」のプロパティも持っています。
  • ポリシーラベルまたはポリシーファクタ :認証の特定の段階で試行されるポリシーの集まりです。
  • 仮想サーバラベル — 仮想サーバはポリシーラベルでもあり、ポリシーを仮想サーバにバインドできます。ただし、仮想サーバーは、ユーザーアクセスのエントリポイントであるため、さまざまなポリシーラベルの集まりです。
  • next factor :指定された認証ポリシーが成功したときに取得されるポリシーラベル/ファクタを指定するために使用されます。
  • NO_AUTHN ポリシー — アクションが常に成功する特別なポリシー。
  • パススルーファクタ — ログインスキーマにビューが含まれていないポリシーラベル/ファクタです。これは、Citrix ADCアプライアンスが、ユーザーの介入なしに指定された要素で認証を続行することを示します。

詳細については、 nFactor の概念、エンティティ、および用語を参照してください

EPA ファクター相互排他性

EPA ファクターには、1 つ以上の EPA ポリシーが含まれています。EPA ポリシーがファクタにバインドされると、そのファクタに対する通常の認証ポリシーは使用できません。この制限は、最高のユーザーエクスペリエンスを提供し、エンドポイント分析を明確に分離することです。この規則の唯一の例外は NO_AUTHN ポリシーです。NO_AUTHN ポリシーは「障害時ジャンプ」をシミュレートするために使用される特別なポリシーであるため、EPA ファクタで許可されています。

EPA の実行

任意の要素(仮想サーバーファクタを含む)で、ログオンフォームを提供する前に、Citrix ADCアプライアンスはファクタがEPA用に構成されているかどうかを確認します。その場合、EPA シーケンスがトリガーされるように、特定の応答をクライアント (UI) に送信します。このシーケンスは、クライアントセキュリティ式を要求し、結果を送信するクライアントで構成されます。 ファクタ内のすべてのポリシーのクライアントセキュリティ式は、クライアントに一度に送信されます。Citrix ADCアプライアンスで結果が得られると、すべてのアクションの各式が順番に評価されます。EPA が成功する最初のアクションはその要素を終了し、defaultGroup (構成されている場合) はセッションに継承されます。NO_AUTHN ポリシーが検出された場合、それは自動成功と見なされます。nextFactor が指定されている場合、アプライアンスはそのファクタで続行します。それ以外の場合、認証は終了します。 この条件は、第1因子にも当てはまります。仮想サーバーで EPA の後に認証ポリシーファクタがない場合、認証は終了します。これは、EPA の後にユーザーに常にログインページが表示される従来のポリシーの動作とは異なります。 ただし、EPAポリシーが成功しない場合、Citrix Gateway は、そのファクタまたはカスケードの最後のEPAポリシーに対して構成された検疫グループを検索します。最後のポリシーが検疫グループで構成されている場合、そのグループがセッションに追加され、NextFactor が検査されます。NextFactor が存在する場合、認証はその要素に進みます。それ以外の場合、認証は完了します。

定期的な EPA スキャンを nFactor 認証の要素として構成する

高度なポリシーインフラストラクチャを使用して、定期的な EPA スキャンを nFactor 認証の要素として設定できます。 注: クラシックポリシーでは、定期的な EPA はでセッションポリシーの一部として設定されました vpn session action。 以下のロジックは、nFactor 認証の要素として EPA スキャンを実装する例として使用されます。

nFactor フローシーケンスの EPA

  • ユーザーがNetScaler Gateway 仮想IPに接続しようとしました。
  • ユーザー名とパスワードフィールドを含むログインページがユーザーにレンダリングされ、ログイン資格情報が提供されます。これらの資格情報を使用して、LDAP または AD ベースの認証がバックエンドで実行されます。成功すると、EPA スキャンを承認するためのポップアップがユーザーに表示されます。
  • ユーザーが承認すると、EPA スキャンが実行され、ユーザークライアント設定の成功または失敗に基づいて、アクセスが提供されます。
  • スキャンが成功すると、EPA スキャンが定期的に実行され、構成されたセキュリティ要件が引き続き満たされていることが確認されます。
  • このようなチェック中に EPA スキャンが失敗すると、セッションは終了します。

前提条件

次の設定が行われていると仮定します。

  • VPN 仮想サーバ、ゲートウェイ、および認証仮想サーバの設定
  • LDAP サーバの設定と関連付けられたポリシー。

次のセクションでは、必要なポリシーとポリシーラベルの設定、およびポリシーとポリシーラベルの認証プロファイルへのマッピングについて説明します。

nFactor ポリシーおよびポリシーラベルマッピングの EPA

ロジックの CLI 設定

  1. EPA スキャンを実行するアクションを作成し、EPA スキャンポリシーに関連付けます。

    add authentication epaAction EPA-client-scan -csecexpr "sys.client_expr("proc_2_firefox")"
    
    add authentication Policy EPA-check -rule true -action EPA-client-scan
    <!--NeedCopy-->
    

    上記の式は、プロセス「Firefox」が実行されているかどうかをスキャンします。EPA プラグインは、スキャン式の数字「2」で表される 2 分ごとにプロセスの存在をチェックします。

  2. EPA スキャンのポリシーをホストするポリシーラベル post-ldap-epa-scan` を設定します。

    add authentication policylabel post-ldap-epa-scan -loginSchema LSCHEMA_INT
    <!--NeedCopy-->
    

    注: LSCHEMA_INT は、スキーマなし (スキーマなし) の組み込みスキーマです。つまり、このステップでは追加のウェブページがユーザーに表示されません。

  3. ステップ 1 で設定したポリシーを、ステップ 2 で設定したポリシーラベルに関連付けます。

    bind authentication policylabel post-ldap-epa-scan -policyName EPA-check -priority 100 -gotoPriorityExpression END
    <!--NeedCopy-->
    

    これで認証メカニズムは完了です。

  4. ldap-auth policyを設定して、特定の LDAP サーバで認証するように設定された LDAP ポリシーに関連付けます。

    add authentication Policy ldap-auth -rule true -action ldap_server1
    <!--NeedCopy-->
    

    ここでldap_server1はLDAP ポリシー、 ldap-authはポリシー名です。

  5. すべてをまとめて、ldap-auth policyをCitrix ADC AAA仮想サーバーに関連付けて、EPAスキャンを実行するためのポリシーラベルpost-ldap-epa-scanを指す次のステップを使用します。

    bind authentication vserver MFA_AAA_vserver -policy ldap-auth -priority 100 -nextFactor post-ldap-epa-scan -gotoPriorityExpression NEXT
    <!--NeedCopy-->
    

    注: 複数のファクタとして設定された定期的な EPA では、定期的な EPA 設定を持つ最新のファクタが考慮されます。

    前の例では、EPA がスキャンでプロセス「Firefox」を検索する最初の要素です。

    • EPA スキャンが成功すると、LDAP 認証が行われ、次の EPA スキャンが実行され、プロセス「Chrome」が検索されます。
    • 複数の定期スキャンが異なるファクタとして設定されている場合は、最新のスキャンが優先されます。この場合、EPA プラグインは、ログイン成功後 3 分ごとにプロセス「Chrome」をスキャンします。

参照ドキュメント

nFactor 認証の要素としての EPA スキャン