Overheid vindt versleutelen van gegevens in Basisregistratie Personen niet nodig

Gegevens in de Basisregistratie Personen worden voorlopig niet versleuteld. De regering had dat wel afgesproken, maar staatssecretaris Raymond Knops denkt dat er betere manieren zijn om de gegevens te beveiligen en dat encryptie weinig toevoegt.

De staatssecretaris van Binnenlandse Zaken liet eind vorig jaar een onderzoek uitvoeren naar de veiligheid van de Basisregistratie Personen of BRP, waar de gegevens van alle Nederlanders in staan opgeslagen. Hij deed dat omdat in het regeerakkoord stond opgenomen dat 'de gegevens van burgers in basisadministraties en andere privacygevoelige informatie' versleuteld zouden moeten worden opgeslagen. Knops concludeert na het onderzoek echter dat versleuteling niet per se de beste maatregel is. Andere beveiligingsmaatregelen werken volgens hem net zo goed of zelfs beter. Dat schrijft hij in een brief aan de Tweede Kamer.

Het onderzoek keek onder andere naar de kosten van het toepassen van die versleuteling. Die werden afgewogen tegen de opbrengsten ervan. Volgens het onderzoek moeten gemeenten en grote aantallen gebruikers de gegevens uit de BRP in hun eigen systemen kunnen gebruiken. Daardoor wordt 'het beveiligende effect van de versleuteling teniet gedaan'. "Geen van de onderzochte vormen van aanvullend versleutelen is een zinvolle maatregel", staat in het onderzoek.

Knops wijst erop dat er andere maatregelen aanwezig zijn die misbruik van de gegevens voorkomen. Dat zijn digitale maatregelen zoals autorisatietoegang, maar ook fysieke zoals toegang tot locaties of trainingen voor werknemers. "Op dit moment valt er meer winst te behalen door het nemen van andere maatregelen dan extra versleuteling", schrijft Knops. Wel houdt hij een slag om de arm: versleuteling kan in de toekomst mogelijk alsnog nodig zijn.

Volgens Knops is het doel van de passage in het regeerakkoord het beveiligen van persoonsgegevens en volgens hem is encryptie daarvoor niet het goede middel. "Versleuteling alleen is geen garantie voor veiligheid. Door het toepassen van de maatregelen (...) worden vertrouwelijke gegevens in de basisregistraties op het juiste niveau beveiligd zodat privacygevoelige gegevens alleen door bevoegden kunnen worden ingezien en bewerkt. Hiermee wordt invulling gegeven aan alternatieve maatregelen met hetzelfde doel als het voornemen uit het Regeerakkoord, namelijk adequate beveiliging van de gegevens."

De staatssecretaris neemt ook een andere belangrijke aanbeveling uit het onderzoek niet over. De Basisregistratie Personen wordt niet gecentraliseerd. Knops zegt dat de huidige decentrale opzet van de ict overeenkomt met hoe gemeentes de BRP gebruiken. "Er zijn geen voornemens om deze opzet ingrijpend te gaan veranderen. Gemeenten zijn en blijven verantwoordelijk voor de registratie en het bijhouden van gegevens van hun inwoners."

Tegelijkertijd wil Knops in de toekomst dat gemeentes meer aandacht besteden aan privacy bij het doorontwikkelen van de BRP. Dat kan dataminimalisatie zijn en het verminderen van kopieën van informatie. De Autoriteit Persoonsgegevens zou gemeentes daarin kunnen adviseren, zegt Knops.

Reacties (255)

[djwice]

Opvallend besluit. Er zo zijn eerder al data gelekt bij gemeenten. De middelen moeten zorgen dat een persoonlijke fout niet kan leiden tot het breder verstrekken van gegevens dan noodzakelijk.

Opvallend dat versleuteling als losstaande maatregel is bekeken en vergeleken is met een combinatie van maatregelen.

Logisch dat als je iets versleutelt en je aan iedereen de sleutel geeft dat versleuteling dan niet veel toevoegt.
Maar dat zelfde geld voor autorisatie: geef je iedereen geautoriseerd toegang is het ook geen afdoende maatregel.
Het zelfde geldt voor training: geef je iedereen een training, dan betekent het nog steeds niet dat mensen altijd doen wat ze op de training is overgedragen.

Bij mij op het werk hebben we voor elke klant in elke database tabel een unieke sleutel. Het proces bepaald tot welke klant en dan welke data toegang wordt gevraagd. En een apart proces bepaald welke toegang wordt verleent.
Het vragende proces krijgt die ene sleutel voor dat ene record in die ene database tabel.
Het vragende proces krijgt op basis van de vraag alleen toegang tot dat ene record in die tabel.
Als er om welke reden dan ook er een mismatch is kan de data niet worden ontsleutelt.
Als er alles 'Select * From tabel' gevraagd wordt, krijgt ie maar 1 versleuteld record.

Alle data in pre-procossed, dat wil zeggen dat elk mogelijk verzoek al tot een record is verwerkt. Daardoor kunnen we vooraf de authenticatie en rechten controleren. Dus voordat er een data verzoek plaats vindt. En is het verstrekken van gegevens super snel en goedkoop.
We werken met change data in plaats van full loads (full loads zijn gebruikelijk in traditionele ETL processen), daardoor is de verwerking zeer behapbaar is geworden en hebben we nauwelijks piek belastingen. Alle data is binnen enkele seconden tot maximaal een paar minuten volledig up-to-date en beschikbaar in de gecontroleerde vorm zoals boven beschreven.

We doen dit met meer dan 1,5 TB aan beschikbare data voor meer dan 2 miljoen klanten.

We belasten onze systemen hierdoor veel minder dan voorheen omdat we real-time werken en batch en full load operaties uitfaseren. Het klinkt tegenstrijdig, maar het is en sneller en goedkoper en veiliger.

Als nu een sleutel of autorisatie onder aanval is, geld dat slechts voor 1 record van 1 klant.
Elk request gebeurd op aparte machines die slechts enkele seconden bestaan.
Mocht om welke reden dan ook alle data uit 1 tabel uitlekken, dan zijn er meer dan 2 miljoen verschillende onafhankelijke (ongecorroleerde) complexe sleutels nodig om alle data te kunnen lezen. En voor elk ander tabel geldt het zelfde.

Je kunt in het process bijvoorbeeld vereisen dat de sleutel alleen verstrekt wordt als ook de data eigenaar - de burger zelf - toestemming verleend via een autorisatie process. Zonder wordt de sleutel niet afgegeven.

Zo voorkom je een situatie waarbij een persoon onder druk wordt gezet en als nog toegang geeft (crimineel met pistool, leidinggevende tijdens beoordelings of reorganisatie periode, senior collega, lieve collega, persoon aan balie in paniek of in hele zielige omstandigheid etc.).

Voorkom dat toegang mensenwerk is. Zorg voor pre-validate van data toegang, voordat de data wens ontstaat, zodat het los van emotie en tijdsdruk gevalideerd kan worden.
Dat is wat wij hebben gedaan - autorisatie tot data niet meer real-time, query samenstellen niet meer real-time en losgekoppeld van authenticatie.

Bij een bedrijf dat al meer dan 100 jaar bestaat.

[Reactie gewijzigd door djwice op 24 juli 2024 12:23]

[CivLord]

Hoeveel verschillende applicaties kunnen bij die database?

Bij de basisregistratie zijn er honderden gemeentes en overheidsinstanties die samen met duizenden verschillende systemen die gegevens raadplegen. Hoe maak je al die systemen geschikt om die gegevens versleuteld op te halen en te ontsleutelen, zonder dat de kosten te pan uit gieren en er een chaos ontstaat?

[djwice]

De applicaties praten tegen een API over TLS, de ontsleutelling vindt plaats voordat de data voor eenmalig gebruik naar het systeem wordt gestuurd.
Na de ontsleitelling wordt bovendien gevalideerd of de data voldoet aan de verwachte output structuur; klopt het patroon van elk record, zijn het niet te veel records, bevat geen systeem error codes.

Elke tabel en API levert alleen de data die nodig is. Elke tabel heeft even veel partities als records waardoor requests de performance van andere requests niet beïnvloed.

We gebruiken een cloud provider en recent hebben we getest dat 12.000 requests in 45 seconden tot geen enkele vertraging leidt, en de kosten nog steeds liniair zijn met het aantal requests - we betalen per 100ms dat de API en de database berekeningen doet, niet voor de beschikbaarheid. De meeste request waren binnen 50ms afgehandeld. Kosten lagen onder de €10,-.

We gebruiken dit since 2017 in productie voor alle klanten.

[Reactie gewijzigd door djwice op 24 juli 2024 12:23]

[MacD]

Vette post!

"Alle data in pre-procossed, dat wil zeggen dat elk mogelijk verzoek al tot een record is verwerkt."

Cool! Alles wat je dus van te voren kan doen, doe je, zodat de 'query' supersnel is. Kost wat ruimte, maar daar heb je snelheid voor terug.
Doet me denken aan toen ik een mobiel spel programeerde en door de garbage collection van android microstuttering kreeg; bleek dat 1 vd redenen was dat ik voor de score telkens Strings aanmaakte (zijn in java immutable ... en charseq/editable kost ook moeite) ... snelste manier was 100kb geheugen wegschrijven in een pre-allocated array waar die Strings in stonden (want drawString op canvas is toch echt de snelste manier om die score op een surfaceview te krijgen).

Maar als ik je reactie begrijp dan denk ik dat je het ook wel eens bent dat
a) encryptie noodzakelijk is omdat alles toch gekraakt kan worden EN/MAAR dat
b) (ook al spreek je hier niet over) decentralisatie idem belangrijk is voor zoveel redenen, zoals: geen master key; voorkomt escalatie als je toch in 1 node inbreekt; beheerbaarheid en damage control bij "schade"; rollout.

MAW een gedecentraliseerd, gelaagd systeem dat gecentraliseerd wordt opgelegd. Maar MET encryptie, ZONDER master key.

Training is altijd goed, maar autorisatietoegang is in feite een low-level soort van versie van encryptie (en berust hoe dan ook daarop ).

De staatssecretaris neemt in mijn mening dus de goedkoopste stappen en niet de juiste, noodzakelijke.

"want we worden toch niet gehackt" ... zei Equifax

[djwice]

Ik ben het helemaal met je eens m.b.t. encryptie. Decentralisatie heeft voor en nadelen.
Wij gebruiken een cloud waarbij we voor ons doel voldoende (honderden miljoenen) partities kunnen maken, verdeelt over 3 of meer (vaak 9) fysieke data centra.

De Keys worden deels op infrastructuur niveau gebruikt, waardoor de software ze überhaupt niet kan zien, en deels op software niveau, maar via de infrastructuur wordt de legitimiteit van verstrekken gevalideerd.
De sleutels op infrastructuur niveau kunnen we verversen zonder impact.

De sleutels op software niveau zijn inderdaad onafhankelijk, als we een breach vermoeden hoeven we alleen die data elementen die geraakt zijn te invalideren. Het her-creatie proces van geïnvalideerde data is bewust geen batch proces, om te voorkomen dat ontwikkelaars er 'voor efficiëntie' Keys gaan hergebruiken, Keys tijdelijk op gaan slaan of de zelfde 'compute' gebruiken om meerdere Keys te verwerken (waardoor je dus weer 1 zwakke plek hebt). Het is dus gedwongen een data event driven process.

[Reactie gewijzigd door djwice op 24 juli 2024 12:23]

[MacD]

"De Keys worden deels op infrastructuur niveau gebruikt, waardoor de software ze überhaupt niet kan zien, en deels op software niveau,"

Kan je hier iets meer op uitweiden? Dat laatste snap ik, denk ik, maar dat eerste? Een paar links zou ook ok zijn ...ik ken het verschijnsel hashes/SALTs etc, maar dat is allemaal op software/db niveau ... met infra bedoel je denk ik meer richting hardware ofzo?

Om ff snel een niveau aan te geven: ik heb compleet ge-encrypte mobiele apps gemaakt die ge-audit zijn door een Fortune 5 company en snap de 7 levels van abstractie ... maar het onderscheid dat je hier maakt ken ik niet en zou het graag willen onderzoeken ...

Thanks!

[Raindeer]

Heeft iemand het onderliggende rapport van de firma's KPN en Noordbeek gelezen?

Er zijn veel grotere problemen met het BRP dan de versleuteling. Een selectie uit de lijst:
1. Geen actuele risicobeheersing: Geen cyberse-curity-medewerkers die een actuele informatiepositie onderhouden met betrek-king tot cyberdreigingen gericht op de BRP.
2. Beperkt gebruik van de Baseline Informatiebeveiliging Overheid (BIO)
3. Groot risico op onvoldoende logging en monitoring bij leveranciers
4. Geen geanonimiseerde decentrale testgegevens
5. Incomplete protocollering
6. Onvoldoende grip op autorisaties voor toegang van beheerders en gebrui-kers
7. Minimale wachtwoordlengte is te kort: Wij adviseren de minimale wachtwoordlengte voor de GBA-mailbox server en GBA-V te verlengen van de huidige 6 tekens naar 8 tekens, om zo het raden en kraken van wachtwoorden moeilijker te maken voor een kwaadwillende. (Nog steeds te kort volgens mij/Raindeer)
8. Onveilig beveiligingsprotocol SSL
9. Onvoldoende robuustheid tegen aanval met ransomware of wiperware

