Cognito

Amazon Cognito ユーザープール作成手順とベストプラクティス

ⓘ本ページはプロモーションが含まれています

スポンサードリンク

1. Amazon Cognito ユーザープールの作成手順

ユーザープールは認証情報や属性情報を保持する「データベース」の役割です。正しいリージョンとプール名で作成しないと、後続の IAM ポリシーやドメイン設定が不整合になり、エラーが頻発します。

手順概要

以下の手順は公式ウィザードに沿っているため、途中で項目を見落とすことはほぼありません。

  1. AWS コンソールへサインイン → 左上メニューの「サービス」から Cognito を選択
  2. 「管理対象のユーザープール」画面で [ユーザープールを作成] ボタンをクリック
  3. リージョン（例：ap-northeast-1）と プール名（例：MyAppUserPool）を入力し、[次へ] を押す
  4. ウィザードの各ステップで以下を設定
  5. サインアップ / サインインオプション（メール・電話番号・ユーザー名）
  6. 標準属性とカスタム属性（氏名、住所など）
  7. メッセージ配信（メール送信元、SMS 発信用 SNS トピック）
  8. すべての画面で [作成] をクリック → ユーザープールが有効化されます

ポイント：リージョンはアプリケーションがデプロイされる場所と同一にするとレイテンシが最小化でき、データ居住要件も満たしやすくなります。

注意点

  • ユーザープール名はグローバルにユニークである必要があります。名前衝突を防ぐためにプロジェクトコードや環境（dev‑, prod‑）をプレフィックスとして付与すると管理が楽です。
  • 作成後に「プールの削除」や「属性の変更」を行うと、既存ユーザーへの影響が出る可能性があります。変更前は必ずバックアップ（CSV エクスポート等）を取得してください。

2. サインイン属性とパスワードポリシーの設定

サインインに使用する属性とパスワード要件は、認証成功率 と セキュリティレベル の両方に大きく影響します。ここでは実務で推奨される構成を示します。

サインイン属性の選択と検証設定

メールアドレス、電話番号、ユーザー名はそれぞれメリット・デメリットがありますが、メール認証 + SMS フォールバック が最も汎用的です。

  • メールアドレスを必須にする手順
  • ユーザープールドメイン > 「サインインエクスペリエンス」 → 「サインイン属性」へ移動
  • 「メールアドレス」をチェックし、必須 に設定

  • メール検証 を有効化し、確認コードのテンプレート（件名・本文）を編集

  • SMS 認証の追加

  • 電話番号属性を 任意 にし、MFA 設定で「SMS」をバックアップ手段として有効にします。SNS の SMS 発信料金が別途発生する点に注意してください。

実務ヒント：ユーザーがメール受信できないケースはまれですが、必ず 2 段階認証（MFA）でフォールバックを用意するとサポート工数が削減できます。

パスワードポリシーのベストプラクティス

Cognito のパスワード設定は 「最小文字数」 と 「必須文字種」 を組み合わせて、総当たり攻撃への耐性を高めます。以下は最新公式ドキュメントに基づく推奨構成です。

設定項目 推奨値
最小文字数 12 文字以上（8 文字は最低要件）
必須文字種 大文字・小文字・数字・特殊文字すべて
パスワード履歴保持 過去 5 回のパスワードを再使用不可
アカウントロックアウト 5 回失敗で 30 分間ロック
  • 理由：12 文字以上かつ多様な文字種は、ブルートフォース攻撃に対して指数的に時間が掛かります。履歴保持はユーザーが以前のパスワードを再利用するリスクを防止します。
  • 実装例：A1b2C3d4!@#E$ のように 12 文字以上で構成されたパスワードを推奨し、管理画面で「強度評価」バーが緑になることを基準に案内します。

3. 多要素認証（MFA）と外部 IdP の統合

MFA はアカウント乗っ取りリスクを劇的に低減させます。また、Google・Facebook・SAML 等の外部 IdP を組み合わせることで、ユーザー管理コストを削減できます。

MFA の有効化と OTP デバイス設定

  1. ユーザープール画面左メニューの 「MFA と検証」 を開く
  2. MFA のステータスを「必須」または「オプション」に切り替える
  3. 必須：全ユーザーがサインイン時に MFA が要求されます。管理者や金融系アプリで推奨。
  4. オプション：ユーザーが自ら有効化でき、UX の柔軟性が保たれます。
  5. OTP デバイスの種類を選択
  6. SMS（テキストメッセージ）：AWS SNS が 6 桁コードを送信。即時導入が容易です。
  7. TOTP（Google Authenticator、Authy 等）：RFC 6238 準拠の時間ベース OTP。QR コードでアプリと連携し、フィッシング耐性が高いです。

実務推奨：TOTP を必須にしつつ、SMS をバックアップ手段としてオプションで残す 構成は、セキュリティとユーザビリティのベストバランスです。

フェデレーティッドサインイン（外部 IdP）概要

プロバイダー 必要情報 設定手順概略
Google クライアント ID / シークレット Cognito > IdP > Google → 「クライアント ID」「シークレット」入力、スコープは openid email profile
Facebook アプリ ID / シークレット 同上 → 「Facebook」プロバイダー作成
SAML (例: Azure AD) メタデータ URL または XML ファイル IdP > SAML → メタデータインポート、属性マッピングで email を設定
  • ポイント：外部 IdP の属性マッピングが正しく行われていないと、Cognito 側のユーザー属性（例：メール）が空になるためサインインに失敗します。
  • テスト方法：Cognito コンソールの「ホストされた UI」から対象プロバイダーを選択し、リダイレクト URL が正しく受信できるか確認してください。

4. アプリクライアントと OAuth フローの構成

