Microsoft Authenticator 導入ガイド（企業向け設定と運用）

Microsoft Authenticator の概要と導入メリット

Microsoft Authenticator は Microsoft Entra ID（旧 Azure AD）と連携する認証アプリです。多要素認証や Passwordless（Phone sign‑in、FIDO2 など）に対応し、ユーザーのサインイン体験と管理の効率化が期待できます。ここでは主要機能と導入効果を整理します。

機能概要

主要な認証方式の特徴と運用上の注意点を示します。表は現場での比較判断用です。

導入で期待できる効果

導入によって組織で期待できる主な効果をまとめます。導入目的を明確にして設計してください。

• リモート／ハイブリッド環境での不正アクセス抑止。Conditional Access と組合せると効果的です。
• ヘルプデスク問い合わせの削減。復元フローや TAP を整備すると早期復旧が可能です。
• 監査対応の容易化。認証ログを SIEM に転送すれば長期保存と検索性が向上します。

表の注記（ライセンスと運用上の注意）

表に示した内容は運用方針の目安です。ライセンスや機能可否はテナントや契約によって異なります。

• Authenticator アプリ自体は無償で提供されますが、Conditional Access やセルフサービス パスワードリセット（SSPR）等の運用には Microsoft Entra ID Premium P1 相当が一般的に必要です。
• リスクベースの保護や Identity Protection などの高度機能は Microsoft Entra ID Premium P2 相当が必要になる場合があります。
• Microsoft 365 バンドルの例としては Microsoft 365 E3 に Entra ID Premium P1 相当が含まれる場合、E5 に P2 相当が含まれる場合がありますが、契約形態で異なるため必ず公式ライセンス情報で確認してください。

認証方式比較と推奨順序（Microsoft Authenticator）

認証方式をセキュリティと運用性で評価し、導入順序の考え方を示します。推奨は組織のリスクプロファイルに応じて調整してください。

推奨順序と理由

優先度は一般的なセキュリティと UX のバランスに基づきます。

• 第一優先：Passwordless（Phone sign‑in / FIDO2）。パスワード攻撃を根本的に減らせます。
• 第二優先：プッシュ承認。ユーザー体験が良く、標準的な MFA として有効です。
• 第三優先：TOTP。オフライン時のフォールバックとして有用です。
• 最後の手段：SMS/音声。番号移行や SIM スワップ等のリスクがあるため単独利用は避けるべきです。

実装時の注意点

方式ごとの実装で注意すべきポイントを簡潔に整理します。

• Phone sign‑in は端末固有の登録が多く、復元できないケースがあるためバックアップポリシーが必要です。
• Number matching や承認番号を必ず検討して誤承認を防止してください。
• ユーザー教育とパイロットの段階的展開で混乱を減らします。

導入前チェック：ライセンス・対応環境（Microsoft Entra ID）

導入前に必須の準備項目を確認します。権限分離と段階的な検証計画を必ず用意してください。

対応 OS と配布戦略

対応端末と配布方法の方針を定めます。Intune を中心に設計するケースが多いです。

• 推奨方針は各 OS の最新安定版と直近数世代前をサポートすることです。具体的な最小バージョンは社内ポリシーで定めてください。
• 配布手段：Intune（iOS は App Store、Android は Managed Google Play）を推奨します。BYOD の場合は MAM（App protection）で保護します。
• パイロット：少数の部門で動作検証を行い、ログやサポート負荷を評価した上で段階展開します。

パイロット設計

パイロットで確認すべき項目と計測指標を示します。

• 対象ユーザー数、デバイス種別、サポート稼働率を定義します。
• 成功指標例：登録率、認証成功率、ヘルプデスク問い合わせ件数。
• 障害時のロールバック手順と連絡経路を必ず用意します。

管理者向け設定と自動化（Entra 管理センター / Microsoft Graph 例示）

管理者が行うべき具体手順と破壊的操作時の安全策を示します。UI 表示は言語設定や更新で変わるため、英語原語も併記します。

Authentication methods の有効化（Entra 管理センター）

以下は一般的な有効化手順の例です。画面や権限名はテナントによって異なる場合があります。

1. 管理者アカウントで Microsoft Entra 管理センター（https://entra.microsoft.com）にサインインします。
2. 左メニューで「Security（セキュリティ）」→「Authentication methods（認証方法）」を選択します。
3. 「Microsoft Authenticator」項目を選び、通知（Notification）、コード（Authenticator app code）、Phone sign‑in などのトグルで有効化します。
4. グローバル適用前にパイロット用のグループ対象でテストします。
5. 設定変更は変更記録（チケット ID）を残し、ロールバック手順を文書化します。