Zoals het rapport ook zegt, versleuteling van de gegevens helpt alleen tegen iemand die de disk jat. Het BRP is zo lek, dat je je afvraagt waarom iemand de moeite zou doen om allerlei datacenters in Nederland af te gaan om van individuele gemeenten de harddisks te jatten, als ie gewoon online toegang kan krijgen via een veelheid van organisaties en mensen.
Zie https://www.tweedekamer.n...0Personen%20%28BRP%29.pdf

[Reactie gewijzigd door Raindeer op 24 juli 2024 12:23]

[djwice]

OMG en wanneer gaan we handhaven?
Het beleid en de deadlines zijn zeer helder en tijdig gecommuniceerd volgens mijn.
Dit is gewoon schandalig slecht, en de burger heeft geen mogelijkheid om er omwille van privacy of willen dat al hun gegevens conform AVG behandeld worden er géén gebruik van te maken.

Zeer kwalijk.

[Reactie gewijzigd door djwice op 24 juli 2024 12:23]

[MacD]

Dat alles is al erg genoeg, maar:

"8. Onveilig beveiligingsprotocol SSL"

*Blink*, *blink*.

WTF!!!

[PrisonerOfPain]

Teleurstellend is eigenlijk het enige juiste woord hier voor.

[phYzar]

Ik denk dat staatssecretaris wel degelijk een punt heeft als hij zegt dat versleutelen weinig zin heeft als jan en alleman een sleutel heeft. Een beter toegangsbeleid, zoals je eigenlijk ook voor een patiëntendossier zou willen hebben, is dan bijvoorbeeld een zinnigere eerste stap.

[tweaknico]

Maar waarom zou iedereen over de sleutel moeten beschikken.
Dat zou voorbehouden zijn aan geautoriseerd personeel.

En als iemand toegang heeft tot bepaalde rubrieken dan kun je dverschillende delen op verschillende manieren encrypten.

[Kees]

Omdat er gewoon heel erg veel gemeentes en organisaties bij die gegevens mogen komen. Het heeft niet heel erg veel zin om de gegevens in de database versleuteld op te slaan als Tammo van gemeente Hoogerland er gewoon een exportje van maakt en die in een excel sheet zet, op een usb stick opslaat en in de Ariva trein laat liggen.

En hij moet gewoon bij die gegevens kunnen komen om zijn werk te doen. Zelfs als je per gemeente maar 3 man authorisatie geeft om in het GBA te mogen komen dan heb je alsnog 1000 man die de sleutel hebben. En dat zijn alleen nog maar de gemeentes.

[Reactie gewijzigd door Kees op 24 juli 2024 12:23]

[SpiceWorm]

Je kan je wel afvragen waarom Tammo van gemeente hogerland kan bij de GBA gegevens van Pietje op schiermonnikoog. Dat lijkt mij niet nodig.

Ik zou graag zelf als burger een sms/e-mail ontvangen telkens als mijn dossier wordt ingekeken met daarin de reden en/of de zaak.

[DataGhost]

Je kan je wel afvragen waarom Tammo van gemeente hogerland kan bij de GBA gegevens van Pietje op schiermonnikoog. Dat lijkt mij niet nodig.

Als Pietje naar Hoogerland verhuist zal Tammo toch echt in de GBA zijn gegevens moeten kunnen ophalen.

[SpiceWorm]

Dat klopt maar dat is toch niet het hele jaar? Er kan in het geval van een verhuizing toch ook sprake zijn dat het tijdelijk even voor beide gemeenten inzichtelijk is? Lijkt mij niet zo ingewikkeld en is al een enorme upgrade t.o.v. altijd alle gemeenten die altijd overal bij kunnen.

[JackBol]

En dan is toegang ineens heel complex geworden en gaan gemeentes een digitale kopie maken voor dagelijks gebruik en dan heeft je veiligheidsmaatregel de veiligheid verlaagd.

[Killemov]

En dan is toegang ineens heel complex geworden en gaan gemeentes een digitale kopie maken voor dagelijks gebruik en dan heeft je veiligheidsmaatregel de veiligheid verlaagd.

En dat mag nou juist niet. De beperking per gemeente invoeren is al een behoorlijke upgrade. Als het centraal hosten niet zo gemakkelijk, efficient en goedkoop was geweest hadden we waarschijnlijk een vorm van sharding over de gemeentes heen gehad: Alle gemeentes zouden hun eigen data beheren en dat delen op basis van gelegenheid.

[SpiceWorm]

Heel complex is ook wel wat overdreven.

[bassekeNL]

Complex is in deze een ander woord voor duur. Misschien moet dat eens duidelijk worden: wat kost privacy. In euro's.

[questo]

Er kan in het geval van een verhuizing toch ook sprake zijn dat het tijdelijk even voor beide gemeenten inzichtelijk is?

Dan is de vraag natuurlijk wel hoe het systeem weet dat er sprake is van een verhuizing. Er zal iemand in het systeem moeten aangeven dat er een adreswijziging heeft plaatsgevonden. Dat wordt nu gedaan door de gemeente waar je gaat wonen. Die moeten dus al toegang hebben tot de persoonsregistratie van een persoon voordat die persoon daadwerkelijk in de gemeente ingeschreven is.

[Jaatoo]

Het fijne aan goed en veilig opzetten van software is dat het je dwingt om over processen na te denken.

Als die stap al wordt overgeslagen gaat het nooit goed komen. Digitalisering is niet alleen software in gebruik nemen, het is ook processen aanpassen om op de juiste manier met de software om te gaan.

Elk bedrijf dat software aanschaft (of het nou maatwerk of of-the-shelf is) in de hoop dat de aanschaf alles efficiënter maakt heeft het goed mis en is direct gedoemd te falen.

[pmeter]

Een snelle brainstorm waarom gemeenten bij gegevens van andere gemeenten moeten kunnen:

• De politie en buitengewoon opsporingsambtenaren (in dienst van de gemeente) maken vast gebruik van het GBA en plaats delict != woonplaats. Denk aan een parkeerboete, te hard rijden op een Rijksweg of het dumpen van afval.
• Scholen krijgen subsidie van de gemeente. Daartoe wordt het aantal leerlingen bijgehouden. Maar die komen niet altijd uit dezelfde gemeente.
• Er geldt een meldplicht voor sommige hooligans tijdens bepaalde wedstrijden. Die hooligans komen uit het hele land.
• Gemeenten moeten samenwerken voor zorgregio's.
• Gemeenten moeten sommige besluiten ten aanzien van personen voorleggen aan de provincie. Provincies moeten sommige besluiten ten aanzien van personen voorleggen aan de Rijksoverheid.
• Iemand wonend in één gemeente kan aanvrager zijn van een vergunning in verband met eigendom in een andere gemeente. Denk aan de ligplaats van een boot en de verbouwing van een bedrijfspand.
• Iemand officieel wonend in één gemeente - een zwerver - kan overlast veroorzaken of zorg nodig hebben in gemeente aan de andere kant van het land.

[Reactie gewijzigd door pmeter op 24 juli 2024 12:23]

[V1RT]

Je bent ook nog die ene scootmobiel/rolstoel monteur vergeten van een privaat zorg instelling die de GBA gegevens in kan zien van letterlijk iedereen. Terwijl dat helemaal niet nodig is... 0.0% reden voor, maar kan het gewoon.

[SpiceWorm]

Daar zijn toch allemaal betere oplossingen voor te bedenken dan "iedereen kan altijd overal bij"?

[bassekeNL]

Beter? Als in 10x zo duur en langere wachttijden?

[Brahiewahiewa]

Ik denk dat je daar wel van terug gaat komen. Dat worden zoveel SMSjes dat je uitindelijk besluit om ze naar je spambox te forwarden

[SpiceWorm]

Weet je dat of denk je dat? Er hoeven toch geen mensen bij mijn gegevens het overgrote deel van de tijd?

[bazzi]

En een log die je in kan zien met digid en dan 1x per x een berichtje in je berichtenbox met een overzicht?

[jaapzb]

Als ingezetene van deze gemeente wil ik er toch even op wijzen dat de gemeente "Het Hogeland" heet.

[phizzie]

In 2008(!) heb ik precies om die reden bij een specialist rondom de zaak Elektronisch Patienten Dossier aangedrongen op een oplossing die bijvoorbeeld:
- een patient laat op verzoek ontsleutelen voor het relevante deel van de patientgegevens, zoals bijvoorbeeld met de chipkaart in Duitsland (proportionaliteit)
- gegevens van een patient buiten bewustzijn kunnen enkel ingezien worden
-- met een melding aan de patient, bijvoorbeeld per brief en/of SMS (notificatieplicht)
-- indien de mobiele telefoon van de patient zich bevindt bij een zendmast bij de plaats waar de patient is (locatiegebonden en gekoppeld)
-- met slechts het gedeelte van medische gegevens die relevant kunnen zijn voor de type behandeling die vereist is (proportionaliteit)
-- met een herleidbaar kenmerk van de inziener (herleidbaarheid)
Dat doen we nog steeds niet

[tweaknico]

wow exporteren van gegevens die "extra beveiligd" bewaard moeten blijven naar een onbetrouwbaar medium.. (kunnen we het wereld kampioenschap meeste overtredingen in een handeling openen?)

[Sinnergy]

Je hebt een punt, maar het probleem hier lijkt me dat het geen zin heeft als dus die externe factoren ook niet dezelfde standaard volgen. Dan krijg je schijnveiligheid.

Voorbeeld: Amazon laat niet toe dat je 'persoonlijke' info kan ophalen via hun seller APIs zonder dat je hun super strenge beveiligingseisen volgt (waaronder encryptie van al deze data). Netjes zou je denken.. Maar je kan perfect op de web interface inloggen en 'manueel' (of via een scraper..) aan dezelfde 'persoonlijke' info die dan bvb in een Excel opgeslagen wordt voor boekhouding, dan is het plots 'OK'.

Nu, wil niet zeggen dat zo'n encryptie niet zou 'moeten' maar dan moet dit een plan worden dat voor een heel land telt én afgedwongen wordt op elk niveau. Maar ook daar weer zal je uiteindelijk op de 'mens' moeten vertrouwen, of men moet het onmogelijk maken om screenshots te nemen, tekst te kopiëren, foto's te nemen, filmpjes te maken, iets af te printen, ...

[Jaatoo]

Iets niet doen omdat iemand er misschien omheen gaat werken is natuurlijk geen argument.

Kom laten we alle belastingwetten afschaffen omdat er mensen zijn die gebruik maken van loopholes.

Sterker nog, gewoon alle wetten want sommige mensen houden zich er toch niet aan.

[Sinnergy]

Ik denk dat je als overheid wel naar het totaalplaatje mag kijken. En hier zien ze blijkbaar dat er wel wat meer moet gebeuren dat dit systeem beveiligen.

Stel dat ze dit uitwerken, en de rest 'later' om dan vast te stellen dat dit niet gaat lukken zo en alles nog eens opnieuw moet gedaan worden. Schijnveiligheid aan een zeer dure prijs dan..

[Jaatoo]

Een stap in de goede richting is een stap in de goede richting. Het hoeft niet in een keer goed.

Juist dat oneindige vooraf alles proberen uit te pluizen is duur.

[SirLenncelot]

welkom in de dagelijkse praktijk waar gemak het vaak wint van gezond verstand.

[lololig]

Dan moet je het gemak ook bieden in de veilige omgeving, dan kan de ambtenaar gewoon netjes werken. Ook zou je dan alle ongewenste activiteiten kunnen dichttimmeren. Bijvoorbeeld door het onmogelijk te maken om bestanden op een usb stick te zetten of dat je alleen kunt exporteren naar een beveiligde omgeving (waaruit je dan ook weer geen copy-paste moet kunnen doen)

[RobbieB]

Exact, en dat zijn precies de betere manieren van beveiligen waar de staatssecretaris naar verwijst.

Disk encryptie van deze data beschermt alleen tegen het uitzonderlijke scenario dat iemand het Datacentrum binnenloopt, de juiste schijven uit het rack haalt en dan met forensische tools de data probeert eruit te halen.

Nu kun je er een hoop geld en energie in gaan steken om dit mogelijk te maken, een key management lifecycle en processen op te zetten etc. om dit ene onwaarschijnlijke scenario af te vangen.

Of je steekt dat geld en de energie in maatregelen die op grote schaal waarschijnlijkere scenario's afvangen zoals jij hierboven beschrijft.

Risk Management 101.

[telskamp]

Nu kun je er een hoop geld en energie in gaan steken om dit mogelijk te maken, een key management lifecycle en processen op te zetten etc. om dit ene onwaarschijnlijke scenario af te vangen.

Want de overheid moet het wiel opnieuw uitvinden? Volgens mij moet je je best doen om een stroragefabrikant te vinden die dit niet standaard in zijn producten aanbied..

[Reloader]

tja, en dan kom je weer in aanbestedingsland terecht. de aanvraag is niet 100% sluitend beschreven. en aangezien de gunning in 99% van de gevallen gaat op prijs wordt een product geleverd wat achteraf net iets te kort komt.

sterker nog de aanvraag wordt vaak geschreven door een voorkeurs reseller en die schrijft de aanvraag zo dat huis de beste kans heeft om als winnaar uit de bus te komen. Waarom ingewikkelder schrijven dan gevraagd?

