问默认情况下，亚马逊海王星中的匿名身份验证？

EN

这里有一些非常有效的观点，让我通过提供一些上下文来详细介绍它们。

默认情况下，亚马逊海王星似乎使用匿名身份验证。

这是有目的的。Neptune现在支持的查询语言是Gremlin和SPARQL，这两种语言都构建在HTTP/HTTPS之上，没有任何形式的auth ( Gremlin中支持Basic Auth，但这不是客户端在生产中使用的语言。我至少需要某种形式的消息摘要才能称之为安全，但不幸的是，语言规范不包括这个)。由于这些语言是开放的，有许多开放源代码客户端代码存在，它们假定它们处理的是一个未经身份验证的端点。因此，纯粹从采用的角度来看，海王星选择将其请求层默认保持未经身份验证。如果您探索AWS中的其他DB引擎(例如Aurora MySQL)，支持DB引擎确实支持auth作为它的默认姿态。

这并不意味着这样做是正确的，所以我将让Gremlin/SPARQL社区的人评论规范是否应该将身份验证作为默认的姿态。

亚马逊海王星的唯一默认安全选项似乎是网络级别的VPC安全组。

SG提供网络ACL，我们在默认情况下支持TLS1.2(在最新的引擎版本中)，这样也可以加强客户端-> db连接。

该服务声称“高度安全”。在我看来，默认情况下不支持应用程序级身份验证的服务并不是“高度安全的”。

除了上面提到的细节之外，海王星的“高度安全”方面不仅限于客户端-> db连接。您的数据被复制6种方式，并存储在3个AZs中。这涉及到大量的通信，不仅来自DB，还包括后台存储节点。所有这些通信都受到行业标准安全协议的保护。分布式存储的rest加密本身就是一个非常有趣的案例。同样的标准也适用于操作员对机器的访问、审计、快照和恢复等数据安全等。简而言之，我确实同意默认的姿态应该是启用SigV4 (或一些开放标准)，我确实想要确保您确实对我们为什么声称是一个高度安全的DB有所了解，就像AWS提供的任何其他产品一样。

是否有一种不使用复杂的IAM集成身份验证而启用身份验证的方法？

SigV4是大多数AWS服务所支持的标准。我确实同意，如果有一个用户可以直接使用的SDK，就会容易得多。我们为一些客户端(特别是Java和Python)提供了SigV4插件，而且它实际上得到了很好的接受。一定要尝试一下，并分享关于集成中哪些方面似乎是痛苦的反馈，我们将非常乐意来看看。

编辑1:这里的OP讨论是关于客户端和数据库之间的安全性，所以我上面引用的不透明后台数据存储中的安全实践并不真正相关。换句话说，这里的讨论完全围绕着海王星的数据平面API，以及我们是否可以在默认情况下是安全的，而不是选择加入。