Contents
Amazon Cognito の概要と主要コンポーネント
Amazon Cognito は、モバイル・Web アプリケーション向けに 認証 と 認可 をサーバレスで提供するマネージドサービスです。本セクションでは、Cognito が提供する 3 つのコアコンポーネント（ユーザープール、ID プール、フェデレーション）について概要を示し、実装時に特に意識すべきポイントを整理します。これらを正しく理解した上で設計を進めることが、後続の設定ミスやセキュリティリスクを防ぐ第一歩となります。
ユーザープール
ユーザープールは認証情報（ユーザー名・パスワード・属性）を格納し、サインアップ／サインインフローを管理するデータベースです。以下の項目は作成時に必ず確認すべき重要設定です。
- パスワードポリシー
- 最低文字数（推奨 12 文字以上）
-
必須文字種（大文字・小文字・数字・記号）
-
メール / 電話番号の検証フロー
Auto verify emailとAuto verify phone numberの有効化-
検証コード送信方法（SES カスタムメール、SMS プロバイダー等）
-
カスタム属性と属性マッピング
- 外部 IdP（Google、Facebook 等）から受け取る属性を 1:1 に合わせる
- 必須属性の有無やデータ型（String, Number, Boolean）の統一
ID プール
ID プールは認証済みユーザーに対して AWS リソースへの 一時的なアクセス権（IAM ロール）を付与します。設定ミスが直接リソース漏洩につながるため、以下のポイントを重点的にチェックしてください。
- ロールマッピング
authenticatedとunauthenticatedの2種類の IAM ロールを明確に分離-
条件付きポリシーで最小権限（Least‑privilege）を実現
-
外部 IdP トークン受け入れ
- Google、Facebook、Apple 等から取得した OIDC / SAML トークンの署名検証設定
Tokenの有効期限とリフレッシュ処理のポリシーを統一
フェデレーション
フェデレーションは SAML や OIDC を利用して外部アイデンティティプロバイダー（IdP）と連携し、シングルサインオン（SSO）を実現します。以下の設定が不十分だと認証フロー全体が破綻するため、入念に確認しましょう。
- IdP メタデータの正確なインポート
- エンドポイント URL と X.509 証明書を最新状態で登録
-
メタデータ更新時は
Import→Overwriteの手順を忘れない -
属性マッピングとロール割当
- IdP が返す属性（例:
email,groups) と Cognito のカスタム属性を一致させる - SAML アサーションの
Role属性で IAM ロールを自動付与できるよう設定
まとめ：ユーザープールは認証情報、ID プールは AWS リソースへの権限付与、フェデレーションは外部 IdP 連携という役割分担が明確です。設計段階で「誰の情報をどこに保存し、どのリソースへ許可するか」を紙面に落とし込んだうえで、属性・ロールマッピングを漏れなく定義すれば、後続のトラブルは大幅に減少します。
実務で陥りやすい設定ミス 10 選
このセクションでは、実務で頻出する Cognito 設定ミスとその具体的な影響・回避策を一覧化しました。チェックリストとして活用し、設計レビュー時に必ず確認してください。
| No | ミス項目 | 典型的な影響例 | 推奨回避策 |
|---|---|---|---|
| 1 | パスワードポリシーが緩すぎる | 弱いパスワードでアカウント乗っ取りの危険性が高まる | 最低 12 文字、大小英数字＋記号を必須に設定。コンソールの「Password policy」から強制 |
| 2 | メール送信設定が不適切（SES がサンドボックス状態） | 認証メールが届かずサインアップ失敗 | SES のサンドボックス解除手順とドメイン検証を必ず実施（後述） |
| 3 | トークン有効期限のデフォルト設定放置 | 長時間有効なアクセストークンが不正利用に使われる | Access token expiration を 1 h 未満、Refresh token は必要最小限に短縮 |
| 4 | クライアントシークレットを SPA に埋め込む | フロントエンドから閲覧可能になり認証情報が漏洩 | SPA 用はシークレットなしの App Client を作成し、サーバー側で機密情報を保持 |
| 5 | 属性マッピングの不一致（外部 IdP とズレ） | SNS ログイン時に必須属性取得失敗 → エラー画面 | IdP 側と Cognito のカスタム属性名・型を 1:1 に合わせ、テストで検証 |
| 6 | MFA が未有効化 | パスワード漏洩時に二段階認証が機能せず被害拡大 | Required に設定し、SMS または TOTP を必須化。バックアップコードも提供 |
| 7 | メールアドレスの未検証でユーザーを許可 | 悪意あるユーザーが任意メールでアカウント取得可能 | 「Email verification」フラグと「Auto verify email」オプションを有効化 |
| 8 | ID プールのロール過剰付与 | 認証済みユーザーに管理者権限が付与される危険性 | IAM ポリシーで最小権限を徹底し、ロールマッピングを細分化 |
| 9 | Cognito トリガーのエラーハンドリング不足 | Lambda が例外をスローし認証フロー全体が停止 | try / catch と CloudWatch ログ出力を必ず実装、例外シナリオもテスト |
| 10 | カスタムドメイン未設定 | デフォルトドメインは共有 SSL 証明書のためフィッシングリスク増大 | ACM で証明書取得後に Cognito にカスタムドメインを割り当て、HTTPS を強制 |
結論：上記 10 項目は「設計 → テスト → 本番」サイクルのどこでも見落としがちです。レビュー時にチェックリスト化し、CI パイプラインで自動検証できるよう組み込めば、障害や予期せぬコスト増を大幅に抑制できます。
メール配信トラブルと SES 対策
Cognito が送信する認証メールが届かない多くのケースは SES のサンドボックスモード が原因です。このセクションでは、サンドボックス解除からドメイン認証・DKIM/DMARC 設定までの具体的手順を示します。正しい設定を行うことで、メール送信失敗によるユーザー離脱リスクを根本的に排除できます。
1. SES サンドボックス解除の流れ
以下はサンドボックス解除を実施する標準的な手順です。各ステップで必ず AWS コンソール上の画面キャプチャやログを残しておくと、トラブル時に原因追求が容易になります。
| 手順 | 内容 |
|---|---|
| a. 送信制限確認 | デフォルトは 200 件/24 h、5,000 件/月。コンソール → SES → Sending Statistics で現在のクォータを確認 |
| b. 解除リクエスト作成 | AWS Support の「Service limit increase」→「SES」→「Production access」へ申請。利用目的（認証メール）と所有ドメインの検証結果を添付 |
| c. 審査通過後 | 1 日以内に本番環境へ自動移行し、送信クォータが実質無制限に近いプランになる |
2. ドメイン認証と DKIM 設定
ドメイン所有権の検証と DKIM の有効化は、メール到達率を高める必須作業です。手順は次の通りです。
- Domain verification：Route 53（または使用中 DNS）に TXT レコードを追加し、SES コンソールで「Verify」ボタンをクリック。検証が成功するとステータスが
Verifiedになる。 - DKIM：SES が提供する CNAME レコード 3 つを同様に DNS に登録。ステータスが “Success” になるまで最大 72 時間待機。
3. SPF / DMARC のベストプラクティス
メール認証技術の組み合わせは、受信サーバ側でのスパム判定を大幅に緩和します。推奨レコード例は以下です。
| レコード | 推奨設定 |
|---|---|
| SPF | v=spf1 include:amazonses.com -all を DNS に追加 |
| DMARC | v=DMARC1; p=none; rua=mailto:postmaster@example.com（段階的に p=quarantine → p=reject） |
4. メール配信チェックリスト
実装後は次の項目を必ず確認し、CI パイプラインで自動テストできるようにします。
- [ ] SES が Production モードかどうか
- [ ] TXT / CNAME レコードが DNS に正しく反映（
digコマンドで検証） - [ ] DKIM ステータスが “Success” になるまで待機
- [ ] SPF と DMARC が有効化され、受信側レポートでエラーが出ていないか確認
結論：SES のサンドボックス解除とドメイン認証・DKIM/DMARC 設定は、Cognito メール配信障害を根本的に防ぐ必須作業です。チェックリスト化し CI に組み込めば、設定ミスの見落としがなくなります。
認証フローのエラーハンドリングとデバッグ方法
認証フローで発生するエラーはユーザー体験を直接損ねるだけでなく、システム全体の信頼性にも影響します。このセクションでは、代表的なエラーコードの意味と CloudWatch・X‑Ray を活用した可視化・アラート手法をご紹介します。
1. 主なエラーコードと発生シーン
以下は公式ドキュメントに掲載されている主要エラーです。実装時には必ず catch ブロックでこれらをハンドリングし、ユーザー向けの分かりやすいメッセージへ変換してください。
| エラー | 発生シーン | 主な原因例 |
|---|---|---|
InvalidParameterException |
サインアップ時に属性が不正 | 必須属性未設定、カスタム属性名のスペルミス |
NotAuthorizedException |
サインイン失敗 | パスワードポリシー違反、MFA 未完了 |
UserNotConfirmedException |
認証メール未検証でサインイン | メール送信設定不備、SES がサンドボックス状態 |
TooManyRequestsException |
高頻度リクエスト時 | デフォルトレートリミット 10 req/秒 超過 |
2. CloudWatch Logs を用いたリアルタイム監視
1️⃣ ロググループ作成：Cognito の「Advanced security」→「Log group」に cognito-auth と命名し、全ての認証イベントを出力。
2️⃣ フィルタパターン設定：{ $.eventType = "SignIn" && $.errorMessage != "" } でエラーのみ抽出できるので、ダッシュボード作成時に活用。
3️⃣ アラーム定義：5 分間にエラー件数が 10 件を超えたら SNS → Slack に通知するよう設定。
3. AWS X‑Ray でリクエストトレース
- 有効化手順：API Gateway と Lambda（カスタムチャレンジ）統合時に「Enable X‑Ray」をオン。
- 可視化ポイント：
cognito-idp.amazonaws.com呼び出しのレイテンシとエラー率をサービスマップで確認。遅延が顕在化したら Lambda のタイムアウトやネットワーク設定を見直す。
4. デバッグフロー（実装例）
以下はローカル環境から Cognito API を叩き、エラー時に CloudWatch へクエリするシンプルなスクリプトです。CI パイプラインのテストステップとして組み込めます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# 1. サインアップテスト（CLI） aws cognito-idp sign-up \ --client-id <APP_CLIENT_ID> \ --username test@example.com \ --password "Passw0rd!" \ --user-attributes Name=email,Value=test@example.com # 2. エラーが返ったら CloudWatch にフィルタクエリ aws logs filter-log-events \ --log-group-name cognito-auth \ --filter-pattern '{ $.eventType = "SignUp" && $.errorMessage != "" }' \ --start-time $(date -d "-5 minutes" +%s)000 |
まとめ：エラーコードを正しく把握し、CloudWatch と X‑Ray を組み合わせたモニタリング・アラート基盤を構築すれば、認証フローの障害原因を迅速に特定できます。
2025 年以降報告された脆弱性事例と防御策
近年公開された Cognito 関連の脆弱性は主に 外部 IdP のリダイレクト管理 と トークン寿命 に起因しています。ここでは 2025 年に報告された代表的なインシデントと、実装で取るべき防御策を具体例付きで解説します。
1. SNS 連携による不正請求問題（2025 年 4 月）
- 概要：Google / Facebook の OIDC 連携時に
redirect_uriが改ざんされ、攻撃者がユーザーの課金 API を呼び出すケースが報告された。 - 根本原因：Cognito のカスタムドメイン未使用と、
Allowed OAuth Flowsに対するホワイトリスト管理の不備。
防御策
| 対策 | 実装ポイント |
|---|---|
| リダイレクト URI を厳格化 | Cognito コンソールで Callback URLs に正規ドメインのみ登録。ワイルドカードは使用しない。 |
| PKCE（Proof Key for Code Exchange）を必須化 | Authorization Code フローに PKCE を設定し、サーバ側でコードベリファイを実装。 |
| WAF ルール適用 | AWSManagedRulesAmazonIpReputationList とカスタムレートリミット（例: 10 req/5 min）を適用し、不正リクエストを遮断。 |
2. トークンリプレイ攻撃（2025 年 9 月）
- 概要：取得した ID トークンが有効期限内に別サービスへ再利用され、認可バイパスが発生したケース。
- 根本原因：トークンの有効期間が長く、Revocation API が未使用だった。
防御策
| 対策 | 実装ポイント |
|---|---|
| 短い Access Token 有効期限 | 1 時間以下に設定し、リフレッシュは必須とする。 |
| トークン Revocation の徹底 | サインアウト時・パスワード変更時に /oauth2/revoke エンドポイントを呼び出す。 |
| WAF + Rate Limiting | 同一 IP からのトークン検証リクエストを秒間 5 回までに制限し、異常なリプレイを阻止。 |
結論：外部 IdP のリダイレクト管理とトークン寿命は、2025 年以降の脆弱性で最も多く指摘されています。カスタムドメイン・PKCE・WAF によるレートリミットを組み合わせれば、同様の攻撃シナリオは実質的に防げます。
設定ミス検知・テスト自動化と CI/CD 組み込み例
設定ミスを「リリース後」に発覚させないためには、CI パイプラインでの自動検証 が不可欠です。このセクションでは CloudWatch メトリクス・AWS Config ルール・GitHub Actions を活用した実装例と、最終的なチェックリストを提示します。
1. CloudWatch メトリクス／ログでのミス検出
| メトリクス | 監視対象 | 推奨アラート条件 |
|---|---|---|
SignUpSuccess |
正常なサインアップ数 | 正常時は特に設定不要 |
SignInFailure |
サインイン失敗回数 | 5 分間に 20 件超えたら SNS → Slack 通知 |
TokenRefreshError |
リフレッシュトークンエラー | 1 時間に 10 件以上でアラート |
2. AWS Config ルール活用
- カスタムルール
cognito-user-pool-password-policy-check - 内容：パスワードポリシーが「最低 12 文字、特殊文字必須」を満たすか評価。違反時は不適合としてレポート。
- マネージドルール
cognito-idp-ses-production-enabled - 内容：Cognito が使用する SES が Production モードであることを確認。サンドボックス状態なら非準拠と判定。
3. テスト項目の自動化例
| シナリオ | 確認内容 |
|---|---|
| ユーザー登録 | メール検証フロー、属性保存、エラーハンドリング（InvalidParameterException） |
| パスワードリセット | リセットトークン有効期限、メール配信成功、UI フロー完了 |
| SNS 連携 | redirect_uri のホワイトリスト、PKCE 動作確認、アクセストークンの短期化 |
| カスタムドメイン | ACM 証明書の有効性、HTTPS リダイレクト、Cognito のエンドポイント設定 |
GitHub Actions サンプルワークフロー（抜粋）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
name: Cognito CI on: push: paths: - 'cognito/**' jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Install AWS CLI run: pip install awscli - name: Run Integration Tests env: AWS_DEFAULT_REGION: ap-northeast-1 run: ./scripts/run_cognito_tests.sh config-check: needs: test runs-on: ubuntu-latest steps: - name: Evaluate Config Rules run: | aws configservice start-config-rules-evaluation \ --config-rule-names cognito-user-pool-password-policy-check \ cognito-idp-ses-production-enabled |
4. Cognito 設定ミス回避チェックリスト（最終まとめ）
| 項目 | 確認ポイント | 実施タイミング |
|---|---|---|
| パスワードポリシー | 長さ ≥ 12、大小英数字＋記号必須 | ユーザープール作成時 |
| メール送信設定 | SES Production、ドメイン/DKIM/SPF/DMARC 完了 | 初期デプロイ前 |
| トークン有効期限 | Access ≤ 1h、Refresh 必要最小限 | ID プール設定後 |
| MFA 設定 | TOTP または SMS を Required に |
セキュリティポリシー策定時 |
| 属性マッピング | IdP と 1:1 整合性確認（テスト実施） | フェデレーション連携テスト |
| カスタムドメイン & HTTPS | ACM 証明書適用、リダイレクト強制 | 本番環境デプロイ前 |
| WAF / Rate Limit | SNS 連携・トークンエンドポイントにルール適用 | セキュリティレビュー時 |
| CloudWatch アラート | SignInFailure / TokenRefreshError の閾値設定 | CI/CD デプロイ後 |
| AWS Config ルール | パスワードポリシー・SES Production を監視 | 定期的（週次） |
| テスト自動化 | 上記4シナリオを GitHub Actions / CodePipeline に組込 | PR マージ時 |
最終結論：Cognito の設定ミスは「設計 → 自動テスト → 本番モニタリング」のサイクルで早期に検知・修正できます。上記チェックリストと CI/CD 組み込み例をプロジェクト標準として採用すれば、セキュリティインシデントのリスクを大幅に低減し、安定した認証基盤を提供できるでしょう。
本稿は 2025 年までに公表された公式情報・実務事例を元に作成しています。AWS のサービス仕様は随時変更されるため、最新ドキュメントの確認を併せて行ってください。
