Datenschutz

• » Home
• »Server-Daten
• » Datenschutz

Die Idee | Beispiele | Sicherheit & Features | Preise | News | Datenschutz | AGB

 

Inhalt

Die Europäische Datenschutz-Grundverordnung (DSGVO) regelt die Verarbeitung personenbezogener Daten. Innerhalb des hiesigen Angebotes tauchen personenbezogene Daten an unterschiedlichen Stellen auf.

 

So können die hiesige Domain und einige der Server-Daten - Subdomains anonym oder mit Registrierung + Login genutzt werden, ohne daß ein kostenpflichtiger Vertrag zwischen dem Nutzer und Server-Daten existiert. Es kann aber ein Vertragsverhältnis zwischen dem Nutzer und einem Kunden von Server-Daten existieren. Für all diese Konstellationen gelten die folgenden 4 Punkte:

 

Nutzung als Gast oder innerhalb von Server-Daten (anonym oder eingeloggt)

1. Datenschutz bei der Nutzung als Gast: Kontaktformular, Newsletter, Blogkommentare und Registrierungen

 

2. Verwendung von Cookies während einer Sitzung

 

3. Wie aktiviere ich Cookies im Browser?

 

4. Verwendung von JavaScript

 

---

Ferner kann sich ein Interessent registrieren, mit Server-Daten Kontakt aufnehmen und eine Datenbank anmieten. Für die Erstanmeldung ist die Übermittlung der für die Rechnung benötigten Daten notwendig. Ferner kann ein Kunde in seiner Datenbank Informationen, bsp. Daten seiner Geschäftspartner, ablegen, für welche die DSGVO Gültigkeit beansprucht. Läßt er andere Nutzer zu seiner Datenbank zu, so erfährt er mindestens deren Mailadressen. Dann werden personenbezogene Daten bei der kontinuierlich mitlaufenden Protokollierung sämtlicher Schreibzugriffe kanonisch erzeugt. Schließlich stellt sich für Kunden die Frage nach einer Vereinbarung zur Auftragsverarbeitung. Die folgenden Ausführungen unterscheiden diese verschiedenen Fälle, die nur Kunden von Server-Daten betreffen.

Nutzung als Kunde von Server-Daten

5. Verhältnis zwischen dem Kunden und Server-Daten

 

6. Verhältnis zwischen den Daten in Kundendatenbanken und Server-Daten

 

7. Daten und Nutzer aus der Sicht des Kunden

 

8. Die Notwendigkeit zur Authentifizierung für jeden Schreibzugriff, die kontinuierlich mitlaufende Protokollierung

 

9. Vereinbarung zur Auftragsverarbeitung

 

---

 

 

1. Datenschutz bei der Nutzung als Gast: Kontaktformular, Newsletter, Blogkommentare und Registrierungen

Verantwortlich: Jürgen Auer, Friedenstr. 37, 10249 Berlin - +49(0)30 420 200 60 - info@sql-und-xml.de

 

Nutzer können - unabhängig von der Dienstleistung Server-Daten - auf www.sql-und-xml.de sowie auf einigen System-Subdomains von server-daten.de einzelne Aktionen ausführen, bei denen eventuell personenbezogene Daten übermittelt und gespeichert werden.

• Nutzung des zentralen Kontaktformulars https://beispiel.server-daten.de/kontakt.html, das auch auf allen Seiten der hiesigen Domain unten eingebunden ist.
• Im Blog https://blog.server-daten.de/de/ können Beiträge kommentiert werden. Ohne oder mit Registrierung.
• Interessenten können sich zum Newsletter https://beispiel.server-daten.de/newsletter-subscribe.html anmelden.
• Ferner können sich Nutzer auf einigen Subdomains registrieren: Auf dem Blog und auf den Subdomains beispiel, homepage-werkzeuge, sql sowie terminerinnerung und online-tools.
• Webserver zeichnen Datum+Uhrzeit des Zugriffs, die IP-Adresse, die angeforderte Seite, evtl. Referer und den Useragenten des Browsers auf.

An diesen Stellen können personenbezogene Daten (Name, Mailadresse) eingegeben werden bzw. werden (Webserver) automatisch erhoben. Für all diese Stellen gilt:

• Personenbezogene Daten werden nur dann erhoben, verarbeitet und genutzt, soweit Sie darin eingewilligt haben oder soweit dies ein Gesetz erlaubt.
• Die Aufzeichnung einiger Daten durch Webserver ist gemäß Artikel 6 Abs. 1f DSGVO zur Wahrung der eigenen, berechtigten Interessen zulässig, um die IT-Sicherheit zu gewährleisten.
• Die Datenübertragung erfolgt stark verschlüsselt (per SSL/TLS), sofern Sie einen einigermaßen aktuellen Browser nutzen (höchstens 5-10 Jahre alt). Seit Ende Mai 2018 gibt es innerhalb von Server-Daten einen Letsencrypt-Client, der das seit Ende März 2018 nutzbare ACME-v2-Protokoll implementiert. Darüber werden kostenlose und automatisch beantragbare Zertifikate von Letsencrypt für alle Kunden bereitgestellt, die ihre Domain per Nameserver-Eintrag auf Server-Daten routen.

   

  Seither erfolgen alle Zugriffe (abgesehen von Weiterleitungen http ⇒ https) verschlüsselt.
