多要素認証（MFA）を全社導入する手順：Microsoft 365 / Google Workspaceの設定とパスキー移行

多要素認証（MFA）とは、パスワードのような「知識」に加えて、スマートフォンやセキュリティキーといった「所持」、指紋や顔などの「生体」のうち、種類の異なる要素を2つ以上組み合わせて本人確認を行う認証方式です。パスワードが漏れただけではログインできなくなるため、クラウドサービスのアカウント乗っ取りに対して最も費用対効果の高い対策とされています。

ただし「MFAを有効にした」だけでは、フィッシングサイトで認証コードごと盗まれる攻撃や、承認通知を連打して押させる攻撃には対抗できません。ここではMicrosoft 365とGoogle Workspaceで全社員にMFAを行き渡らせる手順を、方式ごとのフィッシング耐性の差、例外の決め方、端末紛失時の対応、そしてパスキーへ移行する順序まで含めて整理します。管理画面のメニュー名は執筆時点のもので、変更されることがあります。

多要素認証とは：要素の種類と二段階認証との違い

認証の要素は、本人だけが知っている「知識」（パスワード、PIN）、本人だけが持っている「所持」（スマートフォン、セキュリティキー、社用PCのTPM）、本人そのものである「生体」（指紋、顔）の3種類に分けられます。多要素認証の条件は、異なる種類の要素を組み合わせることです。パスワードの後に「秘密の質問」を聞くのは2段階ですが、どちらも知識要素なので多要素ではありません。攻撃者がフィッシングで片方を得たとき、もう片方も同じ経路で取れてしまうからです。

実務では「二段階認証」「2段階認証プロセス」（Googleの呼称）はほぼMFAと同義で使われており、Microsoft 365もGoogle Workspaceも、パスワード＋スマートフォン（所持）の組み合わせが基本形です。用語の違いより重要なのは、2つ目の要素をどの方式で確認するかで、次の章で扱う耐性の差がそのまま防御力の差になります。

フィッシング耐性で方式を選ぶ：SMS・認証アプリ・プッシュ通知・パスキー

現在のアカウント乗っ取りで主流なのは、本物のログイン画面を中継する「AiTM（Adversary-in-the-Middle）型フィッシング」です。攻撃者のサイトは利用者の入力をそのまま本物のサイトへ転送するので、パスワードも、認証アプリの6桁コードも、プッシュ通知の承認も、利用者が「本物だと思って」操作した瞬間に攻撃者側で成立します。SMSは加えてSIMスワップ（携帯会社を騙して番号を移す）や、通信経路での傍受という固有のリスクを持ちます。

この中継を構造的に無効化するのがパスキー（FIDO2/WebAuthn）です。認証時に端末が署名する内容には、ブラウザが実際に接続しているサイトのドメイン（オリジン）が含まれます。偽サイトのドメインで作られた署名は本物のサイトでは検証に失敗するため、利用者が騙されて操作しても攻撃者は何も得られません。「利用者の注意力に頼らない」点が、他の方式と決定的に違います。

推奨は「まずプッシュ通知（番号一致）で全員に行き渡らせ、管理者と金銭・個人情報を扱う部門はパスキーを必須にし、SMSは移行期間が終わったら方式ごと無効化する」です。最初からパスキーだけで始めない理由は、端末の対応状況（古いAndroid、共有PC）と登録の手間で登録率が伸びず、期限までに例外が大量に残るからです。逆に、既に条件付きアクセスが使える契約で、対象が管理者20人程度なら、最初からパスキー必須で構いません。

導入計画：対象・例外・サポート体制・周知

全社導入で失敗する原因は技術ではなく、例外の扱いを決めずに強制日を迎えることです。計画段階で次の4点を文書にしておきます。

例外の型は3つに絞ります。（1）共有アカウント：人がログインする共有アカウントはMFAと相性が悪いので、共有メールボックスや配布グループに置き換え、置き換えられないものは企業向けパスワードマネージャーの共有機能で保管し、TOTPのシークレットも同じ金庫で共有します。（2）システム連携用アカウント：対話型サインインを止め、APIキーやOAuthアプリ、マネージドIDに置き換えます。「MFA除外」で残すと、それが侵入口になります。（3）スマートフォンを持たない・私物端末にアプリを入れたくない人：FIDO2セキュリティキーを会社が支給します。私物端末へのアプリ導入を強制する根拠は通常ありませんので、代替手段を先に用意しておくことで反発を防げます。

