次の方法で共有

最低限の特権の管理モデルを実装する

  • [アーティクル]

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012

次は、1999年4月1日に発行された「管理者アカウント セキュリティ計画ガイド」からの抜粋です。

「ほとんどのセキュリティ関連のトレーニング コースや文書では、最小特権の原則の実装について説明されていますが、組織がそれに追随することは稀です。 原則はシンプルで、それを正しく適用することで、セキュリティを大幅に向上させ、リスクを減らすことができます。 この原則では、すべてのユーザーは、現在のタスクを完了するために必要な最低限のアクセス許可を持つユーザーアカウントでログオンし、それ以上のアクセス許可を持たないようにします。 これにより、特に悪質なコードに対する防御を実現できます。 この原則は、コンピュータとそのユーザーに適用されます。 「この原則が非常にうまく機能する理由の 1 つは、内部調査を強制的に行うためです。 たとえば、コンピューターやユーザーが本当に必要としているアクセス権を決定し、それを実装する必要があります。 多くの組織にとって、この作業は最初は大変な作業に思えるかもしれませんが、ネットワーク環境のセキュリティを成功させるためには、必要不可欠な手順です。 「すべてのドメインAdministratorユーザーに、最小権限の概念に基づいてドメイン権限を付与する必要があります。 例えば、管理者が特権アカウントでログオンし、誤ってウイルス プログラムを実行した場合、そのウイルスはローカル コンピューターとドメイン全体への管理者権を持つことになります。 仮に、管理者が非特権（非管理者）アカウントでログオンしていた場合、ウイルスはローカル コンピューターのユーザーとして動作するため、被害範囲はローカル コンピューターのみとなります。 「別の例では、ドメイン レベルの管理者権限を付与したアカウントは、フォレスト間に信頼関係があったとしても、別のフォレストで昇格権限を持ってはいけません。 この方法は、攻撃者が 1 つの管理されたフォレストを侵害することに成功した場合、広範囲にわたる被害を防ぐのに役立ちます。 組織は、権限の不正な昇格を回避するために、定期的にネットワークを監査する必要があります。」

次に示すのは、2005 年に最初に公開されたMicrosoft Windows セキュリティ リソース キットからの抜粋です。

「タスクを実行するために必要最小限の特権を付与するという点で、セキュリティを常に考慮してください。 権限が多すぎるアプリケーションが危険にさらされた場合、攻撃者は、そのアプリケーションが最小限の権限しか持っていなかった場合よりも攻撃を拡大できる可能性があります。 たとえば、ウイルスを起動させるメール添付ファイルをネットワーク管理者が意図せず開いた場合の影響について説明します。 管理者がドメイン管理者アカウントを使用してログ オンしている場合、ウイルスはドメイン内のすべてのコンピューターに対する管理者特権を持つことになり、ネットワーク上のほぼすべてのデータに無制限にアクセスできることになります。 管理者がローカルの管理者アカウントを使用してログオンしている場合、ウイルスはローカル コンピューターの管理者特権を持つため、コンピューター上のすべてのデータにアクセスし、キー ストローク ログ ソフトウェアなどの悪意のあるソフトウェアをコンピューターにインストールしてしまう可能性があります。 管理者が通常のユーザーアカウントでログオンしているなら、ウイルスは管理者のデータにしかアクセスできず、悪意のあるソフトウェアをインストールすることはありません。 この例のように、メールの読み取りに必要な最小限の権限を使用することで、セキュリティ侵害の可能性が大幅に低減されます。」

特権の問題

前述の抜粋で説明した原則は変更されていませんが、Active Directory のインストールを評価する場合、日常の業務を実行するために必要な数をはるかに超える権限とアクセス許可が付与されアカウントの数が常に過剰になっています。 環境の規模は、過度に特権的なアカウントの数に影響しますが、その割合には影響しません。中規模のディレクトリでは、最も高い特権を持つグループに数十のアカウントがあるかもしれませんが、大規模なインストールでは、数百または数千のアカウントがあるかもしれません。 一部の例外を除き、攻撃者のスキルや武器の高度化に関わらず、攻撃者は通常、抵抗が最も少ない経路をたどります。 攻撃者らがツールやアプローチを複雑化するのは、より単純なメカニズムが失敗したり、ディフェンダーに阻まれたりした場合に限られます。

残念ながら、多くのシステム環境で最も耐性の低いパスは、広範で深い権限を持つアカウントを過剰に使用していることであることが判明しています。 広範な権限とは、環境内の広範囲にわたる特定のアクティビティを行うアカウントを許可する権限です。たとえば、ヘルプ デスクのスタッフには、多くのユーザーアカウントのパスワードをリセットできるアクセス許可が付与される場合があります。

深い権限とは、サーバー上でエンジニアに管理者権限を付与して修復を実行できるようにするなど、一部のユーザーに適用される強力な権限です。 広範な権限も重要な権限も必ずしも危険ではありませんが、ドメイン内の多くのアカウントに広範で重要な権限が常に付与されている場合、アカウントの 1 つが侵害されるだけで、攻撃者の目的に合わせて環境を再構成したり、インフラストラクチャの大部分を破壊したりできるようになります。

資格情報を盗む攻撃の一種であるパスザハッシュ攻撃は、実行するためのツールが自由に入手できて使いやすく、また多くの環境がこの攻撃に対して脆弱であるため、ユビキタスに存在しています。 しかし、パスザハッシュ攻撃は本質的な問題ではありません。 この問題の本質は 2 つあります。

  1. 通常、攻撃者が 1 台のコンピュータで深い権限を取得し、その権限を他のコンピュータに広く伝播させることは容易です。
  2. 高位の特権を持つ永続的なアカウントが、コンピューティングの世界全体で多すぎるのです。

パスザハッシュ攻撃がなくなったとしても、攻撃者は別の戦術を使うだけで、別の戦略を使うわけではありません。 資格情報を盗むためのツールを搭載したマルウェアを仕掛けるのではなく、キー操作をログに記録するマルウェアを仕掛けるなど、環境全体で強力に資格情報を取得するための様々なアプローチを取ることができます。 どのような方法であっても、ターゲットは同じで、広く深い権限を持つアカウントです。

過剰な権限の付与は、侵害された環境のActive Directory だけに見られるわけではありません。 組織が必要以上の権限を付与する習慣を身につけた場合、通常は次のセクションで説明するように、インフラストラクチャ全体でその権限が検出されます。

Active Directory の場合

