特権ユーザーモニタリング：信頼なしの可視性

常時有効な特権アクセスはほとんどの環境で標準であり、調査によると67％の組織が少なくとも一部の役割にこれを付与しています。Netwrix 2026 Data and Identity Security Report。これらの権限は、それを正当化するタスクの間でも有効なままであり、特権ユーザーの監視が埋めるべきギャップです。

Domain Admins メンバーシップを持つ管理者は、資格情報の背後にいる人物がインフラ担当者であろうとフィッシング攻撃者であろうと、適用される Active Directory の管理範囲内で完全な権限を持ちます。

承認の成功は許可を証明するだけです。善意の意図や運用の正当性には別の証拠が必要です。監視はその証拠を提供し、ビジネスが依存する管理を遅らせることなくアクセスガバナンスを強化します。

特権ユーザーの監視とは何ですか？

特権ユーザーの監視とは、セキュリティ関連の機能を実行することが信頼されたアカウントによる活動を継続的に収集・分析し、権限昇格の使用ごとにレビュー可能な記録を残すことです。NISTはprivileged userを、一般ユーザーが実行できないセキュリティ関連の機能を実行する権限と信頼を持つ者と定義しています。

その定義には資格情報の背後に人間がいることは必要ないため、サービスアカウント、managed identities、および権限が昇格されたautomation principalsも同じ範囲に含まれます。

スコープは、多くのチームが開始するオンプレミスのディレクトリを超えています。Active Directory、クラウドアイデンティティプロバイダー、SaaS管理コンソール、またはデータベースのいずれであっても、管理権限を持つアイデンティティは監視対象に含まれます。

なぜ特権ユーザーアカウントは追跡が最も難しいのか

認可システムは主体がアクションを実行できるかどうかを判断し、特権アカウントの場合、その制御範囲内での答えは通常「はい」です。4つの仕組みが、その「はい」を必要以上に隠しています。

有効な資格情報は管理と攻撃を同じように見せます

ディレクトリが権限を付与すると、ログオンイベント、グループメンバーシップの確認、およびリソースアクセスがすべて成功します。資格情報が有効であれば、その背後にいるのが管理者であろうとフィッシング攻撃者であろうと関係ありません。

MITRE技術T1078.002は、初期アクセス、持続性、権限昇格、および防御回避のための有効なドメインアカウント認証情報の悪用を正確にカバーしています。Netwrix 2026 Data and Identity Security Reportの調査によると、73.78％の組織が自分たちのActive Directoryに権限昇格を可能にする誤設定がないと完全には自信を持っていないと答えました。それぞれが同じ信頼された位置への別のルートです。

正式なグループクエリはネストされたメンバーを見逃します

Active DirectoryのmemberOf属性はネストされたグループメンバーシップを省略します。そのため、Domain Adminsやその他の特権グループを直接読み取ると、ネスト経由でアクセスするすべてのユーザーを見逃します。アクセスレビューがその直接メンバーシップに限定されると、最初から誤った対象を認証してしまいます。

ACLはすべてのprivileged groupの外にシャドウ管理者を作成します

アクセス制御リストはshadow adminsに機密権限を付与します。これらのアカウントはすべてのprivileged directoryグループの外に完全に位置しています。最も厳しいケースは、グループのメンバーシップを書き換える権限を持ち、自分自身をそのグループに追加できるアカウントです。この動作は設計によるもので、誰も無効にできる設定ではありません。

GPOとローカル管理者権限は、検出すべきメンバーシップイベントを残しません

GenericWrite または WriteDacl のような Group Policy Object (GPO) の編集権限、および local administrator rights がマシンのローカル Security Accounts Manager (SAM) に保存されている場合、グループメンバーシップなしで同じ実効権限を付与します。

サービスおよびスケジュールされたタスクのログオンは、アカウントのパスワードをLocal Security Authority（LSA）のディスク上に再利用可能なシークレットとして保存します。これにより、そのホストが侵害されると資格情報の侵害につながります。これらはいずれも権限レポートが依存する4728、4732、または4756のメンバーシップ変更イベントを生成しません。

特権ユーザー監視がカバーすべき内容

モニタリングは、リスクを動かす変化を捉えることでコストを正当化します。理想的なアラートイベントは、不正な活動の可能性が高く、誤検知率が低く、audit records は成功した攻撃が残す唯一の証拠であることがあります（CIS Control 8）。すべてを収集しようとする誘惑がありますが、それは誰も読まないキューを生みます。

所有者以外のアクセスによる機密データへのアクセスは、MITRE T1114やT1213などの収集技術に該当し、Microsoft 365ではMailItemsAccessed監査アクションで表示されます。改ざん防止機能はエンドポイントエージェントの無効化試行を検出します。

