Gemeente Eindhoven getroffen door datalek, bsn burgers kort intern inzichtelijk

De gemeente Eindhoven meldt een datalek waarbij de burgerservicenummers van bijna alle burgers van de gemeente 'enkele uren' inzichtelijk waren. Het gaat om een intern datalek waarbij de gegevens dus alleen voor ambtenaren in te zien waren.

Getroffenen zijn in eerste instantie niet geïnformeerd over het incident omdat het risico op eventueel misbruik van de gegevens als 'onwaarschijnlijk' beoordeeld werd, zo schrijft het Eindhovens Dagblad. Wel is er een melding bij de Autoriteit Persoonsgegevens gedaan, wat verplicht is bij grote datalekken. De burgerservicenummers van ruim 211.000 burgers zijn bij het datalek betrokken geweest.

De Brabantse gemeente staat sinds vorig jaar onder verscherpt toezicht bij de AP. De waakhond maakt zich zorgen over de manier waarop Eindhoven met de persoonsgegevens van burgers omgaat. In een rapport schrijft de gemeente dat er vorig jaar 266 datalekken gesignaleerd werden. In de meeste gevallen gaat het om relatief kleine incidenten, bijvoorbeeld het verkeerd adresseren van post of een e-mail. In 28 gevallen maakte de gemeente een melding bij de AP.

Reacties (58)

[wildhagen]

Getroffenen zijn in eerste instantie niet geïnformeerd over het incident omdat het risico op eventueel misbruik van de gegevens als 'onwaarschijnlijk' beoordeeld werd,

Ik vind dat toch wat straf. Ja, omdat het 'slechts' een intern lek is, is het risico uiteraard minder dan wanneer Jan en alleman het publiek zou kunnen zien, dat klopt absoluut.

Maar ook intern kan je rotte appels hebben natuurlijk bij de eigen werknemers. Of mensen die het niet met opzet laten slingeren op bijv USB-sticks, maar puur per ongeluk.

En nog even los daarvan had het ook wel netjes geweest als je de potentiele slachtoffers van wie de gegevens gelekt zijn had geinformeerd. Dat het wettelijk niet hoeft zal best kloppen, maar dat wil nog niet zeggen dat je ze niet mag informeren. Wel zo klant-/burger-vriendelijk om het gewoon wél te melden lijkt me.

[Heaget]

Misschien een gekke vraag, maar mag de gemeente hier zelf inschatten wat het risico is? Dat is een beetje een omgekeerde "wij van WC eend"...

[Keypunchie]

Zij zijn in principe het beste ge-equipeerd om in te schatten: zij weten de aard van de data en de omvang van het lek…

[BeefHazard]

Precies. Je doet melding bij de AP zodat zij contact met je op kunnen nemen bij vragen over je inschatting van de situatie of de ernst ervan. Als zij vermoeden dat je serieus tekortgeschoten bent of dat de schade groter is dan je toegeeft, kunnen ze overgaan tot verder onderzoek en/of sancties.

Het BSN is juridisch een bijzonder geval; het is geen bijzonder persoonsgegeven maar valt onder Artikel 46 van de U(itvoeringswet)AVG, 'Verwerking nationaal identificatienummer'. Héél weinig organisaties mogen deze verwerken, en dat mogen ze alleen voor de uitvoering van wettelijke taken (doelbinding). Reken maar dat de AP de oren spitst als een vewerker een incident met BSNs meldt.

[kodak]

Dat is onzin. Van een bedrijf of organisatie dat niet in staat is om persoonsgegevens behoorlijk te beschermen gaat namelijk niet zomaar op dat ze dus maar beter inzicht en mogelijkheden dan anderen hebben. Eerder dat er grote gebreken zijn in dat vermogen, bijvoorbeeld door het perse maar blijven nastreven van andere belangen als winst, tijd en moeite besparen en meer belang hechten aan vals gevoel van betrouwbaarheid dan aan wettelijke eisen. Hooguit kan je eisen dat ze genoeg inzicht en mogelijkheden dan anderen horen te hebben, maar zo werkt dat in de praktijk niet. Juist daarom is er ook toezicht en een meldplicht aan de toezichthouder.

