Amazon Cognito ID プールのセキュリティのベストプラクティス - Amazon Cognito

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Cognito ID プールのセキュリティのベストプラクティス

Amazon Cognito ID プールは、アプリケーションの一時的な AWS 認証情報を提供します。 には、アプリケーションユーザーが必要とするリソースとプライベートバックエンドリソースの両方が含まれる AWS アカウント ことがよくあります。 AWS 認証情報を構成する IAM ロールとポリシーは、これらのリソースへのアクセスを許可できます。

ID プール設定の主なベストプラクティスは、アプリケーションが過剰な権限や意図しない権限なしでジョブを完了できるようにすることです。セキュリティの設定ミスを防ぐには、本番環境にリリースする各アプリケーションを起動する前に、これらの推奨事項を確認してください。

IAM 設定のベストプラクティス

ゲストまたは認証されたユーザーが、アイデンティティプールの認証情報を必要とするセッションをアプリケーションで開始すると、アプリケーションは IAM ロールの一時的な AWS 認証情報を取得します。認証情報は、デフォルトのロール、ID プール設定のルールによって選択されたロール、またはアプリによって選択されたカスタムロールです。各ロールに割り当てられているアクセス許可により、ユーザーは リソースにアクセスできます AWS 。

一般的な IAM のベストプラクティスの詳細については、「 ユーザーガイド」の「IAM のベストプラクティス AWS Identity and Access Management 」を参照してください。

IAM ロールで信頼ポリシー条件を使用する

IAM では、ID プールのロールに少なくとも 1 つの信頼ポリシー条件が必要です。この条件は、例えば、ロールの範囲を認証されたユーザーのみに設定することができます。 AWS STS では、クロスアカウントの基本認証リクエストに cognito-identity.amazonaws.com:audと の 2 つの特定の条件が必要ですcognito-identity.amazonaws.com:amr。ベストプラクティスとして、ID プールサービスプリンシパル を信頼するすべての IAM ロールにこれらの条件の両方を適用しますcognito-identity.amazonaws.com

  • cognito-identity.amazonaws.com:aud: ID プールトークンの aud クレームは、信頼できる ID プール ID と一致する必要があります。

  • cognito-identity.amazonaws.com:amr: ID プールトークンの 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" } } } ] }
ID プールに関連する要素
  • "Federated": "cognito-identity.amazonaws.com": ユーザーは ID プールから取得する必要があります。

  • "cognito-identity.amazonaws.com:aud": "us-east-1:a1b2c3d4-5678-90ab-cdef-example11111": ユーザーは特定の ID プール から取得する必要があります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"] } ] }

ID プール設定のベストプラクティス

ID プールには、 AWS 認証情報を生成するための柔軟なオプションがあります。アプリケーションが最も安全な方法で動作できる場合は、設計ショートカットを使用しないでください。

ゲストアクセスの影響を理解する

認証されていないゲストアクセスにより、ユーザーはサインイン AWS アカウント する前に からデータを取得できます。ID プール ID を知っているユーザーは誰でも、認証されていない認証情報をリクエストできます。ID プール ID は機密情報ではありません。ゲストアクセスをアクティブ化すると、認証されていないセッションに付与した AWS アクセス許可はすべてのユーザーが利用できます。

ベストプラクティスとして、ゲストアクセスを非アクティブ化したままにして、ユーザーが認証された後にのみ必要なリソースを取得します。アプリケーションがサインイン前に リソースにアクセスする必要がある場合は、次の予防措置を講じてください。

  • 認証されていないロールに適用される自動制限を理解します。

  • アプリケーションの特定のニーズに合わせて、認証されていない IAM ロールのアクセス許可をモニタリングおよび調整します。

  • 特定のリソースへのアクセスを許可します。

  • デフォルトの認証されていない IAM ロールの信頼ポリシーを保護します。

  • インターネット上のすべてのユーザーに IAM ロールのアクセス許可を付与すると確信できる場合にのみ、ゲストアクセスを有効にします。

拡張認証をデフォルトで使用する

基本 (クラシック) 認証では、Amazon Cognito は IAM ロールの選択をアプリケーションに委任します。対照的に、拡張フローは ID プール内の集中ロジックを使用して IAM ロールを決定します。また、IAM アクセス許可の上限を設定するスコープダウンポリシーにより、認証されていない ID のセキュリティも強化されます。拡張フローは、デベロッパーの労力が最も低い、最も安全な選択肢です。これらのオプションの詳細については、ID プール (フェデレーティッドアイデンティティ) の認証フロー「」を参照してください。

基本的なフローでは、認証情報の AWS STS API リクエストのロール選択とアセンブリに入るクライアント側のロジックを公開できます。拡張フローでは、ID プールの自動化の背後にあるロジックと assume-role リクエストの両方が非表示になります。

基本認証を設定するときは、IAM ロールとそのアクセス許可に IAM ベストプラクティスを適用します。

デベロッパープロバイダーを安全に使用する

デベロッパーが認証した ID は、サーバー側のアプリケーションの ID プールの機能です。ID プールがデベロッパー認証に必要とする認証の唯一の証拠は、ID プールデベロッパーの AWS 認証情報です。ID プールは、この認証フローで提示したデベロッパーとプロバイダーの識別子の有効性に制限を課しません。

ベストプラクティスとして、デベロッパープロバイダーは、以下の条件でのみ実装してください。

  • デベロッパーが認証した認証情報の使用に関する説明責任を作成するには、デベロッパープロバイダーの名前と識別子を設計して認証ソースを示します。例: "Logins" : {"MyCorp provider" : "[provider application ID]"}

  • 存続期間の長いユーザー認証情報は避けてください。EC2 インスタンスプロファイルLambda 実行ロール などのサービスにリンクされたロールを使用して ID をリクエストするようにサーバー側のクライアントを設定します。

  • 内部と外部の信頼ソースを同じ ID プールに混在させないようにしてください。デベロッパープロバイダーとシングルサインオン (SSO) プロバイダーを別々の ID プールに追加します。