Een RFID-systeem, een ouderportaal en een datalek
Een school voert RFID-pasjes in voor aanwezigheid en toegang tot lokalen. Elke pas bevat een leerlingnummer. Bij elke deur hangt een lezer die de naam, het tijdstip en de deur naar een cloud-API stuurt. De leverancier bewaart de gebeurtenissen vijf jaar, omdat dat 'handig is voor analyses'. Ouders kunnen via een ouderportaal de aanwezigheid van hun kind bekijken. Een leerling ontdekt dat de URL https://api.school.nl/aanwezigheid?leerling=12345 ook de gegevens van leerling 12346 teruggeeft als hij het nummer aanpast. De school wil ook dat de conciërge alleen de toegang van deze week kan zien, en de mentor alleen de aanwezigheid van zijn eigen klas. Er is geen functionaris voor gegevensbescherming in dienst; de school heeft wel een verwerkersovereenkomst met de leverancier.
1. Leg uit welk beveiligingsprobleem de leerling heeft gevonden en waarom dit een ernstig datalek is. Betrek zowel de technische oorzaak als de gegevens die gelekt kunnen worden.
Read the worked answer
De leerling past de parameter leerling=12345 aan naar 12346 en krijgt gegevens van een andere leerling. De server controleert waarschijnlijk wel of de gebruiker is ingelogd, maar niet of die gebruiker bij object 12346 mag. Dat is een IDOR (insecure direct object reference) of een ontbrekende object-level autorisatie. Omdat leerlingnummers opeenvolgend zijn, kan hij alle records enumereren.
Gelekt kunnen worden: naam, tijdstip en deur per gebeurtenis, dus aanwezigheid en beweegpatroon van minderjarigen. Dat is een datalek in de zin van de AVG: een inbreuk op de vertrouwelijkheid van persoonsgegevens. De school moet het lek melden bij de Autoriteit Persoonsgegevens als het risico voor betrokkenen hoog is, en ouders informeren. Ook moet de oorzaak worden weggenomen voordat verder wordt gegaan; alleen de URL aanpassen is geen oplossing.
2. Ontwerp een autorisatiemodel met rollen voor leerling, mentor, conciërge en leverancier. Geef per rol aan welke gegevens en welke periode toegankelijk zijn. Licht toe hoe je afdwingt dat een mentor alleen zijn eigen klas ziet.
Read the worked answer
Rollen en rechten:
- Leerling: alleen eigen aanwezigheid en alleen het eigen leerlingnummer; geen andere leerlingen.
- Mentor: alleen aanwezigheid en toegang van leerlingen met de eigen Klascode; geen andere klassen.
- Conciërge: deurgebeurtenissen van de laatste 7 dagen, nodig voor toezicht; geen historie ouder dan 7 dagen.
- Leverancier: geen directe leesrechten voor schoolmedewerkers; alleen verwerken volgens de verwerkersovereenkomst, met geaggregeerde of geanonimiseerde data voor onderhoud.
Afdwingen doe je server-side, niet in de client. De mentor krijgt een klas_id in zijn sessie of token. De API voegt altijd WHERE klas_id = :eigen_klas toe en negeert een klasparameter uit de URL. Voor de conciërge geldt een datumfilter op de server. Elke aanvraag wordt gelogd en rechten worden periodiek herzien.
3. De leverancier wil de gebeurtenissen vijf jaar bewaren. Beoordeel dit vanuit de AVG en stel een concreet bewaarbeleid voor. Noem één technische en één organisatorische maatregel die het datalek in de toekomst beperken.
Read the worked answer
Vanuit de AVG mag je gegevens niet langer bewaren dan nodig (opslagbeperking) en alleen voor het doel waarvoor ze zijn verzameld (doelbinding). Vijf jaar aanwezigheids- en deurgegevens is voor dagelijks toezicht niet nodig; voor conflicten of verzuim is bijvoorbeeld één schooljaar verdedigbaar, met daarna aggregatie of verwijdering. Concreet: ruwe gebeurtenissen 4 weken tot maximaal 1 schooljaar, daarna alleen geaggregeerde verzuimcijfers; toegang tot ruwe data beperken tot conciërge en mentor.
Technische maatregel: object-level autorisatie en het gebruik van niet-raadbare identifiers (UUID) in combinatie met een server-side check, plus monitoring en logging van afwijkende bevragingen. Organisatorische maatregel: een DPIA uitvoeren, de verwerkersovereenkomst aanscherpen, toegangsrechten periodiek herzien en een meldprocedure voor datalekken vastleggen.