[mjtdevries]

Jouw reactie is onzin. De meeste datalekken zijn menselijke fouten. Geen bewuste keuzes om het risico op datalekken hoog te maken.
En hoe dan ook weet een bedrijf of organisatie zelf altijd meer van hun organisatie dan een buitenstaander.

Maar fijn om te zien hoe hier allemaal mensen zitten die nog nooit in hun leven een vergissing hebben gemaakt. Waar alles altijd goed gaat.

[kodak]

Fouten maken is net zo goed een gebrek in het vermogen om goed genoeg aan de wettelijke eisen te voldoen. Ik geef slechts als voorbeeld dat er ook andere gebreken in het vermogen om goed genoeg te handelen zijn, zoals de fout maken om eigen belangen boven dat van de wettelijke plichten te stellen.

Uiteraard worden er ook fouten gemaakt zonder bedoeling om personen te benadelen. Maar dat wil dus niet zeggen dat de oorzaak van fouten hoe dan ook dus maar redelijk zijn of dat men wel genoeg vermogen in kennis en kundigheid heeft om juiste beslissingen te nemen. Terwijl het net zo goed voor komt dat het geen fouten zijn. Waardoor er dus niet zomaar valt te stellen dat de bedrijven of organisaties waar een lek is dus maar het beste ge-equipeerd om in te schatten of ze klanten moeten waarschuwen.

[Aldy]

Je spreekt in de tweede zin je eerste tegen door te stellen dat de MEESTE datalekken, dus niet alle. Daarnaast is het de bedoeling dat je zoveel mogelijk voorkomt dat door menselijke fouten datalekken ontstaan. Met dat in je achterhoofd kun je stellen dat de beveiliging niet op orde was.
En natuurlijk maken mensen fouten en natuurlijk staan de beste stuurlui aan wal, maar er moeten correcties ingebouwd worden, zodat de menselijke fouten geen catastrofale gevolgen hebben.
Je hebt helemaal gelijk dat het bedrijf of organisatie het beste kan inschatten welke gevolgen een lek kan hebben, maar dat wil niet zeggen dat ze de gevolgen graag aan een buitenstaander willen toegeven.

[mjtdevries]

Niet alle nee. Maar er zijn vele gradaties van vergissingen en fouten.
Ik ben nog nooit een datalek tegengekomen in mijn organisatie waar iemand bewust een risico nam.

Wat ik zie zijn vergissingen zoals de verkeerde persoon mailen. (verreweg de meeste datalekken komen daardoor)
Dat heeft helemaal niets met beveiliging te maken. Mensen moeten voor hun werk kunnen emailen, en dan kan het voorkomen dat ze de verkeerde persoon emailen. Dat kan je ook niet met technische maatregelen voorkomen.

Uiteraard kunnen er lekken zijn waarin iemand bv de verkeerde groep rechten heeft gegeven op een applicatie. Ook weer een eerlijke vergissing. Hier roepen mensen dan dat de beveiliging niet op orde was (en dat is strikte genomen zo) en dat een bedrijf dan niet in staat is om dat datalek zelf te beoordelen. Maar dat laatste is dan duidelijk onzin.

Er zijn ook mensen die richtlijnen overtreden omdat ze het risico niet inzien. Bv in de corona periode dat mensen een mail naar hun prive email stuurden om het thuis te kunnen printen. Of een document met de hand verscheurden en in hun prullenbak thuis gooien ipv de papiervernietiger op kantoor.

Maar hier op tweakers doen de meeste mensen net alsof alle datalekken veroorzaakt worden doordat de directie besloten heeft willens en wetens een risico op een datalek te lopen om daarmee wat euros te besparen.

[Aldy]

Maar hier op tweakers doen de meeste mensen net alsof alle datalekken veroorzaakt worden doordat de directie besloten heeft willens en wetens een risico op een datalek te lopen om daarmee wat euros te besparen.

