AWS Cognito MFA認証方式詳細比較表

目次
概要
セキュリティ観点
ユーザビリティ観点
実装・技術観点
コスト・リソース観点
運用・管理観点
統合比較一覧表
1. 総合評価マトリックス
方式選定フローチャート
詳細実装チェックリスト
まとめと推奨
1. 最終推奨
2. 複合アプローチ
参考資料

概要

AWS Cognito では、以下の3つのMFA方式が利用可能です：

方式	概要
SMS	ショートメッセージサービスを使用して、ワンタイムパスワードをユーザーの携帯電話に送信
メール	メールアドレスへワンタイムパスワード（OTP）を送信
TOTP	Time-based One-Time Password。認証アプリ（Google Authenticator等）を使用して生成されるパスワード

セキュリティ観点

1. 認証強度

SMS

プラス点：
- 電話番号は個人に紐付く比較的固有な属性
- デバイスの所有確認に近い認証が可能
- SIMスワップ攻撃まで対応した場合、かなり強固
マイナス点：
- SIMスワップ攻撃に脆弱（攻撃者が携帯キャリアに詐称し、別のSIMで同じ番号を受け取る）
- SS7プロトコルの既知の脆弱性により、傍受リスク存在
- オンプレミスの古い基盤施設でセキュリティが低い場合あり
- 転送、スプーフィングのリスク
脆弱性レベル: 中程度 ～中高（攻撃キャリアは限定的）

メール

プラス点：
- OTP自体は時間限定、ワンタイムであり理論上安全
- メールアドレス確認による二重確認ロジックが実装可能
マイナス点：
- メールアカウント侵害時に全MFA機能が失われる（単一障害点）
- メール配送遅延の可能性
- メールクライアント上での内容表示リスク
- フィッシング攻撃の対象になりやすい
- メール中継サーバー上での傍受リスク
脆弱性レベル: 中程度 （メールアカウント侵害のリスクが高い）

TOTP

プラス点：
- ネットワーク通信不要で、オフラインでも動作
- サーバー側に秘密鍵を保持しないため、サーバー侵害時も秘密鍵は漏洩しない
- 配送遅延なし
- バックドア攻撃への耐性高い
- 利用者本人所有のデバイス（スマートフォン）に依存
マイナス点：
- デバイス盗難時は無効（ただし物理的盗難のため攻撃難度高い）
- バックアップコード紛失時のリカバリが困難
- QRコード読み込み時のフィッシング攻撃リスク
脆弱性レベル: 低い～ 非常に低い （実装の安全性に大きく依存）

2. 攻撃ベクトル別の耐性

攻撃ベクトル	SMS	メール	TOTP
SIMスワップ攻撃	×（脆弱）	○	○
フィッシング	△（OTP盗聴後の転用）	×（脆弱）	○（秘密鍵は局所）
中間者攻撃（MITM）	△（SS7脆弱性）	×（メール内容表示）	○（通信不要）
サーバー侵害（データ流出）	△（電話番号露出）	△（メール露出）	○（秘密鍵局所）
OTP盗聴	×（SMS傍受可能）	×（メール傍受可能）	○
デバイス盗難	○（他デバイス必要）	○（他デバイス必要）	×（本デバイス）

3. コンプライアンス・規制面

規制・基準	SMS	メール	TOTP
PCI-DSS v3.4 以降	○	△（推奨度低）	○
NIST SP 800-63-3	△（低評価）	△	○（推奨）
GDPR	×（電話番号は個人識別情報）	△	○
日本個人情報保護法	△（電話番号保持による負担）	△	○

ユーザビリティ観点

1. ユーザー負担

SMS

セットアップ負担: 低
- 電話番号のみ必要
- 追加アプリ不要
使用時負担: 低
- SMS受信を待つだけ
- ただしSMS受信に1～30秒の遅延あり
習熟度: 高（ほぼ全ユーザーが理解）

