Privacy gevoelige gegevens op een webserver

[willemj]

Ik twijfel of deze vraag in ICT of juridisch thuishoort maar de basis is juridisch. Voor een webapplicatie zijn persoonsgegevens nodig, zowel naw als financiele gegevens. Uiteraard moet er zorgvuldig omgegaan worden met deze gegevens, de beveiliging zal dan ook goed zijn. Mijn vraag is alleen wanneer ben je zorgvuldig? Wanneer ik een gedeelde webserver huur zijn er 100 (willekeurige) mede huurders die zonder al te veel problemen bij de gegevens kunnen. Neem ik een dedicated server maar lees ik pas maandagmorgen het security bulletin dat vrijdag in m'n mailbox kwam kan ik al te laat zijn. Mag je dat soort gegevens uberhaupt zomaar op een 'publiek toegangelijk' (lees internet) machine zetten? Kennen jullie gevallen waar dit fout is gegaan en wat hier de consequenties van waren?

 

Informatie over instanties / advocated die gespecialiseerd zijn in dit soort zaken zijn uiteraard ook welkom.

[WelleKe]

Ik vind het wel een interessante vraag.

 

Mijn boerenverstand (waar je in dit soort zaken dus helemaal niks aan hebt) zegt me dat wanneer je de gegevens afschermt volgens gebruikelijke veiligheidsmaatregelen (goh ja wat is dat) je er voldoende aan het gedaan om de gegevens af te schermen.

 

Ik neem daarom aan dat het voorbeeld van de shared server voldoende is, op het moment dat je de database niet open en bloot hebt staan dan. Ik mag toch hopen dat de server zo is beveiligd dat andere klanten niet gezellig bij jou langs kunnen komen. De hostingprovider kan te allen tijde op die server, zo ook bij dedicated (over het algemeen).

 

Maar ben erg benieuwd wat onze juridisch adviseurs erover zeggen ;)

[Edward]

Mijn boerenverstand (waar je in dit soort zaken dus helemaal niks aan hebt) zegt me dat wanneer je de gegevens afschermt volgens gebruikelijke veiligheidsmaatregelen (goh ja wat is dat) je er voldoende aan het gedaan om de gegevens af te schermen.

Vaak is in juridische zaken boerenverstand het beste verstand ;). Zolang jij je inspant om de gegevens af te schermen voldoe je aan je verplichtingen. Op jouw webserver (ongeacht of deze dedicated is of niet) heb jij in beginsel alleen toegang en kan een ander alleen aan de gegevens komen door daar op in te breken.

[R.I.P. - Benm]

Wat zou 'voldoende afschermen' moeten inhouden? Als je een klein beetje moeite doet, maar het in principe idioot gemakkelijk te kraken is, lijkt me dat onvoldoende (een password van 3 letters beginnende met g en eindigend op d ofzo).

 

Kennen jullie gevallen waar dit fout is gegaan en wat hier de consequenties van waren?

 

Er zijn wel wat gevallen geweest waarbij door eennvoudige inbraakjes naw en creditcardgegevens op straat kwamen te liggen. Dat is vervelend voor de eigenaren van die cards, maar zeker net zo erg voor degene van wie ze gestolen zijn: Het is een stevige deuk in je reputatie, en die kom je niet zo 123 te boven.

[willemj]

Vaak is in juridische zaken boerenverstand het beste verstand

Is het leven echt zo simpel?

 

Op jouw webserver (ongeacht of deze dedicated is of niet) heb jij in beginsel alleen toegang en kan een ander alleen aan de gegevens komen door daar op in te breken.

De mede huurders van een shared server hoeven niet in te breken in de meeste gevallen. De bestanden moeten door de webserver getoond kunnen worden en zijn voor iedereen met toegang tot de server leesbaar. Dus ook het wachtwoord om toegang tot de database te krijgen. Vergelijkbaar met de sleutel van je achterdeur onder de mat te leggen. De inbreker is nog steeds fout maar kan als hij privacy gevoelige informatie uit m'n huis meeneemt ben ik dan niet aansprakelijk??

[WelleKe]

De bestanden moeten door de webserver getoond kunnen worden en zijn voor iedereen met toegang tot de server leesbaar. Dus ook het wachtwoord om toegang tot de database te krijgen

 

Ergens lijkt me dit grote lariekoek en ik hoop maar dat ik gelijk heb ;)

Dus elke sharedhostingklant kan alle bestanden van de andere klanten op die server inzien zeg je, ik hoop toch echt van niet!

[R.I.P. - Benm]

Dat is normaalgesproken niet het geval inderdaad. Een hostingbedrijf is wel extreem aan het prutsen als het mogelijk is dat klant X bestanden en zelfs de database van klant Y kan bekijken.

 

