Communicatiebeveiliging (NEN 7512)

Versie 1.0.0 - maart 2026

Dit document beschrijft de maatregelen voor veilige elektronische communicatie binnen Remedice, conform NEN 7512 (Vertrouwde elektronische communicatie in de zorg).

1. Transport Layer Security

Aspect	Specificatie
Protocol	TLS 1.2 en hoger (ALB-policy ondersteunt TLS 1.2 en 1.3)
Certificaten	Beheerd via AWS Certificate Manager
HSTS	Strict-Transport-Security header actief
Cipher suites	Sterke suites (AES-256-GCM, ECDHE key exchange)

Alle communicatie tussen client (frontend-applicatie) en server (backend-API) vindt plaats over HTTPS. Onversleutelde HTTP-verbindingen worden niet geaccepteerd.

2. API-beveiliging

2.1 Authenticatie

Alle API-endpoints vereisen een geldig JWT-token (behalve publieke endpoints zoals login en registratie)
JWT-tokens worden ondertekend met een geheim dat per omgeving is geconfigureerd
Token-verificatie bij elk request via Django REST Framework Simple JWT

Productie: alleen expliciete origins toegestaan (via CORS_ALLOWED_ORIGINS)
Ontwikkeling: configureerbaar, standaard restrictief
Credentials worden alleen meegestuurd naar toegestane origins

2.3 CSRF (Cross-Site Request Forgery)

Django CsrfViewMiddleware is actief
CSRF-tokens vereist voor state-changing requests (POST, PUT, DELETE)

2.4 Inputvalidatie

Server-side validatie via Django REST Framework Serializers
Geparametriseerde database-queries via Django ORM (geen raw SQL)
Content-type validation op uploads (PDF, tekst)

3. Data-uitwisseling met apotheekinformatiesystemen

3.1 Import

Remedice ontvangt medicatiegegevens via:

Tekst-upload: Gebruiker kopieert tekst uit AIS (Medimo) en plakt in Remedice
PDF-upload: Gebruiker uploadt PDF-export uit AIS (Pharmacom, Sanday) of HIS (Promedico)

Er is geen directe koppeling (HL7, FHIR, of andere integratie) met apotheekinformatiesystemen. Alle data-invoer is handmatig geinitieerd door de gebruiker. Deze handmatige import is geen elektronische gegevensuitwisseling tussen beveiligingsdomeinen in de zin van NEN 7512; de norm wordt pas volledig van toepassing zodra een systeemkoppeling live gaat (zie hoofdstuk 8).

3.2 Beveiliging bij upload

Uploads worden verwerkt in het geheugen en niet persistent opgeslagen als ruwe bestanden
Parsers valideren het formaat en de structuur van de invoer (fingerprint-validatie)
Geparste gegevens worden versleuteld opgeslagen in de database

4. Server-Sent Events (SSE)

Atlas Chat gebruikt Server-Sent Events voor streaming van AI-antwoorden:

Verbinding via HTTPS (TLS)
Authenticatie via JWT-token in de request
Token-limiet per 24 uur per tenant

5. Pushnotificaties

Kanaal	Protocol	Beveiliging
Mobiel (iOS/Android)	Expo Push Service	Device-specifieke push-tokens, HTTPS
Web (browser)	Web Push (VAPID)	VAPID-sleutelpaar, HTTPS, browser-specifieke tokens

Pushnotificaties bevatten minimale informatie (notificatietekst). Gevoelige gegevens worden niet in pushberichten opgenomen.

6. Communicatie met subverwerkers

Subverwerker	Protocol	Authenticatie
AWS (S3, KMS, CloudWatch, Bedrock, Transcribe)	HTTPS (AWS SDK)	IAM credentials, STS tokens
Google Cloud (Cloud Text-to-Speech, Chirp 3 HD)	HTTPS (Google Cloud SDK)	Service account credentials
Stripe	HTTPS (Stripe SDK)	Secret key
Sentry	HTTPS (Sentry SDK)	DSN-token

