Elasticsearch最佳实践：如何保证你的数据安全

这个周末，关注Elasticsearch动态的朋友应该都会被一条关于数据泄露的新闻吸引。虽然，这个事件中泄露的数据并非直接发生在Elasticsearch身上，但任何时候，我们都需要保持警醒，并掌握保证你的数据安全所需的知识，以及建立能够快速检测，并响应相关事件的流程机制，以减少损失。

一直在发生的数据泄露

无需强调，其实类似的事情一直都在发生：

历年的重大数据泄露事故

而每当我们看到类似的新闻，多数人的第一反应是，或者说打趣调侃的论调就是一个“大四实习生”程序员，因为一个错误的安全配置，导致了数据泄露的发生。我们哀其不幸，怒其不争，同时指摘发生数据泄露的相关企业薄弱的安全意识与安全管理能力。似乎是这种错误本可以很轻松就能避免，管理上和专业上的缺失，才是导致任由无良程序员使用错误配置的原因。

其实，我们还可以有一些更加深入的角度看待这个问题：

一，安全问题向来不是一个简单的基础设施安全配置或者安全策略的问题，过度调侃一个“外包程序员的不做基本的安全设置”的故事，会让我们误以为网络安全、数据安全是一个轻易就可以避免的问题，让程序员背锅，会让我们忽略背后的黑客对抗性行为。网络安全所面对的可能是专业的团伙，甚至是国家组织性质的黑客集团。整个攻击链路，可能始于某次外围员工的社交媒体钓鱼事件，然后渗透、横向移动、提权、驻留，一次次的操作才最后引发最终的数据泄露。仅仅只是解决程序员的专业技能，或者管理上的缺失并不能避免类似的事情发生。至少我们看到，即便是FANG组之一，拥有着世界上最优秀的程序员和高级管理人员，甚至是已经数次发生过数据泄露事故，按理说，技术、经验、教训都已经到位了，应该不会再发生类似事故了，仍然免不了再次沦陷在这个战场。

二，当数据已经变为了一种可以变现的资产，有高额收益的存在，必然会有人为此铤而走险。当有人算计着你的数据，随时想方设法的想偷点什么的时候，就不再是一个孤立的事件，而是一个持续发生的对抗性行为。在安全思想上，应该承认风险、漏洞的必然存在，100%的攻击防御已经是天方夜谈，不能仅仅依靠各种边界防御设备，应同时着眼于被渗透之后的快速检测和响应机制，将损失收敛到最小的范围。

三，语言攻击并不能使用人成长，持续的指摘、抱怨并不能带给我们更多的保护，需要认清我们目前面临的情况。可以看到，个人隐私数据已经成为数据泄露事件的重灾区。数据无论是放在政府还是企业，风险敞口都是存在的。黑客无国界，我们面对的是以勒索或者贩卖为主要目的行为，更多应该要在数据安全立法和安全防护总体措施上去解决问题，而不是盯着程序员的错误。

按数据类型分类的数据泄露事件

Elasticsearch的数据安全设置

虽然绝大多数的数据泄露事件都并非来自于软件的漏洞或者不合理的设计。但充分了解如何正确的配置软件的安全选项仍然是软件开发人员，基础运维人员，安全运维人员需要掌握的技能。关于数据安全，至少需要包含以下几个方面：

• 数据存储安全
• 数据通信安全
• 数据访问安全

这几个部分，由上至下，重要级递增。以下，我们按照顺序介绍Elasticsearch提供的相关能力

数据静态加密支持（数据存储安全）

虽然 Elastic Stack 不能直接实施数据静态加密，但我们建议在所有主机上都配置磁盘级别加密。此外，快照目标也必须确保对数据进行静态加密。例如，在Linux系统上，我们可以通过dm-crypt等软件对磁盘进行落盘加密。而对于快照数据，则经常是被或略的地方，特别是当我们选择将备份数据放在公共网络可访问的区域时，更应该小心。应该选择一个加密的快照存储仓库，然后使用elasticsearch-keystore工具，对数据加解密通道所需的密码或证书进行有效的保护：

./bin/elasticsearch-keystore add repository.encrypted.test_enc.password

安全设置