• Die Server, auf welchen die Daten gespeichert werden, stehen ausschließlich in Deutschland. Technisch derzeit bei der Strato AG, Pascalstraße 10, 10587 Berlin, Deutschland als Auftragsverarbeiter.
• Zweck der Datenerhebung und Nutzung der Daten:
  • Kontaktformular: Kommunikation mit Ihnen
  • Blogkommentare: Anzeige des von Ihnen eingegebenen Namens und Ihres Kommentars, eventuell Ihrer Website. Bei Blogkommentaren wird Ihre Mailadresse niemals ausgegeben. Hier wird die Mailadresse höchstens zu Rückfragen bezüglich Ihres Kommentars genutzt.
  • Newsletter: Zusendung eines Newsletters.
  • Terminerinnerung stellt Ihnen einen kleinen und kostenlosen Erinnerungsservice bereit.
  • Auf beispiel/homepage-werkzeuge können Sie bestimmte Aktionen (bsp. Schreiben im Forum auf beispiel) nur als registrierter Nutzer durchführen.
  • sql: Hier können Nutzer eigene Abfragen auf einer Beispieldatenbank erstellen. Das geht ohne und mit Registrierung.
• Die Daten werden nicht zur Werbung genutzt. Die Daten werden nicht ohne Ihre Einwilligung an Dritte weitergegeben. Ausnahme: Ein Gesetz erlaubt die Weitergabe ausdrücklich, so daß eine Pflicht zur Herausgabe gegenüber Gerichten und Strafverfolgungsbehörden besteht. Die Daten werden nicht an ein Drittland oder an eine internationale Organisation weitergegeben.
• Auf den genannten Domains / Subdomains sind keine Werkzeuge / Scripte von anderen Unternehmen (Google, Facebook, deutsche oder europäische Werbenetzwerke, IVW-Zählpixel usw.) eingebunden. Damit werden Ihre Besuche auch nicht an diese Unternehmen bzw. Werbenetze weitergegeben.
• Die Dauer der Speicherung richtet sich nach den gesetzlichen Aufbewahrungspflichten. Bei freiwilligen Beiträgen / Kommentaren werden die Daten bis auf Widerruf gespeichert. Bei Beiträgen ohne Zuordnung zu einer Person (Blogkommentare ohne gültige Mailadresse, anonym eingestellte Sql-Abfragen) besteht kein Anspruch auf Löschung, da sich der Einsteller nicht verifizieren läßt.
• Sie haben Anspruch darauf, unentgeltlich zu erfahren, welche Daten von Ihnen gespeichert wurden. Sollten diese unrichtig sein, haben Sie Anspruch auf eine unentgeltliche Berichtigung. Sie können Ihre Einwilligung zur Speicherung jederzeit widerrufen, so daß die Daten gelöscht oder gesperrt werden. Der Anspruch auf Löschung besteht nicht, falls eigene berechtigte Interessen entgegenstehen.
• Sie haben die Möglichkeit, sich mit einer Beschwerde an uns oder an die für uns zuständige Datenschutzaufsichtsbehörde zu wenden:

   

  Berliner Beauftragte für Datenschutz und Informationsfreiheit - Friedrichstraße 219 - 10969 Berlin - Telefon: 030/138 89-0, Telefax: 030/215 50 50 - E-Mail: mailbox@datenschutz-berlin.de
• Falls Sie Fragen haben, nutzen Sie bitte das obige Kontaktformular oder das Telefon: +49(0)30 420 200 60.

Ferner gelten für all diese Nutzer die Hinweise zu Cookies.

 

2. Verwendung von Cookies während einer Sitzung

Die hiesige Website www.sql-und-xml.de läuft seit Anfang April 2018 ebenfalls auf der Architektur von Server-Daten. Das ermöglicht die Bereitstellung der Suche. Seither nutzt www.sql-und-xml.de das Session-Cookie, das innerhalb von Server-Daten für jeden Zugriff vergeben wird. Ferner __Host-__sd_Cookies_accepted zum Verwalten des Cookie-Banners genutzt.

 

2.1 Welche Cookies nutzt Server-Daten auf den Subdomains subdomain.server-daten.de?