[Reactie gewijzigd door Reloader op 24 juli 2024 12:23]

[eborn]

Staat er uberhaubt vermeldt op welk niveau er encryptie gebruikt moet worden? SSL encryptie is een heel ander beestje dan disk encryptie of record encryptie.

[P_Tingen]

In theorie heb je helemaal gelijk. In de praktijk werkt het helaas niet altijd zo.

[StefanJanssen]

Dan maken ze er een screenshot van en ligt de data ook op straat.

[Unsocial Pixel]

Helaas gebeuren dit soort dingen wel, men wil graag zijn bites snel makkelijk en simpel kunnen verorberen. Van mij mag in dit stuk nog wel een cursusje gegeven worden (incl certificering?) en mogelijk boetes op persoonlijke grond bij het niet naleven van

[SunnieNL]

Tja, dan kun je net zo goed helemaal niet aan beveiliging doen, als iedereen maar een export maakt.

Beveiliging is een optelsom van zaken. Versleuteling van data aan alle kanten hoort daar ook bij. Database gegevens versleuteld aan beide kanten, exports alleen op versleutelde discs, inlogaccounts met 2FA authenticatie (liefst in vorm van certificaat), auditlogs, maximum hoeveelheid gegevens die je mag exporteren per account per uur.

Anders kun je net zo goed de deur wagenwijd openzetten (waarom inlogaccounts gebruiken als iedereen maar exports maakt naar onbeveiligde discen)

[Kees]

Klopt, en dat is dan ook precies wat ze eerst gaan doen. Het heeft niet zoveel nut om de database als eerste helemaal te encrypten als een willekeurige gemeenteambtenaar daarna een exportje op een usb stick kan zetten.

Zoals het artikel zegt: "Op dit moment valt er meer winst te behalen door het nemen van andere maatregelen dan extra versleuteling", schrijft Knops. Wel houdt hij een slag om de arm: versleuteling kan in de toekomst mogelijk alsnog nodig zijn.

[R4gnax]

Klopt, en dat is dan ook precies wat ze eerst gaan doen. Het heeft niet zoveel nut om de database als eerste helemaal te encrypten als een willekeurige gemeenteambtenaar daarna een exportje op een usb stick kan zetten.

Zoals het artikel zegt: "Op dit moment valt er meer winst te behalen door het nemen van andere maatregelen dan extra versleuteling", schrijft Knops. Wel houdt hij een slag om de arm: versleuteling kan in de toekomst mogelijk alsnog nodig zijn.

Het punt is dat het concept van defense-in-depth via versleuteling op alle lagen moet bestaan uit een integrale oplossing die van voor tot achter werkt. Je kunt als je dat toe wilt passen eigenlijk niet verzaken om ook de database meteen mee te nemen in je opzet, want anders wordt het later een hoofdpijn-geval om het alsnog te doen. Dan krijg je een niet goed-doordacht proces wat zaken houtje-touwtje aan elkaar knoopt (overheids-ICT is daar kampioen in) en vanuit zichzelf ook weer risico's tot misbruik zal bevatten.

[Reactie gewijzigd door R4gnax op 24 juli 2024 12:23]

[daanb14]

Ik denk dat men dan sowieso het exporteren van die data moet blokkeren en op zijn minst 2FA ingesteld moet zijn om die data te zien.

[TheMak]

Ik denk dat exporteren altijd nodig zal moeten zijn. Bijvoorbeeld, de politie op de antillen die graag wil weten wie die meneer Dweiland is die in een onderzoek opduikt. Dan geef ik de politie op de Antillen liever een export van de vijf Dweilands die nog leven, dan dat ik de Antilliaanse politie toegang geef tot het hele GBA.

[daanb14]

Het lijkt mij toch dat het GBA een vorm van access management heeft?

[mr.Millenarian]

Dan heet dit plichtsverzuim voor de beste Tammo, waar ontslag op staat. Bovendien als gegevens worden gedownload voor werkzaamheden moet dit in een logfile worden genoteerd lijkt mij.
De encryptiesleutel moet ook niet aan het personeel zelf worden gegeven, maar in de 'beveiligde' computer van deze gebruiker staan. Daar wordt bovendien bij een aantal diensten al een blokkade ingebouwd tegen download op externe gegevensdragers. Dat heeft dan voor de geautoriseerde gebruiker geen nadelige gevolgen om ermee te kunnen werken.

[Reactie gewijzigd door mr.Millenarian op 24 juli 2024 12:23]

[Knoose]

Je kunt wel vanuit de gemeente een beleid opstellen dat dit niet mag (en dit gebeurt gelukkig ook)
Je kunt de medewerkers natuurlijk moeilijk tegenhouden als ze dat op deze manier willen doen, echter mocht er daaruit een datalek ontstaan dan weet je wie je moet hebben.

Overigens is het mogelijk om dit soort dingen via een AD af te kaderen, ik heb zelf servicedesk bij een gemeente gedraaid en gezien dat er veel authorisaties voor applicaties en databases uit AD groepen gehaald werden, zo niet dan was er wel functioneel beheer voor. Ik zie niet in waarom dit niet ook voor het GBA zou kunnen.

Daarnaast, als de versleutelde gegevens op de een of andere manier in handen komen van kwaadwillende personen en ze hebben de sleutel niet, dan hebben ze er alsnog niets aan.

Iedere verdediging helpt, ookal is het maar een klein beetje.

[Brahiewahiewa]

Iedere verdediging helpt, ookal is het maar een klein beetje.

Dus dan moeten we er maar weer miljoenen belastinggeld tegenaan gooien? Om 0,0001% van de misbruik gevallen te voorkomen?

[Knoose]

Voorkomen is beter dan genezen. Ikzelf zie graag dat het belastinggeld dat ik betaal aan beveiliging van gegevens wordt uitgegeven.

Dat nieuwe blitse gemeentehuis dat duurder uitpakt dan ingeraamd hoeft van mij weer wat minder. (niet dat ik hiermee wil impliceren dat jij dit wel belangrijk vindt, maar er zijn ergere dingen waar een overheid geld aan kan verspillen)
Maar ik erken dat over beidde dingen anders gedacht kan worden

edit: enige nuance aanbrengen

[Reactie gewijzigd door Knoose op 24 juli 2024 12:23]

[nullbyte]

Een bulk export maken van dergelijke gegevens zou niet mogelijk moeten zijn.

[Zomborro]

Dat is op zich niet goed maar wees er van bewust dat een goede beveiliging nooit een enkele oplossing heeft, maar veel beter kan bestaan uit meerdere lagen dus encryptie, hardening, MFA, etc. Dus toegangsbeleid is een, maar de rest graag ook.

[Robbaman]

Maar waarom zou iedereen over de sleutel moeten beschikken.
Dat zou voorbehouden zijn aan geautoriseerd personeel.

Maar wellicht is de situatie wel zo, dat om het werkbaar te houden er zoveel geautoriseerd personeel nodig is (kunnen natuurlijk niet bij elke rijbewijsaanvraag Bob van IT bellen), dat het onbegonnen werk is om de encryptiesleutel geheim te houden.

Ik ben geen security-expert, maar ik wil ook weer niet zonder meer stellen dat het onmogelijk is dat de beste man wel degelijk een punt heeft dat encryptie in dit specifieke geval niet veel toevoegt, maar het wel veel moeilijker en duurder maakt.

[The Zep Man]

Maar wellicht is de situatie wel zo, dat om het werkbaar te houden er zoveel geautoriseerd personeel nodig is (kunnen natuurlijk niet bij elke rijbewijsaanvraag Bob van IT bellen), dat het onbegonnen werk is om de encryptiesleutel geheim te houden.

Andersom zou je encryptie ook aan autorisatie kunnen koppelen. Niet iedereen hoeft elk veld te lezen en te schrijven. Ook daar zijn oplossingen voor. Combineer dat met goede logging (wie deed wat op welk moment) en actieve beveiligingssystemen (5000 leesacties in 30 seconden is een beetje veel...), en je komt al een heel eind.

Andersom is encryptie niet de hoogste prioriteit ten opzichte van de rest wat ik voorstel (goed autorisatiebeheer, logging, actieve beveiligingssystemen...).

[Reactie gewijzigd door The Zep Man op 24 juli 2024 12:23]

[Maurits van Baerle]

Ik denk dat autorisatie hier belangrijker is dan encryptie. In een ideale situatie heb je een autorisatiestructuur waar ieder personeelslid en iedere applicatie per gemeente die toegang moet hebben tot deze gegevens en eigen username/password/sleutel heeft.

Als er dan een hack is bij de gemeente Lansingerland dan kun je tijdelijk alle toegang door personeel en applicaties bij de gemeente Lansingerland ontzeggen. Als de hack is opgelost geef je al die accounts weer toegang.

Als Jan Boersma van de afdeling bouwvergunningen in Emmen met pensioen gaat dan kun je permanent zijn account deactiveren en is die post-it op z'n monitor met het wachtwoord niets meer waard.

Maar goed, het lijkt me heel sterk als het bovenstaande niet al lang geimplementeerd is.

[tweaknico]

Denk eens wat er gebeurt als het DC waar de gemeente z'n data opslaat failliet gaat en alles assets op marktplaats komen.
Security onderzoekers kopen graag 2e hands schijven op marktplaats (ebay) om onderzoek te doen, en te oefenen op data extractie. in 2009 had de helft van de schijven die op die manier gekocht waren persoonlijke data.

[Arnoud Engelfriet]

Die harddisks en servers zijn natuurlijk eigendom van de overheid en worden niet met de failliete boedel mee verkocht. Verder is het goed mogelijk dat er al wel full disk encryption (at rest) gebruikt wordt. Beschermen tegen diefstal van de disk is een heel ander model dan beschermen tegen online toegang.

[tweaknico]

Echter geen encryptie implceert ook min of meer geen Full Disk encryptie...

[wica]

Dat weet je niet zeker. Het kan best zijn dat er full disk encryptie van uit het O.S. geregeld wordt.
Maar aan de andere kant, kan ik mij niet voorstellen, dat deze hoeveelheid data. Op een setje disk in RAID opgeslagen wordt.
Maar eerder op een storage laag zoals ceph. Waar de data in blokjes van 4MB in het cluster wordt opgeslagen.
Wij hebben een Ceph cluster van zo'n 3000 disks, ik wens je veel succes om daar een paar disks van te stelen en er data vanaf te halen.
Daarnaast worden disks, die uit een server gaan, direct vernietigd.

[tweaknico]

Ook door een curator als je bedrijf om zou vallen? Of gaat de zaak dan naar marktplaats om nog iets uit de failliete boedel te halen... Ik denk het laatste.

[wica]

Dit soort data, staat echt niet bij een bedrijfje wat zo bankroet gaat. En mocht dat wel zo zijn, dan springt de overheid in om de boel over te nemen.

[Pinkys Brain]

Er zijn scenarios te bedenken waar encryptie toch nog iets toevoegd.

Als ze root access op de storage server hebben maar niet op de database server kunnen ze zonder encryptie met een beetje inspanning nog steeds data eruit halen.

[wica]

Ik ben het 100% met je eens. Ik adviseer onze klanten altijd gebruik te maken van disk encryptie. Al is het alleen maar, zodat ik niet per ongeluk data van ze zie.

Zover ik weet worden volumes wel encrypted. Daar zit ook geen echte kosten aan of technische uitdaging in.

[pe0mot]

Zolang men de rijkspassen deelt om het werk te kunnen uitvoeren zal dit nooit opgelost worden.

[tweaknico]

Zouden mensen dat blijven doen als de boete erop 1 (bruto) maandslaris / overtreding is?
(Ik geloof dat een boete van de overheid naar eigen personeel max. 10% van het maand salaris mag bedragen, dat was ooit in het verleden zo, ik weet niet of dat nog zo is).

Of ontslag op staande voet, zonder wachtgeldregeleing.

[Reactie gewijzigd door tweaknico op 24 juli 2024 12:23]

[Arnoud Engelfriet]

Het doet me wel héél raar aan dat er kennelijk een noodzaak is dat je elkaars pas gebruikt om ergens bij te kunnen. Dan is je bedrijfsproces toch heel gek ingericht? Dat dan weer oplossen met boetes voelt de verkeerde kant op.

[5pë©ïàál_Tèkén]

Wat gek is voor de een is praktisch voor de ander. Als men het kwaad er niet van inziet gaat men voor de weg van de minste weerstand. Een admin pasje voor de afdeling dat eerst aan het koffiezetapparaat hing 'maar na een review van de regels' werd deze opgeborgen in een lade waar iedereen bij kan. Als je zo jaren hebt gewerkt, dan is het bewustzijn omtrent rechtenbeheer nagenoeg niet bestaand. En dan 'opeens' zo veel 'gedoe' met rechten, tja dan leven de regels wel in het hoofd van mensen, maar de geest van de regels komt niet binnen.

[tweaknico]

Ik geloof dat er de afgelopen weken ihkv van corona voorkomen redelijk gebleken is dat "gezond verstand" gebruiken niet iets is dat veel nederlanders verweten kan worden. Dat beperkt zich zeker niet tot corona.

[mr.Millenarian]

Op plichtsverzuim staat al ontslag op staande voet. Alleen een rechter kan hier nog vanaf wijken wanneer bijvoorbeeld de werkgever voor te weinig passen heeft gezorgd.