某些设置很敏感，所以依赖文件系统许可来保护它们的值不外泄是不足够的。对于这一用例，Elastic Stack 组件会提供密钥库来防止在未经授权的情况下访问敏感的集群设置。用户还可以选择对 Elasticsearch 和 Logstash 密钥库进行密码保护，从而进一步增强安全性。

详细了解安全设置

数据通信安全

从下图可以看到，Elasticsearch提供了多种方式跟外部进行交互，我们可以通过Beats, logstash将采集和处理后的数据存储于Elasticsearch，也可以通过API接口，跟其他大数据平台进行对接。而通过Client & API的方式，对接的平台就更多了，比如，我们可以将快照的备份数据存储于对象存储仓库。。。

虽然说对接的生态极其丰富，但接口是统一的。主要集中在两个方面：

• 集群外，通过HTTPS/HTTP协议，默认在9200端口上提供restful API交互能力
• 集群内，通过传输层协议，默认在9300-9400端口上提供内部节点间的通信能力

因为数据通过网络传输，为了避免中间节点、网络流量镜像等带来的数据泄露风险，强烈建议通过流量加密，以及使用 SSL/TLS、节点身份验证证书等方式，来阻止针对 Elasticsearch 节点数据的网络攻击。

具体配置方式，可以在官方文档上，了解加密通信

在大多数情况下，通信安全的最佳实践还会要求我们尽量把Elasticsearch集群部署在专有网络当中，避免直接暴露在公共网络下面，以此减少被攻击到的可能

数据访问安全

Elasticsearch作为一个搜索引擎，其最主要的能力就是提供用户访问我们所希望获取的数据的能力，因此，无论是直接访问Elasticsearch，或者通过客户端，代理，网关访问，其实都是为所有人网络上直接或间接触达的用户开放了访问的权限。因此，数据访问安全会来得比前两个更复杂，也更重要。我们不仅仅需要通过用户名、密码，或者API key来做用户认证（Authentication）。还需要设置权限，确定特定账户对数据的访问级别（Authorization）。同时，对于一些更模糊的场景，比如，IP地址过滤，匿名共享，我们也需要更多的能力来支持。而对于企业内部共享，SSO，基于域的身份验证服务接入，也是必须的正确配置的；最后，对于访问安全，我们还会有审计和合规的需求需要去满足，以下，给大家简单介绍各个部分的功能：

以下为权限设置功能（Authorization）

基于角色的访问控制 (RBAC)

借助基于角色的访问控制 (RBAC)，您能够通过为角色分配权限以及为用户或群组分配角色来为用户授权。

了解 RBAC

screenshot-security-users-roles-feature-page.jpg

基于属性的访问控制 (ABAC)

Elastic Stack 的 Security 功能同时还提供基于属性的访问控制 (ABAC) 机制，通过该机制，您能够使用属性来限制搜索查询和聚合中文档的访问权限。这一功能可让您在角色定义中实施访问政策，这样用户只有在拥有全部必备属性时，才能读取特定文档。

了解 ABAC

匿名访问控制（用于公开分享）

从地图到仪表板，再到任何 Kibana 保存的对象，您现在可以创建专门的链接，让任何人都可以访问其中的资产，而不会被提示输入凭据。

了解匿名访问

字段和文档级别安全性

字段级安全性能够限制用户有权访问的字段。具体而言，其能限制从基于文档的只读 API 中可以访问哪些字段。

了解字段级安全性

文档级安全性能够限制用户有权访问的文档。具体而言，其能限制从基于文档的只读 API 中可以访问哪些文档。

了解文档级安全性

以下为用户认证功能（Authentication）

Security Realm

Elastic Stack 的 Security 功能会使用 Realm 或者一个或多个基于令牌的身份验证服务来验证用户身份。Realm 可基于身份验证令牌来解决问题并验证用户身份。Security 功能提供大量内置 Realm。

了解 Security Realm

• 原生
• LDAP
• Active Directory
• PKI
• File
• SAML
• Kerberos
• JWT

单点登录 (SSO)

通过将 Elasticsearch 作为后端服务，Elastic Stack 支持通过 SAML 单点登录方式 (SSO) 登录 Kibana。通过 SAML 身份验证，可以允许用户使用外部身份提供商服务（例如 Okta 或 Auth0）登录 Kibana。

了解 SSO

第三方安全性集成

