Technische und organisatorische Maßnahmen

Fassung vom 05.11.2026 · Anlage zum Vertrag über die Auftragsverarbeitung · nach Art. 32 DSGVO

1. Was diese Anlage beschreibt

Diese Anlage beschreibt die Maßnahmen, die beim Betrieb von Ladenbote tatsächlich umgesetzt sind. Was erst geplant ist, steht ausdrücklich als „geplant“ in Ziffer 13; was es nicht gibt, steht dort ebenfalls.

• Betreiber: Najim Belhaj, Codefaden – Ladenbote, ein Ein-Personen-Unternehmen.
• Server: ein virtueller Server der netcup GmbH in einem Rechenzentrum in Wien (Österreich, EU), Betriebssystem Debian 13. Auf demselben Server laufen weitere Dienste des Betreibers (unter anderem Website-Überwachung, Werbevideos, ein Nachrichtenportal und die eigene Verwaltung), jeder unter einem eigenen Systembenutzer. Keiner davon kann Gäste- oder Bestelldaten von Ladenbote lesen; der Werbevideo-Dienst sieht nur Sichten ohne Gäste und ohne einzelne Bestellungen (Karte, Fotos, Öffnungszeiten, Aktionen, Zählungen).
• Software: Ladenbote (Node.js, PostgreSQL 17, nginx als einziger Zugang von außen).

2. Zutritt zu den Servern

• Ladenbote betreibt keine eigenen Serverräume. Der physische Schutz der Rechenzentren (Zutrittskontrolle, Brandschutz, Stromversorgung) liegt bei netcup und richtet sich nach dessen Vertrag über die Auftragsverarbeitung.
• Daten der Läden werden nicht auf mobilen Datenträgern oder Papier vorgehalten.

3. Zugang zum Server

• Firewall (nftables): Eingehend ist alles gesperrt außer SSH (Port 22, höchstens 15 neue Verbindungen je Minute) und HTTP/HTTPS (Ports 80 und 443).
• SSH nur mit Schlüssel. Anmeldung mit Kennwort und interaktive Anmeldung sind abgeschaltet, höchstens drei Versuche je Verbindung. Es gibt zwei berechtigte Schlüssel: den Verwaltungsschlüssel des Betreibers und einen Schlüssel, der nur das Sicherungsverzeichnis lesen darf.
• fail2ban sperrt eine Adresse nach drei gescheiterten SSH-Anmeldungen in zehn Minuten für eine Stunde, Wiederholungstäter für eine Woche.
• Notzugang nur über die Konsole im Kundenbereich von netcup.
• Die Datenbank nimmt nur Verbindungen vom Server selbst an. Der Dienst meldet sich über den lokalen Unix-Socket nach Systembenutzer an; ein Datenbank-Kennwort, das irgendwo liegen könnte, gibt es dafür nicht.
• Der Dienst lauscht nur auf der lokalen Adresse 127.0.0.1; von außen ist er nur über nginx erreichbar.
• Der Dienst läuft als eigener Systembenutzer mit Härtung durch systemd: Programmcode nur lesbar, Schreiben nur in seinem Datenordner, keine Sonderrechte, keine neuen Rechte zur Laufzeit, eigenes temporäres Verzeichnis, kein Zugriff auf Home-Verzeichnisse und Geräte, eingeschränkte Systemaufrufe und Netzwerkarten, fremde Prozesse unsichtbar, neue Dateien nicht für andere lesbar.
• Zugangsschlüssel für Dienste (Stripe, Telegram, Bilddienst) stehen in einer Datei, die nur root lesen kann, nicht im Programmcode.
• Sicherheitsupdates des Betriebssystems werden täglich automatisch eingespielt; wenn nötig, startet der Server um 04:30 Uhr neu.

4. Anmeldung in der Verwaltung