[pe0mot]

Goed punt, echter gaat het niet om het aantal passen, maar de rechten die er aan gekoppeld zijn:
Piet heeft geen rechten voor een applicatie, dus leent hij de pas van Carla. "Het werk moet wel gedaan worden, en rechten aanpassen kost maanden".
Of meer ons vakgebied: "Hoe moet ik als ICT'er de productieomgeving testen als ik niet alle functies kan testen? Mag ik je pas?"
.

[Reactie gewijzigd door pe0mot op 24 juli 2024 12:23]

[R4gnax]

Of meer ons vakgebied: "Hoe moet ik als ICT'er de productieomgeving testen als ik niet alle functies kan testen? Mag ik je pas?"

De antwoorden daarop behoren niet en nee respectievelijk te zijn.
Toegang tot de productieomgeving dient enkel voor inspectie en onderhoud van het platform.

Als je de applicatie moet testen, dan dien je dat op een separate staging omgeving te doen die hetzelfde ingericht is en waar dezelfde applicatie met dezelfde instellingen op draait, met als enige verschil de privacy-gevoelige databases en andere connected services waarnaar verbonden wordt. Die verbinden naar dummy omgevingen waarmee getest kan worden.


Dus in die zin is het een goed voorbeeld:
het correcte antwoord is namelijk dat er iets in je proces-structuur niet deugt wanneer het nodig is die vraag überhaupt te stellen.

[Reactie gewijzigd door R4gnax op 24 juli 2024 12:23]

[mjtdevries]

Dat is de theorie. Praktijk is soms anders.

Er zijn productie omgevingen die zodanig groot en complex zijn dat het onbetaalbaar is om een echt representatieve test omgeving te maken. Dus dan kan het wel degelijk voor komen dat je sommige dingen in een productie omgeving moet testen.
En soms moet je een uitrol in productie valideren.

Maar als voormalig test manager heb ik nooit gevraagd: "mag ik je pas"
Nee, de enige opties die we voorstelden waren:
- Is het mogelijk om een tester tijdelijk toegang te geven voor de tests?
- indien data te gevoelig is: kun jij de test voor mij uitvoeren?

[R4gnax]

Helemaal mee eens. Soms is het inderdaad niet praktisch mogelijk of gewoon helemaal niet mogelijk om direct contact met een productieomgeving te vermijden. En in die gevallen moet je daar inderdaad gereguleerd mee omgaan, zoals je al beschrijft.

Wat ik beschreef is dan ook meer de hoofdlijn. Wat jij hier beschrijft is een niet minder belangrijke uitzondering. Dus bedankt voor de aanvulling.

[pe0mot]

[...]
Dus in die zin is het een goed voorbeeld:
het correcte antwoord is namelijk dat er iets in je proces-structuur niet deugt wanneer het nodig is die vraag überhaupt te stellen.

Super, bonuspunten. Het juiste antwoord!

[tweaknico]

Mooi dan is dat al geregeld.

[The Zep Man]

Zouden mensen dat blijven doen als de boete erop 1 (bruto) maandslaris / overtreding is?

Je maakt de veelvoorkomende denkfout dat zwaarder straffen helpt. Dat doet het niet. Het enige dat helpt is de pakkans verhogen.

Met een relatief lage straf en een pakkans van 100% zal niemand snel iets doen dat niet mag. Met de hoogste straf die je kan bedenken en een pakkans van 0,01% zullen alsnog veel mensen vaak de gok nemen.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 12:23]

[Anoniem: 14842]

Ik denk dat jullie iets belangrijks vergeten. Mensen doen dit niet omdat ze een criminele inslag hebben. Mensen delen veelal hun account gegevens omdat de inrichting niet op orde is en ze anders hun werk niet kunnen doen.

Ga je dan de persoon die het account deelt straffen? Of de werkgever die het onmogelijk maakt het werk correct uit te voeren?

Zelfs bij de overheid willen mensen gewoon hun werk doen. 8 uur betaald achter een bureau zitten omdat ze niet bij de juiste gegevens kunnen willen veel mensen nu eenmaal niet.

Ik ben zelf een security specialist en ik denk dat jullie, zoals zoveel op T.net, het een beetje te zwart/wit zien.

[tweaknico]

Dan zal uit een onderzoek blijken dat IEDEREEN in een organisatie het fout doet, in dat geval faalt het bestuur van de organisatie op meerdere manieren....
(niet aanpassen van een onwerkbare situatie.. niet signaleren van ongewenste werkprocedures, niet voorzien in voldoende middelen om werk uitgevoerd te krijgen, niet tijdig mensen autoriseren, ).

Als de werknemers dat ook aangegeven heeft gaat de aansprakelijkheid over op de organisatie...

De conclusie van het onderzoek is dat er wat moet gebeuren.
De reactie van de hoogste baas (staatssecretaris Knops) in de keten is een soort "excuus truus" reactie, dat het ook anders kan.

[Ikzellef]

@Mecallie Hé hé eindelijk iemand met een heldere blik!

[Reactie gewijzigd door Ikzellef op 24 juli 2024 12:23]

[wica]

Uhmm, je hebt bij het ontvangen van je Rijkspas toch ondertekent, dat je hem nooit zal uitlenen?
Sterker, als je dit ziet. Ben je verplicht er een melding van te maken bij je Security officier.

[Nopheros]

Aangezien er grote aantallen gebruikers bij deze data moeten kunnen betekend dat dus ook dat op dat moment de data onversleuteld moet zijn. In dat opzicht is het dus, volgens de minister, niet perse de beste oplossing.

Je wilt je laptop hdd versleutelen omdat deze bij diefstal dan veilig is. Echter als je de laptop hebt openstaan dan is de data niet versleuteld en dienen er andere maatregelen aanwezig te zijn om de data veilig te houden. Blijkbaar is de conclusie dus dat er met andere veiligheidsmaatregelen (bijv. betere toegangscontrole, logging etc) meer winst te behalen is.

[Reactie gewijzigd door Nopheros op 24 juli 2024 12:23]

[icecreamfarmer]

Je hebt 100.000en aan geautoriseerde personen. Bijna elke zorgorganisatie kan er bijvoorbeeld al in.
En dat zijn ook de individuele tandartsen en huisartsen.

[tweaknico]

Die hebben ook al een toegangs registratie plicht...
Facebook heeft een paar miljard klanten, en kan daar toch verschillende niveaus in aangeven. Schaal is NIET het probleem. Het is alleen iets om rekening mee te houden.

[Reactie gewijzigd door tweaknico op 24 juli 2024 12:23]

[Proliges]

Je vergelijkt appels met peren. Facebook is een cloud omgeving en is een entiteit op zichzelf. De BRP is geen entiteit op zichzelf maar een verzamelnaam van honderden verschillende instanties die allemaal hun eigen on premise omgeving beheren. (op een aantal uitzonderingen na)

[Reactie gewijzigd door Proliges op 24 juli 2024 12:23]

[tweaknico]

Een cloud is ook maar een samenstelsel van allerlei losstaande servers en ondersteunende systemen.
JUIST in die omgeving is er cryptografische beveiliging van belang....

Strict genomen is BRP een cloud (avant la lettre?) databse. Verregaand gedistribueerd en over een veelheid van platfoms. Dan moeten ze nog steeds aan de basiseisen voor een dergelijke registratie voldoen. Hoe kan je data vertrouwen die mogelijk door jan en alleman op een afgelegen locatie ingezien/veranderd kan worden?

[Proliges]

Nee de BRP zijn voornamelijk on premise omgevingen die door de locatie waar deze omgeving staan benaderd worden. Het is voor de gemeente Eindhoven nutteloos om de gegevens van inwoners van Amsterdam in te zien (en dat mag ook niet dus wat dat betreft is er al beveiliging).

De SaaS omgevingen en de API's versturen de data wel beveiligd onderling en niet jan en alleman mag de data aanpassen. Het is wel mogelijk dat er intern aanpassingen gedaan worden zonder dat deze de bedoeling zijn.

[tweaknico]

Cloud zegt helemaal niets over de manieren waarop de systemen met elkaar communiceren.
Cloud is vrij hol begrip, in de trand van "Ergens op het netwerk", alleen iets korter.

Ik heb een sterk vermoeden dat dit voortkomt uit netwerkschema's de details van het netwerk in een wolk werden getekend.
Dus een bundel systemen verbonden met API's is een accurate beschrijving van een cloud omgeving.

[Reactie gewijzigd door tweaknico op 24 juli 2024 12:23]

[Proliges]

Nee dat klopt, dat zegt niet s over de manier waarop gecommuniceert wordt (dat beweer ik overigens ook niet) De systemen die wel onderling communiceren via API's zijn wel beveiligd. Dat is wat ik zeg.

[icecreamfarmer]

Ja en wat gebeurd daar mee?
Precies niets. Het wordt geregistreerd maar geen hond komt er achter als je wat zit te grasduinen want niemand controleert die logs.

[CivLord]

Heel veel organisaties hebben voor de uitvoering van hun werk toegang nodig tot bepaalde gegevens. Sowieso alle overheidsorganisaties die gebruik maken van persoonsgegevens. (Dat voorkomt bv. dat het RDW je brief naar je oude adres stuurt, omdat je met je 100 adreswijzigingen net die naar het RDW vergeten was. Het maakt een groot deel van die 100 adreswijzigingen ook overbodig. Het maakt ook vele afzonderlijke adressendatabases met mogelijke fouten overbodig.)
De meeste van die organisaties hebben ook meerdere systemen die allemaal afzonderlijk toegang tot de BRP hebben. Het systeem waaruit de aanslag WOZ-belasting wordt verstuurd (die de NAW-gegevens uit de BPR haalt) is weer een ander systeem dan waaruit een rijbewijs wordt aangevraagd, etc.
Wanneer je de gegevens in de BRP gaat versleutelen, moet je al die systemen, waarschijnlijk duizenden, een sleutel geven. En waarschijnlijk moet je bij veel van die systemen ook nog een 'handje' inbouwen die die sleutel kan gebruiken. Dat is een mega-operatie die klauwen met geld gaat kosten en die gegarandeerd leidt tot een grote chaos. Ik zou haast zegen mislukking gegarandeerd.

En dan wil je nog verschillende categorieën gegevens verschillend versleutelen voor verschillende categorieën medewerkers.

[tweaknico]

Bij (correct) encrypted data kan de data idd. encrypted verspreid worden.
In hoeverre die blob ontsleuteld kan worden kan dan idd ook op persoon niveau geregeld worden.
Het kan geen kwaad als iedereen met toegang geaccrediteerd wordt.

[Proliges]

Omddat vrijwel elke ambtenaar een sleutel heeft tot persoonsgegevens. Van belastingdienst tot gemeente en alles er tussenin.

[Proliges]

Bezoekers en inbrekers zijn volgens mij geen ambtenaren.

Maar schoonmakers en beveiligers zijn nou net de mensen die meestal wel toegang hebben tot bepaalde ruimtes waar gevoelige informatie wordt opgeslagen.

We hebben het hier niet over 1 instantie die de BRP beheert.. Het gaat over honderden verschillende instanties.

We hebben het over honderduizenden mensen die gautoriseerd zijn om gegevens uit het BRP op te vragen.

[Reactie gewijzigd door Proliges op 24 juli 2024 12:23]

[tweaknico]

Bij versleutelde data is een decryptie sleutel vereist==> er moet iets van toegang geauthoriseerd zijn.
(Met controle via audits.) anders is er geen toegang.... .
Of je het voor 1 persoon regelt of voor 1 miljoen personen is een kwestie van schaal, en iets om rekening mee te houden.
Het kan geen belemmering zijn.

En is het alles of niets toegang toto een record...
Er is mi. een verschil tussen NAW controle, en een compleet doopceel inclusief strafblad etc.

De inbrekers hebben dus zonder ambtenaren pas geen toegang.. ie. dat pleit dus voor encryptie.

[Proliges]

Wat voegt encyptie nou toe in een on-premise omgeving van bijv een gemeente?

[tweaknico]

Beveiliging tegen diefstal van de servers?
(of schijven uit servers).

[Proliges]

Dan ben je dus aan het beveiligen tegen de situatie dat er iemand ongeautoriseerd de server ruimte inloopt, Daar de juiste racks uit de server trekt en vervolgens op een andere locatie deze data uit gaat lezen.

Daarbij zijn de serverruimtes meestal toch al wel beveiligd dus dan heb je het over een gerichte diefstal door iemand met voorkennis over welke racks er meegenomen moet worden. Volgens mij ben je dan niet efficient bezig.

Een veel waarschijnlijker scenario is dat iemand data kopieert en doorstuurd of op een USB stick zet en deze verliest.

[Reactie gewijzigd door Proliges op 24 juli 2024 12:23]

[walteij]

Toegangsbeleid is autorisatie, encryptie is file-level beveiliging, 2 totaal verschillende dingen.
Natuurlijk is het belangrijk om een goed toegangsbeleid (en audit policy) te hebben, maar daarmee beveilig je de database niet op file niveau.
Daarvoor is juist de encryptie bedoelt.

Heel simpel, als jan en alleman toegang moeten hebben tot de database, is er een account voor Jan, maar ook een account voor Alleman (heel veel accounts dus). Ieder account heeft in de database toegang tot de basisgegevens van personen waar zij de gegevens van moet kunnen inzien (inwoners van de woonplaats voor een gemeente).
Worden het account onderschept, zal degene die ze onderschept heeft alleen bij de gegevens komen waarvan het account is gecompromitteerd, ongeacht of de database is encrypt of niet.

