3行解説
- Microsoft社の仕様変更（MC862873）により、2024年10月16日以降にEntra管理センターやIntune管理センター、Azureポータルへのアクセスには多要素認証が必須となります
- 通称BreakGlassアカウントと呼ぶ緊急用アカウントのベストプラクティスも変わり、多要素認証設定が必須となります
- 携帯電話・スマートフォンやモバイルアプリに依存しないFIDO2セキュリティキーを利用したパスキーによる多要素認証設定方法および留意事項を解説します
このドキュメントは2024年8月16日現在の情報や検証結果をもとに作成しています。最新情報はMicrosoft 365 管理センターのメッセージや、以下の参考資料などをご参照ください。
はじめに：BreakGlassアカウント（緊急用アカウント）とは
Microsoft社のクラウドサービスで利用される認証基盤であるEntraでは様々な設定が可能ですが、その自由度の高さゆえに設定を誤ると全てのアカウントが認証基盤から締め出されてしまうことがあります。また、多要素認証やシングルサインオンといったモダンな認証方法が一般化した一方でその手段自体が使えなくなるケース（外部IdPのサービスダウン、モバイルネットワークの停止による通話・SMSおよびデータ通信の停止、モバイルアプリの不具合）への対処も必要です。
対処方法として、BreakGlassアカウントとも呼ばれる特定個人に紐づかない緊急用アカウントを作成しておくという方法が知られています。仕方ないので警報が鳴る覚悟でガラス戸（Glass）を破って（Break）中にはいるためのアカウント、というのが由来です。
なお、Entraでは警報を鳴らす（当該アカウントサインイン時のメール通知）ためには別途設定が必要なのですが、それは補足として紹介させていただきます。今回は緊急用アカウントの作成が主題です。
緊急用アカウントについてはMicrosoft社の公式ドキュメントも合わせてご参照ください
緊急用アカウントの管理
先ほど説明した緊急用アカウントですが、過去のベストプラクティスでは多要素認証を適用せず、単一要素であるパスワードを非常に長いものにし、パスワードを分割して印刷して封緘して複数の金庫に保存するといった方法が推奨されておりました。封を切ったら使用されたとみなしパスワードを変更するわけです。
ですが、現在は多要素認証は実施されることが望ましいということもあり、2022年にFIDO2セキュリティキーを利用する方法が記載されるようになりました。
参考：過去のベストプラクティス（2020年10月）
Organizations need to ensure that the credentials for emergency access accounts are kept secure and known only to individuals who are authorized to use them. Some customers use a smartcard and others use passwords. A password for an emergency access account is usually separated into two or three parts, written on separate pieces of paper, and stored in secure, fireproof safes that are in secure, separate locations.
参考：2022年7月の更新後
Organizations need to ensure that the credentials for emergency access accounts are kept secure and known only to individuals who are authorized to use them. Some customers use a smartcard for Windows Server AD, a FIDO2 security key for Azure AD and others use passwords. A password for an emergency access account is usually separated into two or three parts, written on separate pieces of paper, and stored in secure, fireproof safes that are in secure, separate locations.
問題：多要素認証の必須化
上記の経緯で多要素認証は推奨されてきたものの、多要素認証が適用されていないと重要なサービスにアクセスできないことはありませんでした。
ですが、今年2024年5月に大きな変更が発表されました。2024年7月からAzureポータルやAzure CLI、PowerShellを介したAzureリソース管理のためのアクセスには多要素認証が必須化されることになりました。
続報により補足が加えられ、緊急用アカウントについても多要素認証設定が推奨され、FIDO2セキュリティキーや証明書ベースの認証がその手段として提示されています。
そして、8月15日により具体的な計画が発表され、2024年10月16日より、Azureポータル、Entra管理センター、Intune管理センターのサインインには多要素認証が必須となることが発表されました。
メッセージセンターの通知や管理センター上の変化
Microsoft 365管理センターのメッセージボックスにMC862873で2024年10月16日から多要素認証が必須となるため10月15日までに対処を完了するよう告知されています。申請により来年3月までの延期は可能です。
申請の延期手順は https://jpazureid.github.io/blog/azure-active-directory/MC862873-azure-portal-mfaenforcement-update-grace-period/ をご参照ください。
Take action: Enable multifactor authentication for your tenant before October 15, 2024
Starting on or after October 15, 2024, to further increase security, Microsoft will require admins to use multi-factor authentication (MFA) when signing into the Microsoft Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center. Note: This requirement will also apply to any services accessed through the Intune admin center, such as Windows 365 Cloud PC. To take advantage of the extra layer of protection MFA offers, we recommend enabling MFA as soon as possible. To learn more, review Planning for mandatory multifactor authentication for Azure and admin portals.
How this will affect your organization:
MFA will need to be enabled for your tenant to ensure admins are able to sign-in to the Azure portal, Microsoft Entra admin center and Intune admin center after this change.
What you need to do to prepare:
- If you have not already, set up MFA before October 15, 2024, to ensure your admins can access the Azure portal, Microsoft Entra admin center, and Intune admin center.
- If you are unable to set up MFA before this date, you can apply to postpone the enforcement date.
- If MFA has not been set up before the enforcement starts, admins will be prompted to register for MFA before they can access the Azure portal, Microsoft Entra admin center, or Intune admin center on their next sign-in.
For more information, refer to: Planning for mandatory multifactor authentication for Azure and admin portals.
Entra管理センターではポップアップおよび詳細情報の告知も表示されるようになりました。詳細は以下のドキュメントでも確認できます。
なぜFIDO2セキュリティキーが推奨されるのか
緊急用アクセスアカウントに対し多要素認証を設定するとして、FIDO2セキュリティキーが推奨される経緯についてまず解説します。
多要素認証ではさまざまな認証手段が利用可能ですが、各手段を運用するために特定の技術やフレームワーク（以降、依存技術と呼びます）が使われている場合があります。例えばプッシュ通知であればモバイルOSのプッシュ通知フレームワーク、インターネット通信(WiFiまたはモバイル回線)、AzureMFAサービスが必要です。
複数の認証手段を組み合わせる多要素認証では全ての依存技術が正常に動作することが求められます。いずれかの依存技術が停止してしまうと認証が事実上不可能となります。例えばモバイルOSのプッシュ通知フレームワークに障害が発生した場合、Authenticatorアプリにプッシュ通知は届かずサインインできません。
上記の図は各認証手段ごとの依存技術を整理したものです。
障害に強い認証手段という観点でみると、依存技術が少ないほど有利と考えられます。よってWindows HelloまたはFIDO2セキュリティキーが有力な候補となります。
しかしWindows HelloはWindows端末に紐づけられるため共有も困難で長期保管管理には向いておりません。よって、依存技術が少なく保管・管理しやすいFIDO2セキュリティキーにパスキーを保存する方法が緊急用アカウント向けの認証手段として最も有用となります。
EntraでのFIDO2セキュリティキーを用いたパスキーによるパスワードレス多要素認証の設定手順解説
FIDO2セキュリティキーを用いたパスキーによる多要素認証を展開できるようテナントの設定を行い、緊急用アカウントを作成する方法を解説します。
公式ドキュメントでも解説されていますが、FIDO2セキュリティキーを使う方法として紹介されていないので併せて読んでいただくことをお勧めします。
一時アクセスパスとFIDO2セキュリティキーを認証方法として有効化する
最初に、Entra管理センターにて、認証方法として一時アクセスパス（TAP Temporary Access Pass）とパスキー（FIDO2）を有効にします。
一時アクセスパスの有効化ですが、ターゲットを「すべてのユーザー」にし「有効にする」トグルスイッチをオンにして保存すればOKです。有効期間の設定範囲や、既定値、1回限りの使用とするか、一時アクセスパスを有効期間内は繰り返し利用できるか、といった設定も調整可能です。
今回のような一般ユーザー向けのアカウントでないなら一時アクセスパス使わずにパスワードでセットアップした後でセキュリティキーを有効化する手間も特に苦にしないと思いますが、パスワード設定するのも面倒なので一時アクセスパスを使うことにします。便利な機能なのでぜひ使ってみてください。
一時アクセスパスについての詳細は以下の資料もご参照ください。
パスキー（FIDO2）も同様に有効にして保存します。検証テナントではすでに設定してましたが、ターゲットを「すべてのユーザー」に設定変更しました。
新規アカウント作成
では緊急用アカウントを作成します。ドメインはカスタムドメインでなくonmicrosoft.comドメインが推奨されます。
初期パスワードは使わず一時アクセスパスでサインインしますのでパスワードは全く見ません。
プロパティで「利用場所」の設定を欠かさずやっておきます。ライセンス割り当ては行わないので、直ちに空欄で困るわけではありませんが・・・
作成したアカウントで一時アクセスパスを有効化
作成したユーザーの詳細情報を開き、「認証方法」を選択します。「認証方法の追加」から一時アクセスパスを追加します。
方法の選択で「一時アクセスパス」を選びます。アクティブ時間（有効期間範囲）や、有効開始時間、1回限りの利用に限定する（一時使用）かはここで選択可能です。
今回は4時間かつ即時の作成としました。1回限りの有効としています。
一時アクセスパスで初回サインインを行う
一時アクセスパスを設定したアカウントは、アカウント名を入力したあとの認証でパスワードでなく一時アクセスパスを要求されます。そのまま一次アクセスパスを入力します。
今回はサインイン後そのままセキュリティキーの設定を行いたいので、https://mysignins.microsoft.com/security-info へサインインします。
セキュリティキーのセットアップ
https://mysignins.microsoft.com/security-info にサインインすると、セキュリティ情報としてサインイン手段がリストアップされた画面が表示されます。
公式情報もありますが、実際にセットアップを行いました。
今回利用したセキュリティキーはSecurity Key NFC by Yubicoと呼ばれるUSB-A接続NFC対応でFIDO2にのみ対応したシンプルなものです。
https://www.yubico.com/setup/security-key-series
「サインイン方法の追加」を選択すると認証手段の追加が行えますので「セキュリティキー」を選択します。
セキュリティキーは汎用性を重視するため、USBデバイスとして登録します。
指示に従ってUSB端子にセキュリティキーを接続し登録を行います。
ブラウザのポップアップ画面が表示され、QRコードを利用してモバイルアプリにパスキーとして登録するか、FIDO2セキュリティキーにパスキーとして登録するか選択することになります。
今回はFIDO2セキュリティキーに登録するため、USB端子にセキュリティキーを接続しタッチして登録を進めていきます。
（今回、macOS版Edgeを利用していますが、Windowsでも、ChromeやFirefoxでも対応可能です。）
今回使用したセキュリティキーは検証用ですでに利用しているものですので、登録済みのPINを入力します。新規に用意したデバイスであれば、ここでPIN登録を行います。
製造元とモデルの確認は今回は許可しておきます。（製造元やモデル情報を指定する機能があり、指定外のセキュリティキーを使えなくすることも可能です）
セキュリティキーは複数登録することができますので、識別できるよう個別の名前をつけられます。
名前を登録すれば設定完了です。
これで登録完了できました。つけた名前はYubikeyと安直でした・・・。
セキュリティキーでのサインイン
初回サインインはセキュリティキーを使う設定でないため、手動でセキュリティキーを使ったサインインを選択します。
「顔、指紋、PIN、またはセキュリティキー」を選択すると、パスキーの利用を要求されます。セキュリティキー上に保存されているパスキーを利用するため、「スマートフォン、タブレット、またはセキュリティキーを使用する」を選択します。
ここでセキュリティキーをUSB端子に接続しタッチします。
PIN入力後にサインインするアカウントを選択します。今回使ったセキュリティキーは複数のEntraアカウントで利用していたため、アカウント選択画面が表示されました。
無事サインインできました。念の為Entra管理センターで当該アカウントの認証方法設定を確認すると、無事セキュリティキーが登録され多要素認証に標準でセキュリティキーを使う設定になっていることが確認できました。使用済みになった一時アクセスパスも削除しておくとさらに良いです。
グローバル管理者権限付与と権限反映確認
アカウントの準備ができたので、Entra管理センターからグローバル管理者権限をロールで割り当て、実際に特権操作が可能なことを確認すれば完了です。（権限反映までタイムラグがありますので、慌てず待ちます）
補足情報
はい、その通りです。対応しているOSとブラウザがあれば利用可能で、現在サポートされているOSバージョンと最新版のブラウザであれば概ねOKです。
デバイスにより設定が異なる場合がありますので、各デバイスのベンダーに確認することをお勧めします。
ちなみに今回使用したデバイスではPINは4−63文字のASCII文字列で、8回連続で間違えるとロックアウトされ初期化が必要になります。初期化されたら当然ですが保存されているパスキーはもう利用できません。
認証技術としては同じものです。クラウドサービスのアカウント（GoogleアカウントやAppleアカウント、Microsoftアカウント、パスワードマネージャーサービス等）と紐づいてデバイスを跨いで認証鍵を共有するものを同期パスキー（狭義でのパスキー）と呼び、セキュリティキー等に保存されデバイスを跨がないものをデバイス固定パスキーと呼びます。
緊急用アカウントが使用されたことを確認する方法
冒頭で緊急用アカウントは警報が鳴る覚悟でガラス戸（Glass）を破って（Break）中にはいるためのアカウントと説明しましたが、Entraで警報を鳴らす（当該アカウントサインイン時のメール通知）方法について最後に紹介します。
Log Analyticsの設定を行うのでEntraおよびMicrosoft 365の契約だけでは設定することができません。Azureサブスクリプションの準備が必要です。詳細は公式ドキュメントに記載されているので可能であれば設定をお勧めします。
結論
これまで緊急用アカウントは複雑な単一要素認証を安全に共有管理するという考え方で作成してきましたが、今回発表された仕様変更により多要素認証を実現しつつ安全に管理することが求められるようになります。
そこで、FIDO2セキュリティキーを利用してパスキーを保存する方法について利点を整理し、実際に動作検証してみました。
検証の結果問題なくFIDO2セキュリティキーにパスキーを保存できましたので、FIDO2セキュリティキーを封緘・保管管理しつつ緊急用アカウントの利用があれば通知されるよう設定する方法が今後のベストプラクティスとなりうることが確認できました。
多要素認証必須化は延長可能とはいえ、通常利用される管理者権限は多要素認証設定済みでしょうから、この機会に速やかに緊急用アカウントも多要素認証に対応させて対応完了してしまうことをお勧めします。
