Bürgerdaten und die Frage, wer sie tatsächlich entschlüsseln kann
Jeder Plattformanbieter, der Behörden bedient, behauptet, dass Bürgerdaten verschlüsselt sind. Diese Aussage verschleiert jedoch das entscheidende Detail für den Schutz: Wer besitzt den Schlüssel? Liegt der Schlüssel beim Anbieter, schützt die Verschlüsselung Bürgerdaten lediglich vor Dritten – nicht aber vor dem Anbieter selbst oder vor jeder Instanz, die den Anbieter rechtlich zur Entschlüsselung zwingen kann.
Für Behörden, die Bürgerdaten über Drittanbieter-Plattformen austauschen, ist das keine hypothetische Sorge. Ein verschlossenes Archiv nützt wenig, wenn der Anbieter einen Ersatzschlüssel aufbewahrt und diesen bei einer Anfrage aus dem Ausland sofort herausgibt. Dieser Artikel beleuchtet, wie sich die Schlüsselverwaltung tatsächlich auf Behörden auswirkt, warum dieses Detail in Sicherheitsprüfungen oft übersehen wird und was echtes, kundeneigenes Schlüsselmanagement in der Praxis bedeutet – bis hin zu der Frage, wer den Schlüssel rotieren darf und in welchem Zeitrahmen.
Executive Summary
Sicherheitsprüfungen von Behördenplattformen enden oft bei Verschlüsselungsalgorithmus und Schlüssellänge, als würde AES-256 automatisch bedeuten, dass Bürgerdaten sicher sind. Das ist nicht der Fall. Entscheidend für den Schutz ist, wer den Schlüssel kontrolliert – denn wer den Schlüssel kontrolliert, kontrolliert auch die Daten, unabhängig von der Verschlüsselung. Generiert, speichert und verwaltet der Anbieter den Schlüssel im Auftrag der Behörde, kann er technisch jederzeit auf Bürgerdaten zugreifen – aus beliebigen Gründen, auch solchen, denen die Behörde nie zugestimmt hat und die Bürger nie genehmigt haben. Kundeneigenes Schlüsselmanagement, abgesichert durch Hardware, schließt diese Möglichkeit vollständig aus. Für IT-Verantwortliche im öffentlichen Sektor wird Verschlüsselung so von einem Beschaffungskriterium zu einer überprüfbaren architektonischen Tatsache.
Wichtige Erkenntnisse
- Verschlüsselung schützt Daten nur vor Parteien, die den Schlüssel nicht besitzen. Liegt der Schlüssel beim Anbieter, hängt der Schutz der Bürgerdaten vom Wohlwollen des Anbieters ab – nicht von der Verschlüsselung selbst.
- Bring-your-own-key-Modelle entziehen dem Anbieter die Möglichkeit zur Entschlüsselung vollständig. Ein vom Anbieter verwalteter Schlüssel lässt diese Möglichkeit uneingeschränkt bestehen, unabhängig vom verwendeten Algorithmus oder dessen Beschreibung im Beschaffungsdokument.
- Ein Hardware Security Module macht den Schlüsselbesitz zu einer physischen Tatsache, nicht zu einer Richtlinie. Ein in einem von der Behörde kontrollierten HSM generierter und gespeicherter Schlüssel kann von der Plattform, die die Daten hostet, selbst bei administrativem Zugriff nicht extrahiert werden.
- On-Demand-Schlüsselrotation ist Teil des echten Besitzes. Eine Behörde, die den Schlüssel nicht nach eigenem Zeitplan rotieren kann, hat keine vollständige Kontrolle über die Bürgerdaten.
- Die Stärke der Verschlüsselung ist irrelevant, wenn die falsche Partei den Schlüssel hält. Für das Vertrauen der Bürger zählt, wer entschlüsseln kann – nicht, wie stark der Algorithmus ist.
Warum die Stärke der Verschlüsselung für Bürgerdaten die falsche Frage ist
Sicherheitsprüfungen fragen ständig nach Verschlüsselung, und die Antworten beziehen sich fast immer auf den Algorithmus: AES-256 im ruhenden Zustand, TLS 1.3 während der Übertragung. Diese Angaben sind korrekt, aber im Wesentlichen nebensächlich.
Verschlüsselte Daten haben immer einen Schlüsselbesitzer
Jeder verschlüsselte Datensatz eines Bürgers hat genau eine Barriere zur Klartextansicht: den Schlüssel. Wer diesen Schlüssel besitzt, kann die Daten lesen, sie für andere entschlüsseln oder auf rechtliche Anordnung hin entschlüsseln. Eine Datei, die mit einem starken Algorithmus und einem vom Anbieter gehaltenen Schlüssel verschlüsselt ist, ist nicht wesentlich besser vor dem Anbieter geschützt als eine Datei mit schwächerer Verschlüsselung – denn in beiden Fällen ist der begrenzende Faktor derselbe: Der Anbieter kann darauf zugreifen, wenn er es will oder dazu verpflichtet wird.
Warum Anbieter diesen Unterschied selten hervorheben
In Anbieterdokumentationen wird Verschlüsselung oft als vollständig dargestellt: „Verschlüsselt im ruhenden Zustand und während der Übertragung mit branchenüblichen Algorithmen.“ Das ist korrekt, aber unvollständig. Es sagt nichts darüber aus, wer den Schlüssel generiert hat, wo er gespeichert wird oder ob die Infrastruktur des Anbieters darauf zugreifen kann. Eine Behörde, die sich nur auf diese Aussage verlässt, hat bei einer parlamentarischen Anfrage keine echte Antwort.
Was echtes, kundeneigenes Schlüsselmanagement erfordert
Den Schlüssel zu besitzen, ist keine einzelne Funktion, sondern eine Kette von Bedingungen, die alle erfüllt sein müssen. Wird ein Glied unterbrochen, bleibt die Kontrolle der Behörde über den Schlüssel theoretisch statt operativ.
Bring-your-own-key versus Anbieter-verwalteter Schlüssel
Im Anbieter-verwalteten Modell generiert und speichert die Plattform den Verschlüsselungsschlüssel als Teil ihrer eigenen Infrastruktur – die Behörde sieht den Schlüssel möglicherweise nie. Im kundeneigenen Modell kontrolliert die Behörde die Schlüsselerstellung und -speicherung, in der Regel über ein selbst verwaltetes oder dediziertes Hardware Security Module. Der Unterschied: Der Anbieter kann technisch entweder auf Bürgerdaten zugreifen – oder eben nicht.
Warum Hardware Security Modules wichtiger sind, als es der Name vermuten lässt
Ein Hardware Security Module ist ein dediziertes physisches Gerät, das kryptografische Schlüssel so generiert, speichert und verwaltet, dass eine Extraktion selbst bei administrativem Zugriff auf das umgebende System verhindert wird. Ein rein softwarebasiertes Schlüsselmanagement kann theoretisch vom Anbieter mit ausreichendem Zugriff auf die eigene Infrastruktur umgangen werden. Ein korrekt integriertes HSM schließt diese Möglichkeit durch das Design aus – nicht durch Richtlinien.
Warum Rotation und Cipher-Kontrolle über echten Besitz entscheiden
Den Schlüssel einmal zu besitzen, ist nicht dasselbe wie ihn dauerhaft zu kontrollieren. Zwei operative Details unterscheiden echten Schlüsselbesitz von einer Behauptung, die auf dem Papier richtig aussieht, aber in der Praxis versagt.
On-Demand-Schlüsselrotation
Vermutet eine Behörde, dass ein Schlüssel kompromittiert wurde – etwa durch gestohlene Zugangsdaten oder einen vermuteten Vorfall –, ist die Fähigkeit, den Schlüssel sofort und unabhängig vom Zeitplan des Anbieters zu rotieren, entscheidend für den operativen Besitz.
Granulare Kontrolle über Cipher und Protokolle
Die Möglichkeit, bestimmte Cipher Suites zu aktivieren oder zu deaktivieren und zu steuern, welche TLS-Versionen erlaubt sind, ist eine verwandte, aber eigenständige Form der Kontrolle, die eine Behörde nach eigenem Zeitplan und nicht nach Vorgaben des Anbieters ausüben sollte.
Schlüsselverwaltung als Teil der Anbieter-Due-Diligence
Für IT-Teams im öffentlichen Sektor, die einen Anbieter bewerten, ist es entscheidend zu fragen: Wer generiert den Schlüssel? Wo wird er gespeichert? Ist ein HSM im Einsatz? Wer kann ihn rotieren – und wann? Ein Anbieter, der nur Algorithmus und Schlüssellänge nennt, gibt keine Auskunft darüber, wer tatsächlich die Kontrolle über verschlüsselte Bürgerdaten hat.
Wie eine Data Control Plane Schlüsselbesitz architektonisch garantiert
Die Kiteworks Data Control Plane integriert kundeneigene Verschlüsselungsschlüssel über ein Hardware Security Module, sodass Schlüsselerstellung und -speicherung außerhalb des Zugriffsbereichs von Kiteworks liegen. Behörden können Schlüssel nach Bedarf rotieren, steuern, welche Cipher und TLS-Versionen aktiviert sind, und profitieren von einer Single-Tenant-Architektur, bei der die Schlüsselverwaltung nicht mit anderen Kundenumgebungen geteilt wird. Jede Aktion über alle Kanäle – einschließlich E-Mail, Filesharing, APIs und KI-Agents – wird in einem fälschungssicheren, unbegrenzten Audit-Log erfasst, der direkt in SIEM-Tools eingespeist wird. So wird die Schlüsselverwaltung durch überprüfbare Protokolle belegt – nicht nur durch eine Zeile im Beschaffungsdokument.
Behörden, die das Schlüsselmanagement ihres aktuellen Anbieters an diesem Standard messen möchten, können eine individuelle Demo vereinbaren, um zu sehen, wie die Integration eines kundengesteuerten HSM auf ihre Bürgerdaten und Compliance-Anforderungen angewendet wird.
Häufig gestellte Fragen
Verschlüsselung schützt Daten nur vor Parteien, die den Schlüssel nicht besitzen. Wenn ein Anbieter den Schlüssel generiert, speichert und verwaltet, behält er die Möglichkeit, jederzeit auf Bürgerdaten zuzugreifen – unabhängig davon, ob AES-256 oder ein anderer starker Algorithmus verwendet wird.
Im Anbieter-verwalteten Modell generiert und speichert die Plattform den Schlüssel in ihrer eigenen Infrastruktur. Im kundeneigenen Modell kontrolliert die Behörde die Schlüsselerstellung und -speicherung, meist über ein Hardware Security Module, wodurch der Anbieter technisch nicht mehr in der Lage ist, die Daten zu entschlüsseln.
Ein HSM ist ein physisches Gerät, das Schlüssel so generiert, speichert und verwaltet, dass eine Extraktion selbst bei administrativem Zugriff auf das System verhindert wird. Dadurch wird der Schlüsselbesitz zur physischen Tatsache – und nicht nur zu einer Richtlinienaussage.
Wenn eine Behörde eine Schlüsselkompromittierung vermutet, ermöglicht die sofortige Rotation des Schlüssels – ohne auf den Zeitplan des Anbieters warten zu müssen – echten operativen Besitz und gewährleistet durchgehende Kontrolle.