Active Directory では、EA、DA、および BA グループに過剰な数のアカウントが含まれていることがよくあります。 ほとんどの場合、組織の EA グループにはメンバーが最も少なく、DA グループには EA グループ内のユーザー数の乗数が含まれ、管理者グループには通常、他のグループのメンバー数を合計した数より多くのメンバーが含まれます。 これは、管理者が DA や EA に比べて何らかの形で「特権がない」と思われていることが原因です。 これらのグループに付与される権利と許可はそれぞれ異なりますが、一方のメンバーが他方のメンバーになることができるため、実質的には同等に強力なグループと見なされます。

メンバー サーバーの場合

多くの環境でメンバー サーバーのローカル管理者グループのメンバーシップを取得すると、少数のローカル アカウントとドメイン アカウントから、展開すると数百、さらには数千のサーバーに対するローカル特権を持つアカウントを表示する多数の入れ子になったグループまでのメンバーシップが見つかります。 多くの場合、大規模なメンバーシップを持つドメイングループは、メンバーサーバーのローカルの管理者グループにネストされます。ただし、ドメイン内のこれらのグループのメンバーシップを変更できるユーザーは、グループがローカルの管理者グループにネストされているすべてのシステムの管理コントロールを管理制御を取得可能であるという事実は考慮されません。

ワークステーション上

ワークステーションでは、ローカルの管理者グループに所属するメンバーの数は、メンバーサーバーに比べてかなり少ないのが一般的ですが、多くの環境では、ユーザーはパーソナル コンピューターのローカル管理者グループのメンバーシップを与えられています。 これが発生すると、UAC が有効になっていても、これらのユーザーはワークステーションの整合性に対するリスクが高くなります。

重要

ユーザーが自分のワークステーションで管理者権限を必要とするかどうかを慎重に検討する必要があります。必要な場合は、管理者グループのメンバーであるコンピューターに別のローカルアカウントを作成することをお勧めします。 ユーザーが昇格を必要とする場合、そのローカル アカウントの資格情報を昇格のために提示できますが、アカウントはローカルであるため、他のコンピューターへの侵入やドメイン リソースへのアクセスに使用することはできません。 しかし、他のローカルアカウントと同様に、ローカル特権アカウントの資格情報は固有のものでなければなりません。複数のワークステーションで同じ資格情報を持つローカルアカウントを作成すると、コンピュータがパスザハッシュ攻撃にさらされてしまいます。

アプリケーションの場合

攻撃のターゲットが組織の知的財産である場合、アプリケーション内で強力な権限を付与されているアカウントをターゲットにして、データ漏洩を可能にする可能性があります。 機密データにアクセスできるアカウントには、ドメインまたはオペレーティング システムでの管理者権限が付与されていない場合がありますが、アプリケーションの構成を操作したり、アプリケーションが提供する情報にアクセスしたりできるアカウントにはリスクがあります。

データ リポジトリの場合

他のターゲットと同様に、ドキュメントやその他のファイル形式で知的財産にアクセスしようとする攻撃者は、ファイルストアへのアクセスを制御するアカウント、ファイルに直接アクセスするアカウント、さらにはファイルにアクセスするグループやロールをターゲットにする可能性があります。 たとえば、契約書類の保存にファイル サーバーが使用されており、Active Directory のグループを使用して契約書類へのアクセスが許可されている場合、グループのメンバーシップを変更できる攻撃者は、危険なアカウントをグループに追加して契約書類にアクセスすることができます。 ドキュメントへのアクセスが SharePoint などのアプリケーションで提供されている場合、攻撃者は前述のようにアプリケーションをターゲットとすることができます。

特権の削減

環境が大きく、複雑になればなるほど、管理やセキュリティが難しくなります。 小規模な組織では、権限を見直して削減することは比較的簡単なことかもしれませんが、組織内で使用されるサーバー、ワークステーション、ユーザアカウント、アプリケーションが増えるたびに、セキュリティを確保しなければならない対象が増えていきます。 組織の IT インフラストラクチャのすべての側面を適切に保護することは困難または不可能である可能性があるため、まず、特権が最大のリスクをもたらすアカウント (通常は Active Directory に組み込まれている特権アカウントとグループ、およびワークステーションとメンバーサーバー上の特権ローカルアカウント) に重点を置く必要があります。

ワークステーションとメンバーサーバーのローカル管理者アカウントの保護

このドキュメントでは、Active Directory の保護に焦点を当てていますが、これまでに説明してきたように、Directory に対する攻撃のほとんどは、個々のホストに対する攻撃として始まります。 メンバーシステム上のローカルグループを保護するための完全なガイドラインを提供することはできませんが、ワークステーションおよびメンバー サーバー上のローカル管理者アカウントを保護するために、次の推奨事項を紹介します。

ローカル管理者アカウントの保護

現在メインストリーム サポートが提供されているすべてのバージョンの Windows では、ローカルの管理者アカウントが既定で無効になっているため、パスハッシュ攻撃やその他の資格情報の盗難にアカウントは使用できません。 ただし、レガシー オペレーティング システムを含むドメインや、ローカル管理者アカウントが有効になっているドメインでは、前述のようにこれらのアカウントを使用して、メンバーサーバーとワークステーション間で侵害を伝播できます。 このため、ドメインに参加しているシステムのすべてのローカル管理者アカウントに対して、次の制御を行うことをお勧めします。

これらのコントロールを実装するための詳細な手順については、「付録 H: ローカル管理者アカウントとグループをセキュリティで保護する」を参照してください。 ただし、これらの設定を実装する前に、ローカル管理者アカウントが環境内で現在使用されていないことを確認して、コンピューターでサービスを実行するか、これらのアカウントを使用してはならないその他の操作を実行してください。 この設定を本番環境に実装する前に、十分にテストしてください。

ローカル管理者アカウントのコントロール

組み込みの管理者アカウントは、メンバー サーバーのサービス アカウントとして使用したり、ローカル コンピュータへのログオンに使用したりしないでください (ただし、アカウントが無効になっている場合でも許可されるセーフモードを除きます)。 ここで説明した設定を実施する目的は、保護コントロールを元に戻さない限り、各コンピュータのローカル管理者アカウントが使用できないようにすることです。 これらのコントロールを実施し、管理者アカウントの変更を監視することで、ローカルの管理者アカウントを標的とした攻撃が成功する可能性を大幅に減らすことができます。

ドメインに参加しているシステムの管理者アカウントを制限するようにGPOを構成する

