翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Cognito アイデンティティプールに対するセキュリティのベストプラクティス
Amazon Cognito ID プールは、アプリケーションの一時的な AWS 認証情報を提供します。 AWS アカウント には、多くの場合、アプリケーションユーザーが必要とするリソースとプライベートバックエンドリソースの両方が含まれます。 AWS 認証情報を構成する IAM ロールとポリシーは、これらのリソースへのアクセスを許可できます。
アイデンティティプール設定の主なベストプラクティスは、過剰な権限や意図しない権限なしでアプリケーションがジョブを完了できるようにすることです。セキュリティの設定ミスを防ぐために、本番環境にリリースする各アプリケーションの起動前に、これらの推奨事項を確認してください。
**Topics**
+ [IAM 設定のベストプラクティス](#identity-pools-security-best-practices-iam)
+ [アイデンティティプール設定のベストプラクティス](#identity-pools-security-best-practices-cib)
## IAM 設定のベストプラクティス
ゲストまたは認証されたユーザーが、アイデンティティプールの認証情報を必要とするセッションをアプリケーションで開始すると、アプリケーションは IAM ロールの一時的な AWS 認証情報を取得します。認証情報は、デフォルトのロールのもの、アイデンティティプール設定のルールによって選択されたロールのもの、またはアプリケーションによって選択されたカスタムロールのものである場合があります。各ロールに割り当てられたアクセス許可により、ユーザーは AWS リソースにアクセスできます。
一般的な IAM のベストプラクティスの詳細については、 AWS Identity and Access Management 「 ユーザーガイド」の[「IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
### IAM ロールで信頼ポリシー条件を使用する
IAM では、アイデンティティプールのロールに少なくとも 1 つの信頼ポリシー条件が必要です。この条件は、例えば、ロールの範囲を認証されたユーザーのみに設定することができます。 AWS STS また、 では、クロスアカウントの基本認証リクエストに `cognito-identity.amazonaws.com:aud`と の 2 つの特定の条件が必要です`cognito-identity.amazonaws.com:amr`。ベストプラクティスとしては、アイデンティティプールサービスプリンシパル `cognito-identity.amazonaws.com` を信頼するすべての IAM ロールにこの両方の条件を適用します。
+ `cognito-identity.amazonaws.com:aud`: アイデンティティプールトークンの *aud* クレームは、信頼されたアイデンティティプール ID と一致する必要があります。
+ `cognito-identity.amazonaws.com:amr`: アイデンティティプールトークンの *amr* クレームは、*認証されている*もの、または*認証されていない*ものである必要があります。この条件では、認証されていないゲストのみに、または認証されているユーザーのみにロールへのアクセスを予約できます。この条件の値をさらに絞り込んで、`graph.facebook.com` などの特定のプロバイダーのユーザーにロールを制限できます。
次のロール信頼ポリシーの例では、以下の条件下でロールへのアクセスを許可します。
------
#### [ JSON ]
****
```
{
"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 つの画像ファイルへの読み取り専用アクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::mybucket/assets/my_picture.jpg"]
}
]
}
```
------
## アイデンティティプール設定のベストプラクティス
ID プールには、 AWS 認証情報を生成するための柔軟なオプションがあります。アプリケーションが最も安全な方法で動作できる場合は、設計ショートカットを使用しないでください。
### ゲストアクセスの効果を理解する
認証されていないゲストアクセスにより、ユーザーはサインインする前に AWS アカウント からデータを取得できます。アイデンティティプール ID を知っている者は誰でも、認証されていない認証情報をリクエストできます。アイデンティティプール ID は機密情報ではありません。ゲストアクセスをアクティブ化すると、認証されていないセッションに付与する AWS アクセス許可は誰でも利用できます。
ベストプラクティスとしては、ゲストアクセスを非アクティブ化のままにしておき、ユーザーが認証された後にのみ必要なリソースを取得します。アプリケーションがサインイン前にリソースにアクセスする必要がある場合は、次の予防措置を講じます。
+ [認証されていないロールに課される自動制限](iam-roles.md#access-policies-scope-down-services)について十分に理解してください。
+ アプリケーションの特定のニーズに合わせて、認証されていない IAM ロールのアクセス許可の監視と調整を行います。
+ エンコードされたバージョンを使用するものです。特定のリソースへのアクセス許可を付与します。
+ デフォルトの認証されていない IAM ロールの信頼ポリシーを保護します。
+ インターネット上のすべてのユーザーに IAM ロールのアクセス許可を付与してもよいと確信できる場合にのみ、ゲストアクセスを有効にします。
### デフォルトで拡張認証を使用する
基本 (クラシック) 認証では、Amazon Cognito は IAM ロールの選択をアプリケーションに委任します。対照的に、拡張フローは、アイデンティティプール内の一元化されたロジックを使用して IAM ロールを決定します。また、IAM アクセス許可の上限を設定する[スコープダウンポリシー](iam-roles.md#access-policies-scope-down-services)を使用して、認証されていない ID のセキュリティを強化します。拡張フローは、デベロッパーの手間が最も少ない、最も安全な選択肢です。これらのオプションの詳細については、「[ID プールの認証フロー](authentication-flow.md)」を参照してください。
基本的なフローでは、認証情報の AWS STS API リクエストのロール選択とアセンブリに入るクライアント側のロジックを公開できます。拡張フローでは、アイデンティティプールの自動化の背後にあるロジックと assume-role リクエストの両方が非表示になります。
基本認証を設定するときは、IAM ロールとそのアクセス許可に [IAM ベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)を適用します。
### デベロッパープロバイダーを安全に使用する
デベロッパー認証 ID は、サーバー側アプリケーションのアイデンティティプールの機能です。ID プールが開発者認証に必要とする認証の唯一の証拠は、ID プール開発者の AWS 認証情報です。アイデンティティプールは、この認証フローで提示したデベロッパーとプロバイダーの識別子の有効性に制限を適用しません。
ベストプラクティスとしては、デベロッパープロバイダーは、以下の条件でのみ実装します。
+ デベロッパーが認証した認証情報の使用に関する説明責任を作成するには、デベロッパープロバイダーの名前と識別子を設計して、認証ソースを示します。例: `"Logins" : {"MyCorp provider" : "[provider application ID]"}`。
+ 有効期限の長いユーザー認証情報は避けてください。[EC2 インスタンスプロファイル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)や [Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)などのサービスにリンクされたロールを使用して ID をリクエストするようにサーバー側のクライアントを設定します。
+ 同じアイデンティティプールに内部の信頼ソースと外部の信頼ソースを混在させないでください。デベロッパープロバイダーとシングルサインオン (SSO) プロバイダーを別々のアイデンティティプールに追加します。