認証フローは アプリケーションの種類（SPA、サーバーサイド、モバイル）に合わせて選択します。ここでは安全性が高く、現在 AWS が推奨している設定を中心に解説します。

アプリクライアント作成とシークレット設定

  1. ユーザープール左メニューの 「アプリクライアント」 → [クライアントを追加]
  2. クライアント名（例：MyAppWeb）を入力し、必要に応じて 「クライアントシークレットを生成」 にチェック
  3. サーバーサイドフロー（認可コードフローやクライアントクレデンシャル）は必ずシークレットが必要です。

  4. SPA はパブリッククライアントとしてシークレット不要、代わりに PKCE を有効化します。

  5. トークンの有効期限はデフォルトでも動作しますが、セキュリティ要件が厳しい場合は 1 hour 程度に短縮してください。

OAuth フロー選択基準

フロー 推奨シナリオ 主な特徴
認可コードフロー（PKCE） Web アプリ・モバイルアプリ クライアントシークレット不要、コードインジェクション防止
インプリシット 古い SPA（PKCE 未対応） トークンが直接返却されるため XSS リスク増大
クライアントクレデンシャル サーバー間 API 呼び出し ユーザー非依存、アクセストークンを安全に取得

注意：2026 年という予測ではなく、現在（2024‑2025）AWS が公式ドキュメントで推奨しているのは「認可コードフロー + PKCE」 です。PKCE によりコード盗聴やリプレイ攻撃が防げます。

コールバック URL とログアウト URL の設定

  1. アプリクライアント画面の 「OAuth 2.0 設定」 → 「コールバック URL」欄に許可する URI を列挙（改行区切り）
  2. 本番例：https://myapp.example.com/callback

  3. 開発例：http://localhost:3000/auth/callback （ローカルは http が許可される唯一の例外）

  4. 「サインアウト URL」欄にログアウト後の遷移先を入力（例：https://myapp.example.com/）

  5. HTTPS は必須 ですが、Cognito コンソールは http://localhost を明示的に許可しています。実運用で http を使用することは推奨されません。

ホストされた UI のロゴ・CSS カスタマイズ手順

  1. ユーザープール > 「ホストされた UI」 → 「カスタマイズ」タブを開く
  2. ロゴ画像：PNG/JPEG 最大 5 MB、推奨幅 300px 程度でアップロード
  3. Custom CSS に以下のようなシンプルなスタイルを貼り付ける

  1. 保存 → 「プレビュー」で反映を確認。CSS の変更は即座にホスト UI に適用されます。

5. 実務向けベストプラクティスとトラブルシューティング

ここでは運用時に最も注意すべき IAM 権限、コスト管理、典型的なエラー をまとめます。事前に対策を講じることで、障害対応工数を大幅に削減できます。

IAM ロールの最小権限設定（完全 JSON 例）

以下は Cognito ユーザープールのみを操作するアプリケーションが必要とする最小権限です。Resource を特定のプール ARN に絞り込むことで、さらにリスクを低減できます。

  • ベストプラクティス：Resource を arn:aws:cognito-idp:<region>:<account-id>:userpool/<pool-id> に限定し、不要な権限は除外します。
  • ロールの使用例：Lambda 関数や ECS タスクが Cognito API を呼び出す場合にこのポリシーをアタッチ。

コスト最適化とモニタリング

項目 最適化策
未使用プール cognito-idp:ListUserPools で取得し、ユーザー数が 0 のプールは自動削除（Automation via Lambda）
認証リクエスト数 CloudWatch メトリクス AuthenticatedRequests をダッシュボード化し、月次レポートで閾値超過時に SNS アラート
SMS 送信料 大量送信が予想される場合は Twilio 等外部プロバイダーへ切り替えるオプションを検討

ポイント：Cognito の課金モデルは MAU（Monthly Active Users）＋SMS 料金 が主体です。未使用のユーザープールだけでも固定費が発生するため、定期的なクリーンアップが重要です。

よくあるエラー例と対処フロー

エラーメッセージ 主な原因 対処手順
UserNotConfirmedException メール/電話番号の検証が未完了 管理者はコンソールで 「ユーザーを確認」、または API AdminConfirmSignUp を実行
InvalidParameterException: MFA is not enabled MFA が無効な状態で OTP 要求した Cognito コンソール > 「MFA と検証」 → MFA を必須またはオプションに変更
RedirectUriMismatchException コールバック URL がプール設定と不一致 アプリクライアントの「コールバック URL」を正確に列挙、ワイルドカードは使用不可
TooManyFailedAttemptsException パスワードリセットやサインイン失敗が上限超過 ロックアウトポリシーを確認し、管理者が AdminResetUserPassword でリセット
  • 共通のデバッグポイント：エラーメッセージは CloudWatch Logs にも出力されます。ログ検索（@message）でキー語句を絞り込み、設定ミス箇所を特定してください。

全体まとめ

  1. ユーザープール作成 → 正しいリージョン・プール名でウィザード完了
  2. 属性とパスワードポリシー → メール必須＋SMS フォールバック、12 文字以上の強固なパスワードを設定
  3. MFA と外部 IdP → TOTP をメインにし、SMS バックアップ・Google/Facebook/SAML を必要に応じて追加
  4. アプリクライアント & OAuth → PKCE 認可コードフローを基本とし、HTTPS のコールバック URL とシンプルな CSS カスタマイズでブランド統一
  5. 運用ベストプラクティス → 最小権限 IAM ポリシー、定期的な未使用プール削除、CloudWatch でのモニタリング、典型エラーの迅速対応

この手順を踏めば、セキュアかつコスト効率の高い Cognito 認証基盤 が構築できます。実装後は必ずステージング環境でフロー全体をテストし、本番移行時に予期せぬ障害が起きないことを確認してください。

スポンサードリンク

-Cognito