Technische und organisatorische
Maßnahmen

2.1 Anmeldung. Die Identitätsprüfung erfolgt über einen dedizierten Anmeldedienst (Firebase Authentication). Jede Anwendung prüft das Anmelde-Token kryptografisch gegen die öffentlichen Schlüssel des Anbieters; ein Token, das diese Prüfung nicht besteht, erreicht keine Fachlogik.

2.2 Sitzungen. Sitzungen laufen über ein Cookie, das für Skripte im Browser nicht lesbar ist, nur über TLS übertragen wird und auf die eigene Domäne beschränkt ist. Die Umgebungen tragen getrennte Cookie-Namen, damit eine Sitzung nicht versehentlich in eine andere Umgebung trägt.

2.3 Missbrauchsschutz. Anmeldeversuche und Zugriffe auf portalartige Endpunkte sind mengenmäßig begrenzt. Von portalartigen Zugängen wird ein Zeitstempel und eine gekürzte Form der IP-Adresse zur Missbrauchserkennung gespeichert, nicht die vollständige.

2.4 Verwaltungszugänge. Der Zugang zur Cloud-Umgebung ist auf einen kleinen, namentlich bekannten Personenkreis beschränkt und mit Zwei-Faktor-Authentisierung des Anbieters abgesichert. Der laufende Betrieb verwendet Dienstkonten mit eng geschnittenen Rechten, keine persönlichen Zugänge.

3.1 Rechte je Funktion und Vorgang. Jede nicht-öffentliche Schnittstelle trägt ein Recht aus einem festen Rechtekatalog der jeweiligen Anwendung (Funktion × Lesen/Anlegen/Ändern/Löschen). Das ist maschinell erzwungen: eine Schnittstelle ohne Recht oder ohne begründete, namentlich eingetragene Ausnahme lässt sich nicht ausliefern — das Bau-Tor bricht ab.

3.2 Mandantentrennung in der Datenbank selbst. Die Trennung der Kunden hängt nicht an der Sorgfalt beim Programmieren, sondern an der Datenbank: Für die datentragenden Tabellen gelten Zeilen-Sicherheitsregeln (Row Level Security), und zwar in der erzwungenen Form, die auch für den Eigentümer der Tabelle gilt. Eine Abfrage ohne gesetzten Mandantenkontext liefert nichts.

Zusätzlich prüfen zwei Wächter im Bau-Tor, dass eine geschützte Tabelle nicht am Mandantenkontext vorbei angesprochen wird — auch dann nicht, wenn der Zugang über mehrere Ebenen als Argument weitergereicht wird.

3.3 Besondere Kategorien. Personal- und Lohndaten hängen an gesonderten Rechten; wer allgemeine Rechte in der Anwendung hält, sieht sie dadurch nicht. Jeder Abruf durch eine andere Person wird protokolliert — mit Zeitpunkt, handelnder Person und betroffenem Datensatz. Der Blick in die eigenen Daten erzeugt bewusst keinen Protokolleintrag.

3.4 Trennung der Umgebungen. Entwicklung, Abnahme und Produktion verwenden getrennte Datenbanken mit getrennten Zugangsdaten. Betriebs-Skripte, die Daten löschen, prüfen ihr Ziel vorher gegen ein zentrales Umgebungsregister und verweigern den Lauf, wenn es nicht passt.

4.1 Eingaben werden geprüft, nicht vertraut. Jede Außengrenze — Schnittstelle wie Server-Aktion — validiert ihre Eingaben gegen ein Schema. Bezeichner, die in Datenbankabfragen einfließen, werden gegen feste Listen zulässiger Werte geprüft, nie aus der Eingabe übernommen.

4.2 Inhalte aus Daten. Vom Kunden eingebrachte Inhalte, die als HTML dargestellt werden, laufen durch einen einzigen Filter mit einer Liste erlaubter Elemente. Werte, die in Gestaltungsangaben einfließen, werden gegen ein festes Format geprüft.

4.3 Ausgehende Abrufe. Abrufe fremder Adressen durch den Server sind nur über eine geprüfte Zwischenschicht möglich, die Adressen im internen Netz abweist.

4.4 Nachvollziehbarkeit. Änderungen an Verträgen, Nachweisen und freigegebenen Rechtstexten sind unveränderlich: Eine freigegebene Fassung lässt sich nicht mehr im Wortlaut ändern — die Datenbank weist es ab. Wer etwas ändern will, legt eine neue Fassung an.

5.1 Sicherungen. Die Datenbank wird täglich automatisch gesichert; es werden sieben Generationen vorgehalten, abgelegt in der Europäischen Union.

