Zum Inhalt springen
Nummerierte Schliessfächer aus Stahl in mehreren Reihen an einer Backsteinwand, davor eine Bank - niemand ist abgebildet.

Was der Sicherheitsfragebogen fragt - und welche Antworten halten

Die gefährlichste Antwort in einem Sicherheitsfragebogen ist nicht die fehlende. Es ist die zu gute.

Der Fragebogen kommt nach der Demo, wenn alle schon Ja gesagt haben. Er hat oft über hundert Zeilen, er geht an die IT-Sicherheit und an den Datenschutz, und er wird von Leuten gelesen, die jede Antwort ein zweites Mal lesen. „Alle Daten sind verschlüsselt“ klingt gut, bis jemand fragt, welche, womit und wer den Schlüssel hat. Dann zerfällt der Satz, und mit ihm das Vertrauen in alle anderen Antworten.

Dieser Beitrag geht durch, was ein solcher Fragebogen bei einer Analyseplattform für Besucherdaten wirklich fragt, und wie eine Antwort gebaut ist, die im Prüfgespräch hält. Welche Daten überhaupt ankommen, steht in Datenschutz ist eine Architekturentscheidung. Wie Daten hinaus- und hineinkommen, in Offene Schnittstellen. Hier geht es um alles dazwischen: wer was sieht, wie eine Sitzung geschützt ist, was verschlüsselt ist und was passiert, wenn ein Vertrag endet.

Drei Prüffragen für jede Antwort

Bevor es um einzelne Kontrollen geht: Es gibt drei Fragen, mit denen sich jede Antwort eines Anbieters prüfen lässt, auch unsere.

PrüffrageSchwache AntwortBelastbare Antwort
Wert oder Adjektiv?„sichere Sitzungen“30 Minuten Leerlauf, 8 Stunden absolut
Produkt oder Plattform?„verschlüsselt im Ruhezustand“welche Felder die Anwendung selbst verschlüsselt und was die Datenbankplattform darunter leistet
Formulierung, die hält?„vollständig anonym“keine identifizierenden Daten, pseudonyme sitzungsgebundene Verfolgung

Die dritte Zeile ist die unscheinbarste und die wichtigste. Ein Datenschutzbeauftragter hört den Unterschied zwischen anonym und pseudonym sofort, und er schätzt einen Anbieter, der ihn von sich aus macht. Die Herleitung steht in Datenschutz ist eine Architekturentscheidung, hier nur die Formulierung, die in den Fragebogen gehört.

Die erste Frage: Wer sieht wessen Zahlen?

In einer Plattform mit mehreren Kunden ist die teuerste Frage nicht, wer hereinkommt, sondern wessen Zahlen jemand sieht, wenn er drin ist. Eine Filialleitung soll ihre Standorte sehen - nicht die der Nachbarfiliale und niemals die eines anderen Kunden. Eine falsch gesetzte Berechtigung fällt sonst erst auf, wenn fremde Zahlen in einem Screenshot auftauchen.

Belastbar ist eine Mandantentrennung, wenn drei Dinge zutreffen:

  • Die Prüfung sitzt in der Abfrageschicht, nicht in der Oberfläche. Dann wirkt sie auf jeder Auswertung, auch auf einer, die morgen dazukommt, und auf jedem Abruf über die Schnittstelle.
  • Sie schliesst im Zweifel. Ein Benutzer ohne zugewiesenen Standort sieht nichts - nicht alles. Das Fachwort dafür ist fail-closed, und es ist die Frage, die man im Gespräch stellen sollte: Was sieht jemand, dem niemand etwas zugewiesen hat?
  • Ein Entzug wirkt sofort. Wer Rechte verliert, arbeitet nicht bis zum Ablauf seiner Sitzung weiter.

Dazu gehört ein einfaches Rollenmodell. Zwei Rollen genügen auf Kundenseite: eine Verwaltung, die den eigenen Mandanten mit allen Standorten sieht, und Standardbenutzer, die ausschliesslich die ihnen zugewiesenen Standorte sehen. Jede Zuweisung wird vor dem Speichern gegen die Standortliste des Mandanten geprüft, jede Änderung mit Vorher- und Nachher-Stand protokolliert.

Die zweite Frage: Wie ist eine Sitzung geschützt?

Hier gilt die erste Prüffrage am strengsten. Jede Zeile hat einen Wert und einen Zweck:

KontrolleWertWas sie verhindert
AnmeldungOAuth2/OIDC über einen Identity Provider, neue Sitzung bei jedem Loginuntergeschobene Sitzungen; kein eigener Passwortspeicher
Leerlauf30 Minutendie offene Sitzung am unbeaufsichtigten Filialterminal
Absolute Dauer8 Stundendie praktisch ewig gültige Sitzung
GerätebindungSitzung per HMAC an den Browser gebundenein gestohlenes Cookie auf einem anderen Gerät
WiderrufSperrmarke, bei jedem Aufruf geprüftWeiterarbeiten nach Rechteentzug
SkripteContent Security Policy mit Nonce je Aufrufeingeschleustes Skript im Dashboard
TransportHSTS mit einem Jahr, Subdomains, preloadden ersten Aufruf über unverschlüsseltes HTTP
Einbettungkeine Einbettung in fremde Seiten, kein MIME-RatenClickjacking und untergeschobene Dateitypen

