Ga naar inhoud

Noodtoegang (Break-the-Glass)

GedeeltelijkDevOps Lead

Break-the-glass (noodtoegang) is een softwarepatroon waarbij een geautoriseerde gebruiker tijdelijk verhoogde toegang krijgt buiten het normale rollenmodel, met verplichte motivatie en directe alerting. YipYip bouwt dit patroon in zorgapplicaties als de klant (zorginstelling) het nodig heeft. De klant beslist of en hoe break-the-glass wordt ingeschakeld; YipYip levert de technische implementatie.

Break-the-glass is een optionele feature voor zorgapplicaties waarbij:

  • zorgverleners in acute situaties toegang nodig kunnen hebben buiten hun normale rechten;
  • de klant wil voldoen aan de NEN 7510-eis voor gedocumenteerde noodprocedures;
  • de klant een toetsingsproces heeft voor noodtoegang achteraf.

Niet elk YipYip-project vereist break-the-glass. Bij projecten zonder directe patiëntenzorgkoppeling is dit niet relevant.

Stap Technische implementatie
Activatie Expliciete UI-actie (aparte knop of flow, niet per ongeluk te activeren)
Motivatie Verplicht tekstveld; lege invoer wordt geweigerd
Toegangsverlening Tijdelijke token met beperkte scope en TTL (bijvoorbeeld 1 uur)
Logging Extra gedetailleerde audit-log: wie, reden, tijdstip, welke data ingezien
Alerting Direct alert naar de klantbeheerder (e-mail of push)
Expiratie Automatische intrekking na TTL; handmatige intrekking mogelijk
Review-rapport Klantbeheerder ontvangt periodiek een overzicht van noodtoegang-events
  • Backend (Elixir/Phoenix): aparte Guardian-claim voor noodtoegang, niet deelbaar via de normale refresh flow.
  • Audit trail: break-the-glass events worden apart getagd in de audit log (zie Z2).
  • Alerting: via applicatie-event naar een webhook (e-mail of Slack van de klant, configureerbaar).
  • Scope: noodtoegang geeft uitsluitend leesrechten, tenzij de klant schrijfrechten expliciet vereist.

Als break-the-glass is vereist voor een project:

  1. Functionele specificatie: vastleggen welke rollen noodtoegang mogen activeren en waartoe.
  2. Acceptatiecriteria: user story met logging en directe notificatie van de beheerder als eis.
  3. Security review: de activatieflow wordt getest op misbruik (kan iemand zonder rechten het activeren?).
  4. Klant-onboarding: de klantbeheerder wordt geïnstrueerd in het reviewproces van noodtoegang-events.
Aspect Verantwoordelijkheid
Technische implementatie YipYip
Besluit of break-the-glass vereist is Klant (zorginstelling)
Inrichten welke rollen noodtoegang mogen activeren Klant, met technische hulp van YipYip
Review van noodtoegang-events op rechtmatigheid Klant
Disciplinaire maatregelen bij misbruik Klant

Break-the-glass is beschikbaar als te implementeren patroon. Het is niet standaard actief in alle projecten; per project wordt bepaald of het nodig is.

  • Per zorgproject is nog niet geïnventariseerd welke projecten een break-the-glass-implementatie hebben; uitkomst komt in het assetregister (ISMS-383).
  • Geen standaard klantinstructie voor het reviewproces van noodtoegang-events (ISMS-378).
Type Beschrijving Locatie
Code Break-the-glass implementatie GitHub repository van het betreffende project
Logs Noodtoegang audit events GCP Cloud Logging per project
Specificatie Functionele spec per project Projectdocumentatie (PRD)

YipYip heeft geen zorgverleners; er is geen interne break-the-glass-procedure voor eigen medewerkers. Deze maatregel beschrijft uitsluitend de softwarefeature die YipYip bouwt voor klanten die dit nodig hebben om aan NEN 7510 te voldoen.


Laatst gereviewed: 2026-03-26