Jamie van der Pijll

Secure access observability: welke signalen wil je echt zien bij ZTNA, VPN en SASE?

Written by

in

, ,

20 mei 2026 · Door Jamie van der Pijll · 7 min leestijd

Secure access ziet er op slides vaak strak uit. In productie wordt het sneller rommelig. Een login lijkt te slagen, de tunnel is up, de policy staat goed en toch kan iemand nog steeds niet bij de applicatie. Daarom wil ik bij ZTNA, VPN en SASE niet alleen zien of iets “aan” staat, maar waar het pad echt breekt.

Bij gewone netwerkobservability kun je vaak nog redelijk beginnen met health, trend en verkeer. Bij secure access komt daar meer doorheen: identity, device-context, DNS, policy, certificaten, brokerpaden en applicatiegedrag. Als je dat allemaal in één dashboard dumpt, maak je het meestal minder duidelijk in plaats van meer.

Kort antwoord

Bij secure access wil ik eerst kunnen zien wie probeerde in te loggen, welke controle de toegang blokkeerde en of het probleem in identity, device, policy, DNS of applicatiepad zit. Alles wat dat onderscheid niet sneller maakt, is voor mij bijzaak.

Waarom secure access lastiger leest dan een gewoon netwerkpad

Een netwerkpad kan stuk zijn door transport, routing of lokale ellende. Bij secure access kan precies hetzelfde verkeer er gezond uitzien terwijl het probleem hoger zit. Dan leeft het pad nog wel, maar niet de sessie. Of de sessie leeft, maar de policy knipt hem alsnog weg. Of de policy laat hem door, maar DNS stuurt de gebruiker naar een plek waar het verhaal opnieuw misgaat.

Daarom vertrouw ik een enkel groen lampje hier nooit zo snel. Een up-status op een client of connector zegt weinig als de rest van de keten nog niet klopt.

De drie vragen die ik als eerste beantwoord wil hebben

  • Wie probeerde wat te bereiken? Gebruiker, device, applicatie en het gevraagde pad moeten meteen leesbaar zijn.
  • Welke controle besliste? Ging het mis op identity, posture, policy, certificaat, DNS of applicatielaag?
  • Is dit een individueel probleem of een patroon? Eén onhandige laptop is iets anders dan een bredere storing in access of naamresolutie.

Als ik die drie vragen niet snel kan beantwoorden, is het observability-verhaal nog niet goed genoeg. Dan kijk ik naar teveel, maar snap ik nog te weinig.

Welke identity-signalen ik echt wil zien

  • inlogpogingen en mislukte authenticatie met een duidelijke reden;
  • MFA-uitkomsten en time-outs waar die echt het verschil maken;
  • device- of posture-evaluaties die laten zien waarom een endpoint wel of niet door mocht;
  • sessie-opbouw en sessie-afbreking, liefst met tijdlijn in plaats van losse events.

Dat hoeft voor mij niet eindeloos uitgebreid. Ik wil vooral geen vage foutmelding als “access denied” zonder context. Dan ga je alsnog handmatig achter identity- en posture-systemen aanlopen terwijl de observability juist had moeten helpen.

DNS, policy en applicatiepad maken het verschil

In secure access-projecten zit het gedoe opvallend vaak niet in de client alleen. Split DNS, private resolvers, policyvolgorde, certificaatverwachtingen en applicaties die zich anders gedragen achter een broker of proxy zijn vaak minstens zo belangrijk. Daarom wil ik kunnen zien welke naam iemand probeerde op te lossen, welk policy-object de beslissing nam en naar welk doelpad de sessie daarna echt ging.

Juist daar wordt het vaak interessant. Een gebruiker zegt dat de toegang stuk is. De auth is gelukt, de client is gezond en toch loopt het vast. Dan blijkt DNS naar een intern pad te wijzen dat niet meer klopt, of een policy matcht net anders dan bedoeld, of het certificaatverhaal gaat scheef zodra de applicatie een omweg neemt.

ZTNA, VPN en SASE vragen elk net iets anders

  • Bij ZTNA wil ik vooral zien welke identity- en applicatiebeslissingen de toegang bepaalden.
  • Bij VPN wil ik naast login en tunnelstatus ook weten of DNS, routing en de feitelijke applicatiebereikbaarheid nog kloppen.
  • Bij SASE wil ik begrijpen welke cloud- of brokerlaag de sessie droeg en waar policy, inspectie of routekeuze hem beïnvloedde.

Dat verschil doet ertoe. Anders bouw je één generiek secure-access-dashboard dat overal half op past en nergens echt helpt.

Waar secure-access dashboards meestal waardeloos worden

  • als identity-, client- en policy-events los van elkaar blijven staan zonder tijdlijn;
  • als succes en mislukking alleen als aantallen terugkomen zonder reden of beslispunt;
  • als transport- en access-signalen door elkaar lopen alsof ze hetzelfde probleem beschrijven;
  • als elke kleine posture-afwijking als even belangrijk wordt behandeld.

Dan krijg je dashboards die er volledig uitzien, maar in een incident alsnog niks beslissends vertellen. Ik heb liever minder signaal en meer richting.

Mijn werkvolgorde

  1. Lees eerst de toegangsketen van gebruiker naar applicatie, niet alleen de client.
  2. Maak identity-, posture- en policybeslissingen zichtbaar met een duidelijke reden per stap.
  3. Koppel DNS en padinformatie eraan vast zodat “ingelogd” niet wordt verward met “bereikbaar”.
  4. Scheid individuele incidenten van bredere patronen zodat je sneller ziet of dit lokaal gedoe is of een platformprobleem.

Verder lezen

Conclusie

Secure access observability is voor mij geen verzameling losse access-events. Ik wil kunnen zien wie ergens bij wilde, welke controle dat besliste en waar het pad daarna echt brak. Pas dan wordt observability hier bruikbaar.

Als je alleen telt hoeveel sessies slagen of falen, mis je meestal precies het stuk dat operators nodig hebben. Het gaat niet om meer signalen. Het gaat om het juiste beslispunt sneller zien.

More posts