不久前，众多MongoDB实例成为了骇客们取乐的牺牲品。转眼之间，这些无（ling）孔（ren）不（tong）入（hen）的骇客又把目标锁定在了Elasticsearch，今天小编带来的就是360DBA团队分享的Elasticsearch安全策略，希望可以帮助到大家。

背景

不久前，众多MongoDB实例成为了骇客们取乐的牺牲品。转眼之间，这些无（ling）孔（ren）不（tong）入（hen）的骇客又把目标锁定在了Elasticsearch。说来也难怪，谁让Elasticsearch设计之初就定位在纯私网环境而不做权限和安全控制呢（这么说其实有些绝对，毕竟还有个叫Security Manager的东东嘛）。不过话又说回来，人家确实专门出了个收费的Shield来保护你，可是你不买账啊！（难怪骇客如此猖獗？？？！！！怎么感觉满满的都是套路啊，难道……）。

咳咳，跑远啦，咱回来接着唠。

如果说“如何保证Elasticsearch的安全”已成为大家年夜饭之前最大的心结，个人觉得并不为过了吧。幸好我们在决定使用Elasticsearch之前就提前预见到了这个问题，并做了相关工作来保证Elasticsearch的安全。下面就把一些干货分享给大家，希望能给大家提供一些借鉴和帮助。

安全策略

网络层

除却“内鬼”的因素，骇客的攻击基本都是通过外部网络，所以这里是保障Elasticsearch安全的第一道屏障。相信大家都有自己的网络安全策略，硬件防火墙也好，软件防火墙也罢，按照自己的需求做好设置和维护即可。可是如果没有的话，那对不起，“蓬门今始为君开”，骇客岂有不光顾的道理。

OS层

卸载公网IP

如果说网络屏障给大家圈起了“院墙”，那我们服务器上的公网IP就像是搭在后院墙上的“梯子”。虽然有了围墙，却也难保不会有顺梯翻墙的“梁上君子”。所以如果大家的Elasticsearch都在内网环境使用，尽量卸载掉没有使用的公网IP吧，腾出网卡做更多有意义的事情。

普通用户启动

之前已经不止一次的曝出Linux下各种ROOT提权的问题，所以还是建议使用非ROOT用户启动Elasticsearch吧，并且相关数据目录的权限和属主一并改为非ROOT用户。就像是把你家金库托管给你最信任的人一样。

Server层

替换默认端口

众所周知，Elasticsearch默认的http.port是9200，集群各节点间的通信端口transport.tcp.port是9300；这就像是你家金库的大门，如果一眼就能辨识，那骇客攻击就可以在最短的时间做到有的放矢。

所以强烈建议替换掉Elasticsearch的监控端口，就像是给你家金库做了个“暗门”，骇客想要进入金库至少先得找到门路才行。

用户及权限认证

如果说Elasticsearch是一个存放着宝贝，时刻受到“梁上君子”觊觎的保险柜，那么没有开启权限认证的Elasticsearch就像是没有密码锁一样，只要找到了这个保险柜，那里面的宝贝就可以任之取之了。所以要避免骇客入侵的最有力的手段，也是最后一层屏障，那就是用户及权限认证。

可是在开题我们就说到了，Elasticsearch本身没有用户及权限认证体系。

虽然官方提供了自己的权限管理系统—— Shield， 但是它——收费！ （小编不自觉的竖起了中指）

本着“能免费用，绝不花钱买”的持家宗旨，在这里给大家介绍一款实用的开源Elasticsearch权限管理系统——Search Guard

先来看看Search Guard都支持哪些功能及特性：（请原谅小编是个截图党）

接下来就大家最关心的问题简单总结一下（这里只翻译一下免费版提供的功能）

  1. Search Guard支持Transport Layer（Node-to-node）和REST Layer（HTTP/HTTPS）的SSL/TLS加密传输，并且Transport Layer和REST Layer都可以单独配置是否开启SSL/TLS加密。

  2. Search Guard提供了一套完整的“用户-角色-权限”控制系统。免费版权限可以控制到indice/type、host级别。

  3. 如果需要Document level security（DLS）和Field level security（FLS）级别的权限控制，或者Audit logging审计功能，或者需要支持如LDAP、Kerberos等第三方用户认证系统的话，那就乖乖购买Enterprise License吧（每个集群一个License，无所谓集群规模）。

  4. Search Guard权限可以动态配置，我们可以把需要的权限添加到对应的文件，这些文件都作为文档存储在Elasticsearch中的searchguard索引中，然后通过sgadmin工具来更新配置（即将文件加载到ES），加载后立即生效，无需重启ES节点。

  5. Search Guard 以插件的形式发布，它要提供服务需要依赖Search Guard SSL。在Elasticsearch 5.x之前需要单独安装Search Guard和Search Guard SSL；Elasticsearch 5.x之后，Search Guard默认已经集成了对应版本的Search Guard SSL，无需单独安装了。

补充一点，Search Guard可以实现和Logstash、Kibana的完美结合，对于使用ELK的用户大可不必担心，修改集成很容易的。

并且，Elasticsearch在5.x之后，对Search Guard、Search Guard SSL （当然还有Logstash 、Kibana）等插件的版本号都做了统一，变得更加的简单直观了。

总结

以上是我们在部署Elasticsearch时所作的一些安全策略，把这些分享出来希望可以帮助到大家。有一些策略其实很简单，可往往越是细小的点，越容易被大家忽略，越容易成为日后维护的坑。

关于Search Guard的安装配置维护，我们后续会推出一个小的系列专门介绍，绝对干货，敬请期待！

声明：本文来自HULK一线技术杂谈，版权归作者所有。文章内容仅代表作者独立观点，不代表士冗科技立场，转载目的在于传递更多信息。如有侵权，请联系 service@expshell.com。