【Security Hub修復手順】[Cognito.5] Cognito ユーザープールに対して MFA を有効にする必要があります

AWS SecurityHub 基礎セキュリティのベストプラクティスコントロール修復手順をご紹介します。
AWS Security Hub 基礎セキュリティのベストプラクティスコントロール修復手順
2026.09.16
こんにちは！コンサルティング部のみゃんです。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか？
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
 本記事の対象コントロール[Cognito.5] Cognito ユーザープールに対して MFA を有効にする必要があります
[Cognito.5] MFA should be enabled for Cognito user pools
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/cognito-controls.html#cognito-5
 前提条件本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。

AWS Security Hubの詳細についてはこちらのブログをご覧ください。
https://dev.classmethod.jp/articles/lets-learn-aws-security-hub/
https://dev.classmethod.jp/articles/aws-security-operation-with-securityhub-2021/
 対象コントロールの説明このコントロールは、パスワードのみのサインインポリシーが設定されたCognitoユーザープールで、多要素認証（MFA）が有効になっているかをチェックします。MFAが無効（MfaConfigurationがOFFまたはOPTIONAL）の場合に、このコントロールは失敗します。MFAの強制設定を「必須」にすることで、このコントロールは成功します。
フェデレーション認証のみを使用するユーザープールと、パスワードレスサインインのみを使用するユーザープールは評価対象外です。フェデレーションユーザーの認証はIdP（IDプロバイダー）に委任されるため、Cognito側のMFA設定は適用されません。
MFAは、ユーザー名とパスワードという「知っていること」の認証要素に、「持っていること」の認証要素を追加する認証方式です。Cognitoユーザープールでは、第2の認証要素としてSMSメッセージ、Eメールメッセージ、Authenticatorアプリ（TOTP）の3種類を選択できます。
パスワードのみの認証では、他サービスから漏洩した認証情報を悪用するクレデンシャルスタッフィング（パスワードリスト攻撃）や、フィッシングによるパスワード窃取によって、アカウントを乗っ取られるリスクがあります。MFAを有効にすると、パスワードが漏洩した場合でも、攻撃者が追加の認証要素を取得しないかぎりサインインを完了できないため、アカウント乗っ取りのリスクを大幅に低減できます。ただし、SMS・Eメール・TOTPはいずれもフィッシングなどに対して完全ではありません。
MFAの方法を選ぶ際は、前提条件が異なる点に注意してください。
Authenticatorアプリ（TOTP）: Amazon SNS、Amazon SES、送信用IAMロールなどの外部リソースは不要。ただし、ユーザープールでTOTPを有効化し、ユーザーごとにAuthenticatorアプリの登録・検証を行う必要がある。
SMSメッセージ: Amazon SNSからSMSを送信するためのIAMロールの設定が必要。ユーザーにphone_number属性が必要
Eメールメッセージ: 機能プランがEssentialsまたはPlusであることと、Amazon SESの検証済み送信元IDの設定が必要。ユーザーにemail属性が必要
詳しくは以下公式ドキュメントをご確認ください。
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa-totp.html
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-sms-settings.html
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-email.html?utm_source=openai
 修復手順 コントロールの確認方法Security Hubコンソールを開く
左メニューから「検出結果」を選択
フィルターで対象のコンプライアンスセキュリティコントロール ID「Cognito.5」を検索
検出結果の詳細から、対象のユーザープール名（リソースID）を確認する
 ステークホルダーに確認MFAの強制設定を「必須」にすると、既存ユーザーは次回サインイン時にMFAの登録を求められます。アプリケーション側の実装変更が必要になるため、修復を行う前に以下の点を確認してください。
対象ユーザープールを利用しているアプリケーションの範囲と、利用者への周知方法・周知のタイミング
アプリケーションがマネージドログインを使用しているか、SDKで独自のサインイン画面を実装しているか。SDKで実装している場合は、SELECT_MFA_TYPEおよびMFA_SETUPチャレンジへの応答処理をアプリケーション側に実装する担当者
採用するMFAの方法と、それに伴う前提設定の担当者（SMSの場合はAmazon SNS用IAMロール、Eメールの場合は機能プランの変更とAmazon SESの送信元ID設定）
アカウント復旧（パスワードを忘れた場合）の配信方法。MFAの方法と同じ配信方法は使えないため、SMSとEメールの割り当てを整理する
脅威保護のアダプティブ認証をフル機能モードで使用する予定があるか。使用する場合、MFAの強制設定は「任意」にする必要がある
 修復手順ここではAuthenticatorアプリ（TOTP）をMFAの方法として設定する手順を記載します。
Amazon Cognitoコンソールを開く
左メニューから「ユーザープール」を選択し、対象のユーザープールを選択する
「サインイン」メニューを選択し、「多要素認証」の「編集」を選択する
「MFA の強制」で「必須」を選択する
「MFA の方法」で「Authenticator アプリ」にチェックを入れる
「変更を保存」を選択する
SMSメッセージをMFAの方法にする場合は、手順5の前にAmazon SNS用のIAMロールを設定します。「認証方法」メニューで「SMS」の「編集」を選択し、IAMロールを作成または選択してください。AWSアカウントがSMSサンドボックスの状態にある場合は、送信先の電話番号をAmazon SNS側で事前に検証する必要があります。
EメールメッセージをMFAの方法にする場合は、機能プランがEssentialsまたはPlusである必要があります。あわせて「認証方法」メニューで「Eメール」の「編集」を選択し、「SES で E メールを送信」を選んだうえで、Amazon SESの検証済みIDから送信元のEメールアドレスを選択してください。
 修復確認設定後、ユーザープールの「サインイン」メニューで「多要素認証」が「必須」になっていることを確認します。
AWS CLIでも確認できます。
aws cognito-idp get-user-pool-mfa-config \
  --user-pool-id <ユーザープールID> \
  --region <リージョン>
MfaConfigurationがON、SoftwareTokenMfaConfiguration.Enabledがtrueになっていれば設定は完了しています。

修復後、Security Hubで検出結果が「PASSED」になることを確認します。
参考までに、MFAがOPTIONALに設定されている場合も、ポリシー違反として、検知されます。
オプションのMFAを有効化しても、違反状態(FAILED)は解消されませんでした。
そこで試しに新しくユーザープールを作成して、一度コンプライアンスのステータスがPASSEDになるように、「MFA の強制」を有効化しました。

SecurityHub CSPM上でPASSEDになっていることを確認した後、先ほどと同様に「オプションの MFA」を有効化しました。

するとPASSEDからFAILEDになりました。



つまり、ポリシー違反を解消するためには、MFAを強制する必要があるということですね。
 最後に今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう！
最後までお読みいただきありがとうございました！どなたかのお役に立てれば幸いです。
以上、みゃんでした！