特権 AD ユーザーを特定して保護するための10の方法

特権アカウントを侵害することは、ほとんどのサイバー攻撃における「最終目標の一つ手前」の目的です。攻撃者が特権アクセスを得ると、その後、情報資産の窃取や暗号化、あるいは業務運営の妨害といった最終目標を達成できます。通常、サイバー犯罪者はローカルマシン上の低レベルなアカウントを侵害することで、ネットワーク内に足場を築きます。さまざまな手法を用いて、その組織の機密データやシステムにアクセスするために必要な、より特権性の高いアカウントを掌握しようとします。 Active Directory (AD) 環境では、本当の狙いはドメイン管理者（Domain Administrator）アカウントですが、特権アカウントなら何でも十分な場合がよくあります。

特権管理の重要な要素

特権アクセスを持つ攻撃者は、あなたのAD domainをほぼ自由に移動し、最も価値の高いITリソースにアクセスできます。したがって、セキュリティとコンプライアンスを維持するためには、AD環境内のすべての特権アカウントに対して強力なIdentity governanceおよびアクセス管理を確立することが不可欠です。

具体的には、システムとデータの安全を確保するには、2つの重要な要素が関わります。

• どのユーザーが、どのIT資産に対して、どのような特権を持っているかを特定すること
• いずれかのアカウントが初めて特権アクセスを取得したときに検出すること

「privileged access management」は一度きりの取り組みではない、という点を理解することが極めて重要です。ユーザーのオンボーディングや役割変更、そして IT 環境の変化に伴い、グループの権限（entitlements）やメンバーシップは変わります。セキュリティチームは、悪意のある可能性がある、またはそれ以外の不適切な可能性がある変更を見逃さないようにする必要があります。

以下は、特権ユーザーアカウントを侵害から守るために活用できる上位 10 の方法です。これらは、未承認のユーザーが AD への特権アクセスを取得できないようにするための、包括的なセキュリティ戦略の一部です。

1. Domain Admins のような内蔵の特権グループを、厳密に管理してください。

Administrators、Domain Admins、Enterprise Admins、Schema Admins のような組み込みの AD 特権グループは、まず最初に取り組むべき明確な対象です。次に、各 Windows エンドポイントにある Local Administrators グループを確認しましょう。これはそれらのシステムに対して特権アクセスを提供します。

これらの各グループのメンバーを特定するのは、Active Directory Users & Computers（ADUC）でグループの Membership Property タブを表示するだけと同じくらい簡単です。Get-ADGroupMember PowerShell cmdlet を、下のスクリーンショットのように使う方法もあります。複数のグループを素早く分析する必要がある場合は、こちらが推奨の方法です。

グループ メンバーの定期的なレビューは、その時点でのグループの状態に関する情報しか得られない点に留意してください。それでも、開始するには良い場所です。

2. 特権グループの中にネストされたグループがないか確認します。

特権グループにグループがメンバーとして含まれているかどうかを確認することは非常に重要です。なぜなら、そのようなネストされたグループは、特権グループの持つすべてのアクセス権をそのメンバーに付与するからです。たとえば、下のスクリーンショットでは、Domain Admins グループのメンバーの1つが LabPowerUsers というグループであることが分かります。つまり、LabPowerUsers グループのメンバーであれば誰でも、ドメイン全体に対して管理者権限を持つということです。

可能な限り、グループのネストは避けるべきです。特に特権グループの内部では避けてください。ネストを行うと、攻撃者が重要なリソースやデータに、アラームが発報されるリスクをより低くしてアクセスする手段を得られてしまうからです。攻撃者は、より厳密に監視されている可能性がある親の特権グループに直接アカウントを追加するのではなく、自分が管理するアカウントをネストされたグループに追加します。

先ほど示したとおり、Get-ADGroupMember コマンドレットは、照会したグループの直近のメンバーのみを表示するため、入れ子になっているグループは一覧にしますが、そのメンバーまでは表示しません。入れ子になっているグループのメンバーも表示するには、下の赤字で示した LDAP フィルターを使用する方法があります。

      param([string]$groupDn )