1つまたは複数のGPOを作成し、各ドメイン内のワークステーションおよびメンバーサーバーOUにリンクする場合は、Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignmentsの次のユーザー権限に管理者アカウントを追加します。

  • ネットワークからこのコンピューターへのアクセスを拒否
  • バッチ ジョブとしてのログオン権限を拒否する
  • サービスとしてのログオン権限を拒否する
  • リモート デスクトップ サービスを使ったログオンを拒否

これらのユーザー権限に管理者アカウントを追加する場合は、アカウントにラベルを追加する方法で、ローカル管理者アカウントとドメインの管理者アカウントのどちらを追加するかを指定します。 たとえば、これらの拒否権限に NWTRADERS ドメインの Administrator アカウントを追加するには、アカウントを NWTRADERS\Administratorとして入力するか、NWTRADERS ドメインの Administrator アカウントを参照します。 ローカルの 管理者アカウントを制限するには、グループ ポリシー オブジェクト エディターのこれらのユーザー権限設定に「管理者」と入力します。

注意

ローカル管理者アカウントの名前を変更しても、ポリシーは適用されます。

これらの設定により、コンピューターの管理者アカウントが誤って、または悪意を持って有効になっていたとしても、他のコンピューターへの接続に使用できないようになります。 ローカル管理者アカウントを使用したローカル ログオンは、完全には利用不可にすることはできません。また、そのようにしようとしてもいけません。コンピュータのローカル管理者アカウントは、ディザスター リカバリーのシナリオで使用するように設計されているためです。

他のローカル アカウントに管理者特権が付与されていないメンバー サーバーまたはワークステーションがドメインから切断された場合、コンピューターをセーフ モードで起動し、Administrator アカウントを有効にし、その後、アカウントを使用してコンピューターを修復できます。 修復が完了したら、管理者アカウントを無効にしてください。

Active Directory でのローカル特権アカウントとグループの保護

第6条、コンピュータは管理者が信頼できる程度のセキュリティしかありません。 - セキュリティに関する 10 の不変の法則 (バージョン 2.0) (英語)

ここで提供されている情報は、Active Directory で上位の特権を持つ組み込みアカウントおよびグループを保護するための一般的なガイドラインを提供することを目的としています。 詳細な手順は、付録D: Active Directory の組み込み管理者アカウントの保護、付録E: Active Directory のエンタープライズ管理者グループの保護、付録F: ActiveDirectory のドメイン管理者グループの保護、および付録G:Active Directory の管理者グループの保護にも記載されています。

これらの設定を実装する前に、すべての設定を徹底的にテストして、環境に適しているかどうかを判断する必要もあります。 すべての組織がこれらの設定を実行できるわけではありません。

Active Directory の組み込み管理者アカウントを保護する

Active Directory の各ドメインでは、ドメインの作成の一環として管理者アカウントが作成されます。 このアカウントは、既定ではドメイン内の Domain Admins グループおよび管理者グループのメンバーであり、ドメインがフォレスト ルート ドメインの場合は、Enterprise Admins グループのメンバーでもあります。 ドメインのローカル管理者アカウントの使用は、初期ビルド アクティビティ、および場合によってはディザスター リカバリーのシナリオにのみ使用するようにしてください。 組み込みの Administrator アカウントを使用して、他のアカウントを使用できない場合に、修復に影響を与えることができるようにするには、フォレスト内のどのドメインでも、Administrator アカウントの既定のメンバーシップを変更しないようにする必要があります。 この場合は、フォレスト内の各ドメインの管理者アカウントを保護するためのガイドラインに従ってください。 これらのコントロールを実装するための詳細な手順については、「付録 D: Active Directory で組み込み管理者アカウントをセキュリティで保護する」を参照してください。

組み込みの管理者アカウントのコントロール

ここで説明する設定を実装する目的は、複数のコントロールが無効になっていない限り、各ドメインの (グループではなく) 管理者アカウントを使用できないようにすることです。 これらのコントロールを実装し、管理者アカウントの変更を監視することによりドメインの管理者アカウントを利用した攻撃が成功する可能性を大幅に減らすことができます。 フォレスト内の各ドメインの管理者アカウントについては、次の設定を構成する必要があります。

アカウントの「アカウントは機密性があり、委任できません」フラグを有効にします

既定では、Active Directory 内のすべてのアカウントを委任できます。 委任を使用すると、コンピューターまたはサービスは、そのコンピューターに対して認証されたアカウントの資格情報を他のコンピューターに提示し、アカウントに代わってサービスを取得できます。 ドメインベースのアカウントでアカウントが機密性が高く、属性を委任できない場合、アカウントの資格情報をネットワーク上の他のコンピューターまたはサービスに提示できないため、委任を利用して他のシステムでアカウントの資格情報を使用する攻撃が制限されます。

アカウントで「対話型ログオンにはスマートカードが必要です」フラグを有効にします

アカウントの対話型ログオン属性にスマートカードが必要な場合は、Windows によって、アカウントのパスワードが 120 文字のランダム値でリセットできます。 組み込みの管理者アカウントにこのフラグを設定すると、アカウントのパスワードが長く複雑になるだけでなく、どのユーザーにも知られないようになります。 技術的には、この属性を有効にする前にアカウント用のスマートカードを作成する必要はありませんが、可能であれば、アカウントの制限を構成する前に各管理者アカウント用にスマートカードを作成し、スマートカードを安全な場所に保管しておく必要があります。

対話型ログオンフラグにスマートカードを設定すると、アカウントのパスワードがリセットされますが、アカウントのパスワードをリセットする権限を持つユーザーがアカウントを既知の値に設定し、アカウントの名前と新しいパスワードを使用してネットワーク上のリソースにアクセスすることはできます。 このため、次の追加のコントロールをアカウントに実装する必要があります。

ドメインに参加しているシステムのドメインの管理者アカウントを制限するように GPO を構成する

ドメイン内の管理者アカウントを無効にすると、アカウントは事実上使用できなくなりますが、アカウントが誤ってまたは悪意によって有効化された場合に備えて、アカウントに追加の制限を設定する必要があります。 これらの制御は最終的には管理者アカウントによって無効にできますが、目標は、攻撃者の進行を遅らせ、アカウントが被る可能性のある損害を最小限に抑える制御を作成することです。

1 つまたは複数の GPO を作成し、各ドメイン内のワークステーションおよびメンバーサーバー OU にリンクする場合は、Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignmentsで、各ドメインの管理者アカウントを次のユーザー権利に追加します。

  • ネットワークからこのコンピューターへのアクセスを拒否
  • バッチ ジョブとしてのログオン権限を拒否する
  • サービスとしてのログオン権限を拒否する
  • リモート デスクトップ サービスを使ったログオンを拒否

