Technische und organisatorische Maßnahmen

Anlage 2 zum Vertrag über die Verarbeitung personenbezogener Daten im Auftrag

Technische und organisatorische Maßnahmen nach Art. 32 DSGVO HN Solutions Management GmbH, Bullermannshof 7, 47441 Moers

1. Vertraulichkeit

Zutrittskontrolle. Der Produktionsserver steht in einem zugangsgesicherten Firmenbüro des Auftragsverarbeiters. Zugriff auf die Server-Hardware haben nur Mitarbeitende mit Systemadministrations-Aufgabe.

Zugangskontrolle. Der Fernzugang zum Server ist ausschließlich über Public-Key-Authentifizierung möglich; eine Anmeldung mit Passwort ist abgeschaltet. Die Verwaltungsoberfläche des Servers liegt hinter einer eigenen Authentifizierung.

Zugriffskontrolle auf Anwendungsebene. Die Trennung der Mandanten erfolgt durch verpflichtende Zeilenzugriffsregeln der Datenbank (PostgreSQL Row Level Security) auf jeder mandantenbezogenen Tabelle, nicht nur im Anwendungscode. Es bestehen drei getrennte Datenbankrollen mit jeweils minimalen Rechten: eine für Schemaänderungen, eine für den laufenden Betrieb der Anwendung und eine für die Plattformverwaltung. Nur die erste hat Rechte zur Schemaänderung; die Rolle der Anwendung kann die Zeilenzugriffsregeln nicht umgehen.

Auskunftsexporte und Datenausfuhren liegen außerhalb des öffentlich ausgelieferten Medienbaums, in einem eigenen Speicherbereich ohne Adresse im Netz. Abrufbar sind sie nur über eine Seite mit Prüfung der Inhaberrolle im jeweiligen Mandantenkontext. Auskunftsexporte werden nach 14 Tagen entfernt, sofort bei Löschung der zugehörigen Kundenakte; Gesamtausfuhren des Studios nach 30 Tagen. Der öffentliche Medienpfad liefert ausschließlich eine feste Liste erlaubter Präfixe aus, nämlich Logos, Titelbilder und Mitarbeiterfotos.

Für alle Betreiberzugänge, also die Plattform-Konsole und die technische Administrationsoberfläche, ist eine Zwei-Faktor-Anmeldung (TOTP) verbindlich. Ohne bestätigten zweiten Faktor sind weder die Konsole noch die Übernahme einer Studio-Sitzung erreichbar. Es bestehen zehn einmalig verwendbare Wiederherstellungscodes; die Eingabe ist gedrosselt. Einrichtung, Fehlversuche und Rücksetzung werden zwei Jahre lang protokolliert. Eine Rücksetzung ist nur mit verifizierter Sitzung oder unmittelbar auf dem Server möglich.

Status- und Abmeldelinks sind zweckgebunden und verfallen. Zweck und Ablauf werden beim Auflösen des Links geprüft, nicht erst beim Aufbau der Seite.

Passwörter werden mit Argon2 gehasht; überholte Verfahren wie MD5 oder SHA-1 kommen nicht zum Einsatz.

Endkundinnen und Endkunden haben kein Passwort. Das Kundenkonto auf der Buchungsseite wird über einen Einmal-Link freigeschaltet, der 30 Minuten gültig und einmal verwendbar ist und nur als SHA-256-Hash gespeichert wird. Die Sitzung gilt je Studio und wird bei jedem Aufruf gegen den Datenbestand geprüft, damit eine gelöschte oder anonymisierte Person nicht über eine laufende Sitzung weiter Zugriff hat. Das gilt auch für die Anlage eines Kontos: sie legt zwar eine Kundenakte an, gibt aber selbst keinen Zugriff. Dieser entsteht erst mit dem bestätigten Link aus der E-Mail, der zugleich der Nachweis ist, dass die Adresse der anlegenden Person gehört.

An allen Stellen, die eine E-Mail auslösen oder ein Passwort prüfen — Anmeldung, Zurücksetzen des Passworts, Anmeldelink des Kundenkontos, öffentliche Formulare —, besteht eine Drosselung gegen automatisierte Angriffe und gegen den Missbrauch zum Massenversand. Sie arbeitet mit festen Zeitfenstern und lässt bei einer Störung des Zählwerks bewusst durch, damit eine technische Störung nicht die Anmeldung aller Studios lahmlegt.

Die Berechtigungen sind rollenbasiert (Plattformverwaltung, Inhaberin oder Inhaber, Mitarbeitende); orthogonal dazu steht die Freischaltung von Funktionen nach gebuchtem Paket.

Die Übernahme einer Studio-Sitzung durch die Plattformverwaltung ist nur mit Protokollpflicht und sichtbarem Hinweis in der Oberfläche möglich; ein verdeckter Fremdzugriff ist ausgeschlossen. Vor dem Start ist ein Grund anzugeben, der mitprotokolliert wird. Die Sitzung endet nach 60 Minuten automatisch, auch ohne Zutun.

