Microsoft Entra ID で緊急アクセス用管アカウントを管理する

管理者としてサインインしたり、別のユーザーのアカウントをアクティブ化できなくなるため、Microsoft Entra 組織から誤ってロックアウトされないようにすることが重要です。 複数の "緊急アクセス用アカウント" を組織に作成することにより、誤って管理アクセスが不可能になることによる影響を軽減できます。

緊急アクセス アカウントは特権性が高いため、特定の個人には割り当てられません。 緊急アクセス用アカウントは、通常の管理者アカウントを使うことができない "緊急事態" に制限されます。 緊急用アカウントはどうしても必要なときにだけ使うという制限を守ることをお勧めします。

この記事では、Microsoft Entra ID で緊急アクセス用アカウントを管理するためのガイドラインを提供します。

緊急アクセス用アカウントを使用する理由

次のような場合に緊急アクセス用アカウントの使用が必要になることがあります。

• ユーザー アカウントがフェデレーションされており、携帯ネットワークの途絶または ID プロバイダーの停止のためにフェデレーションを現在使用できない場合。 たとえば、環境内の ID プロバイダー ホストがダウンしている場合、Microsoft Entra ID が ID プロバイダーにリダイレクトしたときにユーザーはサインインできない可能性があります。
• 管理者が Microsoft Entra 多要素認証によって登録されていて、すべての個別デバイスを利用できないか、サービスを利用できない場合。 ユーザーは、ロールをアクティブ化する多要素認証を完了できない可能性があります。 たとえば、携帯ネットワークが停止すると、ユーザーがデバイスに対して登録したただ 2 つの認証メカニズムである、電話呼び出しへの応答も、テキスト メッセージの受信も、できなくなります。
• 最後にグローバル管理者アクセス権を持っていたユーザーが組織からいなくなった場合。 Microsoft Entra ID では最後の全体管理者アカウントを削除できないようになっていますが、オンプレミスでアカウントが削除または無効化されるのを防ぐことはできません。 いずれの場合も、アカウントを復旧できなくなる可能性があります。
• 自然災害などの予期しない状況が発生した場合。携帯電話や他のネットワークが利用できなくなる可能性があります。

緊急アクセス用アカウントを作成する

複数の緊急アクセス用アカウントを作成します。 これらのアカウントは、 *.onmicrosoft.com ドメインを使用し、オンプレミス環境からフェデレーションまたは同期されていない、クラウド専用のアカウントである必要があります。

緊急アクセス用アカウントを作成する方法:

1. Microsoft Entra 管理センターにグローバル管理者としてサインインします。

2. [ID]>[ユーザー]>[すべてのユーザー] の順に移動します。

3. [ 新規ユーザー] を選択します。

4. [Create user](ユーザーの作成) を選択します。

5. アカウントの [ユーザー名] を指定します。

6. アカウントの [名前] を指定します。

7. アカウントに長く複雑なパスワードを作成します。

8. [ロール] には、[グローバル管理者] ロールを割り当てます。

9. [使用場所] では、適切な場所を選択します。

   

10. ［作成］ を選択します

11. アカウントの資格情報を安全に保管する。

12. サインイン ログと監査ログを監視する。

13. アカウントを定期的に検証する。

これらのアカウントを構成するときに、次の要件が満たされている必要があります。

• 緊急アクセス アカウントは、組織内の個々のユーザーに関連付けられていてはなりません。 アカウントが、従業員が提供する携帯電話、個々の従業員と共に移動するハードウェア トークン、またはその他の従業員固有の資格情報を使用して接続されていないことを確認します。 この予防策には、資格情報が必要なときに従業員がそれを入手できないような状況が該当します。 Microsoft Entra ID との複数の通信手段がある既知の安全な場所に、登録済みのデバイスを保管しておくことが重要です。
• 緊急アクセス用アカウントには強力な認証を使用するものとし、他の管理者アカウントと同じ認証方法は決して使用しないでください。 たとえば、通常の管理者アカウントで、強力な認証に Microsoft Authenticator アプリを使用している場合、緊急用アカウントには FIDO2 セキュリティ キーを使用します。 認証プロセスに外部の要件が加わらないよう、各種認証方法の依存関係を考慮してください。
• デバイスまたは資格情報は、有効期限が切れておらず、使用不足による自動クリーンアップの対象になっていないことが必要です。
• Microsoft Entra Privileged Identity Management では、グローバル管理者ロールの割り当てを、緊急アクセス用アカウントの臨時管理者ではなく常任管理者にする必要があります。