注意

この設定にローカル管理者アカウントを追加する場合は、ローカル管理者アカウントとドメイン管理者アカウントのどちらを設定するかを指定する必要があります。 たとえば、これらの拒否権限に NWTRADERS ドメインの ローカル Administrator アカウントを追加するには、アカウントを NWTRADERS\Administrator として入力するか、NWTRADERS ドメインのローカル Administrator アカウントを参照しなければなりません。 グループ ポリシー オブジェクト エディターのこれらのユーザー権限設定で Administrator と入力すると、GPO が適用される各コンピューターのローカル Administrator アカウントが制限されます。

ドメインベースの管理者アカウントと同様に、メンバーサーバーやワークステーションのローカル管理者アカウントを制限することをお勧めします。 したがって、一般的には、フォレスト内の各ドメインの管理者アカウントと、ローカル コンピューターの管理者アカウントをこれらのユーザー権限設定に追加する必要があります。

ドメイン コントローラーの管理者アカウントを制限するように GPO を構成

フォレスト内の各ドメインで、既定のドメイン コントローラー ポリシーまたはドメイン コントローラー OU にリンクされているポリシーを変更して、Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments の次のユーザー権限に各ドメインの Administrator アカウントを追加する必要があります：

  • ネットワークからこのコンピューターへのアクセスを拒否
  • バッチ ジョブとしてのログオン権限を拒否する
  • サービスとしてのログオン権限を拒否する
  • リモート デスクトップ サービスを使ったログオンを拒否

注意

これらの設定により、ローカル管理者アカウントを使用してドメイン コントローラーに接続することはできませんが、アカウントが有効になっている場合は、ローカルでドメイン コントローラーにログオンできます。 このアカウントは、ディザスター リカバリーのシナリオでのみ有効にして使用する必要があるため、少なくとも1つのドメイン コントローラーへの物理的なアクセスが可能であるか、ドメイン コントローラーへのリモートアクセス権限を持つ他のアカウントを使用できることが前提となっています。

組み込み管理者アカウントの監査を構成

各ドメインの管理者アカウント アカウントをセキュリティで保護し、無効にした場合は、アカウントの変更を監視するように監査を構成する必要があります。 アカウントが有効になっている場合、パスワードがリセットされた場合、またはアカウントにその他の変更が加えられた場合は、組織内のインシデント対応チームに加えて、AD DS の管理を担当するユーザーまたはチームに警告を送信する必要があります。

管理者、ドメイン管理者、エンタープライズ管理者グループの保護

エンタープライズ管理者グループの保護

フォレスト ルート ドメインに格納されている Enterprise Admins グループは、「付録 D: Active Directory での Built-In Administrator アカウントのセキュリティ保護」で説明されているように、セキュリティで保護されている場合に、ドメインのローカル Administrator アカウントを除き、日常的にユーザーを含めることはできません。

EA へのアクセスが必要な場合、EA の権利や権限が必要なアカウントを持つユーザーを一時的にエンタープライズ管理者グループに入れておく必要があります。 ユーザーは高位の特権を持つアカウントを使用していますが、その活動は監査されるべきであり、不注意による誤用や誤設定の可能性を最小限に抑えるために、1人のユーザーが変更を実行し、別のユーザーが変更を監視することが望ましいです。 活動が完了したら、アカウントを EA グループから削除してください。 これは、手動の手順とドキュメント化されたプロセス、サードパーティのPrivileged Identity Management/特権アクセス管理 (PIM/PAM) ソフトウェア、またはその両方の組み合わせを使用して実現できます。 Active Directory の特権グループのメンバーシップの制御に使用できるアカウントを作成するためのガイドラインは、資格情報の盗難に魅力的なアカウント で提供されています。詳細な手順については、「付録 I: Active Directory で保護されたアカウントとグループの管理アカウントを作成する」を参照してください。

エンタープライズ管理者は、既定では、フォレスト内の各ドメインの組み込みの管理者グループのメンバーになります。 各ドメインの管理者グループからエンタープライズ管理者グループを削除すると、フォレストのディザスター リカバリー シナリオの場合に EA 権限が必要になる可能性があるため、不適切な変更となります。 エンタープライズ管理グループがフォレスト内の管理者グループから削除された場合は、各ドメインの管理者グループに追加して、次の追加コントロールを実装する必要があります。

  • 前に説明したように、Enterprise Admins グループには、「付録 D: Active Directory の組み込み管理者アカウントをセキュリティで保護する」で説明したように、保護する必要があるフォレスト ルート ドメインの Administrator アカウントを除いて、日常的なユーザーを含めないでください。
  • 各ドメインのメンバー サーバーとワークステーションを含む OU にリンクされた GPO では、EA グループを次のユーザー権限に追加する必要があります。
    • ネットワークからこのコンピューターへのアクセスを拒否
    • バッチ ジョブとしてのログオン権限を拒否する
    • サービスとしてのログオン権限を拒否する
    • ローカルでのログオンを拒否する
    • リモート デスクトップ サービスでのログオンを拒否する。

これにより、EA グループのメンバーがメンバー サーバーおよびワークステーションにログオンできなくなります。 ジャンプ サーバーを使用してドメイン コントローラーとActive Directory を管理する場合は、制限された GPO がリンクされていない OU にジャンプ サーバーが配置されていることを確認します。

  • EA グループのプロパティやメンバーシップに変更が加えられた場合、アラートが送信されるように監査を設定する必要があります。 これらのアラートは、少なくとも、Active Directory 管理とインシデント対応を担当するユーザーまたはチームに送信する必要があります。 また、一時的に EA グループを作成するためのプロセスと手順を定義する必要があります。これには、グループの正当な作成が行われる際の通知手順も含まれます。

ドメイン管理者グループの保護

エンタープライズ管理グループと同様に、ドメイン管理グループのメンバーシップは、構築またはディザスター リカバリーのシナリオでのみ必要です。 「付録D:Active Directory の組み込み管理者アカウントの保護」で説明されているように保護されている場合は、ドメインのローカル管理者アカウントを除き、DAグループに日常のユーザーアカウントは設定しないでください。

