如果客户端尝试以来自本地连接的 dbadmin（即与数据库位于相同的节点上）身份进行身份验证：
- 如果 dbadmin 没有密码，Vertica 会使用 trust 方法对客户端进行身份验证。
- 如果 dbadmin 具有密码，Vertica 会使用 hash 方法对客户端进行身份验证。
如果客户端尝试以没有密码的数据库用户身份进行身份验证，且定义的唯一身份验证记录为默认记录，则 Vertica 会使用 trust 方法对客户端进行身份验证。有关详细信息，请参阅隐式身份验证。
如果客户端尝试以具有密码和身份验证记录的用户身份进行身份验证，则 Vertica 会尝试使用该记录对客户端进行身份验证。如果某个用户或角色存在多个身份验证记录，Vertica 将选择优先级最高的记录。

注意
通常情况下，如果未使用 CREATE AUTHENTICATION 定义自定义身份验证记录，则默认身份验证记录将生效（除非它们被 dbadmin 故意删除），且客户端将通过 password 方法进行身份验证。
如果客户端使用所选身份验证方法验证失败，且身份验证 fallthrough 已启用，Vertica 将尝试使用下一个优先级最高的身份验证方法来对客户端进行身份验证。否则，客户端将被拒绝。
除此之外，如果身份验证记录不存在，且默认身份验证记录已被删除；则所有用户（来自本地连接的 dbadmin 除外）均不能访问数据库。

身份验证管理

具有 DBADMIN 角色的用户可以执行以下身份验证任务：

创建身份验证记录。
从数据库中删除身份验证记录。
定义以下身份验证方法所需的参数：
- LDAP
- Ident
- Kerberos
- OAuth
向用户授予（分配）或撤销身份验证记录。
使用 ALTER AUTHENTICATION：
- 启用/禁用身份验证方法。
- 定义要在尚未向用户分配特定身份验证方法时使用的默认身份验证方法。要分配其作为默认身份验证方法，请使用 GRANT（身份验证）将其授予 PUBLIC 角色。
- 更改身份验证记录优先级。
- 启用 fallthrough 身份验证。

1.1 - 默认身份验证记录

Vertica 会自动创建以下默认身份验证记录并将其授予 public 角色。这些记录具有最低的优先级 (-1)，因此用户创建的身份验证记录将优先于这些默认记录：

=> SELECT auth_name,is_auth_enabled,auth_host_type,auth_method,auth_priority,is_fallthrough_enabled FROM client_auth;
         auth_name         | is_auth_enabled | auth_host_type | auth_method | auth_priority | is_fallthrough_enabled
---------------------------+-----------------+----------------+-------------+---------------+------------------------
 default_hash_network_ipv4 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_network_ipv6 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_local        | True            | LOCAL          | PASSWORD    |            -1 | False
(3 rows)

注意

请勿对自定义身份验证记录使用 password 方法。如果要对自定义身份验证记录使用基于密码的身份验证，请改用 hash。

如果未定义身份验证记录（且默认身份验证记录已被删除），则只有 dbadmin 和没有密码的用户可以访问数据库。有关详细信息，请参阅隐式身份验证。

1.2 - 配置客户端身份验证

您可以限制数据库用户与身份验证记录之间的连接方式。Vertica 数据库使用客户端身份验证方法确立发出连接请求的客户端的身份，并确定是否授权该客户端使用提供的凭据从其主机地址连接到 Vertica 数据库。

基本身份验证配置工作流

通常情况下，配置客户端身份验证的工作流如下所示：

创建身份验证记录。身份验证记录在创建后会自动启用。有关详细信息，请参阅创建身份验证记录。
将身份验证记录授予指定用户或角色。

要查看现有的身份验证记录，请查询系统表 CLIENT_AUTH。

用于客户端身份验证的 IPv4 和 IPv6

Vertica 支持客户端使用 IPv4 或 IPv6 协议连接到数据库服务器。数据库服务器之间的内部通信必须一致地使用一个地址系列（IPv4 或 IPv6）。但是，客户端可以从任一类型的 IP 地址连接到数据库。

如果客户端将从 IPv4 和 IPv6 进行连接，必须创建两种身份验证方法，每种方法对应一种地址。任何使用 HOST 身份验证的身份验证方法都需要 IP 地址。

例如，第一个语句允许用户从任何 Ipv4 地址连接。第二个语句允许用户从任何 IPv6 地址连接：

=> CREATE AUTHENTICATION <name> METHOD 'gss' HOST '0.0.0.0/0'; --IPv4
=> CREATE AUTHENTICATION <name> METHOD 'gss' HOST '::/0'; --IPv6

如果在 URL 中使用字面量型 Ipv6 地址，必须将 Ipv6 地址括在方括号中，如以下示例中所示：

=> ALTER AUTHENTICATION Ldap SET host='ldap://[1dfa:2bfa:3:45:5:6:7:877]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[fdfb:dbfa:0:65::177]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[fdfb::177]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[::1]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[1dfa:2bfa:3:45:5:6:7:877]:5678';

如果您使用多节点群集，(HOST, HOST TLS, HOST NO TLS) 中的任何 IP/网络掩码设置都必须匹配群集中的所有节点。此设置允许数据库所有者对群集中的每个节点进行身份验证和管理。例如，指定 10.10.0.8/30 允许 CIDR 地址范围 10.10.0.8–10.10.0.11。

有关 IPv6 地址的详细信息，请参阅 RFC 1924 和 RFC 2732。

支持的客户端身份验证方法

Vertica 支持以下客户端身份验证方法：

trust：用户可以使用有效的用户名（即无需密码）进行身份验证。
reject：拒绝连接尝试。
hash：用户必须提供有效的用户名和密码。有关详细信息，请参阅哈希身份验证。
gss：授权使用 MIT Kerberos 实现连接到 Vertica 的客户端。密钥分发中心 (KDC) 必须使用 GSS-API 支持 Kerberos 5。非 MIT Kerberos 实施必须使用 GSS-API。有关详细信息，请参阅Kerberos 身份验证。
ident：根据 Ident 服务器中的用户名对客户端进行身份验证。有关详细信息，请参阅Ident 身份验证。
ldap：使用 LDAP 或 Active Directory 服务器验证客户端及其用户名和密码。有关详细信息，请参阅LDAP 身份验证。
tls：对提供具有指定有效数据库用户名的通用名称 (CN) 证书的客户端进行身份验证。必须为相互模式 TLS 配置 Vertica，才能使用此方法。有关详细信息，请参阅 TLS 身份验证
oauth：使用访问令牌对客户端进行身份验证。有关详细信息，请参阅OAuth 2.0 身份验证。

本机和主机身份验证

您可以将客户端身份验证方法定义为：

本机：与数据库进行本机连接。
主机：从其他主机与数据库进行远程连接，每个主机都有自己的 IPv4 或 IPv6 地址和主机参数。有关详细信息，请参阅上面的用于客户端身份验证的 IPv4 和 IPv6。

某些身份验证方法只能指定为本机或主机，如下表中所列：

对关联的用户和角色进行身份验证

Vertica 支持创建关联的用户和角色，您可以将 ROLE2 权限授予 ROLE1。ROLE1 中的所有用户使用分配给 ROLE2 的相同身份验证。例如：

=> CREATE USER user1;
=> CREATE ROLE role1;
=> CREATE ROLE role2;
=> CREATE AUTHENTICATION h1 METHOD 'hash' LOCAL;
=> GRANT AUTHENTICATION h1 to role2;
=> GRANT role2 to role1;
=> GRANT role1 to user1;

上面示例中的用户和角色关联可以表示为以下方式：

auth1 -> role2 -> role1 -> user1

在此示例中，由于 role2 权限已授予 role1，您仅需要对 role2 授予身份验证，这样就可以对 role1 启用。

1.3 - Fallthrough 身份验证

通常情况下，如果用户使用所选的第一个身份验证记录验证失败，该用户将被拒绝。但是，可以指定某些身份验证方法在失败时“贯穿”到优先级较低的身份验证记录。当使用多个 LDAP 搜索属性时，这可能很有用。

对于新记录，默认情况下禁用身份验证 fallthrough。

身份验证方法兼容性

下表显示了每种身份验证方法与 fallthrough 身份验证的兼容性。值“yes”表示列中的方法可以贯穿并验证其贯穿到的行方法。值“no”表示您无法贯穿到该方法，且身份验证将结束。

值“-”（破折号）表示虽然可以贯穿，但其没有实际意义。例如，一个 hash 身份验证记录可以贯穿到另一个 hash 身份验证记录，但身份验证始终会失败，因为您无法贯穿到正确的密码：

例如，假设将以下启用了 fallthrough 的身份验证记录授予用户 Bob：

=> CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0' FALLTHROUGH;

此外，Bob 具有 public 角色，因此具有默认身份验证记录：

=> SELECT auth_name,is_auth_enabled,auth_host_type,auth_method,auth_priority,is_fallthrough_enabled FROM client_auth;
         auth_name         | is_auth_enabled | auth_host_type | auth_method | auth_priority | is_fallthrough_enabled
---------------------------+-----------------+----------------+-------------+---------------+------------------------
 default_hash_network_ipv4 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_network_ipv6 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_local        | True            | LOCAL          | PASSWORD    |            -1 | False
(3 rows)

如果从远程地址发起连接的 Bob 使用 v_tls_auth 验证失败，Vertica 会尝试使用下一个（按优先级顺序）身份验证记录 default_hash_network_ipv4 对其进行身份验证。

记录身份验证失败

只有当所有授予的身份验证记录都失败，导致用户被拒绝时，才会记录登录失败。只会记录最后一个失败。

例如，假设一个用户被授予 tls 和 password 两个身份验证记录，并且 tls 记录可以贯穿到 password 记录。

如果用户使用 tls 记录和 password 记录均验证失败，则只会在 LOGIN_FAILURES 中记录 password 失败。

但是，如果用户使用 tls 记录验证失败，但使用 password 记录验证成功，则不会在 LOGIN_FAILURES 中记录失败。因为用户在记录链的末尾没有被拒绝。

示例

要在新的身份验证记录上启用 fallthrough，请使用 CREATE AUTHENTICATION：

=> CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0' FALLTHROUGH;

要在现有身份验证记录上切换 fallthrough，请使用 ALTER AUTHENTICATION：

=> ALTER AUTHENTICATION v_tls_auth NO FALLTHROUGH; -- disable
=> ALTER AUTHENTICATION v_tls_auth FALLTHROUGH; -- enable

1.4 - 隐式身份验证

Vertica 为 dbadmin 和没有密码的用户保留隐式的（即不反映在 CLIENT_AUTH 系统表中）身份验证记录。这些记录不能删除。

对于 dbadmin 用户：

如果满足以下所有条件，则使用 trust 方法：
- dbadmin 没有密码。
- 连接是本地的（即来自 Vertica 节点）。
如果满足以下所有条件，则使用 hash 方法：
- dbadmin 具有密码。
- 连接是本地的（即来自 Vertica 节点）。

对于非 dbadmin 用户，如果满足以下所有条件，则使用 trust 方法：

用户没有密码。
未启用自定义（即非默认）身份验证方法。

1.5 - Dbadmin 身份验证访问

Dbadmin 用户必须随时可访问数据库。Vertica 自动确保客户端可以以来自本地连接的 dbadmin 身份进行身份验证。

如果您需要以来自远程连接的 dbadmin 身份进行身份验证，则 dbadmin 必须具有密码。您可以使用以下方法：

使用 fallthrough 身份验证。
创建特定于 dbadmin 的自定义身份验证方法。

通过本地连接进行身份验证

您始终可以以来自本地连接的 dbadmin 身份隐式进行身份验证。这些特定于 dbadmin 的身份验证记录是隐式记录，因此它们不会列在 CLIENT_AUTH 系统表中，也不能删除。

如果 dbadmin 用户没有密码，Vertica 会使用 trust 方法对其进行身份验证。否则，Vertica 会使用 password 方法对其进行身份验证。

在此示例中，dbadmin 没有密码并通过本地连接连接到 Vertica：

=> SELECT authentication_method, client_authentication_name FROM vs_sessions;
 authentication_method | client_authentication_name
-----------------------+----------------------------
 ImpTrust              | default: Implicit Trust

通过远程连接进行身份验证

Fallthrough 身份验证

Vertica 自动创建以下身份验证记录并将其授予 public 角色（有关详细信息，请参阅客户端身份验证）：

=> SELECT auth_name,is_auth_enabled,auth_host_type,auth_method,auth_priority,is_fallthrough_enabled FROM client_auth;
         auth_name         | is_auth_enabled | auth_host_type | auth_method | auth_priority | is_fallthrough_enabled
---------------------------+-----------------+----------------+-------------+---------------+------------------------
 default_hash_network_ipv4 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_network_ipv6 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_local        | True            | LOCAL          | PASSWORD    |            -1 | False
(3 rows)

这些默认身份验证记录确保所有具有 public 角色的用户（包括 dbadmin）都可以访问数据库，前提是任何自定义身份验证记录都设置为贯穿（默认情况下禁用）到默认记录。

例如，下面的 ldap 身份验证启用了 fallthrough，因此如果 LDAP 服务器关闭，用户仍然可以使用 password 身份验证（由默认记录定义）进行身份验证。

=> CREATE AUTHENTICATION ldap1 METHOD 'ldap' LOCAL FALLTHROUGH;
=> ALTER AUTHENTICATION ldap1 SET host='ldap://localhost:5389',
    binddn='cn=Manager,dc=example,dc=com',
    bind_password='password',
    basedn='ou=dev,dc=example,dc=com',
    search_attribute='cn';

自定义身份验证记录

特定于 dbadmin 的身份验证记录应：

使用 hash 身份验证方法（以便身份验证不依赖于某些外部服务）。
具有较高的优先级（例如 10,000），以便它可以优先于所有其他身份验证记录。

以下示例创建了一个身份验证记录 v_dbadmin_hash 并将其授予 dbadmin 用户。hash 方法表示 dbadmin 在登录时必须提供密码。HOST '0.0.0.0/0' 访问方法表示 dbadmin 可以从任何 IPv4 地址进行远程连接：

=> CREATE AUTHENTICATION v_dbadmin_hash METHOD 'hash' HOST '0.0.0.0/0';
=> ALTER AUTHENTICATION v_dbadmin_hash PRIORITY 10000;
=> GRANT AUTHENTICATION v_dbadmin_hash TO dbadmin;

如果您想以来自本地连接的 dbadmin 身份进行身份验证，但想使用具有 HOST 访问方法的身份验证记录，请指定包含数据库主机名或 IP 地址的 --host 选项：

$ vsql database_name user --host hostname_or_ip;

1.6 - 创建身份验证记录

您可以使用 vsql 管理客户端身份验证记录。您必须以超级用户身份连接到数据库。

重要

您不能使用管理工具 (Administration Tools) 修改客户端身份验证记录。在管理工具界面中可以修改 vertica.conf 文件的内容。但是，Vertica 会忽略该文件中存储的客户端身份验证信息。

创建身份验证记录，并指定：
- 身份验证记录的名称。
- 身份验证方法，为以下之一：
  - trust：用户可以使用有效的用户名（即无需密码）进行身份验证。
  - reject：拒绝连接尝试。
  - hash：用户必须提供有效的用户名和密码。有关详细信息，请参阅哈希身份验证。
  - gss：授权使用 MIT Kerberos 实现连接到 Vertica 的客户端。密钥分发中心 (KDC) 必须使用 GSS-API 支持 Kerberos 5。非 MIT Kerberos 实施必须使用 GSS-API。有关详细信息，请参阅Kerberos 身份验证。
  - ident：根据 Ident 服务器中的用户名对客户端进行身份验证。有关详细信息，请参阅Ident 身份验证。
  - ldap：使用 LDAP 或 Active Directory 服务器验证客户端及其用户名和密码。有关详细信息，请参阅LDAP 身份验证。
  - tls：对提供具有指定有效数据库用户名的通用名称 (CN) 证书的客户端进行身份验证。必须为相互模式 TLS 配置 Vertica，才能使用此方法。有关详细信息，请参阅 TLS 身份验证
  - oauth：使用访问令牌对客户端进行身份验证。有关详细信息，请参阅OAuth 2.0 身份验证。
- 访问方法，为以下之一，这些方法用于指定允许的连接类型：
  - LOCAL：对尝试从数据库运行所在的相同节点进行连接的用户或应用程序进行身份验证。
  - HOST：对尝试从 IPv4 或 IPv6 地址不同于数据库的节点进行连接的用户或应用程序进行身份验证。您可以使用 TLS 或 NO TLS 分别指定加密连接或明文连接。
- 是否启用 Fallthrough 身份验证（默认情况下禁用）。
将身份验证记录授予用户或角色。

示例

以下示例显示了如何创建身份验证记录。

创建身份验证方法 localpwd，以便对尝试使用密码从本地主机登录的用户进行身份验证：

=> CREATE AUTHENTICATION localpwd METHOD 'hash' LOCAL;

创建身份验证方法 v_ldap，以便使用 LDAP over TLS 对从 IPv4 地址为 10.0.0.0/23 的主机登录的用户进行身份验证：

=> CREATE AUTHENTICATION v_ldap METHOD 'ldap' HOST TLS '10.0.0.0/23';

创建身份验证方法 v_kerberos，以便对尝试从网络 2001:0db8:0001:12xx 中的任何主机进行连接的用户进行身份验证：

=> CREATE AUTHENTICATION v_kerberos METHOD 'gss' HOST '2001:db8:1::1200/56';

以下身份验证记录v_oauth 使用 OAuth 令牌（而不是用户名和密码）对来自任何 IP 地址的用户进行身份验证，并且使用以下参数。身份提供者是 Keycloak 18.0.0：

client_id：机密客户端 vertica 在 Keycloak 中注册。
client_secret：客户端密钥，由 Keycloak 生成。
discovery_url：也称为 OpenID 提供者配置文档，这是包含有关身份提供者的配置和端点的信息的端点。

=> CREATE AUTHENTICATION v_oauth METHOD 'oauth' HOST '0.0.0.0/0'
=> ALTER AUTHENTICATION v_oauth SET client_id = 'vertica';
=> ALTER AUTHENTICATION v_oauth SET client_secret = 'client_secret';
=> ALTER AUTHENTICATION v_oauth SET discovery_url = 'https://203.0.113.1:8443/realms/myrealm/.well-known/openid-configuration';
=> ALTER AUTHENTICATION v_oauth SET introspect_url = 'https://203.0.113.1:8443/realms/myrealm/protocol/openid-connect/token/introspect';

例如，要拒绝所有纯文本的客户端连接，按如下所示指定 reject 身份验证方法和 HOST NO TLS 访问方法：

=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '0.0.0.0/0';  --IPv4
=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '::/0';       --IPv6

另请参阅

1.7 - 修改身份验证记录

若要修改现有身份验证记录，您必须首先连接到数据库。以下示例显示了如何对身份验证记录进行更改。有关详细信息，请参阅ALTER AUTHENTICATION。

重命名身份验证记录

将 v_kerberos 身份验证方法重命名为 K5 并启用。所有与 v_kerberos 身份验证方法关联的用户现在都与授予的 K5 方法关联。

=> ALTER AUTHENTICATION v_kerberos RENAME TO K5 ENABLE;

指定身份验证方法的优先级

对 K5 身份验证指定优先级 10：

=> ALTER AUTHENTICATION K5 PRIORITY 10;

有关详细信息，请参阅身份验证记录优先级。

更改参数

将 system_users 身份验证的 ident1 参数设置为 root：

=> CREATE AUTHENTICATION ident1 METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION ident1 SET system_users='root';

更改 IP 地址并为名为 Ldap1 的 LDAP 身份验证方法指定参数。

在此示例中，为 LDAP 服务器指定绑定参数。Vertica 将连接到对 Vertica 客户端进行身份验证的 LDAP 服务器。如果身份验证成功，Vertica 将在指定 LDAP 服务器上对授予了 Ldap1 身份验证方法的任何用户进行身份验证：

=> CREATE AUTHENTICATION Ldap1 METHOD 'ldap' HOST '172.16.65.196';

=> ALTER AUTHENTICATION Ldap1 SET host='ldap://172.16.65.177',
   binddn_prefix='cn=', binddn_suffix=',dc=qa_domain,dc=com';

更改 IP 地址，并为名为 Ldap1 的 LDAP 身份验证方法指定参数。假设 Vertica 没有足够的信息为尝试进行身份验证的用户创建可分辨名称 (DN)。因此，在这种情况下，必须指定使用 LDAP 搜索和捆绑：

=> CREATE AUTHENTICATION LDAP1 METHOD 'ldap' HOST '172.16.65.196';

=> ALTER AUTHENTICATION Ldap1 SET host='ldap://172.16.65.177',
basedn='dc=qa_domain,dc=com',binddn='cn=Manager,dc=qa_domain,
dc=com',search_attribute='cn',bind_password='secret';

更改关联方法

将 localpwd 身份验证从信任更改为哈希：

=> CREATE AUTHENTICATION localpwd METHOD 'trust' LOCAL;
=> ALTER AUTHENTICATION localpwd METHOD 'hash';

ALTER AUTHENTICATION 可以验证您输入的参数。如果出现错误，会禁用您尝试修改的身份验证方法。

使用管理工具

使用管理工具 (Administration Tools) 的优势为：

您无需连接到数据库。
编辑器会验证记录的格式正确。
编辑器会维护记录，以便于您在稍后编辑。

注意

必须重新启动数据库才能实施更改。

有关使用管理工具创建和编辑身份验证记录的信息，请参阅创建身份验证记录。

删除身份验证记录

若要删除身份验证记录，请使用 DROP AUTHENTICATION。若要使用此方法，必须连接到数据库。

若要删除 md5_auth 的身份验证记录，请使用以下命令：

=> DROP AUTHENTICATION md5_auth;

若要删除一个已授予用户的方法的身份验证记录，请使用 CASCADE 关键字：

=> CREATE AUTHENTICATION localpwd METHOD 'password' LOCAL;
=> GRANT AUTHENTICATION localpwd TO jsmith;
=> DROP AUTHENTICATION localpwd CASCADE;

另请参阅

1.8 - 身份验证记录优先级

每个身份验证记录都分配了优先级。如果用户获授多个身份验证记录，Vertica 会尝试使用优先级最高的身份验证记录对用户进行身份验证，并在身份验证失败时拒绝该用户。

如果启用身份验证 fallthrough（默认情况下禁用），当所选身份验证记录失败时，Vertica 将尝试使用下一个优先级最高的记录对用户进行身份验证。有关 fallthrough 身份验证的详细信息，请参阅 Fallthrough 身份验证。

确定身份验证优先级

以下因素会影响身份验证记录的优先级，如 CLIENT_AUTH 系统表中所示：

=> SELECT auth_name, auth_method, auth_priority, method_priority, address_priority FROM client_auth;
   auth_name   | auth_method | auth_priority | method_priority | address_priority
---------------+-------------+---------------+-----------------+------------------
 ldap_auth     | LDAP        |             5 |               5 |               96
 hash_auth     | HASH        |             5 |               2 |              126
 tls_auth      | TLS         |             0 |               5 |               96
 oauth_auth    | OAUTH       |             0 |               5 |               96
 gss_auth      | GSS         |             0 |               5 |               96
 trust_auth    | TRUST       |             0 |               0 |               96
 reject_auth   | REJECT      |             0 |              10 |               96
(7 rows)

注意

值越大表示优先级越高。例如：

优先级 10 比优先级 5 高。
优先级 0 为最低的值。

优先级按层级划分并按重要性顺序列出；如果在某个优先级层级上的优先级相同，Vertica 会检查下一个优先级层级。例如，如果用户同时拥有 ldap 和 hash 身份验证记录，且 auth_priority 均为 5，Vertica 将尝试使用 ldap 身份验证记录，因为其 method_priority 值更大：