• Kennwörter haben mindestens zehn Zeichen und werden nur als Prüfwert mit scrypt und zufälligem Salz gespeichert. Auch für unbekannte Konten wird gerechnet, damit die Antwortzeit nicht verrät, ob es eine Adresse gibt. Gleichzeitige Berechnungen sind begrenzt.
• Bremse gegen Raten: höchstens zehn Fehlversuche je Adresse und je Konto in 15 Minuten.
• Sitzungen: zufälliger Schlüssel von 256 Bit in einem Cookie mit HttpOnly, Secure und SameSite=Strict, gültig 30 Tage. In der Datenbank steht nur sein SHA-256-Wert. Ein Kennwortwechsel beendet alle anderen Sitzungen des Kontos.
• Zugangslinks für neue Konten und zum Neusetzen eines Kennworts: zufälliger Schlüssel von 192 Bit, gespeichert nur als SHA-256-Wert, gültig sieben Tage und nur einmal, höchstens zehn offene je Laden. Der Schlüssel steht hinter dem „#“ der Adresse und gelangt deshalb in kein Zugriffsprotokoll. Ein Link für ein Konto mit zweitem Faktor meldet nicht an, sondern verlangt danach die gewöhnliche Anmeldung mit Code.
• Zwei-Faktor-Anmeldung mit einer Authenticator-App (TOTP nach RFC 6238) für Betreiber- und Ladenkonten, mit acht einmaligen Ersatzcodes, von denen nur Prüfwerte gespeichert sind, und Schutz gegen die Wiederverwendung eines Codes.
• Schutz gegen fremde Seiten, die im Namen eines angemeldeten Browsers handeln wollen: Cookie mit SameSite=Strict, schreibende Anfragen nur als JSON und nur von der eigenen Herkunft.

5. Rechte und Trennung der Läden

• Zwei aktive Rollen: Betreiber und Laden (Inhaber und Team).
• Die Trennung der Läden hängt an einer einzigen Stelle im Programm: Für Ladenkonten kommt der Laden immer aus dem Konto, nie aus der Anfrage. Jede Abfrage der Verwaltung ist auf diesen Laden beschränkt. Automatische Tests versuchen jeden Weg in einen fremden Laden einzeln und laufen vor jeder Auslieferung.
• Gäste sehen auf der Statusseite ihrer Bestellung keine eigenen Angaben zur Person; der Link enthält einen zufälligen Schlüssel. Gespeicherte Daten eines Gastes zeigt der Shop niemandem an, auch nicht, wenn jemand eine Telefonnummer eingibt; ob jemand Neukunde ist, prüft nur der Server.
• Die Verwaltung ist unter den Adressen der Shops nicht erreichbar; nginx und der Dienst sperren sie dort beide.
• Zugriffe des Betreibers auf die Verwaltung eines Ladens werden je Tag, Konto und Bereich protokolliert. Der Laden sieht die letzten 90 Tage selbst; nach zwölf Monaten wird das Protokoll gelöscht.
• Die Tests laufen gegen eine eigene Testdatenbank mit erfundenen Daten, getrennt von der Datenbank der Läden.

6. Datensparsamkeit und Protokolle

• Zugriffsprotokolle des Webservers enthalten Adresse, Zeit, Methode, Pfad ohne Abfrageteil, Status, Größe und Dauer; keine Browserkennung und keinen Referrer. Geheime Teile von Pfaden (Bestellzugänge, Newsletter-Links, Schlüssel von Druckern und Anrufmonitoren) werden unkenntlich gemacht. Aufbewahrung: 14 Tage. Fehlerprotokolle des Webservers ebenfalls 14 Tage.
• Das Protokoll des Dienstes nennt bei Fehlern das Routenmuster statt des Pfads und keine Inhalte, die einen Fehler ausgelöst haben. Es wird höchstens einen Monat aufbewahrt (höchstens 300 MB).
• Bremsen gegen Missbrauch halten Adressen nur im Arbeitsspeicher und nur für zehn bis 15 Minuten.
• Angaben zur Person werden aus Bestellungen und Kundenkartei nach der eingestellten Frist automatisch entfernt; die Bestellungen bleiben als Beleg ohne Namen. Anrufe werden nach 24 Stunden gelöscht, unbestätigte Newsletter-Anmeldungen nach 48 Stunden.
• Das Änderungsprotokoll der Bestellungen nimmt keine Angaben zur Person auf.
• Der Shop setzt keine Cookies, keine Analyse- oder Werbedienste und keine fremden Schriften oder Skripte ein.

7. Verschlüsselung

