Blokkerer ikke VPN-enhetstilstandskontrollen? Følg rapporten først
Endepunktagenten din rapporterer sunn tilstand, men den interne appen åpnes likevel. Gå gjennom innsamleren, avgjørelsen og blokkeringen, og bevis deretter avvisningen med én forespørsel.
Hvis en bærbar datamaskin der antivirussignaturene sluttet å oppdatere seg for uker siden fortsatt kan åpne den interne appen din, er det sjelden policydokumentet som er feil. Tre separate systemer må være enige før tilgang nektes: noe måler endepunktet, noe gjør målingen om til en avgjørelse om å tillate eller avvise, og noe slipper faktisk trafikken gjennom. Når en ikke-samsvarende enhet likevel kommer inn, mangler nøyaktig ett av disse leddene eller stoler på bevis det ikke burde. Kontrollene nedenfor går i den rekkefølgen, og hver har et stoppunkt.
Blokkeringen er det siste trinnet, ikke det første
Autentisering og tilstand svarer på forskjellige spørsmål. En vellykket innlogging beviser at en legitimasjon ble lagt fram; den sier ingenting om programvaren som kjører på maskinen som la den fram. Det er nettopp dette gapet som gjør at en kopiert klientprofil kan flytte en sunn utseende økt over på en usunn vert.
Arbeidet med endepunktsamsvar har allerede et ordforråd for kjeden. NEA-referansemodellen i RFC 5209 deler oppgaven i en innsamler, et vurderingstrinn og et håndhevelsespunkt, og sier rett ut at en klient som lyver om sin egen tilstand faller utenfor modellen. Det forbeholdet er viktigere enn diagrammet: en betrodd plattformmodul gjør ikke en selvrapportert måling til et faktum.
Hold innsamleren ærlig om omfanget. Den skal rapportere attributtene policyen din navngir, på enheten som ber om tilgang, og lite annet. En inventaragent som lister hver installert pakke er et annet verktøy enn en tilstandsinnsamler, og forskjellen er både et oppbevarings- og et nøyaktighetsproblem. Hvis rapporten ikke kan knyttes til én enhetsidentitet, gjetter vurdereren hvilken maskin den nettopp slapp gjennom.
Et dashbord som viser rød status er ikke en kontroll. Spør hva en avvist bruker fortsatt kan nå: wikien, filutvekslingen, databaseporten? Utbedring trenger én smal flate, og alt annet hører til bak blokkeringen.
Les rapporten før du leser regelen
Start ved kilden i stedet for ved klientens grønne hake. I Windows kommer den lokale målingen fra Defender eller fra produktet som registrerte seg hos Security Center, og begge kan leses uten leverandørkonsoll:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateDen andre kommandoen returnerer et heltall kalt productState. Bitene er løst dokumentert, og leverandører pakker flaggene for aktivering og ajourhold ulikt, så bekreft det i stedet for å tolke det. Tredjepartspakker etterlater også Security Center-oppføringen etter avinstallering, og den rapporterer om programvare som ikke lenger ligger på disken.
Alder er feltet folk hopper over. Et signaturtidsstempel betyr bare noe mot klokken til maskinen som gjør vurderingen, så gjør det om til et intervall i stedet for å anslå det på øyemål:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursNå har policyen ett tall å lese. Hvis regelen din sier 72 timer, er det tallet den bruker, og en bærbar datamaskin som sover en uke feiler uten at noen tolker en etikett. Skriv ned terskelen ved siden av kommandoen, for de to glir fra hverandre når endepunktverktøyet byttes ut.
Gjør hver enhetstilstand om til en skriftlig avgjørelse
De fleste tvister om tilstand er egentlig tvister om den ukjente raden. Avgjør den før den første hendelsen, i en tabell som navngir beviset, avgjørelsen og eieren, slik at 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 |
Bunnraden er der produktene skiller seg. Noen gatewayer avviser forbindelsen og forklarer hvorfor; andre lar tunnelen komme opp og bruker en begrenset policy; få faller tilbake til den sist kjente gode rapporten. Bare de to første er forsvarlige, og det er verdt å teste hvilken din gjør.
Hold identitet og tillatelse i sine egne spor. En bærbar datamaskin som består hver tilstandstest trenger fortsatt riktig menneskelig autorisasjon for appen, og et enhetssertifikat beviser besittelse av en nøkkel, ikke filsystemets tilstand. Å presse de tre sammen til én boolsk verdi er måten en helpdesk-konto ender med permanent tilgang til produksjon.
Kontroller håndhevelsesveien med en forespørsel, ikke et dashbord
Håndhevelse er en egenskap ved en forespørsel, så mål den med én. Sett en ikke-samsvarende maskin på tunnelen og gjør kallet en ekte bruker ville gjort:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthEn 200 fra en enhet som skulle vært blokkert betyr at avgjørelsen aldri nådde datastien. To vanlige årsaker: policyen er knyttet til en gruppe testkontoen aldri ble med i, eller appen er tilgjengelig via en rute VPN-et ikke eier.
Kontroller ruteantakelsen først. Hvis det interne navnet løses til en adresse klienten allerede når over det lokale LAN-et, er tunnelen irrelevant og ingen policy vil gjelde. Sammenlign den adressen med ruten gatewayen skyver. På OpenVPN lever policyen per klient i filer som er nøklet på det felles navnet, så det er lett å inspisere:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17En fil som inneholder disable kobler den klienten helt ut, mens en push "route ..."-linje snevrer inn hva den kan nå. Begge er håndhevelse, og begge er synlige for alle som feilsøker rapporten.
Test de fire tilfellene på én testkonto
Den siste kontrollen er en liten matrise, ikke en lykkelig vei. Kjør én testkonto gjennom fire tilstander: gjeldende, utløpt signatur, beskyttelse deaktivert, agent ikke installert. For hver av dem, noter avgjørelsen i vurderingsloggen, HTTP-statusen appen returnerer, og om utbedringssiden ble lastet.
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 lette å overse. Først gjenavspilling: en rapport som ble fanget mens maskinen var sunn, må ikke godtas for en senere økt på samme enhet, så se etter et tidsstempel bundet til den gjeldende forbindelsen. Deretter fjerning: avinstallering av agenten skal gi samme avvisning som en utdatert rapport, ikke en ren passasje, og det er tilfellet som oftest aldri testes.
Når matrisen stemmer med tabellen, overlever tre ting til den som driver gatewayen neste gang: kommandoene, terskelen og de fire forventede resultatene. Nettopp den overleveringen er den egentlige leveransen, fordi et tilstandsdesign som bare lever i et policydokument, glir første gang endepunktverktøyet endrer rapporteringsfeltet sitt.