$s = new-object system.directoryservices.directorysearcher
$s.searchroot = new-object system.directoryservices.directoryentry
$s.filter = “(&(memberOf:1.2.840.113556.1.4.1941:=$groupDn))”
$s.propertiestoload.add(“name”)
$s.propertiestoload.add(“objectclass”)
$r = $s.FindAll()
foreach ($e in $r)
{Write-Host
$e.Properties.objectclass[$e.Properties.objectclass.Count-1]:
$e.properties.name
      

このコードをスクリプト（.GetNestedMembers.ps1）として保存する場合、目的のグループの識別名（Distinguished Name）を指定して、次のように実行できます：

      .GetNestedMembers.ps1 -groupDn “CN=Administrators,CN=Builtin,DC=lab,DC=local”
      

出力には、グループ名とそのメンバーが一覧で表示されます：

      group : Domain Admins
user : bosshogg
user : azuresync
user : Barry Vista
user : Randy Smith
user : AdminService
      

スクリプト作成に伴う手間や費用をかけずに、昇格された特権を迅速に可視化したいという目的から、多くの組織は Netwrix PAM solution のようなサードパーティの Privileged Access Management (PAM) ツールへの投資を選択します。

3. 組織単位（OU）の権限に注意してください。

グループ メンバーシップを通じて特権を得ることに加えて、ユーザーは組織単位（OU）レベルで制御を委任されることもできます。以下のスクリーンショットでは、あるグループに対して Sales OU への特権が委任されています。そのグループのすべてのメンバーは、Sales OU 内の任意のグループのメンバーシップを変更することを含め、選択されたタスクを実行できるようになります。

OU の権限を把握することは、継承によって複雑になります。NTFS のセキュリティと同様に、親 OU の権限が子 OU とリーフ オブジェクトに下方へ伝播します。これにより、多くのユーザーが発見しにくい高い権限を持つことにつながり得ます。以下のスクリーンショットは、Sales OU のすべての子 OU とリーフ オブジェクトを示しています。

親 OU から継承を切り離すことは可能ですが、それを行うと、たとえば担当しているオブジェクトを管理できなくなるといった問題が発生する可能性があります。

ディレクトリ オブジェクトにアクセスされるたびに監査イベントを生成するには、AD Group Policy を使用できます。Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access を選択し、 Audit Directory Service Changes を下記のように構成します。

この監査を有効にすると、ログ エントリが膨大な量生成される点に注意してください。そのため、監査ログを手作業で確認するにはかなりの時間がかかります。さらに、ログ エントリにはどの権限が割り当てられているかは明示されません。特定の OU の権限を見直す必要があることが分かるだけです。

4. ドメイン コントローラー（DC）に、管理者に相当する権限がないか確認します。

ドメイン コントローラーは、Windows Server オペレーティング システムを実行し、重要な認証および認可サービスを提供する特殊な機器です。そのため、DC で管理者レベルの権限を持つアカウントを確認することが重要です。たとえば、サービス アカウントに DC 上でファイルをバックアップまたは復元する権利が付与される場合があります。攻撃者は、Mimikatz を使用してパスワード ハッシュを特定し、その後に平文パスワードを解読（クラック）することで、これらのアカウントを侵害できます。

次の内容にもとづいて、どのアカウントがこれらの権利を持っているかを特定できます。

• 「デフォルト ドメイン コントローラー」ポリシーの確認
• PowerShell スクリプトの使用
• PAM ツールとして Netwrix PAM solutions

5. 他のアカウントに対してパスワードのリセット権限を持つユーザーを特定します。

ユーザー アカウントのパスワードをリセットできる権限は、脅威アクターにとって非常に求められます。というのも、アカウントのパスワードをリセットすると、そのアカウントを制御できるようになるからです。この権利は Full Control 権限に含まれています。以下のように Delegation of Control ウィザードを使用して、他のユーザーのパスワードをリセットするための特定の権限を委任することもできます:

以下の例では、PC Support グループのメンバーに、ドメイン管理者のパスワードをリセットする権限が付与されています。したがって、PC support グループのいずれかのメンバーのアカウントを侵害できれば、攻撃者は容易に昇格されたドメイン全体の特権を取得できます。

この特権を持っているのが誰なのかを確認するために、すべての OU とユーザー オブジェクトを手作業でくまなく調べるのは時間がかかり、ミスも起こりやすくなります。また、すべてのパスワード リセット アクティビティを手作業で監査しようとすることも同様に現実的ではありません。Netwrix AD security の製品を使えば、どのアカウントがパスワード リセット権限を持っているかを簡単に確認できます。以下のスクリーンショットは、prod.net ドメインの 1,000 人のユーザーのパスワードを 15 人の異なる個人がリセットできる環境を示しています:

6. 特権のあるサービスアカウントの使用を監視します。

以前のヒントでは、DCに対して管理者と同等のアクセス権を持つサービスアカウントに注意する必要があると述べました。しかし、サービスアカウントに伴うリスクはDCに限定されません。Exchange、SQL Server、バックアップソリューション、その他の業務アプリケーションのようなワークロードは、管理者権限を持つことが多いサービスアカウントで実行されており、そのアカウントの認証情報を知っている人であれば誰でも悪意のある目的に利用できます。

サービスアカウントのパスワードは、定期的に変更されないことが多く、場合によっては一度も変更されないことさえあるため、誰がそれらを知っているのかが不明確になりがちです。たとえサービスアカウントのパスワードを定期的にローテーションしている場合でも、これらのアカウントのログオン活動を監査して、割り当てられたサービスのためにのみ使用され、不正な活動、たとえばドメインコントローラーへの対話型ログオンには使われていないことを確認する必要があります。

DC上のSecurityログを使って、サービスアカウントが不適切に使用されていないかどうかを判断するには、複数の情報を組み合わせてパズルのように突き合わせる必要があります。たとえば、イベント4768はKerberos認証チケットが要求されたことを示し、4672は新しいログオンに対して特別な特権が付与されたことを示しますが、これらはイベント4624（アカウントが正常にログオンされた）と関連付けて確認する必要があります。

7. DCに適用される、またはドメインの特権アクセスを持つアプリケーションを実行するサーバーに適用されるGPOに対して書き込み権限を持つユーザーを特定します。

グループ ポリシー（Group Policy）は、ユーザーと、DC、アプリケーション サーバー、Windows エンドポイントのようなマシンの両方を管理するための強力なツールです。そのため攻撃者はこれを支配しようとします。また、どのユーザーが任意のグループ ポリシー オブジェクト（GPO）に対して書き込み可能なアクセス権を持っているかを監視することが、極めて重要です。

まずは、ドメイン ルートまたはドメイン コントローラー OU（Domain Controllers OU）にリンクされているすべての GPO の権限を確認することをおすすめします。これは、下に示すように、Default Domain Controllers policy の Delegation タブを確認することで簡単に行えます。

8. どの AD 管理ソリューションにもアクセスできるすべてのユーザー アカウントを特定します。

多くの組織は、AD 管理タスクを簡素化するためにサードパーティのソリューションを利用しています。これらのソリューションは、特権アクセスを得ようとする脅威アクターに対して、時には 2 つの攻撃手法を可能にすることがあります。

• 1 つ目は、ソリューションの管理機能を有効にするために、AD のすべて、または一部に対して特権アクセス権を付与されたサービス アカウントもしくはプロキシ アカウントを使用することです。
• 2つ目の方法では、管理ソリューション内で権限が付与された任意のアカウントを使用します。 ここでは 権限レベルの低いユーザーが、ADアカウントの一部に対して特権タスク（例：別のユーザーのパスワードをリセットする）を実行できるように許可される場合があります。委任のレベルに応じて、このようなアカウントを乗っ取ることは、Domain Adminになるのと同程度に有益な場合があります。

これらのリスクを可視化するには、使用中のすべての管理アプリケーションを棚卸しする必要があります。これらは多くの場合、ドメイン コントローラー上には存在しないことに注意してください。次に、特権アクセス権を持つすべてのサービスアカウントおよびプロキシアカウントを特定し、それらが何を実行しているかを監視します。ほとんどの管理ソリューションでは、不適切な挙動を監視するための監査証跡（audit trail）を確立する手段が用意されています。これらのアプリケーションによって生成されたアラートは、SIEM を利用できる場合は、そのソリューションに転送（パイプ）することもできます。

別の方法として、Netwrix Auditor は、Windows サーバー上のハードウェアとソフトウェアのすべての変更、スケジュールされたタスク、アプリケーション、ネットワーク設定などについて、詳細をまとめた日次のアクティビティ概要を送信できます。以下は、インストールされているすべてのアプリケーションを示すスクリーンショットです：

9. 仮想化インフラの管理者も忘れないでください。

仮想AD環境を保護するには、仮想インフラに対して特権アクセス権を持つアカウントがどれかを把握する必要があります。DC またはメンバー サーバーをホストしている仮想環境を管理する人は、物理マシンに対する管理者と同等のアクセス権を持つことを忘れないでください。

たとえば Hyper-V を実行している場合、Hyper-V Administrators のローカル グループのメンバーは、ゲスト OS に対して管理者レベルのアクセス権を持ちます。同様に、VMware 環境では、ESXi システムの root ユーザーも同等のアクセス権を持ちます。また、メンバー サーバーが AD をホストしていなくても、AD 権限を持つ管理アプリケーションやサービス アカウントが存在すれば、同じリスクが発生します。

10. 管理者が資格情報の痕跡（credential artifacts）を残さないようにする。

ユーザーがシステムにログオンすると、ログオフ後も資格情報（credential information）の一部が残っていることがよくあります。この情報には、平文パスワード、パスワード ハッシュ、NTLM ハッシュ、Kerberos チケットが含まれる場合があります。Mimikatz のようなツールを使うことで、攻撃者はサーバーやワークステーションのメモリ内に残されたこれらの痕跡（artifacts）を容易に悪用し、特権アカウントとして自分自身を認証できます。たとえば、平文パスワードはそのまま再利用でき、ハッシュは認証要求の一部として渡して使用することができます。さらに追加のハッキング ツールを用いることで、他のシステムへのアクセスを得られます。

残念ながら、どのマシンに特権資格情報の痕跡（privileged credential artifacts）が残っているかを特定することはほぼ不可能です。したがって、注目すべきポイントは、特権ユーザーがどこにログオンしているのかを判断することです。

前述のとおり、特権があることが分かっているグループについて、現在の Windows システムのいずれでもイベント ID 4627（Special privileges assigned to new logon）を監視できます。また、特権ログオンを特定するために、DC でイベント ID 4769（A Kerberos service ticket was requested）を監視することもできます。

特権アカウントがどのように使用されているかを把握したら、WDigest の設定によって、平文のパスワードがメモリに保存されないようにしてください。また、資格情報を安全に保つため、特権アカウントをユーザーのワークステーションで使用することを禁止し、エンドユーザーの問題に対処するために Local Admin 権限を持つアカウントを使用してください。

特権アカウントをしっかり管理する

特権ユーザーアカウントは、ローカルの Admin 権限を持つ 1 台限りのアカウントから、完全な Domain Admin 権限を持つアカウントまで、攻撃者によって定期的に狙われます。侵害やダウンタイムを防ぐには、誰があなたの特権ユーザーであるかを把握し、特権アクセスに影響し得る変更を監視する必要があります。ただし、標準のツールに依存すると、評価や監視は時間がかかり、エラーが起こりやすいプロセスになります。特権アカウントを侵害や不正使用から確実に守るために必要な信頼性の高い 24/7 の監視には、自動化されたサードパーティのツールが必要です。その Netwrix suite of solutions は、privilege escalation の試みや特権の濫用を検知して阻止するために必要な可視性を提供します。