Web服务器上利用ACL实现基于职能角色的敏感目录访问权限，核心是将业务角色映射为系统组（如auditors、appops），再通过OS级ACL（如setfacl或NTFS）对目录施加细粒度控制；需配合基础权限、默认ACL、状态监控与上层RBAC协同，确保最小权限和持续有效性。
Web服务器上利用ACL实现基于职能角色的敏感目录访问权限，核心不是“用角色名直接配ACL”，而是将角色映射为系统用户或组，再通过操作系统级ACL（如Linux的setfacl或Windows NTFS ACL）对具体目录施加细粒度控制。这与RBAC不同——ACL不管理“角色→权限”的抽象关系，而是落实到“谁（用户/组）对哪个路径能做什么”的物理层面。
明确角色到系统实体的映射关系
ACL本身不识别“审计员”“运维工程师”这类业务角色，需先将其转化为可被OS识别的身份：
- 为每个职能角色创建专用系统组，例如：
groupadd auditors、groupadd appops、groupadd secadmins - 将对应人员加入组，避免共用账户：使用
usermod -aG auditors alice而非给alice直接sudo权限 - 确保Web服务进程（如www-data、nginx）不意外拥有写入敏感日志目录的权限；其UID/GID不应出现在
/var/log/audit等目录的ACL中
在敏感目录上配置最小化ACL规则
以/var/www/app/logs（应用自定义日志）、/etc/nginx/conf.d/（配置文件）、/var/log/audit/（系统审计日志）为例：
- 审计员只需读取：
setfacl -m g:auditors:r-x /var/log/audit，再配合chmod 750 /var/log/audit锁定基础权限 - 应用运维可追加日志但不可删改：对日志目录设
setfacl -m g:appops:rw- /var/www/app/logs，并添加default ACL保障新建文件继承：setfacl -d -m g:appops:rw- /var/www/app/logs - 禁止非授权写入配置目录：
setfacl -m g:appops:r-x /etc/nginx/conf.d，同时确保chmod 750 /etc/nginx/conf.d且属主为root:root
与Web层权限模型协同，避免权限覆盖失效
ACL是OS层的最后一道防线，必须与上层机制对齐：
- 若Web应用自身已用RBAC控制后台路由访问，ACL仍需独立保护其日志和配置文件——因为RBAC失效或绕过（如直接SSH登录）时，ACL仍在生效
- 在Azure Files等云存储场景中，必须先分配RBAC角色（如SMB共享贡献者），再配置NTFS ACL；否则即使NTFS设了Full Control，RBAC拒绝也会导致整体访问失败
- IIS中配置目录ACL后，需确认“身份验证方法”（如Windows身份验证）已启用，否则匿名用户可能因未触发身份识别而被ACL默认拒绝
建立ACL状态持续验证机制
ACL易被手动修改或脚本误覆盖，需主动监控：
- 每日快照关键目录ACL：
getfacl -R /var/log/audit /etc/nginx/conf.d > /etc/acl-snapshot-$(date +%F).txt，保留最近7天 - 用diff比对变化，发现新增未知用户条目或mask权限扩大（如
mask::rwx）立即告警 - 季度人工复核时重点检查：default ACL是否误设在根目录、是否存在
u:root:rwx以外的显式用户条目、是否有组权限宽于基础chmod设置