• Alle Verbindungen von außen nur verschlüsselt mit TLS 1.2 oder 1.3; HTTP wird auf HTTPS umgeleitet, HSTS ist für ein Jahr gesetzt. Unbekannte Hostnamen bekommen keinen Verbindungsaufbau.
• Verbindungen des Dienstes zu Stripe, zum Mailversand, zu HubRise, zum Bilddienst und zu Telegram laufen über HTTPS. Bondrucker holen ihre Aufträge über HTTPS.
• Sicherheitsrichtlinien im Browser: Inhaltsrichtlinie ohne eingebettete Skripte, keine Einbettung in fremde Seiten, keine Typ-Erkennung durch den Browser, eingeschränkte Weitergabe der Herkunft, Zugriff auf Standort, Kamera und Mikrofon gesperrt.
• Die Festplatte des Servers ist nicht verschlüsselt. Die Datenbank ist nicht verschlüsselt gespeichert. Die Sicherungskopien auf dem Server sind nicht verschlüsselt und nur für root lesbar; außer Haus liegen sie nur verschlüsselt.

8. Weitergabe und Nachvollziehbarkeit

• Rückmeldungen von Stripe werden nur angenommen, wenn ihre Unterschrift (HMAC-SHA256, höchstens fünf Minuten alt) stimmt; ebenso Ereignisse von HubRise. Bondrucker und Anrufmonitore melden sich mit einem geheimen Schlüssel je Laden.
• Preise rechnet allein der Server aus den Daten der Karte; was der Browser schickt, bestimmt nur, was bestellt wird.
• Jede Änderung und Löschung einer Bestellung und ihrer Positionen hält ein Auslöser in der Datenbank mit altem und neuem Wert fest, unabhängig davon, über welchen Weg sie geschieht.
• Nachgewiesen werden außerdem: wer wem wann einen Zugangslink gegeben hat, der Wortlaut jeder Newsletter-Einwilligung mit Zeitpunkten, der Eingang jedes Widerrufs, die Zugriffe des Betreibers, jeder Vertragsschluss mit dem angenommenen Wortlaut sowie jede Referenz-Einwilligung und jeder Datenexport. Die Nachweise zu Vertrag, Referenz und Export werden nur ergänzt, nie geändert; ein Auslöser in der Datenbank weist Änderungen ab.
• Die Sicherungskopien werden mit Prüfsummen abgelegt.

9. Datensicherung und Wiederherstellung

• Jede Nacht um 02:30 Uhr: Abzug jeder Datenbank, der Datenbankrollen und der Konfiguration, mit Prüfsummen. Aufbewahrung auf dem Server 14 Tage.
• Laufende Sicherung der Datenbank: Jede Änderung wird spätestens nach fünf Minuten archiviert. Zusammen mit einer nächtlichen Grundsicherung lässt sich jeder Zeitpunkt der letzten drei Tage wiederherstellen. Archiv vier Tage, Grundsicherung drei Tage.
• Sicherung außer Haus: Jede Nacht um 03:30 Uhr gehen die Sicherungen und die Fotos auf eine Storage Box der Hetzner Online GmbH in Deutschland. Sie werden vorher auf dem Server verschlüsselt (restic); den Schlüssel hat nur der Betreiber, Hetzner sieht nur verschlüsselte Blöcke. Aufbewahrung: 14 tägliche und 11 wöchentliche Stände, also höchstens rund 90 Tage.
• Die Wiederherstellung wird monatlich automatisch geprobt, auf beiden Wegen (Abzug der Nacht; Grundsicherung mit Archiv bis zum letzten Stand) in einer abgeschotteten Instanz. Ergebnis und Rückstand werden protokolliert, ein Fehlschlag wird gemeldet. Letzte Probe vor dieser Fassung: 23.10.2026, bestanden, Rückstand 0 Minuten.
• Möglicher Datenverlust bei einem Fehler der Datenbank: höchstens etwa fünf Minuten. Fällt der ganze Server aus, gehen im schlimmsten Fall die Änderungen seit der letzten Sicherung außer Haus verloren, also bis zu rund 24 Stunden.

10. Betrieb, Überwachung und Belastbarkeit