Database encryptie heeft toegevoegde waarde voor het voorkomen dat de server waarop de database bestanden staan wordt gecopromitteerd. Een niet-encrypted database slaat data gewoon op in leesbare tekst. Een handige jongen kan dus gewoon alle data uit die database trekken door de authenticatie en authorisatie te ontwijken als hij/zij toegang heeft tot de bestanden.

Dat kan dus niet zomaar meer als de database encrypt is.

Encryptie en toegangsbeleid zijn 2 totaal verschillende manieren van data bescherming, maar de beste beveiliging is nog steeds beiden toe te passen.
Beveiliging is niet één laag, maar meerdere lagen na elkaar die elkaar versterken. Een lek of fout in laag 1 kan opgevangen worden door laag 2, 3....10, een lek in laag 6 wordt al tegen gehouden in laag 2 en ga zo maar door.

[Reactie gewijzigd door walteij op 24 juli 2024 12:23]

[Niet Henk]

Precies. Het gaat allemaal om je threat model en hoe je dit het best dekt.

Technieken als encryption at rest dekken bijzonder weinig als je servers on-premises staan, hooguit een kwaadaardige ICT beheerder die een harde schijf uit een server trekt en gaat uitlezen, een dief die je datacenter binnendringt en daar een rack meeneemt, of het per ongeluk verkopen van een server/schijf die persoonsgegevens bevat. Met degelijke fysieke beveiliging en management van oude en defecte apparaten kunnen deze prima gedekt zijn.

Een belangrijk ding is dat encryptie niet rechtenbeheer is. Zonder encryptie kan je prima zorgen dat mensen enkel toegang hebben tot de data waar ze goede rechten voor hebben.

Het kan zeer zeker dat andere punten meer prioriteit hebben.

[Sando]

Ik denk dat staatssecretaris wel degelijk een punt heeft als hij zegt dat versleutelen weinig zin heeft als jan en alleman een sleutel heeft.

Blijkbaar worden jan en alleman vertrouwd. Één veelvoorkomend probleem is het hacken van servers waar de data opstaat, en het lekken of misbruiken van deze data. Dáár is die versleuteling een oplossing voor. Het overkomt de besten.

Je gaat ook niet de entree van een kerncentrale vrij maken omdat 120 werknemers toch een sleutel hebben.

[J_van_Ekris]

Je gaat ook niet de entree van een kerncentrale vrij maken omdat 120 werknemers toch een sleutel hebben.

Niet de entree, maar als je eenmaal binnen de centrale bent, is het onzinnig op elk punt nogmaals te blijven controleren of je geautoriseerd bent. Het staat immers het vermogen om te handelen (in noodsituaties) in de weg. Dus je controleert streng aan de poort, en minder streng eenmaal binnen omdat het bedrijfsproces nu eenmaal randvoorwaarden oplegt om goed te kunnen functioneren.

Het bedrijfsproces van het managen van gegevens van burgers vereist nu eenmaal dat veel ambtenaren bij je persoonsgegevens kunnen (want je moet babies kunnen inschrijven, documenten kunnen aanvragen en kunnen verhuizen). Diezelfde gegevens zijn vorvolgens vrij breed beschikbaar voor andere partijen met autorisatie: het is immers een basisregistratie, en daarmee de enige en authentieke bron voor persoonsgegevens binnen de overheid. Ik ga er vanuit dat de applicaties en API's zaken afschermen waar je niet bij hoeft te kunnen. Maar om dat via encryptie nogmaals op data-element niveau over te doen zou wel eens meer ellende kunnen opleveren dan het ooit oplost. Encryptie is maar een van de vele mogelijkheden tot dataminimalisatie, niet de enige.

[Maurits van Baerle]

Volgens mij gaat het niet om jan en alleman maar zijn er in iedere gemeente waarschijnlijk al een tiental applicaties en minstens evenveel personen die toegang tot deze data moeten hebben. Over heel Nederland heb je het dan al makkelijk over een honderd applicaties en tienduizend mensen die voor hun werk toegang tot deze data nodig hebben. Daar is die centrale registratie ook voor bedoeld, dat het uitgelezen kan worden voor zaken waar dat nodig is.

[xMuchux]

Dit. Zoals vaak bij de overheid wordt er vaak aan symptoombestrijding gedaan (brandjes blussen) en niet gezocht naar het eigenlijke probleem (de aanstichter zoeken).

[n4m3l355]

Duidelijk, maar tegelijkertijd ook schrikbarend dat omtrend deze data nog steeds blijkbaar geen fatsoenlijk protocol bestaat. Zoals je zelf al aangeeft potentieel zitten duizenden mensen aan deze basis registratie, terwijl deze informatie zo misbruikt kan worden. Bij grote bedrijven gaat men hier streng mee om (en ook daar gaat het vaak fout) maar de overheid heeft hier nog niets voor geregeld?

[CivLord]

Wie zegt dat er geen fatsoenlijk protocol bestaat?
Iedereen bij elke overheidsorganisatie die persoonsgegevens nodig heeft voor zijn werk, heeft toegang tot (een deel van) de basisregistratie. Puur omdat ze dat nodig hebben voor hun werkzaamheden.
Alles bij elkaar zijn dat waarschijnlijk meer dan 100.000+ mensen. Een paar zullen misschien een inkijk in de registratie zelf hebben, met alle geregistreerde gegevens, de meeste werken in en systeem waarin ze niet meer kunnen zien dan de gegevens die het systeem nodig heeft voor het uitvoeren van specifieke werkzaamheden.

Bij verschillende overheidsorganisaties waar ik gewerkt heb wordt regelmatig gekeken of autorisaties nog kloppen. Wanneer je dan niet snel genoeg reageert, of de naam van een autorisatie niet kunt plaatsen (soms heeft een autorisatie de naam van de voorganger van het systeem waarvoor je het nu gebruikt), kan het zo maar gebeuren dat je opeens niet meer bij de gegevens kan/ in de systemen kan de je nodig hebt voor je werk.
Er zijn dus zeker protocollen wie, waar, voor welke gegevens is geautoriseerd.

[R4gnax]

Ik denk dat staatssecretaris wel degelijk een punt heeft als hij zegt dat versleutelen weinig zin heeft als jan en alleman een sleutel heeft.

Ik denk van niet. Het heeft nog steeds heel veel zin. Een versleutelde database heb je niet zo veel aan als je niet ook een werkende sleutel hebt. Bulk-exfiltratie door bijv. direct toegang tot de database proberen te bemachtigen en een dump te maken, wordt op die manier al bemoeilijkt.

Je moet data gaan exfiltreren via de reguliere endpoints die over een sleutel beschikken. Deze endpoint sleutels hoeven ook niet 1-op-1 te corresponderen met de database sleutels, maar kunnen gekoppeld worden aan een systeem wat tijdelijke sleutels opbouwt met sessies die via 2FA gevalideerd moeten worden. Deze tijdelijke sleutels kunnen toegang verlenen tot de werkelijke DB sleutels en zo samen toegang tot de DB en de data geven.

Zo kun je een single point of failure in de hele keten wegnemen.
Anders dan regel-voor-regel exfiltratie op een geinfecteerd endpoint. En dat zal altijd een risico blijven.

[Reactie gewijzigd door R4gnax op 24 juli 2024 12:23]

[Dorank]

Er is geen reden om niet te encrypten. Dat de rest van de toegang niet op orde is doet er niet toe, de eerste stap naar dit verbeteren moet ergens gezet worden.

[bbob]

Deels heeft hij natuurlijk gelijk, de basis is een toegangssysteem wie wel en geen toegang heeft.
Dat neemt echter niet weg dat als data niet versleuteld verstuurd worden het onderschept kan worden en er dan alsnog inzage mogelijk is.
Als iemand toch via via toegang krijgt help versleuteling ook altijd.

Dus ja versleuteling zelf is niet de oplossing maar moet gewoon onderdeel van een totaalpakket zijn. Dat niet mee te nemen is nogal dom.

[GekkePrutser]

Het moet gewoon niet mogelijk zijn dat al die organisaties die data zelf hebben staan. Ze moeten het alleen via een API kunnen benaderen met een goed audit logging systeem. En een alarm als er te veel data benaderd wordt.

Anders is het een kwestie van tijd voordat dit alles een keer bij een hack op straat komt te liggen.

[dnrb]

Helemaal niemand moet die sleutel(s) krijgen.... De database moet worden versleuteld en de software moet de gegevens kunnen ontsleutelen. Daarnaast moet er via een rechten systeem (AD) en/of certificaten worden gezorgd dat alleen geautoriseerde gebruikers de software kunnen gebruiken.
Het grote verschil is dat een uitgelekte backup van de database niet zo makkelijk te gebruiken is.
En het is al meermalen gebeurd dat back-ups per ongeluk online stonden, op een harde schijf bij het oud vuil, etc...
Teleurstellend is wat mij betreft een understatement.

[BvanBart]

Eens! Echter vraag ik me dan ook weer af of de staatssecretaris genoeg kennis van zaken heeft om die belangrijke beslissing te kunnen maken. Het wordt nu wel afgeschilderd als een geld kwestie.

[[Stan]]

Moet er niet eerst een beleidskader rond informatieveiligheid opgesteld worden om van daaruit te bepalen wat de juiste security controls zijn die toegepast moeten worden?

"Versleuteling alleen is geen garantie voor veiligheid." Ik volg dit volledig. Dat is één bepaalde security control terwijl andere risico's niet gedekt zijn.

[illusion101]

Ter info / aanvullend hierop: https://www.informatiebev...atiebeveiliging-overheid/

[PCG2020]

Ik kreeg en krijg mijn digitale post van de overheid in vrijwel alle gevallen gewoon als (beveiligd!) PDF-bestand. Een héél enkele keer kwam het wel eens voor dat er een *.doc-bestand werd gebruikt, maar dat heb ik zelf al heel lang niet meer meegemaakt.

Dus waar je de claim dat "onze overheid" (en dat zijn nogal wat instanties, dus welke bedoel je precies?) "de brief" (welke brief?) in Word-indeling beschikbaar stelt op baseert, is mij eerlijk gezegd een raadsel.

[jeroen_loeffen]

Yabada bedoelt de brief die de staatssecretaris aan de voorzitter van de tweede kamer geschreven heeft uit de link die in het artikel staat: dat is inderdaad een download als .docx. Maar dat is natuurlijk geen communicatie die privé moet blijven...


edit: link

[Reactie gewijzigd door jeroen_loeffen op 24 juli 2024 12:23]

[PCG2020]

Oh, mijn excuses, ik begreep de reactie van @Yabada niet goed. Hij had het dan ook over "de overheid" en niet over "de staatssecretaris" en het was me niet direct duidelijk dat 'ie met "de brief" de Kamerbrief bedoelde. Bedankt voor de opheldering

[MsG]

Als ik op de link klik van de brief download ik toch echt een PDF-bestand. Ik heb nog nooit gehad dat iets in docx-formaat only was vanuit de overheid. EDIT: Ik snap wat je bedoeld. De download-knop opent een .docx, en de bijlagen-knop daaronder download gewoon de PDF. Beetje gek inderdaad.

[Reactie gewijzigd door MsG op 24 juli 2024 12:23]

[shag-me]

Volgens mij is dit lang niet overal zo, op veel plekken krijg je brieven/post digitaal in PDF formaat aangeboden?

[Maurits van Baerle]

Volgens mij mag Word formaat niet eens volgens het 'pas toe of leg uit' principe. Bewerkbare documenten moeten in OpenDocument (ODF) worden aangeboden, niet bewerkbare documenten in PDF.

Hier in het Verenigd Koninkrijk hebben we hetzelfde principe en daar zijn de bewerkbare documenten die je van de overheidswebsite download netjes .odt bestanden.

[FreshMaker]

Mee eens.

Ook teleurstellend is dat onze overheid denkt dat iedereen M$ Word gebruikt, want als je de brief download, krijg je het alleen in M$ Word formaat. Echt, werken daar mensen die geen verstand hebben van digitale communicatie? Anno 2020 is PDF de standaard of biedt het in verschillende formaten. Oja, sorry, my bad, overheid en doordachte simpele beslissingen... Ik moet intussen toch echt beter weten.

En elk bedrijf verwacht dat Jan en alleman zo'n ding ook maar (secure) kan ondertekenen.
De afgelopen maanden al verschillende keren gehad, en het antwoord "Dan print U het uit, en na ondertekening scannen en terug mailen"

Wederom ... er wordt verwacht dat je van alles in huis haalt, want simpel retour sturen van zo'n formulier is ook vaak lastig ( of niet mogelijk )

[dj1981]

Het is alleen niet "de overheid" die dat Word-bestand heeft gepubliceerd, maar de Tweede Kamer.

De overheid zelf is in dit geval het Rijk, en op de website van het RIjk staat de brief dus ook keurig in pdf-formaat.

[Argantonis]

