チュートリアル:テーブルの継続認証の構成
テーブルの継続的認証ポリシーのエンドツーエンド構成と、構成変更によるユーザーへの影響について説明する手順。
始める前に
- 必要なロール:admin (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) システムプロパティに制限されます。ハイアシュアランスセッション時間がプロパティ長を超えると、ユーザーは再認証またはステップアップ認証を求められます。