Amazon Neptune 中默认的匿名身份验证？
Anonymous Authentication by default in Amazon Neptune?
我正在了解 Amazon Neptune，并注意到：
- IAM authentication is not enabled by default
- IAM 身份验证需要 AWS Signature v4 进行 API 调用，这会增加应用程序的复杂性
默认情况下，Amazon Neptune 似乎使用匿名身份验证，因为我不必提供任何 API 密钥、用户名/密码组合或身份验证证书。此外，AWS 提供的 code sample 不包含任何身份验证详细信息。
似乎 Amazon Neptune 的唯一默认安全选项是网络级别 VPC Security Groups。
根据 What is Neptune? documentation，该服务声称“高度安全”。在我看来，默认情况下不支持应用程序级身份验证的服务并不“高度安全”。
Neptune provides multiple levels of security for your database. Security features include network isolation using Amazon VPC, and encryption at rest using keys that you create and control through AWS Key Management Service (AWS KMS). On an encrypted Neptune instance, data in the underlying storage is encrypted, as are the automated backups, snapshots, and replicas in the same cluster.
问题：为什么 Amazon Neptune 默认使用不安全的配置，有没有办法启用身份验证而不 使用复杂的IAM 集成身份验证？
你提出了一些非常有效的观点，所以让我通过提供一些上下文来详细介绍它们。
By default, it seems that Amazon Neptune uses anonymous authentication..
这是有意为之的。 Neptune 现在支持的查询语言是 Gremlin 和 SPARQL，它们都建立在 HTTP/HTTPS 之上，没有任何类型的身份验证（Gremlin 支持基本身份验证，但这不是客户在生产中使用的东西） .我至少需要某种形式的消息摘要授权才能称其为安全的，但不幸的是，语言规范不包括此）。由于这些语言是开放的，因此存在许多假设它们正在处理未经身份验证的端点的开源客户端代码。因此，纯粹从采用的角度来看，Neptune 选择默认保持其请求层未经身份验证。如果您探索 AWS 中的其他数据库引擎（例如 Aurora MySQL），支持的数据库引擎确实支持 auth 作为其默认状态。
这并不意味着这样做是正确的，所以我会让 Gremlin/SPARQL 社区的人评论规范是否应该将身份验证作为默认姿势。
It appears that the only default security options for Amazon Neptune are network-level VPC Security Groups.
SG 提供网络 ACL，我们默认支持 TLS 1.2（从最新的引擎版本开始），因此也加强了您的客户端 -> 数据库连接。
The service claims to be "highly secure." In my opinion, a service that does not support application-level authentication by default, is not "highly secure."
除了上面提到的细节之外，Neptune 的“高度安全”方面不仅限于客户端 -> 数据库连接。您的数据以 6 种方式复制并存储在 3 个可用区中。这涉及大量通信，不仅来自数据库，还涉及后备存储节点。所有这些通信都受到行业标准安全协议的保护。分布式存储的静态加密本身就是一个非常有趣的案例研究。相同的标准适用于操作员对机器的访问、审计、快照和恢复等数据安全等。简而言之，我同意默认状态应该启用 SigV4（或某些开放标准）身份验证，我确实想确保您确实清楚为什么我们声称自己是高度安全的数据库，就像 AWS 提供的任何其他产品一样。
Is there a way to enable authentication without using the complicated IAM integrated authentication?
SigV4 是大多数 AWS 服务都支持的标准。我确实同意，如果有一个客户可以直接使用的 SDK，事情会容易得多。我们确实为一些客户（尤其是 Java 和 Python）提供了 SigV4 插件，它实际上有一个很好的吸收。一定要尝试一下，并分享关于集成中哪些方面看起来很痛苦的反馈，我们非常乐意看一看。
编辑 1：这里的 OP 讨论是围绕客户端和数据库之间的安全性进行的，因此我在上面引用的不透明后备数据存储中的安全实践并不真正相关。换句话说，这里的讨论完全围绕 Neptune 的数据平面 API 以及我们是否可以默认安全，而不是选择加入。
我正在了解 Amazon Neptune，并注意到：
- IAM authentication is not enabled by default
- IAM 身份验证需要 AWS Signature v4 进行 API 调用，这会增加应用程序的复杂性
默认情况下，Amazon Neptune 似乎使用匿名身份验证，因为我不必提供任何 API 密钥、用户名/密码组合或身份验证证书。此外，AWS 提供的 code sample 不包含任何身份验证详细信息。
似乎 Amazon Neptune 的唯一默认安全选项是网络级别 VPC Security Groups。
根据 What is Neptune? documentation，该服务声称“高度安全”。在我看来，默认情况下不支持应用程序级身份验证的服务并不“高度安全”。
Neptune provides multiple levels of security for your database. Security features include network isolation using Amazon VPC, and encryption at rest using keys that you create and control through AWS Key Management Service (AWS KMS). On an encrypted Neptune instance, data in the underlying storage is encrypted, as are the automated backups, snapshots, and replicas in the same cluster.
问题：为什么 Amazon Neptune 默认使用不安全的配置，有没有办法启用身份验证而不 使用复杂的IAM 集成身份验证？
你提出了一些非常有效的观点，所以让我通过提供一些上下文来详细介绍它们。
By default, it seems that Amazon Neptune uses anonymous authentication..
这是有意为之的。 Neptune 现在支持的查询语言是 Gremlin 和 SPARQL，它们都建立在 HTTP/HTTPS 之上，没有任何类型的身份验证（Gremlin 支持基本身份验证，但这不是客户在生产中使用的东西） .我至少需要某种形式的消息摘要授权才能称其为安全的，但不幸的是，语言规范不包括此）。由于这些语言是开放的，因此存在许多假设它们正在处理未经身份验证的端点的开源客户端代码。因此，纯粹从采用的角度来看，Neptune 选择默认保持其请求层未经身份验证。如果您探索 AWS 中的其他数据库引擎（例如 Aurora MySQL），支持的数据库引擎确实支持 auth 作为其默认状态。
这并不意味着这样做是正确的，所以我会让 Gremlin/SPARQL 社区的人评论规范是否应该将身份验证作为默认姿势。
It appears that the only default security options for Amazon Neptune are network-level VPC Security Groups.
SG 提供网络 ACL，我们默认支持 TLS 1.2（从最新的引擎版本开始），因此也加强了您的客户端 -> 数据库连接。
The service claims to be "highly secure." In my opinion, a service that does not support application-level authentication by default, is not "highly secure."
除了上面提到的细节之外，Neptune 的“高度安全”方面不仅限于客户端 -> 数据库连接。您的数据以 6 种方式复制并存储在 3 个可用区中。这涉及大量通信，不仅来自数据库，还涉及后备存储节点。所有这些通信都受到行业标准安全协议的保护。分布式存储的静态加密本身就是一个非常有趣的案例研究。相同的标准适用于操作员对机器的访问、审计、快照和恢复等数据安全等。简而言之，我同意默认状态应该启用 SigV4（或某些开放标准）身份验证，我确实想确保您确实清楚为什么我们声称自己是高度安全的数据库，就像 AWS 提供的任何其他产品一样。
Is there a way to enable authentication without using the complicated IAM integrated authentication?
SigV4 是大多数 AWS 服务都支持的标准。我确实同意，如果有一个客户可以直接使用的 SDK，事情会容易得多。我们确实为一些客户（尤其是 Java 和 Python）提供了 SigV4 插件，它实际上有一个很好的吸收。一定要尝试一下，并分享关于集成中哪些方面看起来很痛苦的反馈，我们非常乐意看一看。
编辑 1：这里的 OP 讨论是围绕客户端和数据库之间的安全性进行的，因此我在上面引用的不透明后备数据存储中的安全实践并不真正相关。换句话说，这里的讨论完全围绕 Neptune 的数据平面 API 以及我们是否可以默认安全，而不是选择加入。