Informatiebeveiligingsbeleid (NEN 7510)
Versie 1.0.0 - juni 2026
Dit beleid beschrijft de technische en organisatorische maatregelen binnen Remedice om de vertrouwelijkheid, integriteit en beschikbaarheid (BIV) van gegevens te waarborgen, conform NEN 7510 (informatiebeveiliging in de zorg).
Dit document is de beheersmaatregelen-laag (NEN 7510-2). Het managementsysteem dat deze maatregelen aanstuurt, beoordeelt en verbetert is vastgelegd onder Managementsysteem (NEN 7510-1). De controlnummering hieronder volgt de structuur van NEN 7510-2:2024 (gebaseerd op ISO/IEC 27002:2022): A.5 organisatorisch, A.6 mensgericht, A.7 fysiek, A.8 technologisch.
Het beleid is vastgesteld en goedgekeurd door het topmanagement; de verantwoordelijke voor informatiebeveiliging is benoemd in Leiderschap & rollen.
1. Scope en doelstelling
Dit beleid is van toepassing op alle informatiesystemen, gegevens en processen die onderdeel zijn van de Remedice-dienstverlening. Het doel is het beschermen van patient- en gebruikersgegevens tegen ongeautoriseerde toegang, verlies, wijziging of onbeschikbaarheid.
2. BIV-classificatie
| Aspect | Classificatie | Toelichting |
|---|---|---|
| Vertrouwelijkheid | Hoog | Gezondheidsgegevens en persoonsgegevens |
| Integriteit | Hoog | Klinische analyses moeten correct zijn |
| Beschikbaarheid | Middel-Hoog | Niet spoedeisend, maar wel noodzakelijk voor dagelijkse zorgprocessen |
3. Technische maatregelen
3.1 Toegangsbeheer (A.5.15-A.5.18, A.8.2-A.8.5)
| Maatregel | Implementatie |
|---|---|
| Authenticatie | JWT-tokens (access: 30 min, refresh: 12 uur glijdend met absolute maximumduur van 7 dagen); web via HttpOnly cookies, native via expo-secure-store |
| Token-opslag (web) | HttpOnly cookies -- tokens worden nooit in localStorage of sessionStorage opgeslagen (XSS-bescherming) |
| Token-opslag (native) | expo-secure-store (iOS Keychain / Android Keystore, OS-versleuteld) |
| Tweefactorauthenticatie | Verplichte TOTP via authenticator-app voor alle gebruikers |
| Biometrische login | Optioneel, na initieel TOTP-setup, via trusted device-registratie |
| RBAC | Fijnmazig permissiemodel via HasPermissionCode, rollen per tenant |
| Least privilege | Gebruikers zien alleen gegevens waartoe zij geautoriseerd zijn |
| Rate limiting | Login: 10/min, TOTP: 5/min, wachtwoord wijzigen: 10/min, device registratie: 5/min |
| Brute-force-lockout | Account vergrendeld na 5 mislukte loginpogingen, gedurende 15 minuten |
| Sessie-expiratie | Automatisch na verlopen JWT; geen persistent sessions |
3.2 Versleuteling (A.8.24 - Gebruik van cryptografie)
| Type | Methode | Toelichting |
|---|---|---|
| Data in transit | TLS 1.2+ | Alle communicatie via HTTPS |
| Patientgegevens at rest | Fernet (AES-128-CBC + HMAC-SHA256) | Veldversleuteling op patient- en medewerkergegevens (naam, geboortedatum, telefoonnummer, medicatie, allergieeen) |
| Archieven | AWS KMS (AES-256-GCM) | Chat-langetermijnarchief, klinisch dossierarchief en backups |
| Wachtwoorden | PBKDF2 met SHA256 | Django standaard hasher, salt per wachtwoord |
| TOTP-secrets | Opgeslagen via django-otp | Beveiligd door database-versleuteling |
3.3 Tenant-isolatie (A.8.22 - Netwerksegmentatie, A.5.16 - Identiteitsbeheer)
- Elke apotheek heeft een eigen PostgreSQL-schema via django-tenants
- Cross-tenant queries zijn technisch niet mogelijk via de ORM
- Subverwerkerdata is per tenant gescheiden (CloudWatch logstreams, S3-paden)
3.4 Netwerk en infrastructuur (A.8.20-A.8.23 - Netwerkbeveiliging)
| Maatregel | Implementatie |
|---|---|
| Hosting | AWS eu-central-1 (Frankfurt), EU-regio |
| TLS-terminatie | ALB met TLS 1.2+ (ELBSecurityPolicy-TLS13-1-2-2021-06), ACM-certificaat, HTTP->HTTPS redirect |
| CORS | Productie: alleen expliciete origins toegestaan |
| CSRF | Django CsrfViewMiddleware actief |
| Admin-toegang | Niet-raadbaar admin-pad (ADMIN_URL) gecombineerd met verplichte TOTP; geen IP-allowlist |
| Container-isolatie | Docker met gescheiden services (web, worker, database, cache) |
3.4a Beveiligingsheaders en transportbeveiliging (A.8.20-A.8.23)
In productie worden de volgende HTTP-beveiligingsheaders afgedwongen (Django SecurityMiddleware + prod.py):
| Header | Waarde |
|---|---|
HSTS (Strict-Transport-Security) |
1 jaar, includeSubDomains, preload |
| Content-Security-Policy | default-src 'self', scripts/frames beperkt tot Stripe, frame-ancestors 'none', met CSP-report-endpoint |
X-Frame-Options |
DENY |
X-Content-Type-Options |
nosniff |
Referrer-Policy |
strict-origin-when-cross-origin |
SECURE_SSL_REDIRECT |
True (HTTP omgeleid naar HTTPS) |
Transport in transit is overal versleuteld: ALB-verkeer via TLS 1.2+, databaseverbindingen via rds.force_ssl=1 plus Django sslmode=require, en Redis/ElastiCache via rediss:// met transit_encryption_enabled. Op staging draait CSP in report-only-modus voor veilige iteratie.
3.5 Audit logging (NEN 7513, A.8.15-A.8.16)
- 60+ beveiligingsgebeurtenissen worden gelogd naar AWS CloudWatch
- Per-tenant logstreams met datum-partitionering
- Opslag via CloudWatch Logs met IAM-restrictie (write-only voor applicatie); aanvullende S3-archivering met KMS-versleuteling
- Severity-classificatie: LOW, MEDIUM, HIGH
- Zie logbeleid NEN 7513 voor details
3.6 Backup en herstel (A.8.13 - Back-up van informatie)
| Maatregel | Details |
|---|---|
| Database-backups | Aurora automatische back-ups + point-in-time recovery; retentie 35 dagen (productie), 7 dagen (staging) |
| Backup-locatie | AWS eu-central-1, versleuteld met KMS-CMK (jaarlijkse key-rotatie) |
| Chat-archivering | 3-tier: DB (30d) -> warm S3 (60d) -> langetermijn-S3 (KMS-versleuteld, versioning, verwijderbaar; geen Object Lock - chatlogs zijn geen patientdossier) |
| Hersteltest | Een formele, geregistreerde hersteltest-procedure wordt ingericht als onderdeel van het ISMS (zie Intern auditprogramma). De eerste hersteltest is gepland; tot die tijd vertrouwt het herstel op de geautomatiseerde Aurora-snapshots en PITR. |
4. Organisatorische maatregelen
4.1 Incidentmanagement (A.5.24-A.5.28 - Beheer van informatiebeveiligingsincidenten)
- Procedure voor beveiligingsincidenten en datalekken conform het datalekkenprotocol
- Meldplicht aan verwerkingsverantwoordelijke binnen 24 uur
- Intern register van alle incidenten
- Lessen uit incidenten worden verwerkt in het ISMS via Afwijkingen & corrigerende maatregelen (A.5.27)
4.2 Wachtwoordbeleid (A.5.17 - Authenticatie-informatie)
- Minimaal 10 tekens
- Minimaal 1 cijfer en 1 speciaal teken
- Niet in de lijst van veelgebruikte wachtwoorden (Django CommonPasswordValidator)
- Niet geheel numeriek
- Niet gelijkend aan gebruikersgegevens (email, naam)
- Gecontroleerd tegen bekende datalekken (Have I Been Pwned, k-anonimiteit; fail-open bij storing)
- Gehashte opslag (PBKDF2-SHA256)
4.2a Scope veldversleuteling
Fernet-veldversleuteling is toegepast op:
- Patientgegevens: naam, geboortedatum, medicatiegegevens, allergieeen, contra-indicaties, labwaarden, notities, analyseresultaten
- Medewerkergegevens: telefoonnummer, geboortedatum
De velden email, voornaam en achternaam van medewerkers worden niet versleuteld. Dit is een bewuste keuze: deze velden zijn noodzakelijk voor login-lookup (email) en zoekfunctionaliteit (naam). Compenserende maatregelen: tenant-isolatie (gescheiden PostgreSQL-schema's), RBAC, verplichte 2FA, TLS in transit, en audit logging van alle toegang.
4.3 Personeel
- Geheimhoudingsverklaring voor alle medewerkers
- Beveiligingsbewustzijn: periodieke training
- Toegang tot productiedata op need-to-know basis
4.4 Leveranciersbeheer
- Subverwerkers geselecteerd op ISO 27001-certificering of gelijkwaardig
- Verwerkersovereenkomsten met alle subverwerkers
- Periodieke beoordeling van subverwerker-compliance
4.5 Wijzigingsbeheer
- Alle code-wijzigingen via Git met versiebeheer
- Code review voor productie-deployments
- Gescheiden ontwikkel-, test- en productieomgevingen (Docker)
4.6 Beveiligingstesten en kwetsbaarhedenbeheer (A.8.8, A.8.29, A.5.35)
Gelaagde aanpak van kwetsbaarhedenbeheer en beveiligingstesten:
- Geautomatiseerde codeanalyse (SAST): bandit (security) en ruff draaien als harde poort op elke pull request en productie-promotie.
- Container-scanning: ECR
scan_on_pushop alle container-images. - Eigen DAST: periodieke scans van de draaiende applicatie met OWASP ZAP zijn voorzien als onderdeel van de ontwikkelcyclus.
- Onafhankelijke beoordeling (A.5.35): een zelf-gedraaide ZAP-scan geldt niet als de onafhankelijke beoordeling die NEN 7510 (A.5.35) en het Besluit elektronische gegevensverwerking door zorgaanbieders (art. 3 lid 4) vragen. Een externe penetratietest door een onafhankelijke partij is gepland voorafgaand aan, of als onderdeel van, het NEN 7510-certificeringstraject. Resultaten worden vastgelegd en verwerkt in de risicoanalyse.
5. Business continuity (A.5.29-A.5.30 - Continuiteit en ICT-gereedheid)
- Dagelijkse backups met off-site opslag
- Chat-langetermijnarchief (2 jaar, verwijderbaar) en klinisch dossierarchief (med-reviews, 20 jaar WGBO, Object Lock GOVERNANCE)
- Geen single point of failure: gescheiden database, cache, applicatie
- Recovery Time Objective (RTO): < 24 uur
- Recovery Point Objective (RPO): < 24 uur
6. Verantwoordelijkheden
| Rol | Verantwoordelijkheid |
|---|---|
| Remedice (Aanbieder) | Technische en organisatorische maatregelen, incidentrespons, subverwerker-management |
| Apotheek (Klant) | Interne autorisatie, gebruikersbeheer, naleving beroepsgeheim, melden incidenten |
| Medewerkers | Veilig omgaan met inloggegevens, melden onregelmatigheden |
7. Review
Dit beleid wordt jaarlijks herzien of bij wezenlijke wijzigingen in de technische architectuur of het dreigingslandschap.