DA へのアクセスが必要な場合、このレベルのアクセスを必要とするアカウントは、対象のドメインの DA グループに一時的に配置される必要があります。 ユーザーは高度な権限を持つアカウントを使用していますが、アクティビティを監査し、1人のユーザーが変更を実行し、別のユーザーが変更を監視して、不注意な誤用や構成の誤りを最小限に抑える必要があります。 活動が完了したら、アカウントをドメイン管理者グループから削除する必要があります。 これは、手動の手順とドキュメント化されたプロセス、サードパーティの特権 ID/アクセス管理 (PIM/PAM) ソフトウェア、またはその両方の組み合わせによって実現できます。 Active Directory の特権グループのメンバーシップの制御に使用できるアカウントを作成するためのガイドラインは、「付録 I: Active Directory で保護されたアカウントとグループの管理アカウントを作成する」で提供されます。

ドメイン管理者は、既定では、それぞれのドメイン内のすべてのメンバーサーバーおよびワークステーションのローカル管理者グループのメンバーとなります。 この既定のネストは、サポート性とディザスター リカバリーのオプションに影響するため、変更しないでください。 ドメイン管理者グループがメンバサーバー上のローカルの管理者グループから削除された場合は、リンクされたGPOの制限されたグループ設定を使用して、ドメイン内の各メンバ サーバーおよびワークステーションの管理者グループに追加する必要があります。 「付録 F: Active Directory の Domain Admins グループをセキュリティで保護する」で詳しく説明されている次の一般的なコントロールも実施する必要があります。

フォレスト内の各ドメインのドメイン 管理者グループの場合:

  1. 「付録 D: Active Directory の組み込み管理者アカウントをセキュリティで保護する」の説明に従って保護されている場合は、ドメインの組み込み管理者アカウントを除き、DA グループからすべてのメンバーを削除します。

  2. 各ドメインのメンバー サーバーとワークステーションを含む OU にリンクされた GPO では、DA グループを次のユーザー権限に追加する必要があります。

    • ネットワークからこのコンピューターへのアクセスを拒否
    • バッチ ジョブとしてのログオン権限を拒否する
    • サービスとしてのログオン権限を拒否する
    • ローカルでのログオンを拒否する
    • リモート デスクトップ サービスを使ったログオンを拒否

    これにより、DA グループのメンバーがメンバー サーバーおよびワークステーションにログオンできなくなります。 ジャンプ サーバーを使用してドメイン コントローラーとActive Directory を管理する場合は、制限された GPO がリンクされていない OU にジャンプ サーバーが配置されていることを確認します。

  3. DA グループのプロパティまたはメンバーシップが変更された場合にアラートを送信するように、監査を構成する必要があります。 これらの警告は、少なくとも、AD DS の管理とインシデント対応を担当するユーザーまたはチームに送信する必要があります。 また、グループの正当な取り込みが実行されたときの通知手順など、DA グループを一時的に取り込むためのプロセスと手順も定義する必要があります。

Active Directory の Administrators グループをセキュリティで保護する

EA グループおよび DA グループと同様に、管理者 (BA) グループのメンバーシップは、構築またはディザスター リカバリーのシナリオでのみ必要です。 ドメインのローカル管理者アカウントが「付録 D: Active Directory の組み込み管理者アカウントをセキュリティで保護する」で説明されているように保護されている場合は、ドメインのローカル管理者アカウントを除いて、管理者グループに日常のユーザーアカウントは存在しないはずです。

管理者アクセスが必要な場合、このレベルのアクセスを必要とするアカウントは、問題のドメインの管理者グループに一時的に配置する必要があります。 ユーザーは高い権限を持つアカウントを使用していますが、アクティビティは監査される必要があり、望ましくは、変更を実行するユーザーと変更を監視する別のユーザーと一緒に実行して、不注意な誤用や構成の誤りの可能性を最小限に抑える必要があります。 アクティビティが完了すると、アカウントはただちに管理者グループから削除されます。 これは、手動の手順とドキュメント化されたプロセス、サードパーティの特権 ID/アクセス管理 (PIM/PAM) ソフトウェア、またはその両方の組み合わせによって実現できます。

既定では、管理者はそれぞれのドメイン内のほとんどの AD DS オブジェクトの所有者です。 このグループのメンバーシップは、オブジェクトの所有権または所有権を取得する機能が必要な構築およびディザスター リカバリーのシナリオで必要になる場合があります。 さらに、DA と EA は、管理者グループの既定のメンバーシップによって、多くの権利とアクセス許可を継承します。 Active Directory の特権グループの既定のグループの入れ子を変更することはできません。また、「付録 G: Active Directory で管理者グループをセキュリティで保護する」および以下の一般的な手順に従って、各ドメインの管理者グループをセキュリティで保護する必要があります。

  1. 「付録 D: Active Directory の組み込み管理者アカウントをセキュリティで保護する」で説明されているようにセキュリティで保護されている場合は、ドメインのローカル Administrator アカウントを除き、Administrators グループからすべてのメンバーを削除します。

  2. ドメインの管理者グループのメンバは、メンバー サーバーまたはワークステーションにログオンする必要はありません。 各ドメインのワークステーションとメンバー サーバー OU にリンクされている1つ以上の GPO で、管理者グループを次のユーザー権利に追加する必要があります。

    • ネットワークからこのコンピューターへのアクセスを拒否
    • バッチ ジョブとしてのログオンを拒否します。
    • サービスとしてのログオン権限を拒否する
    • これにより、管理者グループのメンバーは、 (複数のコントロールが最初に違反しない限り) メンバーサーバーまたはワークステーションにログオンまたは接続するために使用されず、資格情報がキャッシュされて危険にさらされる可能性があります。 特権アカウントを使用して特権の下位のシステムにログオンしないでください。これらのコントロールを適用するとで、多くの攻撃から保護できます。

  3. フォレスト内の各ドメインのドメイン コントローラー OU には、管理者グループに次のユーザー権利が付与されている必要があります (まだこれらの権利を持っていない場合)。これにより、管理者グループのメンバーは、フォレスト全体のディザスター リカバリー シナリオに必要な機能が実行できるようになります。

    • ネットワークからこのコンピューターにアクセスする
    • ローカル ログオンを許可
    • リモート デスクトップ サービスを使ったログオンを許可

  4. 管理者グループのプロパティまたはメンバシップが変更された場合に警告を送信するように、監査を構成する必要があります。 これらの警告は、少なくともAD DSの管理を担当するチームのメンバーに送信する必要があります。 また、セキュリティ チームのメンバーにアラートを送信する必要があります。また、Administrators グループのメンバーシップを変更するための手順を定義する必要があります。 具体的には、これらのプロセスには、Administrators グループが変更されたときに、セキュリティ チームに通知する手順が含まれている必要があります。これにより、アラートが送信されたときにアラートが予期されて、アラームが生成しなくなります。 さらに、管理者グループの使用が完了し、使用されているアカウントがグループから削除されたときにセキュリティ チームに通知するプロセスを実装する必要があります。

