チュートリアル:テーブルの継続認証の構成
テーブルの継続的認証ポリシーのエンドツーエンド構成と、構成変更によるユーザーへの影響について説明する手順。
始める前に
- 必要なロール: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 を構成する前に必要な事前作業を理解します。詳細については、「継続認証の事前作業」を参照してください。
手順
-
フォームの各フィールドに入力します。
表 : 1. 継続認証 フィールド 説明 ポリシー名 ポリシーの名前 説明 ポリシーの一般的な説明 リソースを選択 [テーブル] を選択します。 注:- この例では、[インシデント] テーブルが選択されています。要件に基づいて、テーブルをいくつでも選択できます。
- メタデータで選択されたテーブルにエラーが表示されます。メタデータテーブルへのアクセスを制限するとユーザーの構成アクセスに影響を与える可能性があるため、アクセスを実際に制限するかどうかを確認する必要があります。
- sys_properties、sys_continuous_auth_policy、sys_user テーブルは CA から除外され、CA ポリシー構成に追加できません。
注:CA ポリシーには、次のいずれかのログイン方法を使用できます。- SSO ベースのログイン：ID プロバイダーレコード内の [継続認証] タブでフィールドを指定し、ID プロバイダーレコードを [アクティブ] に設定します。
- 非 SSO ベースのログイン：デフォルトでは、継続認証構成を使用した ID プロバイダーがない場合、マルチファクター認証 (MFA) がログイン方法として使用されます。MFA プロパティがアクティブで、要件に基づいて構成されていることを確認します。MFA プロパティの詳細については、「マルチファクター認証システムプロパティ」を参照してください。
タスクの結果
構成に指定された詳細に基づいて、選択したテーブルまたはデータクラスのアクセス制御リスト (ACL) を使用して CA ポリシーが作成されます。作成された ACL の詳細を表示するには、ポリシーページで [ACL の表示 ] を選択します。
作成された CA ポリシーは、ポリシーを使用して保護したテーブル (ここでは、[インシデント] テーブル) にアクセスするための認証をユーザーに求めます。ユーザーは [認証] オプションを選択できます。
以下に基づいて認証を実行します。
- インスタンスへのログイン時にローカルログインを実行したユーザーが、ステップアップ認証のためにプラットフォーム MFA で表示されます。
- インスタンスへのログイン時に SSO ログイン (OIDC または SAML) を実行したユーザーが、再認証のために SSO で表示されます。
認証に成功すると、テーブルが表示されます。
これで、ユーザーのハイアシュアランスセッションが確立されました。ハイアシュアランスセッションは、ハイアシュアランスセッションの長さ (glide.zta.high_assurance.session.timeout) システムプロパティに制限されます。ハイアシュアランスセッション時間がプロパティの長さを超えると、ユーザーは再認証またはステップアップ認証を求められます。