auth_priority：使用 ALTER AUTHENTICATION 显式设置的优先级（默认值：0）。
method_priority：特定于身份验证方法的优先级。这些优先级如下所示：
- trust：0
- hash：2
- ldap：5
- tls：5
- oauth：5
- gss：5
- reject：10
address_priority： HOST [ TLS | NO TLS ] 'host-ip-address' 中指定的 IP 地址的优先级。此优先级由地址的网络掩码大小决定；0 越少表示越具体，因此优先级越高。LOCAL 具有最低的优先级：0。

设置身份验证优先级

要设置身份验证优先级：

=> ALTER AUTHENTICATION authentication_name PRIORITY value;

另请参阅

1.9 - 查看有关客户端身份验证记录的信息

有关您为数据库配置的客户端身份验证记录的信息，请查询 V_CATALOG 架构中的以下系统表：

要确定用于特定用户会话的客户端身份验证背后的详细信息，请查询 V_MONITOR 架构中的以下表：

1.10 - 启用和禁用身份验证方法

在创建身份验证方法后，Vertica 会将其存储在编录中并自动启用该方法。要启用或禁用身份验证方法，请使用 ALTER AUTHENTICATION 语句。要使用这一方法，必须连接至数据库。

如果身份验证方法尚未启用，Vertica 则无法用它来对试图连接数据库的用户和客户端进行身份验证。

要启用身份验证方法：

ALTER AUTHENTICATION v_kerberos ENABLE;

要禁用此身份验证方法：

ALTER AUTHENTICATION v_kerberos DISABLE;

另请参阅

1.11 - 授予和撤销身份验证方法

在 Vertica 能够通过某一身份验证方法验证某一用户或客户之前，您必须首先使用 GRANT（身份验证）将身份验证方法与需要使用该方法的用户或角色进行关联。当该用户或角色不再需要使用该方法连接到 Vertica 时，您可以使用 REVOKE AUTHENTICATION 取消该身份验证方法与用户的关联。

授予身份验证方法

您可以将身份验证方法授予特定用户或角色。您也可以通过向 PUBLIC 授予某一身份验证方法来指定默认身份验证方法，如以下示例中所示。

将 v_ldap 身份验证与用户 jsmith 关联：
```
=> GRANT AUTHENTICATION v_ldap TO jsmith;
```

将 v_gss 身份验证与角色 DBprogrammer 关联：


=> CREATE ROLE DBprogrammer;
=> GRANT AUTHENTICATION v_gss TO DBprogrammer;

将客户端身份验证方法 v_localpwd 与角色 PUBLIC 关联，默认情况下会被分配给所有用户：
```
=> GRANT AUTHENTICATION v_localpwd TO PUBLIC;
```

撤销身份验证方法

如果您不想再使用指定的身份验证方法对用户或客户进行身份验证，请使用以下示例中的 REVOKE（身份验证）语句。

从用户 jsmith 撤销 v_ldap 身份验证：

=> REVOKE AUTHENTICATION v_ldap FROM jsmith;

从角色 DBprogrammer 撤销 v_gss 身份验证：

=> REVOKE AUTHENTICATION v_gss FROM DBprogrammer;

撤销 localpwd 作为默认客户端身份验证方法：
```
=> REVOKE AUTHENTICATION localpwd FROM PUBLIC;
```

1.12 - 隐藏数据库用户名

如果要对发起连接的客户端的某些数据库用户名进行保密，且您的身份验证记录不使用 Fallthrough 身份验证，则这两个用户组必须共享相同的身份验证方法（不一定是相同的身份验证记录）：

用户名必须保密的用户。
具有 PUBLIC 角色的用户。

如果您的身份验证记录使用 fallthrough，则对于私密用户和 PUBLIC 角色，请确保身份验证链中提示输入密码的第一个身份验证方法相同。以下方法将提示输入密码：

满足此条件的一种简单方法是使用相同的方法为两个组复制 fallthrough 链。例如，对于私密用户和 PUBLIC 角色，有效的身份验证链均为 tls > ldap。

对于私密用户，另一个有效的配置将为 tls > ldap > hash，而对于 PUBLIC，则为 ldap。

1.13 - 哈希身份验证

hash 身份验证方法使用密码对用户进行身份验证。

通常，您应该更喜欢其他身份验证方法而不是 hash。

1.13.1 - 密码哈希算法

注意

Vertica 强烈建议您使用 SHA-512 进行 hash 身份验证。

Vertica 不存储 hash 身份验证方法的用户密码。相反，Vertica 存储密码的哈希值。哈希算法由两个参数决定：

系统级别配置参数 SecurityAlgorithm：

=> ALTER DATABASE DEFAULT SET PARAMETER SecurityAlgorithm = 'hashing_algorithm';

用户级别参数 SECURITY_ALGORITHM：

=> ALTER USER username SECURITY_ALGORITHM 'hashing_algorithm' IDENTIFIED BY 'new_password';

系统级别参数 SecurityAlgorithm 可以具有以下值：

SHA512 （默认值）
MD5

用户级别参数 SECURITY_ALGORITHM 可以具有以下值。非 NONE 值将优于系统级别参数：

NONE （默认使用通过系统级别参数 SecurityAlgorithm 指定的算法）
SHA512
MD5

注意
如果用户的密码使用 MD5 进行了哈希处理，则您不能使用 ALTER USER 更改其用户名。

用户的 EFFECTIVE_SECURITY_ALGORITHM 由系统级别参数和用户级别参数两者决定。如果将用户级别参数设置为 NONE，则系统级别参数的算法将作为有效的安全算法。您可以通过将用户级别参数设置为非 NONE 值来覆盖特定用户的系统级别参数。

您可以通过查询系统表 PASSWORD_AUDITOR 查看这些参数及其对每个用户的影响。

下表显示了系统级别参数和用户级别参数的各种组合以及每种组合的有效安全算法。

FIPS 模式将有效的安全算法强制设置为 SHA-512。

1.13.2 - 配置哈希身份验证

hash 身份验证方法允许用户使用密码进行身份验证。

Vertica 将存储密码的哈希值（默认为 SHA-512），而不是密码本身。有关详细信息，请参阅密码哈希算法。

使用 hash 方法创建身份验证记录。身份验证记录在创建后会自动启用。例如，要为从 IP 地址 192.0.2.0/24 登录的用户创建身份验证记录 v_hash：
```
=> CREATE AUTHENTICATION v_hash METHOD 'hash' HOST '192.0.2.0/24';
```
使用 GRANT 语句将 v_hash 身份验证方法与所需的用户或角色关联：
```
=> GRANT AUTHENTICATION v_hash to user1, user2, ...;
```

1.13.3 - 密码

向用户分配密码以允许用户使用密码保护连接至数据库。用户提供正确的密码后，将出现到数据库的连接。

Vertica 根据每个用户的 EFFECTIVE_SECURITY_ALGORITHM 对密码进行哈希处理。但是，经过哈希处理的密码采用明文形式从客户端传输到 Vertica。这样，“中间人”攻击可能会截取来自客户端的明文密码。

配置哈希身份验证可确保使用密码进行安全登录。

关于密码创建和修改

您必须是超级用户才能使用 CREATE USER 语句为用户帐户创建密码。超级用户可以设置任何用户账户的密码。

使用 ALTER USER 语句添加密码。
要更改密码，请使用 ALTER USER 或 vsql 元命令 \password。

用户也可更改自己的密码。

要更加高效地进行密码身份验证，Vertica 建议执行密码策略以控制强制用户更改密码的频率以及密码所要求的内容。使用配置文件.设置这些策略。

默认密码身份验证

当未指定任何身份验证方法时，Vertica 默认为具有密码的用户帐户使用密码身份验证。

如果创建身份验证方法（即使是为远程主机），密码身份验证将禁用。这种情况下，必须显式弃用密码身份验证。下列命令可创建 local_pwd 身份验证方法并设置为所有用户的默认方法。创建身份验证方法时，Vertica 会自动启用该方法：

=> CREATE AUTHENTICATION local_pwd METHOD hash' LOCAL;
=> GRANT AUTHENTICATION local_pwd To Public;

1.13.3.1 - 配置文件

您可以通过为用户分配配置文件来为其设置密码策略。您可以创建多个配置文件来管理多个类别用户的密码策略。例如，您可以为交互用户创建一个要求经常更改密码的配置文件，为用户帐户创建另一个从不要求更改密码的配置文件。

定义配置文件

您可以使用 CREATE PROFILE 创建配置文件，并使用 ALTER PROFILE 更改现有配置文件。这两个语句都允许您设置一个或多个配置文件参数，这些参数用于控制密码的最短有效期限、密码复杂性和密码重置规则等。

每个配置文件都可以指定以下一项或多项策略。

用户必须更换密码的频率
密码自设置到重置之前必须经过的时间
在使用旧密码前用户必须更户密码的次数
在帐户锁定之前，用户可登录失败的次数
密码要求的长度和内容：
- 最大和最小字符数
- 密码中大写字母、小写字母、数字以及符号的最小数量
- 新密码必须与旧密码不同的字符数

分配配置文件

定义配置文件后，您可以分别使用 CREATE USER 和 ALTER USER 将其分配给新用户和现有用户。

密码内容的配置文件策略（例如，PASSWORD_MAX_LENGTH 和 PASSWORD_MIN_SYMBOLS）的更改仅在用户更改密码时才会影响用户。Vertica 不会测试现有密码来验证其是否符合新的密码要求。要强制使其立即符合新的配置文件要求，请使用 ALTER USER...PASSWORD EXPIRE 立即终止当前用户的密码。用户下次登录时，Vertica 会提示他们提供新密码，该密码必须符合当前策略。

默认配置文件

每个数据库均包含一个 DEFAULT 配置文件。Vertica 将默认配置文件分配给未显式分配配置文件的用户。在以下两种情况下，默认配置文件还会设置非默认配置文件的参数：

配置文件参数未通过 CREATE PROFILE 显式设置
参数的 ALTER PROFILE 设置为 DEFAULT

默认配置文件中的所有参数最初都设置为 unlimited。您可以使用 ALTER PROFILE 来更改这些设置。例如，以下语句将修改默认配置文件参数 PASSWORD_MIN_SYMBOLS。此更改要求密码至少包含一个符号，例如 $、#、@。此更改会影响 PASSWORD_MIN_SYMBOLS 设置为 default 的所有配置文件：

ALTER PROFILE DEFAULT LIMIT PASSWORD_MIN_SYMBOLS 1;

配置文件设置和客户端身份验证

以下配置文件设置会影响客户端身份验证方法，例如 LDAP 或 GSS：

FAILED_LOGIN_ATTEMPTS
PASSWORD_LOCK_TIME

所有其他配置文件设置仅供 Vertica 用于管理其密码。

另请参阅

1.13.3.2 - 密码指导原则

为使密码发挥其有效性，必须使用强密码。密码应防范：

字典样式，以防被暴力破解攻击
掌握密码持有人相关信息的人（姓名、生日等）

使用配置文件来强制执行强密码策略（密码长度和所需的内容）确保数据库用户了解密码指导原则，并鼓励其不再密码中使用个人信息。

有关创建强密码的指导原则，请访问微软对创建强密码的一些提示。

另请参阅

创建数据库名称和密码

1.13.3.3 - 密码过期

以下 PROFILE 参数用于控制密码过期、新密码和最短有效期限的条件：

PASSWORD_LIFE_TIME - 密码保持有效的天数
PASSWORD_MIN_LIFE_TIME - 密码自设置到更改之前必须经过的天数
PASSWORD_GRACE_TIME - 密码过期后可以继续使用的天数
PASSWORD_REUSE_MAX - 在重新使用较早的密码之前必须更改密码的次数
PASSWORD_REUSE_TIME - 从设置完密码后到可以重复使用该密码之前必须经过的天数
PASSWORD_MIN_CHAR_CHANGE - 必须与以前的密码不同的最小字符数

有关这些参数和其他参数的更多详细信息，请参阅 CREATE PROFILE 和 ALTER PROFILE。

重要

密码过期不会影响当前的会话。

密码过期和宽限期行为

配置文件参数 PASSWORD_LIFE_TIME 控制密码的有效期限（以天为单位）。默认情况下，DEFAULT 配置文件将 PASSWORD_LIFE_TIME 设置为 UNLIMITED，这会禁用密码过期。您可以使用 ALTER PROFILE 更改默认配置文件和自定义配置文件。

通常情况下，当密码过期后，Vertica 会强制用户在下次登录时更改密码。但是，您可以设置 PASSWORD_GRACE_TIME 以允许用户在密码过期后继续使用该密码登录。如果用户在宽限期内登录，Vertica 会警告用户其密码已过期。此宽限期结束后，Vertica 将发出标准提示，提示用户更改用户密码。

终止密码

可以使用 ALTER USER 语句的 PASSWORD EXPIRE 参数来立即终止密码。通过终止密码，可以：

强制用户遵守密码更改策略。
当用户忘记了旧密码时，要设置新密码。

1.13.3.4 - 帐户锁定

在配置文件中，您可以设置密码策略，确定在锁定用户帐户之前允许的连续失败登录尝试次数。该锁定机制有助于阻止通过字典式强力攻击尝试来猜测用户密码的行为。

设置帐户锁定

使用 FAILED_LOGIN_ATTEMPTS 参数（CREATE PROFILE 或 ALTER PROFILE 语句）设置该值。

如果用户帐户登录尝试连续失败次数超过 FAILED_LOGIN_ATTEMPTS 设置的值，则 Vertica 将锁定该帐户。即使用户提供正确的密码，也无法登录锁定的帐户。

解锁锁定的帐户

您可以通过以下两种方式之一解锁帐户，具体取决于您的权限。

手动：如果您是超级用户，则可以使用 ALTER USER 命令手动解锁帐户。

注意
超级用户帐户不能锁定，因为它是唯一能够解锁帐户的用户。因此，请为超级用户帐户选择一个非常安全的密码。请参阅密码指导原则获取建议。
密码锁定时间设置： PASSWORD_LOCK_TIME 指定在指定的登录尝试失败次数（可使用 FAILED_LOGIN_ATTEMPTS 进行配置）后将帐户锁定的天数（单位可使用 PasswordLockTimeUnit 进行配置）。经过指定的天数后，Vertica 将自动解锁帐户。

如果将此参数设置为 UNLIMITED，则该用户的帐户永远不会自动解锁，必须由超级用户手动解锁。

1.14 - Ident 身份验证

RFC 1413 中定义的 Ident 协议使用系统用户名对数据库用户进行身份验证。要查看该系统用户是否可以在不指定密码的情况下登录，您需要将 Vertica 客户端身份验证配置为查询 Ident 服务器。借助此功能，DBADMIN 用户可以运行自动化脚本以在 Vertica 服务器上执行任务。

当心

Ident 响应很容易被不受信任的服务器欺骗。请仅对本地连接使用 Ident 身份验证，其中 Ident 服务器与 Vertica 数据库服务器安装在相同的计算机上。

按照以下主题中的说明为您的数据库安装、设置和配置 Ident 身份验证：

示例

以下示例显示了配置 Ident 身份验证的几种方法。

允许 system_user1 以 Vertica vuser1 的身份连接到数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1';
=> GRANT AUTHENTICATION v_ident to vuser1;
=> ALTER AUTHENTICATION v_ident ENABLE;

允许 system_user1、system_user2 和 system_user3 以 vuser1 的身份连接到数据库。使用冒号 (:) 分隔用户名：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1:system_user2:system_user3';
=> GRANT AUTHENTICATION v_ident TO vuser1;
=> ALTER AUTHENTICATION v_ident ENABLE;

使用 GRANT AUTHENTICATION 语句将身份验证与 Public 相关联。用户 system_user1、system_user2 和 system_user3 现在可以以任意数据库用户身份连接到数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1:system_user2:system_user3';
=> GRANT AUTHENTICATION v_ident to Public;
=> ALTER AUTHENTICATION v_ident ENABLE;

将 system_users 参数设置为 *，以允许任何系统用户以 vuser1 的身份连接到数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='*';
=> GRANT AUTHENTICATION v_ident TO vuser1;
=> ALTER AUTHENTICATION v_ident ENABLE;

使用 GRANT 语句，将 v_ident 身份验证与 Public 相关联，以允许 system_user1 以任意数据库用户身份登录数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1';
=> GRANT AUTHENTICATION v_ident to Public;
=> ALTER AUTHENTICATION v_ident ENABLE;

1.14.1 - 安装和设置 Ident 服务器

若要使用 Ident 身份验证，您必须安装一个或多个包，具体取决于您的操作系统，并在 Vertica 服务器上启用 Ident 服务器。oidentd是兼容 Vertica 并符合 RFC 1413 标准的 Ident 守护程序。

注意

您可以在 oidentd 网站上找到 oidentd 的源代码和安装说明。

要安装和配置 Ident 身份验证以用于 Vertica 数据库，请按照适用于您的操作系统的相应步骤进行操作。

Red hat 7.x/CentOS 7.x

通过安装 authd 和 xinetd 包，在 Red Hat 7.x 或 CentOS 7.x 上安装 Ident 服务器：

$ yum install authd
$ yum install xinetd

Ubuntu/debian

通过运行此命令，在 Ubuntu 或 Debian 上安装 oidentd：

$ sudo apt-get install oidentd

SUSE Linux Enterprise Server

从以下位置安装 pidentd 和 xinetd RPM：

ubuntu/debian 的安装后步骤

在 Ubuntu/Debian 系统上安装 oidentd 后，请继续执行以下步骤：

验证 Ident 服务器接受 IPv6 地址，以防止身份验证失败。若要执行此操作，必须启用此功能。在脚本 /etc/init.d/oidentd 中，更改行：
```
exec="/usr/sbin/oidentd"
```
到
```
exec="/usr/sbin/oidentd -a ::"
```
然后，在 Linux 提示中，使用 oidentd 启动 -a ::。
使用以下命令重新启动服务器：
```
$ /etc/init.d/oidentd restart
```

Red Hat 7.x/CentOS 7.x 和 SUSE Linux Enterprise Server 的安装后步骤

在 Red Hat 7.x/CentOS 7.x 或 SUSE Linux Enterprise Server 系统上安装所需的包之后，继续执行以下步骤：

通过在配置文件 /etc/xinetd.d/auth 中设置 disable = no 来启用 auth 服务。如果此文件不存在，请创建该文件。以下是一个示例配置文件：

service auth
{
        disable = no
        socket_type = stream
        wait = no
        user = ident
        cps = 4096 10
        instances = UNLIMITED
        server = /usr/sbin/in.authd
        server_args = -t60 --xerror --os
}

使用以下命令重新启动 xinetd 服务：
```
$ service xinetd restart
```

1.14.2 - 为数据库用户配置 Ident 身份验证

要配置 Ident 身份验证，请执行以下步骤：

创建使用 Ident 的身份验证方法。

Ident 服务器必须和您的数据库安装在相同的计算机上，所以请指定关键字 LOCAL。Vertica 要求 Ident 服务器和数据库始终与您的数据库位于相同的计算机上。
```
=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
```
设置 Ident 身份验证参数，指定允许连接到您的数据库的系统用户。
```
=> ALTER AUTHENTICATION v_ident SET system_users='user1:user2:user3';
```
将身份验证方法与 Vertica 用户相关联。使用 GRANT 语句，允许系统用户 user1 使用 Ident 身份验证登录：
```
=> GRANT AUTHENTICATION v_ident TO user1;
```

1.15 - Kerberos 身份验证

Kerberos 身份验证使用以下组件来执行用户身份验证。

客户端程序包

Kerberos 5 客户端程序包用于与 KDC 服务器进行通信。此软件包并不作为 Vertica Analytics Platform 安装的一部分包含在内。Kerberos 软件内置在 Microsoft Windows 中。如果使用的是其他操作系统，必须获取并安装该客户端软件包。

如果您的系统上还没有 Kerberos 5 客户端程序包，请从 MIT Kerberos 分发页面下载。在 Kerberos 身份验证中使用的每个 Vertica 服务器和客户端上安装此程序包，KDC 本身除外。

有关安装说明，请参阅 Kerberos 文档。

服务主体

服务主体由主机名、服务名称和分配了一组凭据的领域组成 (service/hostname@REALM)。这些凭据会连接到服务，即您通过网络连接并使用 KDC 进行身份验证的主机。

要创建领域名，请参阅指定 KDC 信息并配置领域。主机名必须与操作系统提供的值匹配。通常，它是一个完全限定主机名。如果主体的主机名部分与操作系统提供的值不匹配，Kerberos 身份验证会失败。

有些系统使用主机文件（/etc/hosts 或 /etc/hostnames）来定义主机名。主机文件可以为一个主机定义多个名称。操作系统提供了第一个条目，因此，请在主体中使用此条目。例如，如果主机文件包含：

192.168.1.101 v_vmart_node0001.example.com v_vmart_node0001

则将 v_vmart_node0001.example.com 作为主机名值。

注意

具体取决于您的配置，使用完全限定域名而非主机名可能会更安全。

将以下内容配置为 Kerberos 主体：

每一个客户端（连接到 Vertica 的用户或应用程序）
Vertica 服务器

有关详细信息，请参阅以下主题：

Keytab 文件

主体存储在加密 Keytab 文件中。Keytab 文件包含 Vertica 主体的凭据。它有助于 Vertica 服务器向 KDC 验证自身身份。您需要使用 Keytab，这样 Vertica 分析型数据库就不会提示您输入密码。

请为群集中的每个节点创建一个服务主体。然后，您可以创建各个 Keytab 文件（每个节点一个，其中仅包含该节点的主体），或创建一个包含所有主体的 Keytab 文件。

创建一个包含所有主体的 Keytab 文件 可简化设置：所有节点具有相同的文件，可简化初始设置。如果在以后添加节点，则可以更新（和重新分发）全局 Keytab 文件或为新节点创建单独的 Keytab。如果某个主体受损，则该主体在包含它的所有节点的 Keytab 文件中也会受损。
在每个节点中创建单独的 Keytab 文件 可简化维护工作。不过，初始设置时的工作量较大，因为您必须在每个节点中创建不同的文件，但主体不会在各个节点之间共享。如果在以后添加节点，则可以在新节点中创建 Keytab。每个节点的 Keytab 仅包含一个主体，即用于此节点的主体。

票证授予票证

票证授予票证 (TGT) 用于检索对域中服务器的用户进行身份验证的服务票证。随后的登录请求将使用缓存的 HTTP 服务票证进行身份验证，除非该票证已到 krb5.conf 中的 ticket_lifetime 参数中设置的过期时间。

多领域支持

注意

为某个身份验证记录分配多个领域时，请注意，Vertica 无法区分来自某个领域的用户和来自 Vertica 领域的用户。这使得同一用户可以同时从多个领域登录 Vertica。

Vertica 使用 ALTER AUTHENTICATION 中的 SET param=value 参数（REALM 作为参数）为 Kerberos 身份验证提供多领域支持：

=> ALTER AUTHENTICATION krb_auth_users set REALM='USERS.COM';
=> ALTER AUTHENTICATION krb_auth_realmad set REALM='REALM_AD.COM';

这允许您分配不同的领域，以便其他领域的用户可以向 Vertica 验证身份。

多领域支持仅适用于 GSS 身份验证类型。每种身份验证方法可以有一个领域。如果您有多种身份验证方法，则每种方法都可以有自己的领域：

=> SELECT * FROM client_auth;
auth_oid | auth_name | is_auth_enabled | auth_host_type | auth_host_address | auth_method | auth_parameters     | auth_priority
---------+-----------+-----------------+----------------+-------------------+-------------+-----------------+-----------------
45035996 | krb001    |   True          |   HOST         |  0.0.0.0/0        |  GSS        | realm=USERS.COM     |  0
45035997 | user_auth |   True          |   LOCAL        |                   |  TRUST      |                     |  1000
45035737 | krb002    |   True          |   HOST         |  0.0.0.0/0        |  GSS        | realm=REALM_AD.COM  |  1

1.15.1 - 为 Kerberos 身份验证配置 Vertica

