betriebsdesk
Testen

Sicherheit

Technische und organisatorische Maßnahmen (TOM)

Stand: 11.08.2026 · Anlage 1 zum AVV

Diese Anlage beschreibt die konkret eingesetzten oder verbindlich vorgesehenen Maßnahmen zum Schutz der über betriebsdesk verarbeiteten personenbezogenen Daten. Maßnahmen werden risikoorientiert angewendet; die genannten Grenzen zu Backup und Audit sind Bestandteil der Beschreibung.

1. Identitäts- und Zugangskontrolle

  • Personenbezogene Nutzerkonten; gemeinsame Konten sind vertraglich untersagt.
  • Passwörter müssen mindestens 12 Zeichen sowie Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen enthalten.
  • Passwörter werden durch Supabase Auth als nicht rückrechenbare Passwort-Hashes gespeichert; Klartextpasswörter werden nicht persistiert.
  • Die geschäftliche E-Mail-Adresse des Hauptkontos muss bestätigt werden; Teamkonten ohne eigene E-Mail werden ausschließlich durch berechtigte Rollen angelegt und erhalten eine interne technische Authentifizierungsadresse.
  • TOTP-MFA kann pro Konto aktiviert werden; nach Aktivierung erzwingen Datenbank, Storage und sicherheitskritische Funktionen eine AAL2-Sitzung.
  • Passwortänderung, Kontolöschung, Nutzerverwaltung und Abrechnung verlangen eine aktuelle Authentifizierung; bei aktivierter MFA zusätzlich den zweiten Faktor.
  • Sitzungen laufen ab beziehungsweise werden bei Abmeldung beendet; entzogenes Konto erhält keinen weiteren fachlichen Zugriff.

2. Berechtigungs- und Rollenkontrolle

  • Rollen Inhaber, Schichtleiter und Mitarbeiter begrenzen Funktionen und sichtbare Daten.
  • Inhaber verwalten Nutzer, Rollen, Standorte, Abteilungen und seitenbezogene Sichtbarkeiten.
  • Nicht mehr benötigte Konten können deaktiviert oder entfernt werden.
  • Supportzugriffe setzen eine dokumentierte Zuordnung zum betroffenen Betrieb oder eine ausdrücklich administrative Rolle voraus.
  • Sicherheitskritische Datenbankfunktionen prüfen Rolle, Betrieb und aktuelle Sitzung zusätzlich serverseitig.
  • Berechtigungen werden bei jeder Datenbankabfrage durch Row Level Security oder gesicherte Serverfunktionen geprüft.

3. Übertragung und Geheimnisschutz

  • Öffentliche Produktivzugriffe erfolgen über HTTPS/TLS; HSTS erzwingt verschlüsselte Folgeverbindungen.
  • Sicherheitsheader begrenzen Einbettung, MIME-Sniffing und unerwünschte Referrer-Übertragung.
  • API-Schlüssel mit erhöhten Rechten, Stripe-Schlüssel und sonstige Geheimnisse werden serverseitig als Umgebungs- beziehungsweise Plattform-Secrets verwaltet und nicht an Browser ausgeliefert.
  • Private Übergabefotos werden nicht über dauerhafte öffentliche URLs freigegeben, sondern über kurzlebige signierte Links.
  • Supabase verschlüsselt gespeicherte Daten und Sicherungen mit den dokumentierten plattformseitigen Verfahren; eine kundenseitige Ende-zu-Ende-Verschlüsselung besteht nicht.

4. Mandantentrennung und Eingabekontrolle

  • Fachliche Datensätze sind über eine Betriebs-ID einem Mandanten zugeordnet.
  • Row Level Security beschränkt Lesen und Schreiben auf den aktuellen Betrieb, zugewiesenen Support oder ausdrücklich administrative Konten.
  • Untergeordnete Auftrags-, Material- und Laufkartendaten werden über serverseitig geprüfte Beziehungen dem Betrieb zugeordnet.
  • Storage-Pfade beginnen mit der Betriebs-ID; Upload und Download werden gegen diese Zuordnung geprüft.
  • Ausgewählte sicherheits-, rollen-, konto- und abrechnungsrelevante Vorgänge werden mit Zeitstempel und Akteur protokolliert.
  • Das Audit-Log ist ausdrücklich keine vollständige Versionshistorie aller fachlichen Inhalte.

