1. 背景与目标
1.1 适用场景与目标
在企业日志体系中，Filebeat 作为数据采集端需要通过网络传输日志到 Elasticsearch 或 Logstash，确保传输过程的安全性是关键。本文聚焦在 CentOS 环境下实现 Filebeat 数据传输的 TLS/SSL 加密，并覆盖证书管理、密钥存放与轮换等要点。通过配置 TLS，可以有效阻止数据在传输途中的窃听与篡改。
在设计时，我们优先考虑 对等端认证（互信/双向认证）与证书吊销机制，以便在大规模部署中快速定位受信任的客户端与服务端。With TLS，数据在传输层获得加密，后端组件（如 Elasticsearch 或 Logstash）可基于证书进行身份校验，降低仅靠 IP 或口令的安全风险。
核心要点包括：证书颁发机构（CA）的信任根、客户端与服务端证书的有效性、密钥的安全存放、以及证书轮换的可控性。本文将围绕这几个要点展开，帮助你在 CentOS 上落地一个可维护的 TLS/SSL 加密传输方案。
2. 环境准备与依赖
2.1 安装 Filebeat
在 CentOS 上安装 Filebeat，通常通过系统自带包管理器进行，确保版本与 Elasticsearch/Logstash 端的 TLS 要求兼容，并在安装后启用服务以实现自启动。执行流程包括获取仓库、安装包、以及开启服务。
# 以 CentOS 8 为例
sudo dnf install -y epel-release
sudo dnf install -y filebeat
sudo systemctl enable filebeat
sudo systemctl start filebeat
安装完成后，请务必检查 filebeat 支持的日志路径与配置文件位置，默认通常位于 /etc/filebeat/。正确的权限设置对于后续 TLS 配置至关重要。
2.2 服务与防火墙设置
为了确保 Filebeat 能够将日志发送到后端目标，需打开必要端口并确保网络连通性。默认使用 HTTPS 通道时，需要放通相应的 9200/5044 等端口，并确保服务器证书可被客户端信任。
# 示例：放行 Elasticsearch 监听端口（HTTPS）与 Logstash 监听端口
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-port=5044/tcp
sudo firewall-cmd --reload
在生产环境中，建议结合 公网与私网分离、ACL、以及基于证书的双向认证来提升安全性。
2.3 目录与权限
TLS 私钥与证书的存放位置应具备严格的访问控制，推荐放置在 /etc/filebeat/certs/ 并归属 filebeat 用户，以避免未授权访问。正确的权限策略将直接影响私钥的安全性。
sudo mkdir -p /etc/filebeat/certs
sudo chown -R filebeat:filebeat /etc/filebeat
sudo chmod 750 /etc/filebeat /etc/filebeat/certs
3. 证书与密钥的生成与管理要点
3.1 CA、服务器与客户端证书的关系
在 TLS 加密中，CA 是信任根，服务器证书用于验证后端服务的身份，客户端证书用于验证客户端身份（如需要双向认证时）。通过将所有证书链建立在同一个受信任的 CA 之下，可以实现对客户端、服务器端的统一信任管理。
分层的证书架构有助于密钥轮换、吊销以及跨环境部署的统一管理。保持 CA 私钥的安全性是最重要的环节，任何泄露都可能导致全链路信任被破坏。
在实际运维中，很多企业会把 CA、服务端证书和客户端证书放在受控的密钥库或版本控制之外的安全仓库中，并通过自动化流程完成证书的签发与轮换。
3.2 证书生成流程与密钥管理
以下示例展示一个简化的证书生成流程，使用 OpenSSL 生成 CA、服务器端证书与 Filebeat 客户端证书。请在生产环境中结合正式的 CA 签发与证书吊销列表（CRL）/在线证书状态协议（OCSP）进行完善。
# 1) 生成 CA 私钥与自签名证书
openssl genrsa -out /etc/filebeat/certs/ca.key 4096
openssl req -x509 -new -nodes -key /etc/filebeat/certs/ca.key -sha256 -days 3650 -out /etc/filebeat/certs/ca.crt -subj "/CN=MyCompany CA"# 2) 生成服务器证书（Elasticsearch 端）
openssl genrsa -out /etc/filebeat/certs/es_server.key 2048
openssl req -new -key /etc/filebeat/certs/es_server.key -out /etc/filebeat/certs/es_server.csr -subj "/CN=es.example.com"
openssl x509 -req -in /etc/filebeat/certs/es_server.csr -CA /etc/filebeat/certs/ca.crt -CAkey /etc/filebeat/certs/ca.key -CAcreateserial -out /etc/filebeat/certs/es_server.crt -days 3650 -sha256# 3) 生成 Filebeat 客户端证书
openssl genrsa -out /etc/filebeat/certs/filebeat.key 2048
openssl req -new -key /etc/filebeat/certs/filebeat.key -out /etc/filebeat/certs/filebeat.csr -subj "/CN=filebeat-client"
openssl x509 -req -in /etc/filebeat/certs/filebeat.csr -CA /etc/filebeat/certs/ca.crt -CAkey /etc/filebeat/certs/ca.key -CAcreateserial -out /etc/filebeat/certs/filebeat.crt -days 3650 -sha256# 4) 设置合适的权限
chmod 600 /etc/filebeat/certs/*.key
chmod 644 /etc/filebeat/certs/*.crt
chown -R filebeat:filebeat /etc/filebeat/certs
生成完成后，将 CA 证书、服务器证书及客户端证书分发到对应端点，并确保路径与权限在配置中保持一致。对于生产环境，证书的轮换策略与吊销机制必须事先规划，以避免长期使用过期证书带来的安全风险。
4. 在 CentOS 上配置 Filebeat 的 TLS/SSL
4.1 文件路径与权限
将证书和密钥放在事先约定的目录下，并确保 Filebeat 进程能够读写所需文件。证书路径要在配置中正确引用，且密钥文件应仅对 filebeat 用户可读。
sudo mkdir -p /etc/filebeat/certs
# 将前面生成的证书复制或移动到该目录，并设置权限
sudo cp /path/to/ca.crt /etc/filebeat/certs/ca.crt
sudo cp /path/to/filebeat.crt /etc/filebeat/certs/filebeat.crt
sudo cp /path/to/filebeat.key /etc/filebeat/certs/filebeat.key
sudo chown -R filebeat:filebeat /etc/filebeat/certs
sudo chmod 600 /etc/filebeat/certs/filebeat.key
sudo chmod 644 /etc/filebeat/certs/*.crt
4.2 配置示例
在 Filebeat 主配置文件中开启 TLS，以下示例展示了典型的 Elasticsearch 端 TLS 配置（你也可以将相同配置应用于 Logstash 输出）。请根据实际端点及证书路径调整主机地址与证书路径。
# /etc/filebeat/filebeat.yml
filebeat.inputs:- type: logenabled: truepaths:- /var/log/*.logoutput.elasticsearch:hosts: ["https://es.example.com:9200"]# TLS 配置ssl.certificate_authorities: ["/etc/filebeat/certs/ca.crt"]ssl.certificate: "/etc/filebeat/certs/filebeat.crt"ssl.key: "/etc/filebeat/certs/filebeat.key"ssl.verification_mode: "full" # 也可以设置为 "certificate"、"none" 等，具体取决于需要的严格程度
# 如使用 Logstash 作为聚合端，请替换为 output.logstash 并保持同样的 TLS 配置
# output.logstash:
# hosts: ["https://logstash.example.com:5045"]
# ssl.certificate_authorities: ["/etc/filebeat/certs/ca.crt"]
# ssl.certificate: "/etc/filebeat/certs/filebeat.crt"
# ssl.key: "/etc/filebeat/certs/filebeat.key"
核心要点在于确保 filebeat 指向正确的证书文件，并在后端服务端启用对应的 TLS/SSL 支持。此配置有助于实现数据在传输过程中的加密与服务端身份确认。
4.3 轮换与重载
证书轮换通常包括替换新的证书并重新加载 Filebeat 配置。证书更新后应优先测试再落地，再通过重载或重启 Filebeat 生效。
# 更新证书后重载配置
sudo systemctl restart filebeat
# 可选择先测试配置语法
sudo filebeat test config -c /etc/filebeat/filebeat.yml -e
# 查看日志确认 TLS 相关错误已消失
sudo journalctl -u filebeat -n 200 -f
5. 加密传输的验证、监控与故障排查
5.1 验证加密通道
验证 TLS 通道是否生效的常见方法包括从客户端发起 TLS 连接测试，确保证书链正确、信任根可用，以及服务端证书匹配。可以使用 openssl s_client 进行现场验证：
openssl s_client -connect es.example.com:9200 -CAfile /etc/filebeat/certs/ca.crt
# 或验证 Logstash 端
openssl s_client -connect logstash.example.com:5045 -CAfile /etc/filebeat/certs/ca.crt
如果服务器使用了互相认证，需要提供客户端证书和密钥，以完成完整的 TLS 握手。 在连接日志中关注 "Verify return code" 字段，它应为 0，表示信任链无误。
5.2 日志与诊断
排查 TLS 问题时，Filebeat 的日志是第一手数据，通常位于 /var/log/filebeat/ 或通过 journald 查看。需要重点关注证书路径、权限、以及与后端服务端的 TLS 握手失败信息。
# 使用 journal 查看 Filebeat 日志
sudo journalctl -u filebeat -n 300 -f
此外，后端组件（如 Elasticsearch）的 TLS 配置也可能影响可用性，请同时检查 Elasticsearch 的证书是否在信任链中、以及是否启用了 TLS 版本兼容性。
5.3 运维要点
为了长期稳定运行，需建立系统的证书轮换与密钥管理策略。定期更新 CA 与证书，记录有效期、签发人、序列号，并在 CI/CD 中加入证书签发与分发的自动化流程。密钥的存放要分离于普通日志数据，采用最小权限原则，并在必要时启用证书吊销。
