当社ウェブサイトのAWSとの統合サービス

Question

私たちはSAASのウェブサイトを構築しています。一部の機能では、ユーザーのAWSサービスを当社のWebサイトから操作する必要があります。 ユーザーはこれらの機能を選択してもしなくてもかまいませんが、望むのであれば、特定の権限をGoogleに与えることができます。当社のウェブサイトには、独自の認証メカニズムを備えた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に格納することは、1つのオプションおよび/またはDynamoDBです。

2 - フェデレーションの 役割は、誰かが外部AWS（SAML/SSO）の外部IDプロバイダから資格情報を使用してAWSにログインしたときのためのものです。あなたはこれを必要としません。顧客はあなたのAWSアカウントにログインしておらず、ログインしていません。必要な役割はオプションです。顧客は役割を作成し、その役割に権限を付与してから、その役割をユーザーに付与し、そのユーザーに付与することができます。また、ユーザーを作成してユーザーに直接アクセス許可を設定することもできますが、役割のアプローチはより良い方法です。 本当に必要なのは、AWSリソースにアクセスする必要があり、何をしたいのかです。そこから、そのリソースに必要な権限のリストがあります。 ユーザーの作成方法、 役割の作成、必要な権限 の添付、使用するためのAPIキーの生成について、お客様に指示する必要があります。

3 - 役割は必須ではありません。オプションです。必要なのは、顧客が役割を作成し、アクセスする必要のあるAWSサービスごとに権限を与え、アクセスする必要があるAWSサービスだけに権限を与え、API呼び出しで使用するための鍵を生成することです。しかし、全体的にユーザーエクスペリエンスは同じです。ターゲットとする顧客が通常のAWS顧客であれば、これは簡単ですが、通常のAWSの顧客はアカウントを管理するために他の人が必要になるとは思っていません。

あなたが最もクリーンなアプローチをとっている場合、役割の割り当ては避けられません。以下

更新

参照JamieStarkeコメント。顧客にとってより簡単なアプローチで、より安全なのは、AWSアカウントにロールを割り当ててキー交換が不要なためです。コアインフラストラクチャとしてAWSを使用していない場合は、アカウントを開いて引き続きそのアカウントにロールを割り当てることができます。どちらのアプローチでも、あなたと顧客との間でクレデンシャルを交換する必要はありません。

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