「パスワードさえ合っていればログインできる」——その前提が、今の現場では通用しません。
フィッシングメール、パスワードの使い回し、認証情報の流出。攻撃者がアカウントを乗っ取る手口は年々巧妙になっています。そして、これらの攻撃手法に対して「強いパスワードを設定する」だけでは防ぎきれないケースが増えています。
パスワードは漏れることを前提に考える——この発想に立てたとき、次に置くべき防衛線が MFA（多要素認証） です。
認証まわりの基本概念については「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」で解説しています。この記事では、MFAの仕組みから実務での導入・運用の落とし穴まで掘り下げます。
MFAがなければ何が起きるのか
パスワードだけの認証（単要素認証）は、パスワードが1つ漏れれば終わりです。
攻撃者がフィッシングサイトで認証情報を盗む、過去の漏洩データベースで試す、ブルートフォースで総当たりする——こうした手口でパスワードを入手した瞬間、そのアカウントに自由にログインできてしまいます。
フィッシング（Phishing） 偽のサイトやメールを使って、ユーザーのID・パスワードを騙し取る攻撃手法。
アカウントに侵入した攻撃者がその後どう動くかは、IAMの権限設計に依存します。ただし、認証が突破された時点でその後の話です。どれだけ権限設計を丁寧に行っても、認証が破られれば意味をなしません。
認証はIAMの入口であり、最初の防衛線。 MFAはその入口を二重にする仕組みです。
MFAとは何か——3つの要素を理解する
MFA（Multi-Factor Authentication／多要素認証） 「知識・所持・生体」の異なる種類の認証要素を2つ以上組み合わせて本人確認を行う仕組み。
MFAは「異なる種類の要素」を組み合わせることに意味があります。同じ種類を2つ使っても（パスワード＋秘密の質問など）、1つが漏れれば両方突破されるリスクがあるため、MFAとは呼びません。
① 知識要素（Something you know）
本人だけが知っている情報です。パスワード、PIN、秘密の質問などが該当します。利便性は高いですが、フィッシングやデータ流出で漏洩するリスクがあります。
② 所持要素（Something you have）
本人だけが持っているデバイスや物理的なものです。スマートフォン（認証アプリ）、ハードウェアキー、SMS受信できる電話番号などが該当します。物理的に手元にある必要があるため、遠隔からの攻撃に強い。
③ 生体要素（Something you are）
本人の身体的特徴です。指紋、顔認証、虹彩認証などが該当します。なりすましが最も困難ですが、デバイスや環境への依存度が高い。
MFAが有効な理由は、要素をまたいだ攻撃が難しいからです。パスワードを盗んでも、認証アプリが入ったスマートフォンを奪わなければログインできない——この「2つの壁」が攻撃者にとって大きな障壁になります。
よく使われるMFAの種類と選び方
実務で登場する主なMFA方式を強度と使いやすさで整理します。
| 方式 | 仕組み | 強度 | 注意点 |
|---|---|---|---|
| SMS認証 | 6桁のコードをSMSで受信 | 低〜中 | SIMスワップ攻撃・傍受リスクあり |
| 認証アプリ（TOTP） | アプリが30秒ごとにコードを生成 | 中〜高 | アプリとデバイスの管理が必要 |
| プッシュ通知 | スマホに「承認しますか？」通知 | 中〜高 | MFA疲労攻撃（連続プッシュ）に注意 |
| FIDO2／ハードウェアキー | 物理キーでの暗号認証 | 最高 | コスト・紛失時の対応が必要 |
TOTP（Time-based One-Time Password） 時刻をベースに30秒ごとに変わるワンタイムパスワードを生成する仕組み。Google AuthenticatorやMicrosoft Authenticatorが代表的。
FIDO2（Fast IDentity Online 2） パスワードを使わず、デバイス内の暗号鍵で認証する標準規格。フィッシングに対して原理的に強い。
SIMスワップ攻撃 攻撃者が携帯キャリアを騙して被害者の電話番号を自分のSIMに移し替える手口。SMS認証を突破するために使われる。
SMS認証はゼロよりはるかに良いが、最善ではない、というのが実務での扱い方です。可能であれば認証アプリ以上の方式を選ぶことを推奨します。高権限アカウント（管理者・特権ユーザー）にはFIDO2またはTOTPを必須とするのが理想です。
MFA疲労攻撃（MFA Fatigue Attack） 攻撃者がプッシュ通知を大量に送り続け、ユーザーが誤って承認してしまうことを狙う攻撃手法。番号照合（Number Matching）機能で対策できる。
参考：NIST SP 800-63B – Authentication and Lifecycle Management
クラウド環境でのMFA設定の基本
Azure（Microsoft Entra ID）でのMFA
Microsoft Entra ID Microsoftのクラウド型ID管理サービス（旧称：Azure Active Directory）。Azure環境の認証基盤。
AzureでMFAを運用する方法は主に2つです。
① セキュリティの既定値群（Security Defaults） テナント全体に一括でMFAを有効化します。設定が簡単な反面、細かい制御はできません。小規模環境や設定のとっかかりとして有効です。
② 条件付きアクセス（Conditional Access） 「管理者ロールを持つユーザーがログインするとき」「社外IPからのアクセス時」など、条件を指定してMFAを要求できます。柔軟な制御が必要な環境ではこちらを使います。
条件付きアクセス（Conditional Access） ユーザー・場所・デバイス状態などの条件に応じて、MFA要求やアクセスブロックなどのポリシーを適用する仕組み。
実務での優先順位として、まず「管理者アカウント全員にMFA必須」を最初に固め、その後一般ユーザーへ展開するのが現実的な進め方です。
参考：Microsoft Entra の多要素認証の概要 | Microsoft Learn
AWS IAMでのMFA
AWSでは、IAMユーザーとルートアカウントそれぞれにMFAを設定します。ルートアカウントへのMFA設定は最優先事項です。ルートアカウントは全リソースへのフルアクセスを持つため、侵害されると取り返しがつきません。
実務では「MFAが有効でなければコンソールにアクセスできない」というIAMポリシーを設定することで、未設定者のアクセスを制限できます。
実務でよくある落とし穴
① 「管理者だけMFAを適用」で安心してしまう
高権限アカウントにMFAを設定するのは正しい。しかし一般ユーザーアカウントが侵害された場合、そこから横展開・権限昇格を経て管理者レベルの操作が可能になるケースがあります。
権限昇格（Privilege Escalation） 攻撃者が最初に侵害した低権限のアカウントから、より強い権限を取得して操作範囲を広げる攻撃手法。
MFAは管理者だけではなく、すべてのアカウントに適用することが原則です。攻撃の起点はどのアカウントになるか分かりません。
横展開・権限昇格の具体的な攻撃フェーズは MITRE ATT&CK Matrix で体系的に整理されています。
② バックアップコードを管理していない
MFAデバイスを紛失・故障したとき、バックアップコードがなければアカウントにアクセスできなくなります。組織として「バックアップコードの保管場所と手順」を定めておくことが重要です。個人の端末にだけ保存している状態は、運用リスクになります。
③ MFAを無効化できる設定が残っている
設定画面でMFAを「推奨」にとどめ、ユーザーが任意で解除できる状態になっているケースがあります。セキュリティポリシーとして「MFAは必須、無効化不可」と明示し、条件付きアクセスポリシーで強制する構成にしてはじめて効果が出ます。
④ サービスアカウントのMFAを忘れる
サービスアカウント アプリケーションや自動処理がシステムへアクセスするための専用アカウント。人が操作しないためMFAが設定されにくい。
人が使うアカウントにMFAを設定しても、サービスアカウントが野放しになっているケースがあります。サービスアカウントはマネージドID・ワークロードID・証明書ベース認証などの代替手段で保護することが現実的な対策です。
IDライフサイクル全体でのアカウント管理については「IDライフサイクル管理とは？入社・異動・退職で権限を正しく管理する方法」も参照してください。
MFA導入・運用チェックリスト
現状を確認するための最低限の問いです。
導入面
- 管理者・特権アカウント全員にMFAが設定されているか
- 一般ユーザーアカウントにもMFAが適用されているか
- SMS認証より強い方式（TOTP / FIDO2）を使っているか
- ルートアカウント・グローバル管理者にMFAが設定されているか
運用面
- バックアップコードの保管場所と手順が定められているか
- MFAの無効化をポリシーで禁止しているか
- サービスアカウントの認証強化（マネージドID等）が行われているか
- MFA設定状況の定期レビューが仕組み化されているか
設計全体の抜け漏れ確認には「クラウドIAM設計チェックリスト｜抜け漏れを防ぐ実践ガイド」も合わせてご活用ください。
まとめ——パスワードは破られる前提で設計する
MFAは「あると少し安全」な追加オプションではありません。パスワードが漏れることを前提に、認証の入口を守るための必須の設計要素です。
まず今日確認すべきことは1つ。自分が管理している環境で、管理者アカウントにMFAが設定されているか。そこから始めてください。
認証が固まったら、次は権限設計です。認証を通過した後に「何ができるか」を制御するRBACの仕組みについては「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」で解説しています。
あわせてご覧ください
コメント