Sicherheit¶
Diese Seite beschreibt, auf welchen Ebenen verAIficATor abgesichert ist — bewusst abstrakt gehalten, ohne Adressen, Netzbereiche oder sonstige Details, die für den Betrieb relevant, für die Nachvollziehbarkeit eines Records aber nicht nötig sind.
Vier Ebenen¶
Anfragen durchlaufen vier unabhängige Ebenen, bevor sie eine Antwort erhalten. Jede Ebene setzt eigene Kontrollen um, statt sich auf die vorherige zu verlassen:
| Ebene | Kontrollen |
|---|---|
| Edge | Vorgeschalteter Schutz gegen automatisierten Missbrauch und gängige Angriffsmuster, bevor eine Anfrage die Plattform überhaupt erreicht; Transportverschlüsselung zur anfragenden Person. |
| Zugangspunkt (Proxy) | Ausschließlich verschlüsselte Verbindungen, strikte Transportsicherheits- und Sicherheitsheader, Ratenbegrenzung, zusätzliche Netzbeschränkung für den institutionellen Bereich (siehe Einsatz in Institutionen). |
| Anwendung | Serverseitige Autorisierung bei jeder Ansicht — nie nur eine ausgeblendete Schaltfläche; Schutz gegen Cross-Site-Request-Forgery; Sitzungscookies, die nur über eine gesicherte Verbindung, nicht per Skript und nur an dieselbe Seite gesendet werden; eine strikte Content-Security-Policy, die kein eingebettetes Skript zulässt — jede Ausgabe entsteht serverseitig, nicht durch Skriptcode im Browser; Ratenbegrenzung auf besonders missbrauchsanfälligen Formularen (z. B. dem Zugangscode-Formular für externe Evaluationen). |
| Daten | Die Datenbank ist ausschließlich aus dem internen Anwendungsnetz erreichbar, nie direkt aus dem Internet; das Datenbankkonto der Anwendung hat nur die Rechte, die es tatsächlich braucht; Sicherungen sind verschlüsselt. |
Unveränderlichkeit als Sicherheitsmerkmal¶
Zwei Datenklassen sind auf Datenbankebene strukturell gegen nachträgliche Änderung geschützt, nicht nur durch Anwendungslogik: veröffentlichte Record-Versionen (siehe Versionierung) und die Audit-Historie jeder zustandsändernden Aktion. Jeder Eintrag der Audit-Historie verweist über eine Prüfsumme auf seinen unmittelbaren Vorgänger — eine nachträgliche Veränderung oder Entfernung eines einzelnen Eintrags würde die Kette an dieser Stelle nachweisbar unterbrechen. Diese Kette lässt sich vollständig unabhängig neu berechnen, um ihre Unversehrtheit zu bestätigen.
IP-Adressen werden in der Audit-Historie nie im Klartext gespeichert, sondern ausschließlich als gesalzener Hashwert — ausreichend, um Missbrauchsmuster zu erkennen, ohne eine anfragende Person direkt zu identifizieren.
Geheimnisse¶
Zugangsdaten, Signaturschlüssel und vergleichbare Geheimnisse liegen ausschließlich in eigens dafür vorgesehenen, eng zugriffsbeschränkten Ablagen außerhalb jedes Quellcode-Repositoriums. Ein Gutachtenden-Zugangscode (siehe Evaluationen) wird der Autorin/dem Autor genau einmal im Klartext gezeigt und danach ausschließlich als Hash gespeichert — selbst ein vollständiger Datenbankzugriff würde keinen gültigen Code preisgeben.
Betriebsprozesse¶
Die Anwendung läuft mit einem eigenen, nicht privilegierten Systemnutzer statt mit Administratorrechten. Regelmäßige, verschlüsselte Sicherungen sind Teil des Betriebs, unabhängig vom Anwendungscode selbst.
Verantwortungsvolle Meldung von Sicherheitslücken¶
Wer eine Sicherheitslücke findet, wird gebeten, sie nicht über das öffentliche Verbesserungsvorschlag-Formular zu melden, da dieses nicht für vertrauliche Inhalte ausgelegt ist. Stattdessen nimmt das Meldeformular unter der Kategorie „Sicherheitslücke melden“ Hinweise entgegen; sie gehen nicht öffentlich ein, sondern direkt an den Betrieb.