• Eine Wache prüft alle zwei Minuten: ob der Dienst und die Datenbank antworten, ob die laufende Sicherung hakt, ob ein Zertifikat in weniger als 14 Tagen abläuft, ob die Nachtsicherung gelaufen ist, ob Platte oder Arbeitsspeicher knapp werden, ob in einem Laden eine Bestellung seit mehr als acht Minuten unbeachtet liegt und ob ein Bondrucker schweigt. Neue Befunde gehen als Nachricht an den Betreiber; sie enthalten keine Daten von Gästen.
• Stürzt der Dienst ab, startet systemd ihn nach drei Sekunden neu.
• Bremsen gegen Überlastung und Missbrauch: höchstens fünf Bestellungen je Adresse in zehn Minuten, 20 Prüfungen von Gutscheincodes, zehn Widerrufe, fünf Meldungen und zehn unbekannte Links (Newsletter, Bewertungen) je Adresse in zehn Minuten; Größengrenzen für Anfragen (Shop 64 KB, Verwaltung 2 MB).
• Grenze: Ladenbote läuft auf einem einzigen Server ohne Ausweichsystem. Fällt er aus, ist der Dienst bis zur Wiederherstellung nicht erreichbar; eine feste Wiederherstellungszeit gibt es nicht. Gäste erreichen den Laden dann telefonisch.

11. Regelmäßige Überprüfung

• Vor jeder Auslieferung laufen die automatischen Tests auf dem Server gegen die Testdatenbank, darunter die Tests der Mandantentrennung.
• Sicherheitsprüfungen des Programmcodes und der Serverkonfiguration, zuletzt am 23. und 24.10.2026; die Befunde wurden behoben oder als offene Punkte geführt.
• Die Änderungen jedes Tages am Programmcode prüft nachts ein zweites, unabhängiges Werkzeug.
• Programmbibliotheken werden bei bekannten Sicherheitslücken aktualisiert.
• Monatliche Probe der Wiederherstellung (Ziffer 9).

12. Organisation

• Zugriff auf Daten hat nur der Betreiber persönlich. Weitere Personen erhalten Zugriff erst nach schriftlicher Verpflichtung auf Vertraulichkeit und Datenschutz.
• Entwicklungswerkzeuge: Der Betreiber pflegt die Software mit Werkzeugen externer Anbieter. Verbindliche Arbeitsregel: Diese Werkzeuge verarbeiten keine personenbezogenen Daten von Gästen und Teams echter Läden; aus der Datenbank der Läden dürfen sie nur Aufbau, Zahlen und Zählungen lesen, Fehler werden in der Testdatenbank mit erfundenen Daten nachgestellt. Werkzeuge, die selbständig Programmcode ändern, laufen unter einem eigenen Systembenutzer ohne Verwaltungsrechte und ohne Zugriff auf Datenbank, Sicherungen, Schlüssel und Protokolle und arbeiten nur in Kopien des Programmcodes. Werkzeuge, die der Betreiber in seiner eigenen Sitzung nutzt, arbeiten mit seinem Verwaltungszugang; die Regel ist dort eine organisatorische Vorgabe, eine technische Sperre gegen Lesezugriffe aus diesen Sitzungen besteht nicht. Die Anbieter dieser Werkzeuge sind keine Unterauftragsverarbeiter.
• Unterauftragsverarbeiter werden nur mit Vertrag nach Art. 28 DSGVO eingesetzt und vor Aufnahme angekündigt (Liste).
• Datenschutzfreundliche Voreinstellungen: Newsletter nur mit eigenem, leerem Häkchen und Bestätigung per E-Mail; Werbelinks werden nur für den laufenden Besuch beachtet, nicht im Gerät gespeichert; keine Werbung mit Daten der Gäste durch Ladenbote.
• Verletzungen des Schutzes der Daten behandelt der Betreiber nach einem festgelegten Ablauf: erkennen, eindämmen, den Laden binnen 24 Stunden informieren, dokumentieren.
• Löschfristen sind je Datenart festgelegt und weitgehend automatisch umgesetzt.
• Daten von Gästen werden nicht per E-Mail ausgetauscht.

13. Geplant und noch nicht umgesetzt

• Geplant: Zwei-Faktor-Anmeldung für das Betreiberkonto verpflichtend; sie ist verfügbar, für das Betreiberkonto zum Stand dieser Fassung aber noch nicht eingerichtet.
• Nicht vorhanden: Verschlüsselung der Festplatte und der Sicherungskopien auf dem Server im Ruhezustand, ein Ausweichserver, eine technische Sperre für Entwicklungswerkzeuge in der Sitzung des Betreibers (siehe Ziffer 12), eine externe Sicherheitsprüfung, eine Zertifizierung.

SHA-256 dieser Fassung: d8457fbff6b29c4355ca432f55320792ee09b9da43f99b4ed08be6f44c3eb64d