Keine dieser Zeilen ist exotisch. Die Tabelle ist trotzdem der Teil, an dem die meisten Fragebögen hängen bleiben, weil ein Anbieter die Werte nicht kennt oder nur ein Adjektiv liefert.

Die dritte Frage: Was genau ist verschlüsselt?

Das ist die Stelle, an der sich die zweite Prüffrage bezahlt macht. „Verschlüsselt im Ruhezustand“ ist bei jeder Cloud-Datenbank eine Eigenschaft der Plattform, nicht der Anwendung. Das ist gut und richtig, aber es ist eine Anbieterkontrolle - und eine gute Antwort benennt sie als solche.

Was die Anwendung selbst verschlüsseln sollte, sind die Dinge, mit denen jemand Schaden anrichten könnte, der Lesezugriff auf die Datenbank bekommt: Kontaktdaten von Empfängern, Adressen für Chat-Kanäle, Zugangsdaten zu Sensoren, Signaturgeheimnisse für Ereignisse. Dafür ist AES-256-GCM der Standard, mit einer Schlüsselableitung und einem Prüfwert, der jede Veränderung auffallen lässt.

Die Zähldaten selbst sind ein anderer Fall. Sie bestehen aus ganzen Zahlen je Standort und Minute, aus denen sich kein Mensch rekonstruieren lässt. Ihr Schutz liegt in der Struktur, nicht im Schlüssel.

Eine Antwort, die diese drei Ebenen auseinanderhält, ist länger als „alles verschlüsselt“. Sie ist dafür die einzige, die eine Prüfung übersteht.

Die vierte Frage: Was steht in den Protokollen?

Protokolle sind der Ort, an dem Personendaten landen, ohne dass es jemand beschlossen hat. Eine Fehlermeldung schreibt eine E-Mail-Adresse mit, ein Debug-Eintrag einen Token, ein Zustellfehler eine vollständige URL mit Zugangsdaten. Die belastbare Antwort ist deshalb keine Richtlinie, sondern ein Mechanismus:

  • Redaktion in jedem Eintrag, nach Feldnamen - Passwort, Token, Authorization, Cookie, E-Mail, IP-Adresse - und zusätzlich nach Muster: E-Mail-Adressen und Telefonnummern maskiert, Bearer-Tokens und JWTs entfernt.
  • Fehler ohne Innenansicht. In Produktion keine Stacktraces, Datenbankfehler auf wenige allgemeine Meldungen abgebildet. Wer eine Fehlermeldung sieht, lernt nichts über den Aufbau dahinter.
  • Ausgehende Aufrufe gehärtet. Ein Ziel, das ein Kunde hinterlegt, wird bei der Registrierung, bei jeder Änderung und bei der Zustellung erneut geprüft - mit Namensauflösung und Normalisierung aller Schreibweisen einer IP-Adresse, damit kein internes Ziel über eine ungewöhnliche Notation durchrutscht. Weiterleitungen werden nicht verfolgt. Das Fachwort ist SSRF-Härtung; was sie bei Alarmen bedeutet, steht in Von der Zahl zur Handlung.

Die fünfte Frage: Wer hat was geändert?

Ein Audit-Log beantwortet die Frage, die nach jedem Vorfall zuerst kommt. Brauchbar ist es, wenn es breit genug ist und sich nicht still verliert:

  • Breite: Anmeldung und Sitzungssicherheit, abgelehnte Zugriffe, Benutzer-, Mandanten- und Standortverwaltung, Schlüssel, Ereignisziele, Alarme, Export, Löschung und Zugriff auf Daten, Kalender, Konfiguration, Sensoren.
  • Kein stiller Verlust: Einträge werden gesammelt geschrieben, jede Sekunde oder alle 50 Einträge, mit einer Leerung beim Herunterfahren. Ein Absturz verliert den Eintrag nicht unbemerkt.
  • Datenschutz im Protokoll selbst: Die Metadaten werden beim Schreiben bereinigt, die IP-Adresse beim Schreiben pseudonymisiert.
  • Zugang für den Kunden: Das eigene Audit-Log lässt sich über die Schnittstelle mit einem Leseschlüssel abrufen - der Weg ist in Offene Schnittstellen beschrieben.

Die sechste Frage: Wie lange bleibt was?

Die Fristen für die Zähl- und Verhaltensdaten stehen in Datenschutz ist eine Architekturentscheidung. Ein Fragebogen fragt aber auch nach allem, was der Betrieb erzeugt:

DatenbestandFrist
Alarm- und Berichtshistorie395 Tage
Abweichungsprotokoll13 Monate
Protokolle von Anzeigen und Warteschlangen-Ereignissen30 Tage
Anmeldeprotokollegestaffelt, IP-Adresse nach einem Jahr pseudonymisiert
Audit-Log7 Jahre, danach Akteur und IP-Adresse unumkehrbar pseudonymisiert

Durchgesetzt werden die Fristen von einem täglichen Lauf mit rund 35 Regeln. Eine Regel, die auf einen nicht vorhandenen Datenbestand zeigt, meldet sich als fehlkonfiguriert - nicht als eingehalten. Das ist dieselbe Haltung wie überall in diesem Beitrag: Ein Prüfer, der nichts gefunden hat, weil er nicht lief, darf nicht aussehen wie einer, der nichts zu finden hatte.

Die siebte Frage: Was passiert, wenn ein Vertrag endet?

Diese Frage wird oft vergessen und im Ernstfall am meisten bereut. Ein sauberer Ablauf hat vier Schritte:

  1. Tag 0, Sperre: Anmeldung gesperrt, Alarme, Berichte, Ereignisse und Schnittstelle abgeschaltet. Die Datenannahme läuft weiter, damit eine Rücknahme keine Lücke hinterlässt.
  2. 30 Tage umkehrbar: In diesem Fenster ist die Rücknahme ein Schalter. Niemand verliert seine Historie wegen eines Missverständnisses bei der Vertragsverlängerung.
  3. Löschkaskade: Danach entfernt ein geplanter Lauf die Datenbestände des Mandanten und seiner Standorte sowie die Konten beim Identity Provider, in Abschnitten, die sich nach einer Unterbrechung fortsetzen lassen.
  4. Probelauf als Voreinstellung: Der unwiderrufliche Lauf ist standardmässig ein Probelauf hinter einem Notschalter. Scharf wird er nur bewusst - nicht durch einen Konfigurationsfehler um drei Uhr nachts.

Auskunft und Löschung für Betroffene nach Art. 15 und Art. 17 DSGVO laufen über eine mandantengebundene Schnittstelle mit Register, Export, Löschung und Probelauf.

Was der Sensor mitbringt

Ein Teil des Fragebogens betrifft das Gerät an der Decke, nicht die Software. Die Siegel und Zertifikate der Sensorreihen gehören dem Hersteller, und so sollten sie auch in der Antwort stehen - als Eigenschaft der Hardware, nicht als Aussage über die Plattform. Was sie im Einzelnen bedeuten, steht in Datenschutz ist eine Architekturentscheidung. Eine Antwort, die beides trennt, ist genauer und damit glaubwürdiger.

Was in die Ausschreibung gehört

  1. Wo sitzt die Mandanten- und Standortprüfung - in der Oberfläche oder in der Abfrageschicht?
  2. Was sieht ein Benutzer, dem kein Standort zugewiesen ist?
  3. Wirkt ein Rechteentzug sofort oder erst nach Ablauf der Sitzung?
  4. Welche Werte gelten für Leerlauf, absolute Sitzungsdauer, CSP und HSTS?
  5. Welche Felder verschlüsselt die Anwendung selbst, und was leistet die Plattform darunter?
  6. Wie werden Personendaten aus Protokollen und Fehlermeldungen herausgehalten?
  7. Welche Aktionen stehen im Audit-Log, und wie kommt der Kunde daran?
  8. Welche Fristen gelten für Betriebsdaten, und wie werden sie durchgesetzt?
  9. Was passiert in den 30 Tagen nach Vertragsende, und wie wird die endgültige Löschung ausgelöst?

Wie wir das machen

Das ANALYSIT Counting System trennt Mandanten in der Abfrageschicht und schliesst im Zweifel: Eine leere Standortzuweisung bedeutet keinen Zugriff. Standortzuweisungen werden vor dem Schreiben gegen die Standortliste des Mandanten validiert, Rollen- und Zuweisungsänderungen mit Vorher- und Nachher-Stand auditiert, und jede Reduktion von Rechten invalidiert die laufenden Sitzungen sofort.

Die Anmeldung läuft über Auth0 mit OAuth2/OIDC und Session-Regeneration. Sitzungen im Browser enden nach 30 Minuten Leerlauf und spätestens nach 8 Stunden, sind per HMAC an den User Agent gebunden und werden über eine Sperrmarke serverseitig widerrufen. Dazu kommen eine Content Security Policy mit Nonce je Request, HSTS mit preload, X-Frame-Options DENY und nosniff.

Geheimnisse und Kontaktdaten werden mit AES-256-GCM verschlüsselt, jeder Protokolleintrag läuft durch eine PII-Redaktion, Fehler erscheinen ohne Stacktrace, und ausgehende Aufrufe sind gegen SSRF gehärtet. Das Audit-Log ist append-only ausgelegt, über 60 Aktionstypen breit und für den eigenen Mandanten über die REST-Schnittstelle abrufbar. Rund 35 Aufbewahrungsregeln laufen täglich, und ein Mandant, der geht, bleibt 30 Tage umkehrbar, bevor die Löschkaskade, standardmässig ein Probelauf, scharf gestellt wird.

Wenn bei dir ein Sicherheitsfragebogen ansteht, sprich mit uns. Wir beantworten ihn mit Werten, nicht mit Adjektiven.