附录 D. ACL 参考

本节介绍每个资源控制的内容，列出描述这些操作结果的可能操作，并为定义的每个 ACL 资源提供默认 ACI。每个子系统仅包含与该子系统相关的 ACL。

D.1. 关于 ACL 配置文件

访问控制 是设置能够访问服务器一部分的规则以及用户可以执行的操作的方法。依赖于 LDAP 目录服务的四个子系统，并使用 Java 控制台 - CA、KRA、OCSP 和 TKS - 所有实施 LDAP 风格的访问控制来访问其资源。这些访问控制列表(ACL)位于 /var/lib/pki/instance_name/conf/子系统/acl.ldif 文件中。
注意
本节只提供有关访问控制概念的简单概述。《 Red Hat Directory Server 管理指南 》中的管理访问控制章节中提供了更详细的信息。 https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control.html
CertificateCertificate Systemnbsp;System ACL 文件是内部数据库载入的 LDIF 文件。单个 ACL 定义为 resourceACLS 属性，它们识别受保护子系统的区域，然后是正在设置的所有特定访问控制的列表。 
resourceACLS: class_name:all rights: allow|deny (rights) type=target description
允许或拒绝访问资源的每个规则都称为访问控制指令( ACI )。（资源的所有 ACI 的总和是一个访问控制列表。） 在定义实际 ACI 之前，ACL 属性首先应用于证书证书系统nbsp;System 子系统使用的特定插件类。这会将每个 ACL 集中到子系统执行的特定功能，为实例提供更多安全性，并更好地控制应用的 ACL。

例 D.1. 列出证书配置集的默认 ACL

resourceACLS: certServer.ca.profiles:list:allow (list) group="Certificate Manager Agents":Certificate Manager agents may list profiles
因为每个子系统（CA、KRA、OCSP 和 TKS）都有不同的资源用于其操作，所以每个子系统实例都有自己的 acl.ldif 文件，自己的 ACL。
每个 ACI 均可以定义什么访问或行为（ 右侧）以及 ACI 应用到谁（ 目标）。ACI 的基本格式为： 
allow|deny (rights) user|group
权限 是 ACI 允许用户执行的操作类型。对于 LDAP ACI，目录条目的权限相对有限，如搜索、读取、写入和删除等。CertificateCertificate Systemnbsp;System 使用其他权限，它们涵盖常见的 PKI 任务，如撤销、提交和分配。
如果在 ACI 中未明确允许某一操作，则它会被隐式拒绝。如果一个 ACI 中明确拒绝某个操作，则它会显示显式允许的任何 ACI。拒绝规则始终表现为允许规则提供额外的安全性。
每个 ACI 必须应用到特定的用户或组。这使用几个常用条件（通常是 user= 或 group= ）进行设置，尽管存在其它选项（如 ipaddress= ），后者定义了基于客户端的访问而不是基于条目的访问。如果有多个条件，则可以使用双线(||)运算符组成条件，使用双线(||)运算符符号表示逻辑退出（"或"），以及双符号(&&)运算符，使用符号表示逻辑（"和"）。例如，group="group1" || "group2 "。
资源ACLS 属性值 的每个区域都在 表 D.1 “ACL 属性值的部分” 中定义。

表 D.1. ACL 属性值的部分

值 描述
class_name 将 ACI 应用到的插件类。
全部操作 ACI 定义中涵盖的每个操作列表。单一 ACI 和多个 ACI 在单一 资源ACLS 属性中可以有多个操作。
allow|deny 目标用户或组是否允许操作。
(operations) 允许或拒绝的操作。
type=target 用于标识此适用于谁的目标。这通常是用户（如 user="name"）或组(group="group")。如果有多个条件，则可以使用双 pipe(||)运算符（逻辑"或"）和双倍(&&)运算符（逻辑"和"）组成条件。例如，group="group1" || "group2 "。
description 有关 ACL 用途的描述。