选择使用Elastic Cloud的客户可以放心，其使用随机分配的彼此独立密码配合X-Pack安全产品对集群加以保护。客户为这些集群选择对应的AWS服务区，而集群本身亦被部署在冗余防火墙及代理之后。默认配置提供来自互联网的加密TLS通信内容，且Elastic每七天对集群数据进行一次备份。
对于其它部署选项，我们强烈建议大家确保那些可能存在安全问题的Elasticsearch实例不会直接暴露在互联网当中。具体请参阅我们2013年发布的博文。我们还将相关建议以localhost内默认安装绑定的形式加以实施。尽管如此，面对各类互联网可访问实例，我们已经意识到其中存在的安全隐患。
如果大家拥有一套非安全且面向互联网的Elasticsearch实例，那么我们强烈建议您立即采取以下措施以保护您的数据：
对全部数据备份至安全位置，并考虑使用Curator快照。
对您的环境进行重新配置，从而将Elasticsearch运行一套隔离型不可路由网络当中。
如果您必须通过互联网访问对应集群，请通过防火墙、VPN、反向代理或者其它技术手段限制来自互联网的集群访问请求。
而作为最佳实践原则，我们始终建议您：
升级至Elastic Stack的最新版本。
如果您运行的是v2.x版本，请检查您的scripting设置; 在新的v5.x版本中则请检查Painless脚本设置。
利用X-Pack安全工具添加TLS加密、验证、授权以及IP过滤等功能，从而保护您Elasticsearch实例。
更早的呼声：不在公共网络中暴露集群
在ElasticSearch服务器集群收到攻击的当天，搜索及大数据专家Itamar Syn-Hershko便撰文
“抵抗被洗劫：妥善保护您的Elasticsearch集群”详细支招怎样对抗此次劫持，Itamar是以色列的独立咨询师，他的公司code972是Elastics公司的合作伙伴。
Itamar 强烈呼吁：
无论如何，请千万不要让您的集群节点暴露在网络当中。虽然这听起来像是废话，但事实上用户们往往并没有切实遵循这项最佳实践。您永远不应将自己的集群暴露在公共网络当中。
Itamar 对七条推荐实践进行了分析，探讨确保集群安全的“该”与“不该”作法。以下为其文章的翻译：
1、启用HTTP的节点应该仅监听私有IP
Elasticsearch可通过配置限定其所监听的IP，而大家可以控制作为其合法监听对象的本地主机、私有IP、公共IP或者这几类对象的组合。在现实使用中，我们没有任何理由yhElasticsearch监听公共IP或者可公开访问的DNS名称。
这项设置被称为network.bind_host或者简写为network.host，而大家应始终将其设定为仅适用于私有IP（在某些例外情况下，亦可加入某些本地主机）。
让我们再次重申：network.bind_host应当始终被设定为私有网络接口，而永远不可被设定为公共IP或者DNS。
这将影响到HTTP访问与本地Java客户端访问。在某些用例中，我们可能需要实现某客户端节点的公开访问，具体解决办法如下。
2、使用代理实现客户端通信
作为一类常见误区，人们通常表示“嘿，Elsticsearch属于REST over HTTP，我们直接通过智能HTML客户端进行访问即可。”事实上，这种作法极不可取。
如果大家的单页面应用需要查询Elastic并获取JSON作为显示内容，那么将通过具备过滤、审计记录以及最重要的数据密码保护功能的软件代理加以实现。
如果不这样做，那么我们很可能面临以下三种后果：（1）您将其明确绑定至某公共IP，这种作法非常危险; （2）导致数据面临意外修改的风险; （3）最糟糕的是，您无法控制谁在对哪些数据进行访问，而且全部数据皆可供外部查看。而本次出现的Elasticsearch集群劫持事件正是引发了这种情况。
另外，也不要暴露您的文件与索引结构，亦不可对您的瘦客户端同为其提供数据的数据存储系统进行耦合。您的客户端JavaScript绝对不应与Elastic DSL直接通信。
您的客户端应该与服务器端软件进行通信，并由后者将全部客户端请求转发至Elasticsearch DSL、执行查询、而后有选择地将来自Elasticsearch的响应结果返回至客户端。另外，在对Elasticsearch进行任何访问之前，您的服务器端应用显然应验证用户登录凭证，从而确保其身份及授权符合操作数据的相关要求。如若不然，您的集群很可能陷入风险，并直接导致数据为贪婪的攻击者所获取。
3、如果可能，将Elasticsearch运行在隔离网络当中