Diese Felder gehen ein
- Vorname und Nachname
- Geburtsdatum
- Geburtsort
- Ausstellende Hochschule – implizit über den hochschulspezifischen Schlüssel
- Exakte Abschlussbezeichnung – z. B. „Bachelor of Science, Betriebswirtschaftslehre“
- Abschlussjahr
Sicherheit & Datenschutz
Für die Person geschrieben,
die intern gefragt wird:
Können wir das machen?
Diese Seite ist absichtlich lang und technisch. Sie soll es Ihnen erlauben, sich ein Urteil zu bilden, ohne bei uns nachfragen zu müssen. Wo wir etwas nicht wissen oder noch nicht umgesetzt haben, steht das ausdrücklich dabei.
Stand heute: Palatius befindet sich in der Konzept- und Validierungsphase. Es werden derzeit keine Absolventendaten verarbeitet und keine Verifikationen durchgeführt. Was hier beschrieben wird, ist das Verfahren, das umgesetzt werden soll – nicht der Bericht über einen laufenden Betrieb. Der Abschnitt Ehrlicher Stand ganz unten sagt, was davon heute existiert.
Kern des Verfahrens
Warum ein einfacher
Hash nicht genügt.
Die naheliegende Lösung wäre, Name, Geburtsdatum und Geburtsort durch eine Hashfunktion wie SHA-256 zu schicken und nur das Ergebnis zu speichern. Das sieht nach Anonymisierung aus, ist aber keine.
Der Grund ist die geringe Entropie dieser Felder. Die Menge plausibler Kombinationen aus Vorname, Nachname, Geburtsdatum und Geburtsort ist endlich und gut abschätzbar. Wer eine gestohlene Hashtabelle besitzt, kann sie offline durchprobieren – niemand merkt etwas, es kostet nur Rechenzeit – und einen erheblichen Teil der Einträge zurückrechnen. Der Zweck, Datensparsamkeit, wäre damit untergraben.
Wir nennen das hier ausdrücklich, weil es das naheliegende Missverständnis ist. Ein Anbieter, der Ihnen „gehashte Daten“ als Anonymisierung verkauft, hat entweder nicht nachgedacht oder hofft, dass Sie es nicht tun.
Die Lösung: ein geschlüsselter Hash
Statt Hash(Angaben) berechnen wir
HMAC(Schlüssel der Hochschule, Angaben). Der
Unterschied ist entscheidend: Ohne Kenntnis des geheimen Schlüssels ist
ein Offline-Durchprobieren wirkungslos, selbst wenn die vollständige
Tabelle gestohlen wird. Der Angreifer bräuchte zusätzlich den
Schlüssel – und der liegt woanders.
Diese bewusst nicht
- Anschrift – ändert sich, bringt für den Abgleich nichts und wäre zusätzliches Risiko
- Note und Notenspiegel – für die reine Echtheitsprüfung nicht nötig
- Matrikelnummer – hat der Arbeitgeber ohnehin nicht
Jedes zusätzliche Feld im Prüfwert müsste der Arbeitgeber bei der Abfrage kennen. Sparsamkeit ist hier nicht nur Datenschutz, sondern auch Funktionsbedingung.
Schlüsselverwaltung
Der Schlüssel verlässt das
Sicherheitsmodul nie im Klartext.
- Ein eigener Schlüssel je Hochschule. Einmalig erzeugt, nicht ableitbar aus anderen. Ein kompromittierter Schlüssel beträfe nie mehr als eine Hochschule.
- Verwahrung ausschließlich im KMS oder HSM. Die HMAC-Berechnung läuft als Funktionsaufruf gegen das Modul. Der Schlüssel selbst ist weder für Anwendungscode noch für Datenbankadministratoren einsehbar.
- Die Speicherverschlüsselung rotiert dagegen turnusmäßig. Der Prüfindex liegt verschlüsselt ab; dieser Schlüssel wird regelmäßig gewechselt. Das ändert keinen Prüfwert und erfordert von der Hochschule nichts. Jede Nutzung eines Schlüssels wird protokolliert und ist auditierbar.
- Schlüssel und Index liegen getrennt. Unterschiedliche Systeme, unterschiedliche Zugriffsrechte. Der Diebstahl der Indextabelle allein bringt einem Angreifer nichts.
- Der Prüfschlüssel wird nicht turnusmäßig gewechselt – und das ist kein Versäumnis. Ein Prüfwert lässt sich ohne die ursprünglichen Angaben nicht auf einen neuen Schlüssel umrechnen, und die sind gelöscht. Ein Wechsel setzt deshalb eine erneute Übermittlung durch die Hochschule voraus; er ist für den Kompromittierungsfall vorgesehen. Wer Ihnen turnusmäßige Rotation und sofortige Löschung der Rohdaten zugleich verspricht, hat eines von beidem nicht zu Ende gedacht.
Löschkonzept
Nach wenigen Minuten gibt es
die Rohdaten nirgends mehr.
Das ist der zentrale Vertrauensanker und zugleich die Stelle, an der die meisten Rückfragen kommen. Deshalb hier im Detail.
-
1
Empfang Die Datei geht über eine TLS-gesicherte Verbindung ein, auf Wunsch zusätzlich Ende-zu-Ende-verschlüsselt. Sie wird nicht in ein Dauerarchiv gelegt.
-
2
Verarbeitung Prüfbericht auf Dubletten und Formatfehler, dann Berechnung des HMAC je Datensatz gegen das Sicherheitsmodul.
-
3
Löschung, protokolliert Unmittelbar nach der Berechnung. Datum und Uhrzeit stehen in der Jahrgangsübersicht der Hochschule und im revisionssicheren Protokoll. Kein dauerhafter Klartextspeicher, keine Sicherungskopie der Rohdaten.
-
4
Dauerbestand Prüfwert, Hochschulkennung, Abschlussjahr, Status. Mehr nicht. Das Abschlussjahr dient ausschließlich als grobe Filterinformation.
Auch Palatius selbst hat nach Schritt 3 keinen Zugriff mehr auf die Rohdaten. Das ist kein Versprechen über unser Wohlverhalten, sondern eine Eigenschaft des Aufbaus: Was gelöscht ist, kann niemand herausgeben – auch nicht auf Anordnung.
Schutz vor Missbrauch
Wogegen der geschlüsselte
Hash nicht schützt.
Er schützt zuverlässig gegen Offline-Angriffe auf eine gestohlene Datenbank. Er schützt nicht automatisch gegen jemanden, der viele Kombinationen über die reguläre Abfrage durchprobiert – dafür braucht es keinen Schlüssel, nur viele Anfragen. Dagegen sind eigene Maßnahmen nötig.
Geprüfte Konten
Abfragen sind ausschließlich Unternehmen möglich, deren Geschäftskonto zuvor geprüft wurde – Handelsregisterauszug oder Gewerbeanmeldung. Kein anonymer Zugriff.
Bindung an ein Dokument
Eine Abfrage muss alle relevanten Felder eines tatsächlich vorgelegten Zeugnisses enthalten, nicht nur den Namen. Das schrumpft den praktisch durchprobierbaren Raum erheblich.
Rate Limiting
Begrenzung je Konto und Zeiteinheit, mit Eskalation bei auffälligen Mustern – etwa vielen Abfragen mit leicht variierenden Geburtsdaten zum selben Namen.
Kosten je Abfrage
Jede Abfrage ist kostenpflichtig. Systematisches Durchprobieren wird dadurch wirtschaftlich unattraktiv, bevor es technisch auffällt.
Überwachung und Sperrung
Automatisierte Erkennung ungewöhnlicher Abfragemuster mit der Möglichkeit, Konten zu sperren.
Transparenz zur Hochschule
Jede Hochschule sieht die Abfragen gegen ihren eigenen Index. Das dient der Abrechnungskontrolle und macht Missbrauchsversuche gegen den eigenen Namen sichtbar.
Protokollierung
Was geloggt wird –
und was nicht.
Bei einer Abfrage
- Anfragendes Unternehmen, Zeitstempel, betroffene Hochschule, Ergebnis.
- Zweck: Abrechnung und Missbrauchserkennung. Eigene, kurze Aufbewahrungsfrist.
- Nicht gespeichert: die eingegebenen Klardaten der Anfrage. Sie werden für den Abgleich gebraucht und danach verworfen.
Im Hochschulzugang
- Übermittlungen, Löschungen, Widerrufe, Rollenänderungen, Anmeldungen und fehlgeschlagene Anmeldeversuche.
- Einträge lassen sich weder ändern noch löschen – auch nicht von uns.
- Aufbewahrung zehn Jahre, danach automatische Löschung. Export für einen prüfbaren Nachweis.
Rechtlicher Rahmen
Auftragsverarbeitung,
keine Zweckänderung.
- Art. 28 DSGVO. Die Hochschule bleibt Verantwortliche und bestimmt Zweck und Mittel. Palatius ist Auftragsverarbeiter und weisungsgebunden.
- Dokumentierte technische und organisatorische Maßnahmen. Bestandteil des Vertrags, nicht ein Anhang, den man nachreicht.
- Keine Zweckänderung. Die Daten werden ausschließlich für die vereinbarte Verifikationsfunktion verwendet. Kein Training von Modellen, keine Weitergabe, keine Auswertung zu anderen Zwecken.
- Verarbeitungsort. Rechenzentrum in Deutschland; der Betreiber gehört zu einem US-Konzern. Unterauftragnehmer sind im Vertrag benannt, neue werden vier Wochen vorher angekündigt und können abgelehnt werden.
- Beendigung. Kündigung zum Quartalsende, danach Löschung des Index und Vernichtung des Schlüssels.
Ehrlicher Stand
Was davon heute
tatsächlich existiert.
Dieser Abschnitt ist der Grund, warum die Seite glaubwürdig sein kann. Wir könnten hier auch nichts schreiben – dann müssten Sie raten.
Umgesetzt
- Das Verfahren ist durchgeplant und dokumentiert
- Der Hochschulzugang existiert als bedienbare Oberfläche
- Diese Website verarbeitet keine Daten, setzt keine Cookies und bindet keine externen Dienste ein
Noch nicht
- Es gibt keinen Serverbetrieb: keine Anmeldung, keine Übermittlung, keine Abfrage
- Kein Sicherheitsmodul in Betrieb, kein Schlüssel erzeugt
- Es wurden noch nie Absolventendaten verarbeitet
- Der Auftragsverarbeitungsvertrag liegt im Entwurf und ist noch nicht anwaltlich geprüft
Angestrebt
- ISO 27001 oder vergleichbar – angestrebt, nicht vorhanden. Wir werden es hier ändern, wenn es vorliegt, und nicht vorher.
- Regelmäßige externe Sicherheitsprüfung vor dem ersten Echtbetrieb
Wir behaupten kein absolutes Sicherheitsversprechen. „Hundert Prozent fälschungssicher“ wäre fachlich falsch, und gegenüber Ihnen wäre es entlarvend. Was wir behaupten: Das beschriebene Verfahren hat ein wesentlich schwächeres Risikoprofil als eine klassische Datenweitergabe – und wir legen offen, woran das liegt.
Bleibt eine Frage offen?
Wir beantworten Fragen zur Verarbeitung auch schriftlich und mit Unterschrift, damit Sie das intern weiterreichen können. Eine fundierte Gegenmeinung ist uns ebenso willkommen – sie ist in dieser Phase mehr wert als eine Zusage.