Om met dat laatste te beginnen kan ik je vertellen dat een directie dat zijn beveiliging willens en wetens niet op orde heeft eigenlijk volledig ongeschikt is. Niet alleen kun je gegevens van derden lekken, maar je kunt ook daardoor bedrijfsgeheimen lekken. En ik denk dat er best wel bedrijven zijn, die het personeel een arbeidsovereenkomst voorleggen met een concurrentiebeding erin, maar tegelijk ook bezuinigen op iets wat misschien kan gebeuren. Vergis je niet, maar hoeveel winkeliers beginnen pas hun winkel te beveiligen omdat de verzekeringsmaatschappij dit verplicht. Dus is de gedachte dat ondernemers willen besparen op veiligheid niet zo'n vreemde. Wellicht onterecht, maar de geschiedenis leert anders,

Het verkeerd mailen is denk ik een veel voorkomende fout, maar als de ontvanger daar geen ruchtbaarheid aan geeft, zullen deze fouten vaak niet verder komen dan de verzender of hooguit binnen het bedrijf blijven.

Hier roepen mensen dan dat de beveiliging niet op orde was (en dat is strikte genomen zo) en dat een bedrijf dan niet in staat is om dat datalek zelf te beoordelen. Maar dat laatste is dan duidelijk onzin.

Zoals ik al eerder schreef denk ik dat een bedrijf over het algemeen hetgeen wat gelekt is zelf kan beoordelen, maar zoals ik al eerder schreef zullen (bijna?) alle bedrijven de impact van het lek graag bagatelliseren.
En het niet door de papiervernietiger halen van gevoelige informatie, daar komt niemand achter.

[Quintiemero]

Dat ligt inderdaad bij de verwerkingsverantwoordelijke, Je moet je keuze dus wel kunnen verantwoorden. Maar een register is niet publiekelijk beschikbaar dus vaak zit er ook wel een gehalte van wat niet weet wat niet deert. Nogmaals, zo zou het niet moeten zijn maar vaak wel de praktijk. Uiteindelijk zorgt het natuurlijk voor verbetering in bewustwording en processen.

[mjtdevries]

Misschien een gekke vraag, maar mag de gemeente hier zelf inschatten wat het risico is?

Niet alleen mag ze dat. Ze MOETEN dat zelfs.

Dat schrijft de wet namelijk zo voor:
https://www.autoriteitper...atalek-wel-of-niet-melden

Het zou ook totaal onwerkbaar zijn om het anders te doen.

Ten eerste omdat een derde partij zoals de AP dan elk klein datalek zou moeten gaan behandelen. Ga eens bedenken hoe idioot groot die dan zou moeten worden.
En doordat ze niks van de organisatie kennen kost het behandelen van een datalek ook nog eens veel meer tijd dan wanneer de organisatie dat zelf doet.

[Quintiemero]

In menig incidentenregister staat ‘medewerkers hebben geheimhoudingsbeperking’, melden is daarom niet nodig, geen hoog risico.

[Tweakert2020]

Nja, dat hadden verpleegkundigen die bepaalde informatie van BN’ers die in het ziekenhuis lagen ook…
Of politie-informatie die gelekt is door politie medewerkers…

[jdh009]

Zit het verschil niet daarin dat ze wel toegang hadden bij de gemeente maar niet hebben gekeken, terwijl ze in de situatie in het ziekenhuis wel hebben gekeken en ik dacht dat er zelfs informatie naar de media gelekt was?

[Reactie gewijzigd door jdh009 op 23 juli 2024 00:30]

[Tweakert2020]

Of iets gelekt is of niet zou niet uit moeten maken, maar het ging mij om deze melding

In menig incidentenregister staat ‘medewerkers hebben geheimhoudingsbeperking’, melden is daarom niet nodig, geen hoog risico.

[Frame164]

De grootste hacks zijn vaak inside jobs. En het staat ook haaks op een zero trust strategie.

[Krommetenen]

Bronnen?

[Tr1pke]

De dag van vandaag nog spreken over “ geheimhoudingsbeperking” lijkt me wel een heel gedurfde uitspraak

[Jorah_Newstone]

Dat zegt echt helemaal niks tegenwoordig, liever informeren zodat men op de hoogte is als je opeens telefoontjes krijgt over details die blijken te kloppen dan slachtoffer van een of andere scam.

[Quintiemero]

Eens hoor, zeg ook niet dat het goed is.