如果 Elastic Stack 中提供的开箱即用型 Security 功能不支持您使用的身份验证系统，您可以创建一个自定义 Realm 来验证用户身份。

了解第三方安全性

以下为审计和合规功能

审计日志

您可以启用审计来跟踪安全相关事件（例如身份验证失败以及遭拒的连接请求）。对这些事件进行日志记录能够让您监测自己集群中的可疑活动，并在遭受攻击时提供证据。

了解审计日志

IP 筛选

您可以针对应用程序客户端、节点客户端或者传输客户端（而不仅局限于尝试加入集群的其他节点）应用 IP 筛选。如果某节点的 IP 地址在黑名单中，Elasticsearch 安全功能虽允许其连接至 Elasticsearch，但会立即断开连接且不会处理任何请求。

IP 地址或范围

xpack.security.transport.filter.allow:"192.168.0.1"
xpack.security.transport.filter.deny:"192.168.0.0/24"

白名单

xpack.security.transport.filter.allow: [ "192.168.0.1", "192.168.0.2", "192.168.0.3", "192.168.0.4" ]
xpack.security.transport.filter.deny: _all

IPv6

xpack.security.transport.filter.allow:"2001:0db8:1234::/48"
xpack.security.transport.filter.deny:"1234:0db8:85a3:0000:0000:8a2e:0370:7334"

主机名

xpack.security.transport.filter.allow: localhost
xpack.security.transport.filter.deny: '*.google.com'

了解 IP 筛选

FIPS 140-2 模式

Elasticsearch 提供一种符合 FIPS 140-2 规范的模式，此模式可以在已启用的 JVM 中运行。通过使用 FIPS 批准/NIST 推荐的加密算法，可以确保遵守处理标准。

了解 FIPS 140-2 遵从性

Section 508 法案

如果您的 Elastic Stack 部署需要满足 Section 508 合规性标准，我们的 Security 功能可以满足您的需求。

了解不同的合规性方案

标准 (GDPR)

按照 GDPR 指南，您的数据很有可能会归为个人数据。了解您可以如何使用 Elastic Stack 的功能（从基于角色的访问控制到数据加密）来保护自己的 Elasticsearch 数据，从而满足 GDPR 的安全和处理要求。

阅读 GDPR 白皮书

数据安全事件的检测和响应

即便我们已经完全按照建议的方式，正确的配置了所有的安全选项，其实还是无法100%的避免数据泄露的问题。试想，无论是一个程序员不小心在网络上发布了用于数据访问的地址，access id，access key，还是对手黑入你的电脑，获得了你的所有令牌和密码，在拥有正确钥匙的小偷面前，再高级的防护门都是没有用的。

在边界防御的基础上，我们还需要的一套更加全面的检测和响应机制。首先要做到的是，不能有数据盲点，所有的数据都处于可查，可监控的状态。第二，要有基础的防护规则，对于快照仓库，读写权限均应该只开放给特定用户，并且对读写流量进行监控。第三，应该建立正常的行为模式基线，对于没见过的ip、用户访问敏感数据，应该设置告警。

比如，对于数据泄露的案例，网络流量的监控就异常重要：

来源ip、目的ip、对应的协议、流量等基础信息都应该处于被检测的状态。只有获取完成的数据并进行持续的监控，我们此有可能在侵害的开始阶段尽早发现并组织。

并且，应该有特定的规则，进行一些端口、网络流量的限制：

elastic内置的检测规则

更主要的，是需要结合机器学习的行为模式发现，当出现异常时间、异常地点、异常ip、异常流量的时候， 可以在没有阙值可以准确设置的情况下，由机器学习来进行预警

elastic内置的机器学习规则

基于机器学习的网络流量异常检测

总结

数据安全，从来不是一件简单的事情。发展到现在，也不再是通过简单的防御就能够解决的问题。

数据可见性、检测与响应，成了摆在我们面前，非常迫切，且需要解决的事情。需要的技术不仅是数据的准确、有效、及时的采集，也包括各种分析技术的发展，从而准确的寻找数据中的异常。同时，安全响应流程、应急机制则需要规范建设。最后，所有的网络攻防，都是人与人之间的攻防，而非人与机器，战术，战略都需要参考其中。

人、技术、流程，会一直都是我们构建有效安全运营的核心