Die technische Administrationsoberfläche ist auf Lesezugriff beschränkt. Änderungen an Studios, Paketen und Abonnements laufen ausschließlich über die Plattform-Konsole und damit über das Protokoll. Einzige Ausnahme ist die Benutzerverwaltung als Notzugang.

Trennungskontrolle. Jedes Projekt läuft in einem eigenen, exklusiven Container-Netz, getrennt von den übrigen Netzen des Betreibers. Ein Datenaustausch zwischen Studios findet auf Anwendungsebene nicht statt; die Zuordnung erfolgt ausschließlich über eine je Anfrage gesetzte, datenbankseitig abgesicherte Mandantenkennung.

Pseudonymisierung und Verschlüsselung. Der gesamte öffentliche Datenverkehr ist mit TLS verschlüsselt, terminiert durch den Reverse-Proxy des Servers mit einem Zertifikat von Let's Encrypt; unverschlüsselte Aufrufe werden umgeleitet.

Alle Links, die ohne Anmeldung eine Handlung erlauben — Absagelink, Terminverwaltungslink zum Verschieben, Schreiben und Absagen sowie für einen Ersatztermin nach einem Ausfall, Anspruchslink der Warteliste, Anmeldelink des Kundenkontos und Statuslink der Warteschlange bei Selbstanmeldung per QR-Code —, werden ausschließlich als SHA-256-Hash gespeichert, nie im Klartext. Ein Abfluss der Datenbank allein genügt damit nicht, um sie zu benutzen. Der Verwendungszweck steckt im Link selbst und wird beim Auflösen geprüft: ein Absagelink öffnet die Terminverwaltung nicht.

2. Integrität

Automatisierte Tests decken die Mandantentrennung, den Schutz vor Doppelbuchungen, die Korrektheit von Zeitzonen und Zeitumstellungen sowie die Berechtigungsmatrix ab. Sie laufen bei jeder Änderung am Code und schützen vor unbeabsichtigter Datenveränderung durch neue Funktionen.

Sicherheitsrelevante Vorgänge werden unveränderlich protokolliert, jeweils mit handelnder Person, Zeitpunkt und betroffenem Objekt. Dazu gehören die Übernahme einer Studio-Sitzung samt Grund und automatischem Ablauf, Auskunft und Löschung nach DSGVO, die Beendigung und Reaktivierung eines Studios sowie die Vergabe und der Entzug von Plattformrechten.

Wo Korrektheit sicherheitskritisch ist, sichern Bedingungen der Datenbank sie ab und nicht allein die Anwendungslogik. Das gilt insbesondere für den Schutz vor Doppelbuchungen und für die Prüfung von Zeitfenstern.

3. Verfügbarkeit und Belastbarkeit

Die Datenbank wird täglich gesichert, 30 Tage rollierend, durch einen nächtlich laufenden Sicherungsauftrag des Servers. Anschließend erfolgen eine Dateisicherung und eine Kopie auf ein zweites Gerät im Netz des Betreibers, die dort 90 Tage vorgehalten wird. Das Wiederherstellungsverfahren ist dokumentiert und wurde durchgeführt.

Die Sicherungen sind im Ruhezustand verschlüsselt (Art. 32 Abs. 1 lit. a DSGVO). Jede Sicherung wird beim Entstehen mit age verschlüsselt (X25519 in Verbindung mit ChaCha20-Poly1305), lokal wie in der zweiten Kopie. Ein unverschlüsselter Abzug wird zu keinem Zeitpunkt auf einen Datenträger geschrieben, sondern unmittelbar aus der Datenbank in die Verschlüsselung geleitet. Auf dem Server liegt ausschließlich der öffentliche Schlüssel: wer Zugriff auf den Server erlangt, kann damit neue Sicherungen erzeugen, vorhandene aber nicht lesen. Auch die vor der Umstellung entstandenen Sicherungen wurden nachträglich verschlüsselt; unverschlüsselte Sicherungen bestehen nicht mehr.

Schlüsselverwaltung. Es bestehen zwei private Schlüssel. Sie dienen der Ausfallsicherheit und nicht einer Mehr-Augen-Kontrolle: jeder von beiden genügt für sich allein zur Entschlüsselung. Sie werden getrennt voneinander und außerhalb des Servers aufbewahrt, der eine in einem mehrfaktorgeschützten Passwortmanager, der andere auf dem Arbeitsgerät des Verantwortlichen sowie in einem privaten Cloud-Speicher. Kein privater Schlüssel liegt auf dem Anwendungsserver oder auf dem Sicherungsziel; wer Zugriff auf den Server erlangt, kann vorhandene Sicherungen daher nicht entschlüsseln. Der Verlust eines einzelnen Aufbewahrungsorts führt nicht zum Verlust der Wiederherstellbarkeit. Die genannten Cloud-Speicher erhalten weder Zugriff auf den Datenbestand noch auf die Sicherungen selbst; sie verwahren ausschließlich Schlüsselmaterial.