Dat lijkt me een best prima conclusie. Tenslotte zal de sleutel ook ergens in hun infrastructuur moeten worden opgeslagen als ze überhaupt nog wat aan de data willen hebben, dus zo ongelofelijk veel voegt dat niet toe. Het zou wel fijn zijn als de database (en alléén de database) op straat zou belanden maar met daarbij de opmerking "Volgens het onderzoek moeten gemeenten en grote aantallen gebruikers de gegevens uit de BRP in hun eigen systemen kunnen gebruiken." wordt toch al duidelijk dat die data ook al gelokaliseerd wordt door allerlei kleinere instanties met mindere beveiliging.

[Eonfge]

Het sleutel-probleem is inderdaad de voornaamste rede om symetrische encryptie bij opgeslagen data niet in te zetten: Als je vervolgens overal sleutels moet bewaren, dan heeft het de facto geen toegevoegde waarde.

Mijn zus werkt in het ziekenhuis en heeft daardoor toegang tot de medische gegevens van patiënten, en samen met haar nog zo'n tweeduizend andere medewerkers. Het opslaan van de data in een ge-encrypte vorm zal niets toevoegen want al die tweeduizend medewerkers toegang moeten kunnen hebben tot die gegevens. Daarom dat twee-factor pasjes een veel betere investering zijn.

Mijn advies dus aan de overheid: Iedereen zo'n twee-factor pasje, en een goede audit trail zodat elke lees- en schrijfactie achterhaald kan worden. O, en geen email zomaar in de shredder gooien.

[Reactie gewijzigd door Eonfge op 24 juli 2024 12:23]

[CurlyMo]

Mijn advies dus aan de overheid: Iedereen zo'n twee-factor pasje, en een goede audit trail zodat elke lees- en schrijfactie achterhaald kan worden.

Ik ben vooral benieuwd of iemand hier kan bevestigen of dit dan wel of niet gebeurt. Ik kan me namelijk niet voorstellen van niet

[Standeman]

Ik werk zelf aan een stukje dat te maken heeft met het BRP en daar hebben ze specifieke workstations die niet aan het internet hangen en je met een pasje (je encryptiesleutel/certificaat) moet inloggen via dat werkstation om de door jouw organisatie beheerde gegevens in te zien en of te bewerken. Van elke scheet die je laat in het systeem wordt een audit-log aangelegd.

Maar er zijn nog honderden andere systemen bij gemeentes en andere (semi-)overheden waarvan ik geen idee heb hoe dat precies geregeld is.

[Paul]

En toch staat de data van die patiënten vaak degelijk encrypted op de harddisks Ja, een groot deel van je medewerkers kan die data opvragen, en dat is zeker een ingang die je goed moet beveiligen en auditen, maar die schijven (of SSDs) kunnen ook stuk, en die hardware is na een aantal jaar ook afgeschreven.

Als zo'n schijf stuk gaat of het hele array wordt vervangen dan kunnen we die zonder problemen of zonder moeilijk te doen met certified wipen oid terugsturen naar de leverancier (garantie) of verkopen/afvoeren, want zonder de bijbehorende key (die niet op die schijven of de array zelf staat!) kun je niks uitlezen.

Echter, bij ons gaat dat om één systeem. Het GBA / BPR bestaat als ik het goed begrepen heb uit honderden systemen die aan elkaar hangen. Dan is bovenstaande nog steeds een goed idee, maar wel lastiger uit te voeren, en als je je procedures op orde hebt en dingen op een andere manier al borgt dan is de verwachtte winst in beveiliging maar klein en is het misschien mogelijk om met dezelfde moeite of kosten veel grotere problemen op te pakken. Tijd en geld kun je maar één keer uitgeven.

[R4gnax]

Als je vervolgens overal sleutels moet bewaren

Dat hoef je dus niet. Database sleutels groepeer je per x medewerkers die op hetzelfde globale autorisatie-niveau bij dezelfde poel data mogen komen.

Deze sla je centraal zo op dat de sleutels met een meestersleutel ontsleuteld kunnen worden en opnieuw versleuteld kunnen worden met de sleutel die iedere medewerker op zijn/haar individuele pas heeft staan. Deze meestersleutel wordt enkel gebruikt om een medewerker aan een groep toe te voegen. Op dat moment wordt voor die medewerker een nieuwe, speciaal voor hem/haar versleutelde versie van de DB sleutel opgeslagen op de key server.

Het proces van die nieuwe sleutel aan te maken kun je nog inrichten zodat het op een gesloten systeem plaatsvindt en airgapped is, waarbij de daadwerkelijke meestersleutel nooit netwerk-verbonden toegankelijk is.

De encrypted sleutel en de sleutel van de pas gaan beiden naar de database of service in kwestie.
Daar worden ze gebruikt om de DB sleutel te ontsleutelen en deze wordt gebruikt om de opgeslagen data te ontsleutelen en vervolgens te herversleutelen met enkel de sleutel van de individuele medewerker voor transport terug naar het endpoint.

Dit reduceert dramatisch de hoeveelheid verdubbeld opgeslagen encrypted data; en centraliseert je daadwerkelijke key management op een plek die je compleet dicht kunt spijkeren.

[Reactie gewijzigd door R4gnax op 24 juli 2024 12:23]

[djwice]

Volgens het onderzoek moeten gemeenten en grote aantallen gebruikers de gegevens uit de BRP in hun eigen systemen kunnen gebruiken.

Is bijzonder, lijkt me dat het in de meeste zo niet al die gevallen om een sub-set gaat, bijvoorbeeld voor de voedselbank, de parkeervergunning, gebiedstoegang etc.

[CivLord]

Klopt. Maar ze hebben wel de toegang nodig tot die subset.
De overheid is een tijd geleden juist afgestapt van eigen deel-kopieën van de basisregistratie bij verschillende instanties. Die gingen vaak een eigen leven leiden en werden niet altijd juist ververst met gewijzigde gegevens uit de basisregistratie zelf. Daarom kunnen al die verschillende instanties de gegevens die zij nodig hebben direct in de basisregistratie zelf inkijken. Zodat bij een wijziging van de gegevens alle instanties voor wie die wijziging van belang is die wijziging meteen kunnen verwerken. Zodat bij het doorgeven van een verhuizing aan de gemeente, meteen alle overheidsinstanties je juiste adres hebben.
Dat gaat niet altijd goed, maar over het algemeen werkt het zoals het moet werken.

[djwice]

Klinkt heel goed. Dan is een iteratie naar data based access wellicht helemaal niet zo groot en wellicht al grotendeels in place.

En is de stap van encryptie per sub-dataset en daarna per record - indien de sub-set nooit als geheel opgevraagd en wordt, ook mogelijk in de toekomst.

[Zebby]

Er zijn (open-source) oplossingen om je key infrastructuur extern te hosten, maar ja, je zal altijd ergens je keys moeten opslaan. Het is toch echter wel een fijn gevoel, want beveiligen tegen onbevoegden is leuk, maar het hoeft maar 1x fout te gaan om alles te laten lekken, en dan is het toch wel fijn als je data in ieder geval proper versleuteld is...

Je infrastructuur en applicatie beveiligen tegen onbevoegden is een essentieel begin, maar meer ook niet.
Ik zeg het al langer - het is dat ik geen keuze heb in het geheel, maar ik vertrouw de overheid niet met mijn data/gegevens. Schimmig als banken zijn, volgens mij hebben die op dit vlak hun zaakjes beter op orde, net als veel andere commerciële instellingen.

[CivLord]

Zijn er ook oplossingen om honderden gemeentes en overheidsorganisaties met elk misschien tientallen aparte systemen (in totaal dus duizenden verschillende systemen) in één keer geschikt te maken om de gegevens uit hun bronsysteem te kunnen ontsleutelen? Dus zonder elk systeem individueel geschikt te moeten maken om gegevens te kunnen ontsleutelen?

[R4gnax]

Zijn er ook oplossingen om honderden gemeentes en overheidsorganisaties met elk misschien tientallen aparte systemen (in totaal dus duizenden verschillende systemen) in één keer geschikt te maken om de gegevens uit hun bronsysteem te kunnen ontsleutelen? Dus zonder elk systeem individueel geschikt te moeten maken om gegevens te kunnen ontsleutelen?

Ja. Dat heet: hou op met gezever over decentrale opslag; bouw een gecentraliseerd systeem dat één degelijk werkproces ondersteunt; en laat gemeentes en andere instellingen via dat proces werken.

Als er dan een paar zijn die niet constructief mee willen werken daaraan, maar net als kleine kinderen een driftbui krijgen; dan sleep je ze maar krijsend en schoppend aan hun vel mee over de grond.

[Reactie gewijzigd door R4gnax op 24 juli 2024 12:23]

[CivLord]

Het gaat niet alleen om één centraal systeem voor de gemeentes.

Het gaat ook om duizenden systemen bij honderden gebruikers zoals UWV, CBR, Belastingdienst, SVB, pensionfondsen, ziektekostenverzekeraars, etc. die allemaal een deel van de gegevens uit de basisregistratie gebruiken. Al die afzonderlijke systemen moeten dan iets met die versleuteling kunnen doen. Er is geen andere oplossing dan alle systemen afzonderlijk geschikt te maken om de gegevens te kunne ontsleutelen.

[aikebah]

Niet voor de eindoplossing, maar niets houdt je tegen om de core alvast goed te beveiligen en voor beperkte tijd een 'decryptieschil legacy applicaties' beschikbaar te stellen die ze de toegang nog een periode verleent volgens de oude protocollen zodat ieder de eigen systemen gereedmaakt voor de goed beveiligde eindoplossing.
Met een gefaseerd plan kun je die beveiliging dan door het hele landschap uitvoeren en aan het eind van de rit hoef je alleen nog de stekker uit de decryptieschil legacy applicaties te halen.
In de tussentijd kun je op die decryptieschil precies zien wie zich nog altijd misdragen en er beleid op maken om die instanties te forceren over tenstappen naar compliant toegang.
Eventueel nog uit te breiden met een emulatielaag beveiligde toegang als er een probleen is waardoor een core systeem nog niet op de beveiligde wijze kan werken, terwijl je vanuit nieuw ontwikkelde frontends alleen nog via het beveiligde protocol wilt interfacen met het netwerk.
Ook daar heb je dan duidelijke traceability over welke backend nog altijd niet goed beveiligd is, terwijl de nieuwe, goed beveiligde frontend niet nodeloos complex gemaakt wordt om ook nog met een legacy backend te kunnen praten.
Die conversie-lagen zijn natuurlijk wel een bak complexer en een (geaccepteerd) lek in je beveiliging, dus die wil je alleen toepassen als het echt niet anders kan. En die moeten natuurlijk ook een wettelijk gereguleerde houdbaarheidsdatum hebben, want anders passen we niks aan (want dat kost geld en het werkt nu toch ook gewoon)

[tweaknico]

De toegangssleutel om decryptie mogelijk te maken (public key) zou ook aan een "digitale" personeels pas van het personeel gehangen kunnen worden... geen pas geen toegang. en weel pas dan ook GEIDENTIFICEERDE toegang. Het kan dan ook voorbehouden worden aan personen die toegang mogen hebben.
Dus niet effe kijken waar x.y woont oid.
Niet een schoonmaker die even kan snuffelen via een niet afgelogde terminal etc.

Daarnaast als de schijven uit een systeem worden getrokken, hoe is het vernietingsbeleid?
wat gebeurd er met data als een DC failliet gaat waar een gemeente de data had gestald, gaat het hele DC dan door een schredder? Of komende schijven op Ebay, (Marktplaats) terecht.
https://www.cio.com/artic...y-hold-personal-data.html
Je mag hopen dat het sinds 2009 verbeterd is maar ik vertrouw daar niet op.

Aanvulling: in 2019 werkt het nog steeds:
https://www.theregister.com/2019/04/25/ebay_data_drives/

[Reactie gewijzigd door tweaknico op 24 juli 2024 12:23]

[Darses]

Ik ga er vanuit dat men het hier gaat over full-disk encryptie, wat toch wel vrij standaard en eenvoudig is te gebruiken vandaag de dag. Die sleutels kan je dan bijvoorbeeld opslaan in een security chip, waar ze vervolgens lastig uit te halen zijn. Dat is bijvoorbeeld ook hoe Windows Bitlocker werkt. Dat die sleutel dus ook nog ergens opgeslagen moet worden klopt, maar dat wil niet zeggen dat je die niet een stuk beter kan beveiligen dan al je data bij elkaar.

Daarnaast gaat men er hier vanuit dat de fysieke maatregelen voldoende zijn. Dat laat zien dat de auteurs van dit rapport het concept gelaagde beveiliging nog niet goed hebben begrepen. Je gebruikt full-disk encryptie namelijk ook om te compenseren voor situaties waar je andere maatregelen hebben gefaald. Denk aan een laptop of USB-stick laten slingeren, de harde schijf vergeten te wissen als deze afgedankt wordt, etc.

[Sandwalker]

Dat is een reden voor full disk encryptie. Waar het om gaat is dat full disk encryptie niets toevoegt wanneer grote delen van de dataset geëxporteerd worden naar andere bestanden op andere schijven. Het zekerstelling van rechtmatige toegang en alleen tot de juiste dataelementen is dan belangrijker.
Ik heb geen idee over de omvang van deze dataset, maar ik verwacht dat de disks zelf al wel encryptie zullen hebben, maar dat maakt nog niet dat de database ze ook versleuteld aflevert en pas decodeert in de client.

[Darses]

