通过加密、用户等功能免费确保 Elasticsearch 集群安全的提示 | Elastic Blog
工程

通过加密、用户等功能免费确保 Elasticsearch 集群安全的提示

我们在 Elastic Stack 6.8 和 7.1 的默认分发包中免费提供了大量 Elasticsearch Security 功能,以便让更广泛的全体用户可以从中受益。我们对这一点的确倍感兴奋,但现在出现了一个新难题,即需要就如何确保 Elastic Stack 安全性这一主题更新全部文档和指南。仅依赖一个代理服务器就能确保 Stack 安全性的时代,已经一去不复返!

我已经查看了之前大部分热门的安全类博文,现在我要对指南进行更新,消除人们的误解,提出一些新想法,并确保您能够比之前更好地确保 Stack 的安全性。

我在这里不会提供之前任何博文的链接;由于 Elastic Stack 多年来的长足发展,对于之前博文中给出的某些建议,我们现在觉得会带来危险。(谨慎对待之前博文中提到的安全建议,现在一切都变化很快。) 对于所有这些之前文章的链接,我们都会将它们重定向到此页面,但是如果您看到其他网站仍在展示这些之前的文章,请将此页面的链接转发给相关网站。

TLS 加密

TLS 加密现在是默认分发包中 Elasticsearch 和 Kibana 免费 Security 功能的一部分。TLS 的目的是对网络通信进行加密。对集群内节点间的通信、客户端与集群之间的通信,以及从 Kibana 到用户之间的连接,我们都会进行加密。

我们还通过使用 TLS 证书来确保可以允许节点加入集群。没有 TLS,可能任何人都可以向集群中添加节点。虽然这一漏洞可能会被各种险恶用心的攻击者利用,但更常见的情况则是节点意外加入错误的集群。TLS 可帮助避免这些问题,因为没有正确的证书,节点便无法加入集群。

在 6.8 和 7.1 推出之前,如果使用的是基础型证书而又需要在 Elastic Stack 上应用 TLS,您必须依靠某些类型的代理,这便会为设置步骤增加大量工作。即使无需在节点和客户端之间设置代理,TLS 本身也很难配置。如要添加代理,则是难上加难。我们现在可以直接在 Elastic Stack 中利用 TLS 支持。

我们有很多 TLS 配置方法的相关文档。如曾使用过 TLS,您肯定知道设置证书从来都不是件简单的事儿,但是我们提供了内置工具来帮助生成全集群证书和证书颁发机构,帮您简化设置过程。 请关注这一版块的动态,因为我们之后还会发表一些博文来详细讲述如何以最佳方式在全部 Elastic Stack 组件中配置 TLS。有没有两种最简单的方法可让我立即开始使用?请查看这篇博文 Elasticsearch Security 功能入门,或者也可以了解我们的官方 Kubernetes Operator

身份验证

随着 6.8 和 7.1 的推出,现在所有用户都可以使用原生身份验证功能。身份验证的目的是让客户端向 Elastic Stack 表明自己的身份。这通常就是大家所熟知的用于登录系统的用户名和密码。业内基本已达成共识,将满是数据的集群面向全世界开放可不是什么好主意。如果集群直接连至互联网,因为任何人无需使用密码便可访问互联网,这尤为危险。

之前的建议是,在客户端和集群之间使用已启用基础身份验证的 Nginx 服务器。要想正确完成这一配置,难度可谓无比之大。由于每个节点都可以完成外部请求,所以如果您忘记对某个节点应用防火墙,任何人都可以无需身份验证便连接至您的集群。

我们现在允许使用原生文档 Realm 来免费进行身份验证。文档 Realm 会在每个节点的一个文件中存储用户信息。您必须确保在所有节点上对此文档进行同步。原生 Realm 则可以提供更加精简的体验,其执行过程也和用户的期望基本相符:用户数据存储在集群上的索引中,并且每个节点都可访问该索引。您通过 REST API 添加用户名和密码,然后这些账户便可登录了。有关更多详情,请参看博文如何开始使用 Elasticsearch Security 功能

如果您的身份验证需求更加复杂,例如 LDAP、Active Directory、SAML 等等,您可以使用我们的云 (SaaS) 服务,因为我们在云服务中直接整合了其中某些功能以及其他商用功能,或者您也可以联系我们讨论可能的就地部署方案。如需了解我们提供的不同身份验证方案,请务必查看身份验证文档

授权

授权和身份验证通常密不可分;Elastic Stack 也不例外。我们拥有一套非常灵活的系统,可用来定义集群和索引的授权规则,能够一直细化到文档字段级别。我们甚至还推出了授权引擎,让您可以在这里构建自己的授权插件。

在过去,这一方面的建议都十分严苛。之前也曾建议过一些方法,即通过 Nginx 等代理编写相当复杂的筛选规则,然后尝试利用筛选后的别名来实现酷似授权的效果。我们强烈建议大家不要采用这些方法进行授权。这些并不是 Security 功能,很可能无法满足您的需求,而且无比脆弱,难以维护。这些解决方案根本不能真正满足您的需求,因为一段时间以来,Elasticsearch API 的数量已有了巨幅增长。有很多方式可访问并查询索引及其中包含的数据。您并无法确保自己已拦截或限制每一个请求。第二个原因和第一个原因有关,因为有如此多的终端需要保护,而且我们还在不停地增加新终端,所以如要对所有这些筛选进行更新,工作量将会极其之大。

