翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Cognito ユーザープールに対するセキュリティのベストプラクティス
このページでは、一般的な脅威から保護する場合に実装できるセキュリティのベストプラクティスについて説明します。選択した設定は、各アプリケーションのユースケースによって異なります。少なくとも、管理オペレーションに最小特権を適用し、アプリケーションとユーザーのシークレットを保護するアクションを実行することをお勧めします。もう 1 つの高度で効果的なステップは、 AWS WAF ウェブ ACLs を設定してユーザープールに適用することです。
ネットワークレベルでユーザープールを保護する
AWS WAF ウェブ ACLs は、Amazon Cognito で構築する認証メカニズムのパフォーマンスとコストを保護できます。ウェブ ACLs を使用すると、API およびマネージドログインリクエストの前にガードレールを実装できます。ウェブ ACLsネットワークレイヤーとアプリケーションレイヤーのフィルターを作成します。このフィルターは、トラフィックをドロップしたり、作成したルールに基づいて CAPTCHA を要求したりできます。リクエストは、ウェブ ACL ルールの資格を満たすまで Amazon Cognito リソースに渡されません。詳細については、AWS WAF 「ウェブ ACLs」を参照してください。
SMS メッセージの不正使用からの保護
ユーザープールでパブリックサインアップを許可すると、Amazon Cognito が SMS テキストメッセージで送信するコードを使用してアカウント検証を設定できます。SMS メッセージは、不要なアクティビティに関連付けられ、 AWS 請求額が増加する可能性があります。不正の状況下で SMS メッセージを送信しないようにインフラストラクチャを設定します。詳細については、 AWS ブログの以下の投稿を参照してください。
パブリック認証を理解する
Amazon Cognito ユーザープールには、一般のユーザーがユーザーアカウントにサインアップしてアプリケーションにアクセスできるユースケースをサポートするカスタマーアイデンティティおよびアクセス管理 (CIAM) 機能があります。ユーザープールがセルフサービスサインアップを許可すると、パブリックインターネットからのユーザーアカウントのリクエストに対して開かれます。セルフサービスリクエストは、SignUp や InitiateAuth などの API オペレーション、およびマネージドログインとのユーザーインタラクションから送信されます。ユーザープールを設定して、パブリックリクエストから発生する可能性のある不正使用を軽減したり、パブリック認証オペレーションを完全に無効にしたりできます。
以下の設定は、ユーザープールとアプリケーションクライアントでパブリック認証リクエストと内部認証リクエストを管理する方法の一部です。
| 設定 | 利用可能なオプション | で設定 | パブリック認証への影響 | コンソール設定 | API オペレーションとパラメータ |
|---|---|---|---|---|---|
| セルフサービスサインアップ | アカウントにサインアップするか、管理者としてユーザーアカウントを作成することをユーザーに許可します。 | ユーザープール | パブリックサインアップの防止 | サインアップ – セルフサービスサインアップ |
|
| 管理者の確認 | 確認コードを新しいユーザーに送信するか、管理者に確認を求めます。 | ユーザープール | 管理者アクションなしでサインアップの確認を防ぐ | サインアップ – Cognito による検証と確認 |
|
| ユーザー開示 | サインイン時およびパスワードリセット時に「ユーザーが見つかりません」メッセージを配信するか、開示を防止します。 | ユーザープール | サインイン名、E メールアドレス、または電話番号の推測を防ぐ | アプリケーションクライアント – ユーザー存在エラーの防止 |
CreateUserPoolClient、UpdateUserPoolClient
|
| クライアントシークレット | サインアップ、サインイン、パスワードリセット時にシークレットハッシュを要求または要求しない | アプリケーションクライアント | 不正なソースからの認証リクエストからの保護 | アプリケーションクライアント – クライアントシークレット |
|
| ウェブ ACLs | 認証リクエストのネットワークファイアウォールを有効または無効にする | ユーザープール | 管理者が定義したリクエスト特性と IP アドレスルールに基づいてアクセスを制限または禁止する | AWS WAF — WAF 設定 |
|
| 外部 IdP | サードパーティーの IdPsユーザープールディレクトリ、またはその両方のユーザーによるサインインを許可する | アプリケーションクライアント | サインアップとサインインからローカルユーザーまたはフェデレーティッドユーザーを除外します。 | アプリケーションクライアント – ID プロバイダー |
CreateUserPoolClient、UpdateUserPoolClient
|
| 認可サーバー | 認証のためにパブリックウェブページをホストするかホストしない | ユーザープール | パブリックウェブページをオフにし、SDK ベースの認証のみを許可する | [ドメイン] |
ユーザープールドメインを作成すると、パブリックウェブページが使用可能になります。 |
| 脅威保護 | 悪意のあるアクティビティや安全でないパスワードの兆候のモニタリングを有効または無効にする | ユーザープールまたはアプリケーションクライアント | ユーザーが侵害の兆候を表示すると、サインインを自動的にブロックしたり、MFA を要求したりできます | 脅威保護 – 保護設定 |
のパラメータは、脅威保護設定 |
機密クライアントをクライアントシークレットで保護する
クライアントシークレットは、アプリケーションクライアントに関連付けられているオプションの文字列です。クライアントシークレットを持つアプリケーションクライアントへのすべての認証リクエストには、ユーザー名、クライアント ID、およびクライアントシークレットから生成されたシークレットハッシュが含まれている必要があります。クライアントシークレットを知らないユーザーは、最初からアプリケーションからシャットアウトされます。
ただし、クライアントシークレットには制限があります。クライアントシークレットをパブリッククライアントソフトウェアに埋め込むと、クライアントシークレットは検査対象になります。これにより、ユーザーの作成、パスワードリセットリクエストの送信、アプリクライアントでのその他のオペレーションの実行が可能になります。クライアントシークレットは、アプリケーションがシークレットにアクセスできる唯一のエンティティである場合にのみ実装する必要があります。通常、これはサーバー側の機密クライアントアプリケーションで可能です。これは、クライアントシークレットが必要な M2M アプリケーションにも当てはまります。暗号化されたローカルストレージまたは にクライアントシークレットを保存します AWS Secrets Manager。クライアントシークレットをパブリックインターネットに表示させないでください。
他のシークレットを保護する
Amazon Cognito ユーザープールで認証システムは、プライベートデータ、パスワード、認証情報 AWS を処理する場合があります。以下は、アプリケーションがアクセスする可能性のあるシークレットを処理するためのベストプラクティスです。
- パスワード
-
ユーザーは、アプリケーションにサインインするときにパスワードを入力できます。Amazon Cognito には、アプリケーションが新しいパスワードプロンプトなしで期限切れのユーザーセッションを継続するために使用できる更新トークンがあります。ローカルストレージにパスワードやパスワードハッシュを配置しないでください。パスワードを不透明として扱い、ユーザープールにのみ渡すようにアプリケーションを設計します。
ベストプラクティスとして、WebAuthn パスキーを使用してパスワードレス認証を実装します。パスワードを実装する必要がある場合は、セキュアリモートパスワード (SRP) 認証フローと多要素認証 (MFA) を使用します。
- AWS 認証情報
-
管理認証とユーザープール管理オペレーションには、 AWS 認証情報を使用した認証が必要です。これらのオペレーションをアプリケーションに実装するには、一時的な AWS 認証情報への安全なアクセスを許可します。認証情報へのアクセスは、ユーザーが管理するサーバーコンポーネントで実行されるアプリケーションにのみ付与します。 AWS 認証情報を持つアプリケーションを GitHub などのパブリックバージョン管理システムに配置しないでください。パブリッククライアント側のアプリケーションで AWS 認証情報をエンコードしないでください。
- PKCE コード検証子
-
コード交換の証明キー、つまり PKCE は、ユーザープール認可サーバーでの OpenID Connect (OIDC) 認可コード付与用です。アプリケーションは、認可コードをリクエストするときに、コード検証シークレットをユーザープールと共有します。認可コードをトークンと交換するには、クライアントがコード検証子を知っていることを再確認する必要があります。このプラクティスは、傍受された認可コードを持つトークンの発行を防止します。
クライアントは、認可リクエストごとに新しいランダムコード検証子を生成する必要があります。静的または予測可能なコード検証子を使用すると、攻撃者はハードコードされた検証子と認可コードを傍受するだけで済みます。ユーザーにコード検証値を公開しないようにアプリケーションを設計します。
ユーザープール管理の最小権限
IAM ポリシーは、プリンシパルが Amazon Cognito ユーザープールの管理および管理認証オペレーションに対して持つアクセスレベルを定義できます。例:
-
ウェブサーバーに、管理 API オペレーションによる認証のアクセス許可を付与します。
-
でユーザープールを管理する AWS IAM Identity Center ユーザーに AWS アカウント、ユーザープールのメンテナンスとレポートのためのアクセス許可を付与します。
Amazon Cognito のリソースの詳細度は、IAM ポリシーの目的でユーザープールと ID プールの 2 つのリソースタイプに制限されています。個々のアプリケーションクライアントを管理するためのアクセス許可を適用することはできません。付与するアクセス許可がすべてのアプリケーションクライアントで有効であるという知識でユーザープールを設定します。組織に複数のアプリケーションテナントがあり、セキュリティモデルでテナント間の管理責任の分離が必要な場合は、ユーザープールごとに 1 つのテナントを持つマルチテナンシーを実装します。
などのユーザー認証オペレーションのアクセス許可を持つ IAM ポリシーを作成できますがInitiateAuth、これらのアクセス許可は効果がありません。パブリック API オペレーションとトークン認可 API オペレーションは、IAM アクセス許可の対象ではありません。使用可能なユーザープール認証オペレーションのうち、 のような管理サーバー側のオペレーションにのみアクセス許可を付与できますAdminInitiateAuth。
最小特権Actionリストを使用して、ユーザープールの管理レベルを制限できます。次のポリシー例は、IdPsリソースサーバー、アプリケーションクライアント、およびユーザープールドメインを管理できるが、ユーザーまたはユーザープールを管理できる管理者を対象としています。
次のポリシー例では、サーバー側のアプリケーションにユーザーとグループの管理と認証を付与します。
トークンの保護と検証
トークンには、エンドユーザーに開示したくないグループメンバーシップとユーザー属性への内部参照を含めることができます。ID トークンとアクセストークンをローカルストレージに保存しないでください。更新トークンは、ユーザープールのみがアクセスできるキーで暗号化され、ユーザーやアプリケーションにとっては不透明です。ユーザーがサインアウトしたとき、またはセキュリティ上の理由でユーザーのセッションの永続化が望ましくないと判断した場合は、更新トークンを取り消します。
アクセストークンを使用して、トークンが有効で有効期限が切れていないことを個別に検証するシステムへのアクセスのみを許可します。検証リソースについては、「JSON ウェブトークンの検証」を参照してください。
信頼する ID プロバイダーを決定する
SAML または OIDC ID プロバイダー (IdPs) を使用してユーザープールを設定すると、IdPs は新しいユーザーを作成し、ユーザー属性を設定し、アプリケーションリソースにアクセスできます。SAML プロバイダーと OIDC プロバイダーは、通常、お客様またはお客様の直接の顧客がプロバイダーのメンバーシップと設定を管理するbusiness-to-business (B2B) またはエンタープライズシナリオで使用されます。
ソーシャルプロバイダーは、インターネット上のすべてのユーザーにユーザーアカウントを提供し、エンタープライズプロバイダーよりもユーザーの管理下に置かれません。パブリックカスタマーがアプリケーション内のリソースにサインインしてアクセスできるようにする準備が整っている場合にのみ、アプリケーションクライアントでソーシャル IdPs をアクティブ化します。
ユーザープロファイルへのアクセスに対するスコープの影響を理解する
ユーザープール認可サーバーへの認証リクエストでアクセスコントロールスコープをリクエストできます。これらのスコープは、ユーザーに外部リソースへのアクセスを許可し、ユーザーに自分のユーザープロファイルを表示および変更するためのアクセスを許可できます。アプリケーションのオペレーションに必要な最小限のスコープをサポートするようにアプリケーションクライアントを設定します。
aws.cognito.signin.user.admin スコープは、InitiateAuth などのオペレーションで SDK 認証によって発行されたすべてのアクセストークンに存在します。これは、アプリケーションのユーザープロファイルのセルフサービスオペレーション用に指定されています。このスコープを認可サーバーにリクエストすることもできます。このスコープは、UpdateUserAttributes や GetUser などのトークン認可オペレーションに必要です。これらのオペレーションの効果は、アプリケーションクライアントの読み取りおよび書き込みアクセス許可によって制限されます。
openid、profile、email、および phoneスコープは、ユーザープール認可サーバーuserInfo エンドポイント上の へのリクエストを承認します。エンドポイントが返すことができる属性を定義します。openid スコープは、他のスコープなしでリクエストされると、使用可能なすべての属性を返しますが、リクエストでより多くのスコープをリクエストすると、レスポンスは追加のスコープで表される属性に絞り込まれます。openid スコープは ID トークンのリクエストも示します。このスコープをリクエストから に省略すると認可エンドポイント、Amazon Cognito はアクセストークンと、該当する場合は更新トークンのみを発行します。詳細については、「」のOpenID Connect スコープ」を参照してくださいアプリクライアントの用語。
ユーザー属性の入力をサニタイズする
など、配信方法やユーザー名として使用される可能性のあるユーザー属性にはemail、形式制限があります。他の属性には、文字列、ブール値、または数値のデータ型を含めることができます。文字列属性値は、さまざまな入力をサポートします。ユーザーディレクトリまたは Amazon Cognito がユーザーに配信するメッセージに不要なデータを書き込もうとしないようにアプリケーションを設定します。Amazon Cognito に送信する前に、ユーザーが送信した文字列属性値をクライアント側で検証します。
ユーザープールは、指定した属性マッピングに基づいて、IdPs からユーザープールに属性をマッピングします。安全で予測可能な IdP 属性のみをユーザープールの文字列属性にマッピングします。