Als ik het rapport lees, dan lijken de disks juist geen full-disk encryptie te hebben. Immers hoef je dan geen rekening meer te houden met het diefstal scenario. En omdat de rest van de beveiliging al helemaal te wensen overlaat, is het advies om voorlopig niet na te denken over die versleuteling.

Versleutelen van persoonsgegevens in en rondom de BRP kan op verschillende manieren.
Als eerste mogelijkheid kan men de GBA-V database zelf versleutelen, waarbij de gegevens worden ontsleuteld alvorens dienaar de afnemers worden gestuurd. Dit beschermt tegen diefstal van de fysieke schijf of tegen het illegaal kopiëren van de centrale database GBA-V. Maar het beschermt niet tegen alle vormen van opvragingen door de aangesloten instanties en beschermt ook niet tegen frauduleuze mutaties die door dreigende actoren via gemeenten worden aangele-verd.

[Reactie gewijzigd door Darses op 24 juli 2024 12:23]

[datalegend]

Er wordt in gemeente land / binnen de overheid nu gewerkt aan een centrale open-source BRP API.

De bron gegevens staan nu op heel veel plekken en gekopieerd 'alleen' encryptie toevoegen helpt niet er zijn eigenlijk veel grotere problemen met oude software oude wetgeving die een ouderwetse werkwijze verplicht.

github BRP api

IRMA is ook een mooi initiatief IRMA app

[MartijnHavinga]

Hmm, dacht dat het in de AVG stond dat het verplicht is om persoonsgebonden gegevens te versleutelen. Blijkbaar hoeft de overheid zich niet aan haar eigen wetten te houden.

[Anoniem: 1463186]

Versleuteling op zichzelf is niet verplicht. De AVG heeft het over een passende beveiliging, vandaar dit onderzoek. Maar encryptie op zichzelf is niet een eis die genoemd staat. Als encryptie niks toevoegt dan is dat dus niet passend, dan doe je het alleen omdat het leuk klinkt, maar als zoals @Argantonis de sleutel alsnog in de infra zit. Of die data ook deels bij de gemeenten staat, dan ben je dus alleen maar jezelf voor de gek aan het houden.

[Reactie gewijzigd door Anoniem: 1463186 op 24 juli 2024 12:23]

[Cergorach]

dacht dat...

Je heb een PC, je heb Google, wellicht eerst eens even checken of wat je denkt wel klopt. Zodat je je conclusies kan baseren op niet alleen wat jij dacht... Tenzij je het zeker weet en dan heb je vast een linkje naar een bron....

https://autoriteitpersoon...europese-privacywetgeving

[MartijnHavinga]

Heb er zelf niet bijzonder veel onderzoek naar gedaan, maar in het bedrijf waar ik werk hebben er genoeg mensen naar gekeken en daar kwam men toen tot de conclusie dat wij onze databases moesten gaan versleutelen (ingebouwde optie in sql server).

[_haan]

Dit is niet zo. De AVG verplicht geen specifieke maatregelen, alleen dat er "passende maatregelen" getroffen moeten worden om persoonsgegevens te beschermen. Wat passend is hangt onder andere af van "[...] de stand van de techniek en de uitvoeringskosten afgezet tegen de risico's en de aard van de [...] persoonsgegevens". Verplicht is dat je die afweging kunt verantwoorden, maar versleuteling wordt steeds alleen als voorbeeld genoemd van een mogelijke maatregel.
Handig, zo kan de AVG uit 2016 een paar decennia mee.

[joppetie]

Volgens mij mag dit ook een fysiek beveiligen van de toegang tot gegevens zijn. Ik heb me er destijds in verdiept voor een advies en een slot of wachtwoord kan al voldoende zijn soms. Als het bijvoorbeeld om papieren dossiers gaat ofzo, dan wordt het versleutelen van de persoonsgegevens erg moeilijk. Maar dit moet natuurlijk per geval afgewogen worden, dus in dit geval is versleuteling geen gekke gedachte. Maar de sleutel zal wel bij zoveel partijen liggen dat het maar de vraag is of het zin heeft. Zo hebben alle (kandidaat-)notarissen en hun medewerkers bijvoorbeeld al toegang tot het BRP (een slordige 10.000 mensen).

[dec0de]

Raymond Knops denkt dat er betere manieren zijn om de gegevens te beveiligen en dat encryptie weinig toevoegt.

Kan iemand een betere manier offeren?
Want ik ken er geen. (Die ook nog uitvoerbaar is in een redelijk bedrag)

Want "maatregelen voor toegang alleen door bevoegden" is niet bijster duidelijk, en ook geen makkelijk uitvoerbaar plan, tenzij hackers "bevoegden" zijn

[michielRB]

Kan iemand een betere manier offeren?

Ik zal vast een vuurtje gaan stoken.
Een betere manier (als dat nog niet gedaan wordt) is om het permissieniveau van een aanvrager te beperken. Alleen toegang tot de data die voor die persoon/instantie nodig is en niet de hele dataset.

[janbaarda]

Een betere manier (als dat nog niet gedaan wordt) is om het permissieniveau van een aanvrager te beperken. Alleen toegang tot de data die voor die persoon/instantie nodig is en niet de hele dataset.