管理センターの画面名やメニューが変わる可能性があるため、操作前に画面最上部のヘルプや公式ドキュメントを確認してください。

Phone sign‑in の有効化と Conditional Access での適用

Phone sign‑in を段階的に本番導入する流れの例を示します。

• Entra 管理センターで Phone sign‑in を有効にし、まずは特定のパイロットグループに限定します。
• Authentication Strength（認証強度）を作成し、Phone sign‑in を含めます（英語: Authentication strength）。
• Conditional Access（条件付きアクセス）ポリシーで Grant の条件として「Require authentication strength」を選択し、作成した強度を割り当てます。
• 本番導入前に管理者アカウントや緊急用アカウント（break‑glass）はポリシー対象から除外してください。
• Authentication Strength の利用可否や詳細はライセンスやテナント設定に依存します。導入前に確認してください。

高リスク操作の安全策（認証方法削除／TAP 発行）

認証情報の削除や TAP（Temporary Access Pass）発行などは破壊的操作です。実行手順と事前条件を明確にしてください。

• 事前条件：ユーザー本人確認（複数の証跡）、サポートチケットの発行と承認（少なくとも 1 人のセカンドオピニオン）。
• 事前バックアップ：削除前に対象ユーザーの登録済メソッド一覧をエクスポートして保存します。保存先は暗号化されたアクセス制御されたストレージにしてください。
• TAP 発行時：有効期限は短く（例: 10〜30 分）、利用回数を限定し、発行ログを残します。発行は安全なチャネルで行い、使用後に無効化します。
• 実行者：最小特権のアカウントで操作し、操作ログを必ず残すこと。自動化スクリプトを使う場合は実行前にリハーサルを行います。

Microsoft Graph / PowerShell による自動化（例示）

大規模運用では自動化が必要です。以下はあくまで例示です。実行前に公式ドキュメントで API 仕様や権限（scope）名を確認してください。

• 管理モジュール接続（例示）:

• ユーザーの認証メソッド一覧取得（例示）:

• 認証メソッド削除の例（例示、慎重に）:

注意点：スコープ名やエンドポイントは API バージョンやモジュールで異なる場合があります。スクリプトは非本番環境で十分に検証し、最小権限のサービスアカウントで実行してください。操作前にバックアップと承認を必須化することを推奨します。

エンドユーザー向け：登録手順・バックアップ／復元・紛失対応（Authenticator 操作）

ユーザーが迷わない具体手順を示します。管理者はこの手順を分かりやすく社内に配布してください。

インストールと職場／学校アカウントの追加（QR／手動）

PC とスマホを使った典型的な登録手順です。ポータル名は言語設定で変わることがあります。

1. スマホで App Store（iOS）または Google Play（Android）から「Microsoft Authenticator」をインストールします。
2. PC で https://mysignins.microsoft.com/security-info（英語: Security info） または https://aka.ms/mfasetup にアクセスしてサインインします。
3. 「Add method（方法の追加）」→「Authenticator app（認証アプリ）」を選択し、表示された QR コードをスマホでスキャンします。
4. スキャンできない場合は「手動での設定（manual setup）」を選び、画面に表示されたコードをアプリに入力します。
5. 登録後に初回確認の通知や承認コード入力が発生するので、案内に従って完了してください。

ポータルの URL やラベルは更新されることがあるため、ユーザー配布物にはスクリーンラベル（英語名）を併記してください。

バックアップ／機種変更の手順と注意点

バックアップは復旧設計の要です。設定とリスクを明確に伝えてください。

• バックアップ有効化（ユーザー操作）: アプリの「Settings（設定）」→「Backup（バックアップ）」でクラウドバックアップを有効にします。iOS は iCloud、Android は Microsoft アカウントを利用します。
• 機種変更時: 新端末にアプリをインストールし、同じバックアップアカウントでサインイン→復元を選びます。
• 重要な注意点: Phone sign‑in（Passwordless）や一部のデバイス固有情報はクラウドバックアップで復元できない場合があります。テナントでバックアップが禁止されていると復元は不可です。必ず二次端末や代替認証方法を登録する運用を推奨します。
• セキュリティ: バックアップは個人のクラウドアカウントに保存されます。バックアップデータの暗号化やアカウント管理（多要素認証設定）を周知してください。

