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

サインインまたはロールのアクティブ化ができないため、誤ってMicrosoft Entra組織からロックアウトされないようにすることが重要です。 組織内に 2 つ以上の 緊急アクセス アカウント を作成することで、管理アクセスの不注意による影響を軽減できます。

グローバル管理者ロールを持つユーザー アカウントはシステムで高い特権を持ち、このロールにはグローバル管理者ロールを持つ緊急アクセス アカウントが含まれます。 緊急アクセス アカウントは、通常の管理アカウントを使用できない緊急時、または「ブレークグラス」シナリオでのみ使用してください。 緊急アカウントの使用を、絶対に必要な時間のみに制限します。

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

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

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

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

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

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

  1. 既存の緊急アクセス アカウントを見つけるか、 新しいクラウド専用ユーザーを作成 し、グローバル管理者ロールを割り当てます。

  2. 緊急アクセスアカウントに対して、次のいずれかのパスワードレス認証方法を選択します。 これらの方法は、必須の多要素認証要件を満たします。

  3. 前の手順で選択した認証方法の資格情報を登録します。

  4. サインインをブロックまたは制限する条件付きアクセス ポリシーから緊急アクセス アカウントが除外されていることを確認します。 前の手順で登録したフィッシング対策認証方法は、アカウントを保護します。適用された条件付きアクセス ポリシーは、アカウントが設計されている緊急の間にサインインを防ぐことができます。 レポート専用ポリシーはアクセスをブロックせず、除外を必要としません。 詳細については、「 条件付きアクセスに関する考慮事項」を参照してください。

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

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

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

構成要件

これらのアカウントを構成するときは、次の要件が満たされていることを確認します。

  • 緊急アクセスアカウントを組織内の個々のユーザーに関連付けないでください。 管理チームの複数のメンバーが利用できる既知の安全な場所に資格情報を格納します。 これらのアカウントを、電話などの従業員が提供するデバイスに接続しないでください。 このアプローチは、緊急アクセスアカウント管理を統合します。 ほとんどの組織では、Microsoft Cloudインフラストラクチャだけでなく、オンプレミス環境、フェデレーション SaaS アプリケーション、およびその他の重要なシステムについても緊急アクセス アカウントが必要です。

    または、管理者用に個別の緊急アクセス アカウントを作成することもできます。 このソリューションは、アカウンタビリティを高め、管理者がリモートの場所から緊急アクセスアカウントを使用できるようにします。

  • 緊急アクセスアカウントに強力な認証を使用し、他の管理アカウントと同じ認証方法を使用していないことを確認します。 たとえば、通常の管理者アカウントで、強力な認証に Microsoft Authenticator アプリを使用している場合、緊急用アカウントには FIDO2 セキュリティ キーを使用します。 認証プロセスに外部要件を追加しないようにするには、 さまざまな認証方法の依存関係を考慮してください。

  • デバイスまたは資格情報は、有効期限が切れておらず、使用不足による自動クリーンアップの対象になっていないことが必要です。

  • Microsoft Entra Privileged Identity Managementで、緊急アクセス アカウントの対象ではなく、グローバル管理者ロールの割り当てを永続的にアクティブにします。

  • これらの緊急アクセス アカウントを使用する権限を持つ個人は、指定されたセキュリティで保護されたワークステーション、または特権アクセス ワークステーションなどの同様のクライアント コンピューティング環境を利用する必要があります。 緊急アクセス アカウントを操作するときは、これらのワークステーションを使用します。 指定されたワークステーションがある Microsoft Entra テナントの構成の詳細については、特権アクセス ソリューション の展開に関するページを参照してください。

フェデレーション ガイド

一部の組織では、Active Directory Domain Services と Active Directory フェデレーション サービス (AD FS) または類似の ID プロバイダーを使用して、Microsoft Entra ID にフェデレーションします。 オンプレミス システムの緊急アクセスとクラウド サービスの緊急アクセスを区別し、相互に依存関係を持たないようにします。 他のシステムからの緊急アクセス特権を持つアカウントの認証をマスターまたはソーシングすると、それらのシステムで障害が発生した場合に不要なリスクが発生します。

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

緊急アクセス アカウントの資格情報がセキュリティで保護され、使用を許可されている個人にのみ認識されていることを確認します。 たとえば、Microsoft Entra ID FIDO2 セキュリティ キー、Windows Server Active Directory のスマートカードを使用できます。 資格情報は、安全で防火性の高い安全な場所に保管します。

条件付きアクセスに関する考慮事項

