Encryption at Rest and in Transit
Daten verschlüsselt speichern und übertragen
Die Idee und ihr Nutzen
Die Schadenanwendung einer Versicherung speichert ärztliche Befunde von Unfallopfern. Wird eine Sicherungskopie der Datenbank gestohlen, sollen die Befunde darin nicht lesbar sein, und auch auf dem Weg vom Browser des Sachbearbeiters zu den Servern der Versicherung soll niemand sie mitlesen können. Dafür wandelt die Versicherung die Befunde mithilfe eines geheimen Schlüssels, einer langen Zufallszahl, in eine unlesbare Form um. Aus „Schienbeinbruch links“ wird dabei eine Zeichenfolge wie 9fK2xQ7a…. Nur wer den passenden Schlüssel hat, kann die Befunde zurückverwandeln. Dieses Umwandeln heißt Verschlüsselung. Die Versicherung verschlüsselt die Befunde bei der Übertragung und bei der Speicherung, auf Englisch Encryption in Transit und Encryption at Rest.
Wie funktioniert es?
Ein Sachbearbeiter lädt in der Schadenanwendung einen ärztlichen Befund zu einem Unfall hoch. Der Sachbearbeiter arbeitet über das WLAN im Büro. Hochgeladene Befunde nimmt der Schadendienst an, der Teil der Schadenanwendung, der auf den Servern der Versicherung läuft und die Befunde in der Datenbank speichert. Der Browser des Sachbearbeiters prüft zuerst das Zertifikat des Schadendienstes, eine digitale Bescheinigung, dass der Schadendienst wirklich zur Versicherung gehört. Danach überträgt der Browser den Befund verschlüsselt per TLS, dem Verfahren, das bei Webadressen mit https die Daten verschlüsselt. Wer das Büro-WLAN abhört, sieht nur Zeichensalat. Der Schadendienst speichert den Befund in der Datenbank. Die Datenbank verschlüsselt ihre Dateien und die nächtlichen Sicherungskopien mit einem Datenschlüssel. Die Sicherungskopien schreibt die Datenbank an einen eigenen Speicherort. Den Datenschlüssel bewahrt die Datenbank selbst nur verschlüsselt auf. Bevor die Datenbank den Datenschlüssel benutzt, lässt sie ihn von der Schlüsselverwaltung entschlüsseln, einem eigenen Dienst, der getrennt von der Datenbank läuft. Ein halbes Jahr später gibt das Betriebsteam den Speicherort der Sicherungskopien versehentlich für das Internet frei, und ein Unbekannter lädt eine Sicherungskopie herunter. Der Unbekannte hat keinen Zugriff auf die Schlüsselverwaltung, kommt deshalb nicht an den Datenschlüssel und kann die Befunde nicht lesen.
Welche Form der Verschlüsselung passt, hängt davon ab, gegen welchen Zugriff sie schützen soll: gegen Mithören unterwegs, gegen gestohlene Datenträger oder gegen neugierige Datenbankadministratoren. Bei der Übertragung schützt TLS nur, wenn der Browser das Zertifikat prüft. Ohne diese Prüfung könnte sich ein Angreifer als Schadendienst ausgeben und die verschlüsselten Daten selbst empfangen. Bei der Speicherung werden Festplatten, Datenbankdateien, Sicherungskopien oder einzelne Felder eines Datensatzes wie der Befundtext verschlüsselt abgelegt. Daten, die von Ende zu Ende verschlüsselt sind, können nur Absender und endgültiger Empfänger lesen. Alle Server, die die Daten unterwegs weiterleiten, auch die der Versicherung, sehen nur verschlüsselte Daten.
Es gibt zwei Arten von Verfahren. Bei symmetrischer Verschlüsselung wird derselbe geheime Schlüssel zum Verschlüsseln und zum Entschlüsseln verwendet. Symmetrische Verschlüsselung braucht wenig Rechenzeit und eignet sich deshalb für große Datenmengen. Bei asymmetrischer Verschlüsselung gehören zwei Schlüssel zusammen. Den öffentlichen Schlüssel darf jeder kennen, den privaten Schlüssel hat nur sein Besitzer. Asymmetrische Verschlüsselung dient unter anderem dazu, einen gemeinsamen Schlüssel sicher auszutauschen oder Daten digital zu unterschreiben. TLS nutzt beide Arten: Beim Aufbau der Verbindung vereinbaren Browser und Schadendienst mit asymmetrischen Verfahren einen gemeinsamen symmetrischen Schlüssel, und mit diesem Schlüssel überträgt der Browser den Befund.
Das Betriebsteam der Versicherung muss festlegen, wo die Schlüssel liegen, wer sie benutzen darf und wie sie regelmäßig ersetzt werden. Die Datenbank nutzt die verbreitete Umschlagverschlüsselung: Ihr Datenschlüssel ist seinerseits mit einem Hauptschlüssel verschlüsselt. Den Hauptschlüssel verwahrt die Schlüsselverwaltung. Sie gibt den Hauptschlüssel nicht heraus, sondern entschlüsselt nur auf Anfrage Datenschlüssel. Der entschlüsselte Datenschlüssel liegt zeitweise im Arbeitsspeicher der Datenbank. Kein anderes Programm auf dem Datenbankserver darf diesen Arbeitsspeicher auslesen können. Weil der Hauptschlüssel die Schlüsselverwaltung nie verlässt, legt das Betriebsteam allein in der Schlüsselverwaltung fest, welches Programm Datenschlüssel entschlüsseln darf, hier nur die Datenbank. Jede Entschlüsselung steht im Protokoll der Schlüsselverwaltung. Wird der Hauptschlüssel ersetzt, müssen nur die Datenschlüssel neu verschlüsselt werden, nicht alle Befunde.
Fragt ein berechtigter Benutzer einen Befund ab, entschlüsselt die laufende Datenbank den Befund und liefert ihn im Klartext aus, also lesbar. Deshalb kann ein Datenbankadministrator mit Zugang zur laufenden Datenbank die Befunde weiterhin abfragen.
Verschlüsselung: Befund bei Übertragung und Speicherung schützen
Wann ist es sinnvoll und wann nicht?
Verschlüsselung lohnt sich
- Ein Programm überträgt Daten über ein Netz. Verschlüsselung bei der Übertragung ist heute für jede Verbindung üblich, auch innerhalb des Firmennetzes. Ohne Verschlüsselung kann jemand die Verbindung abhören, etwa in einem öffentlichen WLAN.
- Vertrauliche Daten liegen auf Festplatten, in Datenbankdateien oder in Sicherungskopien. Verschlüsselung bei der Speicherung wird von vielen Regelwerken verlangt. Eine Festplatte kann bei der Entsorgung eines alten Servers verloren gehen. Eine Sicherungskopie kann an einem falsch geschützten Ort liegen und von Angreifern heruntergeladen werden. Ohne Verschlüsselung kann jeder, der die Festplatte oder die Sicherungskopie in die Hand bekommt, die Befunde lesen.
- Die Daten sind besonders schutzbedürftig. Dazu gehören Bankverbindungen und Gesundheitsangaben wie die ärztlichen Befunde. Der Datenschutz verlangt für solche Daten angemessene Schutzmaßnahmen. Werden solche Daten unverschlüsselt entwendet, muss die Versicherung die betroffenen Personen nach der Datenschutz-Grundverordnung benachrichtigen. Sind die Daten verschlüsselt und der Schlüssel sicher, entfällt diese Pflicht in der Regel.
- Besonders schutzbedürftige Daten wie die Befunde sollen auch vor Datenbankadministratoren geschützt sein. Ohne diesen Schutz kann jeder Datenbankadministrator mit Zugang zur laufenden Datenbank die Befunde abfragen. Dafür passt die Verschlüsselung einzelner Felder durch den Schadendienst, bevor die Befunde überhaupt in die Datenbank gelangen.
Verschlüsselung ist nicht das Richtige
- Die Datenbank muss in einem Feld suchen und sortieren, etwa im Namen des Unfallopfers. Verschlüsselt der Schadendienst dieses Feld selbst, bevor er es speichert, sieht die Datenbank den Inhalt nicht mehr und kann darin weder suchen noch sortieren. Der Schadendienst verschlüsselt das Feld deshalb nicht selbst. Das Feld ist dann durch die Verschlüsselung der Datenbankdateien geschützt, und die laufende Datenbank kann darin weiter suchen und sortieren. Vor Datenbankadministratoren schützen das Feld dann nur noch die Zugriffsrechte. Für das Suchen in verschlüsselten Feldern gibt es besondere Verfahren. Bei einem davon speichert der Schadendienst zu jedem verschlüsselten Feld zusätzlich einen aus dem Inhalt berechneten Prüfwert, mit dem die Datenbank genau passende Einträge findet; sortieren oder nach Wortteilen suchen kann die Datenbank damit nicht. Ob ein solches Verfahren reicht, muss das Team des Schadendienstes für jede Abfrage einzeln prüfen.
- Die Verschlüsselung der Datenbankdateien soll vor Datenbankadministratoren schützen. Das kann sie nicht, weil die laufende Datenbank die Befunde für jeden entschlüsselt, der sie abfragen darf. Dann legt das Betriebsteam enge Zugriffsrechte nach dem Grundsatz Least Privilege fest, bei dem jeder nur die Daten abfragen darf, die er für seine Aufgabe braucht. Ein Datenbankadministrator, der die Datenbank nur betreibt, darf dann keine Befunde abfragen.
- Der Server muss den Inhalt verarbeiten. Ein Beispiel ist der Schadendienst, der Angaben aus dem Befund auswerten soll. Bei einer Verschlüsselung von Ende zu Ende sieht der Schadendienst nur verschlüsselte Daten und kann nichts damit anfangen. Dann überträgt der Browser den Befund per TLS nur bis zum Schadendienst verschlüsselt, und der Schadendienst kann die Angaben lesen und auswerten. In der Datenbank schützt die Verschlüsselung der Datenbankdateien den Befund weiter.
- Befunde müssen gar nicht vollständig gespeichert werden. Verschlüsselung schützt gespeicherte Befunde nur, solange niemand an den Schlüssel kommt. Dann bewahrt die Versicherung nur die Angaben aus dem Befund auf, die sie für die Bearbeitung des Schadens braucht, und speichert den Rest nicht. Was nicht gespeichert ist, kann auch nicht entwendet werden. Die aufbewahrten Angaben verschlüsselt die Datenbank weiter.
Nachteile und typische Fehler
Verschlüsselung schützt nur Daten, die verschlüsselt vorliegen, und nur gegen Personen ohne Zugriff auf den Schlüssel. Die eigentliche Arbeit liegt in der Verwaltung der Schlüssel. Das Betriebsteam muss die Schlüssel gesondert sichern und einen Notfallplan für ihren Verlust bereithalten. Schlüssel und Daten brauchen getrennte Aufbewahrungsorte und getrennte Zugriffsrechte. Außerdem muss das Betriebsteam die Schlüsselverwaltung einrichten, absichern und verfügbar halten. Ist die Schlüsselverwaltung nicht erreichbar, kann die Datenbank ihren Datenschlüssel nicht entschlüsseln lassen und die Befunde nicht lesen. Zertifikate haben ein Ablaufdatum und müssen regelmäßig erneuert werden; ohne Automatik ist das eine wiederkehrende Aufgabe mit festem Termin.
Typische Fehler und woran man sie erkennt:
- Verlorener Schlüssel: Die Schlüsselverwaltung verliert durch einen Festplattenschaden den Hauptschlüssel, und vom Hauptschlüssel gibt es keine Sicherung. Die Schlüsselverwaltung kann den Datenschlüssel der Datenbank dann nicht mehr entschlüsseln, und die Befunde sind auch für die Versicherung verloren. Erkennbar ist das erst, wenn die Datenbank nach einem Neustart oder bei einer Wiederherstellung aus der Sicherungskopie ihre Daten nicht mehr lesen kann.
- Schlüssel neben den Daten: Damit eine Wiederherstellung auch ohne Schlüsselverwaltung gelingt, legt das Betriebsteam eine unverschlüsselte Kopie des Datenschlüssels an den Speicherort der Sicherungskopien. Wer eine Sicherungskopie herunterlädt, erbeutet den Datenschlüssel gleich mit und kann die Befunde lesen. Erkennbar ist das bei einer Prüfung der Speicherorte an Schlüsseldateien neben den Sicherungskopien.
- Abgelaufenes Zertifikat: Das Zertifikat des Schadendienstes wird nicht rechtzeitig erneuert. Der Browser bricht die Verbindung ab, und die Schadenanwendung ist nicht erreichbar. Erkennbar ist das an Warnmeldungen im Browser und an Verbindungen, die ab dem Ablaufdatum plötzlich fehlschlagen.
- Abgeschaltete Zertifikatsprüfung: Ein anderes Programm der Versicherung schickt Befunde an den Schadendienst. Dieses Programm ist so eingestellt, dass es jedes Zertifikat annimmt. Ein Angreifer im selben Netz leitet die Verbindung auf seinen eigenen Server um und legt dort ein selbst ausgestelltes Zertifikat vor. Das Programm nimmt das Zertifikat an und schickt die Befunde an den Server des Angreifers. Erkennbar ist das an Einstellungen wie „Zertifikat nicht prüfen“ in Konfiguration oder Code.
- Selbst gebautes Verfahren: Der Schadendienst verschlüsselt den Befundtext vor dem Speichern mit einem selbst entwickelten Verfahren statt mit einer geprüften Programmbibliothek. Außer seinen Entwicklern hat niemand das Verfahren auf Schwachstellen geprüft. Ein Datenbankadministrator, der den Befundtext abfragt, sieht dann zwar nur Zeichensalat. Hat das Verfahren aber eine Schwachstelle, kann der Datenbankadministrator den Befundtext auch ohne Schlüssel zurückverwandeln. Erkennbar ist das an eigenem Verschlüsselungscode, für den es keine unabhängige Prüfung gibt.
Weiterführend
Verwandte Ansätze
- Secrets Management: beschreibt, wie Schlüssel, Passwörter und andere Geheimnisse sicher verwahrt und an Programme ausgegeben werden.
- Defense in Depth: beschreibt Sicherheit durch mehrere unabhängige Schutzschichten. Verschlüsselung schützt die Befunde auch dann noch, wenn ein Angreifer schon eine Sicherungskopie erbeutet hat.
- Zero Trust: verlangt verschlüsselte und geprüfte Verbindungen auch innerhalb des Firmennetzes.
- Token Based Authentication: beschreibt digitale Anmeldenachweise. Solche Nachweise werden meist digital unterschrieben, damit niemand sie verändern kann. Verschlüsselt, also für Dritte unlesbar, sind sie dadurch nicht automatisch.
Werkzeuge und Umsetzungen
- OpenSSL: verbreitete Programmbibliothek für TLS und Verschlüsselungsverfahren.
- Let's Encrypt mit Certbot: kostenlose Zertifikate für
httpsund ein Programm, das die Zertifikate automatisch erneuert. - cert-manager: stellt in Kubernetes, einer verbreiteten Plattform zum Betrieb von Anwendungen auf vielen Servern, Zertifikate automatisch aus und erneuert sie.
- Tink: Programmbibliothek, die Verschlüsselung so anbietet, dass Entwickler kaum Fehler machen können, etwa ein unsicheres Verfahren wählen oder einen Zufallswert mehrfach verwenden.
- OpenBao: Tresor für Schlüssel und Geheimnisse mit einem Dienst, der Daten auf Anfrage verschlüsselt und entschlüsselt, ohne den Schlüssel herauszugeben.
- LUKS: Verschlüsselung ganzer Festplatten unter Linux.
Quellen
- OWASP: Cryptographic Storage Cheat Sheet: Empfehlungen der Sicherheitsorganisation OWASP zur Verschlüsselung gespeicherter Daten und zur Schlüsselverwaltung.
- IETF: RFC 9846, The Transport Layer Security (TLS) Protocol Version 1.3: aktuelle Festlegung von TLS 1.3, die RFC 8446 ablöst; beschreibt, wie Verbindungen gegen Mithören, Verändern und gefälschte Nachrichten geschützt werden und wie sich der Server dabei ausweist.