紛失時の管理者とユーザーの対応フロー（標準例）

紛失・盗難時は迅速かつ段階的に対応します。事前に社内ルールを定めておいてください。

1. ユーザーは速やかにヘルプデスクへ連絡します。連絡方法は事前周知します。
2. ヘルプデスクは本人確認を実施し、サポートチケットを起票します。
3. 管理者は Microsoft Entra 管理センターで該当ユーザーの認証方法をクリアするか、該当デバイスを無効化します。必ず操作ログとチケット番号を残します。
4. 必要に応じて TAP を発行し、短時間での再登録を促します。TAP は発行後すぐに無効化する運用を検討してください。
5. 管理対象デバイスであれば Intune で遠隔ワイプ、サインインセッションの無効化（Revoke sessions）を実行します。
6. SSPR が有効な場合はユーザーに再登録手順を案内します。

TAP やリセットの前に必ず本人確認の証跡を残すことが重要です。

運用・監査・トラブルシューティング（ログ確認と KQL 例）

運用中に必要な監査方針と、ヘルプデスク向けの具体的なログ確認方法を示します。ログは早期検知と法令対応に必須です。

監査ログと保存ポリシー（実務例）

監査ログの保存期間や責任分担の例を示します。組織の法令要件に合わせて調整してください。

• 一般的な目安（例示）: 日常のサインインログ 90 日、セキュリティ・インシデント関連は 1 年以上、法的拘束がある場合は 7 年など。業界規制で異なります。
• 役割分担: セキュリティチームが保存ポリシーを設計し、コンプライアンス部門が法令要件を確認します。IT 運用はログのエクスポートと保管を実行します。
• 技術実装: Microsoft Entra の Sign‑in / Audit ログを SIEM（Azure Monitor / Log Analytics / Sentinel 等）へ転送し、長期保存とイミュータブル保存を行います。エクスポート先はアクセス制御と暗号化を実施してください。

サインインログ／監査ログの確認手順（管理センター）

管理センターでの基本的なログ確認手順です。英語 UI 名も併記します。

• Microsoft Entra 管理センター（https://entra.microsoft.com）へサインインします。
• 左メニューで「Monitoring（監視）」→「Sign‑ins（サインイン）」を開きます（英語: Sign‑ins）。日付、ユーザー、アプリでフィルタして問題のサインインを特定します。
• 「Activity（アクティビティ）」→「Audit logs（監査ログ）」で認証方法の変更やポリシー変更履歴を確認します（英語: Audit logs）。
• 必要に応じて CSV エクスポートを実行し、SIEM に取り込んで長期保存します。

KQL サンプル（例示）

Log Analytics / Sentinel に取り込んだログを調査する際のサンプルクエリ例です。テーブル名やフィールド名は環境により異なる場合があるため、実行前に確認してください。

• 直近 7 日の失敗サインインの一覧（例示）:

• 認証方法の変更を監査ログで探す（例示）:

いずれも例示です。組織のフィールド名に合わせて適宜変更してください。

典型的障害の調査フロー（ヘルプデスク向け）

ヘルプデスクが迅速に初動対応できるよう、優先順位と参照ログを示します。

1. ユーザーからの報告確認と基本情報収集（ユーザー名、端末、発生時刻、エラーメッセージ）。
2. 端末側確認：ネットワーク、通知設定、バッテリー最適化、アプリバージョン。
3. 管理側確認：Sign‑in ログで該当のサインインを検索。Conditional Access の適用状況を確認。
4. 必要に応じて Audit logs で認証方法の削除・変更履歴を確認。KQL を用いて相関検索を行います。
5. 解決不能な場合はセキュリティチームへエスカレーションし、調査用のログを保存して共有します。

まとめ

Microsoft Authenticator のビジネス連携は、設計と運用の両面で配慮が必要です。導入前にライセンス、配布、パイロット計画、バックアップ方針を確定し、管理者側で変更管理と監査ログ保存ルールを整備してください。以下は要点の整理です。

• Authenticator は多要素と Passwordless を支える主要ツールです。
• ライセンスと Conditional Access の要件を契約で確認してください。
• 高リスク操作は事前承認・バックアップ・ログ保存を必須にしてください。
• バックアップと二次端末を用意し、Phone sign‑in の復元制約を周知してください。
• ログは SIEM に転送し、KQL 等で検索可能にしておくと調査が速くなります。