緊急用（break-glass）アカウントは、MFAポリシーの対象外にする唯一の例外です。クラウド専用アカウントを2つ作り、長いランダムなパスワードを分割して金庫等に保管し、条件付きアクセスやセキュリティの既定値群から除外し、サインインがあったら即座に通知が飛ぶよう監視します。これがないと、認証基盤側の障害や設定ミスで管理者全員が締め出されたとき、復旧する手段がサポート窓口への連絡だけになります。

件名: 【対応期限 3/28】社用アカウントの多要素認証（MFA）登録のお願い

営業部のみなさま

3/28（金）以降、Microsoft 365へのサインイン時に、パスワードに加えてスマートフォンでの承認が必要になります。
期限までに未登録の場合、翌営業日からメール・Teamsにサインインできなくなります。

■ やること（所要5分）
1. 社用または私物のスマートフォンに「Microsoft Authenticator」を入れる
2. PCでポータルにサインインし、案内に従ってQRコードを読み取る
3. 画面に出た2桁の数字をアプリに入力して完了

■ スマートフォンを使えない方
セキュリティキー（USB）をお渡しします。3/20までにヘルプデスクへご連絡ください。

■ 登録会
3/18・3/19 の 12:00〜13:00、3階会議室Bで随時受け付けます。

承認通知は、ご自身がサインインした直後にだけ届きます。心当たりのない通知は「拒否」を押し、ヘルプデスクへお知らせください。

Microsoft 365での設定：セキュリティの既定値群と条件付きアクセス

Microsoft 365でMFAを強制する方法は2つあり、ライセンスで決まります。セキュリティの既定値群は追加費用なしで使え、全ユーザーにMFA登録（14日間の猶予）、管理者への毎回のMFA要求、レガシー認証（IMAP/POP/SMTPのベーシック認証など）の遮断をまとめて有効にします。設定箇所はMicrosoft Entra管理センターの「ID」→「概要」→「プロパティ」→「セキュリティの既定値群の管理」です。細かい条件は一切付けられない代わりに、設定ミスの余地もありません。

条件付きアクセスはEntra ID P1（Microsoft 365 Business Premium、E3、E5に含まれます）が必要で、「誰が・どこから・どの端末で・どのアプリに」の条件ごとにMFAや準拠デバイスを要求できます。セキュリティの既定値群と同時には使えないので、P1があるなら条件付きアクセスに一本化します。最初に作るポリシーは「すべてのユーザー（緊急用アカウントを除外）、すべてのクラウドアプリ、多要素認証を要求」の1本で、まず「レポート専用」モードで1週間サインインログを眺め、誰が引っかかるかを見てから「オン」にします。ポリシー設計の詳細はEntra IDの条件付きアクセス入門にまとめています。

どちらの方式でも、使える認証方法は「保護」→「認証方法」→「ポリシー」で決めます。Microsoft Authenticator（プッシュ通知は番号一致が既定で有効）、パスキー（FIDO2）、一時アクセスパス（TAP）の3つを有効にし、SMSと音声通話は移行完了後に無効化します。執筆時点では、従来の「ユーザーごとのMFA」画面の設定はこの統合ポリシーへの移行が進められているため、新規に設定するなら最初から認証方法ポリシー側で行ってください。「認証方法」→「登録キャンペーン」を有効にすると、SMSやTOTPしか持たないユーザーにサインイン時にAuthenticatorの登録を促し、スヌーズできる回数も指定できます。

# 執筆時点の Microsoft Graph PowerShell SDK での例。必要な権限は AuditLog.Read.All と UserAuthenticationMethod.Read.All
Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"

Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object { -not $_.IsMfaRegistered } |
  Select-Object UserPrincipalName, UserType, IsSsprRegistered |
  Export-Csv -Path .\mfa-unregistered.csv -NoTypeInformation -Encoding UTF8

同じ内容は管理センターの「保護」→「認証方法」→「ユーザー登録の詳細」でも見られます。部門展開の週次レポートはこのCSVを部署コードで集計すれば足ります。

Google Workspaceでの設定：2段階認証プロセスの必須化

Google管理コンソールでは「セキュリティ」→「認証」→「2段階認証プロセス」で設定します。手順は、（1）「ユーザーに2段階認証プロセスの使用を許可する」をオンにする、（2）「適用」を「指定した日付から」にして強制日を置く、（3）「新規ユーザーの登録期間」を1〜2週間にして入社直後の猶予を作る、（4）「方式」を「テキストメッセージと音声通話を除くすべて」にしてSMSを外す、の順です。設定は組織部門（OU）とグループ単位で上書きできるので、管理者用OUだけ「セキュリティキーのみ」にし、一般ユーザーOUを段階展開の順に切り替えていきます。

「信頼できるデバイス」を許可すると、同じブラウザでは一定期間2つ目の要素を省略できます。利便性は上がりますが、その端末のCookieが盗まれた場合の被害も伸びるので、管理者OUでは許可しないのが妥当です。パスキーは同じ「認証」配下の「パスワード不要」設定で、パスワード入力をパスキーで代替できるようにします。強制日を迎える前に「レポート」→「ユーザーレポート」→「セキュリティ」で「2段階認証プロセスの登録」列を見て、未登録者をゼロにしてから適用してください。強制後に未登録のユーザーはサインインできなくなり、管理者がバックアップコードを発行するまで復旧しません。

2段階認証を必須にすると、IMAP/SMTPでパスワードを直接使う旧式のメールソフトや複合機のスキャン送信が「ユーザー名またはパスワードが正しくありません」で止まります。Google Workspaceでは執筆時点で「安全性の低いアプリ」のパスワード認証は使えなくなっており、OAuth対応のクライアントに替えるか、複合機のような機器には「アプリパスワード」（2段階認証の有効化後に発行できる16桁）を割り当てます。Microsoft 365でも同様で、レガシー認証を止めると古いOutlookや AADSTS50076（MFAが必要）で失敗するクライアントが出るので、事前に サインインログ で「クライアントアプリ」がレガシーのものを洗い出しておきます。

登録キャンペーンの進め方

登録率を上げるのは技術よりも運用です。効いた順に挙げると、（1）強制日を最初の周知に明記する（「翌営業日からサインインできなくなる」まで書く）、（2）昼休みに登録会を開き、その場で完了させる、（3）週次で部門長に未登録者の名前入りリストを送る、（4）登録キャンペーン機能でサインイン時に促す、の4つです。周知は3回（3週間前・1週間前・前日）で、文面は毎回「やること・期限・困ったときの窓口」の3要素だけにします。

登録時に必ず守らせたいルールは「2つ目の方法まで登録する」ことです。認証アプリだけの人は、機種変更や紛失のたびにヘルプデスク対応が発生します。Microsoft 365ならAuthenticatorに加えてパスキーまたは別の電話番号（移行期間中のみ）、Google Workspaceならバックアップコードの印刷を登録会の手順に組み込みます。ヘルプデスク側は「本人確認の手順」を先に決めておいてください。メールでの依頼だけでMFAをリセットする運用は、攻撃者が最初に狙う手口です。上長へのビデオ通話確認や社員証の提示など、攻撃者が用意しにくい確認を1つ挟みます。

端末紛失・機種変更時の対応

一時アクセスパス（TAP）は、有効期限と使用回数を限定した使い捨てのコードで、認証方法ポリシーで有効化すると発行できます。紛失時の再登録だけでなく、入社初日にスマートフォンなしでパスキーを登録させる用途にも使えます。Authenticatorのクラウドバックアップは個人のMicrosoftアカウントやiCloudに紐づくため、復元後に職場アカウントの再確認を求められることがあります。「バックアップがあるから大丈夫」とは案内せず、2つ目の方法の登録を原則にしてください。

パスキーへの移行ステップ

パスキーには、iCloudキーチェーンやGoogleパスワードマネージャーで端末間に同期される「同期型」と、セキュリティキーやWindows HelloのようにTPMやセキュアエレメントから出ない「デバイス固定型」があります。同期型は個人のクラウドアカウントに秘密鍵が乗るため、会社のアカウントの鍵が私物のiCloudに保存されることを許容できるかは、組織として先に決める必要があります。Entra IDではパスキーの方式ごとの識別子（AAGUID）で許可する種類を絞れるので、管理者はデバイス固定型のみ、一般ユーザーは同期型も可、といった線引きが可能です。

移行の順序は次の通りです。（1）認証方法ポリシーでパスキー（FIDO2）を有効にする。（2）情シスがWindows Hello for Businessとセキュリティキーで1か月使い、サインインログで「認証方法」がパスキーになっていることを確認する。（3）管理者ロールに条件付きアクセスの「認証強度：フィッシング耐性MFA」を要求し、管理操作をパスキー必須にする。（4）一般ユーザーには「2つ目の方法」としてパスキー登録を案内し、Authenticatorのプッシュ通知は残す。（5）登録率が十分になった部門から、認証強度でパスキーを主方式に切り替える。（6）SMS・音声を無効化し、最後にパスワードレスサインインを許可する。この順序なら、どの段階で止まっても後戻りが不要です。

確認方法：強制されているか・登録されているかを見る