サインインをブロックまたは制限する条件付きアクセス ポリシーから緊急アクセス アカウントを除外します。 レポート専用ポリシーはアクセスをブロックせず、緊急アカウントを除外する必要はありません。 緊急アクセス アカウントが、MFA、準拠デバイス、または別の制御を必要とする条件付きアクセス ポリシーの対象である場合、そのアカウントが設計されている緊急シナリオの間は使用できない可能性があります。

条件付きアクセスの展開を計画するときは、次の点を考慮してください。

  • EmergencyAccess などの緊急アクセス アカウント専用のセキュリティ グループを作成し、サインインをブロックまたは制限する条件付きアクセス ポリシーからこのグループを除外します。
  • 緊急アクセス アカウントが現在の条件付きアクセス構成で正常にサインインできることを定期的にテストします (たとえば、四半期ごと)。
  • 障害発生時に有効にして重要なユーザーのアクセスを復元できるコンティンジェンシー条件付きアクセス ポリシーを作成します。 詳細については、「 回復性のあるアクセス制御管理戦略を作成する」を参照してください。

条件付きアクセスの除外の計画の詳細については、「 条件付きアクセスの展開を計画する」を参照してください。

セキュリティ ガードレールの概要

次のチェックリストは、緊急アクセス アカウントのセキュリティ要件をまとめたものです。

  • 冗長性を確保するために、少なくとも 2 つの緊急アクセス アカウントを維持します。
  • フェデレーション ID プロバイダーに依存しないクラウド専用アカウント (.onmicrosoft.com ドメイン) を使用します。
  • 通常の管理者アカウントとは異なるフィッシングに強い認証方法 (FIDO2 セキュリティ キーまたは証明書ベースの認証) を使用します。
  • 資格情報とデバイスの有効期限が切れていないか、自動クリーンアップの対象になっていないことを確認します。
  • Privileged Identity Management で、緊急アカウントにグローバル管理者ロールを永続的にアクティブ（対象外）として割り当てます。
  • 緊急アクセス アカウントを使用する場合は、指定されたセキュリティで保護されたワークステーションまたは 特権アクセス ワークステーション を使用する必要があります。
  • 承認された個人がアクセスできる、安全で防火性の高い別の場所に資格情報を保存します。
  • サインインをブロックまたは制限する条件付きアクセス ポリシーから緊急アクセス アカウントを除外します。 レポートのみのポリシーでは、除外は必要ありません。
  • 不要な使用または未承認の使用を検出するために、アラートを含む緊急アクセス アカウントのすべてのサインインと監査ログ アクティビティを監視します。
  • 少なくとも 90 日ごとにアカウント機能を検証します。

監査可能性とコンプライアンス

規制対象の業界の組織では、緊急アクセス アカウントの使用が適切に管理されていることを示す必要がある場合があります。 この記事で説明する監視と検証のプラクティスでは、監査可能性がサポートされています。

  • サインインと監査ログの監視: 緊急アクセス アカウントを使用するたびにアラートを構成します。 レビューのためにサインイン ログと監査ログをキャプチャします。 詳細については、この記事 の「サインイン ログと監査ログの監視」 を参照してください。
  • 事後レビュー: 緊急アクセス アカウントを使用した後、レビューを実施して、使用が承認されたかどうか、および実行されたアクションが適切かどうかを判断します。 詳細については、この記事の事後検証チームを編成するを参照してください。
  • 定期的な検証: 少なくとも 90 日ごとにアカウント検証訓練を実行します。これには、承認されたユーザーリストの確認、サインインと管理タスクの機能のテストが含まれます。 詳細については、この記事の 「アカウントを定期的に検証する 」を参照してください。
  • コンプライアンス マッピング: 組織が HIPAA 規制に準拠する必要がある場合、Microsoftは、緊急アクセス アカウントが HIPAA 緊急アクセス手順要件にどのようにマップされるかに関するガイダンスを提供します。 詳細については、 HIPAA アクセス制御に関するページを参照してください。

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

緊急アカウントからのサインインと監査ログアクティビティを監視し、他の管理者に通知をトリガーします。 緊急アクセスアカウントのアクティビティを監視する場合、これらのアカウントがテストまたは実際の緊急時にのみ使用されていることを確認できます。 Azure Monitor、Microsoft Sentinel、またはその他のツールを使用してサインイン ログを監視し、緊急アクセスアカウントがサインインするたびに管理者に電子メールと SMS アラートをトリガーできます。 このセクションでは、Azure Monitor の使用方法について説明します。