Kerberos 针对设备提供强大的加密身份验证，使客户端和服务器能够以更安全的方式进行通信。从而解决了网络安全问题。

您的系统必须安装和配置一个或多个 Kerberos 密钥分发中心 (KDC)。必须可以从 Vertica 分析型数据库群集中的每个节点访问 KDC。

KDC 必须使用 GSS-API 支持 Kerberos 5。有关详细信息，请参阅 MIT Kerberos 分发页面。

此部分内容

1.15.1.1 - 在 Linux KDC 中创建 Vertica 主体和 Keytab

Vertica 使用服务主体进行系统级别的操作。这些主体用于标识 Vertica 服务，并按如下方式使用：

当 Kerberized Vertica 客户端向数据库进行身份验证时，它们会请求访问此服务。
Tuple Mover 等系统进程向 Hadoop 等外部服务进行身份验证时，它们会使用此标识。

按如下所示创建主体和密钥：

启动 Kerberos 5 数据库管理实用程序（kadmin 或 kadmin.local）可在 Linux KDC 中创建 Vertica 主体。
- 如果要访问远程服务器中的 KDC，请使用 kadmin。如果掌握 Kerberos 管理员密码，则可以在安装了 Kerberos 5 客户端包的任何计算机上使用 kadmin。启动 kadmin 时，实用程序会提示您输入 Kerberos 管理员密码。您可能需要具备客户端的 root 权限才能运行 kadmin。
- 在以下情况下可以使用 kadmin.local：
  - KDC 位于您当前已登录的计算机中。
  - 您对该服务器具有 root 权限。
kadmin.local 不需要管理员登录凭据。

有关 kadmin 和 kadmin.local 命令的详细信息，请参阅 kadmin 文档。
在每个节点中，为 Vertica 创建一个服务主体。主机名必须与操作系统提供的值匹配。以下示例为名为 vertica 的节点创建了服务主体 v_vmart_node0001.example.com：
```
$ sudo /usr/kerberos/sbin/kadmin.local
kadmin.local add_principal vertica/v_vmart_node0001.example.com
```
为每个主体重复执行一次 ktadd 命令。您可以为每个主体用户创建单独的 Keytab，也可以将它们全部添加到一个 Keytab 文件（例如 krb5.keytab）。如要使用一个文件，请参阅 MIT Kerberos 文档中有关 -glob 选项的文档。

