CompTIA SY0-701: Gegevensbeveiliging, Privacy & Cryptografie — Studiegids

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Onderdeel van de CompTIA Security+ SY0-701 — Studiegids. Oefen met geverifieerde antwoorden in het CompTIA-examencentrum, of doe getimede oefentests op ExamRoll.io.

Data is het uiteindelijke doelwit van de meeste aanvallen, en cryptografie is het primaire technische mechanisme om data te beschermen in transit (onderweg), at rest (in opslag) en in use (in gebruik). Het begrijpen van de eigenschappen, beperkingen en correcte toepassing van cryptografische primitieven is fundamenteel — niet alleen voor het examen, maar ook voor het ontwerpen van systemen die veilig blijven wanneer individuele controles falen.

Dataclassificatie en -verwerking

Dataclassificatie wijst gevoeligheidslabels toe die de vereisten voor de omgang met data bepalen. Overheidsframeworks gebruiken labels als Niet-geclassificeerd, Vertrouwelijk, Geheim en Zeer Geheim. Commerciële frameworks gebruiken doorgaans Publiek, Intern, Vertrouwelijk en Beperkt (of equivalenten). Classificatie moet worden gedreven door de gevoeligheid van de data en wettelijke verplichtingen, niet door gemak.

Data Loss Prevention (DLP)-systemen handhaven het beleid voor dataverwerking door content te inspecteren op endpoints, netwerk-egress-punten en in cloudopslag. Een DLP-regel kan bijvoorbeeld e-mailbijlagen blokkeren die 16-cijferige reeksen bevatten die overeenkomen met creditcardpatronen, of een waarschuwing geven wanneer een gebruiker een bestand met de zin “overnamedoelwit” uploadt naar een persoonlijke cloudopslagdienst. De effectiviteit van DLP hangt af van een nauwkeurige classificatie — als gevoelige data niet is gelabeld, kan DLP deze niet beschermen.

Datasoevereiniteit betreft de fysieke locatie van data en de wetten van de jurisdictie die van toepassing zijn. De GDPR vereist dat persoonsgegevens van de EU die buiten de EU worden overgedragen, worden beschermd door adequaatheidsbesluiten, Standard Contractual Clauses (SCC’s) of Binding Corporate Rules (BCR’s). Organisaties die wereldwijd opereren, moeten datastromen in kaart brengen en ervoor zorgen dat opslag- en verwerkingslocaties voldoen aan de toepasselijke regelgeving.

Encryptie in Transit en at Rest

TLS 1.3 is de huidige standaard voor het versleutelen van data in transit. Het elimineert zwakke cipher suites, vereist forward secrecy (efemere Diffie-Hellman-sleuteluitwisseling) en reduceert de handshake tot één round trip. TLS 1.0 en 1.1 zijn verouderd; TLS 1.2 blijft acceptabel, maar moet worden geconfigureerd met sterke cipher suites. Een Nginx-configuratie die de huidige standaarden afdwingt:

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

Encryptie at rest beschermt data op opslagmedia. Volledige schijfversleuteling (BitLocker, FileVault, LUKS) versleutelt het hele volume; versleuteling op bestandsniveau (EFS, VeraCrypt-containers) versleutelt individuele bestanden. Versleuteling op databaseniveau (Transparent Data Encryption in SQL Server en Oracle) versleutelt databestanden en back-ups. De kritieke nuance: encryptie at rest beschermt tegen fysieke diefstal van media, maar niet tegen een gecompromitteerde applicatie die de data al heeft ontsleuteld om deze te verwerken.

Cryptografische Primitieven

Symmetrische algoritmen (AES-128, AES-256, ChaCha20) gebruiken één gedeelde sleutel en zijn snel, geschikt voor grote hoeveelheden data (bulk data). Asymmetrische algoritmen (RSA, ECDSA, Ed25519, ECDH) gebruiken sleutelparen en maken sleuteluitwisseling, digitale handtekeningen en het koppelen van identiteiten mogelijk, maar zijn rekenkundig intensief. Hybride systemen — zoals TLS — gebruiken asymmetrische cryptografie om over een symmetrische sessiesleutel te onderhandelen en versleutelen vervolgens het bulkverkeer symmetrisch.

Hashing (SHA-256, SHA-3) is een eenrichtingsfunctie die een digest van een vaste lengte produceert. Hashes zijn geen encryptie: ze kunnen niet worden omgekeerd met een sleutel, omdat er geen sleutel is. Gezouten wachtwoordhashes (met bcrypt, scrypt, Argon2 of PBKDF2) voegen een willekeurige, per gebruiker unieke waarde (salt) toe om rainbow tables te verslaan. Hashes bieden integriteitsverificatie; HMAC combineert een hash met een geheime sleutel om zowel integriteit als authenticiteit te bieden.

Cipher modes zijn net zo belangrijk als het algoritme. AES in ECB-modus versleutelt elk blok onafhankelijk, wat identieke ciphertext oplevert voor identieke plaintext-blokken — een catastrofale eigenschap die datapatronen lekt. AES-GCM (Galois/Counter Mode) biedt zowel vertrouwelijkheid als integriteit in één enkele bewerking en is de standaard voor moderne protocollen. CBC-modus met de juiste padding en een HMAC is acceptabel, maar complexer om correct te implementeren.

Sleutelbeheer en -opslag

