Cyber Security Academy · Les

Vaults en secret stores

Secrets centraliseren met tools zoals Vault

Les 2 van 413 stappen

Vaults en secret stores is een gratis Cyber Security Academy-les op CoddyKit. Dit is les 2 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Cyber Security Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Cyber Security Academy bevat in totaal 4 lessen.

Wat een geheimenopslag oplost

Een geheimenopslag (of kluis) is een gecentraliseerde, sterk beveiligde dienst met als enige taak de opslag, controle en registratie van toegang tot geheimen. Deze vervangt de verspreide bestanden en omgevingsvariabelen die geheimen zich laten verspreiden.

Een goede geheimenbeheerder biedt vier essentiële mogelijkheden:

Gecentraliseerde opslag: één betrouwbare bron.
Toegangscontrole: fijnmazig beleid over wie en wat elk geheim mag lezen.
Auditlogboekregistratie: een registratie van elke toegang voor de afhandeling van incidenten.
Versleuteling: geheimen worden versleuteld tijdens opslag en overdracht.

Voorbeelden zijn HashiCorp Vault, AWS Secrets Manager, Azure Key Vault en GCP Secret Manager.

Hoe HashiCorp Vault is opgebouwd

HashiCorp Vault is een populaire geheimenbeheerder met open broncode. De functionaliteit is georganiseerd in inplugbare secrets engines die aan paden worden gekoppeld.

KV engine: slaat statische sleutel-waardegeheimen op.
Database engine: genereert dynamische, kortlevende DB-toegangsgegevens.
PKI engine: geeft TLS-certificaten op aanvraag uit.
Transit engine: biedt versleuteling als dienst zonder sleutels bloot te geven.

Je communiceert met Vault via een HTTP-API of de CLI. Elk pad valt onder beleid dat bepaalt wie daar mag lezen of schrijven.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

Het model voor verzegelen en ontgrendelen

Vault beschermt zijn gegevens met een mechanisme voor verzegelen/ontgrendelen. Wanneer Vault start, is het verzegeld: het weet waar de versleutelde gegevens staan, maar kan ze niet ontsleutelen.

De hoofdsleutel die de opslag ontsleutelt, is zelf versleuteld met een ontgrendelsleutel. Met Shamir's Secret Sharing wordt die ontgrendelsleutel opgesplitst in meerdere fragmenten die aan verschillende beheerders worden uitgedeeld.

Er moet een configureerbare drempel (bijvoorbeeld 3 van 5 fragmenten) worden aangeleverd om de sleutel opnieuw samen te stellen en Vault te ontgrendelen. Niemand kan het systeem alleen ontgrendelen, wat bescherming biedt tegen een inbreuk door een interne aanvaller.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Authenticatie: wie ben je?

Voordat een client een geheim kan lezen, moet deze zich authenticeren om een token te krijgen. Vault ondersteunt veel verschillende authenticatiemethoden, afgestemd op verschillende identiteiten:

AppRole voor applicaties en CI-systemen (role ID + secret ID).
Kubernetes gebruikt het token van het serviceaccount van de pod.
AWS/GCP/Azure IAM vertrouwt op de identiteit van het cloudplatform.
OIDC/LDAP voor menselijke gebruikers via SSO.

Het belangrijkste principe: de identiteit komt van het platform, niet van een wachtwoord met een lange levensduur. Een Kubernetes-pod bewijst wie hij is met zijn eigen serviceaccounttoken; er is geen initieel geheim dat kan uitlekken.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Autorisatie met beleid

Authenticatie bewijst de identiteit; beleid bepaalt wat die identiteit mag doen. Vault-beleid wordt geschreven in HCL en volgt het principe van minimale rechten: het verleent alleen toegang tot de paden en mogelijkheden die een werklast nodig heeft.

Met dit beleid kan een dienst alleen zijn eigen databasegeheim lezen en niets anders:

Mogelijkheden komen overeen met API-acties: read, create, update, delete en list. Weiger standaard; ken rechten expliciet toe.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Cloudgebaseerde geheimenopslagen

Als je in één cloud draait, neemt de beheerde opslag van de provider een operationele last weg: geen verzegelen of ontgrendelen en geen servers die je moet bijwerken:

AWS Secrets Manager integreert met IAM en ondersteunt ingebouwde Lambda-functies voor rotatie.
Azure Key Vault slaat geheimen, sleutels en certificaten op met RBAC.
GCP Secret Manager biedt geheimen met versies, afgeschermd door IAM-koppelingen.

Toegang wordt geregeld door de IAM van de cloud, zodat een werklast een geheim met zijn bestaande rol kan lezen; er is geen afzonderlijk wachtwoord nodig. De afweging is afhankelijkheid van de leverancier en mindere ondersteuning voor meerdere clouds vergeleken met Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Versleuteling als dienst

Soms wil je een geheim helemaal niet opslaan: je wilt applicatiegegevens versleutelen zonder dat je applicatie ooit de versleutelingssleutel bezit. De Transit engine van Vault doet precies dat.

De applicatie stuurt leesbare tekst naar Vault, krijgt versleutelde tekst terug en ziet de sleutel nooit. Ontsleutelen werkt op dezelfde manier. Dit heet versleuteling als dienst.

