从移动应用程序使用AWS（特别是S3）的首选方式是什么？

Question

直接在应用代码中添加AWS访问密钥和密钥肯定不是一个好方法，主要是因为应用程序驻留在用户设备上（与服务器端代码不同），并且可以进行逆向工程以获取凭据，这可以然后被误用。

虽然我到处都能找到这些信息，但无法找到解决此问题的明确方法。我有什么选择？我读到了临时凭证的令牌自动售货机架构，但我不相信它更好。如果我可以对密钥进行反向工程，那么我可以对请求临时凭证的代码进行反向工程。一旦我有一套临时凭证来访问S3，我就像拥有密钥一样好。我可以一次又一次地请求临时凭证，即使它们很快到期。总而言之，如果应用程序可以执行某些操作，我可以像恶意用户一样执行操作。如果有的话，TVM可以更好地管理（轮换凭证，并在发生违规时更改密钥等）。请注意，我们可以对密钥设置相同的访问限制，因为我们计划在TVM临时凭证的情况下执行此操作。

此外，如果亚马逊不希望人们直接在应用中使用密钥，为什么不在他们的SDK中阻止它，并强制执行TVM或正确的解决方案。如果你要留下一条路，人们就会使用它。我读了几篇这样的文章，并想知道为什么？：http://blog.rajbala.com/post/81038397871/amazon-is-downloading-apps-from-google-play-and

我主要来自网络背景，因此我对此的理解可能有点缺陷。请帮助我理解这是否更好，以及是否有一个完美的（或可能是好的）解决方案可用于此问题。

PS：是否有TVM的rails实现？

Answer 1

在应用程序代码中嵌入S3密钥非常危险。任何人都可以轻松地从您的应用程序代码中获取该密钥（无需逆向工程或高技能集），即使加密存储它仍然会受到损害，只是有人需要更加努力（取决于您如何加密）。

我希望您了解使用临时凭证访问Amazon（S3等）资源（主要是安全性+其他一些没有应用更新等）的优势。我认为你对从TVM获取临时凭证的过程更加困惑，以及如何比在代码中嵌入密钥更安全。

每个使用TVM的客户首先需要注册您托管的TVM服务器实施。 App（使用TVM客户端）和TVM服务器之间的通信是通过SSL进行的。

首先，app通过提供UUID和密钥向TVM注册。请注意，密钥未嵌入到应用程序代码中（我认为是导致混淆的主要原因），但是在注册时随机生成（使用SecRandomCopyBytes生成加密安全随机字节数组）（和十六进制编码）。

设备成功注册TVM后，客户端TVM将生成的UDID和密钥存储在iOS中的Keychain和Android中的Shared Preferences中。 iOS中的钥匙串是iOS提供的安全（加密）商店信息（主要是密钥，密码等）的共享存储。

注册和UDID /密钥存储后，App可以通过发送UDID，加密签名和时间戳从TVM获取令牌。加密签名是使用密钥从时间戳生成的HMAC hash。 TVM可以使用UDID查找密钥并使用它来验证签名。然后，TVM通过发回临时凭证来响应，这些凭证使用密钥加密（使用AES）。应用程序使用密钥解密临时凭证，然后可以使用它们访问授权临时凭证的任何AWS服务。最终，将达到这些临时凭证的到期时间，此时应用程序可以获得新的临时凭证（如果需要）。

Answer 2

我不确定签名网址与TVM有何关联，因为我不理解100％的概念，但签名网址确实为我解决了问题。我需要一种机制，可以提供Web应用程序和移动应用程序数据，而不会滥用凭据。将密钥放在代码中确实是一个非常糟糕的主意，因为它可能会为公司带来巨额费用。

经过3天的广泛研究，我发现了一个简单的，似乎是一个可靠且相对安全的解决方案：签名网址。我们的想法是，一个非常轻量级的后端可以生成一个临时URL，允许用户访问特定资源 有限时间。所以这个想法很简单：

• 用户向我们的后端询问他想要特定资源的Rest调用

• 后端已获得AWS S3授权

• 后端为用户生成临时URL并将其发送到Rest响应中

• 用户使用该URL直接从AWS获取数据

可以找到即插即用的Python实现here并稍加修改，我必须使用here。

当然还有一件事要弄清楚，在我们知道我们可以授予用户URL之前，我们如何授权用户，而这又是另一双鞋。

Answer 3

理想情况下，您应该使用Cognito Identity来实现此目标以及相应的政策。它应与iOS和Android SDK中的S3TransferUtility和S3TransferManager一起使用。这样也可以进行后台上传和下载。 Cognito出版用于访问AWS资源的临时凭证，并且是免费的。此外，如果您想要安全访问，可以使用UserPools或Google，Facebook等提供商进行联合。

谢谢， 罗汉