• 強制の確認：テスト用アカウントでブラウザのプライベートウィンドウからサインインし、パスワードの後に承認画面が出ること。Microsoft 365はサインインログの「認証要件」列が「多要素認証」になっていること、Google Workspaceは「レポート」→「監査と調査」→「ログイベント」でログインに2段階認証が記録されていること。
• 登録率の確認：Entraの「ユーザー登録の詳細」またはGraphのCSVで IsMfaRegistered が偽のユーザーがいないこと。Googleは「ユーザーレポート」→「セキュリティ」の「2段階認証プロセスの登録」列。
• レガシー認証の遮断：Microsoft 365のサインインログで「クライアントアプリ」を「その他のクライアント」「IMAP」「POP」「SMTP」で絞り、失敗（遮断）以外が残っていないこと。
• 緊急用アカウント：月1回、実際にサインインして通知が飛ぶこと、MFAを求められないことを確認し、記録を残す。

つまずきポイント

「AADSTS50076」「AADSTS50079」でアプリが止まった

AADSTS50076 は「MFAが必要だがこのクライアントでは完了できない」、AADSTS50079 は「ユーザーがMFA未登録」を意味します。前者は先進認証に対応しない古いクライアント（旧OutlookのベーシックIMAP、自作スクリプトのパスワード認証）で起きるので、OAuth対応のクライアントに替えるか、アプリ用にはユーザーのIDではなくアプリ登録（クライアント資格情報）を使います。後者は登録猶予を過ぎたユーザーなので、TAPを発行して登録させます。

身に覚えのない承認通知が連続で届く

パスワードが既に漏れていて、攻撃者がサインインを繰り返し、利用者が根負けして承認するのを待つMFA疲労攻撃です。番号一致が有効ならアプリ側に2桁の数字を入力しないと承認できないので成立しにくくなりますが、通知が届いた時点でパスワードは漏れています。該当ユーザーのパスワードを即時変更し、サインインログで送信元IPを確認し、承認してしまった形跡があればセッションを取り消してください。

管理者全員がサインインできなくなった

条件付きアクセスに「準拠デバイスを要求」や「特定の場所からのみ」を追加した直後に起きる典型例です。緊急用アカウントでサインインしてポリシーを「レポート専用」に戻します。緊急用アカウントを作っていなかった場合、Microsoft 365・Google Workspaceともサポート窓口での本人確認を経た復旧になり、数日かかることがあります。ポリシーを追加するときは必ずレポート専用で影響を見てから有効化してください。

「私物スマートフォンにアプリを入れたくない」と言われた

正当な要望なので、議論せずにFIDO2セキュリティキーを支給します。1本では紛失時に困るので2本を登録させ、1本は自席に固定して使う運用にします。Authenticatorは端末の位置情報や連絡先に触れない旨を説明資料に書いておくと、自主的にアプリを選ぶ人も増えます。

よくある質問

SMS認証では不十分ですか？

パスワードだけよりは確実に安全ですが、AiTM型のフィッシングとSIMスワップの両方に弱く、Microsoft・Googleとも他の方式への移行を促しています。他の方式を使えない人への一時的な手段と位置づけ、認証アプリかパスキーの登録が済んだ時点で方式ごと無効化するのが現実的な落としどころです。

パスキーとは何ですか？

FIDO2/WebAuthnという標準に基づき、端末内の秘密鍵で署名してログインする方式の総称です。署名には接続先のドメインが含まれるため、偽サイトで操作しても本物のサイトに使える署名は作れません。指紋や顔、PINで端末側のロックを解除して使うので、利用者から見ると「パスワードを打たずにログインできる仕組み」です。

全社導入にどのくらいかかりますか？

設定自体は1日で終わります。時間がかかるのは登録の行き渡りと例外の整理で、100〜300人規模なら準備1週間、管理者1週間、パイロット2週間、段階展開4〜8週間の合計2〜3か月が目安です。共有アカウントや旧式クライアントの置き換えが多い組織ほど後半が伸びるので、パイロットの段階で例外の数を数えておくと見積もりが安定します。

まとめ

MFA導入の順番は「緊急用アカウント→管理者→パイロット→段階展開→強制とSMS無効化」で、技術的な設定はMicrosoft 365ならセキュリティの既定値群か条件付きアクセス、Google Workspaceなら2段階認証プロセスの適用日設定に集約されます。成否を分けるのは、共有アカウント・システム連携・端末を持たない人という3種類の例外を先に片付けることと、2つ目の方法まで登録させて紛失時の手順を決めておくことです。プッシュ通知で全員に行き渡らせた後、管理者からパスキーへ移していけば、フィッシングに「気づけなくても守れる」状態に近づきます。

次に読む

• Entra IDの条件付きアクセス入門：中小企業が最初に設定すべき5つのポリシー
• Google Workspace管理者が最初にやるセキュリティ設定10項目
• ゼロトラストとは？情シスが最初の90日で取り組む実践ステップ