附录 D. ACL 参考
本节介绍了每个资源控制的内容，列出描述这些操作结果的可能操作，并为定义的每个 ACL 资源提供默认的 ACI。每个子系统仅包含与那个子系统相关的 ACL。
D.1. 关于 ACL 配置文件
访问控制 是设置可以访问服务器一部分的规则以及用户可以执行的操作的方法。依赖于 LDAP 目录服务并使用 Java 控制台 - CA、KRA、OCSP 和 TKS - 所有子系统都实施 LDAP 风格的访问控制来访问其资源。这些访问控制列表(ACL)位于
/var/lib/pki/instance_name/conf/子系统/acl.ldif 文件中。
注意
本节仅提供有关访问控制概念的简要概述。红帽目录服务器 管理指南中的管理访问控制 一章中更详细地描述了访问控制。
证书系统 ACL 文件是由内部数据库加载的 LDIF 文件。单个 ACL 定义为
resourceACLS 属性，它标识受保护的子系统区域，然后定义一个要设置的所有特定访问控制的列表。
resourceACLS: class_name:all rights: allow|deny (rights) type=target description
允许或拒绝对资源的访问的每个规则称为访问控制指令( ACI )。（资源的所有 ACI 的总和是一个访问控制列表。） 在定义实际 ACI 之前，ACL 属性首先应用于证书系统子系统使用的特定插件类。这会将每个 ACL 专注于子系统执行的特定功能，从而为实例提供更高的安全性，并对应用 ACL 更好地控制。
例 D.1. 列出证书配置文件的默认 ACL
resourceACLS: certServer.ca.profiles:list:allow (list) group="Certificate Manager Agents":Certificate Manager agents may list profiles
由于每个子系统(CA、KRA、GADP 和 TKS)都有自己的资源用于其操作，因此每个子系统实例都有自己的
acl.ldif 文件及其自己的定义的 ACL。
每个 ACI 定义了可以执行的操作或行为( 右侧)，以及 ACI 应用到什么( 目标)。ACI 的基本格式为：
allow|deny (rights) user|group
权限 是 ACI 允许用户执行的操作类型。对于 LDAP ACI，对目录条目的权限列表相对有限，如搜索、读取、写入和删除。证书系统使用覆盖常见 PKI 任务的额外权限，如撤销、提交和分配。
如果 ACI 中没有显式允许某个操作，则会隐式拒绝操作。如果一个 ACI 中明确拒绝某个操作，它会解析显式允许的任何 ACI。始终希望使用拒绝规则来允许规则提供额外的安全性。
每个 ACI 必须应用到特定的用户或组。这使用几个常见条件（通常为 user= 或 group= ）进行设置，但还有其他选项，如 ipaddress=，它们定义基于客户端的访问权限，而不是基于条目的访问。如果有多个条件，可以使用双管道(||)运算符组成条件，表示逻辑分布("或")，以及 double ampersand (&&)运算符，表示逻辑使用("and")。例如，group="group1" || "group2"。
resourceACLS 属性值的每个区域都在 表 D.1 “ACL 属性值的部分” 中定义。
| 值 | 描述 |
|---|---|
| class_name | ACI 应用到的插件类。 |
| 所有操作 | ACI 定义中涵盖的每个操作列表。单个 ACI 中可以有多个操作，单个 resourceACLS 属性中的多个 ACI。 |
| allow|deny | 是否允许对目标用户或组执行操作，还是拒绝目标用户或组。 |
| (操作) | 允许或拒绝的操作。 |
| type=target | 用于标识应用到哪些目标。这通常是一个用户（如 user="name"）或组(group="group")。如果有多个条件，可以使用双管道(||)运算符（逻辑 "or"）和 double ampersand (&&)运算符（逻辑"and"）来组成条件。例如，group="group1" || "group2"。 |
| description | 有关 ACL 的作用的描述。 |
