Sparql Amazon Neptune中默认的匿名身份验证？

我正在学习亚马逊海王星，并注意到：

IAM身份验证要求API调用使用AWS签名v4，这增加了应用程序的复杂性

默认情况下，Amazon Neptune似乎使用匿名身份验证，因为我不必提供任何API密钥、用户名/密码组合或用于身份验证的证书。此外，AWS提供的认证不包括任何认证详细信息

Amazon Neptune的默认安全选项似乎只有网络级别

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

Neptune为您的数据库提供了多个级别的安全性。安全功能包括使用Amazon VPC进行网络隔离，以及使用通过AWS密钥管理服务（AWS KMS）创建和控制的密钥进行静态加密。在加密的Neptune实例上，底层存储中的数据将被加密，同一集群中的自动备份、快照和副本也是如此

---

问题：为什么Amazon Neptune在默认情况下使用不安全的配置，并且有没有一种方法可以在不使用复杂的IAM集成身份验证的情况下启用身份验证？

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

默认情况下，Amazon Neptune似乎使用匿名身份验证

这是故意的，是有原因的。Neptune现在支持的查询语言是Gremlin和SPARQL，它们都构建在HTTP/HTTPS之上，没有任何身份验证（Gremlin支持基本身份验证，但客户机在生产中无论如何都不支持基本身份验证。我至少需要某种形式的消息摘要身份验证来称其为安全身份验证，但不幸的是，语言规范不包括此）。由于这些语言是开放的，因此存在大量开源客户端代码，这些代码假定它们正在处理未经验证的端点。因此，纯粹从采用的角度来看，Neptune选择在默认情况下保持其请求层未经验证。如果您探索AWS中的其他DB引擎（例如Aurora MySQL），后台数据库引擎不支持将身份验证作为其默认姿态

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

Amazon Neptune的唯一默认安全选项似乎是网络级VPC安全组

SG提供网络ACL，我们默认支持TLS 1.2（从最新的引擎版本开始），这样也可以加强客户端->数据库连接

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

除了上面提到的细节外，“高度安全”Neptune的特性不仅限于客户端->数据库连接。您的数据以6种方式复制并存储在3个AZ中。这涉及大量通信，不仅来自数据库，还包括备份存储节点。所有这些通信都由行业标准安全协议保护。分布式存储的静态加密是这本身就是一个非常有趣的案例研究。同样的标准适用于操作员对机器的访问、审计、数据安全（快照和恢复等）。简言之，我同意默认姿势应该是SigV4（或一些开放标准）启用了身份验证，我确实希望您能够弄清楚为什么我们声称自己是一个高度安全的数据库，就像AWS提供的任何其他产品一样

有没有一种方法可以在不使用复杂的IAM集成身份验证的情况下启用身份验证

SigV4是大多数AWS服务都支持的标准。我同意如果有一个客户可以直接使用的SDK，它会容易得多。我们为一些客户端（特别是Java和Python）提供了SigV4插件事实上，它有一个相当好的理解。一定要尝试一下，并分享关于整合中哪些方面看起来很痛苦的反馈，我们会非常乐意看一看

---

编辑1：这里的OP讨论是关于客户端和数据库之间的安全性，因此我上面引用的不透明备份数据存储中的安全实践并不真正相关。换句话说，这里的讨论完全围绕Neptune的数据平面API，以及我们是否可以默认安全，而不是选择加入。

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

默认情况下，Amazon Neptune似乎使用匿名身份验证

Neptune现在支持的查询语言是Gremlin和SPARQL，这两种语言都构建在HTTP/HTTPS之上，没有任何身份验证（Gremlin支持基本身份验证，但客户机在生产中无论如何都不支持基本身份验证。我至少需要某种形式的消息摘要身份验证来称其为安全身份验证，但不幸的是，语言规范不包括此）。由于这些语言是开放的，因此存在大量开源客户端代码，这些代码假定它们正在处理未经验证的端点。因此，纯粹从采用的角度来看，Neptune选择在默认情况下保持其请求层未经验证。如果您探索AWS中的其他DB引擎（例如Aurora MySQL），后台数据库引擎不支持将身份验证作为其默认姿态

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