把ElasticSearch放到AWS的代理后面？

Question

本文（以及有关ES的书籍和其他信息来源）主张将ES置于代理服务之后：

https://dzone.com/articles/securing-your-elasticsearch-cluster-applement

否则，(a)您肯定会绑定到一个公共IP，而您不应该这样做；(b)您将冒着对您的数据进行不希望的更改的风险；(c)最坏的情况是，您无法控制谁访问什么，您的所有数据都是可以看到的。这些弹性搜索集群现在发生了什么。

此外，不要公开文档和索引结构，或者将瘦客户机与提供it数据的数据存储系统耦合。客户端javascript不应该使用弹性DSL。

您的客户端应该与服务器端软件通信，服务器端软件会将所有客户端请求转换为Elasticsearch DSL，执行查询，然后有选择地将Elasticsearch的响应转换回您的客户端所期望的内容。显然，服务器端应用程序可以在必要时验证用户登录，以便在对Elasticsearch进行任何访问之前对其针对数据的操作进行身份验证和授权。以任何其他方式进行操作只会使您面临不必要的风险，并使您的数据暴露在贪婪的黑客面前。

Answer 1

在与AWS工作了一段时间之后，我必须澄清一个误会。AWS不等于无服务器。他们提供了许多云解决方案，FaaS/Function-as-a-Service（AWS Lambda）只是其中之一。

无论您使用的是FAAS、IAAS还是PAAS，您可能总是有这样的用例：您只想向外部世界公开ElasticSearch接口的一个片段。如果您获得了软件即服务，例如ElasticCloud（由Elastic the company托管在AWS上），或者使用X-PACK许可证部署自己的弹性集群，那么您可以考虑使用XPACK安全/索引限制特性。不过，这只照顾到了安全性，而不是简单性。在前端工作的人员需要了解索引的内部结构/映射以及如何在ES中进行（有效的）查询。

我甚至不确定X-PACK是否可以防止大量的计算查询（如脚本查询、聚合和深度分页），所以如果您将API公开给整个Internet,这可能不够安全。

现在firebase视频中的人员所做的（在客户端形成查询）是很好的，并且保持了应用程序的灵活性，但是它现在可能适合于每一个用例。例如，如果您希望用自己的客户机为客户公开一个公共API。