前提条件

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

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

  2. Entra ID>Users に移動します。

  3. 緊急アクセス用アカウントを検索し、ユーザーの名前を選択します。

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

  5. 2 番目の緊急アクセス アカウントに対して前の手順を繰り返します。

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

  1. Azure portal に監視共同作成者以上でサインインします。

  2. Monitor を検索して開きます。

  3. 左側のメニューで、[アラート] を選択 します。

  4. [+ 作成]>[アラート ルール] を選択します。 [アラート ルールの作成] ページが開きます。

  5. スコープ タブで:

    1. リソースの選択 ウィンドウで、Log Analytics ワークスペースを見つけて選択します。
    2. サブスクリプションが前提条件で構成したワークスペースと一致することを確認します。
    3. を選択してを適用します。

  6. [条件] タブで:

    1. [ シグナル名 ] ドロップダウンから、[ カスタム ログ検索] を選択します。

    2. [クエリの種類] を [集計ログ] に設定します。

    3. [ 検索クエリ] で、次のいずれかのクエリを入力し、2 つの緊急アクセス アカウントのオブジェクト ID を挿入します。

      注

      追加する緊急アクセス アカウントごとに、クエリに別の or UserId == "ObjectGuid" を追加します。

      サンプル クエリ:

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

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

      // Search for a single UserPrincipalName
SigninLogs
| where UserPrincipalName == "user@yourdomain.onmicrosoft.com"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

    4. [ 測定] で、クエリの結果を集計する方法を設定します。

      1. 測定を選択します。
      2. 集計の 種類を選択します。
      3. [集計の粒度] を選択します。

    5. ディメンション別に分割 で、リソース ID 列を選択します。

    6. [アラート ロジック] で、以下の手順を実行します:

      1. しきい値の種類を [静的] に設定します。
      2. 演算子を [より大きい] に設定します。
      3. しきい値を 0 に設定します。
      4. 評価の頻度を、クエリを実行する頻度に設定します。

      しきい値の種類、演算子、しきい値、評価の頻度の値の例を含むアラート ロジック設定のスクリーンショット。

    7. [次へ] をクリックして続行します。

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

  8. [詳細] タブでは:

    1. イベントの 重大度 を選択します。 0 - Critical を使用します。
    2. アラート ルール名を入力し、オプションの説明を追加します。
    3. [リージョン] を選択します。
    4. ログ クエリの実行時に使用する ID を 選択します。
    5. [ 詳細オプション] で、[ 作成時に有効にする] を選択します。
    6. [次へ] をクリックして続行します。

  9. [ タグ ] タブで、アラート ルールに関連付けるタグを追加します。

  10. [ 確認と作成] を選択し、[ 作成] を選択します。

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

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

    [基本] タブが開いている [アクション グループの作成] 画面のスクリーンショット。

  2. [基本] タブで、次の情報を入力します。

    • サブスクリプション と リソース グループ: アクション グループを格納する場所を選択します。
    • リージョン: アクション グループのリージョンを選択します。
    • アクション グループ名: わかりやすい名前を入力します。
    • 表示名: 通知に表示される短い名前 (最大 12 文字) を入力します。

  3. [次へ: 通知] を選択します。

  4. [ 通知の種類] で、[ 電子メール/SMS メッセージ/プッシュ/音声] を選択します。

  5. [ 全体管理者に通知] などの通知名を入力します。

  6. [ 詳細の編集] を選択し、通知方法と連絡先情報を構成して、[ OK] を選択します。

  7. トリガーするその他の通知を追加します。

  8. [ 次へ: アクション] を選択して追加の自動化されたアクションを構成するか、[ 確認と作成 ] を選択して完了します。

各緊急アクセスアカウントの資格情報利用を評価するため、事後評価チームを準備する

アラートがトリガーされた場合は、Microsoft Entra やその他のワークロードのログを保持します。 状況と緊急アクセス アカウントの使用状況の結果のレビューを行います。 このレビューでは、アカウントが使用されたかどうかを判断します。

  • 計画されたドリルで適合性を検証する
  • 管理者が通常のアカウントを使用できない実際の緊急時に対応する
  • アカウントの誤用または無断使用の結果として

次に、ログを調べて、緊急アクセス アカウントを持つ個人が実行したアクションを特定し、それらのアクションがアカウントの承認された使用と一致していることを確認します。

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

緊急アクセスアカウントを使用するようにスタッフメンバーをトレーニングするだけでなく、承認されたスタッフが緊急アクセスアカウントにアクセスできることを検証する継続的なプロセスを用意します。 アカウントの機能を検証し、アカウントが誤用された場合に監視ルールとアラート ルールがトリガーされることを確認するための訓練を定期的に実施します。 少なくとも、一定の間隔で次の手順を実行します。

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

次の手順を定期的に実行し、主な変更を行います。

  • 少なくとも 90 日ごと
  • 退職後や役職変更など、IT スタッフの最近の変更がある場合
  • 組織内のMicrosoft Entra サブスクリプションが変更されたとき

次のステップ

関連するコンテンツ

  • Last updated on