少なくとも 1 つのアカウントを電話ベースの多要素認証から除外する

侵害されたパスワードによる攻撃のリスクを減らすため、すべての個別ユーザーに対して多要素認証を使うことをお勧めします。 このグループには、管理者と、アカウントが侵害されると重大な影響のある他のすべてのユーザー (たとえば財務責任者) が含まれます。

ただし、緊急アクセス アカウントの少なくとも 1 つは、他の非緊急アカウントと同じ多要素認証メカニズムを使用しないようにする必要があります。 これにはサード パーティの多要素認証ソリューションも含まれます。 Microsoft Entra ID および他の接続されているサービスとしてのソフトウェア (SaaS) アプリのすべての管理者に対して多要素認証を要求する条件付きアクセス ポリシーがある場合は、緊急アクセス用アカウントをこの要件から除外し、代わりに別のメカニズムを構成してください。 さらに、アカウントにユーザーごとの多要素認証ポリシーがないようにする必要があります。

少なくとも 1 つのアカウントを条件付きアクセス ポリシーから除外する

緊急時に、問題を解決するためのアクセスがポリシーによってブロックされる可能性があるようでは困ります。 条件付きアクセスを使用する場合、すべての条件付きアクセス ポリシーから少なくとも 1 つの緊急アクセス用アカウントを除外する必要があります。

フェデレーション ガイド

AD Domain Services と AD FS または類似の ID プロバイダーを使用して Microsoft Entra ID にフェデレーションする組織もあります。 オンプレミス システムの緊急アクセスとクラウド サービスの緊急アクセスは、相互に依存しないよう分ける必要があります。 緊急アクセス特権を持つアカウントに対する認証を他のシステムからマスタリングまたはソーシングすると、それらのシステムが停止した場合に不要なリスクが生じます。

アカウントの資格情報を安全に保管する

緊急アクセス用アカウントの資格情報は安全に保管し、それらを使うことを許可されたユーザーのみに知らせる必要があります。 一部のお客様は Windows Server AD のスマートカード、すなわち Microsoft Entra ID の FIDO2 セキュリティ キーを使用し、他のお客様はパスワードを使用します。 緊急アクセス用アカウントのパスワードは、通常、2 または 3 つの部分に分けて、異なる紙に書き記し、個別に安全な耐火性の場所に保管します。

パスワードを使用する場合は、アカウントに有効期限のない強力なパスワードが設定されていることを確認してください。 理想的には、パスワードは、少なくとも 16 文字の長さでランダムに生成する必要があります。

サインイン ログと監査ログを監視する

組織では、緊急用アカウントからのサインインと監査のログ アクティビティを監視し、他の管理者に通知をトリガーする必要があります。 緊急用アカウントでのアクティビティを監視すると、これらのアカウントがテストまたは実際の緊急時にのみ使用されていることを確認できます。 Azure Log Analytics を使用すると、サインイン ログを監視し、緊急用アカウントへのサインインが発生したら常に、管理者に対するメールと SMS のアラートをトリガーすることができます。

前提条件

1. Microsoft Entra サインイン ログを Azure Monitor に送信します。

緊急用アカウントのオブジェクト ID を取得する

1. Microsoft Entra 管理センターにユーザー管理者以上でサインインしてください。

2. [ID]>[ユーザー]>[すべてのユーザー] の順に移動します。

3. 緊急用アカウントを探し、そのユーザーの名前を選択します。

4. 後で使用できるように、オブジェクト ID 属性をコピーして保存します。

5. 2 番目の緊急用アカウントに対して以上の手順を繰り返します。

アラート ルールを作成する

1. Azure portal に監視共同作成者以上でサインインしてください。

2. [監視]>[Log Analytics ワークスペース] の順に参照してください。

3. ワークスペースを選択します。

4. ワークスペースで、 [アラート]>[新しいアラート ルール] を選択します。

   1. [リソース] で、サブスクリプションがアラート ルールを関連付けようとしているものであることを確認します。

   2. [条件] で、 [追加] を選択します。

   3. [シグナル名] で [Custom log search](カスタム ログ検索) を選択します。

   4. [検索クエリ] に次のクエリを入力し、2 つの緊急用アカウントのオブジェクト ID を挿入します。

      注意

      追加する緊急用アカウントごとに、別の "or UserId == "<オブジェクト GUID>"" をクエリに追加します。

      サンプル クエリ:

      // Search for a single Object ID (UserID)
      SigninLogs
      | project UserId 
      | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
      

      // Search for multiple Object IDs (UserIds)
      SigninLogs
      | project UserId 
      | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
      

      // Search for a single UserPrincipalName
      SigninLogs
      | project UserPrincipalName 
      | where UserPrincipalName == "user@yourdomain.onmicrosoft.com"
      

      

   5. [アラート ロジック] に、次のように入力します。

      • ベース: 結果の数
      • 演算子:より大きい
      • しきい値: 0

   6. [評価基準] で、クエリの実行時間として [期間 (分単位)] を選択し、クエリを実行する頻度として [頻度 (分単位)] を選択します。 頻度は期間以下でなければなりません。

      

   7. 完了 を選択します。 これで、このアラートの月額推定コストを確認できるようになります。