5. Verfügbarkeit und Sicherungen

  • Primäre relationale Daten werden in der Supabase-Projektregion Central EU (Frankfurt) gespeichert.
  • Umfang und Aufbewahrungsdauer automatischer Datenbanksicherungen richten sich nach dem für die Produktionsumgebung eingesetzten Supabase-Tarif.
  • Sicherungen werden ausschließlich zur Wiederherstellung bei Betriebs- oder Datenfehlern verwendet; Zugriff ist auf administrativ erforderliche Personen und den Plattformanbieter beschränkt.
  • Wiederherstellungen werden nach wesentlichen Infrastrukturänderungen und ansonsten mindestens jährlich anhand eines dokumentierten Verfahrens geprüft.
  • Automatische Datenbanksicherungen und der Objektspeicher für private Übergabefotos sind technisch getrennt. Vorhandene Übergabefotos können über den Kundenexport abgerufen werden.
  • Verbindliche RPO-, RTO- oder Verfügbarkeitswerte bestehen nur in einem individuell einbezogenen SLA.

6. Protokollierung und Erkennung

  • Login-, Funktions-, Fehler- und Infrastrukturereignisse werden nach Erforderlichkeit durch Supabase, Hetzner und die Anwendung protokolliert.
  • ALTCHA-, Honeypot- und Rate-Limit-Ereignisse speichern nur einen gesalzenen IP-Hash statt der Klartext-IP in der Ereignistabelle.
  • Allgemeine technische Protokolle werden grundsätzlich höchstens 30 Tage, Bot-Sicherheitsereignisse grundsätzlich 90 Tage gespeichert.
  • Bei einem konkreten Vorfall dürfen erforderliche Auszüge bis zur Aufklärung, regelmäßig höchstens 180 Tage, länger gesichert werden, wenn Rechtsverfolgung oder Gesetz dies verlangt.
  • Protokolle werden nicht für Mitarbeiter-Rankings oder Werbeprofile verwendet.

7. Schutz vor Missbrauch und Angriffen

  • Authentifizierungsendpunkte sind durch Cloudflare Turnstile, serverseitige Prüfung und Rate Limits geschützt.
  • Öffentliche Nicht-Auth-Formulare verwenden selbst gehostete ALTCHA-Challenges, Honeypots und serverseitige Wiederverwendungssperren.
  • Datenbanktabellen und Storage-Buckets verweigern standardmäßig nicht ausdrücklich autorisierte Zugriffe.
  • Öffentliche Schreibwege laufen über geprüfte Serverfunktionen mit Feld-, Größen- und Berechtigungsvalidierung.
  • Sicherheitsvorfälle werden bewertet, eingedämmt, dokumentiert und nach dem AVV an betroffene Kunden gemeldet.

8. Entwicklung, Änderungen und Schwachstellen

  • Quellcode und Datenbankschema werden versioniert; Datenbankänderungen erfolgen über nachvollziehbare Migrationen.
  • Sicherheitsrelevante Änderungen werden vor Bereitstellung durch Build, statische Prüfungen und anwendbare Regressionstests kontrolliert.
  • Abhängigkeiten werden regelmäßig auf verfügbare Sicherheits- und Wartungsupdates geprüft.
  • Geheimnisse werden nicht im Quellcode abgelegt; bekannt gewordene kompromittierte Werte werden widerrufen und ersetzt.
  • Festgestellte Schwachstellen werden nach Auswirkung priorisiert, behoben und nachgetestet.

9. Datenschutzfreundliche Gestaltung

  • Ohne aktive Buchung entsteht keine automatische Zahlungspflicht.
  • Rollen beschränken die standardmäßig sichtbaren Funktionen und Daten.
  • Mitarbeiterdaten werden nicht für Werbung oder eigene KI-Trainingszwecke verwendet.
  • Diagnosen und medizinische Details sind für die Abwesenheitsfunktion nicht erforderlich und werden vertraglich untersagt.
  • Geschäftsdaten können in einem strukturierten JSON-Format exportiert werden; Fotos erhalten geschützte Downloadmöglichkeiten.
  • Löschung und Rückgabe richten sich nach Kundenweisung, AVV und den Data-Act-Abruffristen.

10. Organisation, Löschung und Kontrolle

  • Personen mit administrativem Zugriff werden auf Vertraulichkeit und zweckgebundene Verarbeitung verpflichtet.
  • Zugriff wird nur für Betrieb, Sicherheit oder konkrete Supportbearbeitung erteilt.
  • Produktive Daten werden nach Weisung gelöscht; private Fotoobjekte werden bei vollständiger Kontolöschung serverseitig entfernt.
  • Datenbanksicherungen laufen spätestens nach 30 Tagen aus und dürfen gelöschte Daten nicht erneut in den Produktivbetrieb einspielen.
  • Direkte Unterauftragnehmer, Verarbeitungszweck und Region werden im AVV dokumentiert und Änderungen mindestens 30 Tage vorher angekündigt.
  • Die TOM werden mindestens jährlich sowie nach wesentlichen Architektur- oder Risikoveränderungen überprüft.
AVV ansehen Trust Center