Dit is bij wet vastgelegd als "doelbinding": Een organisatie mag niet zomaar persoonsgegevens doorgeven aan personen of andere organisaties. De algemene regel is dat verstrekken van persoonsgegevens alleen mag als dat verenigbaar is met het doel waarvoor de gegevens zijn verzameld. Of dit het geval is, hangt af van de concrete omstandigheden. Dat kan dus per situatie verschillen. (zie: https://autoriteitpersoon...kken-van-persoonsgegevens)

Voorbeeld hiervan is dat bij koop van alcoholhoudende dranken, naast de naam, alleen het gegeven "is ouder dan 18" (afgeleid van "geboortedatum") getoond wordt.

[leon_ree]

Goed statement, alleen je voorbeeld is lastig; want hoe weet je zonder verder (identificerend) gegeven, bij wie het 'is ouder dan 18 gegeven' hoort?
In de echte wereld krijg je nu een id kaart waarbij je kan zien dat hij echt is, dat die bij de drager hoort en wat zijn geboortedatum is (helaas meer dan enkel ouder dan 18).

In een digitale variant kan dit laatste element verminderd worden tot' voldoet aan leeftijdseis,' maar hoe weet je dat dus de persoon in kwestie bij de eigenschap hoort, en dat hij dus geen authenticatie van iemand anders 'geleend' heeft. Of valt deze controle buiten het domein van de verkoper?

[jeroen_loeffen]

Je gaat op die manier alleen de geboortedatum krijgen van een persoon als die bij jou aan de kassa komt staan met alcohol EN die persoon er uit ziet alsof die mogelijk jonger dan 18 is. De "organisatie" verstrekt jou die gegevens in ieder geval niet.

Online verkoop van alcohol lijkt nog wat strubbelingen te ondervinden daarin...

[leon_ree]

Als die persoon er niet uitziet als 18 hoef je natuurlijk ook geen verificatie te doen, en als die rond de 18 is wil je waarschijnlijk dus juist uitsluitsel dat de waarde bij de persoon hoort.

Vandaar mijn opmerking dat dit een lastig voorbeeld is,want het punt was hoe bepaal je of de waarde ja/nee ouder dan 18 hoort bij de betreffende persoon. Eigenlijk wil je dan ook een foto, en dus is dataminimalisatie dus toch niet zo eenvoudig.

[janbaarda]

Een ID kaart met alleen een foto/vingerafdruk + een BSN is in principe voldoende.

Het BSN kan gebruikt worden voor een check van de leeftijd. Bij huur van een auto kan gecontroleerd worden of je een geldig rijbewijs bezit. Enzovoort.

Dus geen enkele reden om privé gegevens op een ID kaart te zetten.

[Horatius]

En dan nog logs van wie toegang heeft gevraagd tot wat en wanneer.

Nog steeds lijkt mij dit beter icm met encryptie want dan kan je in principe niet om dit toegangssyteem heen mits alles goed gedaan is. Want als ze nu gehackt worden kunnen ze bij die data zonder encryptie en met encryptie is die data (voorlopig) niks waard.

[Ikkerens]

Maar dat is hem nou ook juist, "why not both?".

Het is niet het een of het ander, je kunt gewoon prima beide toepassen met wat moeite.
Want je wil juist dat als iemand op een andere manier bij de data komt, dat ze er niks aan hebben, en daar is encryptie (at rest) juist voor, als laatste beveiliging voor als de eerdere lagen falen.

[BCC]

Een vriend met een duur adviesbureau inhuren is dan toch de meest gebruikte oplossing?

[nandervv]

Commerciele bedrijven zijn over het algemeen nog veel trager en ge-desinteresseerder dan de overheid, als het om beveiliging en privacy gaat.
Iedere paar maanden gaat er weer een grote commerciele partij op z'n gat, omdat ze gehackt zijn, of gebitlockt.
Bij beveiliging en privacy geldt toch al snel: "Als het nu nog werkt, waarom zouden we investeren?"..

[Djordjo]

Nu is er helemaal geen beveiliging lijkt wel ik vindt dit een kwalijke zaak!

Ben je aan het trollen of heb je er echt geen verstand van?

[Proliges]

Er is wel beveiliging van persoonsgegevens.

[djwice]

Precies en dan alle afschuiven naar Microsoft ActiveDirectory en een 3rd party authenticatie federatie tool.

Deze zullen ze voorstellen als simpel te koppelen. Vervolgens zal in de praktijk blijken dat er veel afwijkende onbekende systemen in gebruik zijn, dus gaan implementatie kosten omhoog.
Dat wordt eerst maar geaccepteerd en toegezegd. Dan vinden ze spontaan systemen die maar enkele tientallen gebruikers hebben per gemeente (apart analyse traject om kosten te reduceren op het project).
En zetten die dan buiten scope.

Zo hebben ze de begin doelstellingen niet gehaald, echter worden deze gedurende het project voorzien van risico en kosten inschattingen. En zo worden de risico's voor de out-of-scope systemen geaccepteerd of buiten de invloedssfeer van de beslisser geplaatst.
En zo wordt met trots met factor 3,5 budget overschrijding het project na 4,5 behaald. Met een vervolg project in de planning;

Consolidatie van systemen.
Dat afgerond?

Dat komt er een nieuw vervangend systeem voor alles. Zelfde als er boven, steeds meer buiten scope.

Terwijl beste aanpak zou zijn: kijk vanuit GDPR en data toegang die werkelijk nodig is.
Zet dit op conform moderne cloud tech, maar oei, dat besteden we aan en uit. Dus een partij stuurt junior designers en kiest een cloud die geen fine grained data access ondersteunt. (Azure).

Bij project 1 zien we in de tussentijd een aantal keren dat de out-of-scope systemen lekken. En omdat ze out-of-scope waren geplaatst wordt dat het project niet aangerekend. Uiteraard was dat risico juist de motivatie om het out-of-scope te plaatsen en was de reden voor het project om het risico weg te nemen. Helaas wil niemand zijn kop in een strop, dus de focus wordt tactisch op andere dingen gelegd.

Wel mooi: veel mensen aan het werk en er na gewoon weer nieuw werk voor de boeg. Ik vermoed dat veel landen hun eigen manier hebben om herhalend werk te creëren om mensen aan het werk te houden. Aangezien we dit overal zien, in verschillende samenlevingen, culturen en politieke stromingen, is het wellicht gewoon een vorm van solidariteit.

[BCC]

Je vergeet alleen het stukje waar de politicus zegt niet verantwoordelijk te zijn want het adviesbureau adviseerde deze richting nou eenmaal. Verder +1

[Groningerkoek]

Encryptie verliest zijn effectiviteit een beetje als er alsnog tienduizenden mensen toegang hebben tot de gegevens in onversleutelde vorm.

[timberleek]

Sterk afhankelijk van waar je tegen wil beschermen.

Voor aanvallers via de reguliere kanalen zal het niet helpen. Die gebruiken de normale credentials.

Maar iemand die lokaal in de storageserver zelf inbreekt hou je wel tegen. Die krijgt een local disk met bende.

Of nog knulliger (maar meermaals gebeurt), als er een schijf verdwijnt uit een kluis. Of gewoon wordt weggegooid ipv vernietigd

[Kewne]

En niet alleen mensen, maar ook systemen. Je kunt het merendeel van de gegevens uit de BRP 24/7 zelf inzien op MijnOverheid. Informatie uit een altijd-toegangkelijk systeem op een daadwerkelijk nuttige manier encrypten is enorm lastig. Er zijn wel wat oplossingen zoals het opslaan van keys bij DigiD encrypted met het user wachtwoord, maar die zijn enorm complex en bieden ook bepaalde minpunten voor de gebruikerservaring.

[TimFelten]

'Segregation of duty' en het strikt beheren van toegang. Is niets nieuws maar is niet altijd strak georganiseerd. Versleutelen lost niks op als je de deur open hebt staan voor iedereen binnen je organisatie. Voor jan en alleman klinkt dit nieuwsbericht als: we laten de deur open, maar er is een daadwerkelijk verschil tussen toegang en versleuteling.
Genoeg maatregelen die getroffen kunnen (en moeten) worden om gegevens veilig te houden voor de buitenwereld.

[yyooss2]

De titel:
>Overheid vindt versleutelen van gegevens in Basisregistratie Personen niet nodig

Het artikel:
>Staatssecretaris adviseert dat er betere technieken zijn waar we resources in kunnen steken om de veiligheid van gegevens te garanderen

Lekkere clickbait weer

[Koffie]

Het klopt toch.
Leuk dat hij andere technieken beter vind en wil gebruiken, maar dat gaat niet voorkomen dat als iemand met de database aan de haal gaat alles in plaintext zo uit te lezen is. Zet je dan met je betere beveiliging op de applicatie op het gemeentehuis in schubbekutteveen. Goed gewerkt pik

Een beetje het idee dat je beter je oprit kunt beveiligen dan een fatsoenlijk slot op je voordeur, want de schoonmaakster, tuinman en melkboer krijgen toch ook de sleutel van die voordeur.

[Anoniem: 1463186]

Maar je doet nu alsof de BRP een soort database is, dat is het niet. Het is een systeem waarbij de data uiteindelijk bij de gemeenten staat. Het is dus niet dat er een lijst is met alle gegevens van alle Nederlanders in plaintext ergens.
Dat iets onder één noemer valt betekent natuurlijk niet direct dat het ook één database is, zeker met het systeem van gemeente e.d. wat wij hier hebben. Dus die beveiliging in het gemeentehuis telt zeker wel mee, omdat dat is waar de informatie voornamelijk vandaan komt. De uitwisseling hiervan gebeurt via het BRP, niet de opslag.

[watercoolertje]

Die encryptie is niks meer dan een druppel op een gloeiende plaat en lost niet op dat er dan nog 355 (gemeente) indirecte ingangen zijn tot die (plain tekst, want anders kunnen gemeentes het ook niet lezen) data.

Ik kan me dus prima vinden in zijn redenering. Al zou het natuurlijk 1 van de 356 wegen naar Rome wel kunnen afsluiten en heb je vind ik ook een voorbeeldfunctie!

De vraag is dus hoeveel geld kost dat en is dat verantwoord om 0.3% van wegen mee af te sluiten (wat er gewoon voor zorgt dat een hacker 1 van de 355 andere wegen pakt, dus het risico wordt niet eens 0.3% kleiner).

[Reactie gewijzigd door watercoolertje op 24 juli 2024 12:23]

[CivLord]

Het zijn niet alleen gemeentes. Elke overheidsorganisatie in Nederland die gebruik maakt van persoonsgegevens heeft toegang tot de basisregistratie. En al die organisaties hebben vaak meerdere systemen die bij een bepaalde subset van de gegevens uit de basisregistratie meten kunnen.
Het zal in de praktijk onmogelijk zijn om al die systemen op een verantwoorde manier, tegen redelijke kosten geschikt te maken om versleutelde gegevens uit de basisregistratie te ontsleutelen, zonder dat er een chaos ontstaat het het project mislukt.

[Bacchus]

Het is inderdaad niet zo gek om eerst eens te kijken of je gewoon een goed slot op de voordeur kunt zetten voor je een kostbaarheden-kluis in je woning gaat laten installeren. Niet dat je de kluis/versleuteling nooit moet doen maar begin eens met het laaghangend fruit.

[Huugje]

Maar een woning heeft natuurlijk niet alleen een voordeur. En een goed slot heeft weinig zin als je die soms vergeet op slot te doen. Dan is het prettig om te weten dat je kostbaarheden in ieder geval in een kluis liggen die heel wat moeilijker te kraken is dan men je woning binnen kan komen.

[Proliges]

Alleen zo werkt het niet. De BRP is niet 1 database ergens. Dat is informatie die over honderden verschillende instanties is verspreid en wordt gekoppeld.

[Bacchus]

Dat maakt encryptie van de opslag alleen maar complexer èn minder waardevol. Extra reden om andere veiligheidsaspecten met meer impact en minder inspanning eerder aan te pakken.

[tweaknico]

Alleen kan het in dit geval beide tegelijk.
Verschillend toegangsniveau, verschillende sleutels. (verdeel de BRP in rubrieken, met ieder hun eigen sleutel). Zet de sleutels op passen van de personen met toegang, dan wordt de pas ook uit de terminal getrokken aka autorisaties vallen weg bij het verlaten van ruimtes.

[Proliges]

Dat gebeud al, niet iedereen heeft toegang tot alle data.

[J_van_Ekris]

Je beseft dat de BRP een virtueel ding is die in werkelijkheid honderden verschillend ingerichte fysieke systemen zijn die door soms miliscule gemeentes worden beheerd?

[tweaknico]

Klopt, dus het hoeft alleen goed geregeld te worden voor grote comemrciele organisaties?
(Die doen dat vaak al om te voorkomen dat er een concurrent met hun data aan de haal kan).

Voor de overheid is er per definitie geen concurrentie, en die kunnen dat alleen bij wet als plicht krijgen opgelegd. Daarnaast kan een kleine gemeent makkelijker data opvragen bij een grote gemeente dan dat willekeurige burger dat kan.

Dus idd. ook kleine gemeenten. (bestaan die nog, na 20 jaar gemeentelijke herindelingen?)

[J_van_Ekris]

Mijn punt is dat hier niet een beveiliging bestaat, maar dat je het op honderd verschillende plekken met meerdere leveranciers moet organiseren.

Overigens is het beeld dat commerciele organisaties grootschalig encryptie van data inzetten om bedrijfsgeheimen inzetten in mijn beleving incorrect. Ik ben altijd al blij als de autorisatiematrix klopt zullen we maar zeggen.

[rjkers]

Ik wou beginnen met hoe totaal kansloos is dat dit soort informatie niet versleuteld opgeslagen is. Je leest zo vaak dat een DB uitlekt van wachtwoorden en email adressen MAAR alles is gehasht dus geen paniek. In mijn ogen mag de overheid dus als de wiedeweer dat spul gaan versleutelen.

Echter, als je de brief van Raymond Knops leest staat daar:
"De BRP is benoemd als een basisregistratie, maar is vanuit technisch oogpunt geen entiteit. Het is een verzameling van honderden zelfstandige systemen, ieder met hun eigen gegevensverzame-lingen. Deze systemen zijn ingericht en worden beheerd door vele organisaties, die ieder hun ei-gen beheers- en beveiligingsmaatregelen hebben getroffen."

Dat word opeens een heel ander verhaal! Ik nam aan dat het één database was met duizenden gebruikers. Echter t zijn honderden systemen met honderden gebruikers. Omdat allemaal even te beveiligen is wel een andere klus. Dan zou je nog eerder een komplete overhaul doen.

[Argantonis]

Versleutelen (encryption) en hashing zijn 2 verschillende dingen.

Hashing kan je maar 1 richting op doen. Als iets gehashed is dan kan je dat niet weer herleiden tot de originele data. Dat is voor passwords prima en ook gewenst. Als iemand zich wil authenticeren dan hashed het systeem opnieuw het opgestuurde wachtwoord en vergelijkt dat met wat er in de database staat.

Versleuteling gaat 2 kanten op. Je moet tenslotte nog wel bij de gegevens kunnen om er wat aan te hebben. Dat iemand in Lutjebroek op de Dorpsstraat 16 woont daar heb je weinig aan als je nooit meer bij die informatie kan.

Inherent aan versleuteling is dus altijd dat de sleutel om het weer te decrypten ook in het systeem aanwezig moet zijn. Dus als je volledige toegang tot het systeem hebt dan kan je ook alle data weer decrypten. Daarom is hashing iets wat je altijd zou moeten doen maar versleutelen is toch al omkeerbaar dus dan wordt het toch meer een kwestie van wat is nu belangrijker.

[CivLord]

Leuk dat je je kennis ventileert, maar je gaat voorbij aan het punt.

Het punt is dat je wanneer je een database hackt niets aan de gegevens hebt wanneer die gehasht of versleuteld zijn. Met als voorbeeld dat wanneer een database met wachtwoorden uitlekt je niets aan die wachtwoorden hebt, omdat ze gehasht zijn, net zoals je niets aan een database met adressen hebt wanneer die adressen versleuteld zijn.

[Argantonis]

Leuk dat je even meent mij te kunnen wijzen op het ventileren van mijn kennis, maar degene op wie ik reageerde begreep dit verschil overduidelijk niet want hij had het over het hashen en versleutelen in 1 zin, en over het hashen van emailadressen wat sowieso de emailadressen onbruikbaar zou maken om er daadwerkelijk naar te mailen. Het is dus wel degelijk leerzaam voor diegene. En het maakt een groot verschil in hoe nuttig het überhaupt is. Dat alléén database op straat kan komen liggen en dat dat dan een probleem is dat snap ik ook wel. Maar als de hele infrastructuur wordt binnengedrongen dan hebben ze ook de sleutel.

[Reactie gewijzigd door Argantonis op 24 juli 2024 12:23]

[rjkers]

Dat valt wel mee. Ik had dit expliciet kunnen benoemen om verwarring te vookomen, maar het doel was zoals CivLord beschrijft het beveiligen van data.

[Pinkys Brain]

In een database wil je over het algemeen kunnen zoeken met complexe zoekopdrachten. Als een front end applicatie de data encrypt voordat hij het in de database zet gaat dat niet meer lukken, dan kan je alleen nog maar heel simpele sleutel-data paren erin zetten.

[Reactie gewijzigd door Pinkys Brain op 24 juli 2024 12:23]

[R4gnax]

In een database wil je over het algemeen kunnen zoeken met complexe zoekopdrachten. Als een front end applicatie de data encrypt voordat hij het in de database zet gaat dat niet meer lukken, dan kan je alleen nog maar heel simpele sleutel-data paren erin zetten.

Dat is waarom competente database implementaties de data transparant encrypten en decrypten zodat je gewoon kunt zoeken in de gegevens die (voor de database account waar je gebruik van maakt) decryptbaar zijn.

Zelfs als zo'n systeem niet row-level granulariteit bezit heeft het al een enorm toegevoegde waarde, omdat het exfiltratie van de database data files voorkomt. Dat is een reëel scenario mocht een hacker zichzelf toegang tot de server weten te verschaffen of bijv. toegang weten te krijgen tot een online onversleutelde backup van de data.

[Reactie gewijzigd door R4gnax op 24 juli 2024 12:23]

[Pinkys Brain]

De meest standaard exploit zijn door SQL foutjes in een web front end, daar zal encryptie door de database software weinig aan. Met authenticatie kan je aanvallen afvangen van de rest van het netwerk, maar daar voegt encryptie weinig aan toe.

Als ze de database server hacken kunnen ze altijd een login afwachten, zelfs als je de encryptie sleutel een deel van de login maakt.

Het enige waar encryptie door de database echt bij helpt is als de storage server gehacked is of de schijven fysiek gejat worden.

[number3]

BRP is de oude gemeentelijke basis administratie. En ja, is inherent gedistribueerd. Dat wil niet zeggen dat het niet veilig kan. Alleen de centralisatie is een paar jaar geleden volledig mislukt.

Dus... dan is het dus echt tijd om de boel eens anders aan te pakken. Ipv te constateren dat het allemaal veel te ingewikkeld is.

[bzzzt]

Ik wou beginnen met hoe totaal kansloos is dat dit soort informatie niet versleuteld opgeslagen is. Je leest zo vaak dat een DB uitlekt van wachtwoorden en email adressen MAAR alles is gehasht dus geen paniek. In mijn ogen mag de overheid dus als de wiedeweer dat spul gaan versleutelen.

In dit geval gaat het dus niet om een 'simpele' password tabel, maar gewoon een bak gegevens met privacy gevoelige status. Lekken is dus per definitie een probleem en daar zijn maatregelen tegen.

Maar hoe zie je voor je dat 'dat spul' versleuteld moet worden? Je zal op enig moment wel een ontsleuteling moeten toepassen om überhaupt wat met die data te kunnen doen (functioneel moet zo'n applicatie de data ophoesten als een gebruiker met rechten daartoe daarom vraagt).

Backups versleutelen is redelijk standaard practice. Ook kan je de 'disk volumes' waar een database op staat encrypten, het transport is beveiligd met TLS en dan is het nog niet genoeg?

In principe is het misschien mogelijk om velden in een database te encrypten, maar als je iemand op z'n BSN wil zoeken zal de database toch toegang moeten hebben tot de oorspronkelijke informatie om een efficiënte index op te zetten. Bovendien zal dan nog een hele sleutel infrastructuur opgetuigd moeten worden naast zo'n database, en blijven er accounts die bij alle data kunnen. Een eventuele inbreker kan op een draaiend systeem dus nog steeds bij alle data, dus zo'n oefening komt op mij een beetje zinloos over...

[eric.1]

Dan zul je dus een standaard moeten afspreken lijkt me. Ik vind dit maar een slap excuus en het getuigd niet van veel cybersecurity-kennis.

[Apoca]

Mensen in de politiek vinden dit pas een probleem als ze zelf met de nadelen van hun eigen beleid worden geconfronteerd.

[psychodude]

Maar hoe zie je het voor je dan? De gegevens moeten ook ontsleuteld kunnen worden. Het voegt weinig toe om éénrichtings hashes op te slaan bij een cluster aan aangeroepen datasets als dit.

Versleuteling is dan ook weinig anders dan pseudosecurity. Klinkt leuk. Maar voegt uitermate vrij weinig toe, zeker op de langere termijn.

Wat op orde moet zijn is de toegang. En de kaders waarbinnen toegang tot de gegevens verkregen kan worden.