5. アラートによって通知されるユーザーのアクション グループを選択します。 作成する場合は、「アクション グループを作成する」を参照してください。

6. アクション グループのメンバーに送信されるメール通知をカスタマイズするには、 [アクションをカスタマイズする] でアクションを選択します。

7. [アラートの詳細] で、アラート ルールの名前を指定し、必要に応じて説明を追加します。

8. イベントの [重大度レベル] を選択します。 [重大 (重大度 0)] に設定することをお勧めします。

9. [ルールの作成時に有効にする] は、 [はい] のままにします。

10. しばらくアラートをオフにするには、 [アラートを表示しない] チェック ボックスをオンにし、アラートが再び通知されるようになるまでの待機時間を入力して、 [保存] を選択します。

11. [アラート ルールの作成] をクリックします。

アクション グループを作成する

1. [アクション グループの作成] を選択します。

   

2. アクション グループの名前と短い名前を入力します。

3. サブスクリプションとリソース グループを確認します。

4. アクションの種類で、 [Email/SMS/Push/Voice](電子メール/SMS/プッシュ/音声) を選択します。

5. グローバル管理者に通知するなどのアクション名を入力します。

6. [アクションの種類] として [Email/SMS/Push/Voice](電子メール/SMS/プッシュ/音声) を選択します。

7. [詳細の編集] を選択し、構成する通知方法を選択して必要な連絡先情報を入力した後、 [OK] を選択して詳細を保存します。

8. トリガーするその他のアクションを追加します。

9. [OK] を選択します。

アカウントを定期的に検証する

緊急アクセス用アカウントの使用と緊急アクセス用アカウントの検証についてスタッフ メンバーをトレーニングするときは、定期的に少なくとも次の手順を行います。

• アカウントチェック アクティビティが行われていることをセキュリティ監視スタッフが認識していることを確認します。
• これらのアカウントを使用する緊急時対処プロセスが文書化され、最新のものになっていることを確認します。
• 緊急時にこれらの手順を行う必要がある可能性のある管理者およびセキュリティ担当者が、プロセスについてトレーニングされていることを確認します。
• 緊急アクセス用アカウントのアカウント資格情報 (特にパスワード) を更新し、緊急アクセス用アカウントでサインインし管理タスクを実行できることを検証します。
• ユーザーが個人のデバイスまたは詳細情報に多要素認証またはセルフサービス パスワード リセット (SSPR) を登録していないことを確認します。
• デバイスに対する Microsoft Entra 多要素認証にアカウントが登録されている場合、サインインまたはロールのアクティブ化で使うには、緊急時にデバイスを使う必要があるすべての管理者がデバイスにアクセスできることを確認します。 また、デバイスが、一般的な障害モードを共有していない 2 つ以上のネットワーク パスを介して通信できることを確認します。 たとえば、デバイスが施設のワイヤレス ネットワークと携帯電話会社ネットワークの両方を介してインターネットに通信できるようにします。

これらの手順は、以下のように定期的およびキーの変更ごとに実行する必要があります。

• 少なくとも 90 日ごと
• 異動、退職、新規採用など、最近 IT スタッフの変更があったとき
• 組織の Microsoft Entra サブスクリプションが変更されたとき

次のステップ

• Microsoft Entra ID でのハイブリッドおよびクラウド デプロイ用の特権アクセスをセキュリティで保護する
• Microsoft Entra ID を使ってユーザーを追加し、新しいユーザーにロールを割り当てる
• まだサインアップしていない場合に Microsoft Entra ID P1 または P2 にサインアップする
• ユーザーに 2 段階認証を要求する方法
• Microsoft 365 で特権ロールに対する追加の保護を構成する (Microsoft 365 を使っている場合)
• 特権ロールのアクセス レビューを開始し、既存の特権ロールの割り当てをより限定的な管理者ロールに移行する