您必须为使用 Kerberos 身份验证的每个 Vertica 分析数据库用户创建一个用户主体。例如：
```
$ sudo /usr/kerberos/sbin/kadmin.local
kadmin.local add_principal [options] VerticaUser1
```
将每个 Keytab 文件复制到相应群集节点中的 /etc 文件夹。在所有节点中使用相同的路径和文件名。
在每个节点中，让 Keytab 文件可供正在运行数据库进程的文件所有者（通常是 Linux dbadmin 用户）读取。例如，您可以按照以下方式，将这些文件的所有权更改为 dbadmin：
```
$ sudo chown dbadmin *.keytab
```
重要
在生产环境中，您必须控制可以访问 Keytab 文件的用户，以免未经授权的用户委派您的服务器。有关委派（也称为模拟）的详细信息，请参阅 [Technet.Microsoft.com](http://technet.microsoft.com/en-us/library/ms161965(v=sql.105)。

创建 Keytab 文件之后，可以使用 klist 命令查看存储在文件中的密钥：
```
$ sudo /usr/kerberos/bin/klist -ke -t
Keytab name: FILE:/etc/krb5.keytab
KVNO    Timestamp        Principal
---- ------------------- --------------------------------------------------------------------------
4     08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
4     08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
```

在 Vertica 上运行以下命令，以确保正确设置 Kerberos 参数：

=> select parameter_name, current_value from configuration_parameters where parameter_name like 'Ker%';
parameter_name         |                      current_value
-----------------------+---------------------------------------------------------------------
KerberosHostname       | v_vmart_node0001.example.com
KerberosKeytabFile     | /etc/krb5.keytab
KerberosRealm          | EXAMPLE.COM
KerberosTicketDuration | 0
KerberosServiceName    | vertica
(5 rows)

确保所有客户端都使用 gss 身份验证方法。

从 Vertica：

=> CREATE USER bob;
CREATE USER

=> CREATE AUTHENTICATION v_kerberos method 'gss' host '0.0.0.0/0';
CREATE AUTHENTICATION

=> ALTER AUTHENTICATION v_kerberos enable;
ALTER AUTHENTICATION

=> GRANT AUTHENTICATION v_kerberos to bob;
GRANT AUTHENTICATION

从操作系统命令行：

$ kinit bob

$ vsql -U bob -k vertica -K v_vmart_node0001.example.com -h v_vmart_node0001 -c "select client_authentication_name,
authentication_method from sessions;"
 client_authentication_name | authentication_method--
----------------------------+-----------------------
 v_kerberos                 |    GSS-Kerberos

(1 row)

在 Vertica 上，运行 KERBEROS_CONFIG_CHECK 以验证 Kerberos 配置。KERBEROS_CONFIG_CHECK 验证以下内容：
- kinit 和 kb5.conf 文件是否存在。
- keytab 文件是否存在且已设置
- 数据库中设置的 Kerberos 配置参数：
  - KerberosServiceName
  - KerberosHostname
  - KerberosRealm
  - Vertica 主体
- Kerberos 可以读取 Vertica 密钥
- Kerberos 可以获得 Vertica 主体的票证
- Vertica 可以使用 kinit 初始化密钥

1.15.1.2 - 指定 KDC 信息并配置领域

Kerberos 领域中的每个客户端和 Vertica 分析型数据库服务器都必须具有有效且配置相同的 Kerberos 配置 (krb5.conf) 文件。如果没有该文件，客户端不知道如何到达 KDC。

如果使用 Microsoft Active Directory，则无需执行此步骤。请参阅适用于您的平台的 Kerberos 文档，详细了解有关在 Active Directory 上的 Kerberos 配置文件信息。

您至少需要在 krb5.conf 文件中配置以下部分。

[libdefaults]—Kerberos 5 库使用的设置
[realms]—领域专用联系信息和设置
[domain_realm]—将服务器主机名映射到 Kerberos 领域

请参阅 Kerberos 文档，了解有关此配置文件中其它部分的信息。

您必须更新 /etc/krb5.conf 文件以反映您的站点的 Kerberos 配置。在 Kerberos 领域中的所有客户端与服务器当中强制执行一致性的最简单办法，就是从 KDC 复制 /etc/krb5.conf 文件。然后，将该文件放入每个 Vertica 群集节点上的 /etc 目录内。

1.15.1.3 - 通知 Vertica 有关 Kerberos 主体的信息

按照以下步骤通知 Vertica 有关主体名称和 keytab 位置的信息。

有关您在此过程中需要设置的参数的信息，请参阅 Kerberos 参数。

以管理员身份（通常为 dbadmin）登录到数据库。
设置 KerberosKeyTabFile 配置参数，以指向 keytab 文件的位置：
```
=> ALTER DATABASE DEFAULT SET PARAMETER KerberosKeytabFile = '/etc/krb5.keytab';
```
在所有节点上，keytab 文件必须在相同位置（在此示例中为 /etc/krb5.keytab）。

设置 Vertica 主体的服务名称；例如，vertica：

=> ALTER DATABASE DEFAULT SET PARAMETER KerberosServiceName = 'vertica';

提供主体的领域部分，例如，EXAMPLE.COM。

=> ALTER DATABASE DEFAULT SET PARAMETER KerberosRealm = 'EXAMPLE.COM'

1.15.1.4 - 为所有客户端配置身份验证方法

为了确保所有客户端均使用 gss 身份验证方法，请运行以下语句：

=> CREATE AUTHENTICATION <method_name> METHOD 'gss' HOST '0.0.0.0/0';
=> GRANT AUTHENTICATION <method_name> TO Public;

有关详细信息，请参阅实施客户端身份验证。

1.15.1.5 - 在 Active Directory 中创建主体和 Keytab

Active Directory 存储有关 Windows 域成员的信息，包括用户和主机。

Vertica 使用 Kerberos 协议访问此信息，以便对 Vertica 数据库的 Windows 用户进行身份验证。Kerberos 协议使用主体来识别用户，并使用 keytab 文件来存储他们的加密信息。您需要将 keytab 文件安装到 Vertica 中，使 Vertica 数据库能够以加密方式验证 Windows 用户。

此过程描述：

创建 Vertica 服务主体。
导出这些主体的 keytab 文件
在 Vertica 数据库中安装 keytab 文件。这将允许 Vertica 对 Windows 用户进行身份验证，并授予其访问 Vertica 数据库的权限。

为 Vertica 服务创建一个 Windows 帐户（主体），并为群集中的每个节点/主机创建一个 Vertica 主机。此过程将为在该节点上运行的主机 verticanode01 和服务 vertica 创建 Windows 帐户。

创建这些帐户时，请选择以下选项：
- 用户无法更改密码
- 密码永不过期
注意
您可以取消选择密码永不过期。但是，如果更改这些用户密码，则必须重新创建 keytab 文件并将其重新安装到 Vertica 中。这包括重复整个过程。
如果您在 HDFS 上使用受 Kerberos 身份验证保护的外部表，则必须启用“委派 (Delegation)”。为此，请访问 Active Directory 用户和计算机对话框，右键单击 Vertica 服务的 Windows 帐户（主体），然后选择“委派 (Delegation)”。信任此用户以委派给任何服务。

运行以下命令为主机 verticanode01.dc.com 节点/主机创建密钥表：

$ ktpass -out ./host.verticanode01.dc.com.keytab -princ host/verticanode01.dc.com@DC.COM -mapuser verticanode01
 -mapop set -pass secret  -ptype KRB5_NT_SRV_HST

运行以下命令为 vertica 服务创建 Keytab:

$ ktpass -out ./vertica.verticanode01dc.com.keytab -princ vertica/verticanode01.dc.com@DC.COM -mapuser vertica
 -mapop set -pass secret  -ptype KRB5_NT_PRINCIPAL

有关 Keytab 文件的详细信息，请参阅 Technet.Microsoft.com

运行以下命令以验证服务主体名称是否正确映射。您必须为群集中的每个节点运行以下命令：

$ setspn -L vertica
    Registered ServicePrincipalNamefor CN=vertica,CN=Users,DC=dc,DC=com
      vertica/verticanode01.dc.com

$ setspn -L verticanode01
    Registered ServicePrincipalNamefor CN=verticanode01,CN=Users,DC=dc,DC=com
      host/verticanode01.dc.com

将您刚才创建的密钥表 vertica.verticanode01.dc.com.keytab 和 host.verticanode01.dc.com.keytab 复制到 Linux 主机 verticanode01.dc.com。

将多个 Keytab 文件组合成一个 Keytab：


[release@vertica krbTest]$ /usr/kerberos/sbin/ktutil
ktutil:  rkt host.verticanode01.dc.com.keytab
ktutil:  rkt vertica.verticanode01.dc.com.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
  1    3  host/verticanode01.dc.com@DC.COM
  2   16  vertica/verticanode01.dc.com@DC.COM
ktutil:  wkt verticanode01.dc.com.keytab
ktutil:  exit

这将创建一个 Keytab 文件，其中包含用于身份验证的服务器主体。

将新的 Keytab 文件复制到编录目录。例如：

$ cp verticanode01.dc.com.keytab /home/dbadmin/VMart/v_vmart_nodennnn_catalog

测试 Keytab 文件检索票证的能力，确保它可以从 Vertica 节点运行：


$ kinit vertica/verticanode01.dc.com -k -t verticanode01.dc.com.keytab
$ klist

Ticket cache: KFILE:/tmp/krb_ccache_1003
Default principal: vertica/verticanode01.dc.com@DC.COM

Valid starting Expires Service principal
04/08/2017 13:35:25 04/08/2017 23:35:25 krbtgt/DC.COM@DC.COM
                renew until 04/15/2017 14:35:25

当票证过期或未自动取回时，您需要手动运行 kinit 命令。请参阅获取 Kerberos 票证并对 Vertica 进行身份验证。

对 Keytab 文件设置正确的权限和所有权：

$ chmod 600 verticanode01.dc.com.keytab
$ chown dbadmin:verticadba verticanode01.dc.com.keytab

使用 ALTER DATABASE 设置以下 Kerberos 参数通知 Vertica 有关 Kerberos 主体的信息：

KerberosKeytabFile=<CATALOGDIR>/verticanode01.dc.com.keytab
KerberosRealm=DC.COM
KerberosServiceName=vertica
KerberosTicketDuration = 0
KerberosHostname=verticanode01.dc.com

重新启动 Vertica 服务器。

按如下所示测试 Kerberos 设置，确保所有客户端都使用 gss 身份验证方法。

从 Vertica：

=> CREATE USER windowsuser1;
CREATE USER

=> CREATE AUTHENTICATION v_kerberos method 'gss' host '0.0.0.0/0';
CREATE AUTHENTICATION

=> ALTER AUTHENTICATION v_kerberos enable;
ALTER AUTHENTICATION

=> GRANT AUTHENTICATION v_kerberos to windowsuser1;
GRANT AUTHENTICATION

从操作系统命令行：

$ kinit windowsuser1

$ vsql -U windowsuser1 -k vertica -K verticanode01.dc.com -h verticanode01.dc.com -c "select client_authentication_name,
authentication_method from sessions;"
 client_authentication_name | authentication_method--
----------------------------+-----------------------
 v_kerberos                 |    GSS-Kerberos

(1 row)

运行 KERBEROS_CONFIG_CHECK 以验证 Kerberos 配置。KERBEROS_CONFIG_CHECK 验证以下内容：
- kinit 和 kb5.conf 文件是否存在。
- keytab 文件是否存在且已设置
- 数据库中设置的 Kerberos 配置参数：
  - KerberosServiceName
  - KerberosHostname
  - KerberosRealm
  - Vertica 主体
- Kerberos 可以读取 Vertica 密钥
- Kerberos 可以获得 Vertica 主体的票证
- Vertica 可以使用 kinit 初始化密钥

1.15.1.6 - 获取 Kerberos 票证并对 Vertica 进行身份验证

如果您的机构使用 Kerberos 作为登录过程的一部分，在登录时会自动检索 Kerberos 票证。否则，您需要运行 kinit 来检索 kerberos 票证。

以下示例显示如何使用 kinit 命令检索票证并通过 KDC 对 Vertica 分析型数据库进行身份验证。域名为 EXAMPLE.COM。您必须使用该域名及您的用户名来检索 Kerberos 票证。请参阅指定 KDC 信息并配置领域。

$ kinit
Password for principal_user@EXAMPLE.COM: kpasswd

将会提示您当您创建主体和密钥文件（请参阅在 Linux KDC 中创建 Vertica 主体和 Keytab）时创建的主体用户名的密码。

Kerberos 票证在预设时间长度内被缓存。请参阅 Kerberos 文档中的票证管理获取有关过期参数设置的更多信息。

过期后，您需要再次运行 kinit 指令来检索另外一张 Kerberos 票证。

1.15.2 - 为 Kerberos 身份验证配置客户端

各个支持的平台使用不同的安全框架。因此，不同客户端中配置和执行 Kerberos 身份验证所需的步骤也不尽相同。

在服务器端，需使用以下格式构建 Vertica Kerberos 服务名称主体：

Kerberos_Service_Name/Kerberos_Host_Name@Kerberos_Realm

对于每个客户端，GSS 库要求 Vertica 服务主体采用以下格式：

Kerberos_Service_Name@Kerberos_Host_Name

可以省略主体的领域部分，因为 GSS 库使用配置的默认 (Kerberos_Realm) 领域的领域名称。

有关客户端连接字符串的信息，请参阅以下主题：

注意

在某些情况下，Vertica 服务器主体名称可能与连接字符串中的主机名不匹配。有关详细信息，请参阅 Kerberos 身份验证故障排除。

此部分内容

1.15.2.1 - 在非 Windows 平台上配置 ODBC 和 vsql 客户端

要在 Linux 或 MAC OSX 上配置 ODBC 或 vsql 客户端，必须首先安装 Kerberos 5 客户端软件包。请参阅配置 Kerberos 身份验证。

安装 Kerberos 5 客户端软件包后，必须向客户端提供有效的 Kerberos 配置文件 (krb5.conf)。要与 KDC 通信，参与 Kerberos 身份验证的每个客户端必须拥有配置相同的有效 krb5.conf 文件。Kerberos 配置文件的默认位置为 /etc/krb5.conf。

提示

要确保客户端、Vertica 分析型数据库和 KDC 之间的一致性，请将 /etc/krb5.conf 文件从 KDC 复制到客户端的 /etc 目录。

Kerberos 配置 (krb5.conf) 文件包含 Kerberos 特定的信息，包括：

如何连接 KDC
默认领域名称
域
指向日志文件的路径
DNS 查询
要使用的加密类型
票证使用期限

Kerberos 配置文件的默认位置为 /etc/krb5.conf。

如果配置正确，客户端可以使用 Kerberos 进行身份验证并通过 kinit 实用程序检索票证（请参阅以下获取 ODBC 身份验证请求和连接）。同样，服务器则可以使用 ktutil 在 keytab 文件中存储其凭据

在非 Windows 平台上对 ODBC 和 vsql 客户端进行身份验证

ODBC 和 vsql 使用 kinit 建立的客户端票证执行 Kerberos 身份验证。这些客户端依赖于安全库的默认机制来查找票证文件和 Kerberos 配置文件。

要按照 Kerberos 进行身份验证，请调用 kinit 实用程序以便从 Kerberos KDC 服务器获取票证。以下两个示例显示了如何使用 ODBC 和 vsql 客户端发送票证请求。

获取 ODBC 身份验证请求和连接

在 ODBC 客户端上，通过调用 kuser 实用程序获取 kinit 用户的票证。
```
$ kinit kuser@EXAMPLE.COM
Password for kuser@EXAMPLE.COM:
```

连接到 Vertica，并在连接字符串中提供主体：

char outStr[100];
SQLLEN len;
SQLDriverConnect(handle, NULL, "Database=VMart;User=kuser;
Server=myserver.example.com;Port=5433;KerberosHostname=vcluster.example.com",
SQL_NTS, outStr, &len);

获取 vsql 身份验证请求和连接

如果 vsql 客户端位于您所连接的同一台计算机中，vsql 将通过 UNIX 域套接字连接。此连接将绕过 Kerberos 身份验证。当使用 Kerberos 进行身份验证时，特别是客户端身份验证方法配置为“本地”时，必须包括 -h 主机名选项。请参阅命令行选项。

在 vsql 客户端上，调用 kinit 实用程序：

$ kinit kuser@EXAMPLE.COM
Password for kuser@EXAMPLE.COM:

连接到 Vertica，并在连接字符串中提供主机和用户主体：

$ ./vsql -K vcluster.example.com -h myserver.example.com -U kuser
Welcome to vsql, the Vertica Analytic Database
interactive terminal.

Type:  \h or \? for help with vsql commands
\g or terminate with semicolon to execute query
\q to quit

将来，以 kuser 身份登录 vsql 时，vsql 将使用您缓存的票证，而不提示您输入密码。

验证身份验证方法

通过查询 SESSIONS 系统表可以验证身份验证方法：

=> SELECT authentication_method FROM sessions;
 authentication_method
-----------------------
GSS-Kerberos
(1 row)

另请参阅

ODBC DSN 连接属性
(vsql) 命令行选项

1.15.2.2 - 在 Windows 上配置 ADO.NET、ODBC 和 vsql 客户端

Vertica 客户端驱动程序支持使用 Windows SSPI 库进行 Kerberos 身份验证。Windows Kerberos 配置存储在注册表中。

对于 Windows 和 ADO.NET 上的 ODBC 和 vsql 客户端 Kerberos 身份验证，可以选择两种不同的设置方案：

在 Active Directory 中使用 Windows 内置 Kerberos 客户端和 Vertica 的 Windows KDC
使用 Windows 内置 Kerberos 客户端和 Vertica 的 Linux KDC

在 Active Directory 中使用 Windows 内置 Kerberos 客户端和 Vertica 的 Windows KDC

在 Windows 上的 Kerberos 身份验证通常搭配 Active Directory（Microsoft 的企业目录服务/Kerberos 实施）使用。通常，由组织的网络或 IT 管理员执行设置。

Windows 客户端的 Kerberos 身份验证内置于身份验证进程中。无需任何其他软件。

在执行以下操作时，登录凭据可对您连接 Kerberos 服务器 (KDC) 进行身份验证：

从客户机登录到 Windows
使用配置为通过 Active Directory 使用 Kerberos 的 Windows 实例

要在 Windows 客户端上使用 Kerberos 身份验证，请以 REALM\user 身份登录。

重要

在使用 ADO.NET 驱动程序连接 Vertica 时，可以选择在连接字符串中指定 IntegratedSecurity=true。这样可通知驱动程序按照用户的 Windows 凭据对呼叫用户进行身份验证。因此，无需在连接字符串中包括用户名或密码。输入连接字符串的任何 user= 条目都将被忽略。

使用 Windows 内置 Kerberos 客户端和 Vertica 的 Linux KDC

一种简单但不太常见的方案是配置 Windows 对非 Windows KDC 进行身份验证。在此实施中，使用 ksetup 实用程序在非 Active Directory KDC 中指出 Windows 操作系统本机 Kerberos 功能。通过登录到 Windows，可获取许可票证，与 Active Directory 实施类似。但在这种情况下，Windows 在内部与 Linux KDC 通信。有关详细信息，请参阅 Microsoft Windows Server Ksetup 页面。

当数据库/Windows 用户登录到 Windows 计算机（或在 Windows 上执行 kinit 之后）时，Kerberos 票证必须设置 ok_as_delegate 和 forwardable 标志才能访问基于 webhdfs 的外部表，如下所示：

$ CMD \> klist
#2>     Client: release @ VERTQA.LOCAL
Server: vertica/vqatest108.verticacorp.com @ VERTQA.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a50000 forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 9/27/2017 13:24:43 (local)
End Time:   9/27/2017 20:34:45 (local)
Renew Time: 10/3/2017 15:04:45 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: ADKDC01

注意

上面的 Ticket Flags 设置必须包含 ok_as_delegate 和 forwardable 条目。有关这些参数的信息，请参阅 Kerberos 文档。

配置 Windows 客户端以执行 Kerberos 身份验证

根据要配置的实施，请参阅 Microsoft Server 网站上的下列页面之一：

要使用 Active Directory 设置 Windows 客户端，请参阅《Kerberos 5 (krb5 1.0) 互操作分步指南》。
要使用 ksetup 实用程序设置 Windows 客户端，请参考 Ksetup 页面。

客户端身份验证和连接

KDC 可对 ADO.NET 和 a vsql 客户端进行身份验证。

注意

在连接字符串中使用完全限定域名作为服务器；例如，使用 host.example.com，而不是 host。这样，如果服务器的位置移动，则不必更改连接字符串。

验证 ADO.NET 身份验证请求和连接

本示例显示如何使用 IntegratedSecurity=true 设置指定通过 ADO.NET 驱动程序对呼叫用户的 Windows 凭据进行身份验证：

VerticaConnection conn = new
VerticaConnection("Database=VMart;Server=host.example.com;
Port=5433;IntegratedSecurity=true;
KerberosServiceName=vertica;KerberosHostname=vcluster.example.com");
conn.open();

验证 vsql 身份验证请求和连接

例如，以 EXAMPLE\kuser 身份登录到您的 Windows 客户端。

运行 vsql 客户端，并向 Vertica 提供连接字符串：

C:\Users\kuser\Desktop>vsql.exe -h host.example.com -K vcluster -U kuser

Welcome to vsql, the Vertica Analytic Database interactive terminal.
Type:  \h or \? for help with vsql commands
\g or terminate with semicolon to execute query
\q to quit

另请参阅

1.15.2.3 - 在所有平台上配置 JDBC 客户端

JDBC 客户端上的 Kerberos 身份验证采用 Java 身份验证和授权服务 (JAAS) 获得初始 Kerberos 凭据。JAAS 是一种 API 框架，可隐藏平台特定的身份验证详细信息并为其他应用程序提供一致的界面。

通过 JAAS 登录配置文件可指定客户端登录过程。此文件包含指定用于 Kerberos 的身份验证方法和其他设置的选项。名为 LoginModule 的类定义配置文件中的有效选项。

JDBC 客户端主体设计为 jdbc-username@server-from-connection-string。

实施 LoginModule

Vertica 建议您使用 Java 运行时环境 (JRE) 中提供的 JAAS 公共类 com.sun.security.auth.module.Krb5LoginModul。

Krb5LoginModule 使用 Kerberos 协议验证用户身份，并且在非 Windows 和 Windows 平台上的实施方式不同：

在非 Windows 平台上： Krb5LoginModule 遵从本机 Kerberos 客户端实施。因此，您可以使用用于在 Linux 和 MAC OSX 平台上配置 ODBC 和 vsql 客户端的相同 /etc/krb5.conf 设置。
在 Windows 平台上： Krb5LoginModule 采用 Java 运行时环境 (JRE) 捆绑的自定义 Kerberos 客户端实施。Windows 设置存储在 %WINDIR%\krb5.ini 文件中，该文件的语法和约定与非 Windows krb5.conf 文件类似。可以从非 Windows 客户端复制 krb5.conf 到 %WINDIR%\krb5.ini 中。

您可以在 com.sun.security.auth 程序包和 Krb5LoginModule 网页上找到 LoginModules 的文档。

创建 JAAS 登录配置

JAASConfigName 连接属性用于标识包含 Krb5LoginModule 及其设置的 JAAS 配置中的特定配置。JAASConfigName 设置允许多个具有不同 Kerberos 设置的 JDBC 应用程序在一个主机中共存。默认配置名称为 verticajdbc。

重要

请认真构建 JAAS 登录配置文件。如果语法不正确，身份验证会失败。

您可以在 java.security 主安全属性文件中配置 JAAS 相关的设置。此文件位于 JRE 的 lib/security 目录中。有关详细信息，请参阅《Java^TM 身份验证和授权服务 (JAAS) 参考指南》中的附录 A。

创建 JDBC 登录上下文

以下示例显示如何为 JDBC 客户端上的 Kerberos 身份验证创建登录上下文。该客户端使用 JAASConfigName 的默认 verticajdbc，并指定：

从票证缓存中获得许可票证
如果无法从缓存、keytab 文件或通过共享状态获得凭据，系统不会提示用户输入密码。

verticajdbc {
  com.sun.security.auth.module.Krb5LoginModule
  required
  useTicketCache=true
  doNotPrompt=true;
};

JDBC 身份验证请求和连接

可以将 Krb5LoginModule 配置为使用缓存的票证或 keytab。另外，如果呼叫用户提供密码，驱动程序也可以自动获得票证或 keytab。

在上一示例中，登录进程之所以使用缓存的票证且不提示输入密码，是因为 useTicketCache 和 doNotPrompt 均设置为 true。如果设置 doNotPrompt=false 并在登录过程中提供用户名和密码，则驱动程序会向 LoginModule 提供该信息。然后，该驱动程序将代表您调用 kinit 实用程序。

在 JDBC 客户端上，调用 kinit 实用程序以获得票证：
```
$ kinit kuser@EXAMPLE.COM
```
如果您希望使用密码而不调用 kinit 实用程序，请参阅下一节。

连接到 Vertica：

Properties props = new Properties();
props.setProperty("user", "kuser");
props.setProperty("KerberosServiceName", "vertica");
props.setProperty("KerberosHostName", "vcluster.example.com");
props.setProperty("JAASConfigName", "verticajdbc");
Connection conn = DriverManager.getConnection
"jdbc:vertica://myserver.example.com:5433/VMart", props);

通过驱动程序获取票证

有时，您可能希望自己绕过调用 kinit 实用程序，但仍使用加密的双向身份验证。在这些情况下，可以选择向驱动程序传递明文密码以便从 KDC 获取票证。密码在网络中发送时为加密状态。例如，在以下示例中，useTicketCache 和 doNotPrompt 均为 false。因此，无法通过票证缓存或 keytab 获得呼叫用户的凭据。

$ verticajdbc  {
  com.sun.security.auth.module.Krb5LoginModule
  required
  useTicketCache=false
  doNotPrompt=false;
};

上一示例演示了 JAAS 的灵活性。驱动程序不再查找缓存的票证，而您无需调用 kinit。相反，驱动程序将使用密码和用户名并代表您调用 kinit。

另请参阅

1.15.3 - Kerberos 身份验证故障排除

这些提示有助于您避免 Vertica 的 Kerberos 身份验证的相关问题，并对产生的任何问题进行故障排除。

JDBC 客户端身份验证失败

如果在 JDBC 客户端上进行 Kerberos 身份验证失败，请检查 JAAS 登录配置文件是否存在语法问题。如果语法不正确，身份验证会失败。

未配置工作域名服务 (DNS)

确认网络上的 DNS 条目和系统主机文件 (/etc/hosts or /etc/hostnames) 均针对您的环境进行了适当的配置。如果您使用的是完全限定域名，请确保其也已正确配置。有关详细信息，请参阅适用于您的平台的 Kerberos 文档。

系统时钟不同步

您网络中的系统时钟必须保持同步，Kerberos 身份认证才能正常进行。如果您访问 HDFS 中的数据，则 Vertica 节点还必须与 Hadoop 同步。

除 Red Hat 7/CentOS 7 之外的所有系统

要保持系统时钟同步，请执行以下操作：

在 Kerberos 服务器 (KDC) 上安装 NTP。
在您网络中的每台服务器上安装 NTP。
针对所有参与 Kerberos 领域，距离 KDC 以及其他每台服务器相隔仅数分钟的所有机器，同步其系统时钟

对于需要与 Windows Time Service 同步的 Linux 虚拟机，可能会存在时钟偏差问题。采用以下步骤保持时间同步：

使用任意文本编辑器，打开 /etc/ntp.conf。
在 Undisciplined Local Clock 部分下方，添加 Vertica 服务器的 IP 地址。然后，删除现有服务器条目。
以 root 身份登录到服务器，并设置一个 cron 作业，用来与添加的 IP 地址同步时间，每半小时同步一次或按需要的频率同步。例如：
```
# 0 */2 * * * /etc/init.d/ntpd restart
```
或者，运行以下命令来强制立即同步时钟：
```
$ sudo /etc/init.d/ntpd restart
```

有关详细信息，请参阅启用网络时间协议 (NTP)和网络时间协议网站。

Red Hat 7/CentOS 7 系统

在 Red Hat 7/CentOS 7 中，为了更侧重于 chrony，弃用了 ntpd。要使您网络中的系统时钟保持同步，以便 Kerberos 身份验证能正常进行，请执行以下操作：

在 Kerberos 服务器 (KDC) 上安装 chrony。
在您网络中的每台服务器上安装 chrony。
针对所有参与 Kerberos 领域，距离 KDC 以及其他每台服务器相隔仅数分钟的所有机器，同步其系统时钟。

Linux 虚拟机上的时钟偏差

对于需要与 Windows Time Service 同步的 Linux 虚拟机，可能会存在时钟偏差问题。采用以下步骤保持时间同步：

使用任意文本编辑器，打开 /etc/chrony.conf。
在 Undisciplined Local Clock 部分下方，添加 Vertica 服务器的 IP 地址。然后，删除现有服务器条目。
以 root 身份登录到服务器，并设置一个 cron 作业，用来与添加的 IP 地址同步时间，每半小时同步一次或按需要的频率同步。例如：
```
# 0 */2 * * * systemctl start chronyd
```
或者，运行以下命令来强制立即同步时钟：
```
$ sudo systemctl start chronyd
```

有关详细信息，请参阅 Red Hat chrony 指南。

Kerberos 票证有效，但 Hadoop 访问失败

Vertica 使用 Kerberos 票证获取 Hadoop 令牌。然后使用 Hadoop 令牌访问 Hadoop 数据。Hadoop 令牌会在一段时间后过期，所以 Vertica 会定期刷新。但是，如果您的 Hadoop 群集设定使得令牌频繁过期，则令牌可能无法及时刷新。如果令牌过期，您将无法访问数据。

通过设置 HadoopFSTokenRefreshFrequency 配置参数，您可以指定 Vertica 刷新令牌的频率。指定值（以秒为单位）应该小于设置的 Hadhoop 到期期限。例如：

=> ALTER DATABASE exampledb SET HadoopFSTokenRefreshFrequency = '86400';

有关 Hadoop 访问失败的另一个原因，请参阅系统时钟不同步。

加密算法选项

Kerberos 基于对称加密。要确保 Kerberos 领域中使用的 Kerberos 各方都同意使用某加密算法。如果不同意，身份验证就会失败。您可以在 vertica.log 中查看异常。

在 Windows 客户端上，要确保加密类型与在 Active Directory 上设置的类型相匹配。请参阅为 Kerberos 身份验证配置 Vertica。

请注意，Kerberos 仅用于保护登录进程的安全。在登录进程完成后，客户端和服务器之间的信息传输默认不加密。如果您想要对信息传输进行加密，请使用 SSL。有关详细信息，请参阅实施 SSL。

Kerberos 密码未能识别

如果您更改了 Kerberos ，则必须重新创建所有的 keytab 文件。

使用 ODBC 数据源配置实用程序

在 Windows vsql 客户端上，您可以选择使用 ODBC 数据源配置实用程序并为客户端提供数据源。若如此，请务必在“客户端设置 (Client Settings)”选项卡中输入 Kerberos 主机名，以避免客户端无法连接 Vertica 分析型数据库服务器。

备份、还原或管理工具身份验证失败

若配置中各 Vertica 节点使用其各自的 Kerberos 主体，则可能产生这个问题。（推荐此配置。）使用 VBR 或 admintools 时，您可能会看到诸如以下的错误：

$ vsql: GSSAPI continuation error: Miscellaenous failure
GSSAPI continuation error: Server not found in Kerberos database

备份/还原以及管理工具将使用用于验证的 Kerberos 主体中的 KerberosHostname 值（若设置了此值）。所有节点都使用相同的值。如果您如推荐的那样，为每个节点都定义了一个 Kerberos 主体，此值将不匹配。要予以更正，请取消设置 KerberosHostname 参数：

=> ALTER DATABASE DEFAULT CLEAR KerberosHostname;

服务器的主体名与主机名不匹配

若配置中所有节点都使用同一个 Kerberos 主体，则可能产生这个问题。Vertica 不推荐对所有节点使用同一个 Kerberos 主体。相反，请为每个节点使用不同的主体，而且不要设置 KerberosHostname 参数。

在某些情况下，连接客户端时，Vertica 服务器的主体名可能与连接字符串中的主机名不匹配。（另请参阅本主题中的使用 ODBC 数据源配置实用程序。）

在 Windows vsql 客户端上，您可以选择使用 ODBC 数据源配置实用程序并为客户端提供数据源。若如此，请务必在“客户端设置 (Client Settings)”选项卡中输入 Kerberos 主机名，以避免客户端无法连接 Vertica 服务器。

在 ODBC、JDBC 和 ADO.NET 客户端上，使用 KerberosHostName 连接字符串设置服务器主体的主机名部分。

提示

在 vsql 客户端上，使用 -K KRB HOST 命令行操作设置服务器主体名的主机名部分。默认值由 -h 开关指定，它是运行 Vertica 服务器的计算机的主机名。 -K 等同于驱动程序的 KerberosHostName 连接字符串值。

有关详细信息，请参阅命令行选项。

主体/主机不匹配问题和解决方案

如果主体和主机不匹配，可能会出现以下问题。

KerberosHostName 配置参数被覆盖

例如，考虑以下连接字符串：

jdbc:vertica://v_vmart_node0001.example.com/vmart?user=kuser

由于此连接字符串不包含显式 KerberosHostName 参数，驱动程序默认其为 URL (v_vmart_node0001.example.com) 下的主机。如果您覆盖服务器端 KerberosHostName 参数，使之为“abc”，客户端将生成不正确的主体。

要解决这个问题，请将客户端 KerberosHostName 显式设置为连接字符串，如本例所示：

jdbc:vertica://v_vmart_node0001.example.com/vmart?user=kuser&kerberoshostname=abc

连接负载均衡功能已启用 ，但客户端进行验证的节点可能不是连接字符串中的节点。

在这种情况下，请考虑更改所有节点，以使用相同的 KerberosHostName 设置。当您使用最初在连接字符串中指定的默认主机时，负载均衡将无法干扰 Kerberos 身份验证。

DNS 名与 Kerberos 主机名不匹配

例如，假定群集中有六台服务器，您想让 hr-servers 和 finance-servers 连接到 Vertica 群集中的不同节点。但 Kerberos 身份验证发生在单个（相同的）KDC 上。在以下示例中，服务器的 Kerberos 服务主机名为 server.example.com。

假设您拥有下列示例服务器：

server1.example.com 192.16.10.11
server2.example.com 192.16.10.12
server3.example.com 192.16.10.13
server4.example.com 192.16.10.14
server5.example.com 192.16.10.15
server6.example.com 192.16.10.16

现在，假定您拥有下列 DNS 条目：

finance-servers.example.com 192.168.10.11, 192.168.10.12, 192.168.10.13
hr-servers.example.com 192.168.10.14, 192.168.10.15, 192.168.10.16

当您连接到 finance-servers.example.com 时，指定：

Kerberos -h 主机名选项为 server.example.com
hr-servers.example.com 的 -K 主机选项

例如：

$ vsql -h finance-servers.example.com -K server.example.com

未在客户端计算机上设置 DNS ，所以您只能通过 IP 连接

要解决这个问题，指定：

该 IP 地址的 Kerberos -h 主机名选项
server.example.com 的 -K 主机选项

例如：

$ vsql -h 192.168.1.12 -K server.example.com

涉及到负载均衡器（虚拟 IP） ，但 VIP 没有 DNS 名

指定：

Virtual IP 地址的 Kerberos -h 主机名选项
server.example.com 的 -K 主机选项

例如：

$ vsql -h <virtual IP> -K server.example.com

您使用 IP 地址连接到 Vertica ，但没有用来构建 Kerberos 主体名的主机名。

如通知 Vertica 有关 Kerberos 主体的信息中所述，为 Vertica 提供实例或主机名

将服务器端 KerberosHostName 配置参数设置为 Vertica 节点主机名之外的名称 ，但客户端无法仅根据连接字符串中的主机名来确定主机名。

重置 KerberosHostName，以匹配 Vertica 节点的主机名的名称。有关详细信息，请参阅以下主题：

1.16 - LDAP 身份验证

轻型目录访问协议 (LDAP) 身份验证方法的工作原理与密码身份验证类似。主要差异在于，LDAP 方法通过 LDAP 或 Active Directory 服务器对尝试访问您的 Vertica 数据库的客户端进行身份验证。当您的数据库需要通过 LDAP 或 Active Directory 服务器验证用户身份时，请使用 LDAP 身份验证。

1.16.1 - LDAP 先决条件和定义

先决条件

在为 Vertica 数据库配置 LDAP 身份验证前，您必须具有：

LDAP 服务器的 IP 地址和主机名。Vertica 支持 IPv4 和 IPv6 地址。
组织的 Active Directory 信息。
用于搜索和捆绑的服务账户。
对 Vertica 数据库的管理访问权限。
open-ldap-tools 程序包至少安装在一个节点上。该包包括 ldapsearch。

定义

对于 LDAP 身份验证，记住以下定义非常重要：

1.16.2 - LDAP 身份验证参数

LDAP 身份验证需要配置几个参数。

常规 LDAP 参数

使用下列参数配置 LDAP 绑定或 LDAP 绑定和搜索：

LDAP 绑定参数

以下参数将创建一个绑定名称字符串，用于指定并唯一标识 LDAP 服务器的用户。有关详细信息，请参阅配置 LDAP 捆绑的工作流程。

要创建绑定名称字符串，必须设置以下内容之一（且只能设置一项）：

binddn_prefix 和 binddn_suffix（必须一起设置）
domain_prefix
email_suffix

例如，如果您设置了 binddn_prefix 和 binddn_suffix，则不能设置 email_suffix。相反，如果设置了 email_suffix，则不能设置 binddn_prefix 和 binddn_suffix。

如果未设置绑定参数，Vertica 将执行绑定和搜索操作，而不是绑定操作。

以下示例使用身份验证记录 v_ldap：

=> CREATE AUTHENTICATION v_ldap METHOD 'ldap' HOST '10.0.0.0/23';

LDAP 搜索和绑定参数

使用 LDAP 搜索和绑定进行身份验证时，使用以下参数。有关详细信息，请参阅LDAP 搜索和捆绑配置工作流。

以下示例演示了如何设置这三个属性。在本例中，设置为：

binddn 到 cn=Manager,dc=example,dc=com
bind_password 到 secret
search_attribute 到 cn

=> ALTER AUTHENTICATION auth_method_name SET host='ldap://example13',
basedn='dc=example,dc=com',binddn='cn=Manager,dc=example,dc=com',
bind_password='secret',search_attribute='cn';

binddn 和 bind_password 参数是可选的。如果忽略，Vertica 将执行匿名搜索。

1.16.3 - LDAP 身份验证的 TLS

Vertica 在两个上下文中建立到 LDAP 服务器的连接，每个上下文都有一个对应的 TLS CONFIGURATION，用于控制每个连接是否应使用 TLS：

LDAPLink：使用 LDAPLink 服务或其试运行功能在 Vertica 和 LDAP 服务器之间同步用户和组。
LDAPAuth：当具有 ldap 身份验证方法的用户尝试登录 Vertica 时，Vertica 会尝试将该用户绑定到 LDAP 服务器中的匹配用户。如果绑定成功，Vertica 将允许用户登录。

查询 TLS_CONFIGURATIONS 以查看现有的 TLS CONFIGURATION：

=> SELECT * FROM tls_configurations WHERE name IN ('LDAPLink', 'LDAPAuth');
   name   |  owner  | certificate | ca_certificate | cipher_suites |  mode
----------+---------+-------------+----------------+---------------+----------
 LDAPLink | dbadmin | client_cert | ldap_ca        |               | VERIFY_CA
 LDAPAuth | dbadmin | client_cert | ldap_ca        |               | DISABLE
(2 rows)

本页介绍 LDAPAuth 上下文。有关 LDAPLink 上下文的详细信息，请参阅 LDAP Link 的 TLS。

请注意，为 LDAP 身份验证配置 TLS 不会使用 TLS 对 Vertica 与客户端之间的连接进行加密。要配置客户端-服务器 TLS，请参阅配置客户端-服务器 TLS。

配置 LDAP 身份验证

客户端与 Vertica 成功建立连接后，它们必须以用户身份进行身份验证，然后才能与数据库进行交互。如果用户具有 ldap 身份验证方法，Vertica 将连接到 LDAP 服务器以对用户进行身份验证。要为此上下文配置 TLS，请使用以下过程。

设置 LDAPAuth TLS 配置

LDAPAuth TLS 配置采用客户端证书和使用 CREATE CERTIFICATE 创建或导入的 CA 证书。Vertica 会将客户端证书提供给 LDAP 服务器以供其 CA 进行验证。Vertica 使用 CA 证书来验证 LDAP 服务器的证书。

有关密钥和证书生成的详细信息，请参阅生成 TLS 证书和密钥。

如果您希望 Vertica 在建立连接之前验证 LDAP 服务器的证书，请生成或导入 CA 证书并将其添加到 LDAPAuth TLS 配置中。

例如，要导入现有的 CA 证书 LDAP_CA.crt：
```
=> \set ldap_ca '\''`cat ldap_ca.crt`'\''
=> CREATE CA CERTIFICATE ldap_ca AS :ldap_ca;
CREATE CERTIFICATE
```
然后，将 ldap_ca CA 证书添加到 LDAPAuth：
```
ALTER TLS CONFIGURATION LDAPAuth ADD CA CERTIFICATES ldap_ca;
```
如果您的 LDAP 服务器需要验证客户端证书，您必须生成或导入客户端证书及其密钥，并将其添加到 LDAPAuth TLS 配置中。Vertica 会将此证书提供给 LDAP 服务器以供其 CA 进行验证。

例如，要导入现有的证书 client.crt（由导入的 CA 签名）和密钥 client.key：
```
=> \set client_key '\''`cat client.key`'\''
=> CREATE KEY client_key TYPE 'RSA' AS :client_key;
CREATE KEY

=> \set client_cert '\''`cat client.crt`'\''
=> CREATE CERTIFICATE client_cert AS :client_cert SIGNED BY ldap_ca KEY client_key;
CREATE CERTIFICATE
```
然后，将 client_cert 添加到 LDAPAuth：
```
=> ALTER TLS CONFIGURATION LDAPAuth CERTIFICATE client_cert;
```
通过将 TLSMODE 设置为以下之一来启用 TLS 或 LDAPS（使用的确切协议取决于 AUTHENTICATION 对象中 host 的值）。 TRY_VERIFY 或更高版本需要 CA 证书：
- ENABLE：启用 TLS。Vertica 不检查 LDAP 服务器的证书。
- TRY_VERIFY：如果出现以下任一情况，则建立 TLS 连接：
  - LDAP 服务器提供一个有效的证书。
  - LDAP 服务器不提供证书。
  如果 LDAP 服务器提供无效证书，则使用纯文本连接。
- VERIFY_CA：如果 Vertica 验证 LDAP 服务器的证书来自受信任的 CA，则连接成功。使用此 TLSMODE 会强制所有没有证书的连接使用纯文本。
- VERIFY_FULL：如果 Vertica 验证 LDAP 服务器的证书来自受信任的 CA 并且 cn（通用名称）或 subjectAltName 属性与 LDAP 服务器的主机名或 IP 地址匹配，则连接成功。
  
  cn 用于用户名，因此 subjectAltName 必须与 LDAP 服务器的主机名或 IP 地址匹配。
例如：
```
=> ALTER TLS CONFIGURATION LDAPAuth TLSMODE 'verify_ca';
ALTER TLS CONFIGURATION
```

验证 LDAPAuthConfigParameter 参数是否正在使用 TLS 配置：

=> SHOW CURRENT LDAPAuthTLSConfig;
  level  |       name        | setting
---------+-------------------+----------
 DEFAULT | LDAPAuthTLSConfig | LDAPAuth
(1 row)

启用身份验证记录：

=> ALTER AUTHENTICATION ldap_auth ENABLE;

创建 LDAP 身份验证记录

客户端与 Vertica 成功建立连接后，它们必须以用户身份进行身份验证，然后才能与数据库进行交互。如果用户具有 ldap 身份验证方法，Vertica 将连接到 LDAP 服务器并尝试绑定以对用户进行身份验证。

要查看现有的身份验证记录，请查询 CLIENT_AUTH。

有关此过程中引用的参数的详细信息，请参阅 LDAP 身份验证参数。

创建具有 LDAP 方法的身份验证记录。

用于创建 LDAP 身份验证记录的语法：
```
=> CREATE AUTHENTICATION auth_record_name method 'ldap' HOST 'user_connection_source';
```
例如，要创建适用于从任何主机连接的用户的 LDAP 身份验证记录：
```
=> CREATE AUTHENTICATION ldap_auth METHOD 'ldap' HOST '0.0.0.0/0';
```
更改身份验证类型，以设置 LDAP 服务器的主机和端口（可选）以及域名 (basedn)，并绑定可分辨名称 (binddn)。
- 要在 Vertica 和 LDAP 服务器之间使用明文连接，请将 host URL 设置为以 ldap:// 开头，并将 LDAPAuth 的 TLSMODE 设置为 DISABLE。
- 要使用 StartTLS，请将 host URL 设置为以 ldap:// 开头，并将 LDAPAuth 的 TLSMODE 设置为 ENABLE 或更高。
- 要使用 LDAPS，请将 host URL 设置为以 ldaps:// 开头，并将 LDAPAuth 的 TLSMODE 设置为 ENABLE 或更高。
例如，要在位于端口 5389 上且 IP 地址为 192.0.2.0 的 LDAP 服务器上搜索 Active Directory orgunit.example.com 中的用户：
```
=> ALTER AUTHENTICATION ldap_auth SET
    host='ldap://192.0.2.0:5389',
    basedn='ou=orgunit,dc=example,dc=com',
    binddn_prefix='cn=',
    binddn_suffix=',ou=orgunit,dc=example,dc=com';
```
binddn_prefix 和 binddn_suffix 结合起来可创建完整 DN。也就是说，对于 Vertica 用户 asmith，' cn=asmith,ou=orgunit,dc=example,dc=com' 是 Vertica 尝试绑定时的完整 DN。
将身份验证记录授予用户或角色。

例如：
```
=> GRANT AUTHENTICATION ldap_auth TO asmith;
```
在这种情况下，当用户 asmith 尝试登录时，Vertica 会通过 ldap_auth 中指定的搜索库构建可分辨名称 'cn=asmith,ou=orgunit,dc=example,dc=com'，然后连接到 LDAP 服务器，并尝试将其绑定到 Vertica 用户。如果绑定成功，Vertica 将允许 asmith 登录。

1.16.4 - LDAP 的身份验证 fallthrough

要为单个 LDAP 服务器使用多个搜索属性或配置多个 LDAP 服务器，请为每个搜索属性或服务器创建单独的身份验证记录，并在每个 ldap 记录（最后一个除外）上启用身份验证 fallthrough（按优先级顺序）。

示例

以下示例创建了两个身份验证记录，vldap1 和 vldap2。它们一起指定 LDAP 服务器应首先搜索整个目录 (basedn=dc=example,dc=com) 中 OU 属性为 Sales 的 DN。如果第一个搜索没有返回结果或失败，LDAP 服务器接下来将搜索 OU 属性为 Marketing 的 DN：

=> CREATE AUTHENTICATION vldap1 method 'ldap' HOST '10.0.0.0/8' FALLTHROUGH;
=> ALTER AUTHENTICATION vldap1 PRIORITY 1;
=> ALTER AUTHENTICATION vldap1
      SET host='ldap://ldap.example.com/search',
      basedn='dc=example,dc=com',
      search_attribute='Sales';
=> GRANT AUTHENTICATION vldap1 to public;

=> CREATE AUTHENTICATION vldap2 method 'ldap' HOST '10.0.0.0/8';
=> ALTER AUTHENTICATION vldap2 PRIORITY 0;
=> ALTER AUTHENTICATION vldap2 SET
      host='ldap://ldap.example.com/search',
      basedn='dc=example,dc=com',
      search_attribute='Marketing';
=> GRANT AUTHENTICATION vldap2 to public;

1.16.5 - LDAP 绑定方法

您可以使用以下两种 LDAP 方法来在 LDAP 服务器上对 Vertica 数据库进行身份验证。

绑定 — 当 Vertica 连接到 LDAP 服务器并使用 CN 和密码绑定时，使用 LDAP 绑定。（这些值是登录到数据库的用户的用户名和密码）。当您的 LDAP 帐户的 CN 字段与数据库中定义的用户名的 CN 字段匹配时，使用捆绑方法。有关详细信息，请参阅配置 LDAP 捆绑的工作流程。
搜索和绑定 — 当您的 LDAP 帐户的 CN 字段是用户的全称或与数据库中定义的用户名不匹配时，使用 LDAP 搜索和绑定。对于搜索和捆绑，用户名通常在另一个字段中，如标准 Active Directory 环境中的 UID 或 sAMAccountName。搜索和捆绑需要组织的 Active Directory 信息。这些信息能让 Vertica 登录到 LDAP 服务器并搜索指定的字段。有关详细信息，请参阅LDAP 搜索和捆绑配置工作流。

如果您正在使用搜索和捆绑，可通过服务帐户简化服务器端配置。此外，您无需存储 Active Directory 密码。

LDAP 匿名绑定

Anonymous binding 是一个 LDAP 服务器函数。匿名捆绑不需要 binddn 和 bindpasswd，因此允许客户无需登录即可连接和搜索目录（捆绑和搜索）。

当您使用管理控制台 (Management Console) 配置 LDAP 身份验证时，也不需要登录。

1.16.5.1 - 配置 LDAP 捆绑的工作流程

要配置您的 Vertica 数据库，以使用 LDAP 捆绑对客户端进行身份验证，请遵循以下步骤：

获取服务帐户。有关信息，请参阅 [LDAP 产品文档](https://msdn.microsoft.com/en-us/library/aa772152(v=vs.85)。您无法使用连接参数中的服务帐户进行 LDAP 捆绑。

比较用户的 LDAP 帐户名及其 Vertica 用户名。例如，如果 John Smith 的 Active Directory (AD) sAMAccountName = jsmith，他的 Vertica 用户名必须是 jsmith。

但是，LDAP 帐户不必与数据库用户名匹配，如以下示例中所示：

=> CREATE USER r1 IDENTIFIED BY 'password';
=> CREATE AUTHENTICATION ldap1  METHOD 'ldap' HOST '172.16.65.177';
=> ALTER AUTHENTICATION ldap1 SET HOST=
   'ldap://172.16.65.10',basedn='dc=dc,dc=com',binddn_suffix=',ou=unit2,dc=dc,dc=com',binddn_prefix='cn=use';
=> GRANT AUTHENTICATION ldap1 TO r1;

\! ${TARGET}/bin/vsql -p $PGPORT -U r1 -w $LDAP_USER_PASSWD -h ${HOSTNAME} -c
   "select user_name, client_authentication_name from sessions;"
 user_name | client_authentication_name
-----------+----------------------------
 r1        | ldap
(1 row)

针对您的 LDAP 或 AD 服务器从一个 Vertica 节点运行 ldapsearch。验证到服务器的连接，并确定相关字段的值。运行 ldapsearch 有助于构建配置 LDAP 身份验证所需的客户端身份验证字符串。

在下述示例中，对于其 CN 包含用户名 jsmith 的任何用户，ldapsearch 将返回 CN、DN 和 sAMAccountName 字段（若存在）。此搜索只有对允许匿名捆绑的 LDAP 服务器执行才会成功：
```
$ ldapsearch -x -h 10.10.10.10 -b "ou=Vertica Users,dc=CompanyCorp,dc=com"
'(cn=jsmith*)' cn dn uid sAMAccountName
```
ldapsearch 返回以下结果。LDAP 捆绑的相关信息显示为粗体：
```
# extended LDIF
#
# LDAPv3
# base <ou=Vertica Users,dc=CompanyCorp,dc=com> with scope subtree
# filter: (cn=jsmith*)
# requesting: cn dn uid sAMAccountName
#
# jsmith, Users, CompanyCorp.com
dn:cn=jsmith,ou=Vertica Users,dc=CompanyCorp,dc=com
cn: jsmith
uid: jsmith
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
```

基于 ldapsearch 提供的信息创建新的身份验证记录。在 ldapsearch 条目中，CN 是用户名 jsmith，所以您无需设置它。Vertica 自动将 CN 设置为尝试建立连接的用户的用户名。Vertica 使用该 CN 捆绑 LDAP 服务器。

=> CREATE AUTHENTICATION v_ldap_bind METHOD 'ldap' HOST '0.0.0.0/0';
=> GRANT AUTHENTICATION v_ldap_bind TO public;
=> ALTER AUTHENTICATION v_ldap_bind SET
host='ldap://10.10.10.10/',
basedn='DC=CompanyCorp,DC=com',
binddn_prefix='cn=',
binddn_suffix=',OU=Vertica Users,DC=CompanyCorp,DC=com';

有关详细信息，请参阅 LDAP 捆绑参数。

1.16.5.2 - LDAP 搜索和捆绑配置工作流

要配置您的 Vertica 数据库，以使用 LDAP 搜索和捆绑对客户端进行身份验证，请遵循以下步骤：

获取服务帐户。有关信息，请参阅 [LDAP 产品文档](https://msdn.microsoft.com/en-us/library/aa772152(v=vs.85)。
从一个 Vertica 节点针对您的 LDAP 或 AD 运行 ldapsearch。验证到服务器的连接，并确定相关字段的值。运行 ldapsearch 有助于构建配置 LDAP 身份验证所需的客户端身份验证字符串。

在下述示例中，对于其 CN 中包含用户名 John 的任何用户，ldapsearch 将返回 CN、DN 和 sAMAccountName fields 字段（若存在）。此搜索只有对允许匿名捆绑的 LDAP 服务器执行才会成功：
```
$ ldapsearch -x -h 10.10.10.10 -b 'OU=Vertica Users,DC=CompanyCorp,DC=com' -s sub -D
'CompanyCorp\jsmith' -W '(cn=John*)' cn dn uid sAMAccountName
```

查看 ldapsearch 返回的结果。搜索和捆绑的相关信息显示为粗体：

# extended LDIF
#
# LDAPv3
# base <OU=Vertica Users,DC=CompanyCorp,DC=com> with scope subtree
# filter: (cn=John*)
# requesting: cn dn sAMAccountName
#
# John Smith, Vertica Users, CompanyCorp.com
dn: CN=jsmith,OU=Vertica Users,DC=CompanyCorp,DC=com
cn: Jsmith
sAMAccountName: jsmith
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

创建客户端身份验证记录。cn 属性包含您想要的用户名 — jsmith。将您的搜索属性设置为 CN 字段，以便搜索找到相应帐户。

=> CREATE AUTHENTICATION v_ldap_bind_search METHOD 'ldap' HOST '10.10.10.10';
=> GRANT AUTHENTICATION v_ldap_bind_search TO public;
=> ALTER AUTHENTICATION v_ldap_bind_search SET
host='ldap://10.10.10.10',
basedn='OU=Vertica,DC=CompanyCorp,DC=com',
binddn='CN=jsmith,OU=Vertica Users,DC=CompanyCorp,DC=com',
bind_password='password',
search_attribute='CN';

有关详细信息，请参阅 LDAP 绑定和搜索参数

1.17 - OAuth 2.0 身份验证

用户无需使用用户名和密码即可向 Vertica 验证身份，具体操作为：首先通过身份提供程序验证其身份，然后接收 OAuth 令牌并将令牌传递给 Vertica。

Vertica 中的 OAuth 通过 Keycloak 和 Okta 进行测试，但如果其他提供程序支持 RFC 7662 令牌自省标准，也可以使用。

1.17.1 - 配置 OAuth 身份验证

有关 ODBC OAuth 连接属性的列表，请参阅 ODBC DSN 连接属性。

以下过程将：

配置 Keycloak 18.0。
创建 OAuth 身份验证记录。
使用 POST 请求检索访问令牌。
使用示例应用程序 sample application 向 Vertica 验证身份，并将访问令牌作为实参和令牌刷新参数（可选）传递。

配置 keycloak

以下过程将在 203.0.113.1 上配置 Keycloak 18.0.0 服务器。

使用 TLS（可选）

如果要使用 TLS，您必须获取由受信任的 CA 签名的 Keycloak 证书和密钥。为方便起见，此示例将使用自签名 CA。

生成 CA 证书：

=> CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;
CREATE KEY

=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/C N=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;
CREATE CERTIFICATE

生成由您的 CA 签名的服务器密钥和证书，将证书的 subjectAltName 设置为您的 Keycloak 服务器的 DNS 和/或 IP 地址：

=> CREATE KEY keycloak_key TYPE 'RSA' LENGTH 2048;
CREATE KEY

=> CREATE CERTIFICATE keycloak_cert
SUBJECT '/C=US/ST=Massachussets/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Server'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Keycloak CA', 'extendedKeyUsage' = 'serverAuth', 'subjectAltName' = 'DNS.1:dnsserver,IP:203.0.113.1'
KEY keycloak_key;
CREATE CERTIFICATE

使用生成的密钥的 key 列内容创建文件 keycloak_directory/conf/keyfile.pem：
```
=> SELECT key FROM cryptographic_keys WHERE name = 'keycloak_key';
```
使用生成的证书的 certificate_text 列内容创建文件 keycloak_directory/conf/certfile.pem：
```
=> SELECT certificate_text FROM certificates WHERE name = 'keycloak_cert';
```
将生成的 CA 证书的 certificate_text 列内容附加到系统的 CA 捆绑包中。默认 CA 捆绑包路径和格式因分发版而异；有关详细信息，请参阅 SystemCABundlePath：
```
=> SELECT certificate_text FROM certificates WHERE name = 'SSCA_cert';
```

设置 SystemCABundlePath 配置参数：

=> ALTER DATABASE DEFAULT SET SystemCABundlePath = 'path/to/ca_bundle';

启动 keycloak

输入以下命令获取最小配置，以创建 Keycloak 管理员并在 start-dev 模式下启动 Keycloak：

$ KEYCLOAK_ADMIN=kcadmin
$ export KEYCLOAK_ADMIN
$ KEYCLOAK_ADMIN_PASSWORD=password
$ export KEYCLOAK_ADMIN_PASSWORD
$ cd keycloak_directory/bin/
$ ./kc.sh start-dev --hostname 203.0.113.1 --https-certificate-file ../conf/certfile.pem --https-certificate-key-file=../conf/keyfile.pem

使用浏览器打开 Keycloak 控制台（这些示例使用默认端口）：
- 对于 HTTP：http://203.0.113.1:8080
- 对于 HTTPS：http://203.0.113.1:8443
以管理员身份登录。
（可选）为了更加方便地测试 OAuth，请导航到领域设置 (Realm Settings) > 令牌 (Tokens)，然后将访问令牌生命期 (Access Token Lifespan) 增加到更大的值（默认值为 5 分钟）。

创建 Vertica 客户端

导航到客户端 (Clients) 并单击创建 (Create)。此时会显示添加客户端 (Add Client) 页面。
在客户端 ID (Client ID) 中，输入 vertica。
单击保存 (Save)。此时会显示客户端配置页面。
在设置 (Settings) 选项卡中，使用访问类型 (Access Type) 下拉菜单选择机密 (confidential)。
在凭据 (Credentials) 选项卡中，记下密码 (Secret)。这是用于在令牌过期时刷新令牌的客户端密码。

创建 Keycloak 用户

Keycloak 用户可映射到同名的 Vertica 用户。此示例创建了一个 Keycloak 用户 oauth_user。

在用户 (Users) 选项卡中，单击添加用户 (Add user)。此时会显示添加用户 (Add user) 页面。
在用户名 (Username) 中，输入 oauth_user。
在凭据 (Credentials) 选项卡中，输入密码。

配置 Vertica

创建身份验证记录

为 OAuth 创建身份验证记录。

client_id：机密客户端 vertica 在 Keycloak 中注册。
client_secret：客户端密钥，由 Keycloak 生成。
discovery_url：也称为 OpenID 提供者配置文档，这是包含有关身份提供者的配置和端点的信息的端点。

=> CREATE AUTHENTICATION v_oauth METHOD 'oauth' HOST '0.0.0.0/0'
=> ALTER AUTHENTICATION v_oauth SET client_id = 'vertica';
=> ALTER AUTHENTICATION v_oauth SET client_secret = 'client_secret';
=> ALTER AUTHENTICATION v_oauth SET discovery_url = 'https://203.0.113.1:8443/realms/myrealm/.well-known/openid-configuration';
=> ALTER AUTHENTICATION v_oauth SET introspect_url = 'https://203.0.113.1:8443/realms/myrealm/protocol/openid-connect/token/introspect';

创建 Vertica 用户

Vertica 用户可映射到用户名相同的 Keycloak 用户。

要映射到 Keycloak 用户 oauth_user，请创建一个同名的 Vertica 用户。无需指定密码，因为身份验证由身份提供程序执行：
```
=> CREATE USER oauth_user;
```

将 OAuth 身份验证记录授予用户（或其角色）：

=> GRANT AUTHENTICATION v_oauth TO oauth_user;
=> GRANT ALL ON SCHEMA PUBLIC TO oauth_user;

检索访问令牌

获取 OAuth 访问令牌的一种简单方法是将 POST 请求发送到令牌端点，同时提供 Keycloak 用户的凭据。例如，oauth_user：

$ curl --location --request POST 'http://203.0.113.1:8080/realms/master/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'username=oauth_user' \
--data-urlencode 'password=oauth_user_password' \
--data-urlencode 'client_id=vertica' \
--data-urlencode 'client_secret=client_secret' \
--data-urlencode 'grant_type=password'

如果身份验证正确，Keycloak 会以 JSON 的格式作出响应。然后，您可以将返回的访问令牌、刷新令牌和范围与相应的连接属性一起使用。

{
   "access_token":"access_token",
   "expires_in":60,
   "refresh_expires_in":1800,
   "refresh_token":"refresh_token",
   "token_type":"Bearer",
   "not-before-policy":0,
   "session_state":"6745892a-aa74-452f-b6b9-c45637193859",
   "scope":"profile email"
}

运行示例应用程序

在令牌过期之前，OAuth 示例应用程序至少会将访问令牌作为实参来对数据库进行身份验证。如果您希望示例应用程序在令牌过期后刷新令牌，您必须指定以下内容。示例应用程序会将这些内容放入 JSON 字符串：OAuthJsonConfig 或 (ODBC) oauthjsonconfig (JDBC)。

刷新令牌
客户端 ID
客户端密码
令牌 URL

ODBC

遵循 README 中的说明。

运行示例应用程序，同时将 OAuth 参数作为实参传递：

在令牌过期之前进行身份验证：

$ ./a.out --access-token OAuthAccessToken

在访问令牌过期后进行身份验证并静默刷新访问令牌：

$ ./a.out --access-token OAuthAccessToken
    --refresh-token OAuthRefreshToken
    --client-id OAuthClientID
    --client-secret OAuthClientSecret
    --token-url OAuthTokenURL

JDBC

遵循 README 中的说明。

运行示例应用程序，同时将 OAuth 参数作为实参传递：

在令牌过期之前进行身份验证：

$ mvn compile exec:java -Dexec.mainClass=OAuthSampleApp -Dexec.args="vertica_host database_name --access-token oauthaccesstoken"

在访问令牌过期后进行身份验证并静默刷新访问令牌：

$ mvn compile exec:java -Dexec.mainClass=OAuthSampleApp -Dexec.args="vertica_host database_name --access-token oauthaccesstoken
    --refresh_token oauthrefreshtoken
    --client-id oauthclientid
    --client-secret oauthclientsecret
    --token-url oauthtokenurl"

故障排除

要获取 TLS 的调试信息，请使用 -Djavax.net.debug=ssl 标记。

将 CA 证书导入 Java 信任库

如果您通过 TLS 配置身份提供程序（即，如果您对令牌或刷新 URL 使用 HTTPS 端点），且其证书不是由熟知的 CA 颁发的，则必须使用 keytool 导入颁发机构的 CA 证书。

例如，将证书 keycloak/cert.crt 添加到 Java 信任库：

$ keytool -trustcacerts -keystore /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.261-2.6.22.2.el7_8.x86_64/jre/lib/security/cacerts -storepass changeit -importcert -alias keycloak -file /keycloak/cert.crt

1.18 - TLS 身份验证

tls 身份验证方法使用在常用名 (CN) 字段中指定有效数据库用户名的证书，对可以建立相互模式客户端-服务器 TLS 连接的用户进行身份验证。

在创建和使用 tls 身份验证方法之前，必须将 Vertica 配置为使用相互模式客户端-服务器 TLS（默认情况下禁用）。

1.18.1 - 使用 TLS 进行客户端身份验证

获授tls身份验证记录的数据库用户或角色可以使用 TLS 证书向 Vertica 验证身份。

先决条件

必须将 Vertica 配置为使用相互模式客户端-服务器 TLS。

在相互模式下，客户端和服务器在连接之前必须验证彼此的身份。在此模式下，Vertica 可验证客户端的身份，且可以通过其证书对客户端进行身份验证。

配置 TLS 身份验证

以下部分将为客户端生成一个私钥和证书。为简单起见，该示例使用以下自签名 CA 证书 SSCA_cert 对客户端证书进行签名（在该示例的上下文中，该自签名证书还对 Vertica 数据库的服务器证书进行签名）。

=> CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;
=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;

而在生产环境中，则应该使用来自受信任证书颁发机构的 CA 证书。

以下示例将 Vertica 配置为使用包含方法 tls 的身份验证记录来对数据库用户 Bob 进行身份验证：

生成客户端的私钥：

=> CREATE KEY client_key_bob TYPE 'RSA' LENGTH 2048;

生成客户端的证书，同时为常用名 (CN) 字段指定数据库用户。此示例为数据库用户 Bob 创建了一个证书：

=> CREATE CERTIFICATE client_cert_bob
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Bob/emailAddress=bob@example.com'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Vertica client cert', 'extendedKeyUsage' = 'clientAuth'
KEY client_key_bob;

导出客户端的私钥和证书：

$ vsql -At -c "SELECT key FROM cryptographic_keys WHERE name = 'client_key_bob';" -o client_key_bob.key
$ vsql -At -c "SELECT certificate_text FROM certificates WHERE name = 'client_cert_bob';" -o client_cert_bob.crt

将证书复制或移动到客户端认可的位置。此示例适用于 vsql：

$ mkdir -p ~/.vsql
$ cp client_cert_bob.crt ~/.vsql/client.crt
$ cp client_key_bob.key ~/.vsql/client.key
$ chmod 600 ~/.vsql/client.key ~/.vsql/client.crt
$ chown -R bob ~/.vsql ~/.vsql/client.key ~/.vsql/client.crt

创建 tls 身份验证记录：

=> CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0';

将身份验证记录授予 Bob 或其默认角色之一：
```
=> GRANT AUTHENTICATION v_tls_auth TO Bob;
```

拒绝明文连接

您可以创建拒绝来自指定 IP 范围的远程连接的身份验证记录。

例如，要拒绝所有纯文本的客户端连接，按如下所示指定 reject 身份验证方法和 HOST NO TLS 访问方法：

=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '0.0.0.0/0';  --IPv4
=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '::/0';       --IPv6

2 - 节点间 TLS

节点间 TLS 用于保护群集内节点之间的通信。如果您不信任节点之间的网络，请务必保护节点之间的通信。

在设置节点间 TLS 之前，请使用 SECURITY_CONFIG_CHECK 检查配置的当前状态。

=> SELECT SECURITY_CONFIG_CHECK('NETWORK');

服务器节点之间的通信使用两个通道：控制通道和数据通道。要启用节点间加密，请设置 EncryptSpreadComm 参数（默认情况下禁用）以对控制通道上的 Spread 通信进行加密，并配置 data_channel TLS CONFIGURATION 以对数据通道进行加密：

使用 EncryptSpreadComm 对控制通道上的 Spread 通信进行加密。有关详细信息，请参阅控制通道 Spread TLS。
使用 data_channel TLS CONFIGURATION 对数据通道进行加密。有关详细信息，请参阅数据通道 TLS。

如果启用节点间加密，某些查询的运行速度可能会比预期慢。您的性能体验取决于发送的数据和网络质量。

Admintools 会生成或检索 spread 密钥以对控制通道上的所有流量进行加密，并将 spread 密钥发送到所有节点。Vertica 使用 TLS 对数据通道上的所有流量进行加密。TLS 凭据通过加密的控制通道在节点之间共享。

下图描述了节点间加密过程。

另请参阅

2.1 - 控制通道 Spread TLS

控制信道允许节点相互交换计划信息，并在节点之间分配调用。启用 Spread 安全可保护此通信。有关详细信息，请参阅节点间 TLS。

节点间 TLS 使用以下两个通道。在设置其他参数之前，必须按以下顺序启用这两个通道：

控制通道用于交换计划信息和分配调用。它是使用 Spread 实现的。有关详细信息，请访问 spread.org。
数据通道用于交换表数据。它是使用 TCP 实现的。

启用 EncryptSpreadComm

EncryptSpreadComm 可以设置为以下两个值之一：

vertica。Vertica 在数据库启动时为群集生成 Spread 加密密钥。
aws-kms|<key_name>。Vertica 在数据库启动时从 AWS Key Management Service 获取用户指定的密钥，而不是自己生成密钥。

通常情况下，您应该在设置任何其他安全参数之前设置 EncryptSpreadComm 参数，以启用 Spread 加密。

使用 ALTER DATABASE 设置 EncryptSpreadComm 参数。

=> ALTER DATABASE DEFAULT SET PARAMETER EncryptSpreadComm = 'vertica';

重新启动数据库。
使用 SECURITY_CONFIG_CHECK 验证您的设置。
```
=> SELECT SECURITY_CONFIG_CHECK('NETWORK');
```

权限

超级用户

限制

设置此参数后，必须重新启动数据库。

示例

这将启用 EncryptSpreadComm 参数，并告知 Vertica 在下次数据库启动时生成一个 Spread 加密密钥。

=> ALTER DATABASE DEFAULT SET PARAMETER EncryptSpreadComm = 'vertica';

有关此安全参数和其他安全参数的详细信息，请参阅安全性参数。

另请参阅

2.2 - 数据通道 TLS

节点在查询等操作期间使用数据通道交换表数据。

节点间通信使用以下通道。在启用其他组件之前，必须按以下顺序启用其关联的组件和参数：

控制通道，以交换计划信息并分发调用。它是使用 Spread 实现的。有关详细信息，请访问 spread.org。
数据通道，以交换表数据。它是使用 TCP 实现的。

配置数据通道 TLS

此过程在 Vertica 节点之间配置 TLS，并使用预定义的 TLS 配置 data_channel。要使用自定义 TLS 配置，请参阅 TLS 配置。

在控制通道上启用 TLS。

生成或导入以下项：

CA（证书颁发机构）证书。

例如，要创建自签名 CA 证书，请生成密钥并使用该密钥对 CA 证书进行签名：

=> CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;

=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;

节点间 TLS 证书的私钥。

例如，使用 CREATE KEY 生成密钥：
```
=> CREATE KEY internode_key TYPE 'RSA' LENGTH 2048;
```

**节点间 TLS 证书。**这必须有一个以 CA 结尾的完整链，且必须是 x509v1 证书或使用 extendedKeyUsage 扩展 serverAuth 和 clientAuth。

例如，要生成 internode_cert 并使用 SSCA_cert 对其进行签名：

=> CREATE CERTIFICATE internode_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=data channel'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Vertica internode cert', 'extendedKeyUsage' = 'serverAuth, clientAuth'
KEY internode_key;

在 data_channel TLS 配置中设置证书。对于数据通道 TLS，TLSMODE 自动设置为 VERIFY_CA，且不应更改。
```
=> ALTER TLS CONFIGURATION data_channel CERTIFICATE internode_cert;
```

验证 InternodeTLSConfig 参数是否正在使用 TLS 配置：

=> SHOW CURRENT InternodeTLSConfig;
  level  |        name        |   setting
---------+--------------------+--------------
 DEFAULT | InternodeTLSConfig | data_channel
(1 row)

验证是否已使用 SECURITY_CONFIG_CHECK('NETWORK') 启用数据通道加密：

=> SELECT SECURITY_CONFIG_CHECK('NETWORK');
   SECURITY_CONFIG_CHECK
---------------------------
 Spread security details:
* EncryptSpreadComm = [vertica]
Spread encryption is enabled
It is now safe to set/change other security knobs

Data Channel security details:
 TLS Configuration 'data_channel' TLSMODE is VERIFY_CA
TLS on the data channel is enabled

特权

超级用户

限制

通常，您应在配置 data_channel 之前设置 EncryptSpreadComm。
对 data_channel 的更改将立即生效，且中断所有正在进行的查询，以更新节点之间的连接。

另请参阅

3 - TLS 协议

TLS（传输层安全）是一种加密协议，用于保护服务器、服务器节点以及客户端之间的通信。

启用后，Vertica 数据库和连接到它的客户端将使用 TLS 1.2。

尽管 TLS、SSL 和 TLS/SSL 通常可以互换使用，但 Vertica 文档始终使用 TLS 来引用协议。某些 Vertica 参数和组件使用 SSL，在这些情况下，文档会使用 SSL 来引用这些参数和组件，但这些也可以归类在 TLS 结构下。

启用 TLS 是一个多步骤过程。首先，使用 SECURITY_CONFIG_CHECK 检查您的安全配置的状态。然后，您可以配置 TLS 身份验证记录以拒绝非 TLS 连接。

3.1 - TLS 概述

要实现安全通信并验证数据完整性，您可以将 Vertica 和数据库客户端配置为使用 TLS。TLS 协议使用密钥和证书交换系统以及受信任的第三方（称为证书颁发机构 (CA)）。证书的所有者和依赖于证书的另一方都必须信任 CA 来确认证书持有者的身份。

Vertica 还支持以下使用传输层安全 (TLS) v1.2 协议的身份验证方法。两种方法均会对传输中数据进行加密并验证其完整性：

服务器模式 - 在服务器模式下，客户端在连接之前必须确认服务器的身份。客户端验证服务器的证书和公钥有效并且由客户端的可信 CA 列表中列出的证书颁发机构 (CA) 发布。这有助于防止中间人攻击。
相互模式 - 在相互模式下，客户端和服务器在连接之前必须验证彼此的身份。

除了此部分详述的要求外，您还必须创建 TLS 身份验证记录以拒绝非 TLS 客户端连接。

TLS 握手过程

下面简要概述了客户端在服务器模式 下验证服务器身份时可能使用的“握手”过程。服务器在相互模式 下识别客户端身份时所采取的其他操作也标记为如此。

公钥和私钥对 - 密钥对由客户端和服务器生成。公钥的所有者必须由证书颁发机构验证。密钥对用于加密消息。例如，假设 Alice 想发送机密数据给 Bob。由于她只希望 Bob 读取数据，因此使用 Bob 的公钥加密数据。即使其他人获得了加密数据的访问权限，数据也仍然受到保护。因为只有 Bob 可以访问其相应的私钥，他是唯一可以将 Alice 的加密数据解密为原始形态的人。

证书 - 证书包含公钥，且用于标识密钥的所有者。它们由证书颁发机构 (CA) 颁发。

证书颁发机构 (CA) - 证书颁发机构是验证公钥所有者身份的受信任方。

客户端和服务器随机数 - 客户端随机数和服务器随机数是用于创建共享密钥的随机字符串，如果握手成功，该密钥会对通信进行加密。

在连接之前，服务器和客户端会生成自己的公钥和私钥对。然后，CA 会将标识证书分发给服务器和客户端，以获取它们各自的公钥。
客户端将其客户端随机数发送到服务器，并请求获取服务器的证书。
服务器将其证书和使用其私钥加密的服务器随机数发送给客户端。在相互模式 下，服务器还会请求获取客户端的证书。
在相互模式 下，客户端发送其证书。
客户端使用证书来验证服务器是否拥有其公钥，然后使用服务器的公钥解密服务器随机数，以验证服务器是否拥有其私钥。
在相互模式 下，服务器使用证书来验证客户端是否拥有其公钥。
服务器和客户端使用客户端和服务器随机数生成一个新的密码，称为会话密钥，用于加密未来的通信。

3.1.1 - TLS 配置

TLS 配置是一个数据库对象，它封装了配置 TLS 所需的所有设置和证书。设置 TLS 配置后，您可以通过将其设置为以下一个或多个数据库参数的值来使用该配置，其中每个参数都控制着 Vertica 数据库与客户端或服务器之间某种类型连接的 TLS：

ServerTLSConfig
HttpsTLSConfig
LDAPLinkTLSConfig
LDAPAuthTLSConfig
InternodeTLSConfig

这些参数默认设置为预定义的 TLS 配置，因此如果您只想配置 TLS，则应使用 ALTER TLS CONFIGURATION 来修改预定义的 TLS 配置。否则，您可以使用 CREATE TLS CONFIGURATION 来创建自定义 TLS 配置。

重用现有 TLS 配置

要重用现有 TLS 配置，请使用 ALTER TLS CONFIGURATION。

下表列出了每个 TLS 连接类型参数及其关联的连接类型和预定义的 TLS 配置：

创建自定义 TLS 配置

您可以使用 CREATE TLS CONFIGURATION 创建 TLS 配置。

以下示例将创建一个 TLS 配置，并通过在 ServerTLSConfig 中设置该配置来为客户端-服务器 TLS 启用它：

创建密钥和证书：


-- create CA certificate
=> CREATE KEY k_ca TYPE 'RSA' LENGTH 4096;
=> CREATE CA CERTIFICATE ca
   SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Root CA'
   VALID FOR 3650
   EXTENSIONS 'nsComment' = 'Vertica generated root CA cert'
   KEY k_ca;

-- create server certificate
=> CREATE KEY k_server TYPE 'RSA' LENGTH 2048;
=> CREATE CERTIFICATE server
    SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Cluster/emailAddress=example@example.com'
    SIGNED BY ca
    KEY k_server;

创建 TLS 配置：

=> CREATE TLS CONFIGURATION new_tls_config CERTIFICATE server_cert TLSMODE 'ENABLE';

将 ServerTLSConfig 参数设置为对客户端-服务器 TLS 使用新的 TLS 配置：
```
=> ALTER DATABASE SET DEFAULT PARAMTER ServerTLSConfig=new_tls_config;
```

3.1.2 - 生成 TLS 证书和密钥

此页面举例说明如何使用 CREATE KEY 和 CREATE CERTIFICATE 生成证书和密钥。要查看密钥和证书，请查询 CRYPTOGRAPHIC_KEYS 和 CERTIFICATES 系统表。

有关创建签名证书的更多详细信息，OpenSSL 建议使用 OpenSSL 手册。

有关 x509 扩展的更多详细信息，请参阅安全套接字层密码库 (OpenSSL) 文档。

导入密钥和证书

键

如果您打算使用其关联的证书来签署某些内容，例如客户端-服务器 TLS 中的消息或其他证书，则仅需导入私钥。即：只有在关联证书为以下之一时，才需要导入密钥：

客户端/服务器证书
在 Vertica 中用于签署其他证书的 CA 证书

如果仅需 CA 证书来验证其他证书，则无需导入其私钥。

导入私钥：

=> CREATE KEY imported_key TYPE 'RSA' AS '-----BEGIN PRIVATE KEY-----...-----END PRIVATE KEY-----';

证书

要导入仅验证其他证书（无私钥）的 CA 证书：

=> CREATE CA CERTIFICATE imported_validating_ca AS '-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----';

要导入可以验证和签署其他证书的 CA（需要私钥）：

=> CREATE CA CERTIFICATE imported_signing_ca AS '-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----'
KEY ca_key;

要导入客户端/服务器证书，您必须导入并指定其私钥和 CA：

=> CREATE CERTIFICATE imported_cert AS '-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----'
SIGNED BY imported_ca KEY imported_key;

生成私钥和证书

键

要生成 2048 位 RSA 私钥：

=> CREATE KEY new_key TYPE 'RSA' LENGTH 2048;

自签名 CA 证书

注意

CA 证书主体必须与其签署的证书主体不同。

CA 是受信任的实体，它们使用 CA 证书来签署和验证其他证书。以下示例将生成自签名的根 CA：

重要

尽管自签名 CA 证书很方便，但始终应在生产环境中使用正确的证书颁发机构。

生成或导入私钥：

=> CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;

使用以下格式生成并使用私钥签署证书：

=> CREATE CA CERTIFICATE certificate_name
SUBJECT '/C=country_code/ST=state_or_province/L=locality/O=organization/OU=org_unit/CN=Vertica Root CA'
VALID FOR days_valid
EXTENSIONS 'authorityKeyIdentifier' = 'keyid:always,issuer', 'nsComment' = 'Vertica generated root CA cert'
KEY ca_key;

例如：

=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;

中间 CA 证书

除了服务器证书，CA 还可以签署其他 CA 的证书。此过程将生成中间 CA，且在顶级 CA 和中间 CA 之间生成信任链。随后，这些中间 CA 可以签署其他证书。

注意

使用 CREATE CERTIFICATE 生成的中间 CA 证书不能签署其他 CA 证书。

生成或导入签署中间 CA 的 CA。以下示例生成并使用自签名根 CA：

=> CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;

=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;

生成或导入私钥：

=> CREATE KEY intermediate_key TYPE 'RSA' LENGTH 2048;

生成中间 CA 证书，指定其私钥并使用以下格式签署 CA：

=> CREATE CERTIFICATE intermediate_certificate_name
SUBJECT '/C=country_code/ST=state_or_province/L=locality/O=organization/OU=org_unit/CN=Vertica intermediate CA'
SIGNED BY ca_name
KEY intermediate_key;

例如：

=> CREATE CA CERTIFICATE intermediate_CA
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Intermediate CA'
SIGNED BY SSCA_cert
KEY intermediate_key;

客户端/服务器证书

CREATE CERTIFICATE 生成 x509v3 证书，允许您指定扩展来限制证书的使用方式。extendedKeyUsage 扩展的值将根据您的用例而有所不同：

服务器证书：
```
'extendedKeyUsage' = 'serverAuth'
```
客户证书：
```
'extendedKeyUsage' = 'clientAuth'
```

节点间加密的服务器证书：

'extendedKeyUsage' = 'serverAuth, clientAuth'

由于这些证书用于客户端/服务器 TLS，因此您必须导入或生成其私钥。

以下示例证书均由此自签名 CA 证书签名：

=> CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;

=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;

要生成服务器证书：

=> CREATE KEY server_key TYPE 'RSA' LENGTH 2048;

=> CREATE CERTIFICATE server_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica server/emailAddress=example@example.com'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Vertica server cert', 'extendedKeyUsage' = 'serverAuth'
KEY server_key;

要生成客户端证书：

=> CREATE KEY client_key TYPE 'RSA' LENGTH 2048;

=> CREATE CERTIFICATE client_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica client/emailAddress=clientexample@example.com'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Vertica client cert', 'extendedKeyUsage' = 'clientAuth'
KEY client_key;

要生成节点间 TLS 证书：

=> CREATE KEY internode_key TYPE 'RSA' LENGTH 2048;

=> CREATE CERTIFICATE internode_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=data channel'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Vertica internode cert', 'extendedKeyUsage' = 'serverAuth, clientAuth'
KEY internode_key;

3.1.3 - 配置客户端-服务器 TLS

Vertica 为客户端-服务器 TLS 提供两种连接模式：

在服务器模式 下，客户端必须验证主机的证书。主机必须具有服务器私钥和证书。
在相互模式 下，客户端和主机必须各自验证对方的证书。主机必须具有服务器私钥、服务器证书和 CA 证书。

客户端-服务器 TLS 用于保护 Vertica 与客户端之间的连接步骤，而不是将这些客户端作为数据库用户进行身份验证的以下身份验证步骤。要为 TLS 连接配置身份验证或拒绝明文连接，请参阅 TLS 身份验证。

使用 TLS 配置设置证书

此过程可为客户端-服务器 TLS 创建密钥和证书，并在预定义的 TLS 配置 server 中设置它们，这是 ServerTLSConfig 和 HttpsTLSConfig 的默认 TLS 配置。要创建自定义 TLS 配置，请参阅TLS 配置。

根据您的用例生成或导入以下内容：
- 服务器模式：服务器证书私钥、服务器证书
- 相互模式：服务器证书私钥、服务器证书、CA 证书
根据您所需的配置运行以下命令。新连接将使用 TLS。
- 要使用服务器模式，请为服务器的 TLS 配置设置服务器证书：
```
=> ALTER TLS CONFIGURATION server CERTIFICATE server_cert;
```
- 要使用相互模式，请设置服务器和 CA 证书。此 CA 证书用于验证客户端证书：
```
=> ALTER TLS CONFIGURATION server CERTIFICATE server_cert ADD CA CERTIFICATES ca_cert;
```
  要使用多个 CA 证书，请用逗号分隔它们：
```
=> ALTER TLS CONFIGURATION server CERTIFICATE server_cert
   ADD CA CERTIFICATES intermediate_ca_cert, ca_cert;
```
启用 TLS（默认情况下禁用）。选择以下按安全性升序列出的 TLSMODE 之一。
- DISABLE：禁用 TLS。此参数的所有其他选项都启用 TLS。
- ENABLE：启用 TLS。Vertica 不检查客户端证书。
- TRY_VERIFY：如果出现以下任一情况，则建立 TLS 连接：
  - 客户出示有效证书
  - 客户没有出示证书
  如果客户端提供无效证书，则连接将使用纯文本。
- VERIFY_CA：如果 Vertica 验证客户端证书来自受信任的 CA，则连接成功。如果客户端不提供客户端证书，则连接使用纯文本。
TLS 配置还支持 TLSMODE VERIFY_FULL，但客户端-服务器 TLS 和 HTTPS（参数分别为 ServerTLSConfig 和 HttpsTLSConfig）不支持此 TLSMODE，其行为类似于 VERIFY_CA。

对于服务器模式，选择 ENABLE：
```
=> ALTER TLS CONFIGURATION server TLSMODE 'ENABLE';
```
对于相互模式，选择 TRY_VERIFY 或更高版本：
```
=> ALTER TLS CONFIGURATION server TLSMODE 'VERIFY_CA';
```

验证 ServerTLSConfig 参数是否设置为 server TLS 配置：

=> SHOW CURRENT ServerTLSConfig;
  level  |      name       | setting
---------+-----------------+---------
 DEFAULT | HttpsTLSConfig  | server
(1 row)

如果没有，请设置 ServerTLSConfig 参数：

=> ALTER DATABASE DEFAULT SET ServerTLSConfig = 'server';

另请参阅

3.1.4 - 管理 CA 捆绑包

使用证书颁发机构 (CA) 捆绑包，可以将 CA 证书分组到一起，并使用它们来验证与数据库的连接。

您可以通过查询 CA_BUNDLES 系统表来查看现有 CA 捆绑包。

创建 CA 捆绑包

要创建 CA 捆绑包，请使用创建 CA 捆绑包并指定一个或多个 CA 证书。如果您没有指定 CA 证书，则 CA 捆绑包将为空。

此示例创建一个名为 ca_bundle 的 CA 捆绑包，其中包含 CA 证书 root_ca 和 root_ca2：

=> CREATE CA BUNDLE ca_bundle CERTIFICATES root_ca, root_ca2;
CREATE CA BUNDLE

=> SELECT * FROM ca_bundles WHERE name='ca_bundle';
        oid        |   name    |       owner       |              certificates
-------------------+-----------+-------------------+----------------------------------------
 45035996274026954 | ca_bundle | 45035996273704962 | [45035996274026764, 45035996274026766]
(1 row)

修改现有 CA 捆绑包

CA_BUNDLES 仅存储 OID。由于对 CA 捆绑包的操作需要证书和所有者名称，因此可以使用以下查询将捆绑包映射到证书和所有者名称：

=> SELECT user_name AS owner_name,
       owner     AS owner_oid,
       b.name    AS bundle_name,
       c.name    AS cert_name
FROM   (SELECT name,
               STRING_TO_ARRAY(certificates) :: array[INT] AS certs
        FROM   ca_bundles) b
       LEFT JOIN certificates c
              ON CONTAINS(b.certs, c.oid)
       LEFT JOIN users
              ON user_id = owner
ORDER  BY 1;

 owner_name |     owner_oid     | bundle_name  | cert_name
------------+-------------------+--------------+-----------
 dbadmin    | 45035996273704962 | ca_bundle    | root_ca
 dbadmin    | 45035996273704962 | ca_bundle    | ca_cert
(2 rows)

添加和移除 CA 证书

如果您拥有 CA 捆绑包的所有权，则可以使用 ALTER CA BUNDLE 添加和移除证书。

此示例通过添加 ca_cert 和移除 root_ca2 来修改 ca_bundle：

=> ALTER CA BUNDLE ca_bundle ADD CERTIFICATES ca_cert;
ALTER CA BUNDLE

=> SELECT * FROM ca_bundles WHERE name='ca_bundle';
        oid        |   name    |       owner       |                       certificates
-------------------+-----------+-------------------+-----------------------------------------------------------
 45035996274027356 | ca_bundle | 45035996273704962 | [45035996274027342, 45035996274027348, 45035996274027396]
(1 row)

=> ALTER CA BUNDLE ca_bundle REMOVE CERTIFICATES root_ca2;
ALTER CA BUNDLE

=> SELECT * FROM CA_BUNDLES;
        oid        |   name    |       owner       |              certificates
-------------------+-----------+-------------------+----------------------------------------
 45035996274027356 | ca_bundle | 45035996273704962 | [45035996274027342, 45035996274027396]
(1 row)

管理 CA 捆绑包所有权

超级用户和 CA 捆绑包所有者可以通过查询 CA_BUNDLES 系统表来查看捆绑包是否存在，但只有给定捆绑包的所有者才能看到其中的证书。

在以下示例中，dbadmin 用户拥有 ca_bundle。将捆绑包的所有权授予“Alice”后，dbadmin 无法再看到捆绑包中的证书：

=> => SELECT * FROM ca_bundles WHERE name='ca_bundle';
        oid        |   name    |       owner       |              certificates
-------------------+-----------+-------------------+----------------------------------------
 45035996274027356 | ca_bundle | 45035996273704962 | [45035996274027342, 45035996274027396]
(1 row)

=> ALTER CA BUNDLE ca_bundle OWNER TO Alice;
ALTER CA BUNDLE

=> SELECT * FROM ca_bundles WHERE name='ca_bundle';
        oid        |   name    |       owner       | certificates
-------------------+-----------+-------------------+--------------
 45035996274027356 | ca_bundle | 45035996274027586 | []
(1 row)

删除 CA 捆绑包

您必须拥有 CA 捆绑包的所有权才能删除它：

=> DROP CA BUNDLE ca_bundle;
DROP CA BUNDLE

3.1.5 - 为 MC 生成证书和密钥

“证书签名请求 (CSR)”是在使用该证书的服务器上生成的加密文本块。您将证书签名请求发送到一个数字证书认证机构 (CA)，用于申请数字身份证书。数字证书认证机构根据您证书上的信息使用证书签名请求创建您的安全套接层 (SSL) 证书；例如组织名称、常用（域）名、城市、国家。

管理控制台 (MC) 使用 OAuth（开放授权）、安全套接字层 (SSL) 和本地加密密码的组合，来保障用户浏览器和 MC 以及 MC 和代理。身份验证通过 MC 发生，并发生在群集内的代理之间。代理也可对作业进行身份验证和授权。

MC 配置过程会自动设置 SSL，但您必须先在您的 Linux 环境中安装 openssl 程序包。

当通过客户端浏览器连接到 MC 时，Vertica 将为每个 HTTPS 请求分配一个包含时间戳的自签名证书。为增强安全性和防止密码重播攻击，时间戳仅在几秒钟内有效，随后就会过期。

为避免遭到 MC 阻拦，请同步 Vertica 群集内各个主机的时间，以及 MC 主机的时间（如果该主机位于专用服务器上）。要从丢失同步或缺乏同步中恢复，请重新同步系统时间和网络时间协议 (Network Time Protocol)。

创建证书并提交证书用于签名

在产品环境中，永远使用由数字证书认证机构签名的证书。您可以创建并提交证书，并且当数字证书认证机构返回证书时，将证书导入 MC。

使用 openssl 命令生成新的 CSR，在提示时输入密码“password”：

$ sudo openssl req -new -key /opt/vconsole/config/keystore.key -out server.csr
Enter pass phrase for /opt/vconsole/config/keystore.key:

您按下回车键 (Enter) 时，将会提示您输入即将纳入您的证书请求的信息。有些字段包含默认值，出于安全考虑，您需要进行更改。其他字段您可以不填写，比如密码和可选择的公司名称。留下空白字段，输入 '.'。

重要

-key 选项的 keystore.key 值为密钥库创建私有密钥。如果您生成新的密钥并使用管理控制台界面将它导入，MC 程序不会正常重启。您必须还原原始的 keystore.jks 文件，并重启管理控制台。

证书签名请求中包含此信息，并显示默认值和替换值：

Country Name (2 letter code) [GB]:USState or Province Name (full name) [Berkshire]:Massachusetts
Locality Name (eg, city) [Newbury]: Cambridge
Organization Name (eg, company) [My Company Ltd]:Vertica
Organizational Unit Name (eg, section) []:Information Management
Common Name (eg, your name or your server's hostname) []:console.vertica.com
Email Address []:mcadmin@vertica.com

常用名 (Commonn Name) 字段是您的服务器的完全限定域名。您的词条必须与您在网络浏览器上输入的内容完全匹配，否则您会收到名称不符合错误。

自签证书用于测试

为了测试您的新的安全套接层执行状态，条件允许情况下，您可以使用临时证书或您自己的内部数字证书认证机构，自签一份证书签名请求。

注意

自签的证书会产生基于浏览器的错误，提示您此份签名数字证书认证机构不存在，不可以信任。为了测试，请选择接受风险并继续。

以下命令会生成一份临时证书，证书在 365 天以后到期：

$ sudo openssl x509 -req -days 365 -in server.csr -signkey /opt/vconsole/config/keystore.key -out server.crt
Enter passphrase for /opt/vconsole/config/keystore.key:
Enter same passphrase again:

之前的案例提示您通行短语。这是启动 Apache 必须的步骤。执行通行短语，您必须将安全套接层通行短语对话直接放在恰当的 Apache 配置文件中。更多详细信息，请参见 Apache 文档。

此案例说明到终端窗口的命令输出：

Signature oksubject=/C=US/ST=Massachusetts/L=Cambridge/O=Vertica/OU=IT/
CN=console.vertica.com/emailAddress=mcadmin@vertica.com
Getting Private key

您现在可以将自签名密钥 server.crt 导入管理控制台。

另请参阅

3.1.6 - 将新证书导入 MC

使用此过程将新证书导入管理控制台。

注意

要为管理控制台生成新证书，您必须使用 keystore.key 文件，其位于安装 MC 的服务器上的 /opt/vconsole/config 中。任何其他生成的密钥/证书对都会导致 MC 错误地重新启动。然后，您必须还原原始的 keystore.jks 文件并重启管理控制台。请参阅为管理控制台生成证书和密钥。

连接到管理控制台，然后以管理员身份登录。
在主页上，单击 MC 设置 (Settings)。
在左侧的按钮面板中，单击 SSL 证书 (SSL certificates)。
在“上传新的 SSL 证书 (Upload a new SSL certificate)”右侧，单击浏览 (Browse) 以导入新密钥。
单击应用 (Apply)。
重启管理控制台。

3.1.7 - 替换代理证书

代理使用预安装的证书颁发机构 (CA) 证书。您可以将首选证书及其私钥复制到主机来替换它。

查看您当前的代理证书：

$ openssl s_client -prexit -connect database_IP:database_port

生成证书

如果您还没有证书，您可以生成自签名证书。有关详细信息，请参阅生成 TLS 证书和密钥

生成私钥和证书。

$ openssl req -new -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -out agent.cert -keyout agent.key

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:MA
Locality Name (eg, city) []:Cambridge
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:*.mycompany.com
Email Address []:myaddress@mycompany.com

制作 PEM 格式的证书副本。

$ openssl x509 -in agent.cert -out agent.pem -outform PEM

查看证书。
```
$ openssl x509 -in agent.pem -text
```

替换主机上的代理证书

以下过程用于在单个主机上替换代理的当前私钥和证书。要在整个群集中替换此证书和密钥，请对所有主机重复此过程。

停止主机上的代理服务。
```
$ /etc/init.d/vertica_agent stop
```

备份并重命名现有代理证书和密钥。


$ cd /opt/vertica/config/share
$ mv agent.cert agent.cert.bck
$ mv agent.key agent.key.bck
$ mv agent.p em agent.pem.bck

将新证书和密钥传输到主机的 /opt/vertica/config/share 目录。
```
$ scp agent.* root@123.12.12.123:/opt/vertica/config/share
```
将证书和密钥的所有者更改为 uidbadmin，将组更改为 verticadba。
```
$ chown installed_Vertica_user:installed_Vertica_group agent.*
```
将证书和密钥文件设为只读。
```
$ chmod -R 400 agent.*
```

启动代理服务。

$ /etc/init.d/vertica_agent start
starting agent
Opening PID file "/opt/vertica/log/agent.pid".
Overwriting /opt/vertica/log/agent_uidbadmin.log
Overwriting /opt/vertica/log/agent_uidbadmin.err
start OK for user: uidbadmin

验证您是否可以使用 API 密钥查看有关数据库的信息。

$ curl -X GET https://10.20.80.145:5444/databases -H "VerticaApiKey:wCgXny3Wm+8OhEvGkAclv7v9+VIlxgXblpr4rf" -k

验证代理是否正在使用新证书。

$ openssl s_client -prexit -connect 10.20.80.145:5444

3.1.8 - 使用 TLS 导入和导出数据

Vertica 使用 TLS 保护客户端和服务器之间的连接和通信。当您在 Vertica 群集之间导入或导出数据时，其中一个群集会充当客户端，这意味着您也可以使用 TLS 来保护该连接。

ImportExportTLSMode 参数控制导入或导出数据时 TLS 的严格性。

默认情况下，ImportExportTLSMode 设置为 PREFER。在此设置下，Vertica 会尝试使用 TLS 并回退到纯文本；您可以将其更改为始终要求加密，并进一步验证每个连接上的证书。有关导入和导出操作期间的 TLS 的更多信息，请参阅配置群集之间的连接安全。

4 - LDAP Link 服务

LDAP Link 可实现 LDAP 与 Vertica 服务器同步。从而不必在 LDAP 服务器和 Vertica 服务器上分别管理两套不同的用户和组或角色。使用 LDAP 同步，Vertica 服务器可作为 LDAP 服务器复制数据库使用。

自动同步

使用 LDAP Link 服务允许 Vertica 服务器与现有的目录服务（例如 MS Active Directory 或 OpenLDAP）深度整合。Vertica 服务器可自动同步：

LDAP 用户与 Vertica 用户进行同步
LDAP 组与 Vertica 角色进行同步

在 LDAP 服务器中管理所有用户和用户组属性。如果您是 Vertica 数据库管理员，只需要在用户和用户组上设置 Vertica 分析型数据库的访问权限。

使用编录中提供的 LDAP Link 连接参数配置 LDAP Link。有关详细信息，请参阅通用参数和连接参数。

使用试运行元函数配置 LDAP Link

通过 LDAP Link 试运行元函数，您可以在对数据库进行任何更改之前配置离散阶段中的服务。这些阶段为：

LDAP Link 绑定：在 LDAP 服务器和 Vertica 数据库之间建立连接
LDAP Link 搜索：在 LDAP 服务器中搜索用户和组
LDAP Link 同步：将 LDAP 用户和组映射到其在 Vertica 中的等效项

查询系统表 LDAP_LINK_DRYRUN_EVENTS，以查看每个试运行的结果。

有关试运行和配置 LDAP Link 的详细信息，请参阅使用试运行元函数配置 LDAP Link。

启用 LDAP Link

按以下所示启用 LDAP Link：

=> ALTER DATABASE dbname SET PARAMETER LDAPLinkURL='ldap://example.dc.com',
    LDAPLinkSearchBase='dc=DC,dc=com', LDAPLinkBindDN='CN=jsmith,OU=QA,DC=dc,DC=com,
    LDAPLinkBindPswd='password',LDAPLinkFilterUser='(objectClass=inetOrgPerson)', LDAPLinkFilterGroup='(objectClass=group)', LDAPLinkOn=1;
=> SELECT ldap_link_sync_start();

请参阅LDAP Link 参数。

LDAP Link 工作流

启用 LDAP Link 后，按照以下工作流进行同步：

系统管理员在 LDAP 服务器上创建用户和用户组。
系统管理员创建所需要的 LDAP Link 服务参数并启用这个服务。
通过使用 LDAP Link 服务，Vertica 分析型数据库可将 Application LDAP 的用户和用户组复制到 Vertica 数据库，以此创建 Vertica 用户和角色。
LDAP 服务器使用 Kerberos (KDC) 对登录 Vertica 的用户进行身份验证。
- LDAP 用户被分配正确的身份验证类型之后，可以登录 Vertica。
- 登录后，您可以使用 GRANT 语句授予用户权限或将其加入组。

注意

同步后，Vertica 用户并没有相关联的身份验证方法。要允许用户登录，您必须为用户分配一种身份验证方法。请参阅配置客户端身份验证。

4.1 - 使用试运行元函数配置 LDAP Link

Vertica 支持多个元函数，可让您在与 Vertica 同步之前调整 LDAP Link 设置。每个元函数都将 LDAP Link 参数作为实参，并测试 LDAP link 的一个单独部分：

LDAP_LINK_DRYRUN_CONNECT 连接 LDAP 服务器。
LDAP_LINK_DRYRUN_SEARCH 搜索 LDAP 用户和组。
LDAP_LINK_DRYRUN_SYNC 将 LDAP 用户和组映射和同步到其在 Vertica 中的等效项，从而相应地创建和孤立它们。

这些元函数旨在连续使用和测试，且其实参是累积的。也就是说，用于配置 LDAP_LINK_DRYRUN_CONNECT 的参数可用于 LDAP_LINK_DRYRUN_SEARCH，而这些函数的实参可用于 LDAP_LINK_DRYRUN_SYNC。

在移至下一个元函数之前，请务必查询 LDAP_LINK_DRYRUN_EVENTS 系统表以验证每个试运行的结果。

为试运行配置 TLS

与标准 LDAP Link 函数一样，LDAP Link 试运行函数从“LDAPLink”中提取 TLS 配置，以管理 TLS 连接。查询 TLS_CONFIGURATIONS 系统表以查看现有的 TLS 配置。

=> SELECT * FROM tls_configurations WHERE name='LDAPLink';
   name   |  owner  | certificate | ca_certificate | cipher_suites |  mode
----------+---------+-------------+----------------+---------------+---------
 LDAPLink | dbadmin | client_cert | ldap_ca        |               | DISABLE
(1 row)

有关为 LDAP Link 及其试运行函数配置 TLS 的说明，请参阅 LDAP Link 的 TLS。

配置 LDAP Link 绑定

在配置 LDAP 用户并将其导入 Vertica 之前，您必须先连接或“绑定”LDAP 服务器。连接通过几个参数进行管理。有关每个参数、相关函数、选项和默认值的详细信息，请参阅 LDAP Link 参数。

LDAP_LINK_DRYRUN_CONNECT 需要一个可分辨名称 (DN)、一个通过 LDAP 服务器进行身份验证的密码以及 LDAP 服务器的 URL。

要加密连接，请配置 LDAPLink TLS 配置。

通过为 LDAPLinkBindPswd 实参提供空字符串，您还可以执行匿名绑定（如果 LDAP 服务器允许未经身份验证的绑定）。

=> SELECT LDAP_LINK_DRYRUN_CONNECT('LDAPLinkURL','LDAPLinkBindDN','LDAPLinkBindPswd');

试运行绑定示例

这将测试 CN=amir,OU=QA,DC=dc,DC=com 中 DN 为 ldap://example.dc.com 的 LDAP 服务器连接。

=> SELECT LDAP_LINK_DRYRUN_CONNECT('ldap://example.dc.com','CN=amir,OU=QA,DC=dc,DC=com','password');

                ldap_link_dryrun_connect
---------------------------------------------------------------------------------
Dry Run Connect Completed. Query v_monitor.ldap_link_dryrun_events for results.

要检查绑定的结果，请查询系统表 LDAP_LINK_DRYRUN_EVENTS。

=> SELECT event_timestamp, event_type, entry_name, role_name, link_scope, search_base from LDAP_LINK_DRYRUN_EVENTS;
        event_timestamp       |       event_type      |      entry_name      | link_scope | search_base
------------------------------+-----------------------+----------------------+------------+-------------
2019-12-09 15:41:43.589398-05 | BIND_STARTED          | -------------------- | ---------- | -----------
2019-12-09 15:41:43.590504-05 | BIND_FINISHED         | -------------------- | ---------- | -----------

配置 LDAP Link 搜索

Vertica 和 LDAP 服务器成功建立连接后，您应该配置您的用户和组搜索空间并测试其正确性和效率。

要在 LDAP 服务器上搜索要导入数据库的用户和组，请同时将连接和搜索参数传递给 LDAP_LINK_DRYRUN_SEARCH 元函数。LDAP 服务器会返回一个用户和组列表作为响应，这些用户和组将使用给定参数导入 Vertica。

通过为 LDAPLinkBindPswd 实参提供空字符串，您还可以执行匿名搜索（如果 LDAP 服务器的访问控制列表 (ACL) 配置为允许未经身份验证的搜索）。允许匿名绑定的设置与允许匿名搜索的 ACL 设置不同。

=> SELECT LDAP_LINK_DRYRUN_SEARCH('LDAPLinkURL','LDAPLinkBindDN','LDAPLinkBindPswd','LDAPLinkSearchBase',
'LDAPLinkScope','LDAPLinkFilterUser','LDAPLinkFilterGroup','LDAPLinkUserName','LDAPLinkGroupName',
'LDAPLinkGroupMembers',[LDAPLinkSearchTimeout],['LDAPLinkJoinAttr']);

试运行搜索示例

这将在 LDAP 服务器中搜索用户和组。在这种情况下，LDAPLinkSearchBase 参数指定了 dc.com 域和子范围，它复制了 DN 下的整个子树。

为了进一步筛选结果，该函数将检查 objectClass 属性为 person 和 group 的用户和组。然后，它将搜索组属性 cn，使用 member 属性识别该组的成员，然后使用属性 uid 识别其中的个人用户。

=> SELECT LDAP_LINK_DRYRUN_SEARCH('ldap://example.dc.com','CN=amir,OU=QA,DC=dc,DC=com','$vertica$','dc=DC,dc=com','sub',
'(objectClass=person)','(objectClass=group)','uid','cn','member',10,'dn');

                ldap_link_dryrun_search
--------------------------------------------------------------------------------
Dry Run Search Completed. Query v_monitor.ldap_link_dryrun_events for results.

要检查搜索结果，请查询系统表 LDAP_LINK_DRYRUN_EVENTS。

=> SELECT event_timestamp, event_type, entry_name, ldapurihash, link_scope, search_base from LDAP_LINK_DRYRUN_EVENTS;
        event_timestamp          |    event_type    |       entry_name       | ldapurihash | link_scope | search_base
---------------------------------+------------------+------------------------+-------------+------------+--------------
2020-01-03 21:03:26.411753+05:30 | BIND_STARTED     | ---------------------- |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:26.422188+05:30 | BIND_FINISHED    | ---------------------- |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:26.422223+05:30 | SYNC_STARTED     | ---------------------- |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:26.422229+05:30 | SEARCH_STARTED   | **********             |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:32.043107+05:30 | LDAP_GROUP_FOUND | Account Operators      |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:32.04312+05:30  | LDAP_GROUP_FOUND | Administrators         |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:32.043182+05:30 | LDAP_USER_FOUND  | user1                  |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:32.043186+05:30 | LDAP_USER_FOUND  | user2                  |           0 | sub        | dc=DC,dc=com
2020-01-03 21:03:32.04319+05:30  | SEARCH_FINISHED  | **********             |           0 | sub        | dc=DC,dc=com

配置 LDAP Link 同步

配置搜索空间后，您将获取一个用户和组列表。LDAP 同步将 LDAP 用户和组映射到其在 Vertica 中的等效项。LDAPLinkUserName 映射到 Vertica 用户名，LDAPLinkGroupName 映射到 Vertica 角色。

=> SELECT LDAP_LINK_DRYRUN_SYNC('LDAPLinkURL','LDAPLinkBindDN','LDAPLinkBindPswd','LDAPLinkSearchBase',
'LDAPLinkScope','LDAPLinkFilterUser','LDAPLinkFilterGroup','LDAPLinkUserName','LDAPLinkGroupName',
'LDAPLinkGroupMembers',[LDAPLinkSearchTimeout],['LDAPLinkJoinAttr']);

试运行同步示例

要执行试运行以映射从 LDAP_LINK_DRYRUN_SEARCH 返回的用户和组，请将相同的参数作为实参传递给 LDAP_LINK_DRYRUN_SYNC。

=> SELECT LDAP_LINK_DRYRUN_SYNC('ldap://example.dc.com','CN=amir,OU=QA,DC=dc,DC=com','$vertica$','dc=DC,dc=com','sub',
'(objectClass=person)','(objectClass=group)','uid','cn','member',10,'dn');

                          LDAP_LINK_DRYRUN_SYNC
------------------------------------------------------------------------------------------
Dry Run Connect and Sync Completed. Query v_monitor.ldap_link_dryrun_events for results.

要检查同步结果，请查询系统表 LDAP_LINK_DRYRUN_EVENTS。

=> SELECT event_timestamp, event_type, entry_name, ldapurihash, link_scope, search_base from LDAP_LINK_DRYRUN_EVENTS;
        event_timestamp          |     event_type      |       entry_name       | ldapurihash | link_scope | search_base
---------------------------------+---------------------+------------------------+-------------+------------+--------------
2020-01-03 21:08:30.883783+05:30 | BIND_STARTED        | ---------------------- |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:30.890574+05:30 | BIND_FINISHED       | ---------------------- |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:30.890602+05:30 | SYNC_STARTED        | ---------------------- |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:30.890605+05:30 | SEARCH_STARTED      | **********             |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939369+05:30 | LDAP_GROUP_FOUND    | Account Operators      |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939395+05:30 | LDAP_GROUP_FOUND    | Administrators         |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939461+05:30 | LDAP_USER_FOUND     | user1                  |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939463+05:30 | LDAP_USER_FOUND     | user2                  |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939468+05:30 | SEARCH_FINISHED     | **********             |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939718+05:30 | PROCESSING_STARTED  | **********             |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939887+05:30 | USER_CREATED        | user1                  |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939895+05:30 | USER_CREATED        | user2                  |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939949+05:30 | ROLE_CREATED        | Account Operators      |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.939959+05:30 | ROLE_CREATED        | Administrators         |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.940603+05:30 | PROCESSING_FINISHED | **********             |           0 | sub        | dc=DC,dc=com
2020-01-03 21:08:31.940613+05:30 | SYNC_FINISHED       | ---------------------- |           0 | sub        | dc=DC,dc=com

4.2 - 使用 LDAP Link

使用 LDAP Link 会直接影响以下内容，而这些内容可帮助您管理和监控 LDAP Link - Vertica 分析型数据库同步：

用户和组管理
LDAP Link 用户标记
阻止的命令
客户端身份验证类型

要取消正在进行的同步，请使用 LDAP_LINK_SYNC_CANCEL。

用户和组管理

在 LDAP 服务器上创建的用户和组与复制到 Vertica 服务器的用户和角色具有特定关系：

当这些用户和组（角色）与 Vertica 分析型数据库同步时，LDAP 服务器上的用户-组关系将保持不变。
如果 Vertica 数据库中存在某个用户或组名称，当使用 LDAP Link 从 LDAP 服务器同步具有相同名称的用户或组时，用户或组会发生冲突。Vertica 无法支持具有相同名称的多个用户。要解决此问题，请参阅用户冲突。
如果 LDAP 服务器包含循环关系，Vertica 会接受并为 LDAP 服务器返回的关系的第一个非循环部分创建角色，并忽略其余部分。

例如，假设 LDAP 服务器包含组 A 和 B，其中 A 包含 B，且 B 包含 A，以此创建一个循环关系。

如果 LDAP 服务器首先返回 A 包含 B，Vertica 会创建角色 A 和 B，并将角色 A 授予角色 B。然后，Vertica 会忽略组 B 也包含 A 这一事实。

将用户同步到 Vertica 分析型数据库时，LDAP Link 会使用 LDAP 配置文件的 dn: 部分中的条目作为唯一用户标识符：

dn: cn=user1,ou=dev,dc=example,dc=com
cn: user1
ou: dev
id: user1

LDAP 配置文件中的 uid 参数表示 LDAP 用户名。

uid: user1

同步后，会将 dn: 条目映射到 uid:，以标识 Vertica 分析型数据库用户。

如果更改 dn: 中的设置但不更改 uid:，则在与 Vertica 分析型数据库重新同步时，LDAP Link 会将用户解释为新用户。在这种情况下，会将具有该 uid: 的现有 Vertica 分析型数据库用户从 Vertica 中删除，并创建一个新的 Vertica 分析型数据库用户。

如果在 LDAP 上更改 uid: 而不是 dn:，则会将 Vertica 分析型数据库上的 uid 更新为新的 uid。由于您没有更改 dn: LDAP Link 不会将用户解释为新用户。

LDAP Link 用户标记

作为 dbadmin 用户，您可以通过访问 vs_users 表来监控 Vertica 分析型数据库上的用户行为。用户表包含一个 ldap_dn 字段，用于标识 Vertica 分析型数据库用户是否也是 LDAP Link 用户。此示例中显示 ldap_dn 字段设置为 dn ，表示 Vertica 分析型数据库用户也是 LDAP Link 用户：

=> SELECT * FROM vs_users;
-[ RECORD 1 ]---------+--------------------------------------------------
user_id               | 45035996273704962
user_name             | dbadmin
is_super_user         | t
profile_name          | default
is_locked             | f
lock_time             |
resource_pool         | general
memory_cap_kb         | unlimited
temp_space_cap_kb     | unlimited
run_time_cap          | unlimited
max_connections       | unlimited
connection_limit_mode | database
idle_session_timeout  | unlimited
all_roles             | dbduser*, dbadmin*, pseudosuperuser*
default_roles         | dbduser*, dbadmin*, pseudosuperuser*
search_path           |
ldap_dn               | dn
ldap_uri_hash         | 0
is_orphaned_from_ldap | f

阻止的命令

请注意，对于在 vs_users 表中将 ldapdn 设置为 dn 的 Vertica 用户，会阻止以下 SQL 语句：

DROP USER 和 DROP ROLE
ALTER ROLE RENAME
ALTER USER name IDENTIFIED BY 'password' [REPLACE 'old_password']
ALTER USER name PASSWORD EXPIRE
ALTER USER name PROFILE
ALTER USER name SECURITY_ALGORITHM...
ALTER USER name DEFAULT ROLE role-name
授权（角色）

客户端身份验证类型

如果未向用户或组分配客户端身份验证，LDAP 用户和组将无法登录 Vertica。您可以为 LDAP 用户和组使用以下有效的身份验证类型：

GSS
Ident
LDAP
拒绝
信任

4.3 - LDAP Link 参数

使用 LDAP Link 参数决定：

LDAP Link 操作，例如启用或禁用 LDAP Link 以及进行复制的频率
身份验证参数，包括 SSL 身份验证参数
继承无主对象的用户和用户组。
如何处理冲突

要为 LDAP Link 配置 TLS，请参阅 LDAP Link 的 TLS。

设置 LDAP Link 参数

以下示例显示了如何设置：

LDAPLinkURL，LDAP 服务器的 URL。
LDAPLinkSearchBase，从中开始复制的基本 DN。

您还可以查看如何设置 LDAP Link 绑定身份验证参数（LDAPLinkBindDN 和 LDAPLinkBindPswd）以及启用 LDAP Link (LDAPLinkOn)。

=> ALTER DATABASE myDB1 SET PARAMETER LDAPLinkURL='ldap://10.60.55.128',
LDAPLinkSearchBase='dc=corp,dc=com',LDAPLinkBindDN='dc=corp,dc=com',LDAPLinkBindPswd='password';

=> ALTER DATABASE myDB1 SET PARAMETER LDAPLinkOn = '1';

通用参数和连接参数

身份验证参数

其他参数

有关设置 LDAP Link 参数的信息，请参阅配置参数管理。

注意

当连接参数或身份验证参数发生改变时，LDAP Link 会重新连接并且重新初始化同步。

4.4 - LDAP Link 的 TLS

Vertica 在两个上下文中建立到 LDAP 服务器的连接，每个上下文都有一个对应的 TLS CONFIGURATION，用于控制每个连接是否应使用 TLS：

LDAPLink：使用 LDAPLink 服务或其试运行功能在 Vertica 和 LDAP 服务器之间同步用户和组。
LDAPAuth：当具有 ldap 身份验证方法的用户尝试登录 Vertica 时，Vertica 会尝试将该用户绑定到 LDAP 服务器中的匹配用户。如果绑定成功，Vertica 将允许用户登录。

查询 TLS_CONFIGURATIONS 以查看现有的 TLS CONFIGURATION：

=> SELECT * FROM tls_configurations WHERE name IN ('LDAPLink', 'LDAPAuth');
   name   |  owner  | certificate | ca_certificate | cipher_suites |  mode
----------+---------+-------------+----------------+---------------+----------
 LDAPLink | dbadmin | client_cert | ldap_ca        |               | VERIFY_CA
 LDAPAuth | dbadmin | client_cert | ldap_ca        |               | DISABLE
(2 rows)

本页介绍了 LDAP Link 服务上下文。有关 LDAP 身份验证上下文的详细信息，请参阅 LDAP 身份验证的 TLS。

配置 LDAP Link TLS

Vertica 使用 LDAP Link 服务从 LDAP 服务器中检索用户和组，并在数据库中创建相应的用户和角色。要为 LDAP Link 及其试运行函数配置 TLS，请使用以下过程。

此过程使用预定义的 TLS 配置 LDAPLink。要创建自定义 TLS 配置，请参阅TLS 配置。

有关密钥和证书生成的详细信息，请参阅生成 TLS 证书和密钥。

如果您希望 Vertica 在建立连接之前验证 LDAP 服务器的证书，请生成或导入 CA 证书并将其添加到 LDAPLink TLS 配置中。

例如，要导入现有的 CA 证书 LDAP_CA.crt：
```
=> \set ldap_ca '\''`cat ldap_ca.crt`'\''
=> CREATE CA CERTIFICATE ldap_ca AS :ldap_ca;
CREATE CERTIFICATE
```
然后，将 ldap_ca CA 证书添加到 LDAPLink：
```
ALTER TLS CONFIGURATION LDAPLink ADD CA CERTIFICATES ldap_ca;
```
如果您的 LDAP 服务器需要验证客户端证书，则必须生成或导入客户端证书及其密钥并将其添加到 LDAPLink TLS 配置中。Vertica 会将此证书提供给 LDAP 服务器以供其 CA 进行验证。

例如，要导入现有的证书 client.crt（由导入的 CA 签名）和密钥 client.key：
```
=> \set client_key '\''`cat client.key`'\''
=> CREATE KEY client_key TYPE 'RSA' AS :client_key;
CREATE KEY

=> \set client_cert '\''`cat client.crt`'\''
=> CREATE CERTIFICATE client_cert AS :client_cert SIGNED BY ldap_ca KEY client_key;
CREATE CERTIFICATE
```
然后，将 client_cert 添加到 LDAPLink：
```
=> ALTER TLS CONFIGURATION LDAPLink CERTIFICATE client_cert;
```
通过将 TLSMODE 设置为以下之一来启用 TLS 或 LDAPS（使用的确切协议取决于 AUTHENTICATION 对象中 host 的值）。 TRY_VERIFY 或更高版本需要 CA 证书：
- ENABLE：启用 TLS。Vertica 不检查 LDAP 服务器的证书。
- TRY_VERIFY：如果出现以下任一情况，则建立 TLS 连接：
  - LDAP 服务器提供一个有效的证书。
  - LDAP 服务器不提供证书。
  如果 LDAP 服务器提供无效证书，则使用纯文本连接。
- VERIFY_CA：如果 Vertica 验证 LDAP 服务器的证书来自受信任的 CA，则连接成功。使用此 TLSMODE 会强制所有没有证书的连接使用纯文本。
- VERIFY_FULL：如果 Vertica 验证 LDAP 服务器的证书来自受信任的 CA 并且 cn（通用名称）或 subjectAltName 属性与 LDAP 服务器的主机名或 IP 地址匹配，则连接成功。
  
  cn 用于用户名，因此 subjectAltName 必须与 LDAP 服务器的主机名或 IP 地址匹配。
例如：
```
=> ALTER TLS CONFIGURATION LDAPLink TLSMODE 'verify_ca';
ALTER TLS CONFIGURATION
```

验证 LDAPLinkTLSConfig 参数是否正在使用 TLS 配置：

=> SHOW CURRENT LDAPLinkTLSConfig;
  level  |       name        | setting
---------+-------------------+----------
 DEFAULT | LDAPLinkTLSConfig | LDAPLink
(1 row)

根据您的用例设置 LDAP Link 参数。

4.5 - LDAP Link 问题故障排除

LDAP Link 服务可能会出现各种问题，包括：

用户和角色断开连接（孤立）
对象丢失
用户冲突

用户和角色断开连接（孤立）

如果 LDAP Link 服务出现问题，通过 LDAP Link 同步的 Vertica 用户和角色可能会断开连接或变为孤立状态。例如，当您更改与 LDAP 服务器的连接时，用户和角色会变为孤立状态，如以下场景中所述：

创建一个 LDAP 连接，如下所示：

=> ALTER DATABASE MyDB1 SET PARAMETER LDAPLinkURL='ldap://ebuser',
LDAPLinkSearchBase='dc=example,dc=com', LDAPLinkBindDN='mega',
LDAPLinkBindPswd='$megapassword$';
=> ALTER DATABASE MyDB1 SET PARAMETER LDAPLinkOn = '1';

运行 LDAP Link 会话以同步 LDAP 和 Vertica 用户。
通过步骤 1 更改一个或多个连接参数。只有更改 LDAPLinkURL 或 LDAPLinkSearchBase 参数之一，才能更改连接。如果新的和旧的 LDAPLinkURL 和 LDAPLinkSearchBase 包含相同的用户集，则用户不会变为孤立状态。
运行另一个 LDAP Link 会话。系统将尝试重新同步 LDAP 和 Vertica 用户。由于连接已更改，现有 Vertica 用户无法与来自新连接的 LDAP 用户同步。这些 Vertica 用户将变为孤立状态。

作为 dbadmin，您可以通过检查 USERS 系统表中的 is_orphaned_from_ldap 列来识别孤立用户：

 => SELECT is_orphaned_from_ldap FROM users;

字段值 t 表示该用户是孤立用户。孤立的 Vertica 用户无法连接到 LDAP 服务器，也无法使用 LDAP 身份验证登录 Vertica（但是，分配给该用户的其他身份验证方法仍然有效）。在这种情况下，您可以删除孤立的 Vertica 用户并运行 LDAP Link 服务，以重新同步用户。

重定父级的对象

当您从 LDAP 服务器中删除用户或组时，LDAP Link 服务会从 Vertica 中移除相同的用户和角色，但不会删除已删除的用户和角色拥有的对象。要为这些无主对象赋予新的所有者，请使用 GlobalHeirUsername 参数，此参数可将某个用户指定为最初由已删除用户拥有的所有对象的新父级。

例如，要将无主对象的所有权授予 user1（如果该用户不存在，则创建该用户）：

=> ALTER DATABASE example_db SET PARAMETER GlobalHeirUsername=user1;

默认情况下，此参数设置为 <auto>，可将对象的父级重定为 dbadmin 用户。

如果 GlobalHeirUsername 为空，则不会将对象的父级重定为其他用户。

有关详细信息，请参阅安全参数。

用户冲突

使用 LDAP Link 同步的 Vertica 用户和角色可能会发生冲突。例如，当您在 LDAP 服务器上创建新用户或组，而 Vertica 上存在另一个同名的用户或角色时，就会发生此类冲突。

作为 dbadmin，请使用以下参数之一解决用户冲突：

LDAPLinkConflictPolicy
LDAPLinkStopIfZeroUsers

LDAPLinkConflictPolicy

LDAPLinkConflictPolicy 用于控制 Vertica 在遇到冲突时的行为方式。对此参数的更改将在下一次同步期间生效。

LDAPLinkConflictPolicy=IGNORE 将忽略新增 LDAP 用户并保留现有 Vertica 用户
LDAPLinkConflictPolicy=MERGE（默认）将新增 LDAP 用户与 Vertica 用户合并，并将数据库用户转换为 LDAP 用户，同时保留数据库用户的对象。

例如，要设置参数：

=> ALTER DATABASE example_db SET PARAMETER LDAPLinkConflictPolcy='MERGE';

LDAPLinkStopIfZeroUsers

LDAPLinkStopIfZeroUsers 用于控制在同步期间 LDAP 服务器的用户为零时 Vertica 的行为方式。

LDAPLinkStopIfZeroUsers=0 表示，在 LDAP 服务器中未找到任何用户且删除了所有 Vertica 用户时，不停止同步。
LDAPLinkStopIfZeroUsers=1 表示，在 LDAP 服务器中找不到用户时，停止同步并返回错误。不会删除任何 Vertica 用户。

监控 LDAP Link

使用 ldap_link_events 表监控 LDAP Link 同步：

=> SELECT transaction_id, event_type, entry_name, entry_oid FROM ldap_link_events;
   transaction_id |    event_type      | entry_name | entry_oid
------------------+--------------------+------------+-----------
45035996273705317 | SYNC_STARTED       |            |         0
45066962732553589 | SYNC_FINISHED      |            |         0
45066988112255317 | PROCESSING_STARTED |            |         0
23411234566789765 | USER_CREATED       | tuser      | 234548899
(4 rows)

5 - 连接器框架服务

连接器框架服务 (CFS) 允许将文档从 IDOL 安全索引到 Vertica 分析型数据库。访问控制列表可确定哪些用户有权访问文档。从 IDOL 传输的文档存储在 Flex 表 (Flex 表) 中。

重要

Vertica 9.1.1 不支持 IdolLib 函数库。如果您安装有 IdolLib 函数库，则当您升级到 Vertica 9.1.1 时，您会看到错误且无法访问 IdolLib 函数库。

要确定是否安装了 IdolLib 库，请运行以下脚本：

$ /opt/vertica/packages/idol/ddl/isinstalled.sql

要卸载 IdolLib 库，请运行以下脚本：

$ /opt/vertica/packages/idol/ddl/uninstall.sql

CFS 组件

使用以下 CFS 组件在 Vertica 上实施服务：

IDOL 文档元数据
CFS 配置文件

有关详细信息，请参阅实施 CFS。

IDOL 文档元数据

Vertica 分析型数据库会将 IDOL 文档元数据存储在 Flex 表中。可在 CFS 配置文件中使用 TableName 参数设置弹性表的名称（请参阅实施 CFS）。元数据包括以下内容：

AUTONOMYMETADATA（强制性）：为文档指定的 ACL 的字母数字标志。
DREFIELD：为用户和组分配访问 IDOL 文档的权限级别。
DRETITLE：文档标题。

CFS 配置文件

必须为 Vertica 分析型数据库中的 IDOL 元数据编制索引，这些数据才能够用于查询。请参阅实施 CFS。

5.1 - 实施 CFS

Vertica 将文档从 IDOL 输入 Flex 表之后，您可以实施 CFS 以保护这些文档。实施此安全性要求 Vertica 数据库管理员修改 CFS 配置文件。

修改 CFS 配置文件

数据库管理员必须修改 CFS 配置文件中的以下内容，以使 CFS 自动编制元数据索引：

在 [Indexing] 部分中，将 IndexerSections 参数设置为 vertica：

[Indexing]
IndexerSections=vertica
IndexBathSize=1
IndexTimeInterval=30

创建一个新部分，其名称与您在 IndexerSections 参数中输入的名称相同，然后输入以下参数和关键字：

[vertica]
IndexerType=Library
ConnectionString=Driver=Vertica;Server=123.456.478.900;Databaswe=myDb;UID=dbadmin;PWD=password
TableName=myFlexTable
LibraryDirectory= ./shared_library_indexers
LibraryName=VerticaIndexer

VerticaIndexer（上面的 LibraryName）是 CFS 的一部分。要使用此工具，您必须在与 CFS 相同的计算机上安装和配置 Vertica ODBC 驱动程序。CFS 使用 ODBC 将 JSON 格式的数据发送到弹性表

有关详细信息，请参阅安装 ODBC 客户端驱动程序。

查询 IDOL 数据

要查询 Flex 表中的 IDOL 数据，请运行简单的 SELECT 查询。在此示例中，idol_table 是 Flex 表的名称：

=> SELECT * FROM idol_table;

6 - 美国联邦信息处理标准

在 Vertica 支持的 FIPS 兼容操作系统上运行时，Vertica 使用经过认证的 OpenSSL FIPS 140-2 加密模块。这符合美国国家标准与技术研究所 (NIST) 为美国或其他国家/地区的联邦机构制定的安全标准。

该标准规定了加密模块在保护敏感信息的系统中所需的安全要求。有关标准的详细信息，请参阅计算机安全资源中心。

注意

Vertica 本身不符合 FIPS 标准，但它可以使用 FIPS 资源在启用了 FIPS 的系统上运行。

有关 FIPS 先决条件的列表，请参阅 FIPS 140-2 支持的平台。

6.1 - OpenSSL 行为

在客户端和服务器上实施 FIPS 需要使用动态 OpenSSL 链接。Vertica 服务器使用主机系统提供的 OpenSSL（如 FIPS 140-2 支持的平台中所示）。OpenSSL 与 LDAP 和 Kerberos 进行动态链接。

有关详细信息，请参阅查找 OpenSSL 库。

CentOS 系统上的库

在 FIPS 兼容的 CentOS 系统上，Vertica 仅使用 FIPS 140-2 支持的平台中列出的 OpenSSL 库运行。这些库的其他版本不在 FIPS 系统上运行。出现这种不兼容性的原因是，FIPS 安全策略对应用程序链接到的库执行校验和，并验证应用程序执行的库是否具有相同的校验和。

非 FIPS 系统上的库版本控制

请注意，在某些非 FIPS 系统上，安装新版本的 OpenSSL 时可能会出现版本控制异常。某些情况下，默认的 OpenSSL 构建过程会生成版本名为 1.0.0 的库。要让 Vertica 识别库具有较高的版本号，您必须为库名称提供更高的版本号。例如，在安装 OpenSSL 版本 1.0.1t 时，将库命名为 libcrypto.so.1.0.1t 或 libssl.1.0.1t（具有这些名称的符号链接即可）。

6.2 - 启用了 FIPS 的数据库：限制

启用了 FIPS 的数据库具有以下限制：

不能在非 FIPS 计算机上创建启用了 FIPS 的数据库。
不能在启用了 FIPS 的计算机上创建非 FIPS 数据库。
管理控制台 (Management Console) 及其守护程序 Agent 在启用了 FIPS 的数据库上不可用。
将使用 MD5 哈希算法生成的数据从非 FIPS 计算机复制到启用了 FIPS 的计算机会导致数据损坏。
由于 FIPS 加密模块的限制，Vertica 不建议在 FIPS 环境中启用节点间加密。如果您使用 FIPS 和节点间加密，由于通过网络发送大量数据的工作负载中的套接字关闭，您偶尔可能会遇到查询失败。

6.3 - 实施 FIPS 140-2

要在 Vertica 分析型数据库上实施 FIPS 140-2，需要对服务器和客户端进行配置。虽然 Vertica 服务器使用经 FIPS 批准的算法，但 Vertica 客户端可能会在未经 FIPS 批准的系统上运行。因此，您必须始终实施 FIPS 140-2 合规性。

有关实施 FIPS 的详细信息，请参阅：

6.3.1 - Vertica 服务器的 FIPS 合规性

要使 Vertica 符合 FIPS 规范，您必须：

将 RequireFIPS 参数设置为 1。
使用 SHA-512 对密码进行哈希处理。有关详细信息，请参阅哈希身份验证。
生成签名的 TLS 证书，以建立与客户端的安全连接。

RequireFIPS 参数

Vertica 在启动时会在服务器上设置 RequireFIPS 配置参数，以反映系统上 FIPS 的状态：如果启用 FIPS，则为 1，如果禁用 FIPS，则为 0。

RequireFIPS 的值与 crypto.fips_enabled 文件的值匹配。

Vertica 根据 crypto.fips_enabled 的内容设置 RequireFIPS 参数：

如果文件 /proc/sys/crypto/fips_enabled 存在且包含 1（启用了 FIPS），Vertica 会将 RequireFIPS 设置为 1。
如果文件 /proc/sys/crypto/fips_enabled 不存在，或存在但包含 0（未启用 FIPS），Vertica 会自动将 RequireFIPS 设置为 0。
如果通过存在 /proc/sys/crypto/fips_enabled 确定的节点的 FIPS 状态与从群集发起方接收到的状态不同，节点将失败。此行为可防止创建混合了 FIPS 系统和非 FIPS 系统的群集。

重要

如果您尝试将启用了 FIPS 的节点还原到非 FIPS 群集，则还原将失败。

安全的客户端-服务器连接

使用 TLS 保护客户端-服务器连接非常重要。有关设置客户端-服务器 TLS 的说明，请参阅配置客户端-服务器 TLS。

FIPS 兼容的 AWS 端点

要将 AWS 配置为使用 FIPS 兼容的 S3 端点，请设置以下 S3 参数：


AWSEndpoint = s3-fips.dualstack.us-east-1.amazonaws.com
S3EnableVirtualAddressing = 1

6.3.2 - 在客户端上实施 FIPS

Vertica 提供 FIPS 兼容的客户端驱动程序，您可以将其安装在启用了 FIPS 的系统上。64 位客户端包括 vsql 和 ODBC 驱动程序。

有关安装 FIPS 客户端以及安装的信息，请参阅以下内容

6.4 - FIPS 140-2 合规性声明

内容

3.Vertica 和 FIPS 140-2

1.摘要

Vertica 符合美国联邦信息处理标准 140-2 (FIPS 140-2)，该标准定义了联邦机构为保护敏感数据或有价值的数据而指定基于加密的安全系统时要使用的技术要求。通过以下方式确保 Vertica 符合 FIPS 140-2 标准：1) 集成经过验证和经 NIST 认证的第三方加密模块，并将模块作为加密服务的唯一提供程序；2) 使用经 FIPS 批准的加密函数；3) 根据 Vertica 设计、实施和操作，使用合适的经 FIPS 批准和经 NIST 验证的技术。

2. 概述

a. 关于 Vertica

Vertica 是用于高级分析应用程序的高性能关系数据库管理系统。其性能与规模扩展是通过提供大规模并行处理解决方案的列存储和执行架构来实现的。激进的编码和压缩策略可以减少 CPU、内存和磁盘 I/O 处理时间，从而执行 Vertica 分析。
有关 Vertica 及其用法的更多详细信息，请参阅体系结构。

b. 关于 FIPS 140-2

FIPS（美国联邦信息处理标准）140-2，即加密模块的安全要求，是用来对政府购买的计算机系统进行适当加密的联邦标准。

美国联邦信息处理标准 (FIPS) 出版物 140-2“加密模块的安全要求”于 2001 年 5 月由美国国家标准与技术研究所 (NIST) 发布。

使用经 FIPS 140-2 验证的加密模块的好处是，加密算法被视为是合适的，且它们可以正确执行加密/解密/哈希函数。该标准规定了在保护敏感或有价值的数据的安全系统中使用的加密模块的安全要求。有关这些要求，请参阅以下文档：

3.Vertica 和 FIPS 140-2

通过 FIPS 140-2 验证的第三方模块

通过动态链接到操作系统提供的经 FIPS 140-2 批准的 OpenSSL 加密模块（在初始版本中为 Red Hat Enterprise Linux 6.6 OpenSSL 模块），Vertica 符合 FIPS 140-2 1 级合规性。

可以将 Vertica 配置为在 FIPS 兼容模式下运行，以确保其功能和过程（例如 SSL/TLS 连接，需要通过安全哈希、加密、数字签名等进行加密）能够利用经 FIPS 140-2 验证的 RedHat Enterprise Linux 6.6 OpenSSL 模块 v3.0 提供的加密服务。如果您不在 Vertica 支持的 FIPS 兼容操作系统上运行，则将无法在 FIPS 模式下运行 Vertica。RedHat 的实施在操作系统级别保证 Vertica 使用正确的 FIPS 140-2 加密模块。

Vertica 会检查操作系统级别标志设置 /proc/sys/crypto/fips_enabled，以启动 Vertica 的 FIPS 模式安装。有关如何安装和配置 Vertica 及其组件以符合 FIPS 140-2 标准的更多详细信息，请参阅安装和安全指南：

操作模式

Vertica 服务器在操作系统配置确定的两种模式之一下操作。

FIPS 兼容模式 – 支持符合 FIPS 140-2 规范的加密函数。在此模式下，所有加密函数、默认算法和密钥长度均绑定为 FIPS 140-2 允许的值。
标准模式 – 不符合 FIPS 140-2 规范的模式，该模式使用所有现有的 Vertica 加密函数。

TLS/SSL3.x

所有 Vertica 客户端/服务器通信都可以使用 FIPS 兼容的传输层安全协议 TLS1.2/SSL3.1 或更高版本来进行保护。该协议依赖于经 FIPS 140-2 批准的哈希算法和密码。

TLS 握手、密钥协商和身份验证可保证数据完整性，并使用安全哈希和经 FIPS 140-2 批准的加密和数字签名。
对传输中的数据应用 TLS 加密可保证数据机密性，并使用经 FIPS 140-2 批准的加密。

安全哈希

根据 FIPS 140-2 标准，在 FIPS 140-2 兼容模式下，可以将 Vertica 配置为仅使用 SHA-512 算法。

FIPS 140-2 架构

Vertica 是一个关系数据库系统，由客户端组件和服务器组件组成。在客户端，我们提供一套驱动程序，以供主机客户端访问 Vertica 服务器端组件。客户端和服务器 Vertica 组件均通过动态链接到 RedHat Enterprise Linux 6.6 OpenSSL 模块提供的经 FIPS 140-2 批准的 OpenSSL 加密模块，来符合 FIPS 140-2 1 级合规性。

支持的平台

有关 Vertica 支持的 FIPS 兼容操作系统和客户端驱动程序的信息，请参阅 FIPS 140-2 支持的平台。

设计保证

Vertica 使用安全提供程序 Red Hat Enterprise Linux 6.6 OpenSSL Module v3.0。这是唯一受 FIPS 140-2 支持的安全提供程序。

将 Vertica 配置为符合 FIPS 140-2 规范后，除非在操作系统级别禁用 FIPS 140-2，否则将无法恢复为标准配置。有关注意事项，请参考以下文档部分：

7 - 数据库审核

数据库审核通常涉及观察数据库以了解数据库用户当前执行的操作。审核有助于提高安全性，例如，确保用户不会更改他们不应具有访问权限的信息。审核类别便于跟踪数据库中的更改。您可以查看将记录的查询、表和对配置参数的更改汇集在一起的系统表。

例如，身份验证审核类别可跟踪与安全性和身份验证相关的查询、系统表和配置参数，例如：

DROP AUTHENTICATION 语句
GRANT/REVOKE 身份验证语句
LDAP Link 相关配置参数

您还可以将身份验证审核类别用于每周安全报告，以更好地了解是否有人尝试访问数据或查看未经授权的更改。

以下三个系统表可用于跟踪查询、参数和表的更改：

还有一个系统表用于跟踪用户权限的更改：

AUDIT_MANAGING_USERS_PRIVILEGES

8 - 系统表限制和访问

通过这两个函数，您可以限制和允许对给定会话的系统表的访问：

RESTRICT_SYSTEM_TABLES_ACCESS 限制访问锁定期间无法访问的非超级用户专用表。
RELEASE_SYSTEM_TABLES_ACCESS 允许访问锁定期间无法访问的非超级用户专用表。