自主访问控制（DAC）
自主访问控制，说实话，是咱们能接触到的、最直观的一种权限模型。说白了就是“我的地盘我做主”——资源属于谁，谁就有权决定谁能碰它。
我最早接触权限管理，就是从 Linux 的 chmod 开始的。那时候觉得“r、w、x”三个字母真简单，后来做 HSM 集成方案才意识到，DAC 的灵活性和它带来的安全隐患，一样突出。
DAC 的核心思想
DAC 的全称是 Discretionary Access Control。“Discretionary”这个词是关键——资源的所有者可以自主决定权限。系统不会强制约束你怎么分权，你爱给谁读就给谁读，爱给谁写就给谁写。
这种模型有点像我租了一套房子。我是房主，钥匙在我手里。我可以把备用钥匙给我朋友，让他偶尔来住。如果朋友又转交给了他的朋友……技术上操作系统是允许的，因为它不检查“传递链”是否合理。
DAC 的核心特征：用户对“自己”的资源拥有完全的自主处置权。权限的授予与收回，不需要管理员介入。
ACL：访问控制列表在 DAC 中的角色
ACL（Access Control List）是 DAC 最常用的实现方式。每个资源挂一张表，表里写着“谁可以干什么”。
举个例子，一个文件可以带有这样的 ACL：
文件：report_v4.pdf
--------------------------------
用户 alice： read, write
用户 bob： read
用户 charlie： no access
组 team_dev： read, write
--------------------------------每次有人访问文件，系统就去 ACL 里逐条查。找到匹配的条目就按上面写的权限放行或拒绝。我之前在项目中调一个 HSM 的密钥访问策略，其实就是把 HSM 内部的对象当作“文件”，每条策略就是一条 ACL 条目。
一个小提示：ACL 的条目顺序很重要。一些系统（比如 Windows NTFS）会按顺序匹配，一旦匹配就不再往下查。我更倾向于把“deny”条目放在前面，避免意外放行。
Linux 文件权限示例
Linux 的经典权限模型是 DAC 的典型代表。你在终端里看到的 -rwxr-xr-- 就是用户、组、其他人三组权限位。
# 查看文件权限
$ ls -l mykey.pem
-rw-rw---- 1 alice crypto-ops 1680 Apr 12 09:15 mykey.pem
# 用符号方式授权
$ chmod u+r,g+r,o-rwx mykey.pem
# 用 ACL 做更细粒度的控制
$ setfacl -m u:bob:r mykey.pem
$ setfacl -m u:charlie:- mykey.pem
# 查看 ACL
$ getfacl mykey.pem
# file: mykey.pem
# owner: alice
# group: crypto-ops
user::rw-
user:bob:r--
user:charlie:---
group::rw-
mask::rw-
other::---我记得有一次，团队里有人用 chmod 777 处理了一个密钥文件。嗯，一看就是新手干的。我后来在 CI 脚本里加了检查，只要是 .pem 或 .key 文件，权限位不对就直接报错。
注意了：DAC 模型下，用户可以把权限传递给别人。比如 alice 把文件设成全局可读，那这个文件就不再受她控制了。这在多租户 HSM 环境里，容易造成意外的密钥泄露。
优缺点分析
| 方面 | 优点 | 缺点 |
|---|---|---|
| 灵活性 | 用户自主决策，操作门槛低 | 权限容易失控，难以统一管理 |
| 实现成本 | 内核支持成熟，工具链完善 | 权限蔓延后难以审计 |
| 细粒度 | 支持单用户、单组的精确控制 | 不检查“传递链”，存在隐式泄露风险 |
| 合规能力 | 适合小团队、非正式环境 | 不满足“最小权限”“职责分离”等严格合规要求 |
我做 HSM 集成时碰到过一个案例。运维人员把 HSM 的一把签名密钥的访问权限设成了 group 可读。本来只打算让一个同事用，结果那同事又把这个权限复制到了另一个组……最后二十多个人都能调这把密钥。这就是典型的 DAC 副作用——权限像病毒一样扩散。
后来我们在 HSM 管理工具里增加了一条规定：所有密钥的 ACL 修改必须经过管理员审核，并且不允许用户设置“其他人”的权限。说白了，就是主动削弱 DAC 的“自主性”，往 MAC（强制访问控制）的方向靠一靠。
DAC 在 HSM 集成中的实践建议
如果你要在一个 HSM 系统里用 DAC，我有几条经验可以分享：
- 限制自主授权的范围：不允许用户把权限授给“所有用户”或“匿名用户”。
- 审计所有权限变更：每次 ACL 修改都在日志里留下记录，方便回溯。
- 设置默认最小权限：新创建的对象默认只能被创建者访问，其他组全部
deny。 - 周期性权限审查：我习惯每个月跑一次
getfacl -R，把那些权限异常的文件挑出来。 - 与 MAC 组合使用：比如 HSM 的密钥先用 DAC 进行用户级的“粗略”控制，再用 SELinux 或类似机制做系统级的“强制”兜底。
你想想看，如果完全放任 DAC 的自由度，那和把门钥匙挂在门口没区别。所以我的做法是“给用户自由度，但加一道安全围栏”。
这张图把三个要素串起来了：主体拿着 ACL 去匹配客体。所有者可以主动修改 ACL，这就是“自主”的体现。而虚线部分表示，一旦授权出去，权限就可能沿着人际关系链扩散——这也是 DAC 最容易被忽视的风险。