1. __Host-subdomain.server-daten.de bzw. __Host-www.sql-und-xml.de sowie __Host-subdomain.server-daten.de.SSNone: Ein Session-Cookie-Paar, wie weiter unten beschrieben
2. __Host-accept_Cookies: Ein Session-Cookie, das testet, ob der Nutzer Cookies zuläßt
3. __Host-__sd_Login: Für Nutzer, die sich einloggen und die Funktion "angemeldet bleiben" nutzen: Ein Cookie, das die dafür benötigten Informationen ablegt. Das Cookie wird mit einer Lebensdauer von einem Jahr initialisiert und bei jeder Nutzung der Funktion "angemeldet bleiben" neu gesetzt. Wer sich bsp. gestern einloggt und heute deshalb bereits eingeloggt ist, dessen Cookie gilt von heute an ein Jahr. Wer sich abmeldet bzw. die Seite nicht eingeloggt aufruft, dessen __sd_Login - Cookie wird in ein Session-Cookie umgewandelt. Dieses löscht der Browser beim Schließen.
4. __GUID_Text: Auf einigen Seiten können nicht eingeloggte Nutzer Daten eingeben, diese speichern und ein PDF herunterladen, das u.a. die vom Nutzer eingegebenen Daten enthält. Das Cookie ist ein 90-Tage-Cookie und dient dazu, genau diesem Nutzer den Zugriff auf seine Informationen zu ermöglichen.
5. __Host-__sd_Cookies_accepted: Beim Erstaufruf einer Subdomain bzw. der hiesigen Domain wird einem nicht eingeloggten Nutzer ein Cookie-Banner am unteren Ende der Seite mit Hinweis auf das Setzen von Cookies, einem Bestätigungs- und einem Ablehnungsbutton sowie ein Link hierher angezeigt. Beim Klick auf den Bestätigungsbutton Ich stimme zu wird dieses Cookie mit yes und Datum/Uhrzeit des Klicks und einer einjährigen Gültigkeit gesetzt. Jeder weitere Aufruf einer Seite auf der Subdomain verlängert die Gültigkeit auf den Zeitpunkt ein Jahr später. Der Banner wird bei gesetztem Cookie nicht mehr angezeigt.
6. Wählt der Nutzer Ich lehne ab, dann wird dasselbe Cookie gesetzt, es beginnt aber mit no. Bei einem weiteren Aufruf werden sämtliche anderen Cookies gelöscht. Es kann dann allerdings sein, daß die Seiten nicht mehr wie gewünscht funktionieren.

    

   Denn damit fehlt auch die Session-Verwaltung.

    

   Will ein Nutzer das rückgängig machen, dann ist dieses Cookie zu löschen.

    

   FireFox: Ctrl + Shift + I, Web-Speicher auswählen, dort Cookies.

    

   Chrome: Ctrl + Shift + I, Application (Anwendung), Storage (Web-Speicher), Cookies.
7. Man kann auch die Position vertreten: Sämtliche gesetzten Cookies sind ausschließlich kurzlebige Session-Cookies und für das technische Funktionieren aller Seiten unerläßlich. Es gibt keine langlebigen Marketing-Cookies.

    

   Damit sei weder ein Cookie-Banner noch eine Einwilligung des Nutzers notwendig.

    

   Ferner sei es absurd, die Ablehnung von Cookies in einem Cookie zu speichern.

    

   Letzteres stimmt - nur gibt es technisch keine "freundlichere Art", sich die Entscheidung des Nutzers zu merken. Die Alternative wäre ein permanent eingeblendeter Banner für alle Personen, die den Banner weder bestätigen noch ablehnen.

    

   Ferner sind für Laien "kurzlebige Session-Cookies" nicht unbedingt erkennbar.

    

   Deshalb wurde im Gesamtsystem Server-Daten diese globale Lösung einheitlich implementiert.

Alle Cookies sind HttpOnly-Cookies. Das heißt, ein Auslesen per JavaScript ist nicht möglich. Seit Sommer 2020 sind die meisten Cookies __Host-Präfix-Cookies.

2.2 Warum benötigt man überhaupt Session-Cookies?

Bei anonymer Nutzung: Wenn Daten in ein Formular eingegeben werden, das sich über mehrere Seiten erstreckt, kann dazwischen eine Weiterleitung (per GET) notwendig sein. Läßt der Nutzer Cookies nicht zu, verliert er seine Eingaben. Dann ist das Formular für ihn nicht nutzbar.

 

Falls sich ein Nutzer anmelden möchte, muß er einmalig Nutzername und Passwort senden. Nach erfolgreicher Anmeldung sollten diese Daten gecacht und bis zur Abmeldung wiederverwendet werden.

 

Immer gilt: Das Http-Protokoll, mit dem Browser und Webserver Daten austauschen, ist statuslos. Zwei Anfragen durch denselben Nutzer sind für den Webserver voneinander isoliert. Der Webserver kann - ohne weitere Maßnahmen - nicht für die zweite Anfrage Nutzername und Passwort des ersten Aufrufs verwenden. Zur Lösung dieses Problem gibt es drei Möglichkeiten:

• Nutzername und Passwort werden bei jeder Anfrage mitgesendet, entweder in der Seitenadresse (seite.html?user=karl&pwd=topsecret) oder als Formulardaten. Im zweiten Fall wäre die Funktionalität einer Seite drastisch eingeschränkt.
• Durch Url-Umschreibungen: Der Webserver generiert nach der Anmeldung einen Zufallsschlüssel und hängt diesen an jeden Link an: seite.html?id=E94F0822-0FDC-4BBD-A725. Der Browser sendet bei jedem Aufruf diesen Zufallsschlüssel in der Adresse mit.
• Verwendung eines Session-Cookies: Der Webserver generiert ein Session-Cookie mit einem Zufallsschlüssel und sendet dieses an den Browser. Anschließend schickt der Browser bei jeder Anfrage an diese Domain das Session-Cookie mit.

Im ersten Fall müßten Nutzername/Passwort bei jedem Aufruf geprüft werden - ein offensichtlich aufwendiges Verfahren. Im zweiten und dritten Fall cacht der Webserver die Daten und verwendet als Verweis den zufälligen Schlüssel. Der zweite Fall führt allerdings zu dem Problem, daß ein Weitergeben des Links auch das Session-Cookie weitergeben würde. Deshalb wird diese Technik nicht genutzt.

2.3 Wie sehen Session-Cookies aus?

Das System verwendet ein Session-Cookie, um auf die Laufzeitdaten des Nutzers zu verweisen und diese auf dem Webserver (nicht im Browser) zu cachen. Ein Session-Cookie sieht wie folgt aus:

