AWS Cognito MFA認証方式 詳細比較表
目次
- 概要
- セキュリティ観点
- ユーザビリティ観点
- 実装・技術観点
- コスト・リソース観点
- 運用・管理観点
- 統合比較一覧表
- 方式選定フローチャート
概要
AWS Cognito では、以下の3つのMFA方式が利用可能です:
セキュリティ観点
1. 認証強度
SMS
- プラス点:
- 電話番号は個人に紐付く比較的固有な属性
- デバイスの所有確認に近い認証が可能
- SIMスワップ攻撃まで対応した場合、かなり強固
- マイナス点:
- SIMスワップ攻撃に脆弱(攻撃者が携帯キャリアに詐称し、別のSIMで同じ番号を受け取る)
- SS7プロトコルの既知の脆弱性により、傍受リスク存在
- オンプレミスの古い基盤施設でセキュリティが低い場合あり
- 転送、スプーフィングのリスク
- 脆弱性レベル: 中程度 ~ 中高 (攻撃キャリアは限定的)
メール
- プラス点:
- OTP自体は時間限定、ワンタイムであり理論上安全
- メールアドレス確認による二重確認ロジックが実装可能
- マイナス点:
- メールアカウント侵害時に全MFA機能が失われる(単一障害点)
- メール配送遅延の可能性
- メールクライアント上での内容表示リスク
- フィッシング攻撃の対象になりやすい
- メール中継サーバー上での傍受リスク
- 脆弱性レベル: 中程度 (メールアカウント侵害のリスクが高い)
TOTP
- プラス点:
- ネットワーク通信不要で、オフラインでも動作
- サーバー側に秘密鍵を保持しないため、サーバー侵害時も秘密鍵は漏洩しない
- 配送遅延なし
- バックドア攻撃への耐性高い
- 利用者本人所有のデバイス(スマートフォン)に依存
- マイナス点:
- デバイス盗難時は無効(ただし物理的盗難のため攻撃難度高い)
- バックアップコード紛失時のリカバリが困難
- QRコード読み込み時のフィッシング攻撃リスク
- 脆弱性レベル: 低い ~ 非常に低い (実装の安全性に大きく依存)
2. 攻撃ベクトル別の耐性
3. コンプライアンス・規制面
ユーザビリティ観点
1. ユーザー負担
SMS
- セットアップ負担: 低
- 使用時負担: 低
- SMS受信を待つだけ
- ただしSMS受信に1~30秒の遅延あり
- 習熟度: 高(ほぼ全ユーザーが理解)
メール
- セットアップ負担: 低~中
- メールアドレスのみ必要
- 追加アプリ不要
- ただしメール確認の習慣必要
- 使用時負担: 低~中
- メール確認に5秒~数分かかる場合あり
- メール中複数のOTPが混在する場合、探索が必要
- 習熟度: 中(メール操作不慣れユーザーは困惑可能性)
TOTP
- セットアップ負担: 中~高
- 認証アプリのインストール必須
- QRコード読み取り必要
- 秘密鍵のバックアップ取得推奨
- リカバリコード生成・保管必須
- 使用時負担: 低
- 習熟度: 低(高齢者やテク不慣れユーザーは導入抵抗大)
2. アクセス性
3. 紛失・復旧シナリオ
実装・技術観点
1. Cognito での利用可能性
SMS
- 必須ユーザー属性:
phone_number
- 必須リソース: なし(SMS配送は AWS SNS が内部利用)
- 必須Tier: Lite 以上
- 設定方法: Cognito コンソール / API / CDK で直接設定可能 ✓
- 複雑度: 低
メール
- 必須ユーザー属性:
email
- 必須リソース: SES(Simple Email Service) (カスタマー管理)
- 必須Tier: Essentials 以上
- 設定方法: API / CDK で設定(コンソール上では不完全)
- 複雑度: 中 参考: 記事内で指摘されている制約
- MFA と パスワードリセット を同じメール宛先にできない(Cognito の設計上の制限)
- 回避策として Custom SMS Sender Lambda が必要
TOTP
- 必須ユーザー属性: なし
- 必須リソース: なし(ユーザー側で認証アプリを用意)
- 必須Tier: Lite 以上
- 設定方法: Cognito コンソール / API / CDK で直接設定可能 ✓
- 複雑度: 低
2. セットアップの複雑度
SMS
1. phone_number 属性を必須に設定
2. Cognito で SMS MFA を有効化
3. ユーザーに電話番号を登録させる
完了
所要時間: 30分 ~ 1時間
メール
1. SES ドメイン認証(必須)
- ドメイン検証メール受け取り
- SPF / DKIM / DMARC 設定
2. メール送信制限解除(必須、初期状態は Sandbox)
- AWS Support への申請
- 申請から数日待機
3. email 属性を必須に設定
4. Cognito でメール MFA を有効化
5. Custom SMS Sender Lambda 設定(パスワードリセット対応の場合)
- KMS 暗号化キー準備
- Lambda 関数作成
- IAM ロール設定
- Cognito トリガー統合
完了
所要時間: 2~5日(SES 申請待ち含む)
TOTP
1. TOTP MFA を有効化
2. ユーザーが認証アプリをダウンロード
3. QRコード読み取り
4. バックアップコード保管
完了
所要時間: 15分 ~ 30分
3. ユーザーの登録・更新時の挙動
4. API レベルの統合
SMS
# Cognito の initiate_auth で SMS OTP を要求
client.respond_to_auth_challenge(
ClientId='...',
ChallengeName='SMS_MFA',
ChallengeResponse='123456',
Session='...'
)
メール
# Cognito の initiate_auth で メール OTP を要求
client.respond_to_auth_challenge(
ClientId='...',
ChallengeName='MFA_REQUIRED', # or 'EMAIL_OTP'
ChallengeResponse='123456',
Session='...'
)
TOTP
# Cognito の initiate_auth で TOTP を要求
client.respond_to_auth_challenge(
ClientId='...',
ChallengeName='SOFTWARE_TOKEN_MFA',
ChallengeResponse='123456',
Session='...'
)
5. バックアップ・復旧メカニズム
SMS
- バックアップ方式:
- セカンダリ電話番号設定(Cognito 標準機能)
- Security Questions(別途実装)
- 復旧難度: 低(運用者が電話番号を再設定可能)
メール
- バックアップ方式:
- セカンダリメールアドレス設定(Cognito 標準機能)
- 復旧難度: 中(メールアカウント侵害時は全て失われる可能性)
TOTP
- バックアップ方式:
- バックアップコード(Cognito 標準機能、一度限り)
- セカンダリ TOTP デバイス(別途実装)
- 復旧難度: 高(バックアップコード紛失で復旧困難)
コスト・リソース観点
1. 直接コスト(2026年5月現在、アジアパシフィック東京リージョン)
注記:
- SMS コストは日本国内への送信料金
- メールは AWS SES の無料枠(月500件)を超える場合のコスト
- Cognito の MFA 機能自体は無料(Tier による制限あり)
2. 間接コスト
SMS
- インフラ:
- SMS Gateway(Cognito が AWS SNS 経由で提供)
- 追加リソースなし
- 管理:
- トラブル:
- SMS 未配送への対応窓口必要
- 国別のSMS配送ルール対応
メール
- インフラ:
- SES セットアップ(ドメイン認証、SPF/DKIM)
- SES から Cognito への IAM ロール設定
- 場合により Lambda(Custom Sender)
- 管理:
- SPF / DKIM / DMARC レコード管理
- SES 送信制限の監視(Bounce Rate, Complaint Rate)
- セキュリティ証明書の更新
- トラブル:
- メール未配送の原因調査(SPF 失敗、IP ブロック等)
- 迷惑メールフォルダ対応
- DMARC Policy の適用度確認
TOTP
- インフラ:
- 管理:
- バックアップコードの安全な保管方法確認
- 認証アプリの対応状況確認
- トラブル:
- デバイス紛失時のサポート
- バックアップコード再生成プロセス
3. スケーラビリティ
運用・管理観点
1. デバイス・属性管理
SMS
- 電話番号の妥当性確認:
- Cognito では
verified_phone_number フラグで確認状態を管理
- 実際の配送確認は Cognito がハンドル
- 更新時の確認コード送信は自動
- 属性更新時のフロー:
ユーザー入力 → OTP送信 → OTP確認 → 属性更新
メール
- メールアドレスの妥当性確認:
- Cognito では
verified_email フラグで確認状態を管理
- 手動確認かメール配信確認コードで実施
- 属性更新時のフロー:
ユーザー入力 → 確認メール送信 → リンククリック → 属性更新
TOTP
- 秘密鍵管理:
- デバイス本体に格納(Cognito では管理しない)
- バックアップコードのみ Cognito で保管
- セットアップフロー:
1. Cognito が秘密鍵を生成2. QRコード表示(Base64 エンコード)3. ユーザーが認証アプリで読み込み4. 秘密鍵はデバイスに保存5. Cognito からは削除
2. ヘルプデスク対応
SMS
- よくある問題:
- SMS 未受信(遅延 or 紛失)
- 電話番号変更
- キャリア変更で同じ番号が使えない
- 対応窓口必要レベル: 高(SMS 未配送は多い)
メール
- よくある問題:
- メール未受信(迷惑メール含む)
- メールアカウント侵害
- メールアドレス変更
- 対応窓口必要レベル: 中~高(メール未配送、迷惑メール多い)
TOTP
- よくある問題:
- 認証アプリを削除してしまった
- 対応: バックアップコードで復旧(バックアップコード紛失時は回復不可)
- デバイス紛失
- 対応: ユーザーが自分で新デバイスに再セットアップ(バックアップコード必須)
- TOTP の時刻ズレ
- 対応窓口必要レベル: 低~中(技術的な対応は限定的)
3. 属性の必須性・可変性
SMS
【課題】Cognito では必須属性作成後に変更不可
・phone_number を必須にしたら、後から削除不可
・既存ユーザーの移行が困難
【回避案】
・ユーザープール作成時に phone_number を必須にしない
・代わりにアプリケーション側で validation + DB確認
・管理画面で phone_number 属性の充足状況をチェック
メール
【一般的に email は必須属性で問題ない】
・ほぼ全ユーザーがメールアドレスを持つ
・Cognito の email 属性も標準的
・後から削除する可能性は低い
TOTP
【課題】TOTP は Cognito の必須ユーザー属性ではない
・セットアップは任意
・段階的導入が可能
・既存ユーザーへの追加導入が容易
【利点】
・最も柔軟な導入が可能
4. 監視・ロギング
SMS
- 監視項目:
- SMS 送信成功率
- 配送遅延時間
- キャリア別のブロック状況
- ログ出力: CloudWatch → CloudTrail で Cognito イベント記録
- アラート設定: 配送失敗率 > 5% 時に通知
メール
- 監視項目:
- SES 送信成功率
- Bounce Rate(SES メトリクス)
- Complaint Rate(SES メトリクス)
- 迷惑メール判定率
- ログ出力:
- SES Event Publishing → SNS / CloudWatch
- CloudTrail でログイン試行回数
- アラート設定:
- Bounce Rate > 5% で警告
- Complaint Rate > 0.1% で即座にサスペンド(SES 仕様)
TOTP
- 監視項目:
- TOTP セットアップ率(全ユーザー比)
- バックアップコード再生成率
- MFA チャレンジ失敗率
- ログ出力: CloudTrail で Cognito イベント記録
- アラート設定: TOTP 失敗率 > 10% でシステム異常を疑う
統合比較一覧表
総合評価マトリックス
方式選定フローチャート
Step 1: セキュリティ要件の確認
Question: 最高レベルのセキュリティが必須か?
├─ YES → TOTP 推奨
│ (バックアップコード管理が課題→二重TOTP検討)
│
└─ NO → Step 2 へ
Step 2: ユーザー母集団の特性
Question: ユーザーが高齢者や非テク層が多いか?
├─ YES → SMS 推奨
│ (セットアップが最も簡単)
│
└─ NO → Step 3 へ
Step 3: コスト感度
Question: スケール時のコスト増加を最小化したいか?
├─ YES → メール or TOTP 推奨
│ (認証数に関わらずコスト固定 or 無料)
│
└─ NO → Step 4 へ
Step 4: グローバル展開
Question: 多国籍ユーザー対応が必須か?
├─ YES → TOTP or メール推奨
│ (SMS は国別配送ルール複雑)
│
└─ NO → Step 5 へ
Step 5: 運用負担度
Question: ヘルプデスク対応を最小化したいか?
├─ YES → TOTP 推奨
│ (技術的サポート最小)
│
└─ NO → Step 6 へ
Step 6: 実装期限
Question: 短期導入が必須か?
├─ YES → SMS 推奨
│ (SES 申請待ちなし)
│
└─ NO → TOTP 推奨
(長期で最適、初期投資で後々効率化)
推奨パターン
詳細実装チェックリスト
SMS 導入チェックリスト
□ phone_number 属性が必須か、任意か確認
□ キャリア別の配送遅延を加味した timeout 設定
□ 国別 SMS ルール(中国、韓国等の特例)確認
□ 複数キャリアでのテスト実施
□ フェイルオーバー方式検討(例: 再試行上限)
□ コスト見積(月間想定認証数 × $0.075)
□ ヘルプデスク体制の構築
□ SMS 未配送時の復旧フロー設計
メール導入チェックリスト
□ SES ドメイン認証(SPF / DKIM / DMARC)完了
□ SES 本番環境への申請完了
□ カスタマー管理 SES リソースへの IAM 権限設定
□ Custom Sender Lambda の実装検討(パスワードリセット統一の場合)
□ KMS キー設定(暗号化必須)
□ SES Bounce / Complaint 監視体制構築
□ 迷惑メールフォルダ対策(リスト登録呼びかけ)
□ メール本文のテンプレート設計
□ 送信失敗時の再試行ロジック
□ SES 送信レート制限の把握(1秒あたり上限等)
TOTP 導入チェックリスト
□ 認証アプリの推奨ツール決定(Google Authenticator, Microsoft Authenticator 等)
□ バックアップコード生成&保管フロー設計
□ バックアップコード紛失時の復旧プロセス確認
□ 段階的導入スケジュール(全員必須 vs 任意)
□ QRコード生成時のセキュリティ確認(トランスポート層)
□ デバイス同期時の NTP 設定確認(時刻ズレ対応)
□ バックアップ TOTP 二台目デバイスの必須化検討
□ ユーザー教育の実施(QRコード読み込み方法等)
□ ヘルプデスク向けトレーニング(バックアップコード再発行方法)
まとめと推奨
最終推奨
- セキュリティ&コスト重視: TOTP (強く推奨)
- 長期的な最適解
- 認証数増加でもコスト不変
- セキュリティ基準で最高評価
- NIST / PCI-DSS 準拠
- バランス型: メール (次点)
- SES 設定の初期投資あり
- 以降はコスト固定
- ユーザビリティも良好
- 国内 SaaS に適している
- 短期導入&ユーザビリティ優先: SMS
- セットアップ最速
- ユーザー負担最小
- ただしセキュリティとコスト面でトレードオフ
- 高齢ユーザー層向け
複合アプローチ
最も堅牢な構成:
メイン: TOTP(セキュリティ&コスト)
バックアップ1: メール(バックアップコード紛失時)
バックアップ2: SMS(メール侵害時)
この組み合わせにより、単一障害点を排除し、全てのシナリオで復旧可能な設計が実現できます。
参考資料
コメント