[OMX2000]

Het kan ook onvrijwillig. Daar gaat een handtekening op een papiertje weinig aan doen.

[mjtdevries]

Ja dat kan. Maar dat scenario is extreem onwaarschijnlijk als er per ongeluk even informatie zichtbaar is.
Zo'n onvrijwillige situatie is een geplande actie en is dus niet van toepassing in deze situatie.

[djwice]

Gezien het aantal lijkt het te gaan om alle inwoners ouder dan 12 jaar van de gemeente.

Wellicht is uit logging gebleken dat de data niet is ingekeken door mensen die dat normaal niet kunnen?

[Reactie gewijzigd door djwice op 23 juli 2024 00:30]

[logix147]

Intern lees ik als niet inzichtelijk vanaf het www, maar dat betekend als je dus in-house zat dat je mogelijk wel als derde partij mee had kunnen kijken?

Ik mis een beetje diepgang en Eindhoven kiest helaas vaker voor hele gekke it oplossingen… zal wel bij imago van m’n stad horen maar blij ben ik er niet mee aangezien elk jaar de “onvrijwillige” bijdrage om er te wonen wel steeds duurder op word.

[Keypunchie]

Het zal eerder zijn: role-based access niet op orde, dus iedereen met een login kon erbij.

[Orangelights23]

En dan meldt je het, en dan?

Het klinkt misschien integer, maar organisaties met beperkte middelen, zoals gemeentes, hebben vaak niet de resources beschikbaar om vragen nav de melding volledig en tijdig op te pakken. Het is een businesskeuze.

[Bux666]

Ik ben vorig jaar bij de gemeente Eindhoven op gesprek geweest voor een freelance klus. Wat ik daar hoorde, tartte elk lot. Het 'team' van web ontwikkelaars daar bestond toen uit 2x vaste dienst, 1x MBO stagiair en 1x een vertrekkende (die dus vervangen moest worden).

De lead developer daar stelde ik wat vragen, hij had nog nooit van Laravel gehoord. Dat is anno nu hèt PHP framework. Ook al gebruik je het niet, het feit dat hij erg nog nooit van had gehoord terwijl het toen al 11 jaar bestond en écht overal genoemd wordt, maakte duidelijk dat er nooit vakliteratuur werd gelezen. In plaats van dat ik er vragen zat te beantwoorden, stelde ik ze. Ook aan de teamleider daar. Hoe deze situatie mogelijk was?

Alles was in-house gemaakt, waarbij bijv. een ORM niet bestaat maar dat middels een super omslachtige Excel → CSV → CLI-tool → PHP inline SQL werd omgezet. Werkt, maar super onhandig.
De lead developer zit er sinds 2007 en maakt alles zelf. Knap, maar oh zo gevaarlijk. Documentatie? Niet beschikbaar.

Ook vroeg ik hoe het zat met de beveiliging, testwerk en dat er niet gebruik werd gemaakt van 'proven technologie'. Zelf het wiel uitvinden voor echt alles...met een paar man...serieus?
Ik heb ze na nog geen half uur bedankt en gezegd dat ik er, ondanks het mooie uurtarief en de korte afstand tot huis, binnen 2 weken gillend weg zou rennen. Vergeet 'Brainport gemeente' maar als je dit ziet.

[MueR]

hij had nog nooit van Laravel gehoord. Dat is anno nu hèt PHP framework.

Dat het populair is wil niet zeggen dat het goed is. Case in point: Laravel. Heeft PHP eindelijk fatsoenlijke namespacing, zijn we eindelijk van de global troep af, gebruiken we eindelijk fatsoenlijke ORMs en template systemen die niet direct php code zijn, Laravel zegt overal nee op. Het is populair omdat het makkelijk is, maar goed is het niet. Verre van.

[Bux666]

Kan je je punten beargumenteren? Klinkt alsof je weinig van Laravel kent...

[MueR]

Sure. Ik kan dat prima beargumenteren. Ik werk namelijk dagelijks met Laravel en er zijn meerdere redenen waarom ik voor eigen projecten Symfony kies.

