本系列故事纯属虚构,如有雷同实属巧合
小B在实现了统一日志分析平台后,想到的第一个问题就是平台的安全性,用于安全分析的平台被攻击成功,那么小B将颜面扫地还可能被扫地出门。所以小B认证分析了平台可能存在的安全风险:
- 平台产品自身的安全漏洞(解决方案:及时安装补丁或升级版本);
- 数据泄露:在采集存储使用等过程中造成的数据泄露问题(解决方案:加密);
- 未授权访问:平台无任何访问控制措施导致未授权访问(解决方案:见后文);
对于平台的安全性,小B觉得首要的是使用没有已知漏洞的产品版本,其次就是添加访问控制。对于小B的日志分析平台,其中有这么几个地方需要额外注意:ES与Kibana的安全性、Kafka的安全性。
通用访问控制实现
使用防火墙实现第一层访问控制是常见也是很多中小型企业使用的方法。大家一般在网络防火墙(云安全组)、本机防火墙实现访问控制功能。
在使用防火墙时,推荐使用白名单对平台的安全性进行保障,我这里使用firewall实现基础的访问控制:
# 如果操作系统是Centos系列7以上版本,推荐使用
# 保护Kafka与Zookeeper
# 只允许Kafka的机器访问ZK,这种方法也是最有效防护ZK未授权访问导致信息泄露的办法
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.10.9" port port="2181" protocol="tcp" accept'
# 只允许Beats机器访问Kafka
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.10.0/24" port port="9092" protocol="tcp" accept'
# 只允许办公网络IP访问Kibana
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="182.*.*.107" port port="5601" protocol="tcp" accept'
# 如果白名单IP比较分散,可以使用firewall结合ipset,关于ipset的使用大家就自行百度吧!
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source ipset="ipset_name" port port="9092" protocol="tcp" accept'
Elastic安全性
Xpack实现访问控制
Elastic在6.8与7.2版本之后开放了免费认证功能。我这里是7.4.1的实验环境:
# 停止Kibana与elasticsearch服务
systemctl stop kibana.service
systemctl stop elasticsearch.service
# 创建es证书颁发机构
/usr/share/elasticsearch/bin/elasticsearch-certutil ca
# 创建es集群通信证书
/usr/share/elasticsearch/bin/elasticsearch-certutil cert --ca /etc/elasticsearch/elastic-stack-ca.p12
# 修改证书权限
chmod 644 /etc/elasticsearch/elastic-certificates.p12
# 修改配置文件
vim /etc/elasticsearch/elasticsearch.yml
# 在文件末尾添加如下内容
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/elastic-certificates.p12