使用 Amazon Web Services 保守秘密
我正在我的个人项目中尝试使用亚马逊网络服务。我已经获取了他们的 AWS SDK for .NET 并且正在使用它，但我有点困惑。
对 Web 服务（在本例中为 SimpleDB，尽管我认为这对问题来说并不重要）的访问是通过私钥/公钥对授权的。
用于创建客户端对象的 AWS SDK for .NET API 需要私钥：
AWSClientFactory.CreateAmazonSimpleDBClient(publicKey, privateKey);这是一个客户端应用程序，因此代码将完全在客户端上运行。
建议客户端需要访问我的私钥才能访问 SimpleDB。但亚马逊反复强调，我的私钥不能离开我的控制。
这对我来说没有意义，所以我想我一定错过了一些东西。
对于亚马逊 Web 服务来说，客户端应用程序对于使用 AWS SDK for .NET 而言是否是错误的模型，或者我是否遗漏了一些使客户端应用程序完全合理的东西？有没有一种好的方法可以解决这个问题，而无需创建我自己的代理服务来验证客户端并将其请求转发到 SimpleDB？
I'm playing around with using amazon web services in my personal project. I've grabbed their AWS SDK for .NET and I'm using that, but I'm a little confused.
Access to the web service (in this case, SimpleDB, though I don't think that's really material to the question) is authorized via a private/public key pair.
The AWS SDK for .NET API used to create a client object requires the private key:
AWSClientFactory.CreateAmazonSimpleDBClient(publicKey, privateKey);This is a client application, so the code would be running entirely on the client.
Suggesting that the client would need to have access to my private key to have access to the SimpleDB. But amazon repeatedly and emphatically states that my private key must not leave my control.
This doesn't make sense to me, so I figure I must be missing something.
Is a client-side application the wrong model for the amazon web services in general, for using their AWS SDK for .NET, or am I missing something that makes a client application perfectly reasonable? Is there a good way to work around this without creating a proxy service of my own that would authenticate clients and forward their requests to the SimpleDB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不需要实现面向远程 (AWS) 服务的代理。只需实现一个简单、小型、经过身份验证的服务，该服务会向客户端返回联系 AWS 时使用的 URL 和标头。您的经过身份验证的 Web 服务会保留 AWS 的秘密，并且仅向客户端提供签名的请求 URL 和标头。客户端，然后使用返回的信息进行实际的工作调用。
这样，您就可以避免 AWS 调用期间必须通过您自己的服务器的开销，从而节省延迟、带宽、服务器上的套接字占用、故障处理复杂性等。您只需预先为客户端进行轻量级的处理即可获得正确的指示。
You don't need to implement a proxy that fronts the remote (AWS) service. Just implement a simple, small, authenticated service which returns to the client the URL and headers to use when contacting AWS. Your authenticated webservice keeps the AWS secret, and only provides the signed request URL and headers to the client, which then goes and makes the actual work call using that returned information.
This way, you avoid the overhead during the AWS call of having to go through your own servers, saving latency, bandwidth, tied up sockets on your server, failure handling complexity, etc. You just take a lightweight hit up front for the client to get the proper instructions.