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

[アーティクル]
02/12/2025

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

グローバル管理者ロールを持つユーザーアカウントは、システムで高い特権を持ちます。これには、グローバル管理者ロールを持つ緊急アクセスアカウントが含まれます。緊急アクセス用アカウントは、通常の管理者アカウントを使うことができない、緊急時や "ブレークグラス" シナリオのために制限されています。緊急用アカウントはどうしても必要なときにだけ使うという制限を守ることをお勧めします。

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

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

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

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

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

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

既存の緊急アクセス用アカウントを見つけるか、グローバル管理者ロールを持つ新しいアカウントを作成します。
緊急アクセスアカウントに対して、これらのパスワードなしの認証方法のいずれかを選択します。これらの方法は、必須の多要素認証要件を満たします。
- パスキー (FIDO2) (推奨)
- 既に組織に公開キー基盤 (PKI) がセットアップされている場合、証明書ベースの認証を行う
パスワードレス認証を使用するように緊急アクセスアカウントを構成します。
- 組織のパスキー (FIDO2) を有効にする
- パスキー (FIDO2) を登録する
- 証明書ベースの認証を構成する
すべての緊急アカウントに対してフィッシングに強い多要素認証が必要です。
アカウントの資格情報を安全に保管する。
サインインログと監査ログを監視する。
アカウントを定期的に検証する。

構成要件

これらのアカウントを構成する場合は、次の要件を満たす必要があります。

ほとんどの組織では、緊急アクセスアカウントは組織内の個々のユーザーに関連付けられません。資格情報は、管理チームの複数のメンバーが利用できる既知の安全な場所にあり、電話などの従業員が提供するデバイスには接続されません。このアプローチは、緊急アクセスアカウント管理を統合するために一般的に使用されます。ほとんどの組織では、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 のスマートカードを使用できます。資格情報は、セキュリティで保護された、別の場所にある安全で防火性の高い安全な場所に格納する必要があります。

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

前提条件

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

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

Microsoft Entra 管理センターにユーザー管理者以上でサインインしてください。
[ID]>[ユーザー]>[すべてのユーザー] の順に移動します。
緊急アクセス用アカウントを検索し、ユーザーの名前を選択します。
後で使用できるように、オブジェクト ID 属性をコピーして保存します。
2 番目の緊急アクセスアカウントに対して前の手順を繰り返します。

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

Azure portal に監視共同作成者以上でサインインしてください。
[監視]>[Log Analytics ワークスペース] の順に参照してください。
ワークスペースを選択します。
ワークスペースで、 [アラート]>[新しいアラートルール] を選択します。
1. [リソース] で、サブスクリプションがアラートルールを関連付けようとしているものであることを確認します。
2. [条件] で、 [追加] を選択します。
3. [シグナル名] で [Custom log search](カスタムログ検索) を選択します。
4. 検索クエリで、次のクエリを入力し、2 つの緊急アクセスアカウントのオブジェクト ID を挿入します。
  
  Note
  
  追加する緊急アクセスアカウントごとに、クエリに別の or UserId == "ObjectGuid" を追加します。
  
  サンプルクエリ:
```
// 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. 完了を選択します。これで、このアラートの月額推定コストを確認できるようになります。
アラートによって通知されるユーザーのアクショングループを選択します。作成する場合は、「アクショングループを作成する」を参照してください。
アクショングループのメンバーに送信されるメール通知をカスタマイズするには、 [アクションをカスタマイズする] でアクションを選択します。
[アラートの詳細] で、アラートルールの名前を指定し、必要に応じて説明を追加します。
イベントの [重大度レベル] を選択します。 [重大 (重大度 0)] に設定することをお勧めします。
[ルールの作成時に有効にする] は、 [はい] のままにします。
しばらくアラートをオフにするには、 [アラートを表示しない] チェックボックスをオンにし、アラートが再び通知されるようになるまでの待機時間を入力して、 [保存] を選択します。
「アラートルールを作成」を選択します。

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

[アクショングループの作成] を選択します。
アクショングループの名前と短い名前を入力します。
サブスクリプションとリソースグループを確認します。
アクションの種類で、 [Email/SMS/Push/Voice](電子メール/SMS/プッシュ/音声) を選択します。
グローバル管理者に通知するなどのアクション名を入力します。
[アクションの種類] として [Email/SMS/Push/Voice](電子メール/SMS/プッシュ/音声) を選択します。
[詳細の編集] を選択し、構成する通知方法を選択して必要な連絡先情報を入力した後、 [OK] を選択して詳細を保存します。
トリガーするその他のアクションを追加します。
[OK] を選択します。

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

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

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

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

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

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

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

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

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

次のステップ