Blokkerer ikke VPN-tilstandskontrollen? Følg rapporten først
Endepunktagenten din rapporterer at alt er sunt, men den interne appen åpnes likevel. Gå gjennom innsamleren, avgjørelsen og sperren, og bevis deretter avslaget med én forespørsel.
Dersom en bærbar PC der antivirusdefinisjonene sluttet å oppdatere seg for uker siden fortsatt kan åpne den interne appen din, er det sjelden policyen som er problemet. Tre atskilte systemer må samstemme før tilgang avvises: noe måler endepunktet, noe gjør målingen til et vedtak om å slippe inn eller avvise, og noe kaster faktisk trafikken. Når en enhet som ikke oppfyller kravene likevel kommer inn, mangler nøyaktig ett av leddene eller stoler på bevis det ikke burde. Kontrollene under går i den rekkefølgen, og hver har et stoppunkt.
Sperren er det siste trinnet, ikke det første
Autentisering og tilstand besvarer forskjellige spørsmål. En vellykket innlogging beviser at en legitimasjon ble lagt frem; den sier ingenting om programvaren som kjører på maskinen som la den frem. Det er dette gapet som gjør at en kopiert klientprofil kan flytte en tilsynelatende sunn økt over på en usunn vert.
Arbeidet med endepunktsamsvar har allerede et vokabular for denne 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 egen tilstand faller utenfor modellen. Det forbeholdet er viktigere enn diagrammet: en betrodd plattformmodul gjør ikke en selvopplyst måling til et faktum.
Hold innsamleren ærlig om omfanget. Den skal rapportere attributtene policyen din nevner, på enheten som ber om tilgang, og lite annet. En inventaragent som lister opp hver installert pakke er et annet verktøy enn en tilstandsinnsamler, og forskjellen er både et lagrings- og et nøyaktighetsproblem. Hvis rapporten ikke kan knyttes til én enhetsidentitet, gjetter vurdereren hvilken maskin den nettopp slapp inn.
Et dashbord med rød status er ikke en kontroll. Spør hva en avvist bruker fortsatt kan nå: wikien, fildelingen, databaseporten? Utbedring krever én smal flate, og alt annet hører hjemme bak sperren.
Les rapporten før du leser regelen
Begynn 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 oppdaterthet ulikt, så bekreft det fremfor å 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 utfører 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 PC som sover en uke feiler uten at noen tolker en etikett. Noter 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 lag. Noen gatewayer avviser forbindelsen og forklarer hvorfor; andre lar tunnelen komme opp og bruker en begrenset policy; noen 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 egne spor. En bærbar PC 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 opp 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 maskin som ikke oppfyller kravene 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 sperret, betyr at avgjørelsen aldri nådde datastien. To vanlige årsaker: policyen er knyttet til en gruppe testkontoen aldri ble medlem av, 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 via det lokale LAN-et, er tunnelen irrelevant og ingen policy vil gjelde. Sammenlign den adressen med ruten gatewayen skyver på. På OpenVPN lever policyen per klient i filer som er nøklet på det felles navnet, så det er enkelt å 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 enhver 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 gjenoppspilling: 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.