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

如何解决Amazon Neptune 中的默认匿名身份验证？

我正在了解 Amazon Neptune，并注意到：

1. IAM authentication is not enabled by default
2. IAM 身份验证需要 AWS Signature v4 才能进行 API 调用，这会增加应用程序的复杂性

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

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

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

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

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

解决方法

您在其中提出了一些非常有效的观点，所以让我通过提供一些背景来详细介绍它们。

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

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

这并不意味着这是正确的做法，因此我将让 Gremlin/SPARQL 社区的某个人评论规范是否应将身份验证强制为默认状态。

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

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

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

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

有没有办法在不使用复杂的 IAM 集成身份验证的情况下启用身份验证？

SigV4 是大多数 AWS 服务支持的标准。我同意如果有一个客户可以直接使用的 SDK 会容易得多。我们确实为一些客户端（尤其是 Java 和 Python）分发了 SigV4 插件，它实际上有很好的使用率。一定要尝试一下，并分享关于集成中哪些领域似乎很痛苦的反馈，我们非常乐意看一看。

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