注意

GPO の管理者グループに制限を実装すると、Windows は、ドメインの管理者グループに加えて、コンピューターのローカルの管理者グループのメンバーにも設定を適用します。 そのため、管理者グループに制限を適用する場合には注意が必要です。 管理者グループのメンバーのネットワーク、バッチ、およびサービスへのログオンは、実装可能な限り禁止することをお勧めしますが、リモート デスクトップ サービスを経由したローカル ログオンやログオンは制限しないでください。 これらのログオンの種類をブロックすると、ローカルの管理者グループのメンバーによるコンピューターの正当な管理がブロックされる恐れがあります。 次のスクリーンショットは、組み込みのローカルまたはドメイン管理者グループの不正使用に加えて、組み込みのローカルおよびドメイン管理者アカウントの不正使用をブロックする構成設定を示すものです。 リモート デスクトップ サービスによるログオンを拒否するユーザー権利には、管理者グループは含まれていません。この設定に含めると、ローカル コンピューターの管理者グループのメンバーであるアカウントに対するこれらのログオンもブロックされるためです。 コンピュータ上のサービスが、このセクションで説明されている特権グループのいずれかのコンテキストで実行されるように構成されている場合、これらの設定を実装すると、サービスおよびアプリケーションがエラーになる可能性があります。 そのため、このセクションで説明するすべての推奨事項と同様に、使用の環境での設定の適用性を徹底的にテストする必要があります。

least privilege admin models

Active Directory ロールベースのアクセス制御 (RBAC)

一般に、ロールベースのアクセス制御 (RBAC) は、ユーザーをグループ化し、ビジネス ルールに基づいてリソースへのアクセスを提供するためのメカニズムです。 Active Directory の場合、AD DS用のRBACの実装は、権限とアクセス許可が委任される役割を作成するプロセスで、その役割のメンバーは、日常の管理タスクに過度の権限を与えずに実行できます。 Active Directory 用のRBACは、すでに所有しているソフトウェアを利用するか、サードパーティ製品を購入するか、またはこれらのアプローチを任意に組み合わせて、ネイティブのツールとインタフェースを使用して設計および実装できます。 このセクションでは、Active Directory にRBACを実装する手順については説明しませんが、AD DSインストールでRBACを実装する方法を選択する際に考慮すべき要素について説明します。

Active Directory のための RBAC へのネイティブ アプローチ

最も単純な RBAC の実装では、役割を AD DS グループとして実装し、指定された役割のスコープ内で日常の管理を実行できるようにする権利とアクセス許可をグループに委任できます。

場合によっては、Active Directory の既存のセキュリティ グループを使用して、ジョブの機能に適した権限とアクセス許可を付与できます。 たとえば、IT 組織内の特定の従業員が DNS ゾーンとレコードの管理と保守を担当している場合、各 DNS 管理者のアカウントを作成し、それをActive Directory のDNS 管理者グループに追加するだけで、その担当を委任できます。 DNS 管理者グループは、より高い権限を持つグループとは異なり、Active Directory 全体での強力な権限をほとんど持っていません。ただし、このグループのメンバーは、DNS の管理を許可するアクセス許可を委任されているため、権限が侵害されたり、権限が乱用されたりする可能性があります。

また、セキュリティグループを作成し、Active Directory オブジェクト、ファイル システム オブジェクト、およびレジストリ オブジェクトに権限とアクセス許可を委任して、グループのメンバーが指定された管理タスクを実行できるようにする必要がある場合もあります。 たとえば、ヘルプ デスクのオペレーターが、失念したパスワードのリセット、接続の問題に関するユーザーの支援、およびアプリケーション設定のトラブルシューティングを担当している場合は、Active Directory のユーザー オブジェクトの委任設定と、ヘルプ デスクのユーザーがユーザーのコンピューターにリモート接続してユーザーの構成設定を表示または変更できる特権を組み合わせる必要があります。 定義する役割ごとに、次の項目を指定する必要があります。

  1. どのタスクが日常的に実行され、どのタスクの実行頻度が低いか。
  2. どのシステムで、どのアプリケーションのどのロール メンバーにアクセス権と権限を付与するか。
  3. どのユーザーにロールのメンバーシップを付与するか。
  4. ロール メンバーシップ管理の実施方法。

多くの環境では、Active Directory 環境を管理するためのロール ベースのアクセス制御を手動で作成することは、実装と管理が複雑になる場合があります。 IT インフラストラクチャの管理の役割と責任を明確に定義している場合は、管理しやすいネイティブ RBAC の展開を支援するために、追加のツールを活用できます。 たとえば、環境内で Forefront Identity Manager (FIM) を使用している場合、FIM を使用して管理者ロールの作成と設定を自動化できるため、継続的な管理がしやすくなります。 Microsoft Endpoint Configuration Manager と System Center Operations Manager (SCOM) を使用する場合は、アプリケーション固有の役割を使用して管理機能と監視機能を委任し、ドメイン内のシステム間で一貫した構成と監査が行われるように設定できます。 公開キー基盤 (PKI) を実装している場合は、環境の管理を担当する IT スタッフに、スマート カードを発行して要求することができます。 FIM Credential Management (FIM CM) を使えば、管理スタッフのロールと資格情報の管理を組み合わせて利用することもできます。

別のケースでは、「すぐに利用できる」機能を提供するサードパーティ製の RBAC ソフトウェアの導入の検討も組織にとって望ましい場合があります。 Active Directory、Windows、およびWindows以外のディレクトリとオペレーティングシステム用の RBAC の市販の既製 (COTS) ソリューションが、多数の企業から提供されています。 ネイティブソリューションとサードパーティ製品を選択する場合は、次の点を考慮する必要があります。

  1. 予算については、既に所有しているソフトウェアとツールを使用して RBAC の開発に投資することで、ソリューションの展開に伴うソフトウェアコストを削減できます。 ただし、ネイティブ RBAC ソリューションの作成と展開の経験があるスタッフがいない場合は、ソリューションを開発するためにコンサルティングリソースの活用が必要になることがあります。 特に予算が限られている場合は、カスタム開発ソリューションの予想コストと、「すぐに利用できる」ソリューションの展開コストを慎重に比較検討する必要があります。
  2. IT 環境の構成には、主に Windows システムで構成されている環境や、Windows 以外のシステムやアカウントの管理に Active Directory をすでに活用している環境では、カスタム ネイティブ ソリューションによってニーズに最適なソリューションを実現できるようになります。 インフラストラクチャに Windows を搭載せず、Active Directory で管理されていないシステムが多数含まれている場合は、Active Directory 環境とは別に、Windows 以外のシステムの管理オプションを検討する必要があります。
  3. ソリューションの特権モデル、製品がそのサービスアカウントをActive Directory内の高い特権グループに配置することに依存しており、RBAC ソフトウェアに過度の特権を付与する必要のないオプションを提供しない場合、Active Directory の攻撃対象を実際に減少させたわけではなく、ディレクトリ内の最も特権の高いグループの構成を変更したにすぎません。 アプリケーション ベンダーからサービス アカウントに対して、アカウントが侵害されたり悪意を持って使用されたりする可能性を最小限に抑えるコントロールが提供されていない限り、他のオプションも検討することをお勧めします。

