Monitoraggio degli utenti privilegiati: Visibilità senza fiducia
Oct 5, 2026
Le operazioni richiedono accesso elevato e le organizzazioni lo concedono basandosi sulla fiducia, quindi il monitoraggio degli utenti privilegiati deve trasformare quella fiducia in prove. Un record di autorizzazione mostra solo che il sistema ha permesso un'azione. Il monitoraggio produce un resoconto verificabile di quali diritti elevati ogni persona ha usato e quando, permettendo a un revisore o investigatore di testare l'attività senza interrompere l'amministrazione.
L’accesso privilegiato permanente e sempre attivo rimane la norma nella maggior parte degli ambienti, e il 67% delle organizzazioni lo concede ad almeno alcuni ruoli, secondo il sondaggio alla base del Netwrix 2026 Data and Identity Security Report. Questi diritti restano attivi tra le attività che li giustificano, ed è questo il divario che il monitoraggio degli utenti privilegiati mira a colmare.
Un amministratore con membership in Domain Admins ha piena autorizzazione all'interno del confine di controllo di Active Directory applicabile, sia che la persona dietro la credenziale sia il responsabile dell'infrastruttura o un attaccante che ha effettuato phishing.
Una decisione di autorizzazione riuscita dimostra il permesso e nulla più. L’intento benigno e la legittimità operativa necessitano di prove separate. Il monitoraggio fornisce queste prove e rafforza la governance degli accessi senza rallentare l’amministrazione da cui dipende l’azienda.
Che cos’è il monitoraggio degli utenti privilegiati?
Il monitoraggio degli utenti privilegiati è la raccolta e l'analisi continua delle attività svolte da account autorizzati a eseguire funzioni rilevanti per la sicurezza, in modo che ogni uso di diritti elevati lasci una traccia verificabile. NIST definisce un privileged user come qualcuno con autorizzazione e quindi fiducia per svolgere funzioni rilevanti per la sicurezza che gli utenti ordinari non possono eseguire.
Niente in quella definizione richiede un essere umano dietro la credenziale, quindi gli account di servizio, le managed identities e gli automation principals con diritti elevati rientrano nello stesso ambito.
L'ambito si estende oltre la directory on-premises da cui la maggior parte dei team parte. Ovunque un'identità detenga diritti amministrativi, sia in Active Directory, un provider di identità cloud, una console di amministrazione SaaS o un database, quell'identità appartiene alla popolazione monitorata.
Perché gli account utente privilegiati sono i più difficili da tracciare
I sistemi di autorizzazione rispondono se un soggetto può eseguire un’azione e, per un account privilegiato, la risposta all’interno del suo confine di controllo è solitamente sì. Quattro meccanismi fanno sì che quel "sì" nasconda più di quanto dovrebbe.
Credenziali valide rendono l'amministrazione e l'attacco identici
Una volta che la directory concede il diritto, l’evento di accesso, il controllo dell’appartenenza al gruppo e l’accesso alla risorsa hanno successo perché la credenziale è valida, sia che la persona dietro sia l’amministratore o un attaccante che l’ha ottenuta tramite phishing.
La tecnica MITRE T1078.002 copre esattamente quell'abuso di credenziali valide di account di dominio per accesso iniziale, persistenza, escalation dei privilegi e elusione della difesa. Nel sondaggio dietro il Netwrix 2026 Data and Identity Security Report, il 73,78% delle organizzazioni ha dichiarato di non essere completamente sicuro che il loro Active Directory sia privo di configurazioni errate che consentano l'escalation dei privilegi. Ognuna è un'altra via verso quella stessa posizione affidabile.
Le query di gruppo formali non includono membri nidificati
L'attributo memberOf di Active Directory esclude l'appartenenza ai gruppi nidificati, quindi una lettura diretta di Domain Admins o di qualsiasi altro gruppo privilegiato non rileva gli utenti che vi accedono tramite nidificazione. Una revisione degli accessi limitata a quella appartenenza diretta certifica fin dall'inizio una popolazione errata.
Le ACL creano amministratori fantasma al di fuori di ogni gruppo privilegiato
Le liste di controllo accessi concedono diritti sensibili ai shadow admins, account che si trovano completamente al di fuori di ogni gruppo di directory privilegiata. Il caso più evidente è un account con il permesso di modificare l'appartenenza a un gruppo, che può aggiungere se stesso a quel gruppo. Questo comportamento è voluto, non è un'impostazione che qualcuno può disabilitare.
I diritti di amministratore locale e GPO non generano eventi di appartenenza da rilevare
I diritti di modifica del Group Policy Object (GPO) come GenericWrite o WriteDacl, e local administrator rights memorizzati nel Security Accounts Manager (SAM) locale di una macchina, conferiscono la stessa autorità effettiva senza necessità di appartenenza a un gruppo.
Gli accessi di servizio e delle attività pianificate salvano anche la password dell’account come segreto riutilizzabile su disco nella Local Security Authority (LSA), il che trasforma qualsiasi compromissione di quell’host in una compromissione delle credenziali. Nessuno di questi genera gli eventi 4728, 4732 o 4756 di modifica dell’appartenenza su cui si basano i report dei diritti.
Cosa dovrebbe coprire il monitoraggio degli utenti privilegiati
Il monitoraggio giustifica il suo costo catturando i cambiamenti che spostano il rischio. L’evento di allerta ideale ha un’alta probabilità di attività non autorizzata e un basso tasso di falsi positivi, e audit records sono a volte l’unica prova che un attacco riuscito lascia dietro di sé (CIS Control 8). La tentazione è raccogliere tutto, il che crea una coda che nessuno legge.
Signal | Examples | Why it matters |
|---|---|---|
|
Entitlement changes |
Admin group additions, Microsoft Entra ID role assignments, organizational unit (OU) delegation, ACL changes, GPO edits |
Each one grants effective authorization or establishes persistence, covered by MITRE T1484 |
|
Authentication behavior |
Logon type shifts, unfamiliar source hosts, elevated-token logons, failed elevation attempts, off-hours access |
Valid-credential abuse carries no malicious signature and surfaces as deviation from an account's baseline |
|
Access to sensitive data |
Non-owner mailbox access, reads of regulated stores, bulk export |
Content access with no matching task maps to collection techniques such as T1114 and T1213 |
|
Security control changes |
Audit policy edits, log clearing, agent disablement, Conditional Access changes |
Tampering with controls usually signals a larger operation already in progress |
|
Account lifecycle events |
Creation, re-enablement of disabled accounts, dormancy |
Adversaries use account creation to hold access across remediation |
Accesso non proprietario a dati sensibili, inclusa la lettura delle caselle di posta, corrisponde a tecniche di raccolta come MITRE T1114 e T1213 e appare in Microsoft 365 tramite l’azione di audit MailItemsAccessed. La protezione contro le manomissioni evidenzia i tentativi di disabilitare un agente endpoint.
La inattività necessita di una soglia definita, e la contromisura di CISA per gli account inattivi lascia quel numero a ogni organizzazione (il suo esempio segnala 180 giorni di età della password). Gli account dei fornitori richiedono la stessa disciplina dei dipendenti in uscita.
I Cross-Sector Cybersecurity Performance Goals 2.0, pubblicati a dicembre 2025, abbinano un obiettivo sul rischio dei fornitori di servizi gestiti con l'obbligo di disabilitare ogni account e percorso di accesso il giorno della partenza di una persona.
Netwrix Threat Manager valuta l'attività degli account privilegiati e di servizio rispetto alla baseline di ciascuna identità e segnala una minaccia quando il comportamento si discosta. Richiedi una demo.
Monitoraggio utenti privilegiati vs. gestione sessioni privilegiate vs. monitoraggio attività utente
Tre controlli vengono confusi tra loro perché tutti riguardano il comportamento amministrativo, ma ciascuno si applica a un’unità diversa e risponde a una domanda differente.
Dimension | Privileged user monitoring | Privileged session management | User activity monitoring |
|---|---|---|---|
|
Scope |
The privileged identity and its entitlements |
The individual privileged session |
Every workforce user |
|
Time horizon |
Continuous, with baselines built over weeks to months |
Duration of a single connection |
|
|
Question answered |
Is this identity's behavior and entitlement set appropriate |
What happened during this session |
Could this person's activity indicate an insider threat |
|
Primary artifact |
Behavioral baseline, risk score, anomaly alerts, entitlement reports |
Session recording, keystroke log, forensic index |
Screen and keystroke content across every employee |
|
Content capture |
Optional |
Standard |
Standard |
Gestione delle sessioni privilegiate gestisce la connessione stessa, isolando le credenziali dall'utente finale, quindi i suoi artefatti più profondi sono le registrazioni delle sessioni e i log delle battute. Questi log catturano tutto ciò che viene digitato, incluse password e dati personali, quindi le finestre di conservazione e i controlli di accesso devono rimanere rigorosi, e gli investigatori hanno ancora bisogno di un log dei comandi analizzato insieme alle registrazioni perché ripulire il video per una singola azione non è scalabile.
Il monitoraggio dell'attività degli utenti estende la stessa acquisizione di contenuti a tutta la forza lavoro per rilevare minacce interne, secondo la definizione UAM di NIST. La linea guida UK ICO sul monitoraggio dei lavoratori considera quel livello di acquisizione di schermo e battiture come un trattamento abbastanza ampio da richiedere una valutazione d'impatto sulla protezione dei dati.
Il monitoraggio degli utenti privilegiati salta la cattura dei contenuti per impostazione predefinita e rimane incentrato sull'autorizzazione, inventariando la popolazione degli amministratori e verificando quali diritti elevati ha utilizzato ogni identità. Questo focus più ristretto rende pratico eseguirlo continuamente su ogni account privilegiato anziché su un campione di sessioni, e la maggior parte dei programmi finisce per eseguirne almeno due su tre.
Come creare un programma di monitoraggio degli utenti privilegiati
Prima viene la scoperta, poi la riduzione, quindi la definizione della baseline e la rilevazione, infine la protezione delle prove. Ogni fase restringe ciò che la successiva deve coprire, motivo per cui iniziare con gli strumenti di rilevazione significa comunque dover ricostruire l'inventario in seguito.
1. Scopri l'intera popolazione privilegiata
Mappa ogni account e ogni diritto che conferisce autorità amministrativa, non solo l'appartenenza a un gruppo:
- Amministratori di dominio e locali, risolti tramite appartenenza transitiva al gruppo in modo che i membri nidificati siano inclusi.
- Diritti concessi da ACL e permessi di modifica GPO sugli oggetti di directory.
- Il gruppo locale degli Amministratori su ogni endpoint.
- Tipi di account di servizio, inclusi group Managed Service Accounts (gMSAs), standalone Managed Service Accounts (sMSAs), account computer e account utente che eseguono servizi.
- 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.
I riferimenti seguenti utilizzano le versioni in vigore a settembre 2026, coprendo PCI DSS v4.0.1, NIST SP 800-53 Rev 5, la HIPAA Security Rule a 45 CFR Parte 164 Sottoparte C, e ISO/IEC 27001:2022.
Due strumenti europei si applicano insieme a essi: il regolamento di esecuzione per la Network and Information Systems Directive 2 (NIS2) e il regolamento delegato per la Digital Operational Resilience Act (DORA).
Framework | Requirement for privileged accountability |
|---|---|
|
PCI DSS v4.0.1 |
Requirement 10.2.1.2 requires logging of all administrative actions. Requirement 7.2.4 requires six-month reviews of user accounts and privileges, including third-party and vendor accounts. |
|
NIST SP 800-53 Rev 5 |
AC-6(9) requires logging the execution of privileged functions. |
|
HIPAA Security Rule |
45 CFR 164.312(b) requires records of system activity for systems holding electronic protected health information (ePHI). The rule prescribes no audit log retention period. |
|
SOX and the Public Company Accounting Oversight Board (PCAOB) |
No numbered control ID covers privileged access review. AS 1105 requires auditors to test the accuracy and completeness of company-produced information. |
|
ISO/IEC 27001:2022 |
Annex A 5.18 and 8.2 require restricting privileged access rights and reviewing them at planned intervals and after changes. Intervals follow the organization's risk assessment. |
|
NIS2 (Implementing Regulation 2024/2690) |
Annex point 11.3 requires reviews of privileged access rights at planned intervals, with the results documented. |
|
DORA (Delegated Regulation 2024/1774) |
Article 21 requires access reviews at least every six months for systems supporting critical or important functions and at least annually for all others. |
HHS ha proposto una riforma della Security Rule a gennaio 2025, ma rimane una proposta, e l'agenda normativa punta a luglio 2027 per l'azione finale. Come proposto, lo standard dei controlli di audit si sposterebbe da 164.312(b) a 164.312(d)(1) e si estenderebbe a ogni sistema rilevante, non solo a quelli che contengono ePHI. Fino a quando HHS non finalizzerà la regola, la citazione applicabile è 164.312(b).
La preparazione all’audit mostra i suoi limiti quando qualcuno chiede a un’organizzazione di ricostruire un’azione privilegiata di mesi prima, e la risposta dipende da quanto a lungo le prove vengono conservate.
Microsoft Entra ID conserva i log di controllo e di accesso per 7 giorni nel livello Free e 30 giorni in P1 e P2 secondo i suoi periodi di conservazione nativi.
Il requisito PCI DSS 10.5.1 richiede dodici mesi di cronologia dei log di audit, con gli ultimi tre mesi immediatamente disponibili per l’analisi. La sola conservazione nativa non è sufficiente, motivo per cui il collector che detiene la copia inoltrata diventa di solito il sistema di registrazione.
Sfide comuni e come superarle
Gli ostacoli seguenti sono culturali e operativi, quindi cambiare gli strumenti raramente li risolve.
- Gli amministratori interpretano il monitoraggio come sfiducia istituzionale e alcuni cercano di disabilitarlo: Mantieni il controllo fuori dal dominio amministrato inoltrando i log a un sistema inaccessibile agli amministratori e spiega quali minacce prendono di mira le loro credenziali prima che vengano applicati i controlli. I diritti assegnati individualmente e limitati nel tempo preservano la traccia di controllo senza trattare gli amministratori come sospetti.
- L'attività privilegiata legittima genera un volume che seppellisce gli avvisi significativi: Valuta le deviazioni dalla baseline invece di segnalare ogni evento. Allinea l'ingegneria della rilevazione a tattiche, tecniche, e procedure (TTPs) così un amministratore che esegue uno script di aggiornamento noto viene silenziato invece di essere allertato.
- Gli account condivisi, break-glass e dei fornitori resistono all'attribuzione individuale, e gli account di emergenza non hanno un proprietario nominato per progettazione: Use dedicated administrator accounts (CIS Control 5) e rivedi gli account di servizio almeno trimestralmente. Assegna un proprietario nominato a ogni account di servizio e genera un avviso a severity 0 a ogni utilizzo break-glass.
Come Netwrix aiuta con il monitoraggio degli utenti privilegiati
Netwrix suddivide queste responsabilità in quattro prodotti, uno per fase. Netwrix Access Analyzer gestisce la scoperta e Netwrix Privilege Secure la riduzione.
Netwrix Auditor e Netwrix Threat Manager coprono quindi le due metà del problema delle prove: il registro storico di ciò che è cambiato e il rilevamento di comportamenti che si discostano dal modello stabilito di un'identità.
Scopri i privilegi effettivi oltre l'appartenenza ai gruppi
Netwrix Access Analyzer determina automaticamente i permessi effettivi su domini, OU, gruppi, utenti e computer di Active Directory. Il suo rapporto di accesso effettivo risolve l’appartenenza a gruppi nidificati e i diritti concessi da ACL per mostrare l’accesso effettivo di un account, e segnala anche gli account trustee obsoleti nello stesso passaggio. Questo inventario alimenta la riduzione, poiché un inventario senza riduzione amplia solo la lista di controllo.
Sostituire l'accesso privilegiato permanente con accesso limitato alle attività
Netwrix Privilege Secure è un prodotto di Privileged Access Management che sostituisce i diritti amministrativi permanenti con accesso limitato alle attività. Emette un Activity Token, un account unico e limitato nel tempo che esiste per una singola attività. Netwrix Privilege Secure rimuove quell’account al termine dell’attività, quindi non rimane alcuna credenziale elevata persistente tra gli usi.
Eastern Carver County Schools ha rimosso gli account privilegiati permanenti dalla gestione degli switch di rete, VMware e dai sistemi di telecamere di sicurezza che servono 9.300 studenti e oltre 2.000 dipendenti, sostituendoli con accessi temporanei che scadono al termine dell’attività. Il team ha completato il rollout in pochi giorni.
Registra le modifiche ai diritti e alla configurazione con i valori prima e dopo
La ricertificazione e la query storica di un auditor dipendono entrambe da un registro di com'era l'ambiente in precedenza.
Netwrix Auditor, un prodotto per audit IT e report di conformità, monitora Active Directory, Group Policy, Entra ID, Exchange, server di file e SQL Server, registrando chi ha modificato cosa, quando e da dove, con valori prima e dopo nei dettagli delle modifiche.
Report di stato ricostruiscono la configurazione in un momento scelto da snapshot giornalieri. Per fare un report su una data passata, è necessario prima importare quello snapshot storico.
Rilevare comportamenti anomali di account privilegiati e di servizio
La definizione della baseline è la fase che i team spesso rimandano, e Netwrix Threat Manager la automatizza. Il prodotto di Identity Threat Detection segnala comportamenti di account privilegiati e di servizio che si discostano da un modello stabilito.
Il rilevamento di comportamenti anomali inizia una volta che un account è stato attivo per almeno 30 giorni, si basa su fino a 120 giorni di attività per costruire la baseline dell’account e rivaluta ogni utente ogni 15 minuti. Una deviazione che supera la soglia configurata crea un record di minaccia per l’indagine.
Per la maggior parte dei team, la domanda utile è quale di queste fasi il loro programma attuale ha effettivamente completato. Netwrix Access Analyzer, Netwrix Privilege Secure, Netwrix Auditor e Netwrix Threat Manager affrontano ciascuno una fase diversa.
Coprire le contromisure degli account di CISA
Strumento di Strategie di Sfratto di CISA cataloga le contromisure post-compromissione per ID. Cinque di esse mirano ad account privilegiati e obsoleti, e ciascuna ha un prodotto Netwrix dietro:
- Rimuovere account superflui e obsoleti (CM0112): Netwrix Access Analyzer segnala account utente disabilitati e inattivi e automatizza la loro pulizia.
- Monitora i permessi per account utente, servizio e amministratore (CM0043): Netwrix Access Analyzer risolve i gruppi nidificati e i diritti concessi da ACL per mostrare i permessi effettivi di ogni account.
- Monitora la creazione degli account e le modifiche alle autorizzazioni (CM0044): Netwrix Auditor registra nuovi account e modifiche ai membri dei gruppi di sicurezza con chi, cosa, quando e dove.
- Auditare gli oggetti di Group Policy in Active Directory (CM0085): Netwrix Auditor registra le modifiche di Group Policy con i valori prima e dopo.
- Indagare tentativi di accesso sospetti (CM0063): Netwrix Threat Manager segnala autenticazioni anomale rispetto alla baseline di ogni identità.
Trasforma la fiducia amministrativa in un record che puoi rivedere
Un sistema di autorizzazione continuerà a dire sì a una credenziale valida, sia che la persona dietro sia l’amministratore o l’attaccante che l’ha ottenuta con phishing. Il monitoraggio è ciò che li distingue, e funziona solo come programma.
Quel programma significa una popolazione scoperta, una superficie di attacco ridotta, una baseline comportamentale, deriva dei diritti rilevata tra le revisioni, avvisi correlati invece di una coda che nessuno legge e prove che gli amministratori che monitora non possono modificare silenziosamente.
Auditor, consigli di amministrazione e assicuratori informatici ora richiedono esattamente quel registro, non una dichiarazione di politica che attesti l’esistenza di uno strumento di monitoraggio. Il divario tra i due si colma un passo alla volta, iniziando da quello che il vostro programma attuale non ha ancora completato.
Richiedi una demo per vedere come Netwrix copre la scoperta, la riduzione, le prove e il rilevamento per i tuoi account privilegiati.
Domande frequenti sul monitoraggio degli utenti privilegiati
Condividi su
Scopri di più
Informazioni sull'autore
Netwrix Team
Scopri di più su questo argomento
Governa l'agente IA come l'identità che è
Convergenza di ITDR, PAM e IGA. Quale dei tre è presente quando arriva l'attacco?
Violazione del sistema di Endpoint Management: perché Privileged Access Management (PAM) è ora fondamentale
Utilizzando Windows Defender Credential Guard per proteggere le credenziali Privileged Access Management
Cos'è Microsoft LAPS: Come puoi migliorarne la sicurezza?