はじめに
GMOコネクトの永田です。
「Cognitoを使えば認証機能は簡単に実装できる」— そう思っていませんか？
実は、デフォルト設定のまま本番運用すると、深刻なセキュリティリスクが潜んでいる可能性があります。 実際に脆弱性診断を受けると、Cognitoの設定不備による指摘を受けるケースは少なくありません。
本記事では、AWS Cognitoのセキュリティ設定を見直した経験をもとに、実際に脆弱性診断で指摘されやすいポイントを中心にチェックリストとしてまとめました。新規構築時の設計レビューや、既存システムのセキュリティ強化にぜひお役立てください。
Cognitoセキュリティ関係設定のチェックリスト
以下、Cognito UserPoolを利用する場合の、特に重要なチェックポイントを、箇条書きで記載します。（それぞれの詳細は後述）
なお以下の機能は今回のチェックリストに含まれていないため、ご注意ください
- Cognito ID Pool
- Cognito domain付与によるOIDC APIの利用
- Cognito Managed Login(Hosted UI)
チェックリスト（サマリー）
※サービス要件や認証認可のユースケースによって対応要否が変わりますのでご注意ください
- セルフサインアップ設定が有効化されていないか？
- Cognito属性の書き込み権限が過剰ではないか？
- Cognito属性の読み込み権限が過剰ではないか？
- 認証フローが過剰ではないか？
- Cognitoデフォルト設定から緩和した設定は、セキュリティリスクを検討したか？
参考資料
チェック内容詳細
(1) セルフサインアップ設定が有効化されていないか？
Cognito作成時に表示される注意事項の通りです。デフォルトで有効になっているため、気にせずにポチポチっと作成すると、見落とすことが多いです。
ユーザープールでユーザーサインアップをアクティブ化すると、インターネット上のあらゆるユーザーがアカウントにサインアップしてアプリケーションにサインインできます。誰でもアプリケーションにサインアップできるようにすることを決定するまでは、ユーザープールで自己登録を有効にしないでください。
ホストされた UI のサインインページに [サインアップ] リンクを表示し、新しいユーザーアカウントを作成するためにパブリック API を使用することを許可します。この機能が有効になっていない場合、フェデレーションおよび管理 API オペレーションがユーザープロファイルを作成します。
例えば招待制のサービスの場合にこの設定が有効のままだと、意図しないユーザーがアカウント作成できてしまいます。また、Googleアカウントなどのソーシャル経由のログインのみを想定している場合も、ソーシャルではない経路でアカウント作成されたりします。
そのため、セルフサインアップ（自己登録）が必要か？は、サービスのユースケースをよく検討した上で、設定をしてください。
「誰でもアプリケーションにサインアップできるようにすることを決定するまでは、ユーザープールで自己登録を有効にしないでください。」と説明があるのですが、それならデフォルトで無効にしておいて欲しい😇
また、セルフサインアップがユースケースにあるサービスでも、諸々の入力やチェックをした上でアカウント発行したいケースもあるかと思います。この場合も本設定は無効にしておき、プログラムで諸々チェックした上でCognito APIによりアカウント発行するのが良いです。（有効だと、プログラムで諸々チェックがbypassされ、直接Cognitoにサインアップできちゃいます。）
(2) Cognito属性の書き込み権限が過剰ではないか？
Cognito UserPoolでは、ユーザー毎に属性を持つことができます。属性としては「標準属性」と「カスタム属性」があります。
そのため、ユーザー毎の設定値などをCognitoで管理するアーキテクチャも技術的には可能です。
（ただ、パフォーマンスやコスト面などを考えると、Cognito subjectをpkeyにDynamoDBなど外部で管理する方が良いですが）
Cognitoに追加したカスタム属性ですが、クライアントから操作（読み書き）する権限を、アプリケーションクライアントで設定可能です。権限があると、ログイン時に発行されたアクセストークンを利用し、直接Cognitoに対して読み書きが可能になります。
カスタム属性を追加する場合、デフォルトでは「読み書き」可能となっています。（ 変更可能 のチェック）
上記のようにUserPoolにカスタム属性を追加すると、アプリケーションクライアントもデフォルトでは以下のように読み書き可能となります。（その後、設定で変更可能）
この場合、is_admin のフラグを利用者が好きなように編集可能です。
認可制御などでCognitoの属性を利用するアーキテクチャの場合、意図しない権限昇格につながりますので、利用者が直接属性変更をする権限が必要か？は、サービスの要件を元に精査するようにしてください。
(3) Cognito属性の読み込み権限が過剰ではないか？
上記の読み込み権限の部分です。
UserPoolの属性として、内部利用の値 をカスタム属性で追加した場合に問題となります。
読み込みを許可するとCognitoから直接値を読み込めるだけではなく、Cognitoが発行するトークンの中身(payload)にも該当の値が入ります。
不要な属性をトークンに含むことで、データの漏洩リスクが増えたり、トークンサイズの増大（通信量の増大）などのデメリットがありますので、書き込み権限と合わせ、サービスにとっての最小権限が何か？は、精査をお願いします。
(4) 認証フローが過剰ではないか？
Cognitoではユーザー（またはシステム）がどのような手段でログインするか？を、設定可能です。
構築直後のデフォルトは以下となっています。
Cognitoデフォルトの認証機能のみを利用する場合にはこれで問題ありません。
カスタム認証Lambdaを使う場合の重要な注意点:
カスタム認証Lambda経由での認証のみを意図している場合、以下の認証フローが有効だと、カスタム認証のロジックをバイパスして認証できるルートが残ってしまいます：
-
ALLOW_USER_AUTH: 選択ベース認証（ユーザーが認証方法を選択可能） -
ALLOW_USER_PASSWORD_AUTH: ユーザー名・パスワードのみで即座に認証 -
ALLOW_USER_SRP_AUTH: SRP認証のみで即座に認証 -
ALLOW_ADMIN_USER_PASSWORD_AUTH: サーバー側の管理者認証
具体的な問題:
これらの認証フローでは、DefineAuthChallenge等のLambda Triggerが実行されず、Cognito内部で直接パスワード検証が行われます。そのため、カスタム認証で実装した独自のロジック（例: OTP検証、リスクベース認証、特定条件下での追加チャレンジ等）が完全にスキップされてしまいます。
推奨設定（カスタム認証を必須とする場合）:
- ✅
ALLOW_CUSTOM_AUTH: 有効（カスタム認証フローのみ） - ✅
ALLOW_REFRESH_TOKEN_AUTH: 有効（トークン更新用） - ❌ その他の認証フローは無効化
脆弱性診断では、この設定不備により「認証バイパス」として指摘されることがあります。
Cognitoカスタム認証については、以下の公式リファレンスなどを参照してください。
(5) Cognitoデフォルト設定から緩和した設定は、セキュリティリスクを検討したか？
トークンの有効期限など、Cognitoがデフォルトで設定している値は、それなりのセキュリティベストプラクティスに沿っています。（と信じています）
そのため、これらの値を緩和した場合（例: アクセストークン有効期限を1時間-->24時間）には、セキュリティリスクが上がることになりますので、変更前に慎重にリスクを検討してください。
（緩和すると、脆弱性診断で指摘されたりします😇）
トークンの有効期限や、
パスワードポリシー、仮パスワードの有効期限の緩和時にはご注意ください。
特にパスワード最小文字数の設定には注意が必要です。
Cognitoのデフォルトは8文字ですが、これは現代のセキュリティ基準では不十分とされています。脆弱性診断では「脆弱なパスワードポリシー」として指摘される可能性が高いため、最小12文字以上への変更を推奨します。
補足: セキュリティをさらに強化したい場合は?
Cognitoには複数の料金プラン（Tier）があり、上位プランではより高度なセキュリティ機能が利用できます。
主な高度なセキュリティ機能（Essentials / Plus Tier）:
- 漏洩済み認証情報の検出: 過去に漏洩したパスワードデータベースと照合し、危険なパスワードの使用を自動的にブロック
- アダプティブ認証: 不審なログイン試行を自動検出し、追加の認証チャレンジを要求
- 疑わしい変更の通知: パスワード変更等の重要な操作時にユーザーへ自動通知
料金プランの検討ポイント:
現在Lite Tierを使用している場合、Essentials/Plus Tierへの移行により料金が増加する可能性があります。ただし、脆弱性診断で「パスワードポリシー強化」「認証変更時の通知不備」などが指摘された場合、カスタムLambdaで実装するよりも、これらのマネージド機能を活用する方が保守性・信頼性の観点で有利なケースがあります。
サービスのセキュリティ要件と予算を考慮し、適切なプランを選択してください。
参考: https://dev.classmethod.jp/articles/new-feature-tiers-cognito/
まとめ
AWS CognitoなどのIDaaSは認証機能を迅速に実装できる強力なツールですが、「簡単に使える」≠「安全に使える」 ということを忘れてはいけません。
本記事で紹介した主要チェックポイントを再掲します：
- セルフサインアップは本当に必要か確認（デフォルト有効に注意）
- カスタム属性の読み書き権限は最小権限に設定
- カスタム認証使用時は認証フローのバイパスルートをチェック
- パスワードポリシーは最小12文字以上を推奨
- トークン有効期限などデフォルト値からの緩和は慎重に判断
認証認可はシステムのセキュリティの要です。不安がある場合は、専門家によるセキュリティレビューを受けることを強くお勧めします。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。