Java 应用把日志写到 CentOS 后，真正的风险往往不在“能不能写”，而在“谁还能看到、拷走或通过接口读到”。这篇文章按从轻到重的顺序梳理几种常见控制手段：先用文件权限把本地访问收紧，再根据需要补上 SELinux、网络访问限制、日志轮转，以及集中式日志平台。读完后，你可以判断自己的场景更适合只做基础加固，还是需要做到进程级、网络级甚至审计级控制。
先用文件权限收紧本地访问
如果日志直接落盘，最先该做的是把文件本身的读写权限关紧。这是成本最低、见效最快的一步，尤其适合单机部署或日志暂时没有对外暴露的应用。
假设日志文件位于 /var/log/myapp.log，可以先用 chown 和 chmod 明确所有者与权限：
# 假设日志文件路径为 /var/log/myapp.log
sudo chown root:root /var/log/myapp.log
sudo chmod 600 /var/log/myapp.log上面的设置表示日志文件归 root:root 所有，权限为 600，即只有 root 可以读写，其他用户无权访问。对于“不希望普通系统用户查看日志”的场景，这一步通常已经能挡住绝大多数非授权访问。
不过它也有边界：文件权限只能控制“谁能碰到这个文件”，无法进一步区分“哪个进程可以访问、哪个进程不行”。如果你的 Java 服务和其他服务共机运行，或者你希望把访问范围限制到更细的进程上下文，就需要更强的系统级策略。
需要更细粒度时，用 SELinux 做进程级限制
当单纯的 Unix 文件权限不够用时，SELinux 可以提供更严格的访问控制。它不是只看文件属主和权限位，而是把进程、文件、操作类型都纳入策略判断，适合对日志访问边界要求更高的环境。
首先确认 SELinux 处于启用状态：
sudo setenforce 1之后可以根据审计日志，为 Java 应用生成自定义策略模块。原文给出的示例如下：
# 创建一个自定义的SELinux策略模块
sudo ausearch -c 'ja va' --raw | audit2allow -M myapp-ja va-log
# 加载并启用策略模块
sudo semodule -i myapp-ja va-log.pp这组命令的思路是：先从系统审计记录里找出与 ja va 相关的访问行为，再通过 audit2allow 生成策略模块，最后用 semodule 导入并启用。这样做的价值在于，你可以把“允许谁访问日志”收敛到特定进程上下文，而不是只停留在文件层面。
这一层通常适用于几类场景：一是服务器上运行着多个服务，不希望它们彼此接触日志；二是业务日志涉及敏感字段，需要额外限制运维侧或其他进程的读取路径；三是已经有 SELinux 管理基础，希望把日志访问也纳入统一策略。
要注意的是，SELinux 的能力更强，配置复杂度也更高。对小型项目来说，它未必是第一步；但在多租户、合规要求较高或系统本身已经启用 SELinux 的环境里，它往往比单纯改权限更可靠。
日志经由接口暴露时，再补网络访问控制
有些 Java 应用不会直接让人登录服务器看日志，而是通过 Web 服务、日志查询接口或管理端口对外提供访问。这种情况下，仅靠文件权限是不够的，因为真正的入口已经变成网络请求。
如果要限制只有特定 IP 能访问相关端口，可以直接在防火墙层处理。以 iptables 为例：
# 允许特定IP地址访问日志文件
sudo iptables -A INPUT -p tcp --dport 80 -s 192.168.1.100 -d localhost -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j DROP这组规则表达的逻辑很直接：先放行来自 192.168.1.100、目标端口为 80 的访问，再丢弃其他到该端口的请求。对于只允许堡垒机、日志采集机或运维终端访问日志接口的场景，这一层非常实用。
如果系统使用的是 firewalld，可以写成 rich rule：
# 允许特定IP地址访问日志文件
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="80" accept'
sudo firewall-cmd --reloadfirewalld 更适合需要长期维护规则的环境，语义也更清晰。无论使用哪一种，本质上都是把日志访问入口前移到网络边界，先判断“谁能连进来”，再谈后续认证和查看范围。
这一手段最适合日志已经通过 Web 服务暴露出去的情况。若日志只在本地文件中存在，没有独立的网络访问入口，那么它的收益就没那么高，重点还是应放在文件和进程权限上。
别忽略日志轮转：既控体积，也控新旧文件权限
日志访问控制不只是“拦住谁来看”，还包括“避免日志长期堆积、难以管理”。日志文件无限增长，不但会拖累读写性能，也会让历史敏感信息长期裸露在磁盘上。这个时候，logrotate 就不只是运维工具，也是一种权限治理手段。
示例配置文件可以放在 /etc/logrotate.d/myapp：
/var/log/myapp.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 640 root root
}这段配置对应几件事：
轮转周期和保留数量
daily 表示每天轮转一次，rotate 7 表示保留最近 7 份历史日志。这样旧内容不会无限累积，清理边界也更明确。
压缩旧日志
compress 与 delaycompress 用于压缩历史日志，既能节省空间，也能让“当前活跃日志”和“历史归档日志”在管理上更容易区分。
创建新日志时同步设定权限
最关键的是 create 640 root root。它表示轮转后新建日志文件时，权限直接设为 640，属主与属组都是 root。这样不会出现“手动改过一次权限，但轮转后新文件又变松”的问题。
对很多团队来说，这一步经常被忽略。实际落地时，日志文件本身权限设对了，只能说明“现在安全”；而轮转配置把权限一并固化下来，才能说明“后续仍然安全”。
日志量大或审计要求高时，引入日志管理系统
当应用数量、日志规模和审计需求继续上升，单机上的权限、SELinux 和防火墙仍然重要，但已经不足以覆盖全部问题。此时更合适的做法，是把日志收集、检索、分析和访问授权统一交给专门的平台。
原文提到的方案包括 ELK Stack（Elasticsearch, Logstash, Kibana）以及 Fluentd。这类系统的价值，不只是“把日志集中起来”，更在于它们可以在平台层定义访问规则，例如：
- 哪些用户能查看哪些应用的日志；
- 哪些来源的日志允许写入系统；
- 是否需要按团队、业务线或环境做隔离；
- 是否要保留检索、审计和分析能力。
这类方案的代价也很明确：部署更重、维护更复杂、资源消耗更高。因此它更适合多应用集成、长期运维、需要审计追踪或跨节点统一管理的环境，而不适合为了看一个小服务日志就仓促上整套平台。
可以把它理解为“从文件访问控制，升级到日志治理体系”。如果你已经遇到日志分散、权限边界混乱、检索困难或审计要求提升的问题，那么单点加固很可能已经不够，集中式管理会更有长期价值。
怎么选：按风险层次逐步加，不必一步到位
CentOS 中给 Java 日志做访问控制，没有单一万能方案，关键在于把手段用在合适的位置上。
- 只想先拦住普通本地用户，优先做文件权限；
- 需要限制到进程级别，补上 SELinux；
- 日志通过接口对外提供，增加防火墙规则；
- 担心日志长期堆积和新文件权限失控，配置 logrotate；
- 面对大规模日志、复杂授权和审计需求，再考虑 ELK Stack、Fluentd 这类系统。
实际部署时，通常不是五选一，而是从基础权限开始，按系统层、网络层和平台层逐步叠加。这样既能控制复杂度，也能让日志安全真正落到可执行、可维护的配置上。