Het is wel zo dat het vaak voor klant X gemakkelijker is om in te breken dan voor een buitenstaander, maar met nette beveiliging gaat dit vrijwel altijd goed.

[willemj]

Ergens lijkt me dit grote lariekoek en ik hoop maar dat ik gelijk heb ;)

Dus elke sharedhostingklant kan alle bestanden van de andere klanten op die server inzien zeg je, ik hoop toch echt van niet!

 

Helaas in bijna alle gevallen kan dit. Je kunt bestanden alleen door jou zelf leesbaar maken maar dan zijn ze voor de bezoekers van je site ook niet meer te zien ;D

 

Kan technisch wel anders maar de meeste providers doen dat niet (kosten, beheer en beveiliging) Ook zijn er wel mogeljikheden om bestanden alleen door jou leesbaar te maken en toch te laten zien op je website (cgiwrap voor de kenners) maar dat is vrij omslachtig.

[willemj]

Dat is normaalgesproken niet het geval inderdaad. Een hostingbedrijf is wel extreem aan het prutsen als het mogelijk is dat klant X bestanden en zelfs de database van klant Y kan bekijken.

 

Waarom aan het prutsen? De content is voor een webbezoeker te zien, dus waarom niet voor de andere klanten (op een andere manier dan) Ook je scripts (met het wachtwoord voor je database) moet voor de webserver leesbaar zijn en dus voor iedereen met toegang tot de server.

 

Kijk maar eens op de helpdesk pagina van providers onder bestandrechten. Gegarandeert dat je daar 'chmod 744' danwel 'chmod 755' tegen komt. Dit zijn de unix commandos om rechten in te stellen. 744 betekend dat jij alle rechten hebt, de groep leesrechten en de rest van de wereld ook alleen leesrechten. Alle gebruikers op die server zijn lid van dezelfde groep of hebben dus net als de rest van de wereld leesrechten.

 

Zoek eens met google op "shared hosting" security "world readable" (inclusief de aanhalingstekens)

 

Maar we wijken een beetje af van het onderwerp :)

 

 

[Edward]

De mede huurders van een shared server hoeven niet in te breken in de meeste gevallen. De bestanden moeten door de webserver getoond kunnen worden en zijn voor iedereen met toegang tot de server leesbaar. Dus ook het wachtwoord om toegang tot de database te krijgen. Vergelijkbaar met de sleutel van je achterdeur onder de mat te leggen. De inbreker is nog steeds fout maar kan als hij privacy gevoelige informatie uit m'n huis meeneemt ben ik dan niet aansprakelijk??

Hmm, dit wordt toch even een technisch verhaal. Voor zover mijn kennis reikte heeft ieder huurder van een shared server een eigen deel en is dit niet zomaar toegankelijk voor derden (lees: door een andere huurder). Om het maar bij sleutels en de huismat te houden. De toegangsdeur van het huis mag dan wel voor ieder met dezelfde sleutel te openen zijn, waarmee hij of zij dan ook toegang heeft tot de gezamenlijke keuken, dat wil nog niet zeggen dat iedere huisgenoot ook maar toegang heeft tot mijn kamer. Als het echter zo is dat een shared server te vergelijken is met het huis van een gemiddeld dispuut dan zou ik het afraden om persoonlijke gegevens op een dergelijke server te zetten.

 

 

[R.I.P. - Benm]

Kom snel, kom snel, Malieveldt is met zn dronken hoofd door de firewall gevallen! ;)

 

Zo'n vaart loopt het meestal niet, maar je hebt gewoon slechte hostingbedrijven, zoals je ook slechte slotenmakers hebt. Uiteraard is dit allemaal verboden, maar dat verhinderd niet dat mensen het toch proberen.

 

[willemj]

Kom snel, kom snel, Malieveldt is met zn dronken hoofd door de firewall gevallen! ;)

Grinnik

 

Zo'n vaart loopt het meestal niet, maar je hebt gewoon slechte hostingbedrijven, zoals je ook slechte slotenmakers hebt. Uiteraard is dit allemaal verboden, maar dat verhinderd niet dat mensen het toch proberen.

Wat ik beschrijf werkt zo bij: xs4all, widexs, vuurwerk en pair. Allemaal business accounts. En ik vraag me dus af of ik beveiligingsmaatregelen omzeil als ik leesrechten heb op een bestand met wachtwoorden.

[MacGyver]

Volgens mij omzeil je dan niets, aangezien dit bestand gewoon leesbaar is en door elke willekeurige zoekmachine kan worden gevonden.

 

