本記事は Django 管理画面（admin）に django-two-factor-auth を使って 2FA を導入する方法を、
設定・運用・注意点・詰みポイントまで含めてまとめた技術備忘録である。
対象読者は以下を想定している。
- Django を本番運用している
- admin をインターネット公開している、または mTLS / IP 制限の内側で使っている
- 「後で自分が読み返して即思い出せる」資料が欲しい
結論（先に要点）
- Django admin の 2FA は **django-two-factor-auth が事実上の定番**
- Google Authenticator は **Google アカウントと無関係**（TOTP 表示アプリなだけ）
- **staff ユーザーごとに完全に独立した 2FA** を持てる
- mTLS があっても **運用事故対策として 2FA 併用は有効**
- 一番詰みやすいのは **「全管理者が 2FA ロックアウト」**
使用するライブラリと方式
- 認証方式：**TOTP（RFC 6238）**
- スマホアプリ： * Google Authenticator * Authy * 1Password 等（TOTP 対応なら可）
採用ライブラリ
- `django-two-factor-auth` * 内部で `django-otp` / `django-otp-totp` を使用
インストール
※ qrcode は QR 表示用。必須。
settings.py 設定
INSTALLED_APPS
MIDDLEWARE（超重要）
AuthenticationMiddleware の 直後 に入れる。
ここを間違えると ログイン後に OTP が有効にならない。
URL 設定
project/urls.py
これだけで admin ログインが自動的に 2FA 対応になる。
マイグレーション
以下のようなテーブルが追加される。
- `otp_totp_totpdevice`
- `two_factor_phonedevice`（バックアップ用）
初回セットアップ（管理者側）
- 通常の admin ログイン
- **2FA セットアップ画面に自動遷移**
- 表示された QR コードを Google Authenticator で読み取り
- 6桁コードを入力
- **リカバリーコードを必ず保存**
これで完了。
Google Authenticator に関する重要な誤解
Google アカウントとは無関係
- ログイン不要
- Google アカウント非連携
- クラウド同期の有無は端末設定次第
👉 User × 秘密鍵 × Authenticator の単純な関係。
staff ごとに異なるスマホ・端末で使える？
完全に可能（むしろ前提）。
内部的には以下の構造：
- staff ごとに secret が違う
- 同じスマホでも登録できるが非推奨
- 端末紛失時の影響を最小化するため **個人端末必須** が望ましい
1ユーザーが複数端末を持つケース
- 技術的には **複数 TOTPDevice 登録可能**
- 運用的には以下どちらかに決める
パターン1（シンプル）
- 1 user = 1 端末
- 予備は **リカバリーコードのみ**
パターン2（厳格）
- メイン端末 + 金庫保管の予備端末
- デバイス棚卸し必須
admin だけ 2FA を必須にしたい場合
原則として：
- **admin に入れるユーザー = staff のみ**
- staff は全員 2FA 必須
という運用が一番事故りにくい。
mTLS との関係
- mTLS は **接続時点の本人性**を保証
- 2FA は **アプリ層の操作権限**を保証
実務判断
- 個人運用・熟練者のみ → mTLS のみでも可
- チーム運用・人の入れ替わりあり → **mTLS + 2FA 推奨**
よくある詰みポイント（重要）
① 全管理者が 2FA ロックアウト
最頻出事故。
原因：
- スマホ紛失
- 機種変更
- リカバリーコード未保存
対策：
- 緊急用 superuser を 1 つ作る
- 強パスワード
- IP 制限 or mTLS
- 普段は使わない（オフライン保管）
② OTPMiddleware の位置ミス
- ログインはできる
- OTP が有効化されない
👉 AuthenticationMiddleware の直後が正解。
③ クラウド同期前提の誤解
- Google Authenticator はデフォルト同期しない
- 端末破損 = 即死亡
👉 同期型 Authenticator を使うか、リカバリーコード必須。
運用ベストプラクティスまとめ
- admin は **staff 専用**
- staff は **全員 2FA 必須**
- リカバリーコードは * パスワードマネージャ * オフライン保管
- 退職・権限剥奪時は * User 無効化 * セッション破棄
まとめ
- django-two-factor-auth は **Django admin の 2FA として実績十分**
- Google Authenticator は単なる TOTP 表示アプリ
- staff ごとに独立した 2FA を自然に構築できる
- 最大の敵は **技術ではなく運用事故**
「突破されない設計」より 「詰まない設計」
これが一番重要。
Google Authenticator のクラウド同期（雲アイコン）についての補足
結論（短く）
- Google Authenticator に **雲のマーク＋チェック** が表示されている場合
- TOTP のシークレットは **Google アカウントに暗号化保存**されている
- **同じ Google アカウントでログインできれば、新しい端末へ復元可能**
つまり、
- スマホ紛失
- 端末故障
- 機種変更
といったケースでも、Google アカウントが生きていれば 2FA は復旧できる。
何が起きているか（仕組みの整理）
以前の Google Authenticator（〜2023 頃）
- TOTP シークレットは端末ローカル保存のみ
- 端末紛失・故障 = TOTP 全滅
- QR 再発行や管理者対応が必要
現在の Google Authenticator（クラウド同期有効時）
- TOTP シークレットを * Google アカウントに * 暗号化して保存
- 新端末で * Google アカウントにログイン * Google Authenticator を起動
- **登録済みの TOTP が自動復元**される
「完全に安心」ではない理由（重要）
便利にはなったが、注意点もある。
① Google アカウントが単一障害点になる
- Google アカウントの乗っ取り
- アカウント復旧失敗
- 誤削除・凍結
👉 全 TOTP が同時に漏洩 or 消失するリスクがある。
強いが「一点集中」
という性質を持つ。
② アプリ自体のロックが弱い
- Google Authenticator 自体には * 独自の PIN / パスコードがない（※OS 側設定依存）
- 端末がアンロックされた瞬間に * TOTP が表示可能
👉 端末セキュリティ（生体認証・アプリロック）は必須。
③ 組織・監査視点ではグレー
個人運用では問題にならないが、
- 業務用 admin
- 顧客データを扱う管理権限
の場合、
- 個人 Google アカウントに秘密鍵が保存される
- 組織側で失効・回収できない
という点を嫌うケースは多い。
django-two-factor-auth 観点での評価
技術的な問題はない
- TOTP 検証に使うのは * サーバ側の secret * 時刻
- クライアント側の保存先 * ローカル * クラウド
どちらでも 動作・安全性に差はない。
運用ポリシー例
パターンA：個人運用・小規模（現実解）
- Google Authenticator
- クラウド同期 ON
- Google アカウントは * 強パスワード * Google 側 2FA 有効
👉 利便性が高く、事故りにくい。
パターンB：チーム運用・統制重視
- Authy / 1Password / 社内 IdP
- 組織管理アカウント
- 同期・失効・棚卸しが可能
👉 管理者権限・監査要件がある場合はこちら。
それでもリカバリーコードは必要か？
YES。必須。
理由：
- Google アカウント自体にログインできない
- Google 側でも TOTP を要求される（認証ループ）
👉 最後の脱出路が django-two-factor-auth のリカバリーコード。
まとめ（補足）
- 雲＋チェック = Google アカウントに保存されている
- 新端末でも復元可能
- ただし Google アカウントが単一障害点
- 組織運用ではポリシー検討必須
- **リカバリーコードは依然として最重要**