Amazon AWS 访问密钥的安全性如何？
我想为我的 s3 存储桶提供带有到期日期的预签名 URL。 .net sdk 很好地生成了这些 url，但是看着它们让我有点担心：
https://s3.amazonaws.com/upload_youtipit/myfile?AWSAccessKeyId=**MYACCESSKEY**&Expires=1317924047&response-content-disposition=attachment;filename=feedback.jpg&response-content-type=image/jpeg&Signature=podKJSrNeFel6%2B0aOneb342H5GA%3D
为什么需要将我的（公共）AWSAccessKey 放在 Url 中？难道这件事不应该保密一点吗？我知道这不是秘密，但我仍然不愿意在公开场合公开它。
拥有我的公钥的人能够猜测/暴力破解我的私钥的可能性有多大？
I want to offer presigned urls to my s3 buckets with an expiry date.
The .net sdk nicely generates these urls, but looking at them makes me worry a little:
https://s3.amazonaws.com/upload_youtipit/myfile?AWSAccessKeyId=**MYACCESSKEY**&Expires=1317924047&response-content-disposition=attachment;filename=feedback.jpg&response-content-type=image/jpeg&Signature=podKJSrNeFel6%2B0aOneb342H5GA%3D
Why does it need to put my (public) AWSAccessKey in the Url? Shouldn't this be kept a bit more confidential? I know its not the secret, but I still don't feel comfortable exposing it in public..
How likely is it that, somebody who has my public key, can guess/bruteforce my private key?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
访问密钥 ID 不是秘密，不需要保护。
事实上，如果您希望随机的陌生人访问 S3 对象，您可以向他们提供过期 URL。他们可以看到该 URL 中的访问密钥，但不能用它执行任何未经您授权的操作。
参考：http://docs.amazonwebservices.com/AWSSecurityCredentials/1.0/AboutAWSCredentials.html #AccessKeys
The Access Key ID is not a secret and does not need protecting.
In fact, you can give expiring URLs to random strangers if you want them to access an S3 object. They can see the access key in that URL, but can't do anything with it that you have not authorized.
reference: http://docs.amazonwebservices.com/AWSSecurityCredentials/1.0/AboutAWSCredentials.html#AccessKeys
我有点同意接受的答案，但是有一种简单的方法可以做你想做的事。
您需要使用 Amazon IAM 创建一个只能读取文件的用户（这并不重要，但他们至少需要只读您正在处理的存储桶）。然后使用该用户的 AWS ID 和密钥生成下载链接。
这不会打开您的整个存储桶，因为要查看整个存储桶，该人需要此 IAM“读取器”用户的 AWSID 以及他们的密钥。您仍然需要构建有时间限制的 URL。
您可以使用 IAM 控制台在几分钟内创建这样的用户。您只有一次机会获得密钥 - 在您创建用户时（或者如果您轮换他的密钥）。
应该可以做到这一点。此 AWSID 无权访问任何内容，并且未与您关联。
一般来说，亚马逊现在建议您不要将主 AWSID 用于“任何用途”。您在 IAM 中创建具有权限的用户，然后使用这些代码。这提供了很大的安全灵活性。您可以通过 IAM 控制台中的简单操作来关闭只读用户。
I kind of agree with the accepted answer, but there is an easy way to do what you want.
You need to use Amazon IAM to create a user that can only read files (it does not really matter, but they at least need read only to the bucket that you are dealing with). Then use THAT users AWS ID and secret to generate a download link.
This does not open up your whole bucket, as to see the whole bucket the person needs the AWSID of this IAM 'reader' user, plus their secret key. You still need to construct time limited URLs.
You can use the IAM console to create a user like that in a few mins. You only get one chance to get the secret key - at the time you make the user (or if you rotate his keys).
That should do it. This AWSID has no access to anything, and is not linked to you.
In general Amazon now recommends that your primary AWSID is not used 'for anything'. You create users with permissions in IAM, then use those codes. This allows for a lot of security flexibility. You can turn off your read only user with a simple action in the IAM console.
你的私钥是一些未知参数的单向计算，它甚至可能不使用公钥本身作为算法的一部分。知道您的 AWSAccessKeyId 应该不会影响暴力破解您的私钥的复杂性。
https 确保有人可以告诉您的连接（如果他们正在嗅探网络流量）的唯一信息是它位于您的 IP 和端口 443 上 s3.amazonaws.com 的 IP 之间。即使您连接到 amazon 的事实也会有从分配给它们的已知 IP 地址范围（这可能是众所周知的）推断出，
在地址栏中获取 AWSAccessKeyId 的唯一方法是在屏幕上实际看到它，安装一些您计算机上的键盘记录器或木马或 MIM（中间人）亚马逊的 SSL 证书，即使有人可以访问所需的上游网络节点，这也是极其困难的。
莱昂
your private key is a one-way computation of some unknown parameters, it may not even use the public key itself as part of the algorithm. knowing your AWSAccessKeyId should have no effect on the complexity of brute-forcing your private key whatsoever.
https ensures the only thing someone can tell about your connection (if they are sniffing network traffic) is that it's between your IP and the IP of s3.amazonaws.com on port 443. even the fact that you're connecting to amazon would have to be deduced from known ip-address ranges assigned to them (which is probably well-known anyhow)
the only way to get at your AWSAccessKeyId in the address bar is to physically see it on your screen, installing some key-logger or trojan on your computer or MIM (man in the middle-ing) amazon's SSL certificate, which is extremely hard even if someone has access to the needed upstream network nodes.
leon
如果您担心更高的安全性，可以使用 AWS
Security Token Service(AWS STS)。临时安全凭证的工作方式与 IAM 用户可以使用的长期访问密钥凭证几乎相同，但存在以下差异：
顾名思义，临时安全凭证是短期的。它们可以配置为持续几分钟到几个小时。凭证过期后，AWS 不再识别它们，也不再允许通过它们发出的 API 请求进行任何类型的访问。
临时安全凭证不会随用户一起存储，而是动态生成并在用户请求时提供给用户。当临时安全凭证过期（甚至之前）时，用户可以请求新凭证，只要请求新凭证的用户仍然有权这样做。
参考：https://docs.aws.amazon.com/IAM/最新/UserGuide/id_credentials_temp.html
You can use AWS
Security Token Service(AWS STS) if you concern of more security.Temporary security credentials work almost identically to the long-term access key credentials that your IAM users can use, with the following differences:
Temporary security credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, AWS no longer recognizes them or allows any kind of access from API requests made with them.
Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested. When (or even before) the temporary security credentials expire, the user can request new credentials, as long as the user requesting them still has permissions to do so.
Ref: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html