Maar, je bent wel erg dom bezig als je wachtwoordbestanden door de webserver gevonden kunnen worden. (via een url) Normaliter staan wachtwoorden met een MD5 encryptie in een bestand welke niet door de webserver kan worden opgevraagt, maar wel door het authentificatie programma gelezen kunnen worden. (Zit iets lastiger, maar dat is de strekking van het verhaal).

 

Wat vaker gebeurt (en dat doe ik dus ook) is dat alle gegevens in een MySql database worden opgeslagen, al dan niet encrypted. Daarin is bv. ook in te stellen dat de webserver bepaalde gegevens alleen maar kan toevoegen en niet bekijken etc. Zodoende scherm je heel veel informatie af en maak je de kans op inbraak kleiner.

 

Natuurlijk kun je niet een 100% veilige oplossing bieden, maar als er goed over word nagedacht, is dit behoorlijk veilig op te zetten en hoeft het geen problemen op te leveren.

[Camelot]

 

Wellicht dat deze link enige duidelijkheid kan verschaffen: http://www.cbpweb.nl/structuur/pag_techn.htm

 

Groet

[willemj]

Dank je Camelot, ik was al enigszins op de hoogte van de theoretische kant van de wbp maar dit ziet er al wat praktijkgerichter uit. Wel vraag ik me af of er bij niet zorgvuldigheid ook andere wetten van toepassing zouden kunnen zijn. Misschien civiel rechtelijk als iemand schade leidt doordat zijn gegevens in de verkeerde handen komen.

 

Maar, je bent wel erg dom bezig als je wachtwoordbestanden door de webserver gevonden kunnen worden.

Klopt. Daar had ik het ook niet over. Het ging om script bestanden die een zoekengine nooit vindt maar wel gelezen kunnen worden door mede huurder.

[MacGyver]

Ok, dan heb je gelijk, mits de bestanden gelezen kunnen worden door een mede huurder.

 

Zelf ben ik dat eigenlijk nog nooit tegen gekomen. Ook de webservers die ik beheer kunnen gebruikers niet bij elkaar kijken. Zou anders een mooie boel worden.

 

En als dat zo zou zijn, is dat, lijkt me, nalatigheid van de provider. Zoveel werk is dat nu ook weer niet om dat dicht te zetten.

[MikeZ]

Met een gedegen, gedocumenteerde, security analyse (bv obv STRIDE) gekoppeld aan een risico analyse (bv DREAD) kun je vaststellen welke beveiligingsaspecten noodzakelijk zijn voor de desbetreffende applicatie. Middels een security audit door een onafhankelijke derde partij kan vervolgens de analyse en implementatie getoetst worden.

 

Op deze manier kun je, in geval van nood, aantonen dat je uitvoerig aandacht hebt besteed aan het beveiligen van de persoonsgegevens. Je expertise hierbij moet uiteraard wel in verhouding staan tot de complexiteit en het risicoprofiel van de applicatie.

 

De uitkomst van de analyse kan natuurlijk zijn dat de situatie zich niet leent voor gebruik op een (al dan niet shared) internet omgeving. In de praktijk heb ik dit overigens nog nooit meegemaak en ik heb met behoorlijk vergaande medische en financiele gegevens te maken gehad.

[MacGyver]

Helemaal mee eens! Echter als je dat soort 'hoog'gevoelige informatie hebt, zit je of bij een provider die secure servers levert en dus de nodige rapporten klaar hebben liggen (en weten wat voor soort informatie je hebt), OF een eigen dedicated server(s) met een eigen IT afdeling die genoeg ervan weet tezamen met de benodigde raporten.

 

Ik zelf zou persoonlijk nooit zelf o.a. credit card gegevens gaan opslaan, maar dit aan partijen overlaten die hierin gespecialiseert zijn. Kost iets meer, maar jouw kunnen ze niets meer maken. Tevens weet je dat die infomatie dan veilig is.

[willemj]

MikeZ dank voor deze suggestie denk dat ik met zo'n analyse inderdaad een eind kan komen (jammer dat ms z'n eigen analyse niet loslaat op een xp machine met m'n telebanking erop maar goed ;D) In geval van nood is niet de bedoeling, dat zou toch de doodsteek voor het bedrijf zijn. Het is meer bedoelt om de klant te laten zien dat het op een correcte manier opgezet is.

 

Dank weer allen voor de bijdragen, geeft weer leesvoer voor het weekend :)

[willemj]

Camelot die link naar het CBP is top. Heb daar al wel eens zitten bladeren maar heb nu het document AV23.PDF gevonden met als titel 'Beveiliging van persoonsgegevens' / 'Achtergrond studies en verkenningen 23' en daar staat praktisch in beschreven hoe je met de gegevens om moet gaan ingedeeld naar risico klassen. Precies wat ik zocht. Reusje erbij! En verplicht leesvoer voor iedereen die systemen maakt die persoongegevens verwerken.