休眠には定義された閾値が必要で、CISAの休眠アカウント対策は その数値を各組織に委ねています（例ではパスワードの使用期間180日を示しています）。ベンダーアカウントも退職者と同じ管理が必要です。

CISAのCross-Sector Cybersecurity Performance Goals 2.0は2025年12月に発表され、マネージドサービスプロバイダーのリスクに関する目標と、退職日にすべてのアカウントとアクセス経路を無効にする要件を組み合わせています。

Privileged user monitoring と privileged session management と user activity monitoring

3つのコントロールはすべて管理者の行動に関係しているため混同されがちですが、それぞれ異なる単位に適用され、異なる質問に答えます。

特権セッション管理 は接続自体を仲介し、エンドユーザーから資格情報を分離するため、最も深い成果物はセッション録画とキーストロークログです。これらのログはパスワードや個人データを含む入力されたすべてを記録するため、保持期間とアクセス制御は厳格に保つ必要があり、調査担当者は録画とともに解析済みコマンドログも必要です。1つの操作のためにビデオを編集するのはスケールしないためです。

ユーザー活動の監視は、内部脅威を検出するために、全従業員にわたって同じコンテンツのキャプチャを拡張し、NISTのUAM定義に従います。UK ICOの労働者監視ガイダンスは、画面およびキーストロークのキャプチャレベルを、データ保護影響評価が必要な十分に広範な処理として扱います。

Privileged user monitoringはデフォルトでコンテンツのキャプチャをスキップし、認可に重点を置き、管理者の集団をインベントリ化し、各IDが使用した昇格権限を監査します。この狭い焦点が、サンプリングされたセッションセットではなく、すべてのprivileged accountで継続的に実行することを実用的にしており、ほとんどのプログラムは3つのうち少なくとも2つを実行しています。

特権ユーザーモニタリングプログラムの構築方法

最初に発見があり、その後削減、ベースライン設定と検出、そして証拠の保護が続きます。各段階は次の段階がカバーすべき範囲を絞り込むため、検出ツールから始めると後でインベントリを再構築することになります。

1. すべての特権ユーザーを発見する

グループメンバーシップだけでなく、管理権限を付与するすべてのアカウントと権利をマッピングします:

• ドメインおよびローカル管理者は、ネストされたメンバーを含むように推移的なグループメンバーシップを通じて解決されます。
• ディレクトリオブジェクトに対するACL付与権限およびGPO編集権限。
• すべてのエンドポイントのローカル管理者グループ。
• サービスアカウントの種類には、group Managed Service Accounts (gMSAs)、standalone Managed Service Accounts (sMSAs)、コンピューターアカウント、およびサービスを実行するユーザーアカウントが含まれます。
• Break-glass emergency accounts and vendor and contractor access.
• Cloud and SaaS privileged roles, from Entra ID Global Administrator and Privileged Role Administrator to the equivalent tenant-admin roles in other identity providers and business applications.

Give every entry a named owner and a stated purpose, or the inventory becomes a list nobody acts on.

2. Reduce it before monitoring it

Remove every standing account monitoring doesn't need to cover before building the next stage. Most environments carry more elevated rights than the work requires, and the same Netwrix survey found 68% of organizations don't enforce strict least privilege.

Move accounts to just-in-time elevation at minimum, temporary permissions that lapse on expiry, or further to zero standing privilege, where no account holds elevated rights between approved sessions and ephemeral accounts exist only for the duration of the work.

3. Baseline normal administration by role

Feed authentication attempts, access requests, privilege changes, and directory modifications into an identity threat detection and response platform, and let it build a profile for each identity and its peer group instead of judging one connection at a time.

Behavioral analytics and signal correlation catch what single-event rules miss, the same principle behind Microsoft Defender for Identity's own detections. Expect weaker signal for the first few weeks on a new administrator or freshly provisioned service account, since baseline quality improves as activity accumulates.

4. Track entitlement drift between reviews

Compare current entitlements against the last certified state between review cycles, not just during them. Periodic certifications only capture a moment, so a grant added the week after reviewers close a campaign can go unchecked until the next one. Flag any grant that appeared since the last certification, so the annual review confirms what monitoring already caught instead of being the only check that ever runs.

5. Alert on change, correlate on pattern

Alert immediately on the small set of events that are almost never legitimate on their own. Correlate everything else. Most attack activity only becomes visible across a sequence of weaker signals, such as an unusual logon followed by a privilege change followed by access to a system the account has never touched. Build single-event rules and behavioral correlation into the same design, rather than choosing one.

6. Protect the evidence from the administrators it describes

Assume the administrators being monitored can edit the record until the architecture proves otherwise. Domain Admins membership includes membership in the local Administrators group on every domain-joined computer by default, which grants the right to read the Security log and the ability to clear it outright.