Facades zijn een abominatie. Gebruik fatsoenlijke dependency injection ipv overal semi-globals van maken. Dan gaat een Sonarlint tenminste een keer schreeuwen als je veel te veel dependencies inject in je code, wat een indicatie is dat je code te complex is.

Eloquent is een draak met magic properties en "doe mij tabel 'users'". Column name aanpassen? Dan moet je even goed in je code zoeken of je die string ergens gebruikt, in plaats van gewoon code gebruiken zoals Doctrine. En dan nog zoiets, Doctrine wil graag een repository pattern, zodat je je interacties met de database tenminste een beetje bij elkaar houdt. Laravel? Nee joh, gewoon je DB facade gebruiken in je controller, kan prima. Maintainability is toch niet belangrijk.

Blade. Waar te beginnen. Het is php. Je hebt toegang tot facades, zoals je DB. Je scheiding tussen models, views en controllers is een pinky promise. En ja, in theorie krijg je dat in Symfony ook wel voor elkaar, maar dan moet je ten minste genoeg snappen van Symfony, Doctrine en Twig om daar custom code voor te schrijven.

Laravel is begonnen toen Symfony 2 "te moeilijk" werd bevonden door veel developers. Het vereiste te veel finnicky setup om een applicatie te bouwen. Rapid development was er niet echt. En dus werd alles wat Symfony zo "moeilijk" (lees: correct) maakte de deur uit gedaan. Want mensen willen helemaal niet nadenken.

[Tweakert2020]

Geen idee welke afdeling je bent geweest maar dit is niet hoe de IT afdeling daar te werk gaat.

[Mr. Awesome]

Hoe dan wel?

[Tweakert2020]

Zoals je van een instantie mag verwachten. Bovenstaand is stemmingmakerij.
Hoe ik dat kan weten? Oom van mijn vrouw werkt ben de IT afdeling van de gemeente Eindhoven.

[Oon]

Oftewel wat jij 'weet' is ook gewoon tweedehands anekdotische informatie, dat is niet echt bewijs

[Tweakert2020]

Anekdotisch als ik ken iemand die daar werkt en zie die persoon wekelijks? Voor mij niet. Voor jullie misschien wel.

Maar al zou ik er zelf werken was het voor jullie nog steeds anekdotisch

[vrow]

Het klinkt inderdaad alsof hij per ongeluk bij de facilitaire dienst binnen is gelopen en dat die mensen daar dachten: ‘wij spelen wel even mee’.

[Bux666]

Het was ook niet de IT-afdeling (beheer) maar het development team. Veel intern is webbased. En allemaal zelfgemaakt...

[Tweakert2020]

Deze afdelingen werken nauw samen.

[segil]

Juist.... dus 1 gesprekje van een half uur en jij weet gelijk hoe de gehele IT daar in elkaar zit? Knap hoor.

[Bux666]

Binnen een half uur weet je doorgaans of je werkt met gangbare technieken en frameworks/systemen of dat je op een eigen gekunsteld eilandje komt te zitten zonder enige documentatie, support of externe kennis in de vorm van een community.
Waarom iedereen toch de hele tijd 'gehele IT' erbij haalt...? Het ging om een ontwikkelopdracht en had niets met systeembeheer te maken.

Als je al meer dan 10 jaar met het populairste PHP framework werkt en gewend bent om dingen snel te kunnen ontwikkelen omdat er een super uitgebreide documentatie is, een levendige community en packages zijn voor zo'n beetje alles, wil je echt niet meer op een project zitten dat praktisch het knutselwerk is van 1 persoon. Sowieso moet je dat niet willen omwille van de redenen die ik bovenaan noemde. Is gewoon mega slecht voor je CV als je met eigen brouwsels hebt gewerkt.

[Reactie gewijzigd door Bux666 op 23 juli 2024 00:30]

[segil]

Vanwege deze opmerking?

Vergeet 'Brainport gemeente' maar als je dit ziet.

[AJediIAm]

Het verbaast me dat je zo open bent over de bedrijfsvoering van je (potentiële) klanten.
Ongeacht of het waar is of niet lijkt het me onwenselijk en onethisch om iemand anders zn vuile was zo buiten te hangen.

