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?
- __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
- __Host-accept_Cookies: Ein Session-Cookie, das testet, ob der Nutzer Cookies zuläßt
- __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.
- __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.
- __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.
- 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.
- 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)

Link zur hiesigen Seite als QR-Code
Kontaktformular:
Schreiben Sie mir und wir bauen gemeinsam Ihre neue Web-Datenbank!
© 2003-2025 Jürgen Auer, Berlin.