Het voordeel: sleutels leven alleen in Vault, kunnen centraal worden geroteerd en een gecompromitteerde applicatie kan geen sleutel lekken die zij nooit heeft bezeten.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Geheimen in werklasten injecteren

Een kluis is alleen nuttig als applicaties geheimen kunnen gebruiken zonder het pad of token te hardcoderen. Veelgebruikte patronen voor injectie zijn:

Sidecar/agent: een Vault Agent draait naast de applicatie, authenticeert zich en schrijft geheimen naar een gedeeld volume in het geheugen.
CSI-driver: Kubernetes koppelt geheimen als bestanden via de Secrets Store CSI-driver.
Ophalen via SDK: de applicatie roept bij het opstarten rechtstreeks de API van de kluis aan.

Geef de voorkeur aan koppeling aan een bestandssysteem in het geheugen (tmpfs) boven omgevingsvariabelen en schrijf geheimen niet naar schijf, waar ze kunnen blijven bestaan.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Auditregistratie en verantwoording

Elke lees-, schrijf- en authenticatiegebeurtenis in een kluis hoort te worden vastgelegd in een auditlog. Daardoor kun je tijdens een incident verantwoorden dat je geheimenbeheer op orde is.

Auditlogs geven antwoord op de kritieke vragen: wie toegang had tot welk geheim, wanneer en vanaf waar. Vault hasht gevoelige waarden in logs, zodat het logboek zelf geen geheimen lekt.

Stuur auditlogs naar een afzonderlijk systeem waarin manipulatie aantoonbaar is (SIEM), zodat een aanvaller die de host van de kluis overneemt niet ook het bewijs kan wissen van wat die heeft ingezien.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

De kluis zelf beschermen

Een gecentraliseerde opslag concentreert het risico: als de kluis omvalt, valt alles om. Beveilig de kluis daarom als je belangrijkste bedrijfsmiddel:

Gebruik TLS op alle eindpunten; stel de API nooit onversleuteld bloot.
Houd de kluis op een privénetwerk achter strikte firewallregels.
Schakel automatisch ontgrendelen via een cloud-KMS in om handmatig shardbeheer te voorkomen, maar bescherm die KMS-sleutel zeer goed.
Gebruik korte TTL's voor tokens en verlengbare leases, zodat gestolen tokens snel verlopen.
Installeer updates snel en controleer auditlogs op afwijkingen.

De kluis ruilt veel faalpunten in voor één zeer goed beveiligd faalpunt.

De juiste opslag kiezen

Er bestaat geen universeel beste hulpmiddel; stem de opslag af op je omgeving:

Eén cloud, eenvoudige behoeften: gebruik de eigen beheerder van AWS/Azure/GCP voor zo weinig mogelijk operationeel beheer.
Meerdere clouds of lokaal: HashiCorp Vault biedt een consistente, overdraagbare abstractielaag.
Dynamische geheimen of versleuteling als dienst nodig: de geheimenmodules van Vault zijn het meest veelzijdig.
Veel Kubernetes: combineer een opslag met het CSI-stuurprogramma of een operator zoals External Secrets.

Wat je ook kiest, het doel is hetzelfde: één gecontroleerde bron van waarheid met toegangsbeheer, in plaats van verspreide geheimen in platte tekst.

Korte toets

Toets je begrip van het beschermingsmodel van Vault.

Beantwoord dit in de interactieve les

Samenvatting: kluizen en geheimenopslag

Je hebt geleerd hoe je verspreide geheimen vervangt door een gecentraliseerde opslag met controle.

Een geheimenopslag biedt gecentraliseerde opslag, toegangsbeheer, auditregistratie en versleuteling.
HashiCorp Vault gebruikt modulaire geheimenmodules en een verzegelings-/ontzegelingsmodel dat wordt beschermd door Shamir's Secret Sharing.
Authenticatiemethoden leiden de identiteit af van het platform (Kubernetes, IAM, AppRole), en beleidsregels dwingen minimale rechten af.
Cloud-native opslag ruilt overdraagbaarheid in voor weinig operationeel beheer.
De Transit-module biedt versleuteling als dienst, zodat apps nooit sleutels beheren.
Injecteer geheimen via agents of CSI in geheugenopslag, registreer elke toegang en beveilig de kluis als je belangrijkste bedrijfsmiddel.

Vervolgens maken we geheimen nog veiliger door ze dynamisch en kortlevend te genereren.

Gratis beginnen

Leer Cyber Security Academy met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 76
Lessen: 303

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Vaults en secret stores” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad Cyber Security Academy, waaronder “Vaults en secret stores”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Cyber Security Academy bevat in totaal 4 lessen.

Wat leer ik in “Vaults en secret stores”?

Secrets centraliseren met tools zoals Vault Je oefent met Cyber Security Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Cyber Security Academy te beginnen?

Ervaring vooraf is niet nodig. Cyber Security Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.

Hoe lang duurt de les “Vaults en secret stores”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Cyber Security Academy?

Ja. Elke les over Cyber Security Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

← Terug naar Cyber Security Academy