nFactor 認証の要素としての EPA スキャン
重要:
エンドポイント分析は、あらかじめ決められたコンプライアンス基準に照らしてユーザーデバイスを分析することを目的としており、エンドユーザーデバイスのセキュリティを強制または検証するものではありません。ローカル管理者による攻撃からデバイスを保護するには、エンドポイントセキュリティシステムを使用することをお勧めします。
以下は、nFactor EPA の基本エンティティの一部です。
EPA アクション: EPA アクションは nFactor EPA に導入されたアクションタイプです。次の内容が含まれています。
- クライアントデバイスチェック式:この式は、評価のためにゲートウェイ EPA プラグインに送信されます。
- 成功グループ:EPA の結果が true の場合、このグループは (設定されている場合) ゲートウェイセッションに継承されます。
- 検疫グループ:EPA の結果が false の場合、このグループが設定されている場合、ゲートウェイセッションに継承されます。
- KillProcess: EPA プロセスが終了しなければならないプロセスの名前を表します。
- DeleteFiles: EPA プロセスで削除する必要があるファイルへのパスをカンマで区切って指定します。
グループは、セッションの存続期間中に使用して、クライアントが特定の EPA 条件を満たしているかどうかを判断できます。 特定の要素で EPA が失敗し、最後のアクションに「検疫グループ」が含まれていない場合、そのユーザーの認証は終了します。 「検疫グループ」が存在する場合、認証は継続され、管理者は制限付きアクセスを許可するグループを確認できます。詳細については、「 EPA の実行」を参照してください。
EPA ポリシー:nFactor では、すべてのポリシーが同じ構文「認証ポリシーの追加」で追加されます。ただし、アクションのタイプによって、ポリシーが EPA ポリシーとして認定されます。
EPAファクター： EPAファクターは通常のポリシーラベルです。EPA ファクターと呼ばれるエンティティはありません。EPA ポリシーがファクタにバインドされると、EPA ファクタにする特定のプロパティが継承されます。
注：
このドキュメントでは、「EPA ファクター」という用語は、EPA ポリシーが適用されるファクターを指す場合によく使用されます。
EPA — 隔離: あるファクターですべてのアクションのすべてのクライアントデバイスチェック式が失敗し、最後のアクションに「Quarantine group」が含まれている場合、そのグループがセッションに追加され、NextFactor が調査されます。つまり、失敗にもかかわらず、「検疫グループ」の存在は、セッションを次の段階に認定します。ただし、特別なグループの継承により、管理者はセッションを制限されたアクセスまたは追加の認証ポリシー（OTP や SAML など）に降格させることができます。
最後のアクションで検疫グループが存在しない場合、認証は失敗して終了します。
nFactor の EPA は、次のエンティティも使用します。
- LoginSchema : ログオンフォームの XML 表現。ログオンフォームの「ビュー」を定義し、「ファクタ」のプロパティも持っています。
- ポリシーラベルまたはポリシーファクター: 認証の特定の段階で試行されるポリシーの集まりです。
- 仮想サーバーラベル:仮想サーバーはポリシーラベルでもあります。つまり、ポリシーを仮想サーバーにバインドできます。ただし、仮想サーバーは、ユーザーアクセスのエントリポイントであるため、さまざまなポリシーラベルの集まりです。
- 次の要素: 特定の認証ポリシーが成功したときに適用されるポリシーラベル/要素を指定するために使用されます。
- NO_AUTHN ポリシー:アクションが常に成功する特別なポリシー。
- パススルーファクター:— ログインスキーマにビューが含まれていないポリシーラベル/ファクターです。これは、NetScaler ADCアプライアンスが、ユーザーの介入なしに指定された要素で認証を続行することを示します。
詳細については、 nFactor の概念、エンティティ、および用語を参照してください。
EPA ファクター相互排他性
EPA ファクターには、1 つ以上の EPA ポリシーが含まれています。EPA ポリシーがファクタにバインドされると、そのファクタに対する通常の認証ポリシーは使用できません。この制限は、最高のユーザーエクスペリエンスを提供し、エンドポイント分析を明確に分離することです。この規則の唯一の例外は NO_AUTHN ポリシーです。NO_AUTHN ポリシーは「障害時ジャンプ」をシミュレートするために使用される特別なポリシーであるため、EPA ファクタで許可されています。
EPA の実行
任意の要素（仮想サーバーファクタを含む）で、ログオンフォームを提供する前に、NetScaler ADCアプライアンスはファクタがEPA用に構成されているかどうかを確認します。その場合、EPA シーケンスがトリガーされるように、特定の応答をクライアント (UI) に送信します。このシーケンスでは、クライアントがクライアントデバイスのチェック式を要求し、結果を送信します。 ファクタ内のすべてのポリシーのクライアントデバイスチェック式は、クライアントに一度に送信されます。NetScaler ADCアプライアンスで結果が得られると、すべてのアクションの各式が順番に評価されます。EPA が成功する最初のアクションはその要素を終了し、defaultGroup (構成されている場合) はセッションに継承されます。NO_AUTHN ポリシーが検出された場合、それは自動成功と見なされます。nextFactor が指定されている場合、アプライアンスはそのファクタで続行します。それ以外の場合、認証は終了します。 この条件は、第1因子にも当てはまります。仮想サーバーで EPA の後に認証ポリシーファクタがない場合、認証は終了します。これは、EPA の後にユーザーに常にログインページが表示される従来のポリシーの動作とは異なります。 ただし、EPAポリシーが成功しない場合、NetScaler Gateway は、そのファクタまたはカスケードの最後のEPAポリシーに対して構成された検疫グループを検索します。最後のポリシーが検疫グループで構成されている場合、そのグループがセッションに追加され、NextFactor が検査されます。NextFactor が存在する場合、認証はその要素に進みます。それ以外の場合、認証は完了します。
定期的な EPA スキャンを nFactor 認証の要素として構成する
高度なポリシーインフラストラクチャを使用して、定期的な EPA スキャンを nFactor 認証の要素として設定できます。
注：
クラシックポリシーでは、定期的な EPA は
vpn session actionのセッションポリシーの一部として設定されていました。 以下のロジックは、nFactor 認証の要素として EPA スキャンを実装する例として使用されます。
- ユーザーがNetScaler Gateway 仮想IPに接続しようとしました。
- ユーザー名とパスワードフィールドを含むログインページがユーザーにレンダリングされ、ログイン資格情報が提供されます。これらの資格情報を使用して、LDAP または AD ベースの認証がバックエンドで実行されます。成功すると、EPA スキャンを承認するためのポップアップがユーザーに表示されます。
- ユーザーが承認すると、EPA スキャンが実行され、ユーザークライアント設定の成功または失敗に基づいて、アクセスが提供されます。
- スキャンが成功すると、EPA スキャンが定期的に実行され、設定されたデバイスチェック要件が満たされているかどうかが確認されます。
- このようなチェック中に EPA スキャンが失敗すると、セッションは終了します。
前提条件
次の設定が行われていると仮定します。
- VPN 仮想サーバ、ゲートウェイ、および認証仮想サーバの設定
- LDAP サーバの設定と関連付けられたポリシー。
次のセクションでは、必要なポリシーとポリシーラベルの設定、およびポリシーとポリシーラベルの認証プロファイルへのマッピングについて説明します。
CLI で
-
LDAP 認証の前に EPA スキャンを実行するアクションを作成し、EPA スキャンポリシーに関連付けます。
add authentication epaAction pre-ldap-epa-action -csecexpr "sys.client_expr ("proc_2_firefox")" add authentication Policy pre-ldap-epa-pol -rule true -action pre-ldap-epa-action <!--NeedCopy-->前述の式は、プロセス ‘Firefox’ が実行中かどうかをスキャンします。EPA クライアントは、スキャン表現の数字「2」で示されるように、2 分ごとにプロセスの存在を確認します。
-
EPA
pre-ldap-epa-labelスキャンのポリシーをホストするポリシーラベルを設定します。add authentication policylabel pre-ldap-epa-label -loginSchema LSCHEMA_INT <!--NeedCopy-->注：
LSCHEMA_INT はスキーマのない組み込みスキーマです (スキーマなし)。つまり、このステップではユーザーに追加の Web ページは表示されません。
-
ステップ 1 で設定したポリシーを、ステップ 2 で設定したポリシーラベルに関連付けます。これで認証メカニズムは完了です。
bind authentication policylabel pre-ldap-epa-label -policyName pre-ldap-epa-pol -priority 100 -gotoPriorityExpression END <!--NeedCopy--> -
LDAP アクションとポリシーを設定します。
add authentication ldapAction ldap-act -serverIP 10.106.103.60 -ldapBase "dc=cgwsanity,dc=net" -ldapBindDn user1@example.net -ldapBindDnPassword 1.cloud -ldapLoginName samAccountName -groupAttrName memberOf -subAttributeName CN -passwdChange ENABLED add authentication Policy ldap-pol -rule true -action ldap-act <!--NeedCopy--> -
SSO を有効にしたログインスキーマを作成します。
add authentication loginSchema ldap-schema -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuth.xml" -SSOCredentials Yes <!--NeedCopy--> -
LDAP
ldap-pol-label認証のポリシーをホストするポリシーラベルを設定します。add authentication policylabel ldap-pol-label -loginSchema ldap-schema <!--NeedCopy--> -
ステップ 5 で設定したログインスキーマを、ステップ 6 で設定したポリシーラベルにバインドします。
bind authentication policylabel ldap-pol-label -policyName ldap-pol -priority 100 -gotoPriorityExpression NEXT <!--NeedCopy--> -
LDAP 認証後に EPA スキャンを実行するアクションを作成し、EPA スキャンポリシーに関連付けます。
add authentication epaAction post-ldap-epa-action -csecexpr "sys.client_expr ("proc_2_chrome")" add authentication Policy post-ldap-epa-pol -rule true -action post-ldap-epa-action add authentication policylabel post-ldap-epa-label -loginSchema LSCHEMA_INT bind authentication policylabel post-ldap-epa-label -policyName post-ldap-epa-pol -priority 100 -gotoPriorityExpression <!--NeedCopy--> -
すべてをまとめて、
pre-ldap-epa-polポリシーを認証仮想サーバーに関連付けます。次のステップでは、ldap-pol-labelポリシーラベルを指してEPAスキャンを実行します。bind authentication vserver user.auth.test -policy pre-ldap-epa-pol -priority 100 -nextFactor ldap-pol-label -gotoPriorityExpression NEXT bind authentication policylabel ldap-pol-label -policyName ldap-pol -priority 100 -gotoPriorityExpression NEXT -nextFactor post-ldap-epa-label <!--NeedCopy-->
注：
- 複数のファクターとして設定された定期的な EPA では、定期的な EPA 設定による最新のファクターが考慮されます。
- 定期スキャンは EPA プラグインを使用してのみ実行でき、ブラウザでは実行できません。
- 最初の例では、EPA がスキャンでプロセス「Firefox」を検索する最初の要素です。
- EPA スキャンが成功すると、LDAP 認証が行われ、次の EPA スキャンが行われ、プロセス「Chrome」が検索されます。
- 複数の定期スキャンが異なるファクタとして設定されている場合は、最新のスキャンが優先されます。この場合、EPA プラグインは、ログインが成功してから 2 分ごとにプロセス「Chrome」をスキャンします。
GUI 上 (nFactor ビジュアライザーを使用)
GUI の nFactor ビジュアライザーを使用して、高度な EPA スキャンをファクターとして設定できます。次の例では、最初の要素として LDAP を使用し、次の要素として EPA を使用しています。
-
nFactor フローの 1 つ目のファクターを作成します。
-
[ セキュリティ] > [AAA アプリケーショントラフィック] > [nFactor ビジュアライザー] > [nFactor フロー ] に移動し、[ 追加] をクリックします
- + をクリックして nFactor フローを追加します。
- 係数を追加して [ 作成] をクリックします。
-
-
1 つ目の要素のログインスキーマとポリシーを作成します。
- 最初のファクタータイルで、[ スキーマの追加 ] をクリックしてログインスキーマを追加します。ドロップダウンリストから既存の認証ログインスキーマを選択するか、ログインスキーマを作成できます。
-
認証ログインスキーマを作成するには、「 追加」をクリックします。認証ログインスキーマの詳細については、「 nFactor 認証の設定」を参照してください。
-
[ ポリシーの追加 ] をクリックして LDAP ポリシーを追加します。LDAP ポリシーがすでに作成されている場合は、同じポリシーを選択できます。［追加］ をクリックします。
注:
LDAP ポリシーが作成されていない場合は、作成できます。「 ポリシーの選択」ドロップダウンリストの横にある「追加」ボタンをクリックします。「アクション 」フィールドで「LDAP」を選択します。認証 LDAP サーバの追加の詳細については、を参照してください
https://support.citrix.com/article/CTX123782。
-
次のファクターを作成し、それを最初のファクターに接続します。
- 緑色または赤色の「 + 」アイコンをクリックして、次の要素として EPA を追加します。
- 「 次の接続要素」ページで次の要素を作成します 。
- 「 スキーマの追加 」セクションを空白のままにすると、デフォルトではこのファクターにスキーマが適用されません。
-
次の要素に関するポリシーを追加してください。
- 「 ポリシーを追加 」をクリックして、認証後の EPA ポリシーとアクションを追加します。
- 既存のポリシーのリストから選択するか、ポリシーを作成できます。既存のポリシーから選択するには、「ポリシーの選択」 ドロップダウンリストからポリシーを選択し 、バインドの詳細を入力して、「 追加」をクリックします。
- ポリシーを作成するには、「 ポリシーの選択 」ドロップダウンリストの横にある「 追加 」ボタンをクリックします。
-
nFactor フローが完了したら、[ 完了] をクリックします。
-
nFactor フローを認証サーバーにバインドします。
- [ セキュリティ AAA-アプリケーショントラフィック] > [nFactor ビジュアライザー] > [nFactor フロー] に移動します。
- nFactor を選択し、[ 認証サーバーにバインド] をクリックします。
