Azure AD で緊急アクセス用管理者アカウントを管理する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フェデレーション ガイド

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

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

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

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

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

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

前提条件

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

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

  1. ユーザー管理者ロールに割り当てられているアカウントを使用して、Azure portal または Azure AD 管理センターにサインインします。

  2. [Azure Active Directory] > [ユーザー] を選択します。

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

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

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

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

  1. Azure Monitor で監視共同作成者ロールに割り当てられているアカウントを使用して、Azure portal にサインインします。
  2. [すべてのサービス] を選択し、[検索] に「log analytics」と入力して、 [Log Analytics ワークスペース] を選択します。
  3. ワークスペースを選択します。
  4. ワークスペースで、 [アラート] > [新しいアラート ルール] を選択します。
    1. [リソース] で、サブスクリプションがアラート ルールを関連付けようとしているものであることを確認します。

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

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

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

      注意

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

      緊急用アカウントのオブジェクト ID をアラート ルールに追加する

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

      • ベース: 結果の数
      • 演算子:より大きい
      • しきい値: 0
    6. [評価基準] で、クエリの実行時間として [期間 (分単位)] を選択し、クエリを実行する頻度として [頻度 (分単位)] を選択します。 頻度は期間以下でなければなりません。

      アラート ロジック

    7. [Done] を選択します。 これで、このアラートの月額推定コストが表示されるようになります。

  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] を選択します。

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

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

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

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

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

次のステップ