Blokkeert de VPN-apparaattoestandscontrole niet? Volg eerst het rapport
Uw endpoint-agent meldt een gezonde toestand, maar de interne app opent nog steeds. Loop de verzamelaar, het oordeel en de blokkade door en bewijs de weigering daarna met één verzoek.
Als een laptop waarvan de antivirushandtekeningen weken geleden stopten met bijwerken uw interne app nog steeds kan openen, is het beleidsdocument zelden het ding dat fout is. Drie afzonderlijke systemen moeten het eens zijn voordat toegang wordt geweigerd: iets meet het endpoint, iets zet die meting om in een oordeel toestaan of weigeren, en iets gooit het verkeer echt weg. Wanneer een niet-conform apparaat er toch in komt, ontbreekt precies één van die schakels of vertrouwt het bewijs dat het niet zou moeten. De controles hieronder lopen in die volgorde, en elk heeft een stoppunt.
De blokkade is de laatste stap, niet de eerste
Authenticatie en toestand beantwoorden verschillende vragen. Een geslaagde aanmelding bewijst dat er een referentie is aangeboden; ze zegt niets over de software die draait op de machine die hem aanbood. Juist die kloof zorgt ervoor dat een gekopieerd cliëntprofiel een gezond uitziende sessie naar een ongezonde host kan dragen.
Het werk aan endpointconformiteit heeft al een vocabulaire voor deze keten. Het NEA-referentiemodel in RFC 5209 verdeelt de taak in een verzamelaar, een beoordelingsstap en een handhavingspunt, en zegt ronduit dat een cliënt die liegt over zijn eigen toestand buiten het model valt. Dat voorbehoud is belangrijker dan het diagram: een vertrouwde platformmodule maakt van een zelfgerapporteerde meting geen feit.
Houd de verzamelaar eerlijk over de reikwijdte. Hij moet de attributen rapporteren die uw beleid noemt, op het apparaat dat toegang vraagt, en weinig anders. Een inventarisagent die elk geïnstalleerd pakket opsomt is een ander hulpmiddel dan een toestandsverzamelaar, en het verschil is tegelijk een bewaar- en een nauwkeurigheidsprobleem. Als het rapport niet aan één apparaatidentiteit kan worden gekoppeld, raadt de beoordelaar welke machine hij net heeft toegelaten.
Een dashboard met een rode status is geen controle. Vraag wat een geweigerde gebruiker nog kan bereiken: de wiki, de bestandsshare, de databasepoort? Herstel vraagt één smal oppervlak, en al het andere hoort achter de blokkade.
Lees het rapport voordat u de regel leest
Begin bij de bron in plaats van bij het groene vinkje van de cliënt. Op Windows komt de lokale meting van Defender of van het product dat zich bij het Security Center heeft geregistreerd, en beide zijn leesbaar zonder leveranciersconsole:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState
Het tweede commando geeft een geheel getal met de naam productState terug. De bits zijn losjes gedocumenteerd en leveranciers verpakken de vlaggen voor activering en actualiteit verschillend, dus bevestig het in plaats van het te ontleden. Pakketten van derden laten na de-installatie ook de vermelding in het Security Center achter, en die rapporteert over software die niet meer op de schijf staat.
Leeftijd is het veld dat mensen overslaan. Een tijdstempel van een handtekening betekent alleen iets ten opzichte van de klok van de machine die de beoordeling doet, dus zet het om in een interval in plaats van het op het oog te schatten:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours
Nu heeft het beleid één getal om te lezen. Als uw regel 72 uur zegt, is dat het getal dat hij gebruikt, en een laptop die een week slaapt faalt zonder dat iemand een label interpreteert. Noteer de drempel naast het commando, want de twee lopen uiteen wanneer het endpointinstrument wordt vervangen.
Zet elke apparaattoestand om in een schriftelijk oordeel
De meeste geschillen over toestand zijn eigenlijk geschillen over de onbekende rij. Beslis die vóór het eerste incident, in een tabel die het bewijs, het oordeel en de eigenaar noemt, zodat niemand aan de gatewayconsole improviseert.
| 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 |
De onderste rij is waar producten verschillen. Sommige gateways weigeren de verbinding en leggen uit waarom; andere laten de tunnel omhoog komen en passen een beperkt beleid toe; enkele vallen terug op het laatst bekende goede rapport. Alleen de eerste twee zijn verdedigbaar, en het is de moeite waard te testen welke de uwe doet.
Houd identiteit en toestemming ook in hun eigen sporen. Een laptop die elke toestandstest doorstaat, heeft voor de toepassing nog steeds de juiste menselijke autorisatie nodig, en een apparaatcertificaat bewijst bezit van een sleutel, niet de toestand van het bestandssysteem. De drie tot één boolean samendrukken is hoe een helpdeskaccount blijvende toegang tot productie krijgt.
Controleer het handhavingspad met een verzoek, niet met een dashboard
Handhaving is een eigenschap van een verzoek, dus meet die met één. Zet een niet-conforme machine op de tunnel en doe de aanroep die een echte gebruiker zou doen:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health
Een 200 van een apparaat dat geblokkeerd zou moeten worden, betekent dat de beslissing nooit het datapad heeft bereikt. Twee gebruikelijke oorzaken: het beleid hangt aan een groep waarvan het testaccount nooit lid werd, of de toepassing is bereikbaar via een route die het VPN niet bezit.
Controleer eerst de routingaanname. Als de interne naam oplost naar een adres dat de cliënt al via het lokale LAN bereikt, is de tunnel irrelevant en zal geen beleid gelden. Vergelijk dat adres met de route die de gateway duwt. Op OpenVPN leeft beleid per cliënt in bestanden die op de gemeenschappelijke naam zijn gesleuteld, dus het is gemakkelijk te inspecteren:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17
Een bestand dat disable bevat, koppelt die cliënt volledig af, terwijl een regel push "route ..." vernauwt wat hij kan bereiken. Beide zijn handhaving, en beide zijn zichtbaar voor iedereen die het rapport debugt.
Test de vier gevallen op één testaccount
De laatste controle is een kleine matrix, geen gelukkig pad. Leid één testaccount door vier toestanden: actueel, verlopen handtekening, bescherming uitgeschakeld, agent niet geïnstalleerd. Noteer voor elk het oordeel in het beoordelingslog, de HTTP-status die de app teruggeeft en of de herstelpagina werd geladen.
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
}
Twee details zijn gemakkelijk te missen. Eerst herhaling: een rapport dat is vastgelegd terwijl de machine gezond was, mag niet worden geaccepteerd voor een latere sessie op hetzelfde apparaat, dus zoek een tijdstempel die aan de huidige verbinding is gebonden. Dan verwijdering: het de-installeren van de agent zou dezelfde weigering moeten opleveren als een verouderd rapport, geen schone doorgang, en dat is het geval dat het vaakst nooit wordt getest.
Wanneer de matrix bij de tabel past, draagt u drie dingen over aan wie de gateway hierna beheert: de commando's, de drempel en de vier verwachte uitkomsten. Juist die overdracht is de echte oplevering, want een toestandsontwerp dat alleen in een beleidsdocument leeft, schuift de eerste keer dat het endpointinstrument zijn rapportageveld wijzigt.