• Name: __Host-subdomain.server-daten.de bzw. __Host-www.sql-und-xml.de
• Content: qxfchp55nwbwdl553uckpy45 bzw. eine andere Zufallsfolge
• Host: Fehlt, da Cookies mit dem Präfix __Host- ausschließlich für den Hostnamen gelten, von dem sie erstmals geschickt wurden.
• Path: /
• expires: at end of session

Der Cookie-Name ist immer gleich dem Hostnamen, auf dem sich der Nutzer befindet. Das ist der Domainteil der Browseradresse - also entweder datenbankname.server-daten.de oder www.sql-und-xml.de. Der Content enthält eine zufällige, einmalige Zeichenfolge. Das Cookie läuft am Ende einer Session aus. Dies bedeutet, daß beim Beenden des Webbrowsers dieser solche Cookies im Normalfall von sich her löscht.

 

Ferner löscht der Webserver Sessions, die eine Stunde lang inaktiv waren.

 

Seit der Einführung des SameSite=Lax - Standardwerts (Sommer 2020) werden zwei Session-Cookies mit demselben Wert verschickt. Das Haupt-Cookie heißt __Host-subdomain.server-daten.de und nutzt SameSite=Lax, das zweite Cookie heißt __Host-subdomain.server-daten.de.SSNone und nutzt SameSite=None.

 

• Schickt der Browser beim Folgeaufruf beide Cookies mit, dann handelt es sich um einen SameSite-Aufruf (Adresse subdomain.server-daten.de in der Adresszeile). Dann wird das SSNone-Cookie "entwertet", indem sein Wert auf "-" gesetzt wird.
• Schickt der Browser beim Folgeaufruf nur das SSNone-Cookie, dann handelt es sich um einen Third-Party-Aufruf. Im Regelfall eine Einbindung einer Seite einer Kundendatenbank bei einem Partner dieses Kunden per iFrame. Dann funktioniert dieses SSNone-Cookie als Session-Cookie.
• Effekt (und Grund für diese Doppelversendung): SameSite-Nutzer haben damit den Schutz durch SameSite-Session-Cookies. Gewünschte iFrame-Einbindungen funktionieren weiterhin.

Bei den Laufzeitdaten des Nutzers kann es sich bsp. um den Namen der aktuell ausgewählten Tabelle im internen Menü 1 oder um eine Kopie des Datensatzes handeln, der dem Nutzer zur Ansicht angezeigt wird. Oder das System merkt sich, was der Nutzer zuletzt gesucht hat, um beim Neusortieren diesen Suchfilter beizubehalten. Die Aufgabe dieser Laufzeitdaten besteht darin, unnötige wiederholte Abfragen bei der Datenbank zu vermeiden und gleichzeitig nicht unnötig viele der für die korrekte Verarbeitung notwendigen Daten in versteckten Feldern mitsenden zu müssen. Nach erfolgreicher Authentifizierung enthalten die Laufzeitdaten zusätzlich einen zufälligen Anmeldeschlüssel, der vom Webserver verwendet wird, um den Nutzer bei Aktionen auf der Datenbank zu identifizieren. Meldet sich ein Nutzer ab, so wird dieser Anmeldeschlüssel intern gelöscht und die Session geschlossen. Aufgrund der verwendeten NET-Architektur öffnet die NET-Laufzeitumgebung allerdings sofort eine neue Session.

 

Diese Form der Session-Cookies wird von der auf dem Webserver verwendeten NET-Umgebung transparent genutzt. Ferner wird ein Session-Cookie genutzt, um zu prüfen, ob der Browser Cookies akzeptiert, ansonsten wird eine Fehlermeldung ausgegeben. Die Entscheidung zum Einsatz von Cookies anstelle von Url-Umschreibungen (seite.html?id=E94F0822-0FDC-4BBD-A725) wurde aus dem folgenden Grund getroffen: Werden mehrere Ausgabeseiten in eine Kundendomain eingebunden und gibt es die Möglichkeit, nach dem server-daten-Login einige Aktionen auszuführen, anschließend auf die Domain zu wechseln und einige Seiten später wieder Ausgabeseiten aufzurufen, so würde mit Url-Umschreibungen die Anmeldesession des Nutzers beim ersten Verlassen einer Ausgabeseite beendet werden. Würde derselbe Nutzer wenig später erneut eine für anonymen Zugriff gesperrte Ausgabeseite aufrufen, so müßte er sich erneut authentifizieren. Ein Cookie dagegen wird im Browsercache gespeichert und bei jedem Aufruf automatisch mitgesendet. Die Anmeldung bleibt damit im Rahmen solcher Bewegungen zwischen Ausgabeseiten und Seiten auf der Domain des Kunden geöffnet.

 

Da das System auf Url-Überschreibungen aus diesem Grund verzichtet, sind für alle authentifizierten Zugriffe Cookies erforderlich. Ansonsten gibt es für den Webserver keine Möglichkeit, den Aufruf nach einem erfolgreichen Login demselben, nun authentifizierten Nutzer zuzuordnen. Folglich verweigert der Webserver weiterhin den Zugriff auf geschützte Ressourcen, obwohl Nutzername und Passwort korrekt sind.

 

 

3. Wie aktiviere ich Cookies im Browser?

