Denver Health Medical Plan (DHMP) heeft laten weten dat de gegevens van 238.000 mensen mogelijk zijn blootgesteld door een datalek. De oorzaak ligt niet bij het zorgprogramma zelf, maar bij een vendor key leak bij een derde partij: SquareML, een leverancier van een no-code platform voor zorganalytics.
Volgens DHMP gaat het om persoonlijke en gezondheidsinformatie die in een database stond die door SquareML wordt beheerd. Hoewel het om een mogelijk scenario gaat en DHMP stelt nog geen bewijs van misbruik te hebben, is de impact op leden aanzienlijk en is snelle herstelactie nodig.
Wat is er gelekt bij de vendor key leak?
DHMP beschrijft in de incidentkennisgeving dat SquareML op 14 augustus 2026 de zorgorganisatie informeerde over een toegangskey die per ongeluk op een publiek toegankelijke website terecht was gekomen.
De toegangskey was tijdens een periode online beschikbaar geweest van 27 juni 2025 tot 18 augustus 2026. In die vensterperiode kon de key mogelijk worden gebruikt om toegang te krijgen tot de database met informatie over de leden van DHMP.
Was er direct gevaar om data te exporteren?
DHMP benadrukt dat de gecompromitteerde account read-only was. Dat betekent dat de sleutel volgens de organisatie niet kon worden gebruikt om bestanden te downloaden, te exporteren, informatie te verwijderen of te wijzigen.
Dat neemt niet weg dat lezen en het verkrijgen van gegevens zelf nog steeds schadelijk kan zijn. Tegelijk stelt DHMP dat het vooralsnog bij “mogelijk” blijft: er is op het moment van de melding geen bewijs dat de gegevens daadwerkelijk zijn bekeken of misbruikt.
Welke gegevens mogelijk betrokken waren
Volgens DHMP kan de database gegevens hebben bevat zoals:
- namen
- geboortedata (dates of birth)
- postcode, plaats en staat
- demografische informatie
- gezondheidsgerelateerde metrics
- gegevens over geschiktheid voor het zorgplan
- informatie rond ziekenhuisopname
- naam van zorgverlener
- gegevens over ontslag en overdracht
Daarnaast meldt DHMP dat de database geen sofinummers of financiële informatie opslaat. Dat verlaagt het risico op identiteits- of financiële fraude, maar het blijft nog steeds gevoelige gezondheidsinformatie.
Geen bewijs van misbruik, maar wél herstelmaatregelen
DHMP zegt op het moment van de melding geen bewijs te hebben dat lidinformatie werd ingezien of misbruikt. Wel is er dus een reëel risico geweest dat de database toegankelijk was.
Om de impact te beperken heeft DHMP samen met SquareML en op basis van de bevindingen direct acties ondernomen. Een van de eerste stappen was het resetten van wachtwoorden voor alle accounts die toegang hadden tot de database.
Verder worden er volgens DHMP aanvullende herstelacties onderzocht of uitgevoerd door zowel DHMP als SquareML.
Waarom vendor key leaks extra lastig zijn
Dit incident laat zien hoe een vendor key leak kan ontstaan buiten de directe controle van de zorgorganisatie. In de praktijk is de keten complex: zorginstellingen gebruiken platforms en dashboards van derden, en die derden beheren vaak ook de technische verbindingen met data.
Als credentials per ongeluk publiek worden gezet (bijvoorbeeld door een fout in een websiteomgeving of deployment), kan dat tot langdurige blootstelling leiden. De periode in dit geval—ruim een jaar—onderstreept dat zelfs een “read-only” toegang tot ongewenste datatoegang kan leiden.
Wie vendor- en ketenrisico serieus neemt, probeert daarom niet alleen de eigen systemen te beveiligen, maar ook afspraken en controles rond derde partijen te versterken. Denk aan afspraken over logging, snelle secret-disclosure procedures en strikte beheersing van waar keys terechtkomen.
Wat kun je hiervan leren voor je eigen security?
Ook als jouw organisatie geen SquareML gebruikt, is het patroon herkenbaar: een sleutel komt publiek beschikbaar en kan toegang bieden tot data in de keten. Hieronder staan praktische aandachtspunten die passen bij dit soort incidenten.
- Inventariseer vendor-toegangen: weet welke accounts en sleutels derden gebruiken om data te benaderen.
- Beperk privileges: read-only is een goede stap, maar minimale toegang moet structureel en aantoonbaar zijn.
- Check op publieke exposure: voer periodiek controles uit op verkeerd gepubliceerde secrets in webcontent en code-repositories.
- Versnel reactie: bij publicatie van sleutels telt tijd—zet procedures klaar voor snelle key rotation.
- Versterk monitoring: log toegangspogingen en detecteer afwijkend gedrag vroeg.
Wil je meer context over hoe indirecte aanvalspatronen in de praktijk tot datalekken leiden? Dan past ook dit artikel over compromitterende toegang via misbruik van accountstromen: AI fake login pages: account takeovers makkelijker.
Vergelijkbare datalekken in de zorg
DHMP noemt in de melding ook andere recente incidenten waarbij patiënt- of zorgdata betrokken was. In het overzicht gaat het onder meer om claims rond:
- Quest Diagnostics en het blootleggen van bepaalde patiëntgegevens
- Medi-Cal leden die zijn geraakt door een datalek bij Paradigm Healthcare
- iRhythm datalekken met impact op minimaal 360.000 personen
- Oracle Health, waarbij de teller bijna richting 20 miljoen komt
Dat maakt duidelijk dat datalekken in de zorg niet zelden voortkomen uit systeem- en ketenkwetsbaarheden—van technische fouten tot vendor-issues.
Conclusie: vendor key leak is een ketenrisico dat je moet aanpakken
De melding van DHMP rond een vendor key leak bij SquareML gaat over mogelijke toegang tot databasegegevens van 238.000 leden. DHMP geeft aan dat er vooralsnog geen bewijs is van daadwerkelijke inzage of misbruik, mede omdat het om read-only toegang zou gaan. Toch is het risico door de lange blootstellingsperiode en de aard van de gegevens groot.
Voor organisaties is dit een duidelijke reminder: beveiliging stopt niet bij het eigen netwerk. Het vraagt om controle over derde partijen, zicht op credentials, en een snelle reactie wanneer secrets (ongewenst) publiek worden. Als je de lessen uit dit soort incidenten vertaalt naar beleid en technische checks, verklein je de kans dat een simpele sleutel tot een groot datalek leidt.
Extra achtergrond over het voorkomen van vendor- en ketenproblemen vind je ook in dit gerelateerde onderwerp: Lazarus misbruikt security-software met post-quantum encryptie.
Bron: https://www.securityweek.com/vendor-key-leak-puts-data-of-238000-denver-health-plan-members-at-risk/
