Se un portatile le cui firme antivirus hanno smesso di aggiornarsi settimane fa riesce ancora ad aprire l'applicazione interna, raramente il documento di policy è ciò che non va. Tre sistemi separati devono concordare prima che l'accesso venga negato: qualcosa misura l'endpoint, qualcosa converte quella misura in un verdetto di consenso o diniego, e qualcosa scarta davvero il traffico. Quando un dispositivo non conforme entra comunque, esattamente uno di quegli anelli manca o si fida di prove di cui non dovrebbe. I controlli qui sotto seguono quest'ordine, e ciascuno ha un punto di arresto.

Il blocco è l'ultimo passo, non il primo

Autenticazione e postura rispondono a domande diverse. Un accesso riuscito prova che è stata presentata una credenziale; non dice nulla sul software in esecuzione sulla macchina che l'ha presentata. Proprio questo divario permette a un profilo client copiato di portare una sessione dall'aria sana su un host non sano.

Il lavoro sulla conformità degli endpoint ha già un vocabolario per questa catena. Il modello di riferimento NEA dell'RFC 5209 divide il compito in un raccoglitore, un passo di valutazione e un punto di applicazione, e dice chiaramente che un client che mente sul proprio stato resta fuori dal modello. Quella riserva conta più del diagramma: un modulo di piattaforma fidato non trasforma una misura autodichiarata in un fatto.

Tieni il raccoglitore onesto sull'ambito. Deve riportare gli attributi che la tua policy nomina, sul dispositivo che chiede accesso, e poco altro. Un agente di inventario che elenca ogni pacchetto installato è uno strumento diverso da un raccoglitore di postura, e la differenza è insieme un problema di conservazione e di accuratezza. Se il report non si può legare a un'identità di dispositivo, il valutatore sta indovinando quale macchina ha appena autorizzato.

Una dashboard che mostra uno stato rosso non è un controllo. Chiedi a cosa può ancora arrivare un utente negato: il wiki, la condivisione file, la porta del database? La remediation richiede un'unica superficie stretta, e tutto il resto sta dietro il blocco.

Leggi il report prima di leggere la regola

Parti dalla fonte invece che dalla spunta verde del client. Su Windows la misura locale viene da Defender o dal prodotto che si è registrato presso Security Center, ed entrambi si leggono senza console del fornitore:

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState

Il secondo comando restituisce un intero chiamato productState. I suoi bit sono documentati in modo lasco e i fornitori impacchettano diversamente i flag di attivazione e aggiornamento, quindi confermalo invece di analizzarlo. Anche le suite di terze parti lasciano la voce di Security Center dopo la disinstallazione, e quella riporta software che non è più sul disco.

L'età è il campo che le persone saltano. Un timestamp della firma significa qualcosa solo rispetto all'orologio della macchina che esegue la valutazione, quindi convertilo in un intervallo invece di stimarlo a occhio:

$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours

Ora la policy ha un numero da leggere. Se la tua regola dice 72 ore, è il numero che usa, e un portatile che dorme una settimana fallisce senza che nessuno interpreti un'etichetta. Annota la soglia accanto al comando, perché le due cose divergano quando lo strumento endpoint viene sostituito.

Converti ogni stato del dispositivo in un verdetto scritto

La maggior parte delle dispute sulla postura sono in realtà dispute sulla riga sconosciuta. Decidila prima del primo incidente, in una tabella che nomina la prova, il verdetto e il proprietario, così nessuno improvvisa alla console del gateway.

Evidence the assessor hasVerdictWhat it protects against
Timestamp inside the policy window, protective service runningAdmit to normal applicationsNothing yet; the other checks still apply
Timestamp older than the windowDeny, admit remediation page onlySignature rollback and dormant laptops
Service disabled or reporting offDeny, escalate to the endpoint ownerAn agent reporting stale success
No report at all for this sessionTreat as deny, never as healthyAgents that fail open under load

La riga in basso è dove i prodotti differiscono. Alcuni gateway rifiutano la connessione e spiegano perché; altri lasciano salire il tunnel e applicano una policy ristretta; pochi tornano all'ultimo report buono conosciuto. Solo i primi due sono difendibili, e vale la pena provare quale faccia il tuo.

Tieni identità e permesso nelle loro corsie. Un portatile che supera ogni test di postura ha comunque bisogno dell'autorizzazione umana corretta per l'applicazione, e un certificato di dispositivo prova il possesso di una chiave, non lo stato del filesystem. Schiacciare i tre in un solo booleano è il modo in cui un account di helpdesk finisce con accesso permanente alla produzione.

Verifica il percorso di applicazione con una richiesta, non con una dashboard

L'applicazione è una proprietà di una richiesta, quindi misurala con una. Metti una macchina non conforme sul tunnel e fai la chiamata che farebbe un utente reale:

curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health

Un 200 da un dispositivo che dovrebbe essere bloccato significa che la decisione non ha mai raggiunto il percorso dei dati. Due cause abituali: la policy è agganciata a un gruppo a cui l'account di test non si è mai unito, oppure l'applicazione è raggiungibile lungo una rotta che la VPN non possiede.

Verifica prima l'assunto di routing. Se il nome interno si risolve in un indirizzo che il client raggiunge già tramite la LAN locale, il tunnel è irrilevante e nessuna policy verrà applicata. Confronta quell'indirizzo con la rotta che il gateway spinge. Su OpenVPN la policy per client vive in file con chiave sul nome comune, quindi è facile ispezionarla:

ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17

Un file che contiene disable disconnette del tutto quel client, mentre una riga push "route ..." restringe ciò che può raggiungere. Entrambi sono applicazione, ed entrambi sono visibili a chiunque stia eseguendo il debug del report.

Prova i quattro casi su un solo account di prova

Il controllo finale è una piccola matrice, non un percorso felice. Fai passare un account di test attraverso quattro stati: attuale, firma scaduta, protezione disattivata, agente non installato. Per ciascuno annota il verdetto nel registro di valutazione, lo stato HTTP che l'applicazione restituisce e se la pagina di remediation si è caricata.

foreach ($case in 'current', 'stale', 'disabled', 'absent') {
  Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
  curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}

Due dettagli sono facili da perdere. Prima la ripetizione: un report catturato mentre la macchina era sana non deve essere accettato per una sessione successiva sullo stesso dispositivo, quindi cerca un timestamp legato alla connessione attuale. Poi la rimozione: disinstallare l'agente dovrebbe produrre lo stesso diniego di un report scaduto, non un passaggio pulito, e questo è il caso che più spesso non viene mai testato.

Quando la matrice coincide con la tabella, consegna tre elementi a chi gestirà il gateway dopo di te: i comandi, la soglia e i quattro esiti attesi. È proprio quella consegna il vero deliverable, perché un progetto di postura che vive solo in un documento di policy deriva la prima volta che lo strumento endpoint cambia il suo campo di report.

Articoli correlati