在企业日志传输场景中，Ubuntu 上 Filebeat 数据加密全解：TLS 配置与证书管理实战以实操为导向，覆盖从基本原理到落地配置的完整过程。本篇文章聚焦与 Filebeat 在 Ubuntu 系统上的 TLS 加密传输，以及证书的生成、管理和轮换等关键环节。
1. 背景与目标：在 Ubuntu 上实现 Filebeat 数据加密
1.1 数据传输加密的必要性
在分布式日志传输中，数据在传输过程中的机密性和完整性尤为重要。通过 TLS 加密通道，Filebeat 与目标接收端（如 Elasticsearch/Logstash）之间的日志数据可以抵御窃听、篡改和中间人攻击。
此外，证书信任机制确保双方在握手阶段仅信任经过签名的实体，从而降低未授权设备接入的风险。
1.2 TLS 的核心要素
TLS 依赖于公钥基础设施（PKI）、证书、私钥以及证书链。实现 Filebeat TLS 传输，通常需要一个受信任的 CA、Server 证书（Elasticsearch/Logstash 端）以及 Client 证书（Filebeat 客户端端）。
2. TLS 基础知识与 Filebeat 的加密传输实现
2.1 TLS/SSL 的工作原理快速回顾
TLS 握手阶段通过证书验证、对称密钥协商和会话密钥封装来实现端到端的加密通道。握手完成后，数据传输采用对称加密，确保通信过程的机密性和完整性。
在 Filebeat 场景中，传输层加密确保日志在发送端与接收端之间不会被窃取或篡改，即使网络环境不可信也是安全的。
2.2 Filebeat 的加密传输实现路径
Filebeat 通过输出端（output.elasticsearch 或 output.logstash）配置 SSL 参数来开启 TLS。ssl.certificate_authorities 指向信任的 CA 证书，ssl.certificate 与 ssl.key 指向 Filebeat 客户端证书与私钥，ssl.verification_mode 控制证书验名程度。
3. 证书管理与 CA 体系在实践中的落地
3.1 构建私有 CA 与证书体系
在企业内部通常会搭建一个私有 CA，用于签发服务器证书和客户端证书，形成一条完整的证书链。私有 CA 可以降低成本并提升运维控制力，但需要严格的权限管理和证书轮换策略。
生成 CA、服务器和客户端证书的工作应当分离，并确保 CA 私钥安全保存，最小化访问权限、使用受限账号执行相关操作。
# 生成私有 CA 证书
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt -subj "/CN=MyCompany CA"# 生成服务器证书（Elasticsearch/Logstash）
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=elasticsearch.local"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 3650 -sha256# 生成 Filebeat 客户端证书
openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr -subj "/CN=filebeat.local"
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 3650 -sha256
3.2 部署证书与密钥的最佳实践
将证书与私钥放置在受控位置，如 /etc/filebeat/certs，并设置合适的权限，例如 700/600 以防止未授权读取。 证书链完整性 要求 ca.crt、server.crt、client.crt 的版本和签名一致，避免版本冲突导致握手失败。
在客户端与服务器端分别配置正确的证书路径，确保私钥从不暴露给普通用户，并将文件权限纳入审计范围。
4. 在 Ubuntu 上配置 Filebeat 的 TLS
4.1 生成并分发证书到 Filebeat 节点与目标端
证书分发应遵循最小权限原则，将 ca.crt、client.crt、client.key 放在 Filebeat 的证书目录下，并设定合适的所有权与权限。
在目标端（Elasticsearch/Logstash）上部署 server.crt 与 server.key，并确保它们对服务器进程可读，但对其他用户不可读。
# 将证书部署到 Filebeat 主机
sudo mkdir -p /etc/filebeat/certs
sudo cp ca.crt /etc/filebeat/certs/
sudo cp client.crt /etc/filebeat/certs/
sudo cp client.key /etc/filebeat/certs/
sudo chown -R filebeat:filebeat /etc/filebeat/certs
sudo chmod -R 600 /etc/filebeat/certs/client.key
4.2 修改 Filebeat 配置文件示例
在 Filebeat 的配置中启用 TLS，指定证书路径、信任的 CA，以及对目标端的证书核验。配置示例是落地的关键，务必与实际证书路径保持一致。
# 文件：filebeat.yml
output.elasticsearch:hosts: ["https://elasticsearch.local:9200"]ssl.certificate_authorities: ["/etc/filebeat/certs/ca.crt"]ssl.certificate: "/etc/filebeat/certs/client.crt"ssl.key: "/etc/filebeat/certs/client.key"ssl.verification_mode: full
除了输出端，若采用 Logstash 作为聚合端，同样需要在 Logstash 的 input/filter/output 中配置相应的 TLS 设置，确保端到端的加密传输。
4.3 证书权限与密钥保护的要点
私钥的保护级别最高，应仅对运行 Filebeat 的系统用户可读。常见做法是将密钥设为 400，文件夹设为 700，并通过系统访问控制列表（ACL）加强权限管理。
定期审计证书路径的权限变更、密钥访问记录，以及证书到期情况，确保在到期前完成替换与重载配置。
# 仅允许 filebeat 用户读取私钥
sudo chown root:filebeat /etc/filebeat/certs/client.key
sudo chmod 400 /etc/filebeat/certs/client.key
4.4 测试 TLS 连接与验证
在上线前进行端到端的 TLS 连通性测试，确认 Filebeat 能正确连接到 Elasticsearch/Logstash，并通过证书校验。openssl s_client 是常用的测试手段之一。
openssl s_client -connect elasticsearch.local:9200 -CAfile /etc/filebeat/certs/ca.crt -cert /etc/filebeat/certs/client.crt -key /etc/filebeat/certs/client.key
5. 证书生命周期管理与安全加固
5.1 证书轮换策略
制定<定期轮换证书的计划，例如每 1-2 年进行一次签发与替换。对服务器和客户端证书都应建立独立的轮换流程，确保在更换过程中最小化业务中断。
为轮换准备自动化脚本或任务计划，例如在到期前的 30 天发起重新签发并热加载配置，以实现零宕机更新。
# 示例：检查证书有效期并触发重载（简化示例）
EXPIRE_DAYS=30
CERT_FILE="/etc/filebeat/certs/client.crt"if [ -f "$CERT_FILE" ]; thenEXP=$(date -d "$( openssl x509 -enddate -noout -in $CERT_FILE | cut -d= -f2 )" +%s)NOW=$(date +%s)if [ $((EXP-NOW)) -lt $((EXPIRE_DAYS*86400)) ]; thenecho "证书即将到期，触发轮换流程"# 这里可以添加重新签发和重载 Filebeat 的逻辑fi
fi
5.2 监控与合规检查
建立证书到期、证书链完整性、以及密钥权限的自动化监控。通过定时任务或监控系统对 证书状态、密钥权限、以及 TLS 握手失败次数进行告警，提升安保态势感知。
另外，对信任锚点（CA）进行安全控制，避免受损的 CA 证书被继续信任，确保整个信任链的可靠性。
通过上述实践，您可以在 Ubuntu 环境中将 Filebeat 的数据传输完全落地为 TLS 加密传输，同时建立完善的证书管理体系，确保长期的日志传输安全性和可控性。