幸运的是,您再也无需忧心这一点了。在 6.8 和 7.1 中,有大量授权功能可供使用。内容太多了,在这篇文章中根本讲不完,但 Elastic Stack Security 文档可以很好地为您解释所有这些已有权限。在之后的文章中,我们会对可使用我们的许可模型构建的某些解决方案加以解释。

和身份验证一样,我们有更高级的授权功能,可应用于单独的文档和字段。您可以构建自己的身份验证和授权插件,甚至在集群上记录安全事件。在我们的 Cloud 服务中,您便可以使用这些功能,或者也可以联系我们讨论您的就地部署方案。

通过 VPN 和/或防火墙保护 Elastic Stack 的安全

过去有大量的建议都推荐您通过 VPN 和/或防火墙来保护 Elastic Stack 的安全。大部分此类建议背后的原因都是,没有 TLS 和身份验证,仅使用代理很难确保集群的安全,所以相比于正确配置所有这些不断变化的组件,简单地阻止所有人的访问权限要来得简单一些。

如果您仍希望这么做,即使已经启用了 TLS 和身份验证,这也不失为一个好主意。如能提供多层保护,安全效果会更好。这样做的可取之处是,VPN 和防火墙不再是仅有的一层保护。

受限脚本

很久之前,我们就如何在 Elasticsearch 中限制脚本发表了一篇博文。由于创建了 Painless 脚本语言,现在想破坏集群要难得多了,即使通过恶意脚本也很难做到。但这并非不可能,我们在脚本安全文档中列出了一些最佳实践,讨论了我们在这一主题上的当前立场。再强调一遍,无论何时您都应审查自己的环境,并采取最合理的步骤。由于多层保护的安全效果最好,所以并没有绝对唯一的最佳方案。

隔离

我们曾不止一次提过,可以对您的集群和节点进行隔离以确保安全。这可以包括所有内容,从容器到防火墙,再到 IP 筛选,都囊括在内。

现在这仍是一条很棒的建议,尽量隔离所有内容的确是一个卓越的安全技巧。在过去几年中,我们做了很多工作以便您能无比轻松地进行隔离。您可以使用在 Docker Hub 上发布的容器镜像。您可以选择 Elasticsearch Service,我们会为您完成所有这些复杂工作。而且我们最近才宣布推出官方 Kubernetes Operator,欢迎试用。

对索引进行备份(尤其是 .kibana,因为它很容易改动)

数据备份的重要性丝毫没有减弱。安全性在这一方面的要求并无任何改变,但我们的确需要告诉老手们一些新技巧。

最大的改进是我们可以利用 Kibana Spaces 来限制谁可以编辑特定仪表板。这一功能在 6.8 和 7.1 版本中也已免费提供。之前,只要能访问 Kibana,您很可能便可随心所欲地进行更改。很常见的一种情况是有人会把仪表板弄得一团糟,在某些情况下甚至会误删除全部内容。我们建议您定期备份 .kibana 索引,以便您能在发生错误时迅速恢复。恢复索引可比重新构建所有仪表板快得多。对 .kibana 进行备份仍然很重要,但是由于推出了 Spaces 和授权功能,您应当无需再定期进行恢复了。

Security 功能的另一巨大优势是能够控制谁可以截取快照,谁可以创建索引,以及谁可以编辑数据。如没有 Security 功能,即使是仅应当拥有只读权限的用户,也可能会对数据进行灾难性的更改。启用 Security 功能后,我们可以采取一些步骤来极大程度上预防对重要数据进行意外更改。

现在需要如何做?

本篇博文的目的是就如何确保 Elastic Stack 部署的安全性,重新回顾之前的一些建议。在安全领域,唯一不变的就是变化。即使本篇博文中的建议,之后也会过时或者错误。在 Elastic Stack 中确保安全性是一项颇有压力的工作,因为其提供了大量备选方案供您选择。(这是一项功能,而不是 bug 哦。) 一定不要忘记在论坛上提问,以及阅读我们的博客和文档

如果您希望轻点几下按钮便能确保 Elastic Stack 的安全,我们提供下列选项。我们在 Elasticsearch Service 中,已为所有集群配置 TLS,并且已启用身份验证和授权,同时还默认启用我们的 Enterprise Security 功能。如果不考虑云服务的话,您可以选择 Elastic Cloud Enterprise (ECE) 以便在自己的数据中心体验 Elasticsearch Service 提供的很多相同功能。我们同时还提供 Kubernetes Operator,它可以代您完成很多繁重工作,例如默认为您启用 TLS 并配置身份验证。当然,如果是运行自己 Stack 的 Enterprise 客户,您可以联系我们卓越的支持团队来帮您解决所遇到的任何问题。

敬请关注我们之后发布的全部内容。我们预计未来会发布很多“操作方法”类的文章,甚至还会发布大量的崭新 Security 功能。欢迎使用 Elastic Stack,定能给您带来无限惊喜!