Contents
パスワードレス（Microsoft Authenticator）概要と利点
Microsoft Authenticator を用いたパスワードレスは、クラウド アクセスの利便性を高めつつフィッシング耐性を向上させます。Phone sign‑in は展開が比較的容易で、FIDO2/Windows Hello は端末やキーでより強固なログオンを提供します。
Phone sign‑in と FIDO2／Windows Hello の違い
Phone sign‑in、FIDO2、Windows Hello の役割が混同されないように簡潔に整理します。
- Phone sign‑in
- モバイルアプリのプッシュ承認を使うクラウド認証。ユーザー体験がシンプルで展開しやすいです。
- FIDO2（セキュリティキー）
- 公開鍵基盤に基づくパスキー。フィッシング耐性が高く、共有端末や高リスクアカウントに適します。
- Windows Hello for Business
- Windows デバイス専用の生体／PIN サインイン。Windows ログオンの置換を検討する場合に採用します。
Authentication Strength と TAP の定義
導入時に使う用語を明示します。
- Authentication Strength（認証強度）
- 複数の認証手段を組み合わせ、Conditional Access で識別可能な「強度」を定義する仕組みです。
- Temporary Access Pass（TAP）
- 一時的なコードで、新端末登録や紛失時の復旧に用いる短時間有効なワンタイム手段です。
導入前の前提条件とアカウント区分（ライセンス・管理ロール・端末）
導入前に確認すべき項目を整理します。ライセンスや管理ロール、端末要件は運用に直結しますので事前に明確にしてください。
対象アカウント（組織アカウント vs MSA）
アカウント種別ごとの取り扱いを整理します。
- 組織アカウント（Microsoft Entra ID / Azure AD）
- 管理対象であり、本記事の主対象です。Conditional Access 等の設定が適用できます。
- 個人の Microsoft アカウント（MSA）
- Phone sign‑in をサポートする場合がありますが、企業側での制御や監査が限定されます。企業リソースへは組織アカウントを推奨します。
必要なライセンスと推奨最小管理ロール
最低限確認すべきライセンスと割当ロールを示します。詳細は公式ドキュメントで都度確認してください。
- ライセンス（目安）
- Conditional Access を利用する場合は Azure AD Premium P1 相当以上が一般的に必要です。Authentication Strength や一部機能は P2 等の追加要件がある場合があります。
- 推奨管理ロール（最小権限）
- Authentication Administrator（認証手段の管理）または Global Administrator（全権限）。
- Conditional Access Administrator（ポリシー作成・管理）を分離して付与することを推奨します。
- TAP 発行／認証リセットは Authentication Administrator 権限が必要なケースが多い点に注意してください。
クライアント要件と Intune 連携
デバイス側で満たすべき要件と Intune と併用する場合のポイントです。
- サポート OS／アプリ
- Microsoft Authenticator は iOS/Android の各ストア配布版を使用します。最新の安定版を推奨します。
- ネットワーク／通知
- プッシュ通知を受け取れる設定、バックグラウンド更新、バッテリー最適化の例外設定を案内してください。
- Intune 連携（推奨）
- Conditional Access で「デバイスを準拠（Compliant）」と連携する場合は Intune からの準拠レポートを前提にポリシー設計します。
- 共有／キオスク端末の注意点
- Phone sign‑in は個人のスマホを前提とするため、共有端末やキオスク用途は FIDO2 や Windows の共有ログオン方式を検討してください。
Entra 管理センターでの具体的な設定手順（遷移パスと設定値）
ここでは管理者が管理センターで行う具体的な操作手順を、遷移パスとクリック順で示します。UI 名称は変わることがあるため、作業前に公式ドキュメントで最終確認してください。
管理センターの遷移パス（サインインとメニュー）
管理画面の入り口と代表的な遷移パスを示します。管理者はまず自身の権限を確認してください。
- ブラウザで Microsoft Entra 管理センター（https://entra.microsoft.com）にサインインします。Global Administrator または Authentication Administrator の権限が必要です。
- 左メニューから「Identity」または「Azure Active Directory」を選択します。
- 「Security」→「Authentication methods」（認証方法）や「Conditional Access」を選択して各設定画面へ移動します。
（検索ボックスに "Authentication methods" や "Conditional Access" を入力して直接移動できます）
Microsoft Authenticator（Phone sign‑in）の有効化（UI での具体手順）
Phone sign‑in の有効化と対象指定の標準的な手順です。手順は UI により若干の差があります。
- Entra 管理センター → Identity → Security → Authentication methods を開きます。
- 「Microsoft Authenticator」または該当の行を選択します。
- Phone sign‑in のトグルを「Enable」または「On」に切り替えます。
- 「対象の指定（Include / Exclude）」で最初は特定グループ（例: PA-PhoneSignIn-Pilot）を選択し、パイロットで運用します。
- Save（保存）して設定を反映します。
- 自動登録やセルフサービス登録の案内を用意し、ユーザーに手順を共有します。
推奨の設定値（初期パイロット）
- 対象: 小規模パイロットグループ（5〜20 名）
- ポリシー動作: Conditional Access は最初「Report-only」で監視、問題なければ「On」に移行
Temporary Access Pass（TAP）の発行手順（管理者操作）
TAP は端末紛失時や初期登録での復旧に使います。発行は最小権限で運用してください。
- Entra 管理センター → Users → 該当ユーザーを選択 → Authentication methods（認証方法）を開きます。
- 「+ Add method」→「Temporary Access Pass」を選択します。
- 開始日時、寿命（例: 10、30、60 分のいずれか）、使い捨て（isUsableOnce）を設定して発行します。
- 発行ログを必ず記録し、本人確認フロー（電話確認など）を経てコードを伝達します。
運用上の注意
- TAP は短時間・使い捨てを原則にする。
- 発行ログを監査対象にする。
- TAP 発行は認証管理者に限定し、発行ポリシーを文書化する。
PowerShell / Microsoft Graph による自動化例
設定や運用を自動化する場合の概念スニペットを示します。API 仕様は更新されやすいので、本番適用前に公式 API リファレンスを確認してください。
Microsoft Graph（Authentication Methods 設定の概念例）
以下は概念的な流れです。実際の JSON フィールドやエンドポイントはドキュメントに従って調整してください。
- 管理者で Microsoft Graph に接続（MS Graph PowerShell や OAuth トークンを使用）。
- 設定一覧を取得して対象 ID を確認。
- GET https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations
- Microsoft Authenticator の構成を更新して有効化・対象グループを追加。
- PATCH https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/{id}
- ボディ例: { "isEnabled": true, "includeTargets": [ { "id": "
", "targetType": "group" } ] }
注意: 上記は概念例です。beta エンドポイントは将来変わる可能性があるため、v1.0 が対応していればそちらを優先してください。
Microsoft Graph（TAP 発行の概念スニペット）
ユーザーに対して TAP を発行する場合の概念的な POST 例です。
- POST https://graph.microsoft.com/beta/users/{userId}/authentication/temporaryAccessPassMethods
- ボディ例:
{ "startDateTime":"2024-01-01T00:00:00Z", "lifetimeInMinutes":30, "isUsableOnce":true }
レスポンスで発行された一時パスが返却されます。発行後は即時ログ記録と本人確認を実施してください。
PowerShell（Graph 呼び出しの概念フロー）
Graph PowerShell を用いる場合の接続例と Invoke の概念です。
- Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","UserAuthenticationMethod.ReadWrite.All"
- $body = <構成 JSON>
- Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies" -Body ($body | ConvertTo-Json -Depth 10)
実運用ではまず少数のテストで API 呼び出しの挙動を確認してください。
Conditional Access と Authentication Strength の設計とサンプルポリシー
Authentication Strength を使うことで「パスワードレス相当」の要件を Conditional Access に紐づけられます。以下は段階的設計と具体例です。
段階的強化の設計（推奨フロー）
段階的に対象を広げ、ログとサポート負荷を確認しながら有効化します。
- 段階 0（パイロット）: 管理センターで Phone sign‑in を有効化。対象は 5〜20 名のテストグループ。Conditional Access は Report-only。
- 段階 1（管理者優先）: 特権ロールに Authentication Strength を要求。リスク条件を追加。
- 段階 2（業務アプリ拡大）: 業務アプリに対してパスワードレスを要求。デバイス準拠や Intune 条件を組合せ。
代表的なサンプルポリシー（3 例）
以下は Conditional Access ポリシーの設定例（ポリシー名、対象、条件、付与）です。UI 上の値をそのまま入力するイメージで作成してください。
- ポリシー A: 管理者向け強制パスワードレス（推奨: 検証後有効）
- 対象ユーザー: グローバル管理者 / Privileged roles グループ
- 対象アプリ: All cloud apps（初期は重要アプリに限定）
- 条件: 場所（国外アクセス）やリスク（ユーザーリスク）を追加可
- 付与: Require authentication strength → 選択: Passwordless-PhoneSignIn（作成した認証強度）
-
動作: 初期は Report-only、その後 On
-
ポリシー B: 業務アプリ（Office 365）でのパスワードレス優先化
- 対象ユーザー: 全従業員（段階的に拡大）
- 対象アプリ: Office 365（Exchange Online, SharePoint 等）
-
付与: Require authentication strength または Require device to be marked as compliant + Allow access
-
ポリシー C: 高リスクアクセス時は FIDO2 を必須化
- 対象ユーザー: 高感度データを扱うグループ
- 条件: クライアントアプリ／リスクシグナル
- 付与: Require authentication strength → 選択: FIDO2-Required
実装時の注意点
- まずは Report-only で影響を可視化する。
- ポリシーの除外は慎重に最小化する。
- ポリシー変更時は事前にコミュニケーションを行う。
ロールアウト計画・運用チェックリストとトラブルシューティング
実運用フェーズでのチェック項目、障害対応、監査の具体的手順を示します。管理者とユーザー向けチェックリストを分けて整理します。
パイロット設計（管理者用チェックリスト）
パイロットを円滑に進めるための管理者視点の必須項目です。
- 対象グループの作成（例: PA-PhoneSignIn-Pilot）とメンバー確定
- 必要ロールの割当（Authentication Administrator、Conditional Access Administrator 等）
- Entra での Phone sign‑in 有効化と Authentication Strength 作成
- Conditional Access ポリシーを Report-only で作成・適用
- ログ取得設定（Sign‑in logs、Audit logs、Intune レポート）を確認
- サポート体制確保（ヘルプデスク手順、TAP 発行ルール、本人確認フロー）
ユーザー向け導入・トラブルシューティング（短い案内）
エンドユーザー向けに配布すべき手順と想定される障害と対処例です。
- 初期案内: Authenticator のインストール、通知とアプリロックの有効化、アカウント登録手順
- よくある問題と対応例
- 通知が届かない: ネットワーク・通知許可・バッテリー最適化を確認。アプリ更新と再起動を推奨。
- Phone sign‑in が表示されない: 管理者許可とアプリ OS バージョンを確認。
- アカウント競合: Authenticator の表示名やアカウントラベル運用でユーザー混乱を減らす。
監査ログと KPI（推奨指標と KQL の概念例）
導入効果と問題発見のための KPI とログ分析の方針例です。ログ項目名は環境により異なるため、実際はログフィールドを確認してクエリを調整してください。
- 推奨 KPI（目安）
- 採用率（登録ユーザー比）: パイロット終了後 60〜80% を目標（組織により目標値は調整）
- サインイン失敗率: 全体の 3% 未満を目標（高ければ原因調査）
-
サポート件数: 100 ユーザーあたり月 2 件未満が目安（サポート体制で変動）
-
ログ確認の概念的 KQL（Log Analytics による例）
-
Signin ログの集計例（概念）:
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationMethodsUsed contains "Phone" // 実フィールド名に置換
| summarize Success = countif(ResultType == 0), Failure = countif(ResultType != 0) by bin(TimeGenerated, 1d) -
フィールド名はサインインログのスキーマに依存します。実環境でフィールド名を確認して調整してください。
ロールバック手順と責任分担（簡潔な手順例）
障害時の迅速な復旧手順と責任者の例を示します。
- 緊急対応フロー（代表例）
- 影響範囲の特定（Sign‑in ログで影響ユーザーを抽出）
- 問題のある Conditional Access ポリシーを一時的に「Off」または「Report-only」に設定（Conditional Access Administrator）
- 必要に応じて Authentication Methods の対象を元に戻す（Authentication Administrator）
- TAP を発行して該当ユーザーの復旧を支援（Helpdesk + 認証担当者）
-
事後分析と手順・ドキュメントの更新（セキュリティ担当）
-
役割例
- 緊急対応責任者: セキュリティ管理者（決裁権限）
- 設定変更実行: Conditional Access / Authentication 管理者
- ユーザー対応: ヘルプデスク（TAP 発行手順に従う）
よくある質問（FAQ）
導入時に頻出する Q&A を短く示します。
- Q: 必要なライセンスは？
-
A: Conditional Access は一般に Azure AD Premium P1 以上が必要です。Authentication Strength の一部機能は P2 等の追加要件がある場合があるため、公式ドキュメントで確認してください。
-
Q: MSA（個人アカウント）はどう扱う？
-
A: MSA は企業の Entra 管理下にないため、企業リソースへは組織アカウントの利用を推奨します。MSA 向け手順は別途用意してください。
-
Q: Windows ログオンも完全にパスワードレスにできますか？
-
A: Windows デバイスのローカルログオンは Windows Hello for Business や FIDO2 の採用が一般的です。Phone sign‑in は主にクラウドアプリ向けです。
-
Q: TAP の発行は誰が行うべきか？
- A: TAP の発行は最小権限で Authentication Administrator 等に限定し、本人確認プロセスを運用で定めてください。
参考（公式ドキュメント）
以下は主要な公式ドキュメントです。設定の詳細や API の最新仕様は必ず参照してください。
-
Microsoft Learn: Phone sign‑in（Microsoft Authenticator）
https://learn.microsoft.com/azure/active-directory/authentication/howto-authentication-phone-signin -
Microsoft Learn: Authentication methods（認証方法の概念）
https://learn.microsoft.com/azure/active-directory/authentication/concept-authentication-methods -
Microsoft Learn: Authentication Strength（認証強度）
https://learn.microsoft.com/azure/active-directory/authentication/concept-authentication-strength -
Microsoft Learn: Temporary Access Pass（TAP）
https://learn.microsoft.com/azure/active-directory/authentication/concept-temporary-access-pass -
Microsoft Learn: Conditional Access の概要
https://learn.microsoft.com/azure/active-directory/conditional-access/overview -
Microsoft Graph API（Authentication Methods / TAP）
https://learn.microsoft.com/graph/api/resources/authenticationmethodconfiguration?view=graph-rest-beta
（注）上記リンク先の UI 名称や API 仕様は随時更新されます。実際の操作や自動化スクリプト作成時は必ず該当ドキュメントを参照してください。