Amazon Cognito アイデンティティプールに対するセキュリティのベストプラクティス
Amazon Cognito アイデンティティプールは、アプリケーションの一時的な AWS 認証情報を提供します。AWS アカウント には、アプリケーションユーザーが必要とするリソースと、プライベートバックエンドリソースの両方が含まれることがよくあります。AWS 認証情報を構成する IAM ロールとポリシーは、これらのリソースへのアクセスを許可できます。
アイデンティティプール設定の主なベストプラクティスは、過剰な権限や意図しない権限なしでアプリケーションがジョブを完了できるようにすることです。セキュリティの設定ミスを防ぐために、本番環境にリリースする各アプリケーションの起動前に、これらの推奨事項を確認してください。
IAM 設定のベストプラクティス
ゲストまたは認証されたユーザーが、アイデンティティプールの認証情報を必要とするセッションをアプリケーションで開始すると、アプリケーションは IAM ロールの一時的な AWS 認証情報を取得します。認証情報は、デフォルトのロールのもの、アイデンティティプール設定のルールによって選択されたロールのもの、またはアプリケーションによって選択されたカスタムロールのものである場合があります。各ロールに割り当てられたアクセス許可により、ユーザーは AWS リソースにアクセスできます。
IAM での一般的なベストプラクティスの詳細については、「AWS Identity and Access Management ユーザーガイド」の「IAM でのセキュリティのベストプラクティス」を参照してください。
IAM ロールで信頼ポリシー条件を使用する
IAM では、アイデンティティプールのロールに少なくとも 1 つの信頼ポリシー条件が必要です。この条件では、例えば、認証されたユーザーのみにロールのスコープを設定することができます。また、AWS STS では、クロスアカウントの基本認証リクエストには cognito-identity.amazonaws.com:aud
と cognito-identity.amazonaws.com:amr
という 2 つの特定の条件が必要です。ベストプラクティスとしては、アイデンティティプールサービスプリンシパル cognito-identity.amazonaws.com
を信頼するすべての IAM ロールにこの両方の条件を適用します。
-
cognito-identity.amazonaws.com:aud
: アイデンティティプールトークンの aud クレームは、信頼されたアイデンティティプール ID と一致する必要があります。 -
cognito-identity.amazonaws.com:amr
: アイデンティティプールトークンの amr クレームは、認証されているもの、または認証されていないものである必要があります。この条件では、認証されていないゲストのみに、または認証されているユーザーのみにロールへのアクセスを予約できます。この条件の値をさらに絞り込んで、graph.facebook.com
などの特定のプロバイダーのユーザーにロールを制限できます。
次のロール信頼ポリシーの例では、以下の条件下でロールへのアクセスを許可します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Federated": "cognito-identity.amazonaws.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "us-east-1:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "authenticated" } } } ] }
アイデンティティプールに関連する要素
-
"Federated": "cognito-identity.amazonaws.com"
: ユーザーは、アイデンティティプールに帰属している必要があります。 -
"cognito-identity.amazonaws.com:aud": "us-east-1:a1b2c3d4-5678-90ab-cdef-example11111"
: ユーザーは、特定のアイデンティティプールus-east-1:a1b2c3d4-5678-90ab-cdef-example11111
に帰属している必要があります。 -
"cognito-identity.amazonaws.com:amr": "authenticated"
: ユーザーは、認証されている必要があります。ゲストユーザーはロールを引き受けることはできません。
最小特権アクセス許可を適用する
認証アクセスまたはゲストアクセスについて IAM ポリシーでアクセス許可を設定する場合、特定のタスクの実行に必要な特定のアクセス許可、または最小特権アクセス許可のみを付与します。次の IAM ポリシーの例では、これをロールに適用すると、Amazon S3 バケット内の 1 つの画像ファイルへの読み取り専用アクセスを許可します。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:GetObject" ], "Effect": "Allow", "Resource": ["arn:aws:s3:::mybucket/assets/my_picture.jpg"] } ] }
アイデンティティプール設定のベストプラクティス
アイデンティティプールには、AWS 認証情報を生成するための柔軟なオプションがあります。アプリケーションが最も安全な方法で動作できる場合は、設計ショートカットを使用しないでください。
ゲストアクセスの効果を理解する
認証されていないゲストアクセスにより、ユーザーはサインインする前に AWS アカウント からデータを取得できます。アイデンティティプール ID を知っている者は誰でも、認証されていない認証情報をリクエストできます。アイデンティティプール ID は機密情報ではありません。ゲストアクセスを有効にすると、認証されていないセッションに付与した AWS アクセス許可は、すべてのユーザーが利用できます。
ベストプラクティスとしては、ゲストアクセスを非アクティブ化のままにしておき、ユーザーが認証された後にのみ必要なリソースを取得します。アプリケーションがサインイン前にリソースにアクセスする必要がある場合は、次の予防措置を講じます。
-
認証されていないロールに課される自動制限について十分に理解してください。
-
アプリケーションの特定のニーズに合わせて、認証されていない IAM ロールのアクセス許可の監視と調整を行います。
-
エンコードされたバージョンを使用するものです。特定のリソースへのアクセス許可を付与します。
-
デフォルトの認証されていない IAM ロールの信頼ポリシーを保護します。
-
インターネット上のすべてのユーザーに IAM ロールのアクセス許可を付与してもよいと確信できる場合にのみ、ゲストアクセスを有効にします。
デフォルトで拡張認証を使用する
基本 (クラシック) 認証では、Amazon Cognito は IAM ロールの選択をアプリケーションに委任します。対照的に、拡張フローは、アイデンティティプール内の一元化されたロジックを使用して IAM ロールを決定します。また、IAM アクセス許可の上限を設定するスコープダウンポリシーを使用して、認証されていない ID のセキュリティを強化します。拡張フローは、デベロッパーの手間が最も少ない、最も安全な選択肢です。これらのオプションの詳細については、「ID プールの認証フロー」を参照してください。
基本フローでは、認証情報の AWS STS API リクエストのロール選択とアセンブリに入るクライアント側のロジックを公開できます。拡張フローでは、アイデンティティプールの自動化の背後にあるロジックと assume-role リクエストの両方が非表示になります。
基本認証を設定するときは、IAM ロールとそのアクセス許可に IAM ベストプラクティスを適用します。
デベロッパープロバイダーを安全に使用する
デベロッパー認証 ID は、サーバー側アプリケーションのアイデンティティプールの機能です。デベロッパー認証用にアイデンティティプールが必要とする認証の唯一の証拠は、アイデンティティプールデベロッパーの AWS 認証情報です。アイデンティティプールは、この認証フローで提示したデベロッパーとプロバイダーの識別子の有効性に制限を適用しません。
ベストプラクティスとしては、デベロッパープロバイダーは、以下の条件でのみ実装します。
-
デベロッパーが認証した認証情報の使用に関する説明責任を作成するには、デベロッパープロバイダーの名前と識別子を設計して、認証ソースを示します。例:
"Logins" : {"MyCorp provider" : "
。[provider application ID]
"} -
有効期限の長いユーザー認証情報は避けてください。EC2 インスタンスプロファイルや Lambda 実行ロールなどのサービスにリンクされたロールを使用して ID をリクエストするようにサーバー側のクライアントを設定します。
-
同じアイデンティティプールに内部の信頼ソースと外部の信頼ソースを混在させないでください。デベロッパープロバイダーとシングルサインオン (SSO) プロバイダーを別々のアイデンティティプールに追加します。