Wenn Sie ein Formular aufrufen, das in eine andere Website eingebunden ist, dann gelten die Cookies in diesem Formular als "Drittanbieter-Cookies" von Seiten, die Sie nicht besucht haben. Das kann zu Problemen mit Cookies führen, wenn ein Kunde von Server-Daten bzw. ein Partner dieses Kunden ein Formular auf seiner Website per iFrame-Fenster eingebunden hat.

 

Es gibt zwei Lösungsmöglichkeiten:

 

Variante 1 (empfohlen): Rufen Sie das Formular über den oben eingeblendeten Direktlink https://datenbankname.server-daten.de/Seite/Parameter auf. Dann genügt die Einstellung "Cookies von aktueller Seite zulassen" / "Cookies von besuchten Seiten zulassen".

 

Der Link wird nur eingeblendet, wenn Ihr System keine Cookies zuläßt. JavaScript muß zulässig sein, sonst klappt auch diese Überprüfung nicht.

 

Variante 2: Lassen Sie kurzzeitig "alle Cookies" bzw. "Cookies von Drittanbietern" zu.

 

Die Einstellungsmöglichkeit pro Browser:

• Safari / Apple: Klicken Sie in der Menüleiste auf "Safari", dann "Einstellungen", dort auf "Datenschutz".
• FireFox: Extras - Einstellungen - Datenschutz & Sicherheit: Cookies von Drittanbietern akzeptieren.
• Chrome: Einstellungen - in die Suche "Cookies" eingeben - Inhaltseinstellungen - Cookies - Drittanbieter-Cookies blockieren bzw. nicht blockieren.
• Internet Explorer: Extras - Internetoptionen - Datenschutz - Erweitert - Cookies von Erstanbietern / Cookies von Drittanbietern.
• Edge: Einstellungen - Erweiterte Einstellungen - Cookies.

Wenn Sie die Aktion auf dem Formular abgeschlossen haben, können Sie wieder Ihre ursprünglichen Cookie-Einstellungen setzen.

 

Weitere Fragen? Schicken Sie mir eine Nachricht, ein Kontaktformular finden Sie am Ende jeder Seite.

 

 

4. Verwendung von JavaScript

Die Regeln für HTML lassen es nur zu, daß mit Formulardaten eine Aktion ausgeführt wird. Diese wird im action-Attribut des <form>-Elements angegeben und durch das Anklicken des Senden-Buttons durch den Nutzer ausgelöst. Soll mit Formulardaten eine von mehreren, sich einander ausschließenden Aktionen ausgeführt werden, so gibt es zwei Möglichkeiten: Entweder müssen Nutzer aus einer zusätzlichen Pulldown-Liste einen Wert auswählen, mit welchem ein Feldwert geeignet belegt wird. Anschließend muß auf den Senden-Button geklickt werden. Oder es werden mehrere Schaltflächen erstellt, bei deren Aufruf dieses interne Feld per JavaScript vorbelegt und anschließend das Formular abgeschickt wird. Die erste Möglichkeit widerspricht der für die meisten Nutzer verständlichen Logik, mehrere Buttons mit erläuternden Beschriftungen anzugeben, aus welchen ein Button auszuwählen ist. Für die internen Masken wurde deshalb die zweite Lösung implementiert. Deren Nutzung erfordert die Aktivierung von JavaScript.

 

Für Ausgabeseiten sind die Anforderungen geringer, da hier bsp. nicht eine derzeit editierte Ausgabseite gespeichert, validiert oder in der Vorschau angezeigt werden soll. Hier wird der Button zum Suchen oder Speichern per JavaScript als a-Element erzeugt. Bei ausgeschaltetem JavaScript wird der Suche/Speichern-Button im <noscript>-Element als gewöhnlicher Submit-Button ausgegeben, so daß er nicht weiter formatiert werden kann. Die Suchbox zum Durchsuchen von Relationen steht nur bei aktiviertem JavaScript zur Verfügung. Bei deaktiviertem JavaScript könnten hier nur ebenfalls zwei Submit-Buttons eingefügt werden, um den eingegebenen Wert abzusenden. Diese wären nicht mehr voneinander unterscheidbar. Alle anderen Funktionen wie Sortierpfeile, ein Reset- und ein Neu-Link werden als gewöhnliche Links realisiert und senden den Formularinhalt nicht erneut.

 

 

---

 

 

5. Verhältnis zwischen dem Kunden und Server-Daten

Server-Daten erhebt, verarbeitet und nutzt personenbezogene Daten eines Kunden nur, soweit sie für die Vertragsbegründung und -abwicklung sowie zu Abrechnungszwecken erforderlich sind.

 

Zwingend erforderlich sind Name, Anschrift sowie eine gültige Mailadresse. Ohne diese Daten kann ein Vertrag nicht begründet werden.

 

Freiwillig sind Telefon und Fax. Diese werden - falls vorhanden - genutzt, um mit dem Kunden in bezug auf seine Datenbank in Kontakt zu treten. Falls der Kunde aufgrund von Störungen seines Netzanbieters seine Datenbank nicht erreichen kann, ermöglichen Telefon bzw. Fax den Rückruf durch Server-Daten und gestatten hierdurch ausnahmsweise eine ersatzweise Authentifizierung des Kunden. Fehlen diese Daten, so kann Server-Daten nur nach schriftlicher Bestätigung per Post tätig werden.

 

