从我们的网站，服务与AWS集成

Question

我们正在建立一个SAAS网站。某些功能要求我们的用户的AWS服务通过我们的网站进行操作。 用户可能会也可能不会选择这些功能，但如果他们愿意，他们应该能够向我们授予某些权限。我们的网站有https和我们自己的身份验证机制。

问题：

1）在这些场景中进行AWS集成的行业最佳实践是什么？

2）我们在aws.amazon.com上发布了这些文章。我们何时使用“角色为IAM用户”方法与“角色为身份联合选项”？

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

3）在我们的产品上使用AWS服务之前，使用AWS“授予IAM角色”的步骤被我们视为用户体验缺陷。这是不可避免的吗？

谢谢， 斯利拉姆

Answer 1

1 - 仅请求您的用户访问您操作SAAS所需的内容。它可以降低您遭受破坏和客户受到影响的风险。例如，如果您只需要只读访问EC2，则只请求只读访问。

要运营客户的AWS账户，您需要的不仅仅是创建用户和角色。要进行API调用，客户必须生成访问密钥并分配密钥供您使用。这就是您的网站将代表他们与AWS进行通信的内容。这基本上只是一个私钥，所以在安全性最佳实践方面，您需要像处理任何非常敏感的资源一样对待它。在s3中存储这样的凭证是一个选项和/或DynamoDB。

2 - 联合的角色是指某人使用来自AWS外部的外部身份提供程序（SAML / SSO）的凭据登录AWS。你不需要这个;客户没有登录您的AWS账户而您没有登录他们的账户。您需要的角色是可选的。您的客户可以创建角色，为其附加权限，然后将角色附加到用户并将该用户提供给您。他们也可以创建用户并直接将权限放在用户身上，但角色方法是一种更好的做法。您真正需要了解的是您需要访问的AWS资源以及您想要的内容和他们一起做。从中可以获得该资源所需的权限列表。您必须向客户发送有关如何创建用户，创建角色，附加所需权限，然后生成供您使用的API密钥的说明。 < / p>

3 - 角色不是必需的，是可选的。所需要的是您的客户创建一个角色，为您需要访问的每个AWS服务授予权限，并且只为您需要访问的服务授予权限，然后生成密钥供您在API调用中使用。但整体而言，用户体验仍然相同。如果您的目标客户是常规AWS客户，这对他们来说很容易，但我怀疑常规AWS客户是否需要其他人来管理他们的帐户。

如果采取最干净的方法，角色分配是不可避免的。

<强>更新

请参阅下面的JamieStarke评论。为您的客户提供一种更简单的方法，更安全的方法是让他们为您的AWS账户分配一个角色，这样就不需要进行密钥交换。如果您不使用AWS作为您的核心基础架构，您可以打开一个帐户，并让他们将角色分配给该帐户。在任何一种方法中，都不需要与您和客户交换凭证。

http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html