パスワード単独はもはや安全な境界ではありません。認証情報はフィッシングで盗まれ、異なるサービスで再利用され、漏洩リストで売られ、公開されたサインイン画面で自動的に試されます。だからこそ第二要素は、モダンなセキュリティアーキテクチャの基本要件となりました。
しかしMFAを追加することは、各アプリケーションの前に別個の検証サービスを置くことや、認証の最も重要な瞬間を完全にサードパーティのクラウドへ移すことを意味すべきではありません。ユーザー単位の継続的なライセンスコスト、外部サービスへの依存、異なる管理パネル、断片的なポリシー構造は、時とともにセキュリティを単純化するどころか複雑化させます。
より大きな問題は、画一的なMFAアプローチです。すべてのアプリケーションが同じリスクを抱えるわけではなく、すべてのユーザーが同じコンテキストからアクセスするわけではなく、すべてのセッションが同じ信頼レベルで始まるわけではありません。組織のwikiにはTOTPで十分かもしれません；本番サーバーとドメインコントローラーへのアクセスは毎回のサインインでTOTPを求め、信頼済みデバイスのショートカットを許可すべきではありません。一方、低リスクのイントラネットアプリケーションは、毎回のサインインで不要なコード画面によってユーザーを遅らせるべきではありません。
MFAの役割はユーザーに絶えず障害を作ることではなく、リスクが高まったときに信頼レベルを引き上げることです。そのために、検証の判断は、アプリケーション、ユーザーグループ、デバイス状態、ロケーション、セッションリスク、アクセスされる資産の機微性に応じて行われるべきです。
MFAは別個のクラウド依存ではなく、組織自身のアクセスポリシーの、ローカルで段階的かつ監査可能な一部であるべきです。
単一のポリシーエンジンの下に3つの要素タイプ — すべてすでに保有しているプラットフォーム上で動作します。
TOTP、SMS、メールOTPのすべてが同じMFA構成モデルで動作します。管理者は、どの方式が全体的に利用可能か、あるサービスにどれが必須か、どれをユーザーが選べるかを — 別個のベンダーコンソールに入ることなく、ユーザー単位のMFA料金を払うこともなく — 単一の場所から定めます。
各サービスまたはサービスグループは独自のMFA要件を宣言します：MFAなし、任意の要素、特定の方式、または連鎖した要素の組み合わせ。低リスクのイントラネットアプリケーションは摩擦のないまま；高リスクの管理者インターフェースはより強い要件を課す；その中間は安全であるために過剰保護を強いられません。
ポリシーが許可するとき、ユーザーはMFAの瞬間に自分のデバイスを信頼済みとしてマークし、構成可能な期間 — デフォルト30日 — 第二要素をスキップできます。信頼はデバイスに紐づき、ネットワークにではありません；そして管理者コンソールからもユーザー自身のプロファイルページからも取り消せます。
継続的トラスト評価がすべてのアクティブセッションを監視します。オペレーターのIPが国を変えたり、エンドポイントの信頼スコアが下がったり、振る舞いが異常化したりすると、ゲートウェイはユーザーをサインインページから最初からやり直させることなく、新鮮なMFAチャレンジを課すことができます。
3つの要素の配信チャネル、加えてその周囲のポリシーとリカバリーツール。
Google Authenticator、Microsoft Authenticator、Authy、1Password、Bitwarden、Yubico Authenticator、FreeOTP、その他あらゆるRFC 6238アプリと互換性のある標準の時間ベースワンタイムパスワード。登録はサーバー側でレンダリングされたQRコードを通じて動作します；共有シークレットは暗号化して保存され、ログに残らず、管理者コンソールには決して表示されません。アルゴリズム、桁数、有効期間はプロファイル単位で構成されます。
すでに使用しているHTTP対応のSMSプロバイダー経由でSMSで配信されるOTPコード — Twilio、Vonage、Infobip、MessageBird、ローカルキャリアAPI、または自社の内部ゲートウェイ。プラットフォームがメッセージを構成し、構成済みのHTTPエンドポイントを呼び出し、配信を追跡します；あなたのユーザーと必要なコードとの間にSMS再販業者は立ちません。
ユーザーの検証済みメールアドレスへ配信されるOTPコード。サインインページはアドレスをマスクされた形でのみ表示します（例：y***@example.com）；これにより、パスワードを盗んだ攻撃者は宛先メールを知ることができません。リカバリーチャネルおよび低リスクの検証フローに有用です。
登録時にTOTPユーザーにワンタイムのバックアップコードが渡されます — 暗号化して保存され、一度だけ表示され、ユーザーが電話へのアクセスを失ったときに消費されます。消費された各コードは「使用済み」とマークされ、二度と受け入れられません；残りのコードはユーザーまたは管理者が再生成できます。
管理者はMFA要件をサービス、サービスグループ、またはアウトカム単位でマッピングします。特定のサービスは任意の要素、特定の要素、または連鎖を要求できます — 例えば送金操作にはサインイン時のTOTPに加えて新鮮なSMS検証。マトリクスはバージョン管理され、監査可能で、単一の場所での変更が適用されるあらゆる場所へ波及します。
単一の要素で十分でないとき、サービスは2つ以上の要素を定義された順序で要求できます — 例えばセッション開始時のTOTPに加えて、機微な操作が呼ばれたときの新鮮なメールまたはSMSコード。連鎖はポリシー主導で構成可能です；ユーザーは追加ステップをリスクが要求するときにのみ目にします。
ルーチンなセッションのためにすでにTOTPを完了したユーザーは、より機微なリソースに到達したときにセッション内で再度チャレンジされうります。引き上げはポリシー主導であり、再ログインではありません；セッションは続行し、ユーザーはコンテキスト、開いたウィンドウ、進行中の作業を失うことなく、追加チャレンジのみを完了します。
ユーザーはTOTPを登録し、バックアップコードを再生成し、信頼済みデバイスを管理し、メールや電話番号を検証します — サポートチケットを開くことなく、単一のプロファイルページから。管理者は、認証が必要なときに再登録を強制したり、信頼済みデバイスを取り消したり、要素をリセットしたりする権限を保持します。
MFAをチェックボックスから、擁護可能な認証レイヤーへと変える基盤。
TOTPシークレット、バックアップコード、信頼済みデバイストークンはプラットフォーム管理のキーで暗号化して保存され、セッションおよびポリシーデータとは分離して保持されます。管理オペレーターはメタデータ（登録状態、最終使用、信頼済みデバイス数）を見ますが、シークレット自体は決して見ません。
各OTPチャネルは独自の試行カウンターを保持します — 誤ったTOTP入力、誤ったSMSコード入力、誤ったメールコード入力 — 構成可能な閾値を超えるとチャネルがロックされます。ロックアウトはプラットフォームのより広範なlogin-attack-protectionレイヤーと連携します；これにより、単一のユーザーがある要素をブルートフォースしている間に、同時に第二要素を試すことができません。
メールアドレス、電話番号、authenticator名は、検証UIでエンドユーザーに常にマスクされた形で表示されます。パスワードを知るが第二要素を持たない攻撃者は宛先を読んでリダイレクトできません — 他人の肩越しに見る者も登録の詳細を集められません。
コード長（6、8、またはそれ以上）、グループ化区切り（123-456または123456）、秒単位の有効期間、再送待機時間はMFAプロファイル単位で構成されます。コンプライアンス対象のフローはより長いコードとより短いウィンドウを求めることができます；ルーチンなフローは標準の6桁、60秒のコードでユーザーフレンドリーなまま保てます。
ユーザーは元のコードが届かないときに再送を要求できます — 再送メカニズムをSMS爆撃ツールとして使うことを防ぐ構成可能な待機時間に紐づけられています。レート制限はチャネル単位の試行カウンターとともに追跡され、監査ログに現れます。
各MFA試行 — 成功、失敗、再送、ロック — がタイムスタンプ、送信元IP、user agent、チャネル、ポリシーエンジンが下した判断とともにログ記録されます。監査フローはプラットフォームのSIEMストリーミング先に供給されます；これにより、セキュリティチームはMFAの異常をテレメトリーの残りと相関させられます。
ドメインコントローラー、本番データベース、プラットフォーム自身の管理者コンソール — これらは利用可能な最も強い連鎖を課します。一般的なパターンはセッション開始時のTOTPに加えて、破壊的な操作が呼ばれたときの新鮮なSMS検証です；最も影響度の高いシステムには信頼済みデバイスのショートカットは開かれません。
送金および照合システムは連鎖MFAを要求できます — サインイン時のTOTPに加えて取引時の新鮮なOTP — これにより単一の盗まれた要素では資金移動を起こせません。ステップアップポリシーは摩擦をすべてのページ読み込み時ではなく取引の境界に保ちます。
固定デスクや信頼済みのノートPCを持たないユーザーは、組織のSMSゲートウェイ経由のSMS OTPで、SMSの信頼性が弱いときはメールOTPで認証します。宛先マスキングとチャネル単位のロックアウトが、同じ電話が一つのシフトに供される間でもフローを安全に保ちます。
監査人は、対象システムへ向かうすべての特権アクセス経路にMFAを求めます。サービス単位のポリシー要件は監査人に対してそれを明確に表現します — 低リスクの内部サービスの前に同じ壁を立てることなく。
3つの方式、単一のポリシーエンジン、サードパーティのMFAクラウドなし — サービス単位かつリスク単位で構成されます。あなた自身のアプリケーション上のライブセットアップでご案内します。