本文（以及有关ES的书籍和其他信息源）中的这篇文章都主张将ES置于代理服务之后：
https://dzone.com/articles/securing-your-elasticsearch-cluster-properly
我看到的一个非常常见的错误是，人们说“嘿，Elasticsearch是基于HTTP的REST，让我们直接从我们的智能HTML客户端直接访问它”。好吧，您真的不想这样做。
有一个单页应用程序，需要查询Elastic并获取 显示的JSON？将其通过可以执行的软件立面 请求过滤，审核日志记录，最重要的是- 密码保护您的数据。
如果没有，（a）您确定要绑定到公共IP，并且您 不应该，（b）您冒着对数据进行不必要的更改的风险，（c）和 最坏的情况–您无法控制谁访问哪些数据，而所有数据都是 所有人都看得到。那些现在正在发生的事情 Elasticsearch集群。
此外，请勿公开您的文档和索引结构，或者 将瘦客户机与为其提供数据的数据存储系统耦合。 您的客户端JavaScript确实不应该讲Elastic DSL。
您的客户端应与您的服务器端软件进行通讯， 依次将所有客户端请求转换为Elasticsearch DSL， 执行查询，然后有选择地转换响应 Elasticsearch返回您的客户期望的东西。显然 然后，您的服务器端应用程序可以在以下情况下验证用户登录： 验证和授权其针对 数据，然后才可以访问Elasticsearch。做到任何 否则只会使您面临不必要的风险，而您的数据 贪婪的黑客。
在私有云中运行自己的ES时，我完全同意此处所说的所有内容。但是，在AWS上运行它时通常会做什么？我是整个无服务器领域的新手，最近我遇到了Google Firebase教程视频，人们争辩说要直接从客户端向数据库进行查询。这在AWS中也很常见吗？
答案 0 :(得分：0)
在与AWS一起工作了一段时间之后，我不得不清除一个误解。 AWS不等于无服务器。他们提供了许多云解决方案，而FAAS /功能即服务（AWS Lambda）只是其中之一。
并且无论您是使用FAAS，IAAS还是PAAS，您都可能总是有用例，您只想将Elasticsearch接口的一部分暴露给外界。如果您获得了软件即服务，例如ElasticCloud（由Elastic公司在AWS上托管）或使用X-PACK许可证部署了自己的Elastic Cluster，则可以考虑使用XPACK安全/索引限制功能。但是，这仅涉及安全性，而不涉及简单性。从事前端工作的人员需要了解索引的内部/映射以及如何在ES中进行（有效的）查询。
我什至不确定X-PACK是否可以防止繁重的计算查询（例如脚本查询，聚合和深度分页），因此，如果将API暴露给整个Internet，这可能不够安全。
现在，firebase视频中的人所做的事情（在客户端形成查询）非常好，并且使应用程序保持灵活，但是现在可能适合每种用例。例如，如果您想为拥有自己客户端的客户公开公共API。