Zero Trust Architectuur

Netwerkgrenzen Die Echt Tellen

In netwerkbeveiliging wint structuur van improvisatie: duidelijke paden, minder privileges en expliciete trust-grenzen.

In Zero Trust Architectuur is het doel keuzes vastleggen die teams consistent en herhaalbaar kunnen uitvoeren.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Zero Trust Architectuur is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Principes van Zero Trust

Zero Trust rust op drie woorden die klinken als een mantra, maar in de praktijk een complete omwenteling van netwerkarchitectuur vereisen: never trust, always verify.

Concreet vertaalt dit zich naar drie pijlers:

De combinatie van deze drie bepaalt of een verzoek wordt toegestaan. Niet een ervan – alle drie. Een geauthenticeerde gebruiker op een besmet apparaat krijgt geen toegang. Een schoon apparaat met gestolen credentials krijgt geen toegang. Een geverifieerde gebruiker op een compliant apparaat die een resource probeert te bereiken die niet in zijn profiel past, krijgt geen toegang.

Traditioneel perimetermodel vs. Zero Trust

De fundamentele verschuiving is de aanname. Het perimetermodel gaat ervan uit dat de binnenkant veilig is. Zero Trust gaat ervan uit dat de binnenkant al gecompromitteerd is en ontwerpt elke controle alsof de aanvaller naast je zit. Dat klinkt paranoia. Elke penetratietest bewijst dat het realisme is.

Identity-Based Access

Identiteit is de nieuwe perimeter. In een Zero Trust-model bepaalt niet je netwerklocatie of je ergens bij kunt, maar wie je bent, hoe je je hebt geauthenticeerd, en of je huidige sessie verdacht gedrag vertoont.

Conditional Access

Conditional Access policies evalueren meerdere signalen voordat ze toegang verlenen:

Signalen:                    Beslissing:           Handhaving:

- Gebruiker/groep            ┐                     - Toegang verlenen
- Applicatie                 ├─→ IF/THEN regels ─→ - MFA vereisen
- Locatie (IP/land)          │                     - Toegang blokkeren
- Apparaat (compliant?)      │                     - Beperkte sessie
- Risicosignalen (AI)        ┘                     - Wachtwoord reset

Voorbeeld: Azure Conditional Access policy

{
  "displayName": "Require MFA for all users except trusted locations",
  "conditions": {
    "users": {
      "includeUsers": ["All"]
    },
    "applications": {
      "includeApplications": ["All"]
    },
    "locations": {
      "excludeLocations": ["AllTrusted"]
    },
    "signInRiskLevels": ["low", "medium", "high"],
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa", "compliantDevice"]
  },
  "sessionControls": {
    "signInFrequency": {
      "value": 4,
      "type": "hours"
    }
  }
}

Risico-gebaseerde authenticatie

Statische regels (“altijd MFA”) zijn een begin, maar slimme aanvallers omzeilen MFA via token theft, MFA fatigue of social engineering. Risico-gebaseerde authenticatie past het niveau van verificatie dynamisch aan:

Dit vereist een identity provider die deze signalen kan evalueren. Entra ID, Okta en Google Workspace bieden dit. On-premises Active Directory alleen niet – een extra reden om identity naar de cloud te tillen, zelfs als de rest van de infrastructuur on-premises blijft.

Microsegmentatie

VLANs zijn een goed begin (zie hoofdstuk 15), maar ze segmenteren op netwerkniveau. Twee servers in hetzelfde VLAN kunnen vrij met elkaar communiceren. Microsegmentatie gaat verder: segmentatie op workload-niveau. Elke server, elke container, elke applicatie heeft zijn eigen beveiligingsperimeter.

Het verschil is als volgt. Traditionele segmentatie is een flatgebouw met beveiligde buitendeuren maar open gangen. Microsegmentatie is een flatgebouw waar elke individuele deur op slot zit.

Tools voor microsegmentatie

Voorbeeld: Calico NetworkPolicy

# Sta alleen verkeer toe van de frontend naar de backend API
# Blokkeer al het andere verkeer naar de backend
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: backend-api-policy
  namespace: productie
spec:
  selector: app == 'backend-api'
  types:
    - Ingress
    - Egress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: app == 'frontend'
      destination:
        ports:
          - 8443
    - action: Deny
  egress:
    - action: Allow
      protocol: TCP
      destination:
        selector: app == 'database'
        ports:
          - 5432
    - action: Allow
      protocol: UDP
      destination:
        nets:
          - 10.0.30.53/32    # Interne DNS
        ports:
          - 53
    - action: Deny

Voorbeeld: nftables microsegmentatie per host

