Informatiebeveiliging

Bij elke nieuwe functie stellen we dezelfde vragen: welke gegevens zijn nodig, wie mag erbij, wat gebeurt er als het misgaat. Beveiliging is onderdeel van de architectuur, van codereview en van de manier waarop we testen, vanaf de eerste regel code.

Iedere gebruiker logt in met een eigen account, en Leyra controleert bij elke handeling of die gebruiker in die context iets mag zien of doen. Rechten volgen de rol en de school, en zijn zo beperkt als mogelijk: iemand krijgt alleen toegang tot wat nodig is voor zijn werk.

Voor medewerkers van scholen en voor beheerders gaan we uit van extra zekerheid bij het inloggen, zoals tweestapsverificatie. Beheertoegang vanuit Leyra zelf is beperkt tot wie het echt nodig heeft en wordt vastgelegd.

Iedere school is binnen Leyra een afgeschermde omgeving. Een fout in één scherm of één functie mag nooit leiden tot inzage in de gegevens van een andere school. Die scheiding controleren we bij iedere wijziging opnieuw.

Gegevens worden versleuteld verstuurd tussen de gebruiker en Leyra, en tussen de onderdelen van Leyra onderling. Ook opgeslagen gegevens worden versleuteld. Welke technieken we precies gebruiken, leggen we vast in de beveiligingsafspraken met scholen.

Ontwikkelen, testen en productie gebeuren in gescheiden omgevingen, waar nodig aangevuld met een acceptatieomgeving. Gegevens van echte leerlingen horen alleen in productie. Om te ontwikkelen en te testen gebruiken we fictieve gegevens; productiegegevens worden niet zomaar naar een ontwikkelomgeving gekopieerd.

Goede logging maakt achteraf zichtbaar wat er is gebeurd. Te veel logging wordt zelf een privacyrisico. We maken daarom onderscheid tussen controleerbare gebeurtenissen en gewone technische logs.

Inloggen

geslaagde en mislukte pogingen

Rechten

wijzigingen in rollen en toegang

Leerlinggegevens

belangrijke wijzigingen in een leerlingdossier

Export

wie welke gegevens exporteert

Slimme ondersteuning

belangrijke voorstellen en wat een mens ermee deed

Gewone technische logs, bijvoorbeeld om storingen op te sporen, bevatten zo min mogelijk persoonsgegevens en worden kort bewaard.

Van productiegegevens worden regelmatig back-ups gemaakt, gescheiden van de productieomgeving. Een back-up is pas iets waard als herstel ook werkt; daarom oefenen we het terugzetten. Concrete hersteltijden en het maximale gegevensverlies bij een storing leggen we vast zodra ze zijn getest, niet eerder.

Wachtwoorden, sleutels en andere geheimen staan nooit in de broncode. Ze worden bewaard in een daarvoor bestemde, beheerde voorziening, en alleen de onderdelen en mensen die ze nodig hebben, kunnen erbij.

We bewaken Leyra op ongebruikelijke activiteit en storingen. Voor beveiligingsincidenten en datalekken komt er een vaste procedure: vaststellen, beperken, herstellen en leren. Omdat de school verwerkingsverantwoordelijke is, informeren we de school bij een datalek zonder onnodige vertraging, zodat de school haar eigen meldplicht kan nakomen.

Leyra wordt ontworpen voor professionele, beheerde cloudinfrastructuur van Google Cloud, met europe-west4 in Nederland als voorkeursregio voor de kerninfrastructuur. Dat is een voorgenomen architectuur. Per dienst stellen we vóór de pilots vast waar gegevens worden verwerkt; een algemene garantie dat alles in Nederland blijft, geven we daarom nu niet.