Störungen der Anwendung werden technisch überwacht, sodass Fehler sichtbar werden, bevor ein Studio sie meldet.

Der Betrieb erfolgt auf einem einzelnen Server ohne zweites, sofort einspringendes System. Dieses Risiko ist bekannt und bewusst getragen; die Wiederherstellung stützt sich auf die oben beschriebenen Sicherungen.

4. Verfahren zur regelmäßigen Überprüfung

Bei jeder Änderung am Code läuft eine automatisierte Prüfstrecke. Sicherheitsprüfungen, die die Abdeckung der Mandantentrennung, den Schutz aller Adressen und die Konsistenz der Datenbankänderungen kontrollieren, dürfen dabei nicht übersprungen werden.

Die Wiederherstellung aus einer Sicherung ist dokumentiert und nachvollziehbar durchgeführt worden. Eine Sicherung gilt erst mit verifiziertem Wiederherstellungsweg als vollständig.

Die Aufbewahrungsfristen werden automatisiert durchgesetzt. Ein nächtlicher Auftrag wendet sie je Studio an; jeder Lauf schreibt eine Zusammenfassung in das Protokoll und macht die Einhaltung damit nach Art. 5 Abs. 2 DSGVO nachweisbar.

5. Auftragskontrolle (Unterauftragsverarbeiter)

Der Betrieb der Anwendungs- und Datenbankserver erfolgt durch den Auftragsverarbeiter selbst auf einem Server in seinen eigenen Räumen in Deutschland.

Amazon Web Services EMEA SARL übernimmt über Amazon Simple Email Service den Versand der E-Mails an die Endkundschaft des Studios — Bestätigung, Erinnerung, Absage, Verschiebung, Ausfallmitteilung, Wartelistenangebot, Nachrichten und Anmeldelink — sowie die Entgegennahme der Zustellereignisse. Ort der Verarbeitung ist die Region eu-central-1 in Frankfurt am Main. Mit Amazon besteht ein Vertrag zur Auftragsverarbeitung. Über denselben Weg versendet der Auftragsverarbeiter Rechnung und Zahlungserinnerung des Abos an das Studio selbst; dabei ist er Absender und eigener Verantwortlicher, nicht das Studio.

Ein Dienst zur Fehlerüberwachung mit Sitz in der Europäischen Union ist technisch vorbereitet, derzeit aber nicht eingeschaltet und damit kein Unterauftragsverarbeiter. Vor einer Aktivierung wird er in diese Anlage aufgenommen und den Studios nach § 8 Abs. 3 des Vertrages vorab angezeigt.

Stripe Payments Europe Ltd., Dublin, wickelt die Zahlungen der Studio-Abos ab, also das Hinterlegen von Mandat oder Karte und den monatlichen Einzug. Stripe ist kein Unterauftragsverarbeiter des Studios, sondern Dienstleister für die eigene Verarbeitung des Auftragsverarbeiters. Die Konzernmutter in den Vereinigten Staaten ist über das EU-US Data Privacy Framework und Standardvertragsklauseln eingebunden.

Die Rechnungsstellung und Buchhaltung der Abos führt der Auftragsverarbeiter in einem eigenen System auf seinem Server in Deutschland.

Kein Unterauftragsverarbeiter erhält direkten Zugriff auf die Datenbank. Stripe erhält ausschließlich die für die Zahlung nötigen Angaben des Studios, also Firma, Rechnungsanschrift und Betrag, und liefert im Gegenzug nur Referenzen zurück. Zahlungsdaten selbst, also Kontonummern und Kartennummern, werden in dieser Anwendung zu keinem Zeitpunkt gespeichert; sie werden ausschließlich auf einer von Stripe betriebenen Bezahlseite erfasst und berühren die Server des Auftragsverarbeiters nie. Amazon Simple Email Service erhält ausschließlich die Empfängeradresse und den Inhalt der jeweiligen Nachricht, keinen Zugriff auf den Datenbestand. Je Studio besteht ein eigener Mandant mit eigener Konfiguration, sodass Zustellereignisse und Zustellreputation nicht zwischen Studios vermischt werden.

Es wird kein Dienst zur Verkehrsvermittlung oder Inhaltsauslieferung eines Drittanbieters eingesetzt; der Server beantwortet die Aufrufe selbst. Aus demselben Grund ist auch die Spam-Prüfung der öffentlichen Buchungsseite selbst betrieben: Sie rechnet ausschließlich im Browser der Besucherin, es wird kein Drittanbieter eingebunden, kein Cookie gesetzt und kein Datum übermittelt.

Der einzige Aufruf nach außen im Buchungsweg ist eine Namensauflösung des Domain-Teils einer eingegebenen E-Mail-Adresse, um erfundene Adressen abzuweisen. Übermittelt wird dabei nur der Domain-Teil, nie die vollständige Adresse; das Ergebnis wird je Domain zwischengespeichert, nicht je Person.