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.

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.