Ungesicherte Subdomains und Testumgebungen sind h\u00e4ufige Quellen f\u00fcr Datenschutzschwachstellen, weil sie oft personenbezogene Daten enthalten, aber nicht mit denselben Sicherheitsma\u00dfnahmen wie Produktivsysteme gesch\u00fctzt werden. Besonders kritisch ist, dass diese Bereiche technisch \u00f6ffentlich erreichbar sein k\u00f6nnen, ohne dass dies beabsichtigt oder bekannt ist. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um dieses untersch\u00e4tzte Datenschutzrisiko.<\/p>\n
Auf Testumgebungen sind h\u00e4ufig echte personenbezogene Daten gef\u00e4hrdet, weil Entwicklungsteams zur Fehlersuche oder zum Testen von Funktionen auf Kopien der Produktionsdatenbank zur\u00fcckgreifen. Dazu k\u00f6nnen Kundennamen, E-Mail-Adressen, Bestellhistorien, Login-Daten oder sogar Zahlungsinformationen geh\u00f6ren, die in der Testumgebung unverschl\u00fcsselt oder unzureichend gesichert vorliegen.<\/p>\n
Typischerweise finden sich auf Testservern folgende datenschutzrelevante Inhalte:<\/p>\n
Hinzu kommt, dass auf Testumgebungen oft externe Dienste wie Analytics-Tools oder Werbepixel aktiv sind, weil die Konfiguration einfach aus der Produktivumgebung \u00fcbernommen wurde. Diese Dienste \u00fcbertragen dann Daten an externe Server, ohne dass eine rechtliche Grundlage daf\u00fcr besteht. Das macht Testumgebungen aus datenschutzrechtlicher Sicht besonders problematisch.<\/p>\n
Ungesicherte Subdomains stellen ein DSGVO-Risiko dar, weil sie personenbezogene Daten verarbeiten oder zug\u00e4nglich machen k\u00f6nnen, ohne dass die erforderlichen technischen und organisatorischen Schutzma\u00dfnahmen nach Artikel 32 DSGVO umgesetzt sind. Jede Subdomain, die im Rahmen des Unternehmens betrieben wird, unterliegt denselben datenschutzrechtlichen Anforderungen wie die Hauptdomain.<\/p>\n
In der Praxis entstehen Datenschutzrisiken durch Subdomains auf mehreren Ebenen:<\/p>\n
Verantwortliche \u00fcbersehen dabei oft, dass auch intern genutzte Subdomains in den Anwendungsbereich der DSGVO fallen, sobald dort personenbezogene Daten verarbeitet werden. Die Unterscheidung zwischen \u201e\u00f6ffentlich“ und \u201eintern“ sch\u00fctzt rechtlich nicht vor Pflichten.<\/p>\n
Suchmaschinen-Crawler und andere automatisierte Bots k\u00f6nnen auf Testumgebungen zugreifen, wenn diese keine Zugangsbeschr\u00e4nkungen wie einen Passwortschutz, eine IP-Whitelist oder eine korrekte Die h\u00e4ufigsten Einfallstore f\u00fcr unerw\u00fcnschte Crawler sind:<\/p>\n Sobald eine Testumgebung indexiert ist, k\u00f6nnen dort enthaltene Daten in Suchergebnissen auftauchen. Das betrifft nicht nur Inhalte, sondern auch Metadaten, Debug-Informationen oder versehentlich ver\u00f6ffentlichte Dateien. F\u00fcr betroffene Personen, deren Daten so zug\u00e4nglich werden, stellt dies eine schwerwiegende Datenschutzverletzung dar, die nach Artikel 33 DSGVO unter Umst\u00e4nden meldepflichtig ist.<\/p>\n Die h\u00e4ufigsten Fehler bei der Absicherung von Subdomains sind fehlende Zugangsbeschr\u00e4nkungen, vergessene oder abgelaufene SSL-Zertifikate sowie die unkritische \u00dcbernahme der Produktivkonfiguration inklusive aller Drittanbieter-Dienste. Diese Fehler entstehen oft nicht aus Fahrl\u00e4ssigkeit, sondern weil Subdomains und Testumgebungen au\u00dferhalb regul\u00e4rer Wartungsprozesse liegen.<\/p>\n Besonders riskant ist die Kombination aus echten Produktionsdaten und fehlender Absicherung. Wenn ein Entwickler schnell eine Testumgebung aufsetzen m\u00f6chte, wird die Datenbank aus dem Produktivsystem kopiert, ohne die enthaltenen Daten zu anonymisieren oder zu pseudonymisieren. Dieser Schritt wird in der Praxis h\u00e4ufig ausgelassen, weil er als zeitaufwendig gilt.<\/p>\n Subdomains und Testumgebungen lassen sich datenschutzkonform absichern, indem Zugangsbeschr\u00e4nkungen konsequent umgesetzt, echte Produktionsdaten durch anonymisierte Testdaten ersetzt und alle Subdomains in regelm\u00e4\u00dfige Datenschutzpr\u00fcfungen einbezogen werden. Entscheidend ist, dass diese Ma\u00dfnahmen von Anfang an in den Entwicklungsprozess integriert werden.<\/p>\n Die wichtigsten Schutzma\u00dfnahmen im \u00dcberblick:<\/p>\n F\u00fcr die Datenschutz-Compliance von Subdomains ist grunds\u00e4tzlich der datenschutzrechtlich Verantwortliche im Sinne von Artikel 4 Nr. 7 DSGVO zust\u00e4ndig, also in der Regel das Unternehmen, das die Subdomain betreibt. Diese Verantwortung gilt unabh\u00e4ngig davon, ob die Subdomain intern entwickelt, von einer Agentur betreut oder von einem Dienstleister gehostet wird.<\/p>\n In der Praxis verteilt sich die operative Verantwortung auf mehrere Rollen:<\/p>\n Entscheidend ist, dass die Verantwortung f\u00fcr Subdomains nicht automatisch mitgedacht wird. Viele Unternehmen haben kein vollst\u00e4ndiges Inventar ihrer aktiven Subdomains, was eine systematische Pr\u00fcfung von vornherein erschwert. Datenschutzbeauftragte sollten daher regelm\u00e4\u00dfig aktiv nachfragen, welche neuen Subdomains oder Testumgebungen eingerichtet wurden.<\/p>\n Ungesicherte Subdomains und Testumgebungen systematisch zu erfassen und zu pr\u00fcfen, ist manuell kaum leistbar, besonders wenn viele Websites oder Domains parallel betrieben werden. Wir bei decareto bieten eine automatisierte L\u00f6sung, die genau hier ansetzt:<\/p>\nrobots.txt<\/code>-Konfiguration haben. Sobald eine Testumgebung \u00f6ffentlich erreichbar ist, kann sie von Suchmaschinen indexiert und damit f\u00fcr jeden auffindbar werden.<\/p>\n\n
Was sind die h\u00e4ufigsten Fehler bei der Absicherung von Subdomains?<\/h2>\n
Technische Fehler<\/h3>\n
\n
robots.txt<\/code> oder noindex<\/code>-Direktiven<\/li>\n<\/ul>\nOrganisatorische Fehler<\/h3>\n
\n
Wie lassen sich Subdomains und Testumgebungen datenschutzkonform absichern?<\/h2>\n
\n
robots.txt<\/code> mit Disallow: \/<\/code> sowie noindex<\/code>-Meta-Tags verhindern die Indexierung durch Suchmaschinen.<\/li>\nWer ist f\u00fcr die Datenschutz-Compliance von Subdomains verantwortlich?<\/h2>\n
\n
So unterst\u00fctzt decareto bei der Pr\u00fcfung von Subdomains und Testumgebungen<\/h2>\n
\n