NIST SP 800-53 AU-9(4) covers exactly this recursion, since individuals with privileged access who are also audit subjects can affect audit information reliability by inhibiting logging or modifying records.

A determined domain administrator can still bypass ACL restrictions on log access by using SeTakeOwnershipPrivilege to take object ownership and rewrite the object's discretionary access control list (DACL). Build architectural separation instead; that control survives the move. AU-9(2) requires separate audit storage so a compromise of the monitored system doesn't compromise its record.

• Forward security events in near real time to a collector under separate administration. Windows Event Forwarding supports this, but it sends no notification and leaves no gap indicator when a disconnected client's log overwrites events.
• Send the 4728, 4732, and 4756 group-membership-addition events and 5136 changes on AdminSDHolder to that same collector, so nobody can edit a re-grant out of the record between reviews.
• Restrict audit log management to a defined subset of privileged users separate from the administrators the audit covers, per AU-9(4), and grant reviewers read-only access, per AU-9(6).
• Alert on tampering itself. Event 4719 records an audit policy change, and Windows logs it regardless of the audit policy setting; rate it as high criticality. Correlate it with a preceding 4688 process-creation event showing wevtutil or auditpol, which requires command-line logging.

Compliance requirements for privileged user monitoring

Auditors ask organizations to prove who held which rights, when they held them, and what they did with them. Frameworks express that demand as recertification intervals and logging obligations, and the intervals are the easy half. What sinks programs is reconstruction, because a review that nobody can rebuild six months later fails the audit, whether or not it ran on schedule.

以下の参照は2026年9月時点の有効なバージョンを使用しており、PCI DSS v4.0.1、NIST SP 800-53 Rev 5、HIPAA Security Rule（45 CFR Part 164 Subpart C）、およびISO/IEC 27001:2022を対象としています。

これらに加えて適用される2つの欧州の規則があります：Network and Information Systems Directive 2（NIS2）の実施規則と、Digital Operational Resilience Act（DORA）の委任規則です。

HHSは2025年1月にSecurity Ruleの見直しを提案しましたが、これはまだ提案段階であり、規制スケジュールは2027年7月を目標としています最終措置のために。提案された通り、監査管理基準は164.312(b)から164.312(d)(1)に移動し、ePHIを保持するシステムだけでなく、すべての関連システムに適用されます。HHSが規則を確定するまでは164.312(b)が適用されます。

監査準備は、数か月前の特権操作を組織に再構築するよう求められたときに限界を示し、その答えは証拠の保存期間に依存します。

Microsoft Entra ID は、Free プランで7日間、P1 および P2 で30日間、監査およびサインインログを ネイティブ保持期間 に保存します。

PCI DSS要件10.5.1では、12か月分の監査ログ履歴を保持し、直近3か月分は即座に分析可能であることが求められます。ネイティブの保持だけでは不十分なため、転送されたコピーを保持するコレクターが通常、記録システムとなります。

よくある課題とその克服方法

以下の障害は文化的および運用上のものであり、ツールを交換してもほとんど解決しません。

• 管理者は監視を制度的な不信と受け取り、一部はそれを無効にしようとします： 管理対象ドメインの外でログをシステム管理者がアクセスできないシステムに転送し、コントロールが適用される前にどの脅威が資格情報を狙っているかを説明してください。時間制限付きで個別に割り当てられた権利は、管理者を疑わしい者として扱うことなく監査証跡を保持します。
• 正当な privileged アクティビティは、意味のあるアラートを埋もれさせる大量のデータを生成します: イベントごとのアラートではなく、ベースラインからの偏差をスコア化します。検知エンジニアリングを戦術、技術、および手順（TTPs）に合わせます そのため、既知の更新スクリプトを実行する管理者は通知されず抑制されます。
• 共有アカウント、ブレイクグラスアカウント、ベンダーアカウントは個別の帰属を困難にし、緊急アカウントには設計上、名前付きの所有者がいません： Use dedicated administrator accounts（CIS Control 5）を使用し、サービスアカウントを少なくとも四半期ごとに見直してください。すべてのサービスアカウントに名前付きの所有者を割り当て、すべてのブレイクグラス使用時にseverity 0でアラートを出してください。

Netwrixが特権ユーザーの監視を支援する方法

Netwrixはこれらの責任を4つの製品に分割し、各段階ごとに1つずつ担当します。Netwrix Access Analyzerが検出を担当し、Netwrix Privilege Secureが削減を担当します。

Netwrix Auditor と Netwrix Threat Manager は、証拠問題の2つの側面、すなわち変更された履歴記録とアイデンティティの確立されたパターンから逸脱する行動の検出をカバーします。