Privileged Identity Management

Privileged Identity Management (PIM) は、特権アカウント管理 (PAM) またはPrivileged Credential Management (PCM) とも呼ばれ、インフラストラクチャ内の特権アカウントを管理するためのアプローチの設計、構築、および実装のことです。 一般的に、PIM は、アカウントに永続的にアタッチされている権限を残すのではなく、構築または故障修理機能を行うために必要な一時的な権限および権限をアカウントに付与するメカニズムを提供します。 PIM 機能を手動で作成するか、サードパーティ製ソフトウェアの展開によって実装するかにかかわらず、次の機能の少なくとも 1 つは実現できます。

  • 資格情報の「 Vault 」は、特権アカウントのパスワードは「チェックアウト」され、初期パスワードが割り当てられます。アクティビティが完了すると「チェックイン」され、アカウントのパスワードは再びリセットされます。
  • 特権的資格情報の使用に関する期限付きの制限
  • ワンタイム用の資格情報
  • 実行されたアクティビティの監視とレポートと、アクティビティが完了したとき、または割り当て時間が経過したときの特権の自動削除の機能を持つ、ワーク フローによって生成された特権の付与
  • スクリプト内のユーザ名やパスワードなどのハードコードされた資格情報を、必要に応じて Vault から取得できるようにするアプリケーションプログラミングインタフェース (API) に置き換える
  • サービスアカウントの資格情報の自動管理

特権アカウントを管理するための特権のないアカウントの作成

特権アカウントの管理における課題のひとつは、既定では、特権アカウントや保護されたアカウント、グループを管理できるアカウントが特権アカウントや保護されたアカウントであることです。 Active Directory のインストールに適切な RBAC および PIM ソリューションを実装する場合、ソリューションには、ディレクトリ内の最も特権の高いグループのメンバーシップを効果的に削除し、一時的かつ必要なときにのみグループに追加できるアプローチが含まれることがあります。

ただし、ネイティブ RBAC と PIM を実装する場合は、特権を持たず、必要に応じて Active Directory の特権グループを設定および設定解除する唯一の機能を持つアカウントを作成することを検討してください。 付録 I: Active Directory で保護されたアカウントとグループの管理アカウントを作成するでは、この目的でアカウントを作成するための手順を順を追って説明します。

堅牢な認証制御の実装

第6条、パスワードを推測しようとしている人がいます。 - セキュリティ管理に関する 10 の不変の法則

ハッシュパスなどの資格情報窃盗攻撃は、Windows オペレーティングシステムに固有のものではなく、新しいものでもありません。 パスザハッシュ攻撃は1997年に初めて作られました。 しかし、歴史的には、これらの攻撃にはカスタマイズされたツールが必要だったり、成功するかどうかは予測できず、攻撃者には比較的高度なスキルが必要でした。 資格情報をネイティブに抽出する、無料で利用できる、使いやすいツール登場したことで、近年、資格情報を盗む攻撃の数と成功率が飛躍的に増加しています。 しかし、資格情報が標的となり侵害されるメカニズムは、資格情報盗難攻撃だけではありません。

資格情報の盗難攻撃からユーザーを保護するためのコントロールを実装する必要がありますが、攻撃者の標的になる可能性が最も高い環境内のアカウントを特定し、それらのアカウントに対して堅牢な認証コントロールを実装する必要もあります。 最も特権のあるアカウントがユーザー名やパスワードなどの単一要素認証を使用している場合 (どちらも「知っていること」であり、1 つの認証要素です)、これらのアカウントは弱く保護されています。 攻撃に必要なのは、アカウントに関連付けられたユーザー名とパスワードの情報だけです。つまり、ハッシュパス攻撃は必要ありません。攻撃者は、単一要素認証の資格情報を受け入れる任意のシステムに対して、ユーザーとして認証を行うことができます。

多要素認証を実装しても、pass-the-hash 攻撃を防ぐことはできませんが、保護されたシステムと組み合わせて多要素認証を実装することは可能です。 保護されたシステムの実装の詳細については、「安全な管理用のホストを実装する」を参照してください。認証オプションについては、次のセクションで説明します。

一般的な認証コントロール

スマート カードなどの多要素認証をまだ実装していない場合は、実装を検討してください。 スマートカードは、公開キーと秘密キーのペアをハードウェアで強制的に保護し、ユーザーが適切な PIN、パスコード、または生体認証識別子をスマートカードに提示しない限り、アクセスしたり使用したりすることができないようになっています。 攻撃を受けたコンピュータのキーロガーによってユーザーの PIN またはパスコードが盗まれた場合でも、悪意のある攻撃者が PIN またはパスコードを再利用するには、カードが物理的に存在している必要があります。

長い複雑なパスワードをユーザーが抵抗を感じて実装するのが困難な場合、スマートカードは、資格情報がブルートフォースやレインボーテーブル攻撃の被害を受けずに、ユーザーが比較的単純な PIN やパスコードで実装できるメカニズムを提供します。 スマートカードの PIN は、Active Directory やローカルの SAM データベースには保存されませんが、認証にスマートカードが使用されているコンピューター上の LSASS で保護されたメモリには、資格情報のハッシュが保存されている場合があります。

VIP アカウントの追加コントロール

スマートカードまたはその他の証明書ベースの認証メカニズムを実装するもう 1 つの利点は、認証メカニズム保証を利用して、VIP ユーザーがアクセスできる機密データを保護できることです。 認証メカニズムの保証は、機能レベルが Windows Server 2012 または Windows Server 2008 R2 に設定されているドメインで使用できます。 これを有効にすると、認証メカニズム保証は、証明書ベースのログオン方法を使用してログオン時にユーザーの資格情報が認証されるときに、管理者が指定したグローバルグループメンバシップをユーザーの Kerberos トークンに追加します。

