継続認証の構成
継続的認証 (CA) ポリシーを構成して、保護されているリソースへのアクセスが試行された場合にユーザーを再認証します。
始める前に
- 必要なロール:ca_admin注:ロールを ca_admin に昇格させる必要があります。
- ライセンスが必要な CA を選択するには、Zero Trust - Continuous Authentication (
com.snc.zero_trust_continuous_authentication) をインストールする必要があります。 - 継続認証 (glide.zta.continuous_authentication.enabled) システムプロパティを有効にします。詳細については、「システムプロパティ」を参照してください。
- Integration - Multiple Provider Single Sign-On Installer (com.snc.integration.sso.multi.installer) プラグインをアクティブ化します。
- インスタンスの CA を構成する前に必要な事前作業を理解します。詳細については、「継続認証の事前作業」を参照してください。
- CA ポリシーは、データクラスまたはテーブルに対して構成できます。
手順
タスクの結果
構成に指定された詳細に基づいて、選択したテーブルまたはデータクラスのアクセス制御リスト (ACL) を使用して CA ポリシーが作成されます。作成された ACL の詳細を表示するには、ポリシーページで [ACL の表示 ] を選択します。
作成された CA ポリシーは、次のシナリオに基づいて、ポリシーを使用して保護したテーブルまたはデータクラスにアクセスするための認証をユーザーに求めます。
- インスタンスへのログイン時にローカルログインを実行したユーザーが、ステップアップ認証のためにプラットフォーム MFA で表示されます。注:ユーザーが認証に最近使用した MFA 要素が表示されます。
- インスタンスへのログイン時に SSO ログイン (OIDC または SAML) を実行したユーザーが、再認証のために SSO で表示されます。
これで、ユーザーのハイアシュアランスセッションが確立されました。ハイアシュアランスセッションは、ハイアシュアランスセッションの長さ (glide.zta.high_assurance.session.timeout) システムプロパティに制限されます。ハイアシュアランスセッション時間がプロパティの長さを超えると、ユーザーは再認証またはステップアップ認証を求められます。
テーブルまたはデータの継続認証のエンドツーエンド構成の詳細については、以下を参照してください。