Golang日志在CentOS中的安全策略
日志这件事，看着不起眼，但一旦出了问题——权限放得太宽、轮转没配好、敏感信息往外漏——溯源查起来可就头疼了。尤其是Golang服务跑在CentOS上，日志安全要怎么落到实处？下面这几个维度，顺下来就能有个清晰的框架。
一 身份与权限最小化
首先要做的一件事：别用 root 写日志。一定要用最小权限的系统账号来跑服务。比如创建一个专用用户 myapp，禁止交互式登录，这样即使日志文件被拖走，也不至于直接暴露整个系统。
日志目录和文件的权限，遵循一个简单原则——目录仅管理员可写，日志文件仅属主与属组可读写。具体来说：
- 建议目录设为
/var/log/myapp，权限 0750，属主设为root:myapp - 建议日志文件设为
/var/log/myapp/app.log，权限 0640，属主同样为root:myapp
在Go代码里，创建目录和文件时就要显式指定权限，别依赖系统的 umask。举个例子：
- 目录：
os.MkdirAll("/var/log/myapp", 0750) - 文件：
os.OpenFile("/var/log/myapp/app.log", O_CREATE|O_WRONLY|O_APPEND, 0640)
千万别一高兴就给个 0666，那等于把家门钥匙放在脚垫下——谁都能看，谁都能改，谁都能删。从根上避免过于宽松的权限，是第一步。
二 输出与轮转策略
生产环境里，推荐的做法是把日志输出到标准输出或标准错误，由 systemd 或容器平台统一采集。这样日志文件直接暴露的风险就小多了。开发或调试阶段再输出到文件，方便排查问题，两套逻辑分开，不混用。
日志轮转呢？用 logrotate 统一管理是最省心的。一个典型的配置示例：
- 路径指向
/var/log/myapp/app.log - 策略：每日轮转、保留7份、自动压缩、允许缺失、不轮空日志、轮转后创建新文件权限 640 且属主为 root:myapp
如果你的服务跑在容器里或者没有 systemd 的环境，推荐在应用内用 lumberjack 进行按大小或时间滚动。几个关键参数：MaxSize 设为 5 MB，MaxBackups 保留 3 份，MaxAge 设为 28 天，Compress 开启。这样配置，日志不会无限膨胀，也不会占用过多磁盘。
三 系统日志与集中审计
关键业务日志，建议通过 syslog 发送到系统日志服务（比如 rsyslog），然后利用系统级的权限和审计能力统一管控。Go 里用 log/syslog 连接本地 LOG_USER 设施，设置 LOG_PID 等选项，日志最终汇集到 /var/log/messages 或自定义设施中。这样做的好处是：日志不过路径依赖，审计和排查都更方便。
四 SELinux 与最小访问面
CentOS 自带的 SELinux 不是摆设。启用并正确配置后，只允许日志相关进程对日志目录和文件拥有追加或写入权限，其他主体一概无权访问。这就叫最小访问面。
常用的检查与设置命令有几个：
- 查看文件或目录的上下文：
ls -Z /var/log/myapp - 查看进程上下文：
ps -eZ | grep myapp - 必要时调整上下文：
chcon -t var_log_t /var/log/myapp /var/log/myapp/app.log - 用
semanage fcontext持久化路径上下文，再用semodule管理自定义策略模块，确保策略与业务变更同步更新
这一步虽然稍显繁琐，但带来的安全收益非常扎实。
五 敏感信息与加密
日志里不能出现明文密码、密钥、令牌、个人敏感数据——这应该是常识。实在必须记录，就先做脱敏或哈希处理再写入。存量日志中如果已有敏感内容，也需要尽快清理。
对于离线归档或备份的日志，写入后或归档前可以用对称加密（比如 AES-CFB）保护起来，密钥长度选 16/24/32 字节，且要妥善管理密钥。在线写入的场景，建议结合磁盘或文件级加密与访问控制一起使用，形成多层防护。
说到底，日志安全不是装一个工具、改一行配置就能一劳永逸的。把上述几个步骤走一遍，至少能保证你的 Golang 服务在 CentOS 上跑得安心一些。