Cryptografie is slechts zo sterk als het sleutelbeheer. Sleutels moeten worden gegenereerd met sterke entropie, apart worden opgeslagen van de data die ze beschermen, volgens een schema worden geroteerd en worden vernietigd wanneer ze buiten gebruik worden gesteld. Hardware Security Modules (HSM’s) bieden fraudebestendige sleutelopslag en cryptografische acceleratie. Een Trusted Platform Module (TPM) is een chip op endpoints die sleutels opslaat die worden gebruikt door BitLocker en ‘measured boot’. Key escrow plaatst een kopie van sleutels bij een vertrouwde derde partij voor wettelijk toegestane recovery, terwijl key recovery agents bedrijven in staat stellen om data van werknemers te ontsleutelen wanneer dat nodig is. Cloud KMS-diensten (AWS KMS, Azure Key Vault, Google Cloud KMS) bieden ’envelope encryption’, waarbij een data encryption key (DEK) de data beschermt en zelf wordt versleuteld door een key encryption key (KEK) die in de HSM wordt bewaard.

Public Key Infrastructure

PKI koppelt identiteiten aan publieke sleutels via certificaten die worden uitgegeven door een Certificate Authority (CA). Een subordinate CA is gekoppeld aan een root CA, wiens certificaat vooraf moet worden vertrouwd. De levenscyclus van een certificaat begint met een Certificate Signing Request (CSR) die samen met een private key wordt gegenereerd:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

De CA valideert de aanvrager, ondertekent de CSR en geeft een X.509-certificaat uit. Intrekking (revocation) wordt gepubliceerd via Certificate Revocation Lists (CRL’s) — periodiek gedownloade lijsten van ingetrokken serienummers — of het Online Certificate Status Protocol (OCSP), dat per certificaat real-time queries beantwoordt. OCSP stapling stelt de server in staat om tijdens de TLS-handshake een recente, ondertekende status te presenteren, waardoor lookups van de client naar de CA worden vermeden. Certificaten verlopen en moeten worden vernieuwd; automatisering via ACME (Let’s Encrypt, interne ACME-servers) voorkomt uitval door verlopen certificaten.

Code Signing en Integriteitsvalidatie

Code signing gebruikt de private key van een ontwikkelaar om een softwareartefact te ondertekenen; ontvangers verifiëren de handtekening met het certificaat van de ontwikkelaar, wat zowel de integriteit als de herkomst bevestigt. Dit beschermt tegen manipulatie in de supply chain. Tools voor bestandsintegriteitsmonitoring (Tripwire, AIDE) en het publiceren van hashes (sha256sum-waarden naast downloads) detecteren op vergelijkbare wijze ongeautoriseerde wijzigingen, maar hashen alleen bewijst slechts dat het bestand overeenkomt met een waarde — het authenticeert niet wie die waarde heeft geproduceerd. Alleen een digitale handtekening, ondersteund door PKI, biedt zowel integriteit als onweerlegbaarheid.

Retentie, Sanering en Veilige Verwijdering

Retentiebeleid definieert hoe lang elke dataklasse bewaard moet worden en wanneer deze verwijderd moet worden. Regelgeving schrijft vaak zowel minima (financiële administratie voor zeven jaar) als maxima (persoonsgegevens niet langer bewaren dan nodig) voor. Back-ups zijn niet uitgezonderd: als een betrokkene gebruikmaakt van het recht op verwijdering, moet de organisatie een verdedigbaar proces hebben om die gegevens uit back-ups te verwijderen of om de technische beperkingen en compenserende maatregelen te documenteren. Legal holds hebben voorrang op het normale retentiebeleid en bevriezen gegevens tijdens een rechtszaak.

Wanneer media het einde van hun levensduur bereiken, moet de sanering overeenkomen met de gevoeligheid van de gegevens en de bestemming van het medium. NIST SP 800-88 definieert drie niveaus: Clear (logisch overschrijven, voldoende voor hergebruik binnen de organisatie), Purge (cryptografisch wissen, block erase of degaussing, voldoende voor hergebruik buiten de organisatie), en Destroy (vernietigen, desintegratie, verbranding, verpulvering). Cryptografisch wissen — het vernietigen van de encryptiesleutel zodat de ciphertext onherstelbaar wordt — is snel en effectief voor self-encrypting drives die een nieuwe bestemming krijgen. Degaussing maakt magnetische media onbruikbaar en werkt niet op SSD’s. Fysieke vernietiging is de enige gegarandeerde methode voor beschadigde media of de hoogste classificaties.

Praktijkscenario: Falend Sleutelbeheer Leidt tot een Datalek

Een SaaS-bedrijf versleutelde zijn klantendatabase met AES-256, maar bewaarde de encryptiesleutel in een plaintext configuratiebestand in dezelfde repository als de applicatiecode. Toen een ontwikkelaar per ongeluk de repository naar een openbaar GitHub-account pushte, ontdekte een geautomatiseerde bot die naar credentials scant de sleutel binnen 11 minuten. De aanvaller gebruikte de sleutel om een databaseback-up te ontsleutelen die was opgeslagen in een publiek toegankelijke S3-bucket (een afzonderlijke misconfiguratie). De versleuteling was technisch correct — AES-256 is niet te kraken met brute force — maar het sleutelbeheer was catastrofaal gebrekkig. Correct sleutelbeheer zou de sleutel hebben opgeslagen in een secrets manager (AWS Secrets Manager, HashiCorp Vault) met toegang beheerd door IAM-rollen, en nooit in broncode of configuratiebestanden.

← Cloud · Alle domeinen · Bedrijfscontinuïteit →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →