← Zurück zur Anmeldung

Technische und organisatorische Maßnahmen

Fassung 2 · Stand 2026-09-16

Anlage zum Vertrag: wie die Daten technisch gesichert sind. Nach Art. 32 DSGVO.

Technische und organisatorische Maßnahmen

Anlage 1 zum Vertrag über die Auftragsverarbeitung Stand 17.09.2026 · Entwurf: vor der Verwendung anwaltlich prüfen lassen

Diese Anlage beschreibt die Maßnahmen nach Art. 32 DSGVO, mit denen Snackpot die Daten der digitalen Speisekarte schützt.

Grundsatz dieses Dokuments: Hier steht nur, was tatsächlich
umgesetzt ist. Wo eine Maßnahme eine Grenze hat, die für dich als
Auftraggeber erheblich ist, steht die Grenze dabei.

1. Vertraulichkeit

1.1 Zugang zum Server

  • Der Anwendungsdienst läuft unter einem eigenen Systembenutzer ohne

Passwort und ohne sudo-Rechte, mit den systemd-Härtungen NoNewPrivileges, PrivateTmp, ProtectSystem=strict und ProtectHome.

  • Der Dienst lauscht nur auf der lokalen Schleife (127.0.0.1). Von

außen erreichbar ist ausschließlich der vorgelagerte Webserver.

  • Administrativer Zugang zum Server erfolgt über **SSH mit

Schlüsselpaar**; die Passwortanmeldung ist abgeschaltet.

1.2 Zugang zu einem Konto

  • Passwörter werden mit bcrypt und einem je Passwort zufälligen Salz

gespeichert. Klartextpasswörter werden nirgends abgelegt.

  • Legen wir ein Konto an oder setzen ein Passwort zurück, geht ein

vorläufiges Passwort einmalig per E-Mail an den Betrieb. Ein Wechsel danach wird empfohlen, aber nicht erzwungen.

  • Mindestlänge Passwort: 8 Zeichen, an allen Setzwegen geprüft.
  • Anmeldebremse: Nach 8 Fehlversuchen wird der Zugang für 15 Minuten

gesperrt. Das gilt für die Anmeldung, die Registrierung und das Zurücksetzen von Passwörtern.

  • Grenze: Der Zähler liegt im Arbeitsspeicher und beginnt nach einem

Neustart des Dienstes von vorn.

  • Nicht umgesetzt: Zwei-Faktor-Authentifizierung.

1.3 Sitzungen

  • Anmeldungen laufen über signierte Sitzungsmarken (JWT).
  • Laufzeit: 7 Tage, 30 Tage bei „angemeldet bleiben".
  • Ein Passwortwechsel entwertet alle älteren Sitzungen dieses Kontos.
  • Sitzungs-Cookies sind HttpOnly, SameSite=Lax und im Betrieb über

HTTPS Secure.

  • Grenze: Abmelden löscht das Cookie, entwertet die Marke aber nicht

serverseitig. Eine abgegriffene Marke bleibt bis zum Ablauf gültig, sofern nicht das Passwort gewechselt wird.

1.4 Trennung der Betriebe

  • Jede Portalroute läuft durch eine einzige Prüfstelle, die den

aufgerufenen Laden gegen das angemeldete Konto abgleicht.

  • Auf einen fremden Laden antwortet das System mit 404 statt 403.
  • Untergeordnete Daten (Gerichte, Kategorien, Karten, Anliegen) werden

zusätzlich gegen den Laden geprüft.

  • Die Daten aller Betriebe liegen in einer gemeinsamen Datenbank und

sind durch die Ladenzuordnung jeder Zeile getrennt. Eine physische Trennung je Kunde besteht nicht.

  • Zu benennen: Es existiert eine **Plattform-Administratorrolle mit

Zugriff auf alle Betriebe**. Sie wird von den beiden Betreibern von Snackpot ausgeübt und ist für Betrieb und Unterstützung erforderlich.

  • Nicht umgesetzt: Protokollierung administrativer Zugriffe auf die

Daten eines Betriebs.

1.5 Daten der Gäste

  • Gäste brauchen kein Konto; Namen oder Kontaktdaten werden nicht

erhoben.

  • Auf der Speisekarte werden keine Cookies gesetzt und keine

Analyse-, Werbe- oder Trackingdienste eingebunden.

  • Besucher werden über einen täglich wechselnden Abdruck gezählt

(IP-Adresse, Browserkennung, Datum und ein geheimer Serverschlüssel, gehasht). Ohne diesen Schlüssel ist er nicht rückrechenbar, er ergibt am nächsten Tag für dasselbe Gerät einen anderen Wert und wird in der folgenden Nacht gelöscht, vor der nächtlichen Sicherung. Gespeichert bleiben nur Anzahlen je Tag und Stunde.

  • Grenze: Der geheime Schlüssel liegt auf demselben Server. Wer ihn

hat, könnte einen Abdruck für einen Tag durch Ausprobieren zuordnen.

  • Echte Speisekarten laden Schriften, Skripte und Bilder vom eigenen

Server. Die Vorführkarten nutzen Beispielbilder eines externen Bilddienstes. Kartenausschnitte für Standortkarten holt der Server selbst, damit die IP-Adresse des Besuchers den Kartendienst nicht erreicht.

  • Grenze: Eine eigens gestaltete Seite, die ein Betrieb statt der

Speisekarte nutzt, läuft abgeschottet, darf aber Inhalte von fremden Servern nachladen (etwa Schriften). Solche Seiten laden nur die Betreiber von Snackpot hoch.

2. Integrität

2.1 Eingabekontrolle

  • Alle Ausgaben in Web-Seiten werden grundsätzlich escaped. Freies

HTML kann über Eingaben nicht ins System.

  • Datenbankzugriffe laufen über einen ORM mit gebundenen Parametern; SQL

wird nirgends aus Eingaben zusammengesetzt.

  • Formulare sind durch SameSite=Lax und form-action 'self' gegen

Absenden von fremden Seiten geschützt.

  • Bilder der Speisekarte werden neu kodiert, nicht übernommen. Damit

fallen eingebettete Metadaten (auch GPS-Koordinaten) weg. Druckvorlagen, die wir selbst hochladen, werden unverändert abgelegt.

  • Dateinamen werden serverseitig gebildet.

2.2 Übertragungskontrolle

  • Die Auslieferung erfolgt ausschließlich über HTTPS; Zertifikate

werden automatisch erneuert, unverschlüsselte Aufrufe umgeleitet.

  • Schutz-Kopfzeilen: Strict-Transport-Security,

Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin.

  • Skripte im Portal und auf der Website laufen nur mit einer je Aufruf

neu erzeugten Kennung (Nonce).

  • Grenze: Die Speisekarte selbst erlaubt eingebettete Skripte, weil

ihre Vorlagen darauf aufbauen; Daten werden dort vor dem Einsetzen maskiert. Nachladen von fremden Servern verhindert die Richtlinie weiterhin.

  • Der Mailversand erfolgt verschlüsselt (STARTTLS) mit Prüfung des

Serverzertifikats.

2.3 Protokollierung

  • Der Webserver schreibt Zugriffe (IP-Adresse, Zeitpunkt,

Anfragemethode, Adresse ohne Anfrageteil, Statuscode, übertragene Datenmenge, verweisende Seite ohne Anfrageteil, Browserkennung) in ein Protokoll, das nach 14 Tagen gelöscht wird. Abrufe statischer Dateien werden nicht protokolliert.

  • Die Anwendung schreibt Anfragen ohne IP-Adresse und Fehler in das

Systemprotokoll des Servers.

  • Geheimnisse in Adressen werden vor dem Schreiben geschwärzt, etwa

die Marke aus einer Passwort-vergessen-Mail; die Seite zum Setzen eines neuen Passworts gibt ihre Adresse nicht als verweisende Seite weiter.

3. Verfügbarkeit und Belastbarkeit

  • Die Datenbank läuft im WAL-Modus; Sicherungen werden über die

Online-Backup-Schnittstelle von SQLite erstellt und sind auch im laufenden Betrieb in sich stimmig.

  • Der Dienst wird von systemd überwacht und nach einem Absturz neu

gestartet.

  • Nächtlich entsteht eine vollständige Sicherung. Stände älter als

14 Tage werden automatisch entfernt, die jüngsten drei bleiben in jedem Fall. Kopien, die unmittelbar vor dem Löschen von Daten entstehen, werden nach 90 Tagen entfernt.

  • Vor jedem Aufspielen einer neuen Fassung wird eine Sicherung erstellt

und danach geprüft, ob alle Speisekarten erreichbar sind.

  • Grenze, ausdrücklich: Die Sicherungen liegen **unverschlüsselt auf

demselben Server** wie die Datenbank und werden von Hand an einen zweiten Ort kopiert. Ein Wiederanlaufplan mit zugesagten Zeiten besteht nicht.

4. Verschlüsselung

  • Bei der Übertragung: durchgehend TLS (siehe 2.2).
  • Im Ruhezustand: Passwörter sind mit bcrypt gehasht, Marken zum

Zurücksetzen von Passwörtern nur als SHA-256-Abdruck gespeichert.

  • Ausdrücklich nicht: Die übrigen Inhalte der Datenbank liegen

unverschlüsselt in der Datenbankdatei. Geschützt sind sie durch die Zugriffsrechte des Betriebssystems und die Abschottung des Dienstes.

5. Weitergabe und Empfänger

Empfänger Wofür
Hetzner Online GmbH, Deutschland Server und E-Mail-Versand (Unterauftragsverarbeiter)
  • Daten der Gäste erreichen den Betrieb als Anzahlen (Portal und

wöchentlicher Bericht) und als Rückmeldungen einschließlich freiwilliger Kommentare in seinem Portal. Die Plattformverwaltung sieht Rückmeldungen ebenfalls.

  • Die Adresse des Ladens wird einmalig an den Dienst Nominatim der

OpenStreetMap Foundation gesendet, um sie in Kartenkoordinaten umzurechnen. Daten der Gäste sind daran nicht beteiligt.

  • **Es findet keine Übermittlung von Daten der Gäste in Drittländer

statt.**

6. Löschung

  • Wird ein Betrieb gelöscht, verschwinden die zugehörigen Daten

(Speisekarte, Bilder, Auswertungen, Rückmeldungen) aus der Datenbank.

  • Geräteabdrücke zur Besucherzählung werden jede Nacht gelöscht,

Server-Protokolle nach 14 Tagen.

  • Eine automatische Löschung der Daten eines Betriebs nach Vertragsende

ist nicht eingerichtet; sie geschieht auf Weisung im Adminbereich.

  • Sicherungskopien laufen nach den Fristen aus Abschnitt 3 aus.

7. Organisation

  • Der Kreis der Personen mit Zugriff auf Produktivdaten ist auf die

Geschäftsführung von Snackpot begrenzt.

  • Änderungen an der Software werden versioniert und sind einer Person

und einem Zeitpunkt zugeordnet.

  • Änderungen werden vor der Auslieferung automatisiert getestet; der

Auslieferungsweg sichert vorher die Datenbank und prüft danach, ob alle Speisekarten erreichbar sind.

  • Ein Verfahren für den Umgang mit Datenschutzverletzungen einschließlich

der unverzüglichen Meldung an dich als Verantwortlichen ist festgelegt.

8. Was wir als Nächstes verbessern

  1. Sicherungen verschlüsselt und automatisch an einem zweiten Ort.
  2. Ein Prüfprotokoll für administrative Zugriffe.
  3. Serverseitiger Widerruf einzelner Sitzungen.

Änderungen dieser Anlage teilen wir dir mindestens vier Wochen im Voraus mit. Verschlechtern sie das Schutzniveau, kannst du widersprechen.

← Zurück · Impressum · Datenschutz