翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Cognito ユーザープールのセキュリティ機能を使用する
ネットワーク侵入、パスワードの推測、ユーザーのなりすまし、悪意のあるサインアップやサインインからアプリケーションを保護する場合があります。Amazon Cognito ユーザープールのセキュリティ機能の設定は、セキュリティアーキテクチャの重要なコンポーネントである可能性があります。アプリケーションのセキュリティは、「 責任共有モデル」で説明されているように*、お客様の責任「クラウド内のセキュリティ*」です。 AWS [https://aws.amazon.com/compliance/shared-responsibility-model/](https://aws.amazon.com/compliance/shared-responsibility-model/)この章のツールは、これらの目標に沿ったアプリケーションセキュリティ設計の機能に役立ちます。
ユーザープールを設定するときに行う必要がある重要な決定は、パブリックサインアップとパブリックサインインを許可するかどうかです。機密クライアント、管理上の作成とユーザーの確認、ドメインのないユーザープールなどのユーザープールオプションの中には、インターネット経由の攻撃の程度が小さいものがあります。ただし、一般的なユースケースは、インターネット上のすべてのユーザーからサインアップを受け入れ、すべてのオペレーションをユーザープールに直接送信するパブリッククライアントです。どの設定でも、特にこうしたパブリック設定の場合は、セキュリティ機能を念頭に置いてユーザープールの計画とデプロイを行うことをお勧めします。セキュリティが不十分な場合、不要なソースが新しいアクティブユーザーを作成したり、既存のユーザーを悪用しようとしたりすると、 AWS 請求書にも影響する可能性があります。
MFA と脅威保護は、[ローカルユーザー](cognito-terms.md#terms-localuser)に適用されます。サードパーティー IdP は、[フェデレーションユーザー](cognito-terms.md#terms-federateduser)のセキュリティ体制を担当します。ユーザープールのセキュリティ機能
**多要素認証 (MFA)**
ユーザープールのサインインを確認するために、ユーザープールが E メール (エッセンシャル機能プランまたはプラス機能プランの場合)、SMS メッセージ、または Authenticator アプリケーションを使用して送信するコードをリクエストします。
**脅威保護**
リスクの指標に関してサインインをモニタリングして、MFA を適用するか、またはサインインをブロックします。アクセストークンにカスタムクレームとスコープを追加します。MFA コードを E メールで送信します。
**AWS WAF ウェブ ACLs**
[ユーザープールエンドポイントと認証 API](authentication-flows-public-server-side.md#user-pools-API-operations) への受信トラフィックについて、ネットワークレイヤーとアプリケーションレイヤーでの望ましくないアクティビティがないか検査します。
**大文字と小文字の区別**
E メールアドレスまたは任意のユーザー名が、文字の大文字と小文字の区別を除き、他のユーザーと同じになるユーザーの作成を防止します。
**削除保護**
自動システムがユーザープールを誤って削除しないようにします。 AWS マネジメントコンソールでのユーザープールの削除を追加で確認する必要があります。
**ユーザー存在エラー**
ユーザープール内の既存のユーザー名とエイリアスの開示を防止します。ユーザー名が有効かどうかにかかわらず、認証に失敗した場合に一般的なエラーを返します。
**Topics**
+ [ユーザープールに MFA を追加します](user-pool-settings-mfa.md)
+ [脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)
+ [AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)
+ [ユーザープールの大文字と小文字の区別](user-pool-case-sensitivity.md)
+ [ユーザープールの削除保護](user-pool-settings-deletion-protection.md)
+ [ユーザー存在エラー応答の管理](cognito-user-pool-managing-errors.md)
# ユーザープールに MFA を追加します
これは、一般的にはユーザー名とパスワードになっている、初期設定の*知っていること*の認証要素に、*持っていること*の認証要素を追加するものです。パスワードを主要な認証要素とするユーザーをサインインさせるには、SMS テキストメッセージ、E メールメッセージ、または時間ベースのワンタイムパスワード (TOTP) を追加要素として選択できます。
多要素認証 (MFA) は、アプリケーション内の[ローカルユーザー](cognito-terms.md#terms-localuser)のセキュリティを向上させます。[フェデレーションユーザー](cognito-terms.md#terms-federateduser)の場合、Amazon Cognito はすべての認証プロセスを IdP に委任するので、追加の認証要素を提供しません。
**注記**
新しいユーザーがアプリに初めてサインインするときに、Amazon Cognito は OAuth 2.0 トークンを発行します。これは、ユーザープールに MFA が必要な場合でも同様です。ユーザーが初めてサインインするときの 2 番目の認証要因は、Amazon Cognito が送信する検証メッセージの確認です。ユーザープールに MFA が必要な場合、Amazon Cognito は、最初のログイン試行後の各サインイン試行で使用する追加のサインイン係数を登録するようユーザーに要求します。
アダプティブ認証では、リスクレベルの上昇に対応して、追加の要素認証を要求するようにユーザープールを設定できます。アダプティブ認証をユーザープールに追加するには、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。
ユーザープールの MFA が `required` に設定されている場合は、すべてのユーザーはサインインするために MFA を完了する必要があります。サインインするために、各ユーザーには、少なくとも 1 つの MFA 要素が必要です。MFA を必須にする場合は、ユーザーオンボーディングに MFA セットアップを含め、ユーザープールでユーザーのサインインを許可する必要があります。
MFA を必須に設定すると、マネージドログインは MFA を設定することをユーザーに求めます。ユーザープールで MFA をオプションとして設定すると、マネージドログインはユーザーに設定を求めません。オプションの MFA を使用するには、ユーザーに MFA を設定するかどうかを選択するようプロンプトを表示し、API 入力を案内して追加のサインイン要素を確認するインターフェースをアプリに構築する必要があります。
**Topics**
+ [ユーザープールの MFA について知っておくべきこと](#user-pool-settings-mfa-prerequisites)
+ [ユーザー MFA 設定](#user-pool-settings-mfa-preferences)
+ [ユーザー実行時の MFA ロジックの詳細](#user-pool-settings-mfa-user-outcomes)
+ [ユーザープールでの多要素認証を設定する](#user-pool-configuring-mfa)
+ [SMS メッセージ MFA と E メールメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)
+ [TOTP ソフトウェアトークン MFA](user-pool-settings-mfa-totp.md)
## ユーザープールの MFA について知っておくべきこと
MFA を設定する前に、次の点を考慮します。
+ ユーザーは MFA を使用する*か*、パスワードレス要素でサインインできます。ただし、ユーザープール `MULTI_FACTOR_WITH_USER_VERIFICATION`で `FactorConfiguration`を に設定すると、ユーザー検証付きのパスキーが MFA 要件を満たすことができます`WebAuthnConfiguration`。
+ [ワンタイムパスワード](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)をサポートするユーザープールでは、MFA を必須に設定することはできません。
+ ユーザープールで `AllowedFirstAuthFactors` MFA が必要な場合、 `EMAIL_OTP`または `SMS_OTP`を に追加することはできません。`WEB_AUTHN` `FactorConfiguration` が に設定されている場合、 を追加できます`MULTI_FACTOR_WITH_USER_VERIFICATION`。
+ [選択ベースのサインイン](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)では、ユーザープールで MFA が必須である場合にのみ、すべてのアプリケーションクライアントに `PASSWORD` 要素と `PASSWORD_SRP` 要素を提供します。ユーザー名パスワードフローの詳細については、このガイドの「**認証**」章で「[永続的なパスワードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-password)」と「[永続的なパスワードと安全なペイロードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp)」を参照してください。
+ MFA がオプションであるユーザープールでは、MFA 要素を設定したユーザーは、選択ベースのサインインでユーザー名パスワード認証フローを使用してのみサインインできます。これらのユーザーは、すべての[クライアントベースのサインイン](authentication-flows-selection-sdk.md#authentication-flows-selection-client)フローを利用できます。
次の表は、ユーザープールの MFA 設定とユーザーによる MFA 要素の設定が、パスワードなしの要素を使用したユーザーのサインインに与える影響を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-settings-mfa.html)
+ ユーザーが希望する MFA の方法は、パスワードの復旧に使用できる方法に影響します。希望する MFA を E メールメッセージにしたユーザーは、パスワードリセットコードを E メールで受信できません。希望する MFA を SMS メッセージにしたユーザーは、パスワードリセットコードを SMS で受信できません。
希望するパスワードリセット方法の対象にユーザーがなっていない場合、[[パスワード復旧]](managing-users-passwords.md#user-pool-password-reset-and-recovery) 設定で代替オプションを提供する必要があります。例えば、復旧メカニズムで E メールが最優先事項になっており、E メール MFA がユーザープールのオプションである場合があります。この場合、SMS メッセージによるアカウント復旧を 2 番目のオプションとして追加するか、管理 API オペレーションを使用してこれらのユーザーのパスワードをリセットします。
Amazon Cognito は、有効な復旧方法を持たないユーザーからのパスワードリセットリクエストに対して、`InvalidParameterException` エラーレスポンスで応答します。
[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#API_UpdateUserPool_Examples) のリクエスト本文の例は、`AccountRecoverySetting` を示しています。E メールメッセージによるパスワードのリセットが利用できない場合、ユーザーはここにフォールバックして、SMS メッセージによる復旧を行うことができます。
+ ユーザーは、MFA とパスワードのリセットコードを、同じ E メールアドレスや電話番号で受け取ることはできません。E メールメッセージのワンタイムパスワード (OTP) を MFA に使用する場合、アカウントの復旧には SMS メッセージを使用する必要があります。SMS メッセージの OTP を MFA に使用する場合、アカウントの復旧には E メールメッセージを使用する必要があります。MFA を使用するユーザープールでは、属性として E メールアドレスがあっても電話番号がないか、電話番号があっても E メールアドレスがない場合、ユーザーはセルフサービスのパスワード復旧を完了できない可能性があります。
この設定でユーザーがユーザープールのパスワードをリセットできない状況を防ぐには、`email` および `phone_number` [属性を必須](user-pool-settings-attributes.md)に設定します。別の方法として、ユーザーのサインアップ時や管理者によるユーザープロファイルの作成時に、これらの属性を常に収集して設定するようにプロセスを設定することもできます。ユーザーが両方の属性を持っている場合、Amazon Cognito は、ユーザーの MFA 要素*ではない*送信先にパスワードリセットコードを自動的に送信します。
+ ユーザープールで MFA を有効にし、2 番目の要素として **SMS メッセージ**または **E メールメッセージ**を選択すると、Amazon Cognito で検証していない電話番号または E メール属性にメッセージを送信できます。ユーザーが MFA を完了すると、Amazon Cognito は、`phone_number_verified` 属性または `email_verified` 属性を `true` に設定します。
+ MFA コードの提示に 5 回失敗すると、Amazon Cognito は [サインイン試行の失敗時におけるロックアウト動作](authentication.md#authentication-flow-lockout-behavior) で説明した指数関数的タイムアウトロックアウトプロセスを開始します。
+ アカウントがユーザープールの Amazon Simple Notification Service (Amazon SNS) リソース AWS リージョン を含む の SMS サンドボックスにある場合は、SMS メッセージを送信する前に Amazon SNS で電話番号を確認する必要があります。詳細については、「[Amazon Cognito ユーザープール用の SMS メッセージ設定](user-pool-sms-settings.md)」を参照してください。
+ 脅威保護で検出されたイベントに応じてユーザーの MFA ステータスを変更するには、Amazon Cognito ユーザープールコンソールで MFA を有効にしてオプションとして設定します。詳細については、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。
+ E メールメッセージと SMS メッセージでは、各ユーザーに E メールアドレスと電話番号の属性が必要です。ユーザープールでは、`email` または `phone_number` を必須の属性として設定できます。この場合、ユーザーは電話番号を指定しない限りサインアップを完了できません。これらの属性について必要に応じた設定を行わずに、E メールメッセージ MFA または SMS メッセージ MFA を実行する場合は、サインアップ時に E メールアドレスまたは電話番号の入力を求めます。ベストプラクティスとして、ユーザープールを設定して、[これらの属性を検証する](signing-up-users-in-your-app.md)ようにユーザーに自動的にメッセージを送信します。
Amazon Cognito は、ユーザーが SMS メッセージまたは E メールメッセージで仮コードを受信し、[VerifyUserAttribute](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) API リクエストでそのコードを返した場合、その電話番号または E メールアドレスを検証済みとしてカウントします。代わりに、チームは、電話番号を設定し、[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API リクエストを実行する管理用アプリケーションを使用して検証済みとしてマークできます。
+ MFA を必須に設定し、複数の認証要素をアクティブ化した場合、Amazon Cognito は新しいユーザーに、使用する MFA 要素を選択するよう求めます。ユーザーは、SMS メッセージ MFA をセットアップするための電話番号と、E メールメッセージ MFA をセットアップするための E メールアドレスを持っている必要があります。使用可能なメッセージベースの MFA に属性が定義されていない場合、Amazon Cognito は TOTP MFA を設定するようにユーザーに求めます。MFA 要素 (`SELECT_MFA_TYPE`) を選択し、選択した要素 (`MFA_SETUP`) を設定するように求めるプロンプトが、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) および [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) の API オペレーションへのチャレンジレスポンスとして表示されます。
## ユーザー MFA 設定
ユーザーは複数の MFA 要素を設定できます。アクティブにできるのは 1 つだけです。ユーザープール設定またはユーザープロンプトで、ユーザーの有効な MFA 設定を選択できます。ユーザープールの設定と独自のユーザーレベルの設定が以下の条件を満たす場合、ユーザープールは MFA コードをユーザーに要求します。
1. ユーザープールで MFA をオプションまたは必須に設定している。
1. ユーザーは、有効な `email` 属性または `phone_number` 属性を持っているか、Authenticator アプリケーションを TOTP 用にセットアップ済みである。
1. 少なくとも 1 つの MFA 要素がアクティブである。
1. 1 つの MFA 要素を優先として設定している。
### サインインと MFA に同じ要素を使用しない
ユーザープールは、1 つのサインイン要素を一部またはすべてのユーザーが使用できる唯一のサインインおよび MFA オプションにする方法で設定できます。この結果は、プライマリサインインのユースケースが E メールメッセージまたは SMS メッセージワンタイムパスワード (OTPs) である場合に発生する可能性があります。ユーザーが優先する MFA は、次の条件でサインインと同じタイプの要素である場合があります。
+ ユーザープールには MFA が必要です。
+ E メールと SMS OTP は、ユーザープールでサインイン*オプションと* MFA オプションを使用できます。
+ ユーザーは E メールまたは SMS メッセージ OTP でサインインします。
+ E メールアドレス属性はありますが、電話番号属性はありません。または、電話番号属性はありますが、E メールアドレス属性はありません。
このシナリオでは、ユーザーは E メール OTP でサインインし、E メール OTP で MFA を完了できます。このオプションは、MFA の必須関数をキャンセルします。ワンタイムパスワードでサインインするユーザーは、MFA とは異なる配信方法をサインインに使用できる必要があります。ユーザーに SMS オプションと E メールオプションの両方がある場合、Amazon Cognito は別の要素を自動的に割り当てます。たとえば、ユーザーが E メール OTP でサインインする場合、希望する MFA は SMS OTP です。
ユーザープールがサインインと MFA の両方で OTP 認証をサポートしている場合、次の手順を実行して同じ要素認証に対処します。
1. サインイン要因として E メールと SMS OTP の両方を有効にします。
1. E メールと SMS OTP の両方を MFA 要因として有効にします。
1. 収集
### ユーザープールの設定と MFA オプションへの影響
ユーザープールの設定は、ユーザーが選択できる MFA の方法に影響します。以下のいくつかのユーザープール設定が、ユーザーによる MFA の設定に影響します。
+ Amazon Cognito コンソールの **[サインイン]** メニューの **[多要素認証]** 設定で、MFA をオプションまたは必須に設定するか、オフにすることができます。この設定と同等の API は、`CreateUserPool`、`UpdateUserPool`、および `SetUserPoolMfaConfig` の [MfaConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-MfaConfiguration) パラメータです。
また、**[多要素認証]** 設定では、**[MFA の方法]** 設定によって、ユーザーが設定できる MFA 要素が決まります。この設定と同等の API は [SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html) オペレーションです。
+ **[サインイン]** メニューの **[ユーザーアカウントの復旧]** で、パスワードを忘れたユーザーにユーザープールからメッセージを送信する方法を設定できます。ユーザーの MFA の方法は、パスワードを忘れた場合のコードをユーザープールから配信する方法と同じにすることはできません。パスワードを忘れた場合の配信方法の API パラメータは、`CreateUserPool` および `UpdateUserPool` の [AccountRecoverySetting](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-AccountRecoverySetting) パラメータです。
例えば、復旧オプションが **[E メールのみ]** の場合、ユーザーは E メール MFA を設定できません。これは、同じユーザープールで E メール MFA を有効にして、復旧オプションを **[E メールのみ]** に設定することはできないためです。このオプションを **[使用可能な場合は E メール、それ以外の場合は SMS]** に設定すると、E メールが優先の復旧オプションになりますが、ユーザーが E メールメッセージ復旧の対象でない場合、ユーザープールは SMS メッセージにフォールバックできます。この場合、ユーザーは E メール MFA を優先として設定し、パスワードをリセットするときにのみ SMS メッセージを受信できます。
+ 使用できるものとして 1 つの MFA の方法のみを設定した場合、ユーザーの MFA 設定を管理する必要はありません。
+ SMS をアクティブに設定すると、ユーザープールで SMS メッセージが、使用できる MFA の方法に自動的になります。
ユーザープール内の独自の Amazon SES リソースと、エッセンシャル機能プランまたはプラス機能プランを使用した、アクティブな [E メール設定](user-pool-email.md)により、E メールメッセージは自動的にユーザープールで使用可能な MFA 方法になります。
+ ユーザープールで MFA を必須に設定すると、ユーザーは MFA の方法を有効または無効にできません。設定できるのは、希望する方法のみです。
+ ユーザープールで MFA をオプションとして設定すると、マネージドログインは、MFA を設定するようユーザーに求めません。ただし、希望する MFA の方法を持っているユーザーには、MFA コードの入力を求めます。
+ [[脅威保護]](cognito-user-pool-settings-threat-protection.md) を有効にし、アダプティブ認証レスポンスをフル機能モードで設定する場合、MFA がユーザープールでオプションになっている必要があります。アダプティブ認証によるレスポンスオプションの 1 つは、サインイン試行にリスクレベルが含まれていると評価されたユーザーに MFA を要求することです。
コンソールの **[サインアップ]** メニューの **[必須属性]** 設定は、ユーザーがアプリケーションにサインアップするために E メールアドレスまたは電話番号を入力する必要があるかどうかを決定します。ユーザーが対応する属性を持っている場合、E メールメッセージと SMS メッセージは MFA 要素として適格になります。`CreateUserPool` の[スキーマ](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-Schema)パラメータは、必要に応じて属性を設定します。
+ ユーザープールで MFA を必須として設定した場合、ユーザーがマネージドログインを使用してサインインすると、Amazon Cognito はユーザープールで利用可能な MFA 方法から選択するようユーザーに求めます。マネージドログインは、E メールアドレスまたは電話番号の収集と TOTP の設定を処理します。以下の図は、Amazon Cognito がユーザーに提示するオプションの背後のロジックを示しています。
### ユーザーの MFA 設定を構成する
アクセストークン認証を使用するセルフサービスモデル、または管理 API オペレーションを使用する管理者管理モデルで、ユーザーの MFA の希望を設定できます。これらのオペレーションは MFA の方法を有効または無効にし、複数の方法のうちのいずれかを、希望するオプションとして設定します。ユーザーが MFA の希望を設定すると、Amazon Cognito はサインイン時に、希望する MFA の方法によるコードを提供するようにユーザーに求めます。希望を設定していないユーザーは、`SELECT_MFA_TYPE` チャレンジで、希望する方法を選択するよう求めるプロンプトを受け取ります。
+ ユーザーセルフサービスモデルまたはパブリックアプリケーションでは、サインインユーザーのアクセストークンで認可された [SetUserMfaPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserMFAPreference.html) によって MFA の設定が決まります。
+ 管理者管理アプリケーションまたは機密アプリケーションでは、管理者 AWS 認証情報で承認された [AdminSetUserPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserMFAPreference.html) が MFA 設定を設定します。
また、Amazon Cognito コンソールの **[ユーザー]** メニューからユーザーの MFA 設定を構成することもできます。Amazon Cognito ユーザープール API オペレーションのパブリック認証モデルと機密認証モデルの詳細については、「[API、OIDC、マネージドログインページの認証についての理解](authentication-flows-public-server-side.md#user-pools-API-operations)」を参照してください。
## ユーザー実行時の MFA ロジックの詳細
ユーザーがサインインするときに実行する手順を決定するために、ユーザープールはユーザーの MFA 設定、[ユーザー属性](user-pool-settings-attributes.md)、[ユーザープールの MFA 設定](#user-pool-configuring-mfa)、[脅威保護](cognito-user-pool-settings-adaptive-authentication.md)アクション、[セルフサービスのアカウントの復旧](managing-users-passwords.md#user-pool-password-reset-and-recovery)に関する設定を評価します。次に、ユーザーをサインインさせ、MFA の方法の選択、設定、または入力をユーザーに求めます。MFA の方法を設定する場合、ユーザーは [E メールアドレスまたは電話番号](user-pool-settings-mfa-sms-email-message.md)を指定するか、[TOTP Authenticator を登録](user-pool-settings-mfa-totp.md#totp-mfa-set-up-api)する必要があります。事前に MFA のオプションを設定し、[優先オプションを登録](#user-pool-settings-mfa-preferences-configure)することもできます。以下の図は、ユーザープールの設定が、初回サインアップ直後のサインイン試行にどのような影響を及ぼすかを詳しく示しています。
ここに示したロジックは、SDK ベースのアプリケーションと[マネージドログイン](cognito-user-pools-managed-login.md)のサインインに適用されますが、マネージドログインの場合、影響はあまり明確ではありません。MFA のトラブルシューティングを行うときは、ユーザーの結果から遡って、決定に影響を及ぼしたユーザープロファイルやユーザープールの設定を検討してください。
![\[Amazon Cognito ユーザープールでのエンドユーザーによる MFA 選択の意思決定プロセスを示す図。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-mfa-decision-tree.png)
次のリストは、意思決定ロジック図の番号に対応したステップごとの詳しく説明です。![\[checkmark\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png) は、認証の成功とフローの結果を示します。![\[error\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/error.png) は、認証の失敗を示します。
1. ユーザーはサインイン画面でユーザー名を入力するか、ユーザー名とパスワードを入力します。有効な認証情報を提示しない場合、サインインリクエストは拒否されます。
1. ユーザー名パスワード認証が成功したら、MFA を必須、オプション、またはオフのいずれにするかを決めます。オフにした場合は、正しいユーザー名とパスワードを入力すると、認証が成功します。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. MFA をオプションにした場合は、ユーザーが TOTP Authenticator を設定済みであるかどうかを確認します。TOTP を設定済みである場合は、TOTP を使用した MFA を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. 脅威保護のアダプティブ認証機能により、MFA を設定することをユーザーに求めているかどうかを確認します。MFA が割り当てられていない場合、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. MFA が必須であるか、アダプティブ認証が MFA を割り当て済みである場合は、ユーザーが MFA 要素を有効および優先として設定しているかどうかを確認します。設定している場合は、その要素を使用した MFA の入力を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. ユーザーが MFA 設定を指定していない場合は、ユーザーが TOTP Authenticator を登録済みであるかどうかを確認します。
1. ユーザーが TOTP Authenticator を登録済みである場合は、TOTP MFA がユーザープールで使用可能かどうかを確認します (ユーザーが以前に Authenticator を設定した後で、TOTP MFA が無効になっている可能性があります)。
1. E メールメッセージ MFA または SMS メッセージ MFA もユーザープールで利用できるかどうかを確認します。
1. E メール MFA も SMS MFA も利用できない場合は、ユーザーに TOTP を使用した MFA を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. E メール MFA または SMS MFA が利用可能な場合は、ユーザーが対応する `email` 属性または `phone_number` 属性を持っているかどうかを確認します。持っている場合は、セルフサービスのアカウント復旧のプライマリ方法ではなく、MFA が有効になっている属性であれば、ユーザーが使用できます。
1. TOTP と利用可能な SMS MFA 要素または E メール MFA 要素を含む `MFAS_CAN_SELECT` オプションを使用して、`SELECT_MFA_TYPE` チャレンジに応答するようユーザーに求めます。
1. `SELECT_MFA_TYPE` チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. ユーザーが TOTP Authenticator を登録していないか、登録済みでも TOTP MFA が現在無効になっている場合は、ユーザーが `email` 属性または `phone_number` 属性を持っているかどうかを確認します。
1. ユーザーが属性として E メールアドレスまたは電話番号のみを持っている場合、その属性が、ユーザープールでパスワードリセット用のアカウント復旧メッセージを送信するために実装する方法と同じであるかどうかを確認します。同じである場合、MFA を必須としているサインインは完了できず、Amazon Cognito はエラーを返します。このユーザーのサインインを有効にするには、復旧用ではない属性を追加するか、TOTP Authenticator を登録する必要があります。![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/error.png)
1. 復旧用ではない E メールアドレスや電話番号を利用できる場合は、対応する E メール要素または SMS MFA 要素が有効になっているかどうかを確認します。
1. 復旧用ではない E メールアドレス属性があり、E メール MFA が有効になっている場合は、`EMAIL_OTP` チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. 復旧用ではない電話番号属性があり、SMS MFA が有効になっている場合は、`SMS_MFA` チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. 有効な E メール MFA 要素または SMS MFA 要素の対象となる属性がない場合は、TOTP MFA が有効になっているかどうかを確認します。TOTP MFA が無効になっている場合、ユーザーは MFA を必須としているサインインを完了できず、Amazon Cognito はエラーを返します。このユーザーのサインインを有効にするには、復旧用ではない属性を追加するか、TOTP Authenticator を登録する必要があります。![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/error.png)
**注記**
ユーザーが TOTP Authenticator を持っているが TOTP MFA が無効になっている場合、このステップは **[いいえ]** と評価済みです。
1. TOTP MFA が有効になっている場合は、`MFAS_CAN_SETUP` オプションの `SOFTWARE_TOKEN_MFA` を使用してユーザーに `MFA_SETUP` チャレンジを提示します。このチャレンジを完了するには、ユーザーの TOTP Authenticator を個別に登録し、`"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "SESSION": "[Session ID from VerifySoftwareToken]}"` を使用して応答する必要があります。
1. ユーザーが [VerifySoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifySoftwareToken.html) リクエストからのセッショントークンで `MFA_SETUP` チャレンジに応答すると、ユーザーは `SOFTWARE_TOKEN_MFA` チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. ユーザーが E メールアドレスと電話番号の両方を持っている場合は、どちらの属性がパスワードリセットのアカウント復旧メッセージのプライマリ方法であるかを確認します。
1. セルフサービスのアカウントの復旧が無効になっている場合は、どちらの属性も MFA に使用できます。E メール MFA 要素と SMS MFA 要素の一方または両方が有効になっているかどうかを確認します。
1. 両方の属性が MFA 要素として有効になっている場合は、`MFAS_CAN_SELECT` のオプション (`SMS_MFA` と `EMAIL_OTP`) を使用して `SELECT_MFA_TYPE` チャレンジに応答するようユーザーに求めます。
1. `SELECT_MFA_TYPE` チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
1. 1 つの属性のみが適格な MFA 要素である場合は、残りの要素のチャレンジに応答するようユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
この結果が生じるのは、以下の場合です。
1. ユーザーが `email` 属性と `phone_number` 属性を持っていて、SMS MFA と E メール MFA が有効であり、アカウント復旧のプライマリ方法が E メールまたは SMS メッセージである場合。
1. ユーザーが `email` 属性と `phone_number` 属性を持っていて、SMS MFA または E メール MFA の一方のみが有効であり、セルフサービスのアカウントの復旧が無効になっている場合。
1. ユーザーが TOTP Authenticator を登録しておらず、`email` 属性も `phone_number` 属性も持っていない場合は、`MFA_SETUP` チャレンジに応答するようユーザーに求めます。`MFAS_CAN_SETUP` のリストには、ユーザープールのすべての有効な MFA 要因のうち、アカウント復旧のプライマリ方法ではないものが表示されます。ユーザーは E メール MFA または TOTP MFA で `ChallengeResponses` を使用し、このチャレンジに応答できます。SMS MFA を設定するには、電話番号属性を別個に追加し、認証を再開します。
TOTP MFA の場合は、`"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "SESSION": "[Session ID from VerifySoftwareToken]"}` を使用して応答します。
E メール MFA の場合は、`"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "email": "[user's email address]"}` を使用して応答します。
1. `SELECT_MFA_TYPE` チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)
## ユーザープールでの多要素認証を設定する
MFA を設定するには、Amazon Cognito コンソールを使用するか、[SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html) API オペレーションと SDK メソッドを使用できます。
**Amazon Cognito コンソールで MFA を設定する**
1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。
1. **[User Pools]** (ユーザープール) を選択します。
1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。
1. **[サインイン]** メニューを選択します。**[多要素認証]** を見つけて、**[編集]** を選択します。
1. ユーザープールで使用する **[MFA enforcement]** (MFA 強制実行) 方法を選択します。
![\[Amazon Cognito コンソールの MFA オプションを示すスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-mfa.png)
1. **MFA が必要**。ユーザープール内のすべてのユーザーは、さらに SMS、E メール、または時間ベースのワンタイムパスワード (TOTP) コードを追加の認証要素として使用し、サインインする必要があります。
1. **オプションの MFA**。ユーザーに追加のサインイン要素を登録するオプションを提供した場合でも、MFA を設定していないユーザーに依然としてサインインを許可できます。アダプティブ認証を使用している場合は、このオプションを選択してください。アダプティブ認証の詳細については、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。
1. **MFA なし**。ユーザーは、サインイン要素を追加登録することはできません。
1. アプリケーションでサポートする **[MFA methods]** (MFA メソッド) を選択します。2 番目の要素として **E メールメッセージ**、**SMS メッセージ**または TOTP 生成**認証アプリケーション**を設定できます。
1. 2 番目の要素として SMS テキストメッセージを使用していて、SMS メッセージ用の Amazon Simple Notification Service で使用する IAM ロールを設定していない場合は、コンソールで作成できます。ユーザープールの **[認証方法]** メニューで、**[SMS]** を見つけて **[編集]** を選択します。Amazon Cognito がユーザーに SMS メッセージを送信することを許可する既存のロールを使用することもできます。詳細については、[「IAM ロール」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を参照してください。
E メールメッセージを第 2 の要素として使用し、Amazon Simple Email Service (Amazon SES) で E メールメッセージに使用する送信元 ID を設定していない場合は、コンソールで作成します。**[SES で E メールを送信]** オプションを選択する必要があります。ユーザープールの **[認証方法]** メニューで、**[E メール]** を見つけて **[編集]** を選択します。リストの利用可能な検証済み ID から **[送信元の Eメールアドレス]** を選択します。検証済みドメイン (`example.com` など) を選択した場合は、検証済みドメイン (`admin-noreply@example.com` など) で **[送信者の名前]** も設定する必要があります。
1. **[Save changes]** (変更の保存) をクリックします。
# SMS メッセージ MFA と E メールメッセージ MFA
SMS MFA メッセージと E メールの MFA メッセージは、サインインする前にユーザーがメッセージの宛先にアクセスできることを確認します。パスワードだけでなく、元のユーザーの SMS メッセージまたは E メールの受信トレイにもアクセスできることを確認します。Amazon Cognito は、ユーザーがユーザー名とパスワードを正常に提供した後にユーザープールが送信した短いコードを提供するようユーザーに要求します。
ユーザーがプロファイルに E メールアドレスまたは電話番号を追加すると、SMS メッセージ MFA および E メールメッセージ MFA に追加の設定は必要ありません。Amazon Cognito は、未検証の E メールアドレスと電話番号にメッセージを送信できます。ユーザーが最初の MFA を完了すると、Amazon Cognito は、その E メールアドレスまたは電話番号を検証済みとしてマークします。
MFA 認証は、MFA を持つユーザーがアプリケーションにユーザー名とパスワードを入力したときに開始されます。アプリケーションは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API リクエストまたは [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) API リクエストを呼び出す SDK メソッドでこれらの初期パラメータを送信します。API レスポンスの `ChallengeParameters` には、認証コードが送信された場所を示す `CODE_DELIVERY_DESTINATION` 値が含まれます。アプリケーションで、ユーザーに電話を確認するよう求め、かつコードの入力要素を含めたフォームを表示します。コードを入力したら、チャレンジレスポンス API リクエストでコードを送信してサインインプロセスを完了します。
MFA を持つユーザーが[マネージドログイン](cognito-user-pools-managed-login.md)ページでユーザー名とパスワードを使用してサインインすると、ユーザーは MFA コードを入力するよう自動的に求められます。
ユーザープールは、 AWS アカウントの Amazon Simple Notification Service (Amazon SNS) リソースを使用して、MFA およびその他の Amazon Cognito 通知に関して SMS メッセージを送信します。同様に、ユーザープールは、アカウントの Amazon Simple Email Service (Amazon SES) リソースを使用して E メールメッセージを送信します。これらのリンクされたサービスでは、メッセージ配信の AWS 請求書に独自のコストが発生します。また、本番稼働ボリュームでメッセージを送信するための追加要件もあります。詳細については、以下のリンクを参照してください。
+ [Amazon Cognito ユーザープール用の SMS メッセージ設定](user-pool-sms-settings.md)
+ [ワールドワイド SMS 料金](https://aws.amazon.com/sns/sms-pricing/)
+ [Amazon Cognito ユーザープールの E メール設定](user-pool-email.md)
+ [Amazon SES の価格設定](https://aws.amazon.com/ses/pricing)
## SMS メッセージ MFA と E メールメッセージ MFA に関する考慮事項
+ ユーザーに E メール MFA でのサインインを許可するには、ユーザープールに次の設定オプションが必要です。
1. ユーザープールにプラス機能プランまたはエッセンシャル機能プランがある。詳細については、「[ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)」を参照してください。
1. ユーザープールは、独自の Amazon SES リソースを使用して E メールメッセージを送信する。詳細については、「[Amazon SES の E メール設定](user-pool-email.md#user-pool-email-developer)」を参照してください。
+ MFA コードは、アプリケーションクライアントで設定した**認証フローセッションの持続期間**の間有効です。
認証フローセッションの持続期間は、Amazon Cognito コンソールの **[アプリケーションクライアント]** メニューで、アプリケーションクライアントを**編集**するときに設定します。`CreateUserPoolClient` または `UpdateUserPoolClient` API リクエストで認証フローセッション持続期間を設定することも可能です。詳細については、「[認証セッションの例](authentication.md#amazon-cognito-user-pools-authentication-flow)」を参照してください。
+ 検証されていない電話番号または E メールアドレスに Amazon Cognito が送信した SMS または E メールメッセージからユーザーがコードを正常に提供すると、Amazon Cognito は、対応する属性を検証済みとしてマークします。
+ MFA に関連付けられた電話番号または E メールアドレスの値に対してユーザーがセルフサービスで変更を加えるには、サインインしたうえでアクセストークンを使用してリクエストを認可する必要があります。現在の電話番号または E メールアドレスにアクセスできない場合は、サインインできません。チームは、[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API リクエストで管理者 AWS 認証情報を使用してこれらの値を変更する必要があります。
+ ユーザープールで [SMS を設定](user-pool-sms-settings.md)した後は、使用できる MFA 要素として SMS メッセージを無効にすることはできません。
# TOTP ソフトウェアトークン MFA
ユーザープールで TOTP ソフトウェアトークン MFA を設定すると、ユーザーはユーザー名とパスワードでサインインし、TOTP を使用して認証を完了します。ユーザーがユーザー名とパスワードを設定して検証した後、MFA の TOTP ソフトウェアトークンを有効化できます。アプリケーションでユーザーのサインインに Amazon Cognito のマネージドログインを使用する場合、ユーザーはユーザー名とパスワードを送信し、別のサインインページで TOTP パスワードを送信します。
ユーザープールの TOTP MFA は、Amazon Cognito コンソールでアクティブ化することも、Amazon Cognito API オペレーションを使用してもかまいません。ユーザープールレベルでは、[SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html) を呼び出すことで、MFA を設定して TOTP MFA を有効化できます。
**注記**
TOTP ソフトウェアトークン MFA がユーザープールに対して有効になっていない場合は、Amazon Cognito で、ユーザーをトークンに関連付けたり、トークンで検証することができません。この場合、ユーザーは`SoftwareTokenMFANotFoundException`説明による例外`Software Token MFA has not been enabled by the userPool`を受診します。ソフトウェアトークン MFA が後にユーザープールに対して非アクティブ化された場合、以前に TOTP トークンを関連付けて検証したユーザーは、引き続き MFA で使用することができます。
ユーザーの TOTP の設定には複数のステップが伴います。ユーザーはシークレットコードを受け取り、ワンタイムパスワードを入力して、このコードを検証します。次に、ユーザーの TOTP MFA を有効にするか、ユーザーの優先 MFA メソッドとして TOTP を設定することができます。
ユーザープールで TOTP MFA を必須に設定した場合、ユーザーがマネージドログインでアプリケーションにサインアップするときに、Amazon Cognito はユーザープロセスを自動化します。Amazon Cognito は、ユーザーに MFA メソッドの選択を促し、Authenticator アプリケーションを設定するための QR コードを表示し、MFA 登録を確認します。ユーザーが SMS と TOTP MFA のどちらかを選択できるようにしたユーザープールでは、Amazon Cognito もユーザーに選択肢を提示します。
**重要**
ユーザープールに関連付けられた AWS WAF ウェブ ACL があり、ウェブ ACL のルールが CAPTCHA を提示すると、マネージドログイン TOTP 登録で回復不可能なエラーが発生する可能性があります。CAPTCHA アクションを含み、マネージドログインの TOTP には影響しないルールを作成するには、「[マネージドログイン TOTP MFA 用の AWS WAF ウェブ ACL の設定](#totp-waf)」を参照してください。 AWS WAF ウェブ ACL と Amazon Cognito の詳細については、「[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)」を参照してください。
AWS SDK と [Amazon Cognito ユーザープール API を使用してカスタムビルド UI に TOTP MFA を実装するには、](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html)「」を参照してください[ユーザーの TOTP MFA の設定](#totp-mfa-set-up-api)。
MFA をユーザープールに追加するには、「[ユーザープールに MFA を追加します](user-pool-settings-mfa.md)」を参照してください。
**TOTP MFA 考慮事項と制約事項**
1. Amazon Cognito は、TOTP コードを生成する Authenticator アプリケーションを介してソフトウェアトークン MFA をサポートします。Amazon Cognito はハードウェアベースの MFA をサポートしていません。
1. TOTP を設定していないユーザーに対してユーザープールが TOTP を必要とする場合、ユーザーはワンタイムアクセストークンを受け取り、アプリはそれを使ってユーザーの TOTP MFA を有効化することができます。後続のサインイン試行は、ユーザーが追加の TOTP サインイン要素を登録するまで失敗します。
+ ユーザーが `SignUp` API オペレーションまたはマネージドログインを使用してユーザープールにサインアップすると、サインアップを完了したときに 1 回限りのトークンを受け取ります。
+ ユーザーを作成し、ユーザーが初期パスワードを設定すると、Amazon Cognito はマネージドログインからユーザーに 1 回限りのトークンを発行します。ユーザーに永続的なパスワードを設定すると、ユーザーが最初にサインインしたときに Amazon Cognito が 1 回限りのトークンを発行します。
+ Amazon Cognito は、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) または [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) API オペレーションでサインインする管理者が作成したユーザーには 1 回限りのトークンを発行しません。ユーザーが初期パスワードの設定のチャレンジに成功した後、またはユーザーに永続的なパスワードを設定すると、Amazon Cognito はすぐに MFA の設定をユーザーに要求します。
1. MFA を必須としているユーザープールのユーザーは、ワンタイムアクセストークンを既に受け取っていても、TOTP MFA を設定していない場合、MFA を設定するまでマネージドログインでサインインできません。アクセストークンの代わりに、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) または [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) に対する `MFA_SETUP` チャレンジの `session` レスポンス値を、[AssociateSoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AssociateSoftwareToken.html) リクエストで使用できます。
1. ユーザーが TOTP を設定した場合は、TOTP が後でユーザープールに対して無効にされた場合でも、その TOTP を MFA に使用できます。
1. Amazon Cognito は、HMAC-SHA1 ハッシュ関数を使用してコードを生成する認証アプリケーションからの TOTP のみを受け入れます。SHA-256 ハッシュで生成されたコードは `Code mismatch` エラーを返します。
## ユーザーの TOTP MFA の設定
ユーザーが最初にサインインすると、アプリはワンタイムアクセストークンを使用して TOTP プライベートキーを生成し、テキスト形式または QR コード形式でユーザーに提示します。ユーザーは Authenticator アプリケーションを設定し、その後のサインイン試行の TOTP を提供します。アプリケーションまたはマネージドログインは、この TOTP を MFA チャレンジレスポンスで TOTP を Amazon Cognito に提示します。
状況によっては、マネージドログインにより、新規ユーザーに TOTP Authenticator を設定するように求めます。詳細については、「[ユーザー実行時の MFA ロジックの詳細](user-pool-settings-mfa.md#user-pool-settings-mfa-user-outcomes)」を参照してください。
**Topics**
+ [TOTP ソフトウェアトークンを関連付ける](#user-pool-settings-mfa-totp-associate-token)
+ [TOTP トークンを検証](#user-pool-settings-mfa-totp-verification)
+ [TOTP MFA でのサインイン](#user-pool-settings-mfa-totp-sign-in)
+ [TOTP トークンを削除](#user-pool-settings-mfa-totp-remove)
### TOTP ソフトウェアトークンを関連付ける
TOTP トークンを関連付けるには、ワンタイムパスワードで検証する必要のあるシークレットコードをユーザーに送信する必要があります。トークンの関連付けには 3 つのステップが必要です。
1. ユーザーが TOTP ソフトウェアトークン MFA を選択したら、[AssociateSoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AssociateSoftwareToken.html) を呼び出して、一意に生成された共有シークレットキーコードをユーザーアカウントに返します。AssociateSoftwareToken は、アクセストークンまたはセッション文字列を使用して承認できます。
1. アプリは、プライベートキーまたはプライベートキーから生成した QR コードをユーザーに提示します。ユーザーは、Google Authenticator などの TOTP 生成アプリにプライベートキーを入力する必要があります。入力するには、アプリケーションでプライベートキーから生成した QR コードをスキャンするか、手動で入力します。
1. ユーザーがキーを入力するか、Google Authenticator などの認証システムアプリケーションに QR コードをスキャンすると、アプリがコードの生成を開始します。
### TOTP トークンを検証
次に、TOTP トークンを検証します。以下のように、ユーザーからサンプルコードをリクエストし、Amazon Cognito サービスに提供して、ユーザーが TOTP コードを正常に生成していることを確認します。
1. アプリは、ユーザーが認証システムアプリケーションを適切に設定したことを示すコードの入力をユーザーに促します。
1. ユーザーの認証システムアプリケーションは、一時的なパスワードを表示します。認証システムアプリケーションは、ユーザーに与えたシークレットキーに基づいてパスワードを作成します。
1. ユーザーは一時パスワードを入力します。アプリは、`[VerifySoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifySoftwareToken.html)` API リクエストで一時パスワードを Amazon Cognito に渡します。
1. Amazon Cognito は、ユーザーに関連付けられたシークレットキーを保持し、TOTP を生成し、ユーザーが指定したシークレットキーと比較します。一致した場合は、`VerifySoftwareToken` は `SUCCESS` レスポンスを返します。
1. Amazon Cognito は TOTP 要素をユーザーに関連付けます。
1. `VerifySoftwareToken` オペレーションが `ERROR` レスポンスを返した場合は、ユーザーのクロックが正しいこと、およびリトライの最大回数を超えていないことを確認します。Amazon Cognito は、試行の前後 30 秒以内の TOTP トークンを受け入れ、マイナークロックスキューを考慮します。問題が解決したら、VerifySoftwareToken オペレーションをもう一度試してください。
### TOTP MFA でのサインイン
この時点で、ユーザーは時間ベースのワンタイムパスワードを使用したサインインを行います。以下はその手順です。
1. ユーザーはユーザー名とパスワードを入力してクライアントアプリにサインインします。
1. TOTP MFA チャレンジが呼び出され、アプリが一時パスワードを入力するプロンプトをユーザーに表示します。
1. ユーザーは、関連付けられた TOTP 生成アプリから一時パスワードを取得します。
1. ユーザーが TOTP コードをクライアントアプリに入力します。アプリは、コードを検証するよう Amazon Cognito サービスに通知します。サインインごとに、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) を呼び出して新しい TOTP 認証チャレンジに対するレスポンスを取得する必要があります。
1. Amazon Cognito によってトークンが検証されると、サインインが成功し、ユーザーは認証フローを続行します。
### TOTP トークンを削除
最後に、アプリは TOTP 設定を非アクティブ化することをユーザーに許可する必要があります。現在、ユーザーの TOTP ソフトウェアトークンを削除することはできません。ユーザーのソフトウェアトークンを置き換えるには、新しいソフトウェアトークンを関連付けて検証します。ユーザーの TOTP MFA を無効にするには、[SetUserMFAPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserMFAPreference.html) を呼び出して、MFA を使用しないか、SMS MFA のみを使用するようにユーザーを変更します。
1. MFA をリセットしたいユーザーのためのインターフェイスをアプリケーション内に作成します。このインターフェイスでユーザーにパスワードの入力を求めます。
1. Amazon Cognito が TOTP MFA チャレンジを返す場合は、ユーザーの MFA 設定を [SetUserMFAPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserMFAPreference.html) で更新します。
1. アプリで、MFA を非アクティブ化したことをユーザーに伝え、再度サインインするよう促します。
## マネージドログイン TOTP MFA 用の AWS WAF ウェブ ACL の設定
ユーザープールに関連付けられた AWS WAF ウェブ ACL があり、ウェブ ACL のルールが CAPTCHA を示している場合、マネージドログイン TOTP 登録で回復不可能なエラーが発生する可能性があります。 AWS WAF CAPTCHA ルールは、マネージドログインとクラシックホスト UI の TOTP MFA *にのみ*この効果があります。SMS MFA は影響を受けません。
CAPTCHA ルールにより、ユーザーが TOTP MFA の設定を完了できない場合、Amazon Cognito は次のエラーを表示します。
Request not allowed due to WAF captcha. (WAF captcha によりリクエストは許可されていません。)
このエラーは、 がユーザープールがバックグラウンドで行う [AssociateSoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AssociateSoftwareToken.html) および [VerifySoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifySoftwareToken.html) API リクエストに応答して CAPTCHA AWS WAF をプロンプトすると発生します。CAPTCHA アクションを含み、マネージドログインページの TOTP に影響しないルールを作成するには、ルール内の CAPTCHA アクションから `AssociateSoftwareToken` と `VerifySoftwareToken` の `x-amzn-cognito-operation-name` ヘッダー値を除外します。
次のスクリーンショットは、`x-amzn-cognito-operation-name`ヘッダー値が `AssociateSoftwareToken`または でないすべてのリクエストに CAPTCHA アクションを適用する AWS WAF ルールの例を示しています`VerifySoftwareToken`。
![\[または のx-amzn-cognito-operation-nameヘッダー値を持たないすべてのリクエストに CAPTCHA AssociateSoftwareToken アクションを適用する AWS WAF ルールのスクリーンショットVerifySoftwareToken。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-WAF-rule-TOTP.png)
AWS WAF ウェブ ACLs「」を参照してください[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)。 Amazon Cognito
# 脅威保護を備えた高度なセキュリティ
ユーザープールを作成すると、Amazon Cognito コンソールのナビゲーションメニューで **[脅威保護]** にアクセスできます。脅威保護機能をオンにして、さまざまなリスクに応じて実行されるアクションをカスタマイズできます。また、監査モードを使用して、セキュリティ緩和策を適用せずに、検出されたリスクに関するメトリクスを収集できます。監査モードの場合、脅威保護は Amazon CloudWatch にメトリクスを発行します。Amazon Cognito が脅威保護の最初のイベントを生成すると、メトリクスを確認できます。「[脅威保護メトリクスの表示](metrics-for-cognito-user-pools.md#user-pool-settings-viewing-threat-protection-metrics)」を参照してください。
脅威保護 (以前は*高度なセキュリティ機能*と呼ばれていました) は、ユーザープール内の望ましくないアクティビティをモニタリングするツールと、潜在的に悪意のあるアクティビティを自動的にシャットダウンする設定ツールのセットです。脅威保護には、標準認証オペレーション用とカスタム認証オペレーション用の異なる設定オプションがあります。例えば、追加のセキュリティ要素を設定済みのカスタム認証で、疑わしいサインインを使用したユーザーに通知を送信するが、基本的なユーザー名/パスワード認証を使用した同じリスクレベルのユーザーをブロックする場合などです。
脅威保護は、プラス機能プランで利用できます。詳細については、「[ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)」を参照してください。
以下のユーザープールオプションは、脅威保護のコンポーネントです。
**漏えいした認証情報**
ユーザーは複数のユーザーアカウントのパスワードを再利用します。Amazon Cognito の認証情報漏えい機能では、ユーザー名とパスワードの公開漏えいに関するデータを収集し、ユーザーの認証情報を漏えいした認証情報のリストと比較します。漏えいした認証情報の検出では、よく推測されるパスワードもチェックされます。ユーザープールのユーザー名とパスワードの標準認証フローで、漏えいした認証情報を確認できます。Amazon Cognito は、セキュアリモートパスワード (SRP) またはカスタム認証で漏えいした認証情報を検出しません。
漏えいした認証情報の確認を促すユーザーアクションと、それに応じて Amazon Cognito に実行してほしいアクションを選択できます。サインイン、サインアップ、パスワード変更のイベントでは、Amazon Cognito は**サインインをブロック**するか、**サインインを許可**することができます。どちらの場合も、Amazon Cognito はユーザーアクティビティログを生成し、そこでイベントに関する詳細情報を確認できます。
**詳細情報**
[漏えいした認証情報の検出の使用](cognito-user-pool-settings-compromised-credentials.md)
**アダプティブ認証**
Amazon Cognito は、ユーザーのサインインリクエストから位置情報とデバイス情報を確認し、自動応答を適用してユーザープールのユーザーアカウントを疑わしいアクティビティから保護します。ユーザーアクティビティをモニタリングし、ユーザー名パスワードと SRP、カスタム認証で検出されたリスクレベルへの応答を自動化できます。
脅威保護を有効にすると、Amazon Cognito はユーザーアクティビティにリスクスコアを割り当てます。疑わしいアクティビティには自動応答を割り当てることができます。たとえば、**MFA を義務付けたり**、**ログインをブロックしたり**、アクティビティの詳細とリスクスコアを記録したりできます。また、疑わしいアクティビティをユーザーに通知する E メールメッセージを自動的に送信して、ユーザーがパスワードのリセットやその他の自発的なアクションを実行できるようにすることもできます。
**詳細情報**
[アダプティブ認証の使用](cognito-user-pool-settings-adaptive-authentication.md)
**IP アドレスの許可リストと拒否リスト**
Amazon Cognito の脅威保護を **[フル機能]** モードで使用することで、IP アドレスの **[常にブロック]** と **[常に許可]** の例外を作成できます。**常にブロック** 例外リストの IP アドレスからのセッションは、アダプティブ認証によってリスクレベルが割り当てられておらず、ユーザープールにサインインできません。
**IP アドレスの許可リストとブロックリストについて知っておくべきこと**
+ **[常にブロック]** と **[常に許可]** は CIDR 形式で示す必要があります。例えば、24 ビットマスクを `192.0.2.0/24`、単一の IP アドレスを `192.0.2.252/32` で示します。
+ **[常にブロック]** する IP 範囲の IP アドレスを持つデバイスは、SDK ベースやマネージドログインのアプリケーションを使用してサインアップまたはサインインできませんが、サードパーティの IdP を使用してサインインできます。
+ **[常に許可]** と **[常にブロック]** のリストはトークンの更新には影響しません。
+ Amazon Cognito は、**[常に許可]** する IP 範囲のデバイスにアダプティブ認証 MFA ルールを適用しませんが、漏えいした認証情報のルールを適用します。
**ログのエクスポート**
脅威保護は、ユーザープールに対するユーザーの認証リクエストの詳細なログを記録します。これらのログには、脅威評価、ユーザー情報、ロケーションやデバイスなどのセッションメタデータが含まれます。これらのログについて、保持と分析のための外部アーカイブを作成できます。Amazon Cognito ユーザープールは、脅威保護ログを Amazon S3、CloudWatch Logs、Amazon Data Firehose にエクスポートします。詳細については、「[ユーザーイベント履歴の表示とエクスポート](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-event-user-history)」を参照してください。
**詳細情報**
[脅威保護ユーザーアクティビティログのエクスポート](exporting-quotas-and-usage.md#exporting-quotas-and-usage-user-activity)
**Topics**
+ [脅威保護に関する考慮事項と制限事項](#cognito-user-pool-threat-protection-considerations)
+ [ユーザープールで脅威保護を有効にする](#cognito-user-pool-threat-protection-activating)
+ [脅威保護の強制適用の概念](#cognito-user-pool-settings-threat-protection-threat-protection-enforcement)
+ [標準認証とカスタム認証の脅威保護](#cognito-user-pool-settings-threat-protection-threat-protection-types)
+ [脅威保護の前提条件](#cognito-user-pool-threat-protection-prerequisites)
+ [脅威保護の設定](#cognito-user-pool-settings-configure-threat-protection)
+ [漏えいした認証情報の検出の使用](cognito-user-pool-settings-compromised-credentials.md)
+ [アダプティブ認証の使用](cognito-user-pool-settings-adaptive-authentication.md)
+ [アプリケーションにおける脅威保護のためのデータ収集](user-pool-settings-viewing-threat-protection-app.md)
## 脅威保護に関する考慮事項と制限事項
**脅威保護オプションは認証フローによって異なる**
Amazon Cognito は、アダプティブ認証と、認証フローの `USER_PASSWORD_AUTH` と `ADMIN_USER_PASSWORD_AUTH` による漏えいした認証情報の検出の両方をサポートしています。`USER_SRP_AUTH` のアダプティブ認証のみを有効にできます。フェデレーティッドサインインでは脅威保護を使用できません。
**常にブロックする IP はリクエストクォータにカウントされる**
ユーザープールの **常にブロック** 例外リストの IP アドレスからのブロックされたリクエストは、ユーザープールの[リクエストレートクォータ](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#category_operations) に貢献します。
**脅威保護にはレート制限は適用されない**
一部の悪意のあるトラフィックは、分散型サービス拒否 (DDoS) 攻撃など、大量のリクエストの特徴を持っています。Amazon Cognito が受信トラフィックに適用するリスク評価はリクエストごとに行われるため、リクエストボリュームは考慮されません。大量のイベント内における個々のリクエストは、大量攻撃でのロールに関連しないアプリケーションレイヤーの理由で、リスクスコアと自動レスポンスを受け取る場合があります。ユーザープールにボリューメトリック攻撃に対する防御を実装するには、 AWS WAF ウェブ ACLs を追加します。詳細については、「[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)」を参照してください。
**脅威保護は M2M リクエストには影響しません**
クライアント認証情報の付与は、ユーザーアカウントに接続しないマシンツーマシン (M2M) 認可を目的としています。脅威保護は、ユーザープール内のユーザーアカウントとパスワードのみをモニタリングします。M2M アクティビティでセキュリティ機能を実装するには、リクエストレートとコンテンツをモニタリング AWS WAF するための の機能を検討してください。詳細については、「[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)」を参照してください。
## ユーザープールで脅威保護を有効にする
------
#### [ Amazon Cognito user pools console ]
**ユーザープールで脅威保護を有効にするには**
1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。
1. **[User Pools]** (ユーザープール) を選択します。
1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。
1. まだ有効にしていない場合は、**[設定]**メニューからプラス機能プランを有効にします。
1. **[脅威保護]** メニューを選択し、**[アクティブ化]** を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
------
#### [ API ]
[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストで、機能プランをプラスに設定します。次のリクエスト本文の部分的な例では、脅威保護をフル機能モードに設定しています。完全なリクエストの例については、「[例](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#API_CreateUserPool_Examples)」を参照してください。
```
"UserPoolAddOns": {
"AdvancedSecurityMode": "ENFORCED"
}
```
------
脅威保護は、アカウント乗っ取りの兆候がないかについてユーザーオペレーションをモニタリングし、影響を受けるユーザーアカウントのセキュリティ保護に自動的に応答する機能の集合語です。脅威保護設定は、ユーザーが標準認証フローとカスタム認証フローでサインインするときに適用できます。
脅威保護は、ユーザーのサインイン、サインアウト、その他のアクティビティを詳細に記録する[ログを生成](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-event-user-history)します。これらのログは、サードパーティーのシステムにエクスポートできます。詳細については、「[ユーザーイベント履歴の表示とエクスポート](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-event-user-history)」を参照してください。
## 脅威保護の強制適用の概念
脅威保護は、ユーザープールがユーザーアクティビティをモニタリングし、リスクレベルを割り当て、ログを生成する*監査のみ*モードで開始されます。ベストプラクティスとして、*フル機能モード*を有効にする前に、監査のみモードで 2 週間以上実行します。フル機能モードには、検出された危険なアクティビティと漏えいしたパスワードに対する一連の自動応答が含まれます。監査のみモードでは、Amazon Cognito が実行している脅威評価をモニタリングできます。また、擬陽性と陰性について機能をトレーニングする[フィードバックを提供](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-feedback)することもできます。
ユーザープールレベル、および個々のアプリケーションクライアントのレベルで、すべてのアプリケーションクライアントをカバーするように脅威保護の強制適用を設定できます。アプリケーションクライアント脅威保護の設定は、ユーザープールの設定を上書きします。アプリケーションクライアントで脅威保護を設定するには、Amazon Cognito コンソールでユーザープールの **[アプリケーションクライアント]** メニューのアプリケーションクライアント設定に移動します。そこでは、**[クライアントレベルの設定を使用]** により、アプリケーションクライアント専用の強制適用を設定できます。
さらに、標準認証タイプとカスタム認証タイプに対して脅威保護を個別に設定できます。
## 標準認証とカスタム認証の脅威保護
脅威保護を設定する方法は、ユーザープールとアプリケーションクライアントで実行している認証のタイプによって異なります。以下の各タイプの認証には、独自の強制適用モードと自動応答を使用できます。
**標準認証**
*[標準認証]* は、ユーザー名パスワードフローとマネージドログインを使用したユーザーのサインイン、サインアウト、パスワード管理です。Amazon Cognito の脅威保護は、ユーザーがマネージドログインでサインインするときや、以下の API `AuthFlow` パラメータを使用するときに、オペレーションをモニタリングしてリスクの兆候がないか確認します。
**[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-AuthFlow)**
`USER_PASSWORD_AUTH`、`USER_SRP_AUTH`。漏えいした認証情報機能は、`USER_SRP_AUTH` サインイン時のパスワードにアクセスできず、このフローを用いてイベントのモニタリングや、イベントに対するアクションを行いません。
**[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-AuthFlow)**
`ADMIN_USER_PASSWORD_AUTH`、`USER_SRP_AUTH`。漏えいした認証情報機能は、`USER_SRP_AUTH` サインイン時のパスワードにアクセスできず、このフローを用いてイベントのモニタリングや、イベントに対するアクションを行いません。
標準認証の **[強制適用モード]** を **[監査のみ]** または **[フル機能]** に設定できます。標準認証の脅威モニタリングを無効にするには、脅威保護を **[強制適用なし]** に設定します。
**カスタム認証**
*カスタム認証*は、[カスタムチャレンジ Lambda トリガー](user-pool-lambda-challenge.md)によるユーザーサインインです。マネージドログインではカスタム認証を実行できません。Amazon Cognito 脅威保護は、`InitiateAuth` および `AdminInitiateAuth` の API `AuthFlow` パラメータ `CUSTOM_AUTH` を使用してサインインするときに、リスクの指標についてオペレーションをモニタリングします。
カスタム認証の **[強制適用モード]** は、**[監査のみ]**、**[フル機能]**、または **[強制適用なし]** に設定できます。**[強制適用なし]** オプションは、脅威保護の他の機能に影響を与えることなく、カスタム認証の脅威モニタリングを無効にします。
## 脅威保護の前提条件
開始するには、以下が必要です。
+ アプリクライアントを持つユーザープール。詳細については、「[ユーザープールの開始方法](getting-started-user-pools.md)」を参照してください。
+ Amazon Cognito コンソールで多要素認証 (MFA) を **[Optional]** (オプション) に設定して、リスクに基づくアダプティブ認証機能を使用する。詳細については、「[ユーザープールに MFA を追加します](user-pool-settings-mfa.md)」を参照してください。
+ 通知に E メールを使用している場合は、[Amazon SES コンソール](https://console.aws.amazon.com/ses/home)に移動して、通知 E メールで使用する E メールアドレスまたはドメインの設定と検証を実行します。Amazon SES の詳細については、「[Amazon SES での ID の検証](https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html)」を参照してください。
## 脅威保護の設定
ユーザープールの脅威保護を設定するには、次の手順に従います。
**注記**
Amazon Cognito ユーザープールコンソールでアプリケーションクライアント別の脅威保護設定をセットアップするには、**[アプリケーションクライアント]** メニューでアプリケーションクライアントを選択し、**[クライアントレベルの設定を使用]** を選択します。
------
#### [ AWS マネジメントコンソール ]
**ユーザープールの脅威保護を設定するには**
1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。
1. **[User Pools]** (ユーザープール) を選択します。
1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。
1. **[脅威保護]** メニューを選択し、**[アクティブ化]** を選択します。
1. 設定する脅威保護方法を、**標準認証とカスタム認証**から選択します。カスタム認証と標準認証にはさまざまな強制適用モードを設定できますが、それらは**フル機能**モードでの自動応答の設定を共有します。
1. **[Edit]** (編集) を選択します。
1. **[強制適用モード]** を選択します。検出されたリスクへの対応をすぐに開始するには、**[フル機能]** を選択し、漏えいした認証情報とアダプティブ認証への自動レスポンスを設定します。ユーザーレベルのログと CloudWatch で情報を収集するには、**[監査のみ]** を選択します。
アクションを有効にする前の 2 週間、脅威保護を監査モードにしておくことをお勧めします。この間に、Amazon Cognito は、アプリケーションユーザーの使用パターンを学習でき、イベントフィードバックを提供してレスポンスを調整できます。
1. **[Audit only]** (監査のみ) を選択した場合、**[Save changes]** (変更の保存) を選択してください。**[Full function]** (完全な機能) を選択した場合:
1. **侵害された認証情報**への応答は、 **[Custom]** (カスタム) アクションの実行または使用、または **[Cognito defaults]** (Cognito デフォルト) を選択します。**Cognito デフォルト**では、
1. **サインイン**,**サインアップ**, および**パスワードの変更時**に、侵害された認証情報を検出します。
1. 侵害された認証情報は、**[Block sign-in]** (サインインをブロックする) で応答します。
1. **[漏えいした認証情報]** で **[カスタム]** アクションを選択した場合、Amazon Cognito で **[イベントの検出]** に使用するユーザープールアクションと、Amazon Cognito で実行する **[漏えいした認証情報に関する応答]** を選択します。侵害された認証情報による**サインインをブロック**または**サインインを許可**することができます。
1. **[Adaptive authentication]** (アダプティブ認証) で、悪意のあるサインイン試行への応答方法を選択します。**[Custom]** (カスタム) アクションを実行または使用、または悪意のあるアクティビティの疑いに対応するために **[Cognito defaults]** (Cognito デフォルト) を選択します。**[Cognito defaults]** (Cognito デフォルト) を選択した場合、Amazon Cognito はすべてのリスクレベルでサインインをブロックし、ユーザーに通知しません。
1. **[Adaptive authentication]** (アダプティブ認証) で、 **[Custom]** (カスタム) アクションを選択した場合、重要度レベルに基づいて検出されたリスクに対して、Amazon Cognito で実行する **[Automatic risk response]** (自動リスク対応) アクションを選択します。リスクのレベルに応じて対応を割り当てる場合、より高いレベルのリスクに対して、より制限の少ない対応を割り当てることはできません。リスクレベルには、次の対応を割り当てることができます。
1. **サインインを許可する** - 予防策をとりません。
1. **MFA のオプション** - ユーザーが MFA を設定している場合、Amazon Cognito はサインイン時に常に SMS またはタイムベースドワンタイムパスワード (TOTP) の追加要素を提供するようユーザーに要求します。ユーザーに MFA が設定されていない場合は、通常どおりサインインを続行できます。
1. **MFA を要求** - ユーザーが MFA を設定している場合、Amazon Cognito はサインイン時に常に SMS または TOTP ファクターの追加要素の提供を要求します。ユーザーに MFA が設定されていない場合、Amazon Cognito は MFA を設定するよう促します。ユーザーに MFA を自動要求する前に、SMS MFA の電話番号をキャプチャするメカニズム、または TOTP MFA の認証アプリケーションを登録するメカニズムを、お客様のアプリケーションに設定してください。
1. **サインインをブロックする** - ユーザーがサインインできないようにします。
1. **ユーザーに通知する** - Amazon Cognito が検出したリスクと応答に関する情報を E メールでユーザーに送信します。送信するメッセージの E メールメッセージテンプレートをカスタマイズできます。
1. 前の手順で **[Notify user]** (ユーザーに通知する) を選択した場合、アダプティブ認証に使用する E メール配信設定と E メールメッセージテンプレートをカスタマイズできます。
1. **[E メール設定]** で、アダプティブ認証に使用する **[SES リージョン]**、**[送信元の E メールアドレス]**、**[送信者の名前]**、**[返信先 E メールアドレス]** を選択します。ユーザープールの E メールメッセージを Amazon Simple Email Service の統合方法の詳細については、「[Amazon Cognito ユーザープールに使用する E メールの設定](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-email.html)」を参照してください。
![\[ユーザーイベント履歴\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-advanced-security-ses-notification.png)
1. **[Email templates]** (E メールテンプレート) を展開して、E メールメッセージの HTML とプレーンテキストバージョンの両方でアダプティブ認証通知をカスタマイズします。E メールメッセージテンプレートの詳細については、「[メッセージテンプレート](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-message-templates)」を参照してください。
1. **[IP アドレスの例外]** を展開して、脅威保護のリスク評価に関係なく、常に許可またはブロックする IPv4 または IPv6 アドレス範囲の **[常に許可]** または **[常にブロック]** のリストを作成します。[CIDR 表記](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation) で IP アドレスの範囲を指定します (例: 192.168.100.0/24)。
1. **[Save changes]** (変更の保存) をクリックします。
------
#### [ API (user pool) ]
ユーザープールの脅威保護を設定するには、`UserPoolId` パラメータを含むが、`ClientId` パラメータを含まない [SetRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetRiskConfiguration.html) API リクエストを送信します。ユーザープール用のリクエスト本文の例を次に示します。このリスク設定は、リスクの重大度に基づいて一連のアクションをエスカレートし、すべてのリスクレベルでユーザーに通知します。これは、漏えいした認証情報ブロックをサインアップオペレーションに適用します。
この設定を適用するには、別の [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストの `ENFORCED` に `AdvancedSecurityMode` を設定する必要があります。この例における `{username}` のようなプレースホルダーテンプレートの詳細については、「[MFA、認証、検証、招待メッセージの設定](cognito-user-pool-settings-message-customizations.md)」を参照してください。
```
{
"AccountTakeoverRiskConfiguration": {
"Actions": {
"HighAction": {
"EventAction": "MFA_REQUIRED",
"Notify": true
},
"LowAction": {
"EventAction": "NO_ACTION",
"Notify": true
},
"MediumAction": {
"EventAction": "MFA_IF_CONFIGURED",
"Notify": true
}
},
"NotifyConfiguration": {
"BlockEmail": {
"Subject": "You have been blocked for suspicious activity",
"TextBody": "We blocked {username} at {login-time} from {ip-address}."
},
"From": "admin@example.com",
"MfaEmail": {
"Subject": "Suspicious activity detected, MFA required",
"TextBody": "Unexpected sign-in from {username} on device {device-name}. You must use MFA."
},
"NoActionEmail": {
"Subject": "Suspicious activity detected, secure your user account",
"TextBody": "We noticed suspicious sign-in activity by {username} from {city}, {country} at {login-time}. If this was not you, reset your password."
},
"ReplyTo": "admin@example.com",
"SourceArn": "arn:aws:ses:us-west-2:123456789012:identity/admin@example.com"
}
},
"CompromisedCredentialsRiskConfiguration": {
"Actions": {
"EventAction": "BLOCK"
},
"EventFilter": [ "SIGN_UP" ]
},
"RiskExceptionConfiguration": {
"BlockedIPRangeList": [ "192.0.2.0/24","198.51.100.0/24" ],
"SkippedIPRangeList": [ "203.0.113.0/24" ]
},
"UserPoolId": "us-west-2_EXAMPLE"
}
```
------
#### [ API (app client) ]
アプリケーションクライアントの脅威保護を設定するには、`UserPoolId` パラメータと `ClientId` パラメータを含む [SetRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetRiskConfiguration.html) API リクエストを送信します。次に、アプリケーションクライアント用のリクエストの本文の例を示します。このリスク設定は、ユーザープール設定よりも重大であり、高リスクのエントリをブロックします。また、漏えいした認証情報ブロックを適用して、サインアップ、サインイン、パスワードリセットの各オペレーションも行います。
この設定を適用するには、別の [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストの `ENFORCED` に `AdvancedSecurityMode` を設定する必要があります。この例における `{username}` のようなプレースホルダーテンプレートの詳細については、「[MFA、認証、検証、招待メッセージの設定](cognito-user-pool-settings-message-customizations.md)」を参照してください。
```
{
"AccountTakeoverRiskConfiguration": {
"Actions": {
"HighAction": {
"EventAction": "BLOCK",
"Notify": true
},
"LowAction": {
"EventAction": "NO_ACTION",
"Notify": true
},
"MediumAction": {
"EventAction": "MFA_REQUIRED",
"Notify": true
}
},
"NotifyConfiguration": {
"BlockEmail": {
"Subject": "You have been blocked for suspicious activity",
"TextBody": "We blocked {username} at {login-time} from {ip-address}."
},
"From": "admin@example.com",
"MfaEmail": {
"Subject": "Suspicious activity detected, MFA required",
"TextBody": "Unexpected sign-in from {username} on device {device-name}. You must use MFA."
},
"NoActionEmail": {
"Subject": "Suspicious activity detected, secure your user account",
"TextBody": "We noticed suspicious sign-in activity by {username} from {city}, {country} at {login-time}. If this was not you, reset your password."
},
"ReplyTo": "admin@example.com",
"SourceArn": "arn:aws:ses:us-west-2:123456789012:identity/admin@example.com"
}
},
"ClientId": "1example23456789",
"CompromisedCredentialsRiskConfiguration": {
"Actions": {
"EventAction": "BLOCK"
},
"EventFilter": [ "SIGN_UP", "SIGN_IN", "PASSWORD_CHANGE" ]
},
"RiskExceptionConfiguration": {
"BlockedIPRangeList": [ "192.0.2.1/32","192.0.2.2/32" ],
"SkippedIPRangeList": [ "192.0.2.3/32","192.0.2.4/32" ]
},
"UserPoolId": "us-west-2_EXAMPLE"
}
```
------
# 漏えいした認証情報の検出の使用
Amazon Cognito は、ユーザーのユーザー名とパスワードが他の場所で侵害されたかどうかを検出できます。これは、ユーザーが複数のサイトで認証情報を再利用したり、安全でないパスワードを使用したりするときに発生します。Amazon Cognito は、マネージドログインと Amazon Cognito API で、ユーザー名とパスワードでサインインする[ローカルユーザー](cognito-terms.md#terms-localuser)をチェックします。
Amazon Cognito コンソールの **[脅威保護]** メニューで、**[漏えいした認証情報]** を設定できます。**[Event detection]** (イベント検出) を設定して、侵害された認証情報を監視するユーザーイベントを選択します。**[Compromised credentials responses]** (侵害された認証情報の応答) を設定し、侵害された認証情報が検出された場合にユーザーを許可するかブロックするかを選択します。Amazon Cognito は、サインイン時、サインアップ時、パスワード変更時に侵害された認証情報をチェックすることができます。
**[Allow sign-in]** (サインインを許可する) を選択する場合、Amazon CloudWatch Logs を確認して、Amazon Cognito がユーザーイベントに対して行う評価を監視できます。詳細については、「[脅威保護メトリクスの表示](metrics-for-cognito-user-pools.md#user-pool-settings-viewing-threat-protection-metrics)」を参照してください。**[Block sign-in]** (サインインをブロックする) を選択する場合、Amazon Cognito は、侵害された認証情報を使用するユーザーによるサインインを防止します。Amazon Cognito がユーザーのサインインをブロックすると、ユーザーの [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserType.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserType.html) が `RESET_REQUIRED` に設定されます。`RESET_REQUIRED` ステータスのユーザーは、再度サインインする前にパスワードを変更する必要があります。
漏えいした認証情報では、次のユーザーアクティビティのパスワードをチェックできます。
**サインアップ**
ユーザープールは、ユーザーが [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) オペレーションおよびマネージドログインのサインアップページで送信したパスワードをチェックし、漏えいの兆候を確認します。
**サインイン**
ユーザープールは、ユーザーがパスワードベースのサインインで送信したパスワードをチェックし、漏えいの兆候を確認します。Amazon Cognito は、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) の `ADMIN_USER_PASSWORD_AUTH` フロー、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) の `USER_PASSWORD_AUTH` フロー、および両方の `USER_AUTH` フローの `PASSWORD` オプションを確認できます。
現在 Amazon Cognito では、Secure Remote Password (SRP) フローでのサインイン操作に対する侵害された認証情報のチェックが行われません。SRP はサインイン時にハッシュ化されたパスワード証明書を送信します。Amazon Cognito は内部でパスワードにアクセスできないため、クライアントがプレーンテキストで渡したパスワードのみを評価できます。
**パスワードのリセット**
ユーザープールは、セルフサービスのパスワードリセットオペレーション [ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html) を使用して、新規ユーザーのパスワードを設定するオペレーションにおける漏えいの兆候をチェックします。このオペレーションに必要なコードは、[ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) と [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) によって生成されます。
漏えいした認証情報では、[AdminSetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) で設定された仮パスワードや永続的な管理者設定パスワードをチェックしません。ただし、仮パスワードの場合、ユーザープールは [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) と [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) で `NEW_PASSWORD_REQUIRED` チャレンジへのレスポンスのパスワードをチェックします。
漏洩した認証情報の保護をユーザープールに追加するには、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。
# アダプティブ認証の使用
アダプティブ認証では、リスクレベルの上昇に対応して、疑わしいサインインをブロックする、または 2 番目の要素認証を追加するようにユーザープールを設定できます。Amazon Cognito はサインインの試行ごとに、サインインリクエストが侵害されたソースからのものである可能性についてリスクスコアを生成します。このリスクスコアは、アプリケーションが提供するデバイスとユーザーの要因、および Amazon Cognito がリクエストから派生するその他の要因に基づいています。Amazon Cognito によるリスク評価に影響する要素には、IP アドレスとユーザーエージェント、ユーザーエージェント、および他のサインイン試行からの地理的な距離があります。アダプティブ認証は、Amazon Cognito がユーザーのセッションでリスクを検出し、ユーザーがまだ MFA メソッドを選択していない場合に、ユーザープール内のユーザーに対して多要素認証 (MFA) を有効にする、または多要素認証 (MFA) を要求することができます。ユーザーに MFA を有効にすると、アダプティブ認証の設定方法にかかわらず、認証中に必ず 2 つ目の要素を提供または設定するように求めるチャレンジが常に表示されます。ユーザーの観点から見ると、アプリは MFA の設定を支援し、また、オプションとして、Amazon Cognito では、ユーザーが追加の要素を設定するまで、ユーザーが再度サインインできないようにすることもできます。
Amazon Cognito は、サインイン試行、試行のリスクレベル、および失敗したチャレンジに関するメトリクスを Amazon CloudWatch にパブリッシュします。詳細については、「[脅威保護メトリクスの表示](metrics-for-cognito-user-pools.md#user-pool-settings-viewing-threat-protection-metrics)」を参照してください。
アダプティブ認証をユーザープールに追加するには、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。
**Topics**
+ [アダプティブ認証の概要](#security-cognito-user-pool-settings-adaptive-authentication-overview)
+ [API リクエストへのユーザーデバイスおよびセッションデータの追加](#user-pool-settings-adaptive-authentication-device-fingerprint)
+ [ユーザーイベント履歴の表示とエクスポート](#user-pool-settings-adaptive-authentication-event-user-history)
+ [イベントフィードバックを提供します](#user-pool-settings-adaptive-authentication-feedback)
+ [通知メッセージの送信](#user-pool-settings-adaptive-authentication-messages)
## アダプティブ認証の概要
Amazon Cognito コンソールの **[脅威保護]** メニューで、アダプティブ認証の設定を選択できます。これには、リスクレベル別に実行するアクション、ユーザーへの通知メッセージのカスタマイズなどが含まれます。すべてのアプリケーションクライアントにグローバルな脅威保護設定を割り当てる一方、個々のアプリケーションクライアントにはクライアントレベルの設定を適用できます。
Amazon Cognito アダプティブ認証は、各ユーザーセッションに**「高」**、**「中」**、**「低」**、**「リスクなし」**のいずれかのリスクレベルを割り当てます。
**[Enforcement method]** (強制実行メソッド) を **[Audit-only]** (監査専用) から **[Full-function]** (完全な機能) に変更する場合は、選択肢を慎重に検討してください。リスクレベルに適用する自動応答は、Amazon Cognito が同じ特性を持つ後続のユーザーセッションに割り当てるリスクレベルに影響します。例えば、Amazon Cognito が最初にリスクが高いと評価したユーザーセッションに何もしないか、**[Allow]** (許可) を選択すると、Amazon Cognito では同様のセッションのリスクが低いと見なします。
**リスクレベルごとに、以下のオプションから選択できます。**
| オプション | アクション |
| --- | --- |
| 許可 | ユーザーは、追加要素なしでサインインできます。 |
| オプションの MFA | 第 2 要素を設定しているユーザーは、サインインするために第 2 要素のチャレンジを完了する必要があります。SMS の電話番号と TOTP ソフトウェアトークンが利用可能な第 2 要素です。2 番目の要素が設定されていないユーザーは、1 つの認証情報のみでサインインできます。 |
| MFA が必要 | 第 2 要素を設定しているユーザーは、サインインするために第 2 要素のチャレンジを完了する必要があります。Amazon Cognito は、第 2 要素が設定されていないユーザーのサインインをブロックします。 |
| ブロック | Amazon Cognito は、指定されたリスクレベルですべてのサインイン試行をブロックします。 |
**注記**
SMS を 2 番目の認証要素として使用するために電話番号を検証する必要はありません。
## API リクエストへのユーザーデバイスおよびセッションデータの追加
API を使用してユーザーのサインアップ、サインイン、パスワードのリセットを行う際に、ユーザーのセッションに関する情報を収集し、Amazon Cognito の脅威保護に渡すことができます。この情報には、ユーザーの IP アドレスと一意のデバイス識別子が含まれます。
ユーザーと Amazon Cognito の間に、プロキシサービスやアプリケーションサーバーなど、中間ネットワークデバイスがある場合があります。ユーザーのコンテキストデータを収集して Amazon Cognito に渡すことで、アダプティブ認証がサーバーやプロキシではなく、ユーザーエンドポイントの特性に基づいてリスクを計算できます。クライアント側アプリが Amazon Cognito API オペレーションを直接呼び出す場合、アダプティブ認証は送信元 IP アドレスを自動的に記録します。ただし、デバイスのフィンガープリントも収集しない限り、`user-agent` などの他のデバイス情報は記録されません。
このデータを Amazon Cognito コンテキストデータ収集ライブラリで生成して、Amazon Cognito の脅威保護に送信するには、[ContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ContextDataType.html) パラメータと [UserContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserContextDataType.html) パラメータを使用します。コンテキストデータ収集ライブラリは AWS SDKs に含まれています。詳細については、「[Amazon Cognito の認証と認可を、ウェブアプリケーションとモバイルアプリケーションに統合する](cognito-integrate-apps.md)」を参照してください。プラス機能プランを使用している場合は、`ContextData` を送信できます。詳細については、「[脅威保護の設定](cognito-user-pool-settings-threat-protection.md#cognito-user-pool-settings-configure-threat-protection)」を参照してください。
アプリケーションサーバーから以下の Amazon Cognito 認証 API オペレーションを呼び出す場合、`ContextData` パラメータにユーザーのデバイスの IP を渡します。また、サーバー名、サーバーパス、およびエンコードされたデバイスフィンガープリントデータを渡します。
+ [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html)
+ [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html)
Amazon Cognito の認証されていない API オペレーションを呼び出すと、Amazon Cognito の脅威保護に `UserContextData` を送信できます。このデータには、`EncodedData` パラメータのデバイスフィンガープリントが含まれます。また、次の条件を満たす場合、`UserContextData` に `IpAddress` パラメータを送信できます。
+ ユーザープールをプラス機能プランで使用しています。詳細については、「[ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)」を参照してください。
+ アプリクライアントにはクライアントシークレットがあります。詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。
+ アプリクライアントで **[Accept additional user context data]** (追加のユーザーコンテキストデータを受け入れる) をアクティブ化しました。詳細については、「[追加のユーザーコンテキストデータの受け入れ (AWS マネジメントコンソール)](#user-pool-settings-adaptive-authentication-accept-user-context-data)」を参照してください。
アプリは、以下の Amazon Cognito の認証されていない API オペレーションで、`UserContextData` パラメータにエンコードされたデバイスフィンガープリントデータとユーザーのデバイスの IP アドレスを入力できます。
+ [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html)
+ [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html)
+ [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html)
+ [ConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html)
+ [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html)
+ [ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html)
+ [ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html)
### 追加のユーザーコンテキストデータの受け入れ (AWS マネジメントコンソール)
ユーザープールは **[Accept additional user context data]** (追加のユーザーコンテキストデータを受け入れる) 機能をアクティブ化すると、`UserContextData` パラメータで IP アドレスを受け入れます。次の場合は、この機能をアクティブ化する必要はありません。
+ ユーザーは、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) のような認証された API オペレーションでのみサインインし、`ContextData` パラメータを使用します。
+ 認証されていない API オペレーションから、IP アドレスではなく、デバイスのフィンガープリントのみを Amazon Cognito の脅威保護に送信します。
Amazon Cognito コンソールでアプリクライアントを次のように更新し、追加のユーザーコンテキストデータのサポートを追加します。
1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。
1. ナビゲーションペインで [**ユーザープールの管理**] を選択してから、編集するユーザープールを選択します。
1. **[アプリケーションクライアント]** メニューを選択します。
1. アプリケーションクライアントを選択または作成します。詳細については、「[ユーザープールのアプリクライアントの設定](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-idp-settings.html)」を参照してください。
1. **[App client information]** (アプリのクライアント情報) コンテナから **[Edit]** (編集) を選択します。
1. アプリクライアントの **[Advanced authentication settings]** (詳細な認証設定) で、**[Accept additional user context data]** (追加のユーザーコンテキストデータを受け入れる) を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
Amazon Cognito API でユーザーコンテキストデータを受け入れるようにアプリクライアントを設定するには、[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) または [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) リクエストで `EnablePropagateAdditionalUserContextData` を `true` に設定します。ウェブまたはモバイルアプリで脅威保護を使用する方法については、「[アプリケーションにおける脅威保護のためのデータ収集](user-pool-settings-viewing-threat-protection-app.md)」を参照してください。アプリがサーバーから Amazon Cognito を呼び出すときに、クライアント側からユーザーコンテキストデータを収集します。以下は、JavaScript SDK メソッド `getData` 使用する例です。
```
var EncodedData = AmazonCognitoAdvancedSecurityData.getData(username, userPoolId, clientId);
```
アダプティブ認証を使用するようにアプリを設計する場合は、最新の Amazon Cognito SDK をアプリに組み込むことをお勧めします。SDK の最新バージョンでは、デバイス ID、モデル、およびタイムゾーンなどのデバイスフィンガープリント情報を収集します。Amazon Cognito SDK の詳細については、「[ユーザープール SDK のインストール](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-sdk-links.html)」を参照してください。Amazon Cognito の脅威保護では、アプリケーションが正しい形式で送信したイベントのみを保存し、リスクスコアを割り当てます。Amazon Cognito がエラーレスポンスを返す場合は、リクエストに有効なシークレットハッシュが含まれていることと、`IPaddress` パラメータが、有効な IPv4 または IPv6 アドレスであることを確認します。
**`ContextData` および `UserContextData` リソース**
+ AWS Amplify Android 用 SDK: [GetUserContextData](https://github.com/aws-amplify/aws-sdk-android/blob/main/aws-android-sdk-cognitoidentityprovider/src/main/java/com/amazonaws/mobileconnectors/cognitoidentityprovider/CognitoUserPool.java#L626)
+ AWS Amplify SDK for iOS: [userContextData](https://github.com/aws-amplify/aws-sdk-ios/blob/d3cd4fa0086b526f2f5c9c6c58880c9da7004c66/AWSCognitoIdentityProviderASF/AWSCognitoIdentityProviderASF.m#L21)
+ JavaScript: [amazon-cognito-advanced-security-data.min.js](https://amazon-cognito-assets.us-east-1.amazoncognito.com/amazon-cognito-advanced-security-data.min.js)
## ユーザーイベント履歴の表示とエクスポート
脅威保護を有効にすると、Amazon Cognito は、ユーザーによる認証イベントごとにログを生成します。デフォルトでは、Amazon Cognito コンソールの **[ユーザー]** メニューまたは [AdminListUserAuthEvents](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListUserAuthEvents.html) API オペレーションを使用して、ユーザーログを表示できます。また、これらのイベントを、CloudWatch Logs、Amazon S3、Amazon Data Firehose などの外部システムにエクスポートすることもできます。エクスポート機能を使用すると、アプリケーション内のユーザーアクティビティに関するセキュリティ情報について、独自のセキュリティ分析システムにアクセスさせることが容易になります。
**Topics**
+ [ユーザーイベント履歴の表示 (AWS マネジメントコンソール)](#user-pool-settings-adaptive-authentication-event-user-history-console)
+ [ユーザーイベント履歴の表示 (API/CLI)](#user-pool-settings-adaptive-authentication-event-user-history-api-cli)
+ [ユーザー認証イベントのエクスポート](#user-pool-settings-adaptive-authentication-event-user-history-exporting)
### ユーザーイベント履歴の表示 (AWS マネジメントコンソール)
ユーザーのサインイン履歴を表示するには、Amazon Cognito コンソールの **[ユーザー]** メニューでユーザーを選択できます。Amazon Cognito は、ユーザーイベント履歴を 2 年間保持します。
![\[ユーザーイベント履歴\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-advanced-security-event-history.png)
各サインインイベントにはイベント ID があります。イベントには、場所、デバイスの詳細、およびリスク検出結果など、対応するコンテキストデータもあります。
また、イベント ID を Amazon Cognito がイベントを記録した時点で発行したトークンと関連付けることができます。ID とアクセストークンには、ペイロードにこのイベント ID が含まれます。Amazon Cognito はまた、更新トークンの使用を元のイベント ID に関連付けます。元のイベント ID は、Amazon Cognito トークンの発行につながったサインインイベントのイベント ID まで追跡できます。システム内のトークンの使用は、特定の認証イベントまで追跡できます。詳細については、「[ユーザープール JSON ウェブトークン (JWT) の理解](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)」を参照してください。
### ユーザーイベント履歴の表示 (API/CLI)
Amazon Cognito API オペレーション [AdminListUserAuthEvents](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListUserAuthEvents.html) を使用して、または [admin-list-user-auth-events](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-list-user-auth-events.html) を使用して AWS Command Line Interface (AWS CLI) を使用して、ユーザーイベント履歴をクエリできます。
------
#### [ AdminListUserAuthEvents request ]
次の `AdminListUserAuthEvents` 用のリクエスト本文は、1 人のユーザーの最新のアクティビティログを返します。
```
{
"UserPoolId": "us-west-2_EXAMPLE",
"Username": "myexampleuser",
"MaxResults": 1
}
```
------
#### [ admin-list-user-auth-events request ]
次の `admin-list-user-auth-events` 用のリクエストは、1 人のユーザーの最新のアクティビティログを返します。
```
aws cognito-idp admin-list-user-auth-events --max-results 1 --username myexampleuser --user-pool-id us-west-2_EXAMPLE
```
------
#### [ Response ]
Amazon Cognito は、両方のリクエストに同じ JSON レスポンス本文を返します。以下は、リスク要因が含まれていないことが検出されたマネージドログインのサインインイベントのレスポンス例です。
```
{
"AuthEvents": [
{
"EventId": "[event ID]",
"EventType": "SignIn",
"CreationDate": "[Timestamp]",
"EventResponse": "Pass",
"EventRisk": {
"RiskDecision": "NoRisk",
"CompromisedCredentialsDetected": false
},
"ChallengeResponses": [
{
"ChallengeName": "Password",
"ChallengeResponse": "Success"
}
],
"EventContextData": {
"IpAddress": "192.168.2.1",
"DeviceName": "Chrome 125, Windows 10",
"Timezone": "-07:00",
"City": "Bellevue",
"Country": "United States"
}
}
],
"NextToken": "[event ID]#[Timestamp]"
}
```
------
### ユーザー認証イベントのエクスポート
脅威保護から外部システムにユーザーイベントをエクスポートするようにユーザープールを設定します。サポートされている外部システムである Amazon S3、CloudWatch Logs、Amazon Data Firehose は、送信または取得するデータの AWS 請求にコストを追加する可能性があります。詳細については、「[脅威保護ユーザーアクティビティログのエクスポート](exporting-quotas-and-usage.md#exporting-quotas-and-usage-user-activity)」を参照してください。
------
#### [ AWS マネジメントコンソール ]
1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。
1. **[User Pools]** (ユーザープール) を選択します。
1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。
1. **[ログストリーミング]** メニューを選択します。**[Edit]** (編集) を選択します。
1. **[ログ記録ステータス]** で、**[ユーザーアクティビティログのエクスポートをアクティブ化]** の横にあるチェックボックスをオンにします。
1. **[ログ記録先]** で、ログを処理する AWS のサービス を **[CloudWatch ロググループ]**、**[Amazon Data Firehose ストリーム]**、または **[S3 バケット]** の中から選択します。
1. 選択すると、対応するリソースタイプがリソースセレクターに入力されます。リストからロググループ、ストリーム、またはバケットを選択します。**[作成]** ボタンを選択して、選択したサービスの AWS マネジメントコンソール に移動し、新しいリソースを作成することもできます。
1. **[変更を保存]** を選択します。
------
#### [ API ]
ユーザーアクティビティログの送信先のタイプを 1 つ選択します。
以下は、Firehose ストリームをログの送信先として設定する `SetLogDeliveryConfiguration` リクエスト本文の例です。
```
{
"LogConfigurations": [
{
"EventSource": "userAuthEvents",
"FirehoseConfiguration": {
"StreamArn": "arn:aws:firehose:us-west-2:123456789012:deliverystream/example-user-pool-activity-exported"
},
"LogLevel": "INFO"
}
],
"UserPoolId": "us-west-2_EXAMPLE"
}
```
以下は、Amazon S3 バケットをログの送信先として設定する `SetLogDeliveryConfiguration` リクエスト本文の例です。
```
{
"LogConfigurations": [
{
"EventSource": "userAuthEvents",
"S3Configuration": {
"BucketArn": "arn:aws:s3:::amzn-s3-demo-logging-bucket"
},
"LogLevel": "INFO"
}
],
"UserPoolId": "us-west-2_EXAMPLE"
}
```
以下は、CloudWatch ロググループをログの送信先として設定する `SetLogDeliveryConfiguration` リクエスト本文の例です。
```
{
"LogConfigurations": [
{
"EventSource": "userAuthEvents",
"CloudWatchLogsConfiguration": {
"LogGroupArn": "arn:aws:logs:us-west-2:123456789012:log-group:DOC-EXAMPLE-LOG-GROUP"
},
"LogLevel": "INFO"
}
],
"UserPoolId": "us-west-2_EXAMPLE"
}
```
------
## イベントフィードバックを提供します
イベントフィードバックは、リアルタイムでリスクの評価に反映され、リスク評価アルゴリズムを経時的に向上させます。ユーザーは、Amazon Cognito コンソールおよび API を使用して、サインイン試行の妥当性に関するフィードバックを提供できます。
**注記**
イベントフィードバックは、Amazon Cognito が同じ特性を持つ後続のユーザーセッションに割り当てるリスクレベルに影響します。
Amazon Cognito コンソールで、**[ユーザー]** メニューからユーザーを選択し、**[イベントフィードバックを提供]** を選択します。イベントの詳細を確認して、**[Set as valid]** (有効として設定) または **[Set as invalid]** (無効として設定) できます。
コンソールでは、**[ユーザー]** メニューのユーザー詳細にサインイン履歴が一覧表示されます。エントリを選択すると、イベントを有効または無効としてマークできます。また、ユーザープール API オペレーション [AdminUpdateAuthEventFeedback](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateAuthEventFeedback.html) および AWS CLI コマンド [admin-update-auth-event-feedback](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-update-auth-event-feedback.html) を通じてフィードバックを提供することもできます。
Amazon Cognito コンソールで **[Set as valid]** (有効として設定) を選択するか、API で `valid` の `FeedbackValue` 値を指定するとき、Amazon Cognito がある程度のリスクを評価したユーザーセッションを信頼することを Amazon Cognito に伝えます。Amazon Cognito コンソールで **[Set as invalid]** (無効として設定) を選択するか、API で `invalid` の `FeedbackValue` 値を指定するとき、ユーザーセッションを信頼しないこと、または Amazon Cognito が十分に高いリスクレベルを評価したとは考えないことを Amazon Cognito に伝えます。
## 通知メッセージの送信
脅威保護により、Amazon Cognito はユーザーにリスクの高いサインイン試行を通知できます。Amazon Cognito では、サインインが有効か無効かを示すリンクを選択するようユーザーに促すこともできます。Amazon Cognito はこのフィードバックを使用して、ユーザープールのリスク検出精度を向上させます。
**注記**
Amazon Cognito は、ユーザーのアクションによって自動リスク対応 (サインインのブロック、サインインの許可、MFA をオプションに設定、または MFA を必須に設定) が生成された場合にのみ、ユーザーに通知メッセージを送信します。リクエストによっては、リスクレベルが割り当てられていても、アダプティブ認証の自動リスク対応が生成されない場合があります。このようなリクエストの場合、ユーザープールは通知を送信しません。例えば、誤ったパスワードがリスク評価とともにログに記録される場合がありますが、Amazon Cognito による対応では、アダプティブ認証ルールを適用せずに、サインインを失敗させます。
**[Automatic risk response]** (自動リスク対応) セクションで、低、中、高のリスクケースに応じて **[Notify Users]** (ユーザーに通知) を選択します。
![\[ユーザーに通知する\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-adaptive-auth.png)
Amazon Cognito は、ユーザーが E メールアドレスを検証したかどうかに関係なく、E メール通知をユーザーに送信します。
通知 E メールメッセージをカスタマイズして、これらのメッセージのプレーンテキストと HTML の両バージョンを提供できます。E メール通知をカスタマイズするには、脅威保護設定の **[アダプティブ認証メッセージ]** から **[E メールテンプレート]** を開きます。E メールテンプレートの詳細については、「[メッセージテンプレート](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-message-templates)」を参照してください。
# アプリケーションにおける脅威保護のためのデータ収集
Amazon Cognito [アダプティブ認証](cognito-user-pool-settings-adaptive-authentication.md)は、ユーザーのサインイン試行のコンテキスト詳細からアカウント乗っ取りを試みた場合のリスクレベルを評価します。Amazon Cognito の脅威保護がリスクをより正確に評価できるように、アプリケーションは API リクエストに*コンテキストデータ*を追加する必要があります。コンテキストデータは、ユーザーがユーザープールにどのように接続したかに関するコンテキスト情報を提供する、IP アドレス、ブラウザエージェント、デバイス情報、リクエストヘッダーなどの情報です。
このコンテキストを Amazon Cognito に送信するアプリケーションの主な責任は、ユーザープールへの認証リクエストの `EncodedData` パラメータです。このデータをリクエストに追加するには、この情報を自動的に生成する SDK を使用して Amazon Cognito を実装することも、このデータを収集する JavaScript、iOS、または Android 用のモジュールを実装することもできます。Amazon Cognito に直接リクエストを行う*クライアント専用*アプリケーションは AWS Amplify SDKs を実装する必要があります。中間サーバーまたは API コンポーネントを持つ*クライアントサーバー*アプリケーションは、別の SDK モジュールを実装する必要があります。
次のシナリオでは、認証フロントエンドが、追加の設定なしでユーザーコンテキストのデータ収集を管理します。
+ マネージドログインは、コンテキストデータを自動的に収集して脅威保護に送信します。
+ すべての AWS Amplify ライブラリには、認証方法に組み込まれたコンテキストデータ収集があります。
## Amplify を使用したクライアント専用アプリケーションでのユーザーコンテキストデータの送信
![\[Amplify アプリケーションでの脅威保護のためのデータ収集の概要。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/user-pools-asf-amplify-data-collection.png)
Amplify SDK は、Amazon Cognito で直接認証するモバイルクライアントをサポートします。この種類のクライアントは、Amazon Cognito パブリック API オペレーションに直接 API リクエストを行います。Amplify クライアントは、デフォルトで脅威保護のためのコンテキストデータを自動的に収集します。
JavaScript を使用した Amplify アプリケーションは例外です。ユーザーコンテキストデータを収集する [JavaScript モジュール](#user-pool-settings-viewing-threat-protection-app-additional-resources-js)を追加する必要があります。
通常、この設定のアプリケーションは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) や [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) などの認証されていない API オペレーションを使用します。[UserContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserContextDataType.html) オブジェクトは、これらのオペレーションのリスクをより正確に評価するのに役立ちます。Amplify SDK は、デバイスとセッション情報を `UserContextData` の `EncodedData` パラメータに追加します。
## クライアントサーバーアプリケーションでのコンテキストデータの収集
一部のアプリケーションには、ユーザー認証データを収集するフロントエンド層と、Amazon Cognito に認証リクエストを送信するアプリケーションバックエンド層があります。これは、マイクロサービスベースのウェブサーバーとアプリケーションの一般的なアーキテクチャです。これらのアプリケーションでは、パブリックコンテキストデータ収集ライブラリをインポートする必要があります。
![\[JavaScript での脅威保護のコンテキストデータを使用したサーバー側の認証の概要。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/user-pools-asf-non-amplify-data-collection.png)
通常、この設定のアプリケーションサーバーは、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) や [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) などの認証された API オペレーションを使用します。[ContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-ContextData) オブジェクトは、Amazon Cognito がこれらのオペレーションのリスクをより正確に評価するのに役立ちます。`ContextData` のコンテンツは、フロントエンドがサーバーに渡したエンコードされたデータと、ユーザーによる HTTP リクエストからサーバーへの追加の詳細です。HTTP ヘッダーや IP アドレスなど、これらの追加のコンテキストの詳細により、アプリケーションサーバーにユーザーの環境の特性が提供されます。
また、アプリケーションサーバーは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) や [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) などの認証されていない API オペレーションでサインインする場合もあります。[UserContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-UserContextData) オブジェクトは、これらのオペレーションにおける脅威保護のセキュリティリスク分析に役立ちます。利用可能なパブリックコンテキストデータ収集ライブラリ内のオペレーションは、認証リクエストの `EncodedData` パラメータにセキュリティ情報を追加します。さらに、追加のコンテキストデータを受け入れるようにユーザープールを設定し、ユーザーのソース IP を `UserContextData` の `IpAddress` パラメータに追加します。
**クライアントサーバーアプリケーションにコンテキストデータを追加するには**
1. フロントエンドアプリケーションで、[iOS、Android、または JavaScript モジュール](#user-pool-settings-viewing-threat-protection-app-additional-resources)を使用してクライアントからエンコードされたコンテキストデータを収集します。
1. エンコードされたデータと認証リクエストの詳細をアプリケーションサーバーに渡します。
1. アプリケーションサーバーで、HTTP リクエストから、ユーザーの IP アドレス、関連する HTTP ヘッダー、リクエストされたサーバー名、リクエストされたパスを抽出します。これらの値を Amazon Cognito への API リクエストの [ContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-ContextData) パラメータに入力します。
1. SDK モジュールが収集したエンコードされたデバイスデータを使用して、API リクエストの `ContextData` の `EncodedData` パラメータを入力します。このコンテキストデータを認証リクエストに追加します。
## クライアントサーバーアプリケーション用のコンテキストデータライブラリ
### JavaScript
`amazon-cognito-advanced-security-data.min.js` モジュールは、アプリケーションサーバーに渡すことができる `EncodedData` を収集します。
`amazon-cognito-advanced-security-data.min.js` モジュールを JavaScript 設定に追加します。を、、`us-east-1`、`us-east-2`、、`eu-west-2`、または `us-west-2` `eu-west-1` AWS リージョン のリストから ``に置き換えます`eu-central-1`。
```
```
`EncodedData` パラメータで使用できる `encodedContextData` オブジェクトを生成するには、JavaScript アプリケーションソースに以下を追加します。
```
var encodedContextData = AmazonCognitoAdvancedSecurityData.getData(_username, _userpoolId, _userPoolClientId);
```
### iOS/Swift
コンテキストデータを生成するには、iOS アプリケーションは、[Mobile SDK for iOS](https://github.com/aws-amplify/aws-sdk-ios/tree/main) モジュール [AWSCognitoIdentityProviderASF](https://github.com/aws-amplify/aws-sdk-ios/tree/main/AWSCognitoIdentityProviderASF) を統合できます。
脅威保護のためにエンコードされたコンテキストデータを収集するには、次のスニペットをアプリケーションに追加します。
```
import AWSCognitoIdentityProviderASF
let deviceId = getDeviceId()
let encodedContextData = AWSCognitoIdentityProviderASF.userContextData(
userPoolId,
username: username,
deviceId: deviceId,
userPoolClientId: userPoolClientId)
/**
* Reuse DeviceId from keychain or generate one for the first time.
*/
func getDeviceId() -> String {
let deviceIdKey = getKeyChainKey(namespace: userPoolId, key: "AWSCognitoAuthAsfDeviceId")
if let existingDeviceId = self.keychain.string(forKey: deviceIdKey) {
return existingDeviceId
}
let newDeviceId = UUID().uuidString
self.keychain.setString(newDeviceId, forKey: deviceIdKey)
return newDeviceId
}
/**
* Get a namespaced keychain key given a namespace and key
*/
func getKeyChainKey(namespace: String, key: String) -> String {
return "\(namespace).\(key)"
}
```
### Android
コンテキストデータを生成するには、Android アプリケーションは、[Mobile SDK for Android](https://github.com/aws-amplify/aws-sdk-android/tree/main) モジュール [aws-android-sdk-cognitoidentityprovider-asf](https://github.com/aws-amplify/aws-sdk-android/tree/main/aws-android-sdk-cognitoidentityprovider-asf) を統合できます。
脅威保護のためにエンコードされたコンテキストデータを収集するには、次のスニペットをアプリケーションに追加します。
```
UserContextDataProvider provider = UserContextDataProvider.getInstance();
// context here is android application context.
String encodedContextData = provider.getEncodedContextData(context, username, userPoolId, userPoolClientId);
```
# AWS WAF ウェブ ACL をユーザープールに関連付ける
AWS WAF はウェブアプリケーションファイアウォールです。 AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) を使用すると、クラシックホスト UI、マネージドログイン、Amazon Cognito API サービスエンドポイントへの不要なリクエストからユーザープールを保護できます。ウェブ ACL を使用すると、ユーザープールが応答するすべての HTTPS ウェブリクエストをきめ細かく制御できます。 AWS WAF ウェブ ACL の詳細については、「*AWS WAF デベロッパーガイド*」の「[ウェブアクセスコントロールリスト (ウェブ ACL) の管理と使用](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)」を参照してください。
ユーザープールに関連付けられた AWS WAF ウェブ ACL がある場合、Amazon Cognito は選択した非機密ヘッダーとユーザーからのリクエストの内容を に転送します AWS WAF。 AWS WAF はリクエストの内容を検査し、ウェブ ACL で指定したルールと比較し、Amazon Cognito にレスポンスを返します。
## AWS WAF ウェブ ACLs と Amazon Cognito について知っておくべきこと
+ ウェブ ACL ルールは、ユーザー名、パスワード、電話番号、E メールアドレスなど、ユーザープールリクエスト内の個人を特定できる情報 (PII) と一致するように設定することはできません。このデータは利用できません AWS WAF。代わりに、IP アドレス、ブラウザエージェント、リクエストされた API オペレーションなど、ヘッダー、パス、本文のセッションデータと一致するようにウェブ ACL ルールを設定します。
+ ウェブ ACL ルールの条件は、ユーザーインタラクティブなマネージドログインページへのユーザーからの**最初**のリクエストに対してのみ、カスタムブロックレスポンスを返すことができます。後続の接続がカスタムブロックレスポンスの条件に一致すると、カスタムステータスコード、ヘッダー、リダイレクトレスポンスを返しますが、デフォルトのブロックメッセージは返しません。
+ によってブロックされたリクエスト AWS WAF は、どのリクエストタイプのリクエストレートクォータにもカウントされません。 AWS WAF ハンドラーは、API レベルのスロットリングハンドラーの前に呼び出されます。
+ ウェブ ACL を作成すると、ウェブ ACL が完全に伝達されて Amazon Cognito で使用できるようになるまでに少し時間がかかります。伝播時間は、数秒から数分までです。 は、完全に伝播される前にウェブ ACL を関連付けようと[https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociateWebACL.html#API_AssociateWebACL_Errors](https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociateWebACL.html#API_AssociateWebACL_Errors)すると、 AWS WAF を返します。
+ ユーザープールごとに 1 つのウェブ ACL を関連付けることができます。
+ リクエストは、 AWS WAF が検査できる範囲を超えたペイロードになる可能性があります が Amazon Cognito [からのオーバーサイズリクエストを処理する方法を設定する方法については、「 デベロッパーガイド」の「オーバーサイズリクエストコンポーネントの処理](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-oversize-handling.html)」を参照してください。 *AWS WAF * AWS WAF
+ AWS WAF [Fraud Control アカウント乗っ取り防止 (ATP)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-atp.html) を使用するウェブ ACL を Amazon Cognito ユーザープールに関連付けることはできません。ATP 機能は、`AWS-AWSManagedRulesATPRuleSet` マネージドルールグループに含まれています。ウェブ ACL をユーザープールに関連付ける前に、ウェブ ACL がこのマネージドルールグループを使用していないことを確認してください。
+ ユーザープールに関連付けられた AWS WAF ウェブ ACL があり、ウェブ ACL のルールが CAPTCHA を提示すると、マネージドログイン TOTP 登録で回復不可能なエラーが発生する可能性があります。CAPTCHA アクションを含み、マネージドログインの TOTP には影響しないルールを作成するには、「[マネージドログイン TOTP MFA 用の AWS WAF ウェブ ACL の設定](user-pool-settings-mfa-totp.md#totp-waf)」を参照してください。
AWS WAF は、次のエンドポイントへのリクエストを検査します。
**マネージドログインとクラシックのホストされた UI**
[ユーザープールのエンドポイントとマネージドログインのリファレンス](cognito-userpools-server-contract-reference.md) 内のすべてのエンドポイントへのリクエスト。
**公開 API オペレーション**
アプリケーションから Amazon Cognito API へのリクエストのうち、認可に AWS 認証情報を使用しないリクエスト。これには、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html)、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html)、[GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) などの API オペレーションが含まれます。の範囲内にある API オペレーションでは、 AWS 認証情報による認証 AWS WAF は必要ありません。これらは、認証されていないか、セッション文字列またはアクセストークンで承認されています。詳細については、「[認可モデル別にグループ化された API オペレーションのリスト](authentication-flows-public-server-side.md#user-pool-apis-auth-unauth)」を参照してください。
ウェブ ACL のルールを設定するには、ルールと一致するリクエストに応じて、**カウント**、**許可**、**ブロック**、または **CAPTCHA** 提示を行うルールアクションを使用できます。詳細については、「*AWS WAF デベロッパーガイド*」の「[AWS WAF のルール](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html)」を参照してください。ルールアクションに応じて、Amazon Cognito からユーザーに返す応答をカスタマイズできます。
**重要**
エラー応答をカスタマイズするオプションは、API リクエストを行う方法によって異なります。
マネージドログインリクエストのエラーコードとレスポンス本文をカスタマイズできます。マネージドログインでは、ユーザーに解決してもらうためだけに CAPTCHA を提示できます。
Amazon Cognito [ユーザープール API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html) を使用して行うリクエストの場合は、**ブロック**応答を受信するリクエストの応答本文をカスタマイズできます。カスタムエラーコードを 400～499 の範囲で指定することもできます。
AWS Command Line Interface (AWS CLI) と AWS SDKs は、**ブロック**または **CAPTCHA** レスポンスを生成するリクエストに`ForbiddenException`エラーを返します。
## ウェブ ACL をユーザープールに関連付ける
ユーザープールでウェブ ACL を使用するには、 AWS Identity and Access Management (IAM) プリンシパルに次の Amazon Cognito および アクセス AWS WAF 許可が必要です。アクセス AWS WAF 許可の詳細については、「 *AWS WAF デベロッパーガイド*」の[AWS WAF 「API アクセス許可](https://docs.aws.amazon.com/waf/latest/developerguide/waf-api-permissions-ref.html)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowWebACLUserPool",
"Effect": "Allow",
"Action": [
"cognito-idp:ListResourcesForWebACL",
"cognito-idp:GetWebACLForResource",
"cognito-idp:AssociateWebACL"
],
"Resource": [
"arn:aws:cognito-idp:*:123456789012:userpool/*"
]
},
{
"Sid": "AllowWebACLUserPoolWAFv2",
"Effect": "Allow",
"Action": [
"wafv2:ListResourcesForWebACL",
"wafv2:AssociateWebACL",
"wafv2:DisassociateWebACL",
"wafv2:GetWebACLForResource"
],
"Resource": "arn:aws:wafv2:*:123456789012:*/webacl/*/*"
},
{
"Sid": "DisassociateWebACL1",
"Effect": "Allow",
"Action": "wafv2:DisassociateWebACL",
"Resource": "*"
},
{
"Sid": "DisassociateWebACL2",
"Effect": "Allow",
"Action": [
"cognito-idp:DisassociateWebACL"
],
"Resource": [
"arn:aws:cognito-idp:*:123456789012:userpool/*"
]
}
]
}
```
------
IAM アクセス許可を付与する必要がありますが、リストされているのは、対応する [API オペレーション](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html)のない許可のみのアクションです。
**ユーザープール AWS WAF の をアクティブ化し、ウェブ ACL を関連付けるには**
1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。
1. ナビゲーションペインで **[User Pools]** (ユーザープール) を選択してから、編集するユーザープールを選択します。
1. **[セキュリティ]** セクションの **[AWS WAF]** タブを選択します。
1. **[編集]** を選択します。
1. **ユーザープール AWS WAF で を使用する** を選択します。
![\[ユーザープールを選択した AWS WAF 状態で を使用する AWS WAF ダイアログボックスのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-WAF-console.png)
1. すでに作成した**AWS WAF ウェブ ACL** を選択するか、**「 でウェブ ACL AWS WAF** を作成する」を選択して、 の新しい AWS WAF セッションで作成します AWS マネジメントコンソール。
1. **[Save changes]** (変更の保存) をクリックします。
ウェブ ACL を AWS Command Line Interface または SDK のユーザープールにプログラムで関連付けるには、 AWS WAF API の [AssociateWebACL](https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociateWebACL.html) を使用します。Amazon Cognito には、ウェブ ACL を関連付ける個別の API オペレーションはありません。
## AWS WAF ウェブ ACLsテストとログ記録
ウェブ ACL でルールアクションを**カウント**に設定すると、 はルールに一致するリクエストの数にリクエスト AWS WAF を追加します。ユーザープールでウェブ ACL をテストするには、ルールアクションを**カウント**に設定し、各ルールに一致するリクエストの量を考慮します。例えば、ルールを**ブロック**アクションに設定した場合に、通常のユーザートラフィックと判断される多数のリクエストと一致するときは、ルールの再設定が必要になる場合があります。詳細については、「*AWS WAF デベロッパーガイド*」の「[AWS WAF 保護のテストとチューニング](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)」を参照してください。
リクエストヘッダーを Amazon CloudWatch Logs ロググループ、Amazon Simple Storage Service (Amazon S3) バケット、または Amazon Data Firehose に記録する AWS WAF ように を設定することもできます。ユーザープール API で行った Amazon Cognito リクエストは、`x-amzn-cognito-client-id` と `x-amzn-cognito-operation-name` で特定できます マネージドログインのリクエストには、`x-amzn-cognito-client-id` ヘッダーのみが含まれます。詳細については、「*AWS WAF デベロッパーガイド*」の「[ウェブ ACL トラフィックのログ記録](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)」を参照してください。
AWS WAF ウェブ ACLsは、すべてのユーザープール[機能プラン](cognito-sign-in-feature-plans.md)で使用できます。 AWS WAF のセキュリティ機能は、Amazon Cognito の脅威保護を補完します。ユーザープールで両方の機能を有効にすることができます。 AWS WAF は、ユーザープールリクエストの検査に対して別途に請求を行います。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing)」を参照してください。
ログ記録 AWS WAF リクエストデータには、ログをターゲットとするサービスによる追加料金が適用されます。詳細については、「*AWS WAF デベロッパーガイド*」の「[ウェブ ACL トラフィック情報のログ記録の料金](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html#logging-pricing)」を参照してください。
# ユーザープールの大文字と小文字の区別
で作成した Amazon Cognito ユーザープール AWS マネジメントコンソール では、デフォルトで大文字と小文字が区別されません。ユーザープールが大文字と小文字を区別しない場合、*user@example.com* と *User@example.com* は同じユーザーを参照します。ユーザープール内のユーザー名が大文字と小文字が区別しない場合、`preferred_username` と `email` 属性でも大文字と小文字が区別されません。
大文字と小文字の区別なしは、属性の入力だけでなく出力にも適用されます。大文字と小文字を区別しないユーザープールにおいて、大文字と小文字が混在する属性値は、ユーザープールのテキスト出力で小文字に変換されます。ユーザープールのテキスト出力の例としては、[userInfo](userinfo-endpoint.md) レスポンス、ユーザークエリレスポンス ([GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) の出力など)、[Lambda トリガー](cognito-user-pools-working-with-lambda-triggers.md)への入力イベントがあります。
ユーザープールの大文字と小文字の区別の設定を考慮するには、代替のユーザー属性に基づいてアプリコードでユーザーを識別します。ユーザー名、優先ユーザー名、または E メールアドレス属性の大文字と小文字はユーザープロファイルによって異なる場合があるため、代わりに `sub` 属性を参照してください。また、ユーザープールにイミュータブルカスタム属性を作成し、各新規ユーザープロファイルの属性に独自の一意の識別子値を割り当てることもできます。最初にユーザーを作成するときに、作成したイミュータブルカスタム属性に値を書き込むことができます。
**注記**
ユーザープールの大文字と小文字を区別する設定に関係なく、Amazon Cognito では、SAML または OIDC ID プロバイダー (IdP) のフェデレーティッドユーザーが、大文字と小文字を区別する一意の `NameId` または `sub` クレームを渡す必要があります。一意の識別子の大文字と小文字の区別および SAML IdP の詳細については、「[SP が開始した SAML サインインを実装する](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-saml-idp-authentication)」を参照してください。
大文字と小文字を区別するユーザープールの作成
AWS Command Line Interface (AWS CLI) および [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) などの API オペレーションを使用してリソースを作成する場合は、ブール`CaseSensitive`パラメータを に設定する必要があります`false`。この設定では、大文字と小文字を区別しないユーザープールが作成されます。値を指定しないと、`CaseSensitive` はデフォルトで `true` に従います。Amazon Cognito コンソールで作成するユーザープールでは、大文字と小文字は区別されません。大文字と小文字を区別するユーザープールを生成するには、`CreateUserPool` オペレーションを使用する必要があります。2020 年 2 月 12 日以前のユーザープールでは、プラットフォームに関係なく、大文字と小文字が区別されていました。
AWS マネジメントコンソール の **[サインイン]** メニューおよび [DescribeUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserPoolType.html#CognitoUserPools-Type-UserPoolType-UsernameConfiguration) の `UsernameConfiguration` プロパティで、アカウント内の各ユーザープールの大文字と小文字を区別する設定を確認できます。
新しいユーザープールに移行する
ユーザープロファイル間で競合が発生する可能性があるため、Amazon Cognito ユーザープールで大文字と小文字を区別するから大文字と小文字を区別しないに変更することはできません。代わりに、ユーザーを新しいユーザープールに移行します。ケース関連の競合を解決するには、移行コードをビルドする必要があります。このコードは、競合を検出したときに一意の新しいユーザーを返すか、サインイン試行を拒否する必要があります。大文字と小文字を区別しない新しいユーザープールで、[ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md) を割り当てます。 AWS Lambda 関数は、新しい大文字と小文字を区別しないユーザープールにユーザーを作成できます。ユーザーが大文字小文字を区別しないユーザープールでサインインに失敗した場合、Lambda 関数は大文字小文字を区別するユーザープールからユーザーを見つけて、複製します。また、[ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) イベントで、ユーザーの移行 Lambda トリガーを有効化することもできます。Amazon Cognito は、サインインやパスワード回復アクションからユーザー情報とイベントメタデータを Lambda 関数に渡します。関数が大文字と小文字を区別しないユーザープールに新しいユーザーを作成する際、イベントデータを使用してユーザー名とメールアドレス間で発生する競合を管理することができます。ユーザー名と E メールアドレスが、大文字と小文字を区別するユーザープールでは一意でも、大文字と小文字を区別しないユーザープールでは同一となる場合に競合が発生します。
Amazon Cognito ユーザープール間でユーザーの Lambda 移行トリガーを使用する方法の詳細については、 AWS ブログの[「ユーザーの Amazon Cognito ユーザープールへの移行](https://aws.amazon.com/blogs/mobile/migrating-users-to-amazon-cognito-user-pools/)」を参照してください。
# ユーザープールの削除保護
管理者が誤ってユーザープールを削除しないようにするには、削除保護を有効にします。削除保護が有効になっている場合は、ユーザープールを削除する前に削除の確認を行う必要があります。でユーザープールを削除すると AWS マネジメントコンソール、削除保護を同時に無効にできます。次の画像に示すように、削除保護を無効にするプロンプトに応じて削除の意思を確認すると、Amazon Cognito がユーザープールを削除します。
![\[削除保護を無効にするプロンプトを含むユーザープールを削除するプロンプト AWS マネジメントコンソール を示す のスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/amazon-cognito-delete-user-pool-deactivate-deletion-protection.png)
Amazon Cognito API リクエストを使用してユーザープールを削除する場合は、まず [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエストで `DeletionProtection` を `Inactive` に変更する必要があります。削除保護を無効にしないと、Amazon Cognito は `InvalidParameterException` エラーを返します。削除保護を無効にすると、[DeleteUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPool.html) リクエストでユーザープールを削除できます。
Amazon Cognito は、 AWS マネジメントコンソールで新しいユーザープールの作成時に、デフォルトで**削除保護**を有効にします。`CreateUserPool` API を使用してユーザープールを作成すると、削除保護はデフォルトで無効になります。 AWS CLI または AWS SDK で作成したユーザープールでこの機能を使用するには、 `DeletionProtection`パラメータを に設定します`True`。
Amazon Cognito コンソールの **[設定]** メニューの **[削除保護]** コンテナで、削除保護ステータスをアクティブ化または非アクティブ化できます。
# 削除保護を設定するには
1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。 AWS 認証情報の入力を求められる場合があります。
1. **[User Pools]** (ユーザープール) を選択します。
1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。
1. **[設定]** メニューを選択し、**[削除保護]** タブに移動します。**[アクティブ化]** または **[非アクティブ化]** を選択します。
1. 次のダイアログで選択を確定します。
# ユーザー存在エラー応答の管理
Amazon Cognito は、ユーザープールから返されるエラーレスポンスのカスタマイズをサポートしています。カスタムエラーレスポンスは、ユーザーの作成と認証、パスワードリカバリ、および確認操作に利用できます。
ユーザープールアプリクライアントの `PreventUserExistenceErrors` 設定を使用して、ユーザーの存在に関連するエラーを有効または無効にします。Amazon Cognito ユーザープール API を使用して新しいアプリケーションクライアントを作成する場合、`PreventUserExistenceErrors` はデフォルトで `LEGACY` または無効になっています。Amazon Cognito コンソールでは、オプションの**ユーザー存在エラーの防止**が、`PreventUserExistenceErrors` を `ENABLED` とする設定としてデフォルトで選択されています。`PreventUserExistenceErrors` の設定を更新するには、次のいずれかを実行します。
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) API リクエストで `PreventUserExistenceErrors` の値を `ENABLED` と `LEGACY` との間で変更します。
+ Amazon Cognito コンソールでアプリケーションクライアントを編集し、**ユーザー存在エラーの防止**の状態を、選択 (`ENABLED`) と選択解除 (`LEGACY`) との間で変更します。
このプロパティの値が `LEGACY` である場合、ユーザーがユーザープールに存在しないユーザー名でサインインしようとすると、アプリケーションクライアントは `UserNotFoundException` エラー応答を返します。
このプロパティの値が `ENABLED` である場合、アプリケーションクライアントは、ユーザープールにユーザーアカウントが存在しないことを `UserNotFoundException` エラーを用いて開示しません。`PreventUserExistenceErrors` を `ENABLED` に設定した場合、存在しないユーザー名をリクエストすると、以下のようになります。
+ Amazon Cognito は API リクエストに対して非特定の情報で応答します。そうしない場合、その応答から有効なユーザーが存在することが開示される可能性があります。
+ Amazon Cognito は、パスワードを忘れた場合のリクエストに対して、さらに `USER_SRP_AUTH` や `CUSTOM_AUTH` などの[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice) (`USER_AUTH`) を*除く*認証フローによる認証リクエストに対して、一般的な認証失敗レスポンスを返します。エラーレスポンスは、ユーザー名またはパスワードが正しくないことを伝えます。
+ Amazon Cognito は、選択ベースの認証へのリクエストに対して、ユーザープールで許可されているチャレンジタイプからランダムに選択して応答します。ユーザープールは、パスキー、ワンタイムパスワード、またはパスワードチャレンジを返す場合があります。
+ Amazon Cognito のアカウント確認 API とパスワード復旧 API の動作は、シミュレートされた配信メディアにコードが送信されたことを示すレスポンスを返すか、`InvalidParameterException` エラーを返すかのいずれかです。
次の情報は、`PreventUserExistenceErrors` が `ENABLED` に設定されている場合のユーザープールオペレーションの動作を詳しく示しています。
## 認証とユーザー作成のオペレーション
エラーレスポンスは、ユーザー名パスワード認証とセキュアリモートパスワード (SRP) 認証で設定できます。カスタム認証により、返すエラーをカスタマイズすることもできます。選択ベースの認証は、`PreventUserExistenceErrors` 設定の影響を受けません。認証フローでのユーザー存在開示の詳細
**選択ベースの認証**
`USER_AUTH` 選択ベースの認証フローの場合、Amazon Cognito は、ユーザープール設定とユーザー属性に応じて、利用可能なプライマリ認証要素からチャレンジを返します。この認証フローでは、パスワード、セキュアリモートパスワード (SRP)、WebAuthn (パスキー）、SMS ワンタイムパスワード (OTP)、または E メール OTP チャレンジを返すことができます。`PreventUserExistenceErrors` がアクティブな場合、Amazon Cognito は、存在しないユーザーに対して 1 つ以上の利用可能な認証形式を完了するためのチャレンジを発行します。`PreventUserExistenceErrors` が非アクティブな場合、Amazon Cognito は `UserNotFound` 例外を返します。
**ユーザー名およびパスワード認証**
`PreventUserExistenceErrors` がアクティブな場合、`ADMIN_USER_PASSWORD_AUTH` 認証フロー、`USER_PASSWORD_AUTH` 認証フロー、および `USER_AUTH` の `PASSWORD` フローは、メッセージ `Incorrect username or password` とともに `NotAuthorizedException` を返します。`PreventUserExistenceErrors` が非アクティブな場合、これらのフローは `UserNotFoundException` を返します。
**セキュアリモートパスワード (SRP) ベースの認証**
ベストプラクティスとして、E メールアドレス、電話番号、または優先ユーザー名の[エイリアス属性](user-pool-settings-attributes.md#user-pool-settings-aliases)がないユーザープールでは、`PreventUserExistenceErrors` を実装するのに `USER_SRP_AUTH` または `USER_AUTH` の `PASSWORD_SRP` フローのみを使用します。エイリアス属性を持つユーザーは、SRP 認証フローでユーザー存在が抑制されない場合があります。ユーザー名パスワード認証フロー (`ADMIN_USER_PASSWORD_AUTH`、`USER_PASSWORD_AUTH`、および `USER_AUTH` `PASSWORD` チャレンジ) は、エイリアス属性からのユーザー存在を完全に抑制します。
アプリケーションクライアントに知られていないユーザー名を使用して誰かが SRP サインインを試みると、Amazon Cognito は、[RFC 5054](https://tools.ietf.org/html/rfc5054#section-2.5.1.3) で説明されているように、最初のステップでシミュレートされたレスポンスを返します。Amazon Cognito は、同じユーザー名とユーザープールの組み合わせに対して、同じ Salt と [UUID](cognito-terms.md#terms-uuid) 形式の内部ユーザー ID を返します。パスワードの証明を含む `RespondToAuthChallenge` API リクエストを送信すると、Amazon Cognito はユーザー名またはパスワードのいずれかが正しくない場合に一般的な `NotAuthorizedException` エラーを返します。SRP 認証の実装の詳細については、「[永続的なパスワードと安全なペイロードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp)」を参照してください。
検証ベースのエイリアス属性を使用していて、変更不可能なユーザー名の形式が [UUID](cognito-terms.md#terms-uuid) でない場合は、ユーザー名とパスワードの認証で汎用応答をシミュレートできます。
**カスタム認証チャレンジの Lambda トリガー**
Amazon Cognito は、`CUSTOM_AUTH` 認証フローでサインインしようとしたユーザーのユーザー名が見つからない場合、[カスタム認証チャレンジ Lambda トリガー](user-pool-lambda-challenge.md)を呼び出します。ユーザーが存在しない場合、入力イベントには `UserNotFound` という名前のブール型パラメータが `true` の値とともに含まれます。このパラメータは、カスタム認証アーキテクチャを構成する認証チャレンジの作成、定義、検証を行う Lambda 関数にユーザープールから送信するリクエストイベントに表示されます。このインジケータを Lambda 関数のロジックで確認したら、存在しないユーザーのカスタム認証チャレンジをシミュレートできます。
**認証前の Lambda トリガー**
Amazon Cognito は、サインインしようとしたユーザーのユーザー名が見つからない場合、[認証前トリガー](user-pool-lambda-pre-authentication.md)を呼び出します。ユーザーが存在しない場合、入力イベントには `UserNotFound` パラメータが `true` の値とともに含まれます。
ユーザーアカウントの作成に対する `PreventUserExistenceErrors` の影響について以下に説明します。ユーザー作成フローでのユーザー存在開示の詳細
**SignUp**
`SignUp` オペレーションは、ユーザー名がすでに使用されている場合は必ず `UsernameExistsException` を返します。アプリケーションでユーザーをサインアップするときに Amazon Cognito が E メールアドレスと電話番号の `UsernameExistsException` エラーを返さないようにするには、検証ベースのエイリアス属性を使用してください。エイリアスの詳細については、「[ログイン属性のカスタマイズ](user-pool-settings-attributes.md#user-pool-settings-aliases)」を参照してください。
Amazon Cognito が`SignUp` API リクエストを使用してユーザープール内のユーザーを検出できないようにする方法の例については、「[サインアップ時のメールアドレスと電話番号の `UsernameExistsException` エラーの防止](#cognito-user-pool-managing-errors-prevent-userexistence-errors)」を参照してください。
**インポート済みユーザー**
`PreventUserExistenceErrors` が有効になっている場合は、インポートされたユーザーの認証中、`PasswordResetRequiredException` を返す代わりに、ユーザー名またはパスワードが正しくなかったことを示す `NotAuthorizedException` エラーが返されます。詳細については「[インポートされたユーザーにパスワードをリセットするように要求](cognito-user-pools-using-import-tool.md#cognito-user-pools-using-import-tool-password-reset)」を参照してください。
**ユーザー移行の Lambda トリガー**
Lambda トリガーによって元のイベントコンテキストに空のレスポンスが設定された場合、Amazon Cognito は存在しないユーザーについてシミュレートされたレスポンスを返します。詳細については、「[ユーザー移行の Lambda トリガーを使用したユーザーのインポート](cognito-user-pools-import-using-lambda.md)」を参照してください。
### サインアップ時のメールアドレスと電話番号の `UsernameExistsException` エラーの防止
次の例は、ユーザープールでエイリアス属性を設定するときに、重複する E メールアドレスと電話番号が `SignUp` API リクエストに応答して `UsernameExistsException` エラーを生成しないようにする方法を示しています。E メールアドレスまたは電話番号をエイリアス属性として使用してユーザープールを作成しておく必要があります。詳細については、「[ユーザープール属性](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases)」の「*サインイン属性のカスタマイズ*」セクションを参照してください。
1. Jie は新しいユーザー名にサインアップし、E メールアドレス `jie@example.com` も提供します。Amazon Cognito がユーザーの E メールアドレスにコードを送信します。
** AWS CLI コマンドの例**
```
aws cognito-idp sign-up --client-id 1234567890abcdef0 --username jie --password PASSWORD --user-attributes Name="email",Value="jie@example.com"
```
**レスポンスの例**
```
{
"UserConfirmed": false,
"UserSub": "",
"CodeDeliveryDetails": {
"AttributeName": "email",
"Destination": "j****@e****",
"DeliveryMedium": "EMAIL"
}
}
```
1. Jie は、E メールアドレスの所有権を確認するために送信されたコードを提供します。これで、ユーザーとしての登録は完了です。
** AWS CLI コマンドの例**
```
aws cognito-idp confirm-sign-up --client-id 1234567890abcdef0 --username=jie --confirmation-code xxxxxx
```
1. Shirley は新しいユーザーアカウントを登録し、E メールアドレス `jie@example.com` を提供します。Amazon Cognito は `UsernameExistsException` エラーを返さず、確認コードを Jie の E メールアドレスに送信します。
** AWS CLI コマンドの例**
```
aws cognito-idp sign-up --client-id 1234567890abcdef0 --username shirley --password PASSWORD --user-attributes Name="email",Value="jie@example.com"
```
**レスポンスの例**
```
{
"UserConfirmed": false,
"UserSub": "",
"CodeDeliveryDetails": {
"AttributeName": "email",
"Destination": "j****@e****",
"DeliveryMedium": "EMAIL"
}
}
```
1. 別のシナリオでは、Shirley が `jie@example.com` の所有権を持っています。Shirley は Amazon Cognito が Jie の E メールアドレスに送信したコードを取得し、アカウントの確認を試みます。
** AWS CLI コマンドの例**
```
aws cognito-idp confirm-sign-up --client-id 1234567890abcdef0 --username=shirley --confirmation-code xxxxxx
```
**レスポンスの例**
```
An error occurred (AliasExistsException) when calling the ConfirmSignUp operation: An account with the email already exists.
```
`jie@example.com` が既存のユーザーに割り当てられているにもかかわらず、Amazon Cognito は Shirley の `aws cognito-idp sign-up` リクエストにエラーを返しません。Amazon Cognito がエラーレスポンスを返す前に、Shirley は E メールアドレスの所有権を証明する必要があります。エイリアス属性を持つユーザープールでは、この動作により、パブリック `SignUp` API を使用して、特定の E メールアドレスまたは電話番号を持つユーザーが存在するかどうかを確認できなくなります。
この動作は、次の例に示すように、Amazon Cognito が既存のユーザー名の `SignUp` リクエストに対して返すレスポンスとは異なります。Shirley はこのレスポンスから、そのユーザー名 `jie` を持つユーザーが既に存在することを知っていますが、そのユーザーに関連する E メールアドレスや電話番号については知りません。
**CLI コマンドの例**
```
aws cognito-idp sign-up --client-id 1example23456789 --username jie --password PASSWORD
--user-attributes Name="email",Value="shirley@example.com"
```
**レスポンスの例**
```
An error occurred (UsernameExistsException) when calling the SignUp operation: User already exists
```
## パスワードのリセットオペレーション
ユーザー存在エラーを防ぐと、Amazon Cognito は、ユーザーパスワードのリセット操作に対して以下の応答を返します。
**ForgotPassword**
ユーザーが見つからない、非アクティブ化されている、またはパスワードを回復するための検証済みの配信メカニズムがない場合、Amazon Cognito はそのユーザーについてシミュレート済みの配信ミディアムを用いた `CodeDeliveryDetails` を返します。シミュレートされた配信メディアは、入力ユーザー名形式とユーザープールの検証設定によって決まります。
**ConfirmForgotPassword**
Amazon Cognito は、存在しない、または無効になっているユーザーについて `CodeMismatchException` エラーを返します。`ForgotPassword` の使用時にコードが要求されない場合、Amazon Cognito は `ExpiredCodeException` エラーを返します。
## 確認オペレーション
ユーザー存在エラーを防ぐと、Amazon Cognito は、ユーザーの確認および検証の操作に対して以下の応答を返します。
**ResendConfirmationCode**
Amazon Cognito は、無効化されたユーザー、または存在しないユーザーについて `CodeDeliveryDetails` を返します。Amazon Cognito は、既存ユーザーの E メールまたは電話番号に確認コードを送信します。
**ConfirmSignUp**
コードの有効期限が切れている場合は、`ExpiredCodeException` が返されます。Amazon Cognito は、ユーザーが承認されていない場合に `NotAuthorizedException` を返します。コードがサーバーが期待するものと一致しない場合、Amazon Cognito は `CodeMismatchException` を返します。