メール

セットアップ負担: 低～中
- メールアドレスのみ必要
- 追加アプリ不要
- ただしメール確認の習慣必要
使用時負担: 低～中
- メール確認に5秒～数分かかる場合あり
- メール中複数のOTPが混在する場合、探索が必要
習熟度: 中（メール操作不慣れユーザーは困惑可能性）

TOTP

セットアップ負担: 中～高
- 認証アプリのインストール必須
- QRコード読み取り必要
- 秘密鍵のバックアップ取得推奨
- リカバリコード生成・保管必須
使用時負担: 低
- 認証アプリを開いて6桁コードを入力
- 待ち時間なし
習熟度: 低（高齢者やテク不慣れユーザーは導入抵抗大）

2. アクセス性

観点	SMS	メール	TOTP
インターネット不要	×（SMS受信には通信必要）	×	○
デバイス種別に依存しない	○（ほぼ全携帯で受信可）	○	△（スマートフォン必須）
複数デバイス間の同期	○（キャリアが管理）	○	×（デバイスローカル）
視覚障害者対応	○	△（画面読み上げ必要）	△

3. 紛失・復旧シナリオ

シナリオ	SMS	メール	TOTP
デバイス紛失	△（新SIMで受信可）	○	×（秘密鍵もデバイス内）
電話番号変更	△（変更手続き必要）	○	○
メールアカウント侵害	○	×（アクセス不可）	○
認証アプリ削除	○	○	×（バックアップなければ復旧困難）

実装・技術観点

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. ユーザーの登録・更新時の挙動

方式	セットアップ必須性	後から追加可	削除後の復旧
SMS	○（属性が必須）	○	△（新番号登録必要）
メール	○（属性が必須）	○	○
TOTP	×（属性不要）	○	×（バックアップコード必須）

4. API レベルの統合

SMS

python

# Cognito の initiate_auth で SMS OTP を要求
client.respond_to_auth_challenge(
    ClientId='...',
    ChallengeName='SMS_MFA',
    ChallengeResponse='123456',
    Session='...'
)

メール

python

# Cognito の initiate_auth で メール OTP を要求
client.respond_to_auth_challenge(
    ClientId='...',
    ChallengeName='MFA_REQUIRED',  # or 'EMAIL_OTP'
    ChallengeResponse='123456',
    Session='...'
)

TOTP

python

# 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	メール	TOTP
MFA認証1件あたり	$0.075	$0.0001（SES経由）	$0
月間1,000認証	$75	$0.10	$0
月間10,000認証	$750	$1.00	$0
月間100,000認証	$7,500	$10.00	$0

注記:

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

インフラ:
- Cognito のみ（追加リソース不要）
管理:
- バックアップコードの安全な保管方法確認
- 認証アプリの対応状況確認
トラブル:
- デバイス紛失時のサポート
- バックアップコード再生成プロセス

3. スケーラビリティ

観点	SMS	メール	TOTP
スケール時のコスト増加	線形（認証数に比例）	ほぼ固定	なし
キャパシティ制限	△（SMS Gateway 依存）	○	○（サーバー側）
グローバル対応	×（国別ルール複雑）	○	○

運用・管理観点

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

よくある問題:
1. SMS 未受信（遅延 or 紛失）
  - 対応: 再送信 or 短時間の再試行制限緩和
2. 電話番号変更
  - 対応: 管理画面でユーザー属性を更新
3. キャリア変更で同じ番号が使えない
  - 対応: 新しい番号に登録変更
対応窓口必要レベル: 高（SMS 未配送は多い）

メール

よくある問題:
1. メール未受信（迷惑メール含む）
  - 対応: 再送信 or ドメイン認証確認
2. メールアカウント侵害
  - 対応: 緊急対応（アカウントロック推奨）
3. メールアドレス変更
  - 対応: 確認メール再送信後、属性更新
