审计日志权限的基本作用
在公司内网运维中，经常遇到这样的情况：某台服务器上的关键配置被修改了，但没人承认操作过。这时候翻查审计日志就成了唯一线索。但如果日志权限没设好，要么普通员工能随意删除记录，要么管理员查看时提示“访问被拒绝”，问题就更复杂了。
审计日志的核心不只是记录谁做了什么，更重要的是确保这些记录本身不被篡改或删除。这就得靠合理的权限设置来实现。
Windows 系统中的设置方法
以常见的 Windows Server 为例，打开“本地安全策略”>“高级审核策略配置”>“系统审计策略”，可以开启对账户管理、对象访问等行为的记录。但这只是第一步，真正关键的是日志文件本身的 NTFS 权限控制。
右键点击 C:\Windows\System32\winevt\Logs 下的 .evtx 文件所在目录，选择“属性”>“安全”选项卡。默认情况下，只有 SYSTEM 和 Administrators 组有完全控制权。建议移除 Users 组的写入和修改权限，防止普通账户干扰日志。
icacls "C:\Windows\System32\winevt\Logs" /grant *S-1-5-18:(OI)(CI)(F) /remove *S-1-5-32-545这条命令用管理员身份运行后，会赋予本地系统完全控制权，并移除普通用户组的访问权限。注意 S-1-5-18 是 SYSTEM 的 SID，S-1-5-32-545 对应 Users 组。
Linux 下的日志权限管理
在 CentOS 或 Ubuntu 服务器上，auditd 是常用的审计服务。安装完成后，配置文件位于 /etc/audit/audit.rules。比如想监控 /etc/passwd 的访问，可以添加：
-w /etc/passwd -p r -k user_access规则生效后，所有读取该文件的操作都会被记录到 /var/log/audit/audit.log。这个文件默认属主是 root:root，权限为 600。为了防止意外覆盖，建议加上不可变属性：
chattr +i /var/log/audit/audit.log这样即使是 root 用户也不能直接编辑或删除日志，除非先执行 chattr -i 解锁。当然，日常轮转日志时记得临时解除锁定。
权限分配要讲究最小化原则
有些企业为了方便，给技术支持人员开放了“本地管理员”权限，结果他们顺手清掉了可疑的日志条目。正确的做法是通过“审核查看者”角色来授权，比如在域环境中使用“事件日志读者”组，允许查看但不能清除日志。
在 Active Directory 中，可以通过组策略将特定用户加入“Event Log Readers”组，这样他们在远程查看事件日志时不会触发新的审计事件，也不会误删原始数据。
定期检查权限是否被篡改
设置一次并不等于一劳永逸。曾有个案例，黑客入侵后第一件事就是修改 audit.log 的权限，让自己可以静默删除痕迹。建议每周跑一次脚本，检查关键日志文件的权限状态是否符合预期。
比如写个简单的 shell 脚本：
if [ `stat -c %a /var/log/audit/audit.log` != "600" ]; then
echo "/var/log/audit/audit.log 权限异常"
fi结合 cron 定时任务，发现问题及时告警。
审计日志权限不是设完就忘的事，它像门禁系统的录像存储一样，必须保证完整性和可信度。合理配置不仅能帮你在出事时快速定位责任人，还能有效震慑内部违规操作。