Verificarea stării dispozitivului prin VPN nu blochează? Urmează mai întâi raportul
Agentul de endpoint raportează o stare sănătoasă, dar aplicația internă se deschide în continuare. Parcurge colectorul, verdictul și blocarea, apoi dovedește refuzul cu o singură cerere.
Dacă un laptop ale cărui semnături antivirus au încetat să se actualizeze acum câteva săptămâni poate deschide în continuare aplicația internă, documentul de politică este rareori lucrul care nu este în regulă. Trei sisteme separate trebuie să fie de acord înainte ca accesul să fie refuzat: ceva măsoară endpointul, ceva transformă acea măsurătoare într-un verdict de permitere sau refuz, iar ceva chiar aruncă traficul. Când un dispozitiv neconform intră totuși, exact una dintre acele verigi lipsește sau se încrede în dovezi în care nu ar trebui. Verificările de mai jos merg în acea ordine, și fiecare are un punct de oprire.
Blocarea este ultimul pas, nu primul
Autentificarea și starea dispozitivului răspund la întrebări diferite. O autentificare reușită dovedește că a fost prezentată o acreditare; nu spune nimic despre software-ul care rulează pe mașina care a prezentat-o. Exact această lacună permite unui profil de client copiat să ducă o sesiune cu aspect sănătos pe un host nesănătos.
Munca de conformitate a endpointurilor are deja un vocabular pentru acest lanț. Modelul de referință NEA din RFC 5209 împarte sarcina într-un colector, o etapă de evaluare și un punct de aplicare și spune clar că un client care minte despre propria stare este în afara modelului. Această rezervă contează mai mult decât diagrama: un modul de platformă de încredere nu transformă o măsurătoare autoraportată într-un fapt.
Păstrează colectorul onest în privința domeniului. Trebuie să raporteze atributele pe care le numește politica ta, pe dispozitivul care cere acces, și puțin altceva. Un agent de inventar care listează fiecare pachet instalat este un alt instrument decât un colector de stare, iar diferența este simultan o problemă de păstrare și de precizie. Dacă raportul nu poate fi legat de o singură identitate de dispozitiv, evaluatorul ghicește ce mașină tocmai a admis.
Un panou care arată stare roșie nu este un control. Întreabă la ce mai poate ajunge un utilizator refuzat: wiki-ul, partajarea de fișiere, portul bazei de date? Remedierea are nevoie de o singură suprafață îngustă, iar tot restul aparține în spatele blocării.
Citește raportul înainte de a citi regula
Începe de la sursă în loc de bifa verde a clientului. În Windows măsurătoarea locală vine de la Defender sau de la produsul care s-a înregistrat la Security Center, iar ambele se citesc fără consola furnizorului:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateA doua comandă returnează un întreg numit productState. Biții săi sunt documentați lejer, iar furnizorii împachetează diferit fanioanele de activare și de actualitate, așa că verifică-l în loc să-l analizezi. Pachetele terțe lasă și intrarea din Security Center după dezinstalare, iar aceasta raportează despre software care nu mai este pe disc.
Vârsta este câmpul pe care oamenii îl sar. O marcă de timp a semnăturii înseamnă ceva doar față de ceasul mașinii care face evaluarea, așa că transformă-o într-un interval în loc să o estimezi din ochi:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursAcum politica are un număr de citit. Dacă regula ta spune 72 de ore, acesta este numărul pe care îl folosește, iar un laptop care doarme o săptămână eșuează fără ca cineva să interpreteze o etichetă. Notează pragul lângă comandă, pentru că cele două se despart când instrumentul de endpoint este înlocuit.
Transformă fiecare stare a dispozitivului într-un verdict scris
Majoritatea disputelor despre stare sunt de fapt dispute despre rândul necunoscut. Decide-l înainte de primul incident, într-un tabel care numește dovada, verdictul și proprietarul, ca nimeni să nu improvizeze la consola gateway-ului.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
Rândul de jos este locul unde produsele diferă. Unele gateway-uri refuză conexiunea și explică de ce; altele lasă tunelul să urce și aplică o politică restrictivă; câteva revin la ultimul raport bun cunoscut. Doar primele două sunt de apărat, și merită testat care dintre ele face al tău.
Păstrează identitatea și permisiunea pe benzi proprii. Un laptop care trece fiecare test de stare are totuși nevoie de autorizarea umană corectă pentru aplicație, iar un certificat de dispozitiv dovedește deținerea unei chei, nu starea sistemului de fișiere. A strivi cele trei într-un singur boolean este felul în care un cont de helpdesk ajunge cu acces permanent la producție.
Verifică calea de aplicare cu o cerere, nu cu un panou
Aplicarea este o proprietate a unei cereri, așa că măsoar-o cu una. Pune o mașină neconformă pe tunel și fă apelul pe care l-ar face un utilizator real:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthUn 200 de la un dispozitiv care ar trebui blocat înseamnă că decizia nu a ajuns niciodată pe calea datelor. Două cauze obișnuite: politica este atașată unui grup în care contul de test nu s-a înscris niciodată, sau aplicația este accesibilă pe o rută pe care VPN-ul nu o deține.
Verifică mai întâi presupunerea de rutare. Dacă numele intern se rezolvă la o adresă la care clientul ajunge deja prin LAN-ul local, tunelul este irelevant și nicio politică nu se va aplica. Compară acea adresă cu ruta pe care o împinge gateway-ul. Pe OpenVPN politica per client trăiește în fișiere cheiate pe numele comun, așa că este ușor de inspectat:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17Un fișier care conține disable deconectează complet acel client, în timp ce o linie push "route ..." îngustează la ce poate ajunge. Ambele sunt aplicare, și ambele sunt vizibile pentru oricine depanează raportul.
Testează cele patru cazuri pe un singur cont de test
Verificarea finală este o matrice mică, nu o cale fericită. Condu un cont de test prin patru stări: actual, semnătură expirată, protecție dezactivată, agent neinstalat. Pentru fiecare, notează verdictul în jurnalul de evaluare, statusul HTTP pe care îl returnează aplicația și dacă pagina de remediere s-a încărcat.
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
}Două detalii sunt ușor de ratat. Mai întâi reluarea: un raport capturat cât timp mașina era sănătoasă nu trebuie acceptat pentru o sesiune ulterioară pe același dispozitiv, așa că caută o marcă de timp legată de conexiunea curentă. Apoi eliminarea: dezinstalarea agentului ar trebui să producă același refuz ca un raport învechit, nu o trecere curată, și exact acesta este cazul care cel mai des nu este testat niciodată.
Când matricea se potrivește cu tabelul, predă trei lucruri celui care va opera gateway-ul în continuare: comenzile, pragul și cele patru rezultate așteptate. Exact această predare este livrabilul real, pentru că un design de stare care trăiește doar într-un document de politică derivează prima dată când instrumentul de endpoint își schimbă câmpul de raportare.