Natuurlijk is het leuk om mooie dramatische verhalen te vertellen en ik heb de fout zelf gemaakt.
Of het nu om een datalek gaat of het schenden van het vertrouwen van een klant, laten we van onze fouten leren en in het vervolg beter handelen.

[Valandin]

Raar verhaal dit. Een gemeente heeft zelden een dedicated web development team.
Als ik naar de website van de gemeente Eindhoven kijk (https://www.eindhoven.nl/) zie ik dat deze ook ontwikkeld is door een bekende partij die veel andere lokale overheidswebsite bouwt, dus niet in-house.
Vreemde stemmingsmakerij.

[Bux666]

De website is vaak extern gemaakt ja. Dit team ontwikkelt interne applicaties. En daar komen al die security issues in voor die in het artikel genoemd staan. Dat artikel gaat namelijk ook niet over de website.

[WouterL]

Klopt, ik snap het incident. Maar het risico is wel dermate laag dat ik me afvraag of je hier niet vooral mensen onnodig harstikke ongerust maakt. Nu is Eindhoven een grote gemeente, maar was dit bij mijn gemeente gebeurd (ik ben FG bij een kleine gemeente) dan was mijn advies om geen melding te maken. Op zijn hoogst aan de AP. Dat durf ik wel aan.

[Reactie gewijzigd door WouterL op 23 juli 2024 00:30]

[WouterL]

Bijzonder dat je roeptoetert zonder het wettelijk kader te begrijpen. En dan ook nog eens heel hoog van de toren blaast.

In mijn bewoordingen gebruik ik het woord “advies”. Het is inderdaad namelijk uiteindelijk niet mijn keus, maar dat van het college (de verantwoordelijke). Daarnaast moeten interne lekken alleen gemeld worden wanneer dit waarschijnlijk een risico oplevert voor de rechten en vrijheden van de betrokkenen. Een melding aan betrokkene is tevens verplicht wanneer dit risico “hoog” wordt.
Er bestaan mitigerende omstandigheden waardoor dit risico wordt weggenomen, in de richtlijnen wordt (een voorbeeld van een mitigerende omstandigheid) dit de “betrouwbare ontvanger” genoemd. Een dergelijke ontvanger is iemand die bijvoorbeeld aan een beroepsgeheim is verbonden en/of bijvoorbeeld een eigen medewerker. Een interne datalek kwalificeert dus wel degelijk als een datalek, maar dat betekent niet dat deze ook direct gemeld moet worden. (Lees: wel opnemen in register, verbeter maatregelen eventueel implementeren)

Jammer dat je dit direct verwart met “laks”, terwijl er wel degelijk goed onderbouwde analyses aan dit soort uitspraken ten gronde liggen.

Je kunt je het misschien niet voorstellen, maar onnodige datalek brieven aan betrokkenen kunnen mensen behoorlijk onnodig ongerust maken, zeker als je de taal niet goed machtig bent en of anderzijds laaggeletterd bent. Een melding doet soms zo onbedoeld meer kwaad dan goed. Ik neem mijn vak zeer serieus, en “lama hangen” is zelden de drijfveer achter mijn adviezen

[Reactie gewijzigd door WouterL op 23 juli 2024 00:30]

[Faeron]

Het wordt echt tijd dat we minder spastisch met dat BSN omgaan. Het is niet meer dan een gebruikers ID bij de overheid. Lekker spannend.

[WouterL]

Frappante melding. Ik weet niet hoe het bij Eindhoven zit, maar vrijwel alle medewerkers bij gemeenten hebben standaard toegang tot bsn van inwoners, via het zaaksysteem. In theorie is er een groep ambtenaren die niet via een zaaksysteem werkt (buitendienst), maar vrijwel alle kantoorhoudende ambtenaren wel.

Tot slot kan een datalek inderdaad door de grootte kwalificeren als zijnde een “risico”, waardoor de melding meldplichtig wordt. Ditzelfde risico kan worden weggenomen wanneer de ontvangers zijn te kwalificeren als vertrouwde ontvanger.

[Reactie gewijzigd door WouterL op 23 juli 2024 00:30]

[Kenhas]

Weet niet wat de wetgeving in Nederland is maar in België mag het absoluut niet dat iedereen zomaar toegang heeft. Het idee is "niemand heeft toegang tot gegevens tenzij ze kunnen aantonen dat het nodig is om hun job te doen". Een ICT medewerker heeft in principe geen gegevens van burgers nodig en die heeft dan ook geen toegang.
In de gemeente waar ik woon, is het zo dat de persoon die toegang kan geven tot de bevolkingsgegevens zelf geen consultatie rechten heeft.

Voor de rest vind ik het beetje veel ophef voor dit incident zonder meer details. Intern was er iets te bekijken. Dan moeten andere werknemers van de gemeente ook nog weten dat die informatie op die toegankelijke plaats staat. Ik wil het zeker niet minimaliseren maar ook zeker niet opblazen

[WouterL]

Klopt helemaal, alleen zijn sommige kern applicaties (zaaksysteem) alsnog gekoppeld aan het bevolkingsregister. Indirect heb je dan alsnog toegang tot BSN. Het BSN is dan ook alles behalve een gevoelig gegeven voor een ambtenaar. Ik durf te stellen dat het bsn überhaupt geen gevoelig gegeven is.

[Reactie gewijzigd door WouterL op 23 juli 2024 00:30]

[Dennahz]

Dat dus, maar ik neem aan dat ze geen melding van een datalek doen op basis van functies die zo horen te zijn. In een Zaaksysteem heb je trouwens ook intensieve logging, waardoor het direct duidelijk is wie er welke gegevens heeft opgevraagd.

Er zal wel ergens een kant en klare lijst geweest zijn met deze gegevens die voor iedereen toegankelijk was.

[!mark]

Het BSN, iets wat je in de basis absoluut voor jezelf wilt houden i.v.m. misbruik vanwege hetgeen waar het voor gebruik wordt maar aan de andere kant overal niet afgeschermd gebruikt wordt: het staat immers gewoon leesbaar op je ID, op de site van de belasting en het zou me niet verbazen dat het veelal niet versleuteld wordt opgeslagen.

M.a.w. heeft het BSN dus effectief een wachtwoordfunctie gezien wat je er mee kunt doen, maar het wordt niet zo behandeld. Ik snap dat veranderingen op deze schaal lastig zijn, maar is er net te gekozen te werken met iets als een tweede persoonlijke code welke wél overal is afgeschermd met dezelfde status als een wachtwoord?

Dan kan het BSN in de basis gewoon overal openbaar gedeeld worden zonder gevolgen maar zodra iemand dan namens jou iets wil doen dan heeft ie het wachtwoord nodig om aan te doen dat jij wel echt de persoon achter dat BSN bent.

In de zorg is het helaas nog erger, waar de combinatie naam+geboortedatum vaak gebruikt wordt als enige bevestiging dat iemand inderdaad die persoon is. Openbare informatie welke van veel mensen eenvoudig te vinden is

@pvcholten @Frame164 Dat is de theorie, in de praktijk gebeurd het helaas vaak zat dat er buiten het BSN geen authenticatie nodig is waardoor het BSN zelf feitelijk authenticatie wordt. Als BSN echt alleen maar als identificatie gebruikt wordt dan zou het uitlekken hiervan ook niet zo'n probleem zijn geweest, hoogstens vergelijkbaar met je naam.

[Reactie gewijzigd door !mark op 23 juli 2024 00:30]

[pvcholten]

Het BSN is voor identificatie, niet voor authenticatie. Het is dus geen wachtwoord.

Degene die het gebruikt als wachtwoord doet het verkeerd.

[Frame164]

BSN is feitelijk niets anders dan een nummer om een persoon uniek te maken. Zonder BSN zou je naam, geboortedatum, geboorteplaats moeten gebruiken (eventueel aangevuld met geboortetijd om de kleine kans dat op dezelfde dag in dezelfde plaats iemand met dezelfde naam wordt geboren). Maar een uniform BSN maakt het makkelijker voor automatisering. Ergo: het is geen wachtwoord, het heeft zelfs geen wachtwoordfunctie.

[peet de haas]

Maar goed iedereen heb het maar over digi maar die werkt blijkbaar niet of zie ik het verkeerd.