対応窓口必要レベル: 中～高（メール未配送、迷惑メール多い）

TOTP

よくある問題:
1. 認証アプリを削除してしまった
  - 対応: バックアップコードで復旧（バックアップコード紛失時は回復不可）
2. デバイス紛失
  - 対応: ユーザーが自分で新デバイスに再セットアップ（バックアップコード必須）
3. 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% でシステム異常を疑う

統合比較一覧表

総合評価マトリックス

評価軸	SMS	メール	TOTP	推奨度
セキュリティ（脆弱性）	4/10	5/10	9/10	TOTP >> メール > SMS
ユーザビリティ	8/10	7/10	6/10	SMS >> メール > TOTP
セットアップ難度	7/10（簡）	3/10（難）	6/10（中）	SMS > TOTP > メール
実装複雑度	6/10	3/10（複雑）	8/10	TOTP > SMS > メール
コスト効率	3/10（高）	9/10	10/10	TOTP = メール >> SMS
グローバル対応	5/10	8/10	9/10	TOTP >> メール > SMS
リカバリ容易性	7/10	7/10	5/10	SMS = メール > TOTP
規制対応	6/10	6/10	9/10	TOTP >> SMS = メール
ヘルプデスク負担	5/10（高）	4/10（高）	8/10（低）	TOTP > メール > SMS

方式選定フローチャート

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 推奨
         （長期で最適、初期投資で後々効率化）

推奨パターン

ユースケース	推奨方式	理由
B2B Enterprise	TOTP	セキュリティ＆規制対応＆コスト
B2C ソーシャル	SMS	ユーザビリティ優先
金融機関	TOTP + SMS（バックアップ）	セキュリティ＆復旧性
SaaS（国内）	メール	コスト＆ユーザビリティバランス
SaaS（グローバル）	TOTP	スケール性＆セキュリティ
初期段階スタートアップ	SMS	初期投資最小

詳細実装チェックリスト

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（メール侵害時）

この組み合わせにより、単一障害点を排除し、全てのシナリオで復旧可能な設計が実現できます。

参考資料

AWS Cognito – MFA の構成
NIST SP 800-63-3 Authentication and Lifecycle Management
PCI-DSS v3.4 MFA Requirements
AWS Cognito 公式ドキュメント：Custom Sender Lambda トリガー

目次

概要

セキュリティ観点

1. 認証強度

SMS

メール

TOTP

2. 攻撃ベクトル別の耐性

3. コンプライアンス・規制面

ユーザビリティ観点

1. ユーザー負担

SMS

メール

TOTP

2. アクセス性

3. 紛失・復旧シナリオ

実装・技術観点

1. Cognito での利用可能性

SMS

メール

TOTP

2. セットアップの複雑度

SMS

メール

TOTP

3. ユーザーの登録・更新時の挙動

4. API レベルの統合

SMS

メール

TOTP

5. バックアップ・復旧メカニズム

SMS

メール

TOTP

コスト・リソース観点

1. 直接コスト（2026年5月現在、アジアパシフィック東京リージョン）

2. 間接コスト

SMS

メール

TOTP

3. スケーラビリティ

運用・管理観点

1. デバイス・属性管理

SMS

メール

TOTP

2. ヘルプデスク対応

SMS

メール

TOTP

3. 属性の必須性・可変性

SMS

メール

TOTP

4. 監視・ロギング

SMS

メール

TOTP

統合比較一覧表

総合評価マトリックス

方式選定フローチャート

Step 1: セキュリティ要件の確認

Step 2: ユーザー母集団の特性

Step 3: コスト感度

Step 4: グローバル展開

Step 5: 運用負担度

Step 6: 実装期限

推奨パターン

詳細実装チェックリスト

SMS 導入チェックリスト

メール導入チェックリスト

TOTP 導入チェックリスト

まとめと推奨

最終推奨

複合アプローチ

参考資料

コメント