Blokerer VPN-posturekontrollen ikke? Følg rapporten først
Din endpoint-agent rapporterer, at alt er sundt, men den interne app åbner stadig. Gå gennem indsamleren, afgørelsen og blokeringen, og bevis derefter afvisningen med én anmodning.
Hvis en bærbar computer, hvis antivirus-signaturer stoppede med at blive opdateret for uger siden, stadig kan åbne din interne app, er det sjældent policydokumentet, der er noget i vejen med. Tre separate systemer skal være enige, før adgang afvises: noget måler endpointet, noget omdanner den måling til en afgørelse om tilladelse eller afvisning, og noget dropper faktisk trafikken. Når en ikke-kompatibel enhed alligevel kommer ind, mangler præcis ét af disse led, eller det stoler på beviser, det ikke burde. Kontrollerne nedenfor kører i den rækkefølge, og hver har et stoppunkt.
Blokeringen er det sidste skridt, ikke det første
Godkendelse og enhedstilstand svarer på forskellige spørgsmål. Et vellykket login beviser, at en legitimationsoplysning blev fremlagt; det siger intet om den software, der kører på maskinen, som fremlagde den. Netop dette gab er grunden til, at en kopieret klientprofil kan flytte en session, der ser sund ud, over på en usund vært.
Arbejdet med endpoint-compliance har allerede et ordforråd til kæden. NEA-referancemodellen i RFC 5209 deler opgaven i en indsamler, et vurderingstrin og et håndhævelsespunkt og siger rent ud, at en klient, der lyver om sin egen tilstand, falder uden for modellen. Det forbehold er vigtigere end diagrammet: et betroet platformmodul gør ikke en selvrapporteret måling til en kendsgerning.
Hold indsamleren ærlig om omfanget. Den skal rapportere de attributter, din politik navngiver, på den enhed, der beder om adgang, og lidt andet. En inventaragent, der lister hver installeret pakke, er et andet værktøj end en tilstandsindsamler, og forskellen er både et opbevaringsproblem og et nøjagtighedsproblem. Hvis rapporten ikke kan knyttes til én enhedsidentitet, gætter vurdereren på, hvilken maskine den netop har godkendt.
Et dashboard med rød status er ikke en kontrol. Spørg, hvad en afvist bruger stadig kan nå: wikien, filudvekslingen, databaseporten? Afhjælpning kræver én smal overflade, og alt andet hører bag blokeringen.
Læs rapporten, før du læser reglen
Start ved kilden i stedet for klientens grønne hak. I Windows kommer den lokale måling fra Defender eller fra det produkt, der har registreret sig hos Security Center, og begge kan læses uden leverandørkonsol:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState
Den anden kommando returnerer et heltal kaldet productState. Dets bit er løst dokumenteret, og leverandører pakker flagene for aktivering og ajourhed forskelligt, så bekræft det i stedet for at parse det. Tredjepartspakker efterlader også Security Center-posten efter afinstallation, og den rapporterer om software, der ikke længere er på disken.
Alder er det felt, folk springer over. Et signaturtidsstempel betyder kun noget i forhold til uret på den maskine, der udfører vurderingen, så omdan det til et interval i stedet for at skønne det på øjemål:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours
Nu har politikken ét tal at læse. Hvis din regel siger 72 timer, er det det tal, den bruger, og en bærbar computer, der sover en uge, fejler, uden at nogen fortolker en etiket. Noter tærsklen ved siden af kommandoen, for de to glider fra hinanden, når endpoint-værktøjet udskiftes.
Omdan hver enhedstilstand til en skriftlig afgørelse
De fleste uenigheder om tilstand er i virkeligheden uenigheder om den ukendte række. Afgør det før den første hændelse, i en tabel der navngiver beviset, afgørelsen og ejeren, så ingen improviserer ved gatewaykonsollen.
| 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 |
Bundrækken er, hvor produkterne adskiller sig. Nogle gateways afviser forbindelsen og forklarer hvorfor; andre lader tunnelen komme op og anvender en begrænset politik; få falder tilbage til den sidst kendte gode rapport. Kun de to første er forsvarlige, og det er værd at teste, hvilken din gør.
Hold identitet og tilladelse i deres egne baner. En bærbar computer, der består hver tilstandstest, har stadig brug for den korrekte menneskelige autorisation til appen, og et enhedscertifikat beviser besiddelse af en nøgle, ikke filsystemets tilstand. At presse de tre sammen til én boolean er, hvordan en helpdesk-konto ender med permanent adgang til produktion.
Kontrollér håndhævelsesvejen med en anmodning, ikke et dashboard
Håndhævelse er en egenskab ved en anmodning, så mål den med én. Sæt en ikke-kompatibel maskine på tunnelen, og lav det kald, en rigtig bruger ville lave:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health
Et 200 fra en enhed, der burde være blokeret, betyder, at afgørelsen aldrig nåede datastien. To sædvanlige årsager: politikken er knyttet til en gruppe, som testkontoen aldrig blev medlem af, eller appen kan nås via en rute, som VPN'et ikke ejer.
Kontrollér først routingantagelsen. Hvis det interne navn opløses til en adresse, som klienten allerede når over det lokale LAN, er tunnelen irrelevant, og ingen politik vil blive anvendt. Sammenlign den adresse med den rute, gatewayen skubber. På OpenVPN lever politikken pr. klient i filer, der er nøglet på det fælles navn, så det er let at inspicere:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17
En fil, der indeholder disable, afbryder den klient helt, mens en push "route ..."-linje indsnævrer, hvad den kan nå. Begge er håndhævelse, og begge er synlige for enhver, der fejlfinder rapporten.
Test de fire tilfælde på én prøvekonto
Den sidste kontrol er en lille matrix, ikke en lykkelig vej. Kør én testkonto gennem fire tilstande: aktuel, udløbet signatur, beskyttelse deaktiveret, agent ikke installeret. For hver skal du notere afgørelsen i vurderingsloggen, den HTTP-status appen returnerer, og om afhjælpningssiden blev indlæst.
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
}
To detaljer er nemme at overse. Først genafspilning: en rapport, der blev fanget, mens maskinen var sund, må ikke accepteres til en senere session på samme enhed, så led efter et tidsstempel, der er bundet til den aktuelle forbindelse. Derefter fjernelse: afinstallation af agenten bør give samme afvisning som en forældet rapport, ikke et rent gennemløb, og det er det tilfælde, der oftest aldrig testes.
Når matricen matcher tabellen, overdrag tre ting til den, der kører gatewayen næste gang: kommandoerne, tærsklen og de fire forventede resultater. Netop den overdragelse er den egentlige leverance, fordi et tilstandsdesign, der kun lever i et policydokument, glider første gang, endpoint-værktøjet ændrer sit rapporteringsfelt.