Die erhobenen Daten werden außerhalb der Kundendatenbank in einer Zeile einer gesonderten Tabelle gespeichert. Der Kunde kann diese jederzeit im Menü <Eigene Einstellungen> - <Kundendaten> abrufen. Der Kunde ist verpflichtet, die Korrektheit seiner Daten bei Änderung seiner Adresse o.ä. sicherzustellen. Server-Daten protokolliert, wie bei allen Änderungen innerhalb der Kundendatenbank, auch für die Kundendaten jeden Schreibzugriff und zeigt dieses Protokoll in gewohnter Weise an. Diese Daten sind nur für Server-Daten, den Kunden (= admin dieser Datenbank) sowie für Nutzer des Kunden sichtbar, welchen dieser das Recht zum Zugriff auf diese Daten eingerichtet hat.

 

Mietet ein Kunde mehrere Datenbanken, so wird immer auf denselben Kundendatensatz zurückgegriffen. Pro Datenbank werden die Informationen gespeichert, welche im Menü <Eigene Daten> - <Datenbank> angezeigt werden. Ändert der Kunde hier Daten, so wird dies analog protokolliert und angezeigt. Die Mailadresse kann für jede Datenbank individuell gewählt werden und entspricht immer der Mailadresse für den Nutzer admin in dieser Datenbank. Eine Änderung der Mailadresse über <Kundendaten> ist gleichbedeutend mit der Änderung über <Eigene Daten> - <Sicherheit>.

 

Für jede Datenbank ist unter <Eigene Daten> - <Datenbank> ein Disclaimer für Mails festzulegen. Dieser wird an Mails angehängt, die Nutzer bei ihrer Erstanmeldung (anonym, anonym mit Nick, Initialpasswort), dem Anfordern eines neuen Passworts, dem Ändern einer Mailadresse oder dem Einrichten einer Urlaubssperre erhalten. Diese Mails werden vom System automatisiert versandt. Der Disclaimer sollte Name und Mail eines verantwortlichen Ansprechpartners enthalten. Diese Mails werden immer von noreply @ server-daten.de versandt. Mails an diese Adresse werden gelöscht.

 

Die Abrechnungsdaten sind über <Eigene Einstellungen> - <Buchungen> zugänglich. Die dort gelisteten Daten werden anhand der letzten sowie der aktuellen Buchung berechnet.

 

Die Subdomains werden lokal eingerichtet. Deren Namen bzw. die Kundendaten werden deshalb nicht an Einrichtungen wie die DENIC weitergegeben. Der Kunde ist sich jedoch bewußt, daß Adressen der Form <datenbank-name.server-daten.de> nicht geheim sind, auch wenn der Kunde selbst keine Ausgabeseiten erstellt bzw. keine erstellte Ausgabeseite verlinkt. Ein anderer Interessent kann bsp. bei der Eingabe seiner Daten feststellen, daß der von ihm gewünschte Datenbank-Name bereits vergeben ist und daß eine Subdomain schon existiert. Daraufhin erstellt dieser Interessent einen Hyperlink auf seiner Domain auf die Subdomain von server-daten.de, Suchmaschinen finden den Link und listen die Subdomain, Nutzer von Suchmaschinen finden über die site-Abfrage die 'geheime Subdomain'.

 

Bei Vorliegen der entsprechenden Voraussetzungen ist Server-Daten berechtigt, die personenbezogenen Daten zu erheben, verarbeiten und zu nutzen, die zum Aufdecken sowie Unterbinden von rechtswidrigen Inanspruchnahmen und zur Durchsetzung von Ansprüchen gegenüber dem Nutzer erforderlich sind. Soweit es im Einzelfall erforderlich ist, ist Server-Daten berechtigt, zum Erkennen, Eingrenzen und Beseitigen von Störungen und Fehlern von Datenbanken die Bestands- und Verbindungsdaten der Beteiligten zu erheben, verarbeiten und zu nutzen.

 

Gemäß der hierfür geltenden gesetzlichen Bestimmungen ist Server-Daten berechtigt, Auskunft an Strafverfolgungsbehörden und Gerichte für Zwecke der Strafverfolgung zu erteilen.

 

Abgesehen von den genannten Fällen werden die erhobenen Daten nicht an Dritte weitergegeben und nicht von Server-Daten für Werbung genutzt. Die einzigste Nutzung der Mailadresse besteht darin, mit dem Kunden in bezug auf Probleme mit dessen Datenbank zu kommunizieren sowie zur Information bei einer geänderten AGB oder einer wesentlichen Änderung des Angebotes.

 

Server-Daten erteilt dem Kunden gemäß § 34 Abs. 1 BDSG auf Verlangen unentgeltlich und unverzüglich Auskunft über die zu seiner Person gespeicherten Daten. Server-Daten weist jedoch darauf hin, daß bei regulärer Nutzung durch den Kunden sämtliche zu ihm erhobenen Daten über die oben genannten Menüs vom Kunden abrufbar sind.

 

6. Verhältnis zwischen den Daten in Kundendatenbanken und Server-Daten

Daten in Kundendatenbanken gehören dem Kunden. Sie werden in keinem Fall von Server-Daten an Dritte verkauft oder weitergegeben, ausgenommen Auskunft an Strafverfolgungsbehörden und Gerichte.

 