#!/usr/sbin/nft -f
# Webserver: sta alleen HTTP/HTTPS in en database outbound toe
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif "lo" accept
        ct state established,related accept
        tcp dport { 80, 443 } accept
        ip saddr 10.0.30.0/24 tcp dport 22 accept  # SSH alleen van management
        log prefix "nft-drop-web-in: " counter drop
    }
    chain output {
        type filter hook output priority 0; policy drop;
        oif "lo" accept
        ct state established,related accept
        ip daddr 10.0.20.5 tcp dport 5432 accept    # Alleen naar database
        ip daddr 10.0.30.53 udp dport 53 accept     # DNS
        ip daddr 10.0.30.123 udp dport 123 accept   # NTP
        log prefix "nft-drop-web-out: " counter drop
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

Microsegmentatie is werk. Veel werk. Je moet weten welke applicatie met welke andere applicatie praat, op welke poorten, in welke richting. Maar het is precies dit werk dat het verschil maakt wanneer een aanvaller voet aan wal krijgt. In een plat netwerk is een gecompromitteerde webserver een springplank naar alles. In een microsegmenteerd netwerk is een gecompromitteerde webserver een doodlopende straat.

Device Trust

Een sterk geauthenticeerde gebruiker op een besmet apparaat is als een bankmedewerker die met de juiste badge het gebouw binnenkomt, maar een tas vol inbrekerswerktuig bij zich draagt. De badge klopt. De intentie niet.

Device trust verifieert dat het apparaat zelf betrouwbaar is:

Intune compliance policy (voorbeeld)

{
  "displayName": "Werkstation compliance policy",
  "platform": "windows10",
  "settings": {
    "bitLockerEnabled": true,
    "secureBootEnabled": true,
    "codeIntegrityEnabled": true,
    "osMinimumVersion": "10.0.22631",
    "passwordRequired": true,
    "firewallEnabled": true,
    "antivirusRequired": true,
    "antiSpywareRequired": true,
    "defenderEnabled": true,
    "defenderVersion": "current-1"
  },
  "scheduledActionsForRule": [{
    "ruleName": "deviceComplianceNeeded",
    "scheduledActionConfigurations": [{
      "actionType": "block",
      "gracePeriodHours": 24
    }, {
      "actionType": "notification",
      "gracePeriodHours": 0
    }]
  }]
}

Een apparaat dat niet compliant is, krijgt geen toegang tot bedrijfsresources. Niet “beperkte toegang.” Geen toegang. De gebruiker krijgt een melding, lost het probleem op (update installeren, encryptie aanzetten), en probeert opnieuw. Dat is de consequentie die het model laat werken.

Zero Trust Network Access (ZTNA)

VPN is het symbool van het perimetermodel: authenticeer een keer, krijg toegang tot het hele netwerk. ZTNA is de vervanging: authenticeer per applicatie, krijg alleen toegang tot die ene applicatie.

Het verschil is fundamenteel:

Populaire ZTNA-oplossingen

Voorbeeld: Cloudflare Access configuratie

# Cloudflare Access policy voor interne wiki
application:
  name: "Interne Wiki"
  domain: "wiki.intern.example.com"
  type: "self_hosted"

  policies:
    - name: "Medewerkers met compliant apparaat"
      decision: "allow"
      include:
        - email_domain: "example.com"
      require:
        - device_posture:
            integration_id: "intune-compliance"
            checks:
              - type: "disk_encryption"
                enabled: true
              - type: "os_version"
                operator: ">="
                version: "10.0.22631"
              - type: "firewall"
                enabled: true

  # Geen directe netwerktoegang -- alleen deze applicatie
  # Alle verzoeken worden gelogd
  # Sessie verloopt na 8 uur
  session_duration: "8h"

# Cloudflare Tunnel opzetten (vervangt port forwarding)
cloudflared tunnel create intern-wiki
cloudflared tunnel route dns intern-wiki wiki.intern.example.com

# config.yml voor cloudflared
# tunnel: <tunnel-id>
# credentials-file: /root/.cloudflared/<tunnel-id>.json
# ingress:
#   - hostname: wiki.intern.example.com
#     service: http://localhost:8080
#   - service: http_status:404

Het mooie van ZTNA is dat de interne applicatie nergens bereikbaar is vanuit het internet. Er is geen open poort. Er is geen IP-adres om te scannen. De tunnel gaat vanuit de applicatie naar de ZTNA-provider. Een aanvaller die het netwerk scant, ziet niets. Letterlijk niets.

Data-Centric Security

Zero Trust beschermt niet alleen de toegang tot data, maar de data zelf. Zelfs als een aanvaller door alle controles heen breekt, moeten de data onbruikbaar zijn.

Classificatie

Voordat je data kunt beschermen, moet je weten welke data je hebt en hoe gevoelig die is:

Data Loss Prevention (DLP)

DLP voorkomt dat gevoelige data de organisatie verlaat via ongeautoriseerde kanalen:

• Endpoint DLP: blokkeert kopieren naar USB, print, clipboard van gerubriceerde documenten
• Network DLP: scant uitgaand verkeer op patronen (BSN-nummers, creditcardnummers, broncode)
• Cloud DLP: scant uploads naar cloud storage, SaaS-applicaties

Encryptie in drie lagen

Encryptie in rust en in transit zijn baseline – niet optioneel. Elke database, elke schijf, elke verbinding. Encryptie in gebruik is de volgende grens, relevant voor organisaties die gevoelige data verwerken in cloud-omgevingen waar ze de hypervisor niet vertrouwen (en in een Zero Trust-model vertrouw je niets).

Implementatiestrategie

Zero Trust implementeer je niet in een weekend. Het is een meerjarig programma. Maar je hoeft niet alles tegelijk te doen. Begin met wat het meeste impact heeft en bouw daarop voort.

Fasering

Fase 1: Identity (maanden 1-3)
├── MFA voor alle gebruikers (niet alleen admins)
├── Conditional Access policies
├── SSO voor alle applicaties
└── Privileged Access Management (PAM)

Fase 2: Device (maanden 3-6)
├── MDM enrollment voor alle endpoints
├── Compliance policies (encryptie, patching, EDR)
├── Device-based Conditional Access
└── Certificaat-gebaseerde authenticatie

Fase 3: Network (maanden 6-12)
├── Microsegmentatie van kritieke assets (zie hoofdstuk 15)
├── ZTNA voor externe toegang (VPN uitfaseren)
├── DNS-filtering en threat protection
└── Network monitoring en logging

Fase 4: Data (maanden 12-18)
├── Data classificatie
├── DLP policies
├── Encryptie at rest overal
└── Monitoring van data-toegang en -export

Quick wins

Niet alles hoeft een project te zijn. Deze maatregelen kun je deze week implementeren en ze leveren direct resultaat:

Wat niet te doen

• Alles tegelijk – Zero Trust is geen big bang. Begin met identity, want dat levert het snelste resultaat.
• Producten kopen voor je een strategie hebt – elk beveiligingsbedrijf verkoopt nu “Zero Trust.” Sommige daarvan zijn gewoon een firewall met een nieuw label.
• VPN van de ene op de andere dag uitzetten – migreer applicatie voor applicatie naar ZTNA, test, en schakel pas de VPN uit als alles werkt.
• Vergeten dat mensen ermee moeten werken – als Zero Trust de gebruikerservaring vernietigt, vinden gebruikers workarounds. En workarounds zijn het tegenovergestelde van beveiliging.

Samenvatting

Zero Trust is geen product, geen appliance, geen checkbox. Het is een architectuurprincipe dat ervan uitgaat dat de aanvaller al binnen is en elke controle dienovereenkomstig ontwerpt:

1. Never trust, always verify – authenticeer elke gebruiker, elk apparaat, elk verzoek. Netwerklocatie is geen bewijs van vertrouwen
2. Identity is de nieuwe perimeter – Conditional Access, MFA, risico-gebaseerde authenticatie. Bescherm credentials als kroonjuwelen (zie hoofdstuk 7)
3. Device trust – een geauthenticeerde gebruiker op een besmet apparaat is geen vertrouwde gebruiker. MDM compliance, health attestation, EDR-status
4. Microsegmentatie – ga voorbij VLANs. Segmenteer per workload, per applicatie. Zie hoofdstuk 15 voor de basis
5. ZTNA vervangt VPN – per-applicatie toegang in plaats van netwerktoegang. Geen open poorten, geen aanvalsoppervlak
6. Bescherm de data, niet alleen de toegang – classificatie, DLP, encryptie in alle drie de lagen
7. Begin met identity – MFA en Conditional Access zijn de hoogste impact met de laagste inspanning. Bouw van daaruit verder

John Kindervag had in 2010 gelijk. Google had in 2014 gelijk. Het concept is niet nieuw. De technologie is niet nieuw. Het enige dat nieuw is, is de urgentie – want de aanvallers hebben het perimetermodel allang begrepen. Ze rekenen erop.

Vorige: Hoofdstuk 18 – Vulnerability Management & Patchbeleid Volgende: Hoofdstuk 20 – …