Wet Meldplicht Datalekken – Database

Nu zijn we bij Axis into ICT geen juristen en dus past enige terughoudendheid bij het praten over wetgeving. Nu de Wet Meldplicht Datalekken vanaf 1 januari 2016 actief is en de voorpagina van de krant haalt (zie Nu.nl of Telegraaf.nl) is het tijd om vanuit een technisch perspectief te kijken wat er op ons afkomt.

Al sinds enige jaren kennen we de Wet Bescherming Persoonsgegevens. De Wet Meldplicht Datalekken is een wijziging op deze wet. In deze wet wordt geregeld wat wel en wat niet met persoonsgegevens mag worden gedaan en aan welke voorwaarden dit verbonden is. Hiermee is het voor een groot deel een wet zonder directe impact naar de dagelijkse praktijk van betrokken technische mensen.Toch kan het geen kwaad eens te kijken wat er nu daadwerkelijk in de wet staat. En dan vanuit ‘ons’ technisch ‘DBA-perspectief’:

Een relevante passage staat in artikel 13:

De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. Deze maatregelen garanderen, rekening houdend met de stand van de techniek en de kosten van de tenuitvoerlegging, een passend beveiligingsniveau gelet op de risico’s die de verwerking en de aard van te beschermen gegevens met zich meebrengen. De maatregelen zijn er mede op gericht onnodige verzameling en verdere verwerking van persoonsgegevens te voorkomen.

Dit is een erg algemeen gesteld stuk tekst, zoals we dat vaker zien met wetteksten. Als we de tekst nu technisch proberen te ontleden lijkt ‘passende technische en organisatorische maatregelen tegen verlies of tegen enige vorm van onrechtmatige verwerking’ hier de centrale kreet. Als we dit vertalen naar begrippen uit de dagelijkse DBA praktijk komt dat volgens ons neer op:

  • Authenticatie: wie ben je wel niet dat je bij de betreffende data mag komen.
  • Autorisatie: wat moet je dan eigenlijk met die data kunnen.
  • Databeveiliging: hoe zorgen we er voor dat de data niet op een andere manier dan de geëigende manier wordt benaderd.

De wet laat in het midden hoe je dit uitvoert. De enige beperking die gegeven wordt, is dat rekening gehouden mag worden met de stand van de techniek en de kosten. Hiermee wordt niet gezegd dat je voor een dubbeltje op de eerste rang mag zitten maar wordt aangegeven dat er een afweging nodig is tussen kosten, inspanning en potentieel risico. Probleem is dat pas bij de rechter of de Autoriteit Persoonsgegevens (voorheen het College Bescherming Persoonsgegevens) de toetsing plaats vindt of de juiste afweging is gemaakt.

In de dagelijkse praktijk zien wij regelmatig zaken die volgens ons een risico vormen:

  • Standaard passwords
    Veel leveranciers en eindgebruikers hanteren standaard accounts. Met regelmaat komen we database accounts tegen met toegang tot persoonsgegevens waarbij de username en password gelijk zijn aan elkaar of uit een lijstje van drie standaard worden komt. Hiermee is effectief je data toegankelijk voor elke liefhebber.
  • Database accounts met (zeer) veel rechten
    In de database worden, vaak al bij inrichting van de applicatie, (te) veel rechten aan een gebruiker gegeven. Hiermee is dan ineens toegang tot alle opgeslagen data mogelijk. Berucht is het toekennen van dba of sysdba aan een applicatie gebruiker. Maar ook het overmatig toekennen van select, delete en wijzigrechten op tabellen kan hier onder geschaard worden.
  • Data ontsluiting op zeer veel (ongestructureerde) manieren.
    Zolang de data alleen via een applicatielaag toegankelijk is, wordt nog enige invloed op het gebruik van de data uitgeoefend. Zodra toegang wordt gegeven met SQL*plus/ MS Excel(via een ODBC-connectie) of een willekeurige andere query tool, is het ineens totaal onduidelijk wat er met de data wordt gedaan.

Met het aanpakken van bovenstaande algemene misstanden kan aan een groot deel van de eisen worden voldaan. Dit is echter geen DBA specifieke taak maar vereist betrokkenheid van alle (technische) betrokkenen.

Maar wat is er nieuw met ingang van 1 januari dat de wet de voorpagina haalt? De wijziging betreft de melding van datalekken en staat in het nieuwe artikel 34a:

1. De verantwoordelijke stelt het College onverwijld in kennis van een inbreuk op de beveiliging, bedoeld in artikel 13, die leidt tot de aanzienlijke kans op ernstige nadelige gevolgen dan wel ernstige nadelige gevolgen heeft voor de bescherming van persoonsgegevens.

2. De verantwoordelijke, bedoeld in het eerste lid, stelt de betrokkene onverwijld in kennis van de inbreuk, bedoeld in het eerste lid, indien de inbreuk waarschijnlijk ongunstige gevolgen zal hebben voor diens persoonlijke levenssfeer.

3. De kennisgeving aan het College en de betrokkene omvat in ieder geval de aard van de inbreuk, de instanties waar meer informatie over de inbreuk kan worden verkregen en de aanbevolen maatregelen om de negatieve gevolgen van de inbreuk te beperken.
….
7. Indien de verantwoordelijke geen kennisgeving aan de betrokkene doet, kan het College, indien het van oordeel is dat inbreuk waarschijnlijk ongunstige gevolgen zal hebben voor de persoonlijke levenssfeer van de betrokkene, van de verantwoordelijke verlangen dat hij alsnog een kennisgeving doet.

Waar de media vooral op reageert, is lid 7, de boete die opgelegd kan worden bij het niet voldoen aan (o.a.) lid 1 t/m 3. Maar wezenlijk gaat het hier om het implementeren van de meldplicht.
Van belang is dat om aan de meldplicht te kunnen voldoen het noodzakelijk is dat je weet dat er iets mis is gegaan. Met deze meldingsplicht is het dus nog meer dan voorheen van belang te weten wanneer data geraakt wordt. En dan vooral zodra het gaat om ongewenste toegang. Technisch wordt dit meestal vertaald naar auditing.

Auditing is in de database jaren een ondergeschoven kindje geweest. Het was lastig, inflexibel en niemand die iets met de informatie deed. Met deze wetgeving is de noodzaak anders komen te liggen. Met de Unified Auditing zoals Oracle deze in Oracle Database 12c heeft geïmplementeerd is setup ook veel flexibeler geworden. Daarover een andere keer meer.

Zo blijkt dat een wet die in eerste instantie een voornamelijk administratieve wet blijkt te zijn toch sterke invloed op de technische inrichting van onze database (omgeving) kan hebben.

Op 1 januari 2016 verandert er niet heel veel maar het biedt wel een goede aanleiding om met de applicatieleverancier(s), andere beheerders en eindgebruikers om tafel te gaan. Het lijkt zinvol om te kijken of de procedures en inrichting wel op het juiste niveau zijn. Verder is het aan te bevelen om een basis vorm van (database) auditing in te richten waarbij in ieder geval gekeken wordt naar verdachte activiteiten.

Scroll to Top