Technische und organisatorische Maßnahmen

nach Art. 32 DSGVO, Anlage 1 zum Vertrag über die Auftragsverarbeitung

Stand: 16.08.2026

Dieses Dokument beschreibt, was tatsächlich eingerichtet ist. Wo eine Maßnahme noch aussteht, steht das dabei. Eine Liste, die Maßnahmen behauptet, die es nicht gibt, wäre im Ernstfall wertlos und nach Art. 5 Abs. 2 DSGVO nicht nachweisbar.

1. Vertraulichkeit

Zutrittskontrolle

Die Server stehen in einem Rechenzentrum von Hostinger in Frankfurt am Main. Zutrittskontrolle, Videoüberwachung und Besucherprotokolle liegen in der Verantwortung des Rechenzentrumsbetreibers. Eigene Hardware setzen wir nicht ein.

Zugangskontrolle

• Anmeldung ausschließlich über Kundennummer oder Fahrernummer und Passwort
• Passwörter werden mit Argon2id gehasht, nie im Klartext gespeichert
• Sperrung des Kontos nach fünf Fehlversuchen für 15 Minuten
• Sitzungen laufen nach 12 Stunden ab
• Der Berechtigungsstand wird bei jeder Anfrage neu aus der Datenbank geholt, nicht aus dem Sitzungstoken. Ein gesperrtes Konto verliert den Zugang sofort und nicht erst mit Ablauf des Tokens
• Der Serverzugang für Administration erfolgt über SSH mit Schlüsselpaar; fail2ban sperrt auffällige Adressen

Zugriffskontrolle

• Zwei Rollen: Unternehmer und Fahrer. Ein Fahrer erreicht keine Unternehmerfunktion; die Prüfung erfolgt im Backend, nicht in der Oberfläche
• Ein Fahrer sieht ausschließlich seine eigenen Daten, auch nicht die seiner Kolleginnen und Kollegen im selben Betrieb
• Jede Tabelle ausser der Mandantentabelle trägt eine Mandantenkennung als Pflichtfeld
• Jede Datenbankabfrage läuft durch eine zentrale Wache, die den Mandantenfilter erzwingt. Eine Abfrage ohne Filter wird abgewiesen und protokolliert, statt Daten zu liefern
• Der Datenbanknutzer der Anwendung hat keine Rechte an anderen Datenbanken auf demselben Server und darf keine Datenbanken anlegen

Trennungskontrolle

• Mandantentrennung wie oben beschrieben, durchgesetzt im Schema und zusätzlich zur Laufzeit
• Belegfotos liegen in getrennten Verzeichnissen je Mandant. Ein Zugriffsversuch außerhalb des eigenen Verzeichnisses wird abgewiesen
• Getrennte Datenbanken für Betrieb und Test

Pseudonymisierung und Verschlüsselung

• Zugangsdaten zu Uber und Bolt werden symmetrisch verschlüsselt gespeichert (Fernet, AES-128 mit HMAC-Signatur). Der Schlüssel liegt außerhalb der Datenbank in einer Datei mit Rechten 600
• Zugangsdaten werden nie protokolliert und nie an das Frontend gesendet
• Primärschlüssel sind zufällige UUID, keine fortlaufenden Zahlen. Daraus lässt sich weder die Kundenzahl ableiten noch ein fremder Datensatz erraten
• Ausstehend: Verschlüsselung der Übertragung mit TLS. Das Zertifikat wird eingerichtet, sobald die Domain steht. Bis dahin laufen die Dienste ausschließlich auf der lokalen Netzwerkschnittstelle und sind von aussen nicht erreichbar

2. Integrität

Eingabekontrolle

• Änderungen an Fahrzeugen, Schichten und Belegen werden in einem Protokoll festgehalten, mit Zeitpunkt, handelndem Konto und vorherigem Wert
• Das Protokoll wird nur geschrieben, nie geändert
• Anmeldevorgänge werden protokolliert

Weitergabekontrolle

• Weitergabe nur an die in Anlage 2 des AVV genannten Empfänger
• Export durch den Kunden nur über sein eigenes Konto und nur für seine eigenen Daten
• Belegfotos werden nicht als statische Dateien ausgeliefert, sondern nur über eine Schnittstelle, die vorher die Berechtigung prüft

Datenintegrität

• Eine Fahrt kann je Mandant und Plattform nur einmal existieren. Das ist im Datenbankschema erzwungen, nicht nur im Programm. Ein wiederholter Import kann damit keine doppelten Umsätze erzeugen
• Zeitliche Plausibilität wird im Schema geprüft, etwa dass ein Ende nicht vor dem Beginn liegt
• Hochgeladene Dateien werden an ihren Anfangsbytes geprüft, nicht am gemeldeten Dateityp. Dateien, die kein Bild sind, werden abgewiesen

3. Verfügbarkeit und Belastbarkeit

• Tägliche Sicherung der Datenbank um 03:30 Uhr
• Die Sicherung prüft sich selbst auf Grösse und Lesbarkeit und meldet einen Fehlschlag sofort
• Aufbewahrung der Sicherungen 30 Tage
• Die Wiederherstellung wurde erprobt und protokolliert
• Automatischer Neustart der Dienste bei Absturz
• Automatische Sicherheitsaktualisierungen des Betriebssystems
• Ausstehend: ein zweites Sicherungsziel außerhalb des Servers. Derzeit liegen die Sicherungen auf demselben Rechner. Bei einem Totalverlust der Hardware wären sie mit verloren. Vermerkt im Backlog
• Ausstehend: Überwachung der Erreichbarkeit mit Alarmierung. Vorgesehen für CP-14

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

• 113 automatische Tests laufen vor jeder Änderung. Darunter sind Tests, die ausdrücklich prüfen, dass ein Mandant keine Daten eines anderen sieht und dass ein Fahrer keine Daten eines Kollegen sieht
• Jede Änderung wird versioniert; jeder Stand ist nachvollziehbar
• Änderungen an der Datenbank laufen ausschließlich über versionierte Migrationen und sind zurückdrehbar

5. Auftragskontrolle

• Verarbeitung nur nach Weisung, siehe AV-Vertrag
• Unterauftragsverarbeiter sind in Anlage 2 des AVV benannt
• Änderungen werden 30 Tage vorher angekündigt

Was noch aussteht

Diese Punkte sind oben einzeln vermerkt und hier zusammengefasst, damit sie nicht übersehen werden:

1. TLS-Zertifikat, sobald die Domain steht 2. Zweites Sicherungsziel außerhalb des Servers 3. Überwachung der Erreichbarkeit mit Alarmierung (CP-14)

Entwurf. Anwaltlich zu prüfen.