Bei dem vordefinierten Nutzer <server-daten>, welcher zusätzlich zu <admin> in jeder Datenbank vordefiniert ist, handelt es sich nicht um einen Nutzer, der von Server-Daten interaktiv über den Browser aufgerufen werden könnte. Einen Nutzer mit dieser Eigenschaft gibt es nicht. Dem Nutzer <server-daten> ist die interaktive Anmeldung explizit untersagt. Er dient dazu, für gewisse Objekte (etwa den Nutzer <admin>) einen Besitzer bereitzustellen und für gewisse Systemaktivitäten einen Nutzer für die Protokollierung bereitzustellen. Hat bsp. ein Nutzer seine Mailadresse geändert und den Bestätigungsschlüssel in das Formular eingetragen, so wird die Freischaltung der Mail im Protokoll als Aktion von <server-daten> vermerkt.

 

Server-Daten versichert, daß es keine geheime Backdoor oder ähnliches gibt, welche es ihm ermöglichen würde, über einen Standardbrowser auf die Datenbank eines Kunden zuzugreifen. Der Kunde ist sich jedoch bewußt, daß Server-Daten als Administrator des Datenbank-Servers bzw. der MS-SqlServer-Grundsoftware jederzeit über diesen Weg auf alle Daten zugreifen kann und daß Server-Daten als Entwickler der zusätzlichen Module technisch dazu in der Lage ist, bsp. Daten unter Umgehung der im Modul implementierten Protokollierung direkt zu ändern, ohne daß diese Änderung in dem Protokoll erfaßt wird, welches für den Kunden sichtbar ist. Diese Sachverhalte werden hier erwähnt, nicht, weil geplant ist, sie mißbräuchlich zu nutzen, sondern weil sie sich aus der Architektur des Gesamtsystems ergeben.

 

 

7. Daten und Nutzer aus der Sicht des Kunden

Der Kunde ist verpflichtet, sich über die für ihn gültigen datenschutzrechtlichen Bestimmungen zu informieren und diese für seine Datenbank sowie gegenüber seinen Nutzern einzuhalten. Zu beachten ist, daß verschiedenste Möglichkeiten existieren. Ein Kunde kann seine Datenbank verwenden, ohne weitere Personen zuzulassen. Dann ist er der einzigste, der Objekte erstellt und Daten einträgt, importiert und exportiert. Hier fehlt das Verhältnis Kunde - Nutzer vollständig. Oder er läßt nur interne Nutzer zu, welche ohnehin in einem Rechtsverhältnis zu ihm stehen. Dies gilt bsp. bei einer Firmendatenbank, die nur von Mitarbeitern genutzt wird. Hier dürften die bereits existierenden Rechtsbeziehungen alles weitere regeln. Oder es werden Bekannte, Teilnehmer eines Kongresses oder ähnliche Personen als interne Nutzer eingetragen, Personen wird die anonyme Anmeldung auf einer Ausgabeseite erlaubt, sie werden als Nutzer der inneren Masken zugelassen oder erhalten weitere Rechte. In solchen Fällen erhebt ein Kunde Daten seiner Nutzer bei deren Anmeldung (Name, Mail), für die er verantwortlich ist. Ferner nutzt ein Kunde seine Datenbank vielleicht, um personenbezogene Daten seiner eigenen Geschäftsbeziehungen zu speichern. Hier könnte ein Geschäftspartner gemäß § 34 Abs. 1 BDSG Auskunft über die zu ihm gespeicherten Daten verlangen. Schließlich ist denkbar, daß der Kunde Daten importiert, die von Dritten bereitgestellt wurden und vom Kunden zum Zwecke der Marktforschung o.ä. genutzt werden.

 

Der Kunde hat eigenständig dafür Sorge zu tragen, daß seine Verantwortlichkeit sichtbar wird. Hierfür gibt es allerdings, je nachdem, welche Art von Ausgabeseiten gewählt wird, unterschiedlichste Lösungen. Erstellt ein Kunde keine Ausgabeseiten, so ist zwar die Login-Maske auf https://datenbank-name.server-daten.de/ sichtbar, ansonsten gibt es jedoch keine Informationspflichten. Bindet ein Kunde seine Ausgabeseiten so nahtlos in sein bereits bestehendes Webangebot ein, daß Leser ohnehin die Kontaktdaten des Hauptangebotes nutzen, so könnten weitere Hinweise überflüssig sein. Verfügt der Kunde über keine eigene Domain und erstellt er Ausgabeseiten, welche ohne iFrame/Frame-Einbindung direkt aufgerufen werden, so fügt er gegebenenfalls Impressum und weitere Daten seiner Subdomain hinzu.

 

Server-Daten ist für die einzelnen, für Kunden eingerichteten Subdomains nur im Rahmen der Mitstörerhaftung verantwortlich.

 

Zu beachten ist, daß Server-Daten nicht berechtigt ist, Auskunftsersuchen gemäß § 34 Abs. 1 BDSG, die von Dritten an Kunden gestellt werden, ersatzweise für den Kunden zu beantworten. Solche Auskunftsersuchen können nur von den Kunden beantwortet werden, welche diese Daten erhoben haben, Server-Daten muß solche Anfragen mit Verweis auf die Autonomie des Kunden in bezug auf seine Daten ablehnen.

 

 

8. Die Notwendigkeit zur Authentifizierung für jeden Schreibzugriff, die kontinuierlich mitlaufende Protokollierung

Datenbanken sind, bei hinreichend ausdifferenzierter Struktur, akzeptabel gegen Angriffe von außen schützbar. Alle von außen kommenden Anfragen werden zunächst über die Firewall auf den Http-Port 80 bzw. 443 eingeschränkt und an den Internetserver weitergegeben. Erst dieser authentifiziert sich beim Datenbankserver über eine schwache Verbindung und fordert Informationen an bzw. übergibt Daten gespeicherten Prozeduren, welche die Daten in Tabellen schreiben.

 

