継続認証の構成

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:3分
  • 継続的認証 (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 ポリシーは、データクラスまたはテーブルに対して構成できます。

    手順

    1. 移動先 すべて > 継続認証.
    2. [ポリシー] タブを選択します。
    3. [新規] を選択します。
    4. フォームの各フィールドに入力します。
      表 : 1. 継続認証
      フィールド 説明
      ポリシー名 ポリシーの名前
      説明 ポリシーの一般的な説明
      リソースを選択 オプション:
      • データクラス。データクラスを作成し、CA ポリシー構成に使用できます。
        注:
        データクラスの作成方法の詳細については、「 データ分類」を参照してください。
      • テーブル
      注:
      • メタデータで選択されたテーブルにエラーが表示されます。
      • メタデータテーブルへのアクセスを制限するとユーザーの構成アクセスに影響を与える可能性があるため、アクセスを実際に制限するかどうかを確認する必要があります。
      • sys_propertiessys_continuous_auth_policysys_user テーブルは CA から除外され、CA ポリシー構成に追加できません。
      CA ポリシーレコード
      注:
      CA ポリシーには、次のいずれかのログイン方法を使用できます。
      • SSO ベースのログイン:ID プロバイダーレコード内の [継続認証] タブでフィールドを指定し、ID プロバイダーレコードを [アクティブ] に設定します。継続認証 - タブ情報

        ID プロバイダー構成の詳細については、「OIDC」および「SAML」を参照してください。

      • 非 SSO ベースのログイン:デフォルトでは、継続認証構成を使用した ID プロバイダーがない場合、マルチファクター認証 (MFA) がログイン方法として使用されます。MFA プロパティがアクティブで、要件に基づいて構成されていることを確認します。MFA プロパティの詳細については、「マルチファクター認証システムプロパティ」を参照してください。
    5. [保存してアクティブ化] を選択します。

    タスクの結果

    構成に指定された詳細に基づいて、選択したテーブルまたはデータクラスのアクセス制御リスト (ACL) を使用して CA ポリシーが作成されます。作成された ACL の詳細を表示するには、ポリシーページで [ACL の表示 ] を選択します。

    CA ACL の詳細

    作成された CA ポリシーは、次のシナリオに基づいて、ポリシーを使用して保護したテーブルまたはデータクラスにアクセスするための認証をユーザーに求めます。

    • インスタンスへのログイン時にローカルログインを実行したユーザーが、ステップアップ認証のためにプラットフォーム MFA で表示されます。
      MFA-SMS

      注:
      ユーザーが認証に最近使用した MFA 要素が表示されます。
    • インスタンスへのログイン時に SSO ログイン (OIDC または SAML) を実行したユーザーが、再認証のために SSO で表示されます。
      SSO - 画面

    これで、ユーザーのハイアシュアランスセッションが確立されました。ハイアシュアランスセッションは、ハイアシュアランスセッションの長さ (glide.zta.high_assurance.session.timeout) システムプロパティに制限されます。ハイアシュアランスセッション時間がプロパティの長さを超えると、ユーザーは再認証またはステップアップ認証を求められます。

    テーブルまたはデータの継続認証のエンドツーエンド構成の詳細については、以下を参照してください。