Security hardening: wat het is, met checklist

Security hardening: checklist per laag

Security hardening betekent dat je een systeem zo inricht dat er minder aan te vallen valt. Je zet uit wat je niet gebruikt, je geeft zo min mogelijk rechten en je legt vast wat er gebeurt. Cloud security hardening is hetzelfde, toegepast op servers, containers en diensten in de cloud. Daar horen ook de instellingen van je cloudomgeving zelf bij.

Deze checklist loopt de lagen af, van de server tot de gebruiker. Elk punt is een actie die je kunt controleren. De punten volgen gangbare baselines zoals de CIS Benchmarks. Het is een hulpmiddel, geen certificering, en geen beschrijving van wat Noveu allemaal heeft ingevoerd. Waar Noveu zelf staat, lees je onderaan.

Zo gebruik je deze checklist

Kies één systeem of dienst per keer.
Loop de lagen hieronder af en noteer per punt: gedaan, niet van toepassing of nog open.
Leg bij elk punt dat gedaan is vast hoe je het controleert. De auditor vraagt altijd naar het bewijs.
Plan de open punten in, met een eigenaar en een datum.

De lagen in één oogopslag

Netwerkrand: DDoS-bescherming, WAF en rate limiting.
Netwerk: segmentatie, firewall en zero trust.
Server: minimale installatie, updates en kernelinstellingen.
Containers: geen root, alleen-lezen en limieten.
Applicatie en API: veilige ontwikkeling en toegangscontrole.
Data: versleuteling, back-ups en sleutelbeheer.
Identiteit: MFA, rechten en wachtwoordbeleid.
Monitoring: logging en alarmen.

Server en besturingssysteem

Checklist voor Linux-servers

Installeer alleen de pakketten die je nodig hebt en verwijder de rest.
Zet automatische beveiligingsupdates aan, of plan ze vast in.
Zet SELinux of AppArmor in de enforcing-modus.
Stel de kernelparameters hieronder in.
Zet UEFI Secure Boot aan waar de hardware het ondersteunt.
Versleutel datavolumes, bijvoorbeeld met LUKS.
Sta SSH alleen toe met sleutels, niet met wachtwoorden en niet als root.

Kernelinstellingen (sysctl)

# /etc/sysctl.d/99-security.conf

# Netwerk
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0

# Kernel
kernel.randomize_va_space = 2
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2

Containers en Kubernetes

Checklist voor containers

Draai containers als gewone gebruiker, niet als root.
Maak het bestandssysteem van de container alleen-lezen waar dat kan.
Geef elke container een limiet voor CPU en geheugen.
Scan images op kwetsbaarheden bij elke build.
Beperk het verkeer tussen pods met network policies.
Houd het gedrag tijdens het draaien in de gaten, bijvoorbeeld met Falco.

Voorbeeld: Pod Security Standards (restricted)

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Netwerk

Checklist voor het netwerk

Deel het netwerk op in zones: rand, applicatie, data en beheer.
Weiger standaard alles en sta alleen expliciet toe wat nodig is.
Laat beheer, zoals SSH, alleen via een beheerzone of jumphost lopen.
Zet een WAF en rate limiting voor diensten die op internet staan.

Zones en toegang

Zone	Inhoud	Toegang vanaf
Rand (DMZ)	Load balancers, WAF	Internet
Applicatie	Applicatieservers	Alleen de rand
Data	Databases, opslag	Alleen de applicatiezone
Beheer	Monitoring, logging	Alleen jumphosts

Zero trust in het kort

Controleer elk verzoek, ook van binnen het netwerk.
Geef elke gebruiker en dienst zo min mogelijk rechten.
Ga ervan uit dat er al iemand binnen is: segmenteer en monitor.

Applicatie en API

Checklist voor veilige ontwikkeling

Scan elke commit op geheimen, bijvoorbeeld met Gitleaks.
Draai statische analyse (SAST) bij elke build.
Scan containerimages, bijvoorbeeld met Trivy, voordat je uitrolt.
Test de draaiende applicatie met DAST, bijvoorbeeld met OWASP ZAP.

Checklist voor API's

Authenticeer met OAuth 2.0 of OIDC.
Autoriseer met rollen en scopes.
Zet rate limiting per client en per endpoint.
Controleer invoer tegen een schema.
Log verzoeken zo dat je ze kunt terugvinden, zonder gevoelige inhoud.