5.2 Punktgenaue Wiederherstellung. Über die Transaktionsprotokolle ist eine Wiederherstellung auf einen beliebigen Zeitpunkt innerhalb der letzten sieben Tage möglich — auch auf einen Zeitpunkt zwischen zwei Sicherungen.

5.3 Betriebsüberwachung. Fehler laufen in die zentrale Protokollierung des Anbieters. Ein regelmäßiger, gruppierter Rundgang über die Fehlermeldungen ist Teil des Betriebs; gruppiert deshalb, weil ein einzelner Dauerfehler sonst alle anderen aus dem Blickfeld verdrängt. Das Verfahren bei einem Sicherheitsvorfall ist gesondert festgelegt (Art. 33/34).

5.4 Skalierung. Die Anwendungen laufen als verwaltete Dienste und werden bei Last automatisch vervielfacht.

Grenze, ausdrücklich benannt: Die Datenbank läuft in einer Verfügbarkeitszone. Der Ausfall dieser Zone führt zu einer Unterbrechung, bis der Anbieter sie behebt oder aus der Sicherung wiederhergestellt wird — nicht zu einem Datenverlust, da Sicherungen und Protokolle regionsübergreifend liegen. Eine zonenübergreifende Hochverfügbarkeit ist nicht eingerichtet.

5.5 Aufbewahrung der Protokolle. Betriebsprotokolle werden nach 30 Tagen gelöscht. Die Frist ist technisch erzwungen — sie ist die Aufbewahrungseinstellung des Protokoll-Speichers beim Anbieter, kein Aufräum-Skript, das ausfallen könnte. Eine Ausnahme betrifft ausschließlich Beschäftigte des Auftragsverarbeiters: Protokolle über Verwaltungshandlungen in der Cloud-Umgebung liegen in einem vom Anbieter vorgegebenen Speicher mit 400 Tagen; diese Frist lässt sich nicht verkürzen.

6.1 Maschinelle Prüfungen vor jeder Auslieferung. Vor jeder Auslieferung laufen Typprüfung, automatisierte Tests und eine Reihe von Wächtern, die die oben beschriebenen Maßnahmen erzwingen — unter anderem: kein Zugriff an der Mandantentrennung vorbei, kein Endpunkt ohne Recht, keine Eingabe ungeprüft in eine Datenbankabfrage, kein ausgehender Abruf ohne Prüfung, kein HTML aus Daten am zentralen Filter vorbei, keine Zugangsdaten im Quelltext, keine abgeschaltete Sicherung ohne namentlich eingetragene Begründung. Schlägt einer an, findet keine Auslieferung statt.

Das ist der entscheidende Unterschied zu einer Checkliste: Die Maßnahmen sind nicht dokumentiert und werden gelegentlich geprüft — sie sind Voraussetzung dafür, dass Software überhaupt ausgeliefert werden kann.

6.2 Abgleich der Datenbankstände. Die Schemata der Umgebungen werden gegeneinander abgeglichen, damit eine Schutzmaßnahme nicht in einer Umgebung besteht und in der anderen fehlt.

6.3 Fortschreibung dieser Anlage. Ändert sich eine der beschriebenen Maßnahmen, wird diese Anlage im selben Arbeitsschritt geändert — nicht später.

7.1 Weitere Auftragsverarbeiter sind in Anlage 1 einzeln aufgeführt, mit Leistung, Datenumfang, Ort und Rechtsgrundlage — und mit der Kennzeichnung, ob sie immer greifen oder nur bei Nutzung einer bestimmten Anwendung. Systeme, die der Kunde selbst anbindet, stehen dort gesondert und ausdrücklich nicht als weitere Auftragsverarbeiter: mit deren Anbietern besteht kein Vertrag des Auftragsverarbeiters, also könnte er sie weder verpflichten noch für sie einstehen (§ 7.6 AVV).

7.2 Zugangsdaten, die ein Kunde für eine Verbindung hinterlegt, verlassen das System nicht: Die Leseschnittstelle liefert ausschließlich den Zustand („eingerichtet" / „nicht eingerichtet"), nie den Wert.

7.3 Verpflichtung der Beschäftigten. Personen mit Zugang zu Kundendaten sind zur Vertraulichkeit verpflichtet; die Verpflichtung besteht nach Beendigung der Tätigkeit fort.

Diese Aufstellung gehört zur Ehrlichkeit dieses Dokuments. Sie beschreibt Maßnahmen, die noch nicht oder nicht vollständig umgesetzt sind, samt der Folge für den Kunden.

Diese Grenzen werden abgearbeitet. Der jeweils erreichte Stand ist Gegenstand der Fortschreibung dieser Anlage; erhebliche Änderungen werden nach § 7.3 AVV angezeigt.