グループメンバーシップを超えた効果的な権限を発見する

Netwrix Access AnalyzerはActive Directoryのドメイン、OU、グループ、ユーザー、およびコンピューターの実効権限を自動的に判定します。その実効アクセスレポートは、ネストされたグループメンバーシップとACLで付与された権利を解決し、アカウントが実際に持つアクセス権を表示し、同時に期限切れの受託者アカウントにフラグを立てます。このインベントリは削減に寄与します。削減なしのインベントリは監視リストを広げるだけだからです。

常時の特権アクセスをタスクスコープのアクセスに置き換える

Netwrix Privilege Secureは、常設の管理者権限をタスク限定アクセスに置き換えるPrivileged Access Management製品です。Activity Tokenを発行し、これは1つのアクティビティのためだけに存在する一意の時間制限付きアカウントです。Netwrix Privilege Secureはアクティビティ完了時にそのアカウントを削除し、使用間に持続的な昇格資格情報が残らないようにします。

Eastern Carver County Schoolsは、9,300人の学生と2,000人以上のスタッフにサービスを提供するネットワークスイッチ管理、VMware、およびセキュリティカメラシステムから常設の特権アカウントを削除し、タスク終了時に期限切れとなる一時アクセスに置き換えました。チームは数日で展開を完了しました。

変更前後の値とともに権限および構成の変更を記録します

再認証と監査人の履歴クエリはどちらも、以前の環境の記録に依存しています。

Netwrix Auditorは、IT監査およびコンプライアンス報告製品であり、Active Directory、Group Policy、Entra ID、Exchange、ファイルサーバー、SQL Serverを監視し、誰がいつどこで何を変更したかを記録します。変更前後の値も変更の詳細に記録されます。

特定時点のレポートは、日次スナップショットから選択した時点の構成を再構築します。過去の日付でレポートするには、まずその履歴スナップショットをインポートする必要があります。

特権およびサービスアカウントの異常な動作を検出する

ベースライン設定はチームが最も先延ばしにしがちな段階であり、Netwrix Threat Managerがこれを自動化します。Identity Threat Detection製品は、特権アカウントおよびサービスアカウントの行動が確立されたパターンから外れていることを検出します。

異常行動の検出は、アカウントが少なくとも30日間アクティブであることを条件に開始され、最大120日間の活動を基にそのアカウントの基準値を構築し、15分ごとにすべてのユーザーを再評価します。設定された閾値を超える逸脱があると、調査のための脅威記録が作成されます。

ほとんどのチームにとって、有用な質問は現在のプログラムが実際に完了した段階はどれかということです。Netwrix Access Analyzer、Netwrix Privilege Secure、Netwrix Auditor、Netwrix Threat Managerはそれぞれ異なる段階に対応しています。

CISAのアカウント対策をカバーする

CISAの退去戦略ツールはIDごとに侵害後の対策をカタログ化しています。そのうち5つは特権および古いアカウントを対象としており、それぞれにNetwrix製品が関連しています：

• 不要で古くなったアカウントを削除する（CM0112）: Netwrix Access Analyzerは無効および非アクティブなユーザーアカウントを検出し、そのクリーンアップを自動化します。
• ユーザー、サービス、管理者アカウントの権限を監視する（CM0043）: Netwrix Access AnalyzerはネストされたグループとACLで付与された権利を解決し、各アカウントの実効権限を表示します。
• アカウント作成と権限変更の監視（CM0044）: Netwrix Auditorは、誰が、何を、いつ、どこで新しいアカウントおよびセキュリティグループのメンバーシップ変更を記録します。
• Active DirectoryのGroup Policyオブジェクトを監査する (CM0085): Netwrix Auditorは、変更前後の値とともにGroup Policyの変更を記録します。
• 疑わしいログイン試行を調査する（CM0063）：Netwrix Threat Managerは各IDのベースラインに対する異常な認証を検出します。

管理者の信頼を確認可能な記録に変えましょう

認証システムは、管理者であろうとフィッシング攻撃者であろうと、有効な資格情報には常に「はい」と応答します。監視だけが両者を区別し、それはプログラムとしてのみ機能します。

そのプログラムは、発見された対象、縮小された攻撃面、行動の基準値、レビュー間で検出された権限の変動、誰も読まないキューの代わりに相関されたアラート、そして監視対象の管理者が静かに編集できない証拠を意味します。

監査人、取締役会、サイバー保険会社は、監視ツールが存在するという方針の声明ではなく、まさにその記録を求めています。この二つの間のギャップは、現在のプログラムがまだ完了していない段階から順に埋められていきます。

デモをリクエストして、Netwrixが特権アカウントの検出、削減、証拠、検知をどのようにカバーしているかをご覧ください。