Afdrukvoorbeeld
"hoe de data verwerkt" is als hoster dan weer relatief eenvoudig: "hosting" en "backups" is het meestal. Pakketten en co boeit niet echt.
Welke gegevens de klant opslaat: nu zijn we terug bij het begin. De (belangrijke) 5% van de verwerkersovereenkomst :)
Wij hebben een vrij algemene die misschien wel 99% van de lading dekt. Zo staat er ook iets in over financiële gegevens verwerken, maar wellicht doet een klant dat niet. Maakt mij dan verder niet uit, want het is de verantwoordelijke zijn taak om te controleren of het beveiligingsniveau voldoende is voor hetgeen hij met die gegevens wil doen. Door het ondertekenen garandeert ie dat ook.
Hoe staat het met de lokale hardware? Is een klant niet verplicht om hier ook onderhoud op te laten uitvoeren? Update firewall, laptops en smartphones. Een datalek moet je binnen 72 uur melden maar hoe weet je nu of je een datalek hebt? Moet de firewall niet gelogd worden etc.
Ik zie nu dat het vooral een papieren kwestie aan het worden is. Een klant komt er straks niet mee weg dat hij de laatste security patch niet heeft geïnstalleerd.
Klopt helemaal. Als leverancier moet he de klant hierop wijzen en er is een verwerkersovereenkomst nodig. Blijft altijd lastig want jij kunt als leverancier vanalles adviseren maar je klant bepaalt.Citaat:
Oorspronkelijk geplaatst door blacktcp
Dat laatste is geen excuus in de GDPR: controller en processor zijn *samen* verantwoordelijk. In principe moet je dus je klant weigeren als er zo geen overeenkomst is, anders heb jij ook een probleemCitaat:
Oorspronkelijk geplaatst door Marin
Prima maar wat staat er dan in die overeenkomst?
Een voorbeeld: Wij zijn bezig voor een klant die online werkplekken heeft, er is een vpn verbinding naar de "cloud" maar de lokale schijven op de pc's zijn ook beschikbaar in de cloud. Klant ziet niet in waarom zijn lokale firewall enige vorm van onderhoud nodig heeft. (en is dit wel nodig in de GDPR)
Op deze wijze kunnen er alsnog dingen gebeuren buiten het zicht van de cloud provider. Zo ook met smartphones.
GDPR lijkt meer voer voor juristen, je kan altijd verantwoordelijk worden gesteld..
Wij zijn bezig dit op te stellen, dus welke informatie van klanten slaan we op, bij wie, en hoe is dat beveiligd.
Weet iemand waar ik het kan toetsen of het juridisch gezien wel een "OK" document is?
@Ramon Fincken
Bij een jurist denk ik, ICT Recht bijvoorbeeld.
@blacktcp
De hoster zal dat risico moeten inventariseren en voorleggen aan de klant. Maar de infra op locatie bij de klant is zijn eigen verantwoordelijkheid. En dan nog zelfs als dat van alles misgaat zou een goed beveiligde online werkplek dit moeten kunnen afvangen.
Zal wel goed beveiligd zijn maar leidt toch tot discussie wanneer het fout gaat. Er zijn wat dat betreft veel hiaten.
Dan verschillen we van mening [emoji1303]
Werkplek moet je beveiligen en dan zou een VPN naar een klant daar dus geen afbreuk aan moeten doen. Je moet gewoon aannemen dat de klant locatie net zo onveilig is als het internet.
Een ander verhaal is het als ingebroken wordt doordat de klant zijn wachtwoord heeft laten uitlekken, duidelijk verantwoordelijkheid van de klant en af te vangen met two-factor
Oke voorbeeld. Je levert cloud plekken er moet een site to site vpn worden opgezet ivm printen of wat dan ook. Klant heeft zelf de FW aangekocht maar doet verder geen onderhoud. Door security issue op de firmware blijkt dat er kan worden ingebroken op de FW.
Laten we aannemen dat dit gebeurd en dat kwaadwillende hiermee via de vpn toegang krijgen tot het cloud systeem.
Is dan de leverancier aansprakelijk of de klant? Een beter voorbeeld zou zijn de smartphones .
IctRecht beweert dat je als hoster eigenlijk geen echte verplichting hebt, aangezien jij niet de verantwoordelijke bent:
https://ictrecht.nl/juridisch-advies...-als-bewerker/
Ik zou het zoals daar ook staat wel goed regelen en adviseren aan de klant(tegen betaling?).
@blacktcp
Dit is geen nieuw voorbeeld en wat ik noemde blijft van toepassing, een site to site vpn mag geen gat in je beveiliging zijn. Kom gerust langs voor een kop koffie, dan werken we de case uit met je [emoji1303]
Dan ben je ook als aanbieder niet helemaal lekker bezig. Ook bij een site-to-site VPN moet je aan beide kanten firewall regels instellen die alleen printverkeer doorlaten. TCP:9100. Op die manier kunnen ze nooit via de VPN bij de servers komen. Als je als provider dit nalaat moet je daarna ook niet huilen (en dus verantwoording nemen).Citaat:
Oorspronkelijk geplaatst door blacktcp
Als het goed is kun je restricties opleggen via policies wat een klant wel en niet mag. Zo kun je afdwingen dat een PC voorzien moet zijn van virusscanners, malware scanner en meer - anders mag je niet verbinden.Citaat:
Oorspronkelijk geplaatst door blacktcp