Schätzungen sprechen jedoch davon, daß Angriffe gegen Datenbanksysteme zu mehr als 60% von internen, ohnehin authentifizierten Nutzern durchgeführt werden. Hierfür gibt es unterschiedliche Möglichkeiten. Es kann sich um zu schwache Konfigurationsmöglichkeiten handeln, so daß alle Nutzer gleichermaßen stärkste Rechte haben. Die interne Protokollierung mag fehlen, so daß bei Änderungen unbekannt ist, welcher der schreibberechtigten Nutzer verantwortlich ist. Schließlich sind Administratoren meist berechtigt, Passwörter zu vergeben bzw. zu ändern, so daß sie die Identität eine anderen Nutzers annehmen, in dessen Namen Änderungen vornehmen und das Protokoll auf den in Wirklichkeit unbeteiligten Nutzer verweist.

 

Das hiesige System sieht deshalb vor, daß nur Nutzer mit Passwort schreibberechtigt sind. Die Ausnahme stellen Konfigurationen wie die anonyme Pizza-Bestellung dar. Für anonyme Nutzer gibt es ansonsten nur die Möglichkeit, das Formular zur Erstanmeldung auszufüllen. Dessen Daten werden jedoch nicht in den Kundendatenbanken gespeichert. Damit ist - mit Ausnahme expliziter Freigaben (Pizzabestellung) sichergestellt, daß bsp. nicht eine Kundendatenbank über eine Ausgabeseite mit sinnlosen Daten aufgefüllt wird, ihre Maximalgröße erreicht und keine weiteren Eingaben mehr annimmt. Ferner werden sämtliche Schreibzugriffe protokolliert (Tabelle, Zeile, ausführender Nutzer und Datum/Uhrzeit) und jedem Nutzer der internen Masken pro Datensatz angezeigt. Direkt sichtbar ist der letzte Editierzugriff, ein Link öffnet ein weiteres Fenster und zeigt sämtliche Bearbeitungen für diesen Datensatz an. Man könnte sagen: Wer in die Datenbank schreibt, kann sich nicht vor anderen Nutzern verstecken und übernimmt die Verantwortung für die Korrektheit der von ihm eingegebenen bzw. geänderten Daten. Schließlich gibt es keine Möglichkeit, daß ein Administrator für einen anderen Nutzer ein Passwort vergibt. Ein Passwort wird entweder automatisiert generiert und dem Nutzer zugesandt oder der Nutzer meldet sich an und ändert sein Passwort eigenständig.

 

Diese Sachverhalte sind wesentliche Teile der Gesamtkonzeption. Sie sind für alle Kunden und Nutzer verbindlich und nicht optional. Die mitlaufende Protokollierung stellt die Eingabekontrolle gemäß Punkt 5 der Anlage zu § 9 Satz 1 BDSG zur Verfügung und dehnt diese auf sämtliche Eingaben aus, anstatt sie auf personengebundene Daten zu beschränken. Jeder interne Nutzer kann über <Eigene Daten> - <Protokoll> die von ihm erzeugten Protokollaufzeichnungen tabellen- und datensatzübergreifend abrufen. Somit erzeugt die Protokollierung einerseits kontinuierlich neue personengebundene Daten, andererseits ist diese spezielle Form ausdrücklich vom BDSG gefordert. Die Möglichkeit einer nur optional wählbaren, zu einzelnen Tabellen hinzuschaltbaren Protokollierung wurde explizit nicht implementiert. Eine solche 'unscharfe Konzeption' tendiert dazu, unsinnige Konflikte zu erzeugen (Tabelle mit/ohne Protokollierung), so daß die Gefahr besteht, daß höherrangige Nutzer die Protokollierung ausschalten, um ungestört 'spielen' zu können und andere Nutzer Leidtragende der ungültig gewordenen, 'verspielten' Daten sind.

 

 

9. Vereinbarung zur Auftragsverarbeitung

Kunden erhalten Zugang zu einer internen Web-Datenbank. Dort können sie ihre Stammdaten ergänzen und - falls notwendig - jene Daten anlegen bzw. ergänzen, die für eine Vereinbarung zur Auftragsverarbeitung gemäß Artikel 28 DSGVO notwendig sind. Anschließend können sich Kunden drei Dokumente herunterladen:

• Die Vereinbarung zur Auftragsverarbeitung (Word-Dokument)
• Eine Kopie der Zeile, die Server-Daten in seinem eigenen Verzeichnis von Verarbeitungstätigkeiten für diesen Kunden hat und die nach Aufforderung der zuständigen Aufsichtsbehörde zur Verfügung gestellt wird (Excel-Tabelle)
• Eine Zeile, die der Kunde als Basis für sein eigenes Verzeichnis von Verarbeitungstätigkeiten nutzen kann (Excel-Tabelle)

Server-Daten nutzt diese interne Web-Datenbank zur Verwaltung seines eigenen Verzeichnisses von Verarbeitungstätigkeiten. Damit können die dafür zusätzlich benötigten Spalten auch Kunden angeboten und von diesen exportiert werden.

 

---

 

Server-Daten ist Mitglied der Gesellschaft für Datenschutz und Datensicherung e.V. (GDD)