これにより、リソース管理者は、ユーザーが使用する証明書の種類に加えて、証明書ベースのログオン方法を使用してログオンするかどうかに基づいて、ファイル、フォルダー、プリンターなどのリソースへのアクセスをコントロールできます。 たとえば、ユーザーがスマートカードを使用してログオンする場合、ネットワーク上のリソースへのユーザーのアクセスを、ユーザーがスマートカードを使用しない場合のアクセスとは異なるアクセスとして指定できます (つまり、ユーザーがユーザー名とパスワードを入力してログオンしたとき)。 認証メカニズムの保証の詳細については、「Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide」を参照してください。

特権アカウント認証の構成

すべての管理者アカウントの Active Directory で、[対話型ログオンにスマート カードが必要] 属性を有効にし、(例:cn、name、sAMAccountName、userPrincipalName、userAccountControl)アカウント管理者ユーザー オブジェクトの [アカウント] タブにある任意の属性に対する変更を (少なくとも) 監査します。

アカウントで [対話型ログオンにスマートカードを必要とする] を設定すると、アカウントのパスワードが 120 文字のランダムな値にリセットされ、対話型ログオンにスマートカードが必要になりますが、アカウントのパスワードを変更する権限を持つユーザーによって属性が上書きされる可能性があります。その後、アカウントを使用して、ユーザー名とパスワードのみで非対話型ログオンを確立できます。

その他の場合は、Active Directory のアカウントの構成および Active Directory 証明書サービス (AD CS) またはサードパーティ PKI の証明書設定に応じて、ここで説明するように、管理アカウントまたは VIP アカウントのユーザー プリンシパル名 (UPN) 属性が特定の種類の攻撃の対象になることがあります。

証明書スプーフィングのための UPN ハイジャック

公開キー インフラストラクチャ (PKI) に対する攻撃の詳細な説明は、このドキュメントの範囲外ですが、パブリックおよびプライベートの PKI に対する攻撃は 2008年以降、飛躍的に増加しています。 公開 PKI の侵害は、広く公表されていますが、組織の内部 PKI に対する攻撃は、おそらく、さらに大量に発生しているでしょう。 そのような攻撃の 1 つは、Active Directory と証明書を利用して、攻撃者が検出が困難な方法で他のアカウントの資格情報をスプーフィングできるようにするものです。

ドメインに参加しているシステムに対して証明書が認証用に提示されると、証明書のサブジェクトまたはサブジェクト別名 (SAN) 属性の内容を使用して、証明書が Active Directory 内のユーザーオブジェクトにマップされます。 次のスクリーンショットに示すように、証明書の種類とその構成方法に応じて、証明書のサブジェクト属性には通常、ユーザーの共通名 (CN) が含まれます。

Screenshot that shows the Subject attribute in a certificate typically contains a user's common name.

既定では、Active Directory は、アカウントの名前 + " "+ 姓を連結して、ユーザーの CN を構築します。 ただし、Active Directory 内のユーザーオブジェクトの CN コンポーネントは、必ずしも固有である必要はなく、固有であることも保証されていません。また、ユーザーアカウントをディレクトリ内の別の場所に移動させると、アカウントの識別名 (DN) が変更されます。これは、前のスクリーンショットの下部示されているように、ディレクトリ内のオブジェクトへのフルパスです。

証明書のサブジェクト名は静的であることも固有であることも保証されないため、多くの場合、サブジェクト別名の内容を使用して Active Directory 内のユーザー オブジェクトを検索します。 エンタープライズ証明機関 (Active Directory 統合 CA) のユーザーに発行された証明書の SAN 属性には、通常、ユーザーの UPN または電子メール アドレスが含まれます。 UPN は AD DS フォレスト内で一意であることが保証されているため、通常、UPN によるユーザーオブジェクトの検索は、認証プロセスに証明書が含まれているかどうかにかかわらず、認証の一部として実行されます。

認証証明書の SAN 属性での UPN の使用は、攻撃者が不正な証明書を取得するために利用することがあります。 攻撃者がユーザー オブジェクトの UPN を読み書きできるアカウントを侵害した場合、攻撃は次のように実行されます。

ユーザー オブジェクト (VIPユーザなど) の UPN 属性は、一時的に別の値に変更されます。 SAM アカウント名属性と CN は、この時点でも変更することもできますが、通常は前述の理由で必要ありません。

ターゲット アカウントの UPN 属性が変更されると、古い有効なユーザーアカウントまたは新しく作成されたユーザーアカウントの UPN 属性が、ターゲットアカウントに最初に割り当てられた値に変更されます。 古い有効なユーザー アカウントとは、長期間ログオンしていないが、無効になっていないアカウントのことです。 これらは、次の理由で「同化して見えない」攻撃者の標的になります。

  1. アカウントは有効になっていますが、最近使用されていないため、アカウントを使用しても、無効になっているユーザーアカウントを有効にした場合のようにアラートがトリガーされることはありません。
  2. 既存のアカウントを使用する場合、管理スタッフが認識する可能性のある新しいユーザーアカウントを作成する必要はありません。
  3. 古いユーザー アカウントは通常、さまざまなセキュリティ グループのメンバーであり、ネットワーク上のリソースへのアクセスが許可されているため、既存のユーザーへのアクセスと「混在」が容易になります。

ターゲット UPN が構成されたユーザー アカウントは、Active Directory 証明書サービスから 1 つ以上の証明書を要求するために使用します。

攻撃者のアカウントの証明書が取得されると、「新しい」アカウントとターゲットアカウントの UPN は元の値に戻ります。

攻撃者は、ユーザーがアカウントが一時的に変更された VIP ユーザーであるかのように、リソースおよびアプリケーションに対する認証のために提示できる 1 つ以上の証明書を持つようになります。 証明書および PKI が攻撃者の標的になる可能性があるすべての方法についての詳細な説明はこのドキュメントの範囲外ですが、この攻撃メカニズムは、AD DS の特権アカウントおよび VIP アカウントの変更、特にアカウントの[Account]タブのいずれかの属性の変更 (例:cn、name、sAMAccountName、userPrincipalName、userAccountControl) を監視すべき理由を説明するために記載されています。 アカウントの監視に加えて、アカウントを変更できるユーザーを、できるだけ少数の管理ユーザーに制限する必要があります。 同様に、管理ユーザーのアカウントを保護し、不正な変更がないか監視する必要があります。