Veelvoorkomende kwetsbaarheden en wat helpt

Kwetsbaarheid (OWASP)	Wat helpt
Injectie	Geparametriseerde queries, een ORM
Zwakke authenticatie	MFA, goed sessiebeheer
Blootgestelde gevoelige data	Versleuteling, maskeren
Kapotte toegangscontrole	Rollen, minimale rechten
Verkeerde configuratie	Vaste baselines, scannen
XSS	Output encoding, CSP
Kwetsbare onderdelen	Afhankelijkheden scannen
Te weinig logging	Auditlogs op de juiste plekken

Data en versleuteling

Checklist voor data

Versleutel verkeer met TLS 1.2 of hoger, bij voorkeur TLS 1.3, en zet HSTS aan.
Versleutel data in rust: volumes, databases en back-ups.
Test het terugzetten van back-ups, niet alleen het maken ervan.
Bewaar sleutels apart van de data die ze beschermen.
Leg vast wie bij de sleutels kan en vervang ze volgens een vast schema.

Voorbeeld: TLS-configuratie (nginx)

ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

# HSTS
add_header Strict-Transport-Security "max-age=63072000" always;

Identiteit en toegang

Checklist voor accounts

Maak MFA verplicht, in elk geval voor beheeraccounts.
Kies passkeys of hardwaresleutels (WebAuthn, FIDO2) boven codes per sms.
Laat inloggen waar het kan via één centrale identiteitsdienst lopen (met OIDC), zodat je een account op één plek intrekt.
Geef serviceaccounts een certificaat of een sleutel die snel verloopt.
Vraag wachtwoorden van minimaal 14 tekens en blokkeer na een paar mislukte pogingen.

Monitoring en logging

Checklist voor logging

Log aanmeldingen, wijzigingen in rechten en beheeracties.
Bepaal per soort log hoe lang je hem bewaart en leg dat vast.
Stuur logs naar een plek waar een aanvaller ze niet kan wissen.

Alarmen die je minimaal wilt

Alarm	Ernst	Wat je doet
Veel mislukte aanmeldingen	Middel	Bekijken, zo nodig account blokkeren
Iemand krijgt meer rechten	Hoog	Direct uitzoeken
Ongewone toegang tot data	Hoog	Bij de gebruiker navragen
Wijziging in configuratie	Laag	Vastleggen in het audittrail
Malware gevonden	Kritiek	Systeem isoleren

Wat cloud security hardening extra vraagt

In de cloud beheer je niet alleen je eigen servers, maar ook de omgeving eromheen. Die laag wordt vaak vergeten.

Zet de beheeraccounts van je cloudomgeving achter MFA en gebruik ze niet voor dagelijks werk.
Controleer de standaardinstellingen: publieke opslag, open poorten en te brede rollen.
Kijk waar je gegevens en back-ups fysiek staan en onder welk recht je aanbieder valt.
Houd bij welke sub-verwerkers en diensten bij je data kunnen.

Dat laatste raakt aan soevereiniteit. Lees wat een soevereine cloud in de EU anders doet dan een EU-regio van een Amerikaanse aanbieder.

Waar Noveu staat

Noveu is niet ISO 27001-, NEN 7510- of NTA 7516-gecertificeerd. De checklist hierboven beschrijft gangbare maatregelen, niet wat bij ons allemaal is ingevoerd. Dit leggen we wel publiek vast, in de verwerkersovereenkomst en op de sub-verwerkerslijst:

Je gegevens en back-ups staan in Duitsland, in een Hetzner-datacenter in Falkenstein. Versleuteling van back-ups en opslag at rest wordt ingevoerd (gepland oktober 2026).
Extern verkeer gaat over TLS 1.2 of hoger, met HSTS.
MFA (TOTP) is verplicht voor alle beheer- en adminaccounts.
Schijven, databases en objectopslag zijn vandaag nog niet versleuteld at rest; dat komt met dezelfde invoering.
De API-gateway doet rate limiting en controleert invoer.

Hoe we beveiliging verder aanpakken, lees je op de beveiligingspagina.

Laatste update: 29 september 2026. Herschreven als checklist per laag; alleen maatregelen met een publieke bron staan bij Noveu.

Security hardening: wat het is, met een checklist per laag