Blockerar inte VPN-enhetens tillståndskontroll? Följ rapporten först

Om en bärbar dator vars antivirussignaturer slutade uppdateras för veckor sedan fortfarande kan öppna din interna app, är det sällan policydokumentet som är fel. Tre separata system måste vara överens innan åtkomst nekas: något mäter slutpunkten, något omvandlar mätningen till ett beslut att tillåta eller neka, och något släpper faktiskt igenom trafiken. När en enhet som inte uppfyller kraven ändå kommer in saknas exakt en av dessa länkar, eller så litar den på bevis den inte borde. Kontrollerna nedan går i den ordningen, och var och en har en stoppunkt.

Blockeringen är det sista steget, inte det första

Autentisering och tillstånd svarar på olika frågor. En lyckad inloggning bevisar att en autentiseringsuppgift presenterades; den säger ingenting om programvaran som körs på maskinen som presenterade den. Det är just denna lucka som gör att en kopierad klientprofil kan flytta en till synes frisk session till en ohälsosam värd.

Arbetet med efterlevnad för slutpunkter har redan ett ordförråd för kedjan. NEA-referensmodellen i RFC 5209 delar uppgiften i en insamlare, ett bedömningssteg och en genomdrivningspunkt och säger rakt ut att en klient som ljuger om sitt eget tillstånd faller utanför modellen. Det förbehållet är viktigare än diagrammet: en betrodd plattformsmodul gör inte en självrapporterad mätning till ett faktum.

Håll insamlaren ärlig om omfattningen. Den ska rapportera de attribut som policyn namnger, på den enhet som begär åtkomst, och litet annat. En inventarieagent som listar varje installerat paket är ett annat verktyg än en tillståndsinsamlare, och skillnaden är både ett förvarings- och ett noggrannhetsproblem. Om rapporten inte kan knytas till en enda enhetsidentitet gissar bedömaren vilken maskin den just släppte igenom.

En instrumentpanel som visar röd status är ingen kontroll. Fråga vad en nekad användare fortfarande kan nå: wikin, filutdelningen, databasporten? Åtgärden kräver en enda smal yta, och allt annat hör hemma bakom blockeringen.

Läs rapporten innan du läser regeln

Börja vid källan i stället för vid klientens gröna bock. I Windows kommer den lokala mätningen från Defender eller från produkten som registrerade sig hos Security Center, och båda kan läsas utan leverantörskonsol:

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

Det andra kommandot returnerar ett heltal som heter productState. Dess bitar är löst dokumenterade och leverantörer packar flaggorna för aktivering och aktualitet olika, så bekräfta det i stället för att tolka det. Tredjepartspaket lämnar också Security Center-posten efter avinstallation, och den rapporterar om programvara som inte längre ligger på disken.

Ålder är det fält folk hoppar över. En signaturtidsstämpel betyder bara något mot klockan på maskinen som gör bedömningen, så gör om den till ett intervall i stället för att uppskatta den på ögonmått:

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

Nu har policyn ett tal att läsa. Om din regel säger 72 timmar är det talet den använder, och en bärbar dator som sover en vecka fallerar utan att någon tolkar en etikett. Skriv ned tröskeln bredvid kommandot, eftersom de två glider isär när slutpunktsverktyget byts ut.

Gör om varje enhetstillstånd till ett skriftligt beslut

De flesta tvister om tillstånd är egentligen tvister om den okända raden. Avgör den före den första incidenten, i en tabell som namnger beviset, beslutet och ägaren, så att ingen improviserar vid gatewaykonsolen.

Det är i den nedersta raden som produkterna skiljer sig. Vissa gateways nekar anslutningen och förklarar varför; andra låter tunneln komma upp och tillämpar en begränsad policy; ett fåtal faller tillbaka på den senast kända goda rapporten. Bara de två första är försvarbara, och det är värt att testa vilken din gör.

Håll identitet och behörighet i egna spår. En bärbar dator som klarar varje tillståndstest behöver fortfarande rätt mänsklig auktorisering för appen, och ett enhetscertifikat bevisar innehav av en nyckel, inte filsystemets tillstånd. Att pressa ihop de tre till en enda boolesk är vägen till att ett helpdeskkonto får permanent åtkomst till produktionen.

Kontrollera genomdrivningsvägen med en begäran, inte en instrumentpanel

Genomdrivning är en egenskap hos en begäran, så mät den med en. Sätt en enhet som inte uppfyller kraven på tunneln och gör anropet en riktig användare skulle göra:

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

En 200 från en enhet som borde vara blockerad betyder att beslutet aldrig nådde datapath. Två vanliga orsaker: policyn är kopplad till en grupp som testkontot aldrig gick med i, eller appen är nåbar via en rutt som VPN inte äger.

Kontrollera ruttantagandet först. Om det interna namnet löses till en adress som klienten redan når över det lokala LAN:et är tunneln irrelevant och ingen policy kommer att gälla. Jämför den adressen med rutten som gatewayen knuffar. På OpenVPN lever policyn per klient i filer som är nycklade på det gemensamma namnet, så det är lätt att inspektera:

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

En fil som innehåller disable kopplar bort den klienten helt, medan en push "route ..."-rad snävar in vad den kan nå. Båda är genomdrivning, och båda är synliga för alla som felsöker rapporten.

Testa de fyra fallen på ett enda testkonto

Den sista kontrollen är en liten matris, inte en lycklig väg. Kör ett testkonto genom fyra tillstånd: aktuellt, utgången signatur, skydd avstängt, agent inte installerad. För varje, notera beslutet i bedömningsloggen, HTTP-statusen som appen returnerar och om åtgärdssidan laddades.

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
}

Två detaljer är lätta att missa. Först uppspelning: en rapport som fångades medan maskinen var frisk får inte accepteras för en senare session på samma enhet, så leta efter en tidsstämpel knuten till den aktuella anslutningen. Sedan borttagning: avinstallation av agenten ska ge samma nekande som en inaktuell rapport, inte en ren passage, och det är fallet som oftast aldrig testas.

När matrisen stämmer med tabellen, lämna över tre saker till den som sköter gatewayen nästa gång: kommandona, tröskeln och de fyra förväntade resultaten. Just den överlämningen är den egentliga leveransen, eftersom en tillståndsdesign som bara lever i ett policydokument glider första gången slutpunktsverktyget ändrar sitt rapporteringsfält.