在 CentOS 上保障 Filebeat 日志安全的要点
一 身份与最小权限
- 使用专用的非 root 账户运行 Filebeat（如创建用户 filebeat，并加入必要的补充组），避免使用 root 直接启动，降低被提权风险。
- 严格控制配置与密钥文件的访问权限：证书、私钥、filebeat.yml 建议设置为仅属主可读（如 600），属主为 filebeat；必要时使用 ACL 做细粒度授权。
- 不建议直接关闭 SELinux 或 firewalld 来“排障”，应通过正确的策略放行与最小权限原则来兼顾安全与可用性。
二 传输加密与身份认证
-
对到 Elasticsearch/Logstash 的链路启用 TLS/SSL：在 Filebeat 配置中开启 ssl.enabled，指定 ca.crt（服务器/CA 证书）、客户端 client.crt 与 client.key；将 Elasticsearch 的 xpack.security.http.ssl.enabled 设为 true，确保双向校验。
-
示例（输出到 ES，启用双向 TLS）：
filebeat.inputs:
- type: log
enabled: true
paths:
output.elasticsearch:
hosts: [“https://es.example.com:9200”]
ssl.enabled: true
ssl.certificate_authorities: [“/etc/filebeat/certs/ca.crt”]
ssl.certificate: “/etc/filebeat/certs/client.crt”
ssl.key: “/etc/filebeat/certs/client.key”
-
证书与密钥管理：使用 openssl 生成 CA 与客户端证书，私钥严格保护并定期轮换；自签名证书需在 ES 端正确配置信任链。
三 网络边界与访问控制
- 通过 firewalld 仅放行必要端口与来源网段：
- Filebeat→ES/Logstash：放行 5044/TCP（Logstash）或 9200/TCP（ES HTTP）。
- Kibana 管理面（如需要）：放行 5601/TCP。
- 建议将日志链路置于 内网/VPC 或专用网段，结合网络 ACL 限制来源 IP，减少暴露面。
四 数据完整性与可靠性
- 利用 Filebeat 的 ACK/确认与注册表机制（registry） 实现至少一次投递语义：事件在输出端确认后才会更新本地 registry 的 offset，异常时从断点重发，避免数据丢失。
- 通过内部队列与 反压机制 在下游异常时自动“背压”，输入侧暂停采集，优先保障本地日志落盘安全。
五 运行监控与持续加固
- 启用 X-Pack 监控 将 Filebeat 自身指标与健康状态上报至受保护的 ES，配合 Kibana 实时观测采集延迟、失败重试、吞吐等；必要时设置告警。
- 保持 Filebeat 与依赖组件 的版本更新，及时修补安全漏洞；定期审计配置、证书有效期与访问权限。