Alle API-sleutels worden opgeslagen als omgevingsvariabelen en niet in broncode.

7. Interne communicatie (backend)

Component	Protocol
Applicatie <-> Database (PostgreSQL)	TCP met TLS, afgedwongen (`rds.force_ssl=1`, `sslmode=require`)
Applicatie <-> Cache (Redis)	TCP met transit-encryptie ingeschakeld (`transit_encryption_enabled`), intern netwerk, niet publiek bereikbaar
Applicatie <-> Celery Worker	Redis als broker (intern netwerk)

In de productieomgeving communiceren alle services binnen een beveiligd netwerk (Docker network / VPC). Geen van deze services is rechtstreeks bereikbaar via het publieke internet.

8. Koppelvlakkenbeleid (NEN 7512-readiness)

Remedice wisselt op dit moment geen persoonlijke gezondheidsinformatie uit met externe zorgsystemen via systeemkoppelingen. Dit hoofdstuk legt vast aan welke eisen elke toekomstige koppeling (AIS/HIS-API, LSP/AORTA, FHIR-endpoints, e-recept) moet voldoen voordat deze live gaat, conform NEN 7512:2022.

8.1 Risicoclassificatie per uitwisseling

Voor elke nieuwe uitwisseling wordt voor livegang een risicoclassificatie vastgelegd:

Classificeer de uitwisseling op de gevolgen van schending van vertrouwelijkheid, integriteit en beschikbaarheid, volgens de risicoklassen van NEN 7512.
Uitwisseling van identificeerbare gezondheidsgegevens valt in de hoogste risicoklassen en vereist maatregelen op alle drie de aspecten.
De classificatie en de gekozen maatregelen worden vastgelegd in de risicoanalyse (zie Risicoanalyse) en per koppeling gedocumenteerd.

8.2 Vertrouwensniveaus voor authenticatie

Personen: voor toegang tot uitgewisselde gezondheidsgegevens geldt betrouwbaarheidsniveau hoog (eIDAS "hoog"). In de Nederlandse zorg betekent dit in de praktijk een UZI-middel of een door VZVZ erkend alternatief (zoals ZORG-ID met UZI-identiteit). De bestaande optionele ZORG-ID-koppeling levert hiervoor de UZI-identiteitsbinding.
Systemen: wederzijdse systeemauthenticatie met PKIoverheid-servercertificaten (UZI-servercertificaat waar het zorgdomein dat vereist), mutual TLS in de meest recente door het NCSC als "goed" beoordeelde versie, en sterke encryptie (minimaal AES-256 of gelijkwaardig).

8.3 Wederzijdse afspraken

Met elke uitwisselpartner worden voor livegang schriftelijke afspraken gemaakt over:

de risicoclassificatie van de uitwisseling en de vereiste vertrouwensniveaus per aspect;
encryptiemethoden, certificaat- en sleutelbeheer (uitgifte, intrekking, rotatie);
logging van uitwisselingsgebeurtenissen aan beide zijden (NEN 7513, tabel 3), inclusief bewaartermijnen, zodat de logging over domeinen heen navolgbaar blijft;
beschikbaarheid, incidentmelding en beeindiging van de koppeling.

8.4 Aanvullende voorwaarden per koppeltype

LSP/AORTA: aansluiting volgt de aansluitvoorwaarden van VZVZ, inclusief een goed beheerd zorgsysteem (GBZ)-toets en UZI-middelen.
Wegiz-aangewezen uitwisselingen: zodra een AMvB een NEN-norm voor een specifieke gegevensuitwisseling verplicht stelt (bijvoorbeeld NEN 7503 voor het voorschrijven en ter hand stellen van medicatie), wordt conformiteit met die norm onderdeel van de koppelingseisen.
Onafhankelijke beoordeling: Begz artikel 3 lid 4 vereist ten minste vijfjaarlijkse onafhankelijke beoordeling van de naleving van de NEN 7510-reeks en NEN 7512; een nieuwe koppeling wordt in de eerstvolgende beoordeling meegenomen.