Der Dokumentendienst · Verschlüsselung, Zugriff und die Grenzen, die echt sind
Jede Compliance-Aussage auf dieser Website — die amerikanische, die europäische, die britische, die deutsche — zeigt am Ende auf ein einziges Stück Maschinerie: den Dienst, der Behandlungsunterlagen speichert. Diese Seite erklärt in gewöhnlichen Worten, wie er arbeitet — und tut dann etwas, worum die meisten Anbieterunterlagen einen Bogen machen.
Sie listet die Risiken auf, die sich technisch nicht beheben lassen. Nicht die, die wir gelöst haben und von denen wir gern erzählen — die, bei denen die ehrliche Antwort lautet: „Das kann passieren, hier ist der Grund für unsere Entscheidung, und hier ist, was Sie dagegen tun müssen.“ Wenn Sie nur einen Abschnitt lesen, lesen Sie diesen.
Stellen Sie sich jedes Behandlungsdokument in einer Kiste mit eigenem Vorhängeschloss vor, und zu jedem Schloss gehört ein anderer Schlüssel. Diese Schlüssel liegen ihrerseits in einem Tresor. Die Kisten und die kleinen Schlüssel liegen in Ihrer Datenbank. Der Tresorschlüssel nicht.
Das ist der ganze Entwurf. Alles Weitere ist Feinheit darüber, und die Folgen lohnen sich vor der Mechanik:
Wer Ihre ganze Datenbank kopiert, bekommt die Kisten und die eingeschlossenen kleinen Schlüssel. Ohne den Tresorschlüssel öffnet sich nichts davon. Erst das eröffnet Ihnen die Verschlüsselungsausnahme im Melderecht — Sie können vortragen, dass die Daten unlesbar waren, sofern der Tresorschlüssel nicht mit entwendet wurde.
Um ein Dokument zu vernichten, vernichtet man seinen kleinen Schlüssel. Die Kiste bleibt, leer und für immer verschlossen. Das ist stärker als eine gelöschte Zeile — eine gelöschte Zeile kommt aus der Sicherung der letzten Nacht zurück, ein vernichteter Schlüssel nicht.
Es gibt keine Zweitschrift, keine Hinterlegung beim Anbieter, keinen Wiederherstellungsdienst. Ist der Tresorschlüssel fort, ist jedes Behandlungsdokument, das Sie halten, mit fort. Das ist so gewollt, und Abschnitt 05 erklärt, warum jede „Lösung“ dafür schlimmer wäre als das Problem.
Das Verfahren heißt Umschlagverschlüsselung, und Banken wie Cloud-Anbieter lösen dasselbe Problem damit. Es gibt drei Schichten. Warum drei und nicht eine, steht in der dritten Spalte.
| Schicht | Was sie ist | Warum sie getrennt ist |
|---|---|---|
| Die Dokumentfassung | Die eigentliche Datei — ein Sitzungsbericht, ein Vorfallsvermerk, ein Ausweisdokument — verschlüsselt mit AES-256-GCM. Das verschlüsselte Ergebnis landet in einem eigenen Verzeichnis auf der Platte, außerhalb des gewöhnlichen Dateispeichers von Odoo, und wird nie über den üblichen Download-Weg ausgeliefert. | Den Geheimtext aus dem gewöhnlichen Dateibereich herauszuhalten heißt, dass ein falsch eingestellter Webserver keine Behandlungsunterlagen versehentlich veröffentlichen kann — denn sie liegen nicht dort, wo ein Webserver suchen würde. |
| Der Datenschlüssel (DEK) | Ein frischer zufälliger 256-Bit-Schlüssel, erzeugt für jede Fassung jedes Dokuments. Nicht je Patientin, nicht je Dokument — je Fassung. Er liegt in der Datenbank, aber nur eingeschlagen. | Ein Schlüssel je Fassung macht die Vernichtung genau. Den Schlüssel einer Fassung zu vernichten entsorgt genau diese Fassung und nichts sonst — eine Korrektur kann also bleiben, während das Original vernichtet wird, oder umgekehrt. |
| Der Installationsschlüssel (KEK) | Ein 256-Bit-Schlüssel für die ganze Installation, in einer Datei auf dem Server, der jeden Datenschlüssel einschlägt. Er liegt nie in der Datenbank und verlässt den Server nie. | Diese Trennung ist es, die die Arbeit leistet. Datenbank und Schlüssel sind verschiedene Dinge an verschiedenen Orten mit verschiedenen Sicherungen — das eine zu bekommen gibt einem das andere nicht. |
Zu jeder Dokumentfassung gibt es sechs Dinge. Sie liegen absichtlich an verschiedenen Orten, denn der ganze Entwurf ruht darauf, dass kein einziger Ort zwei davon hält.
| Das Stück | Wo es liegt | Was es bringt, nur dieses zu haben |
|---|---|---|
| Die Datei selbst, verschlüsselt | Ein eigenes Verzeichnis auf dem Server, aufgebaut als
<Speicher>/<erste 2 der UUID>/<nächste 2>/<uuid>.enc.v<Fassung>. Die Verzeichnisse gehören nur der Eigentümerkennung, die Dateien sind für sie les- und schreibbar. Außerhalb des Odoo-Dateispeichers, also nicht erreichbar über /web/content und von der Aufräumroutine für Anhänge nicht angefasst. |
Nichts. Authentifizierter Geheimtext ohne Schlüssel. Eine Datei je Fassung — eine neue Fassung abzulegen kann die vorherige also nicht überschreiben. |
| Die Nonce und zwei Prüfsummen | In der Datenbank, an der Zeile der Fassung: die für diese Verschlüsselung verwendete Nonce, eine Prüfsumme des Klartexts und eine des Geheimtexts. | Für sich genommen nichts — aber die Klartextprüfsumme wird gebraucht, um die unten beschriebene Bindung neu aufzubauen; sie zu verlieren macht den Geheimtext unentschlüsselbar. Das ist Absicht und kein Versehen. |
| Der Datenschlüssel, eingeschlagen | In der Datenbank, verschlüsselt unter dem Installationsschlüssel. Die ausgepackte Form besteht nur im Arbeitsspeicher, für die Dauer eines Lesevorgangs, und wird unmittelbar danach verworfen. | Ohne den Installationsschlüssel nichts. Eine gestohlene Datenbank liefert eingeschlagene Schlüssel und Pfade zum Geheimtext, und keines davon öffnet etwas. |
| Der Installationsschlüssel | Eine Datei auf dem Server, lesbar nur für die Kennung, unter der Odoo läuft. Nie in der Datenbank. Nie im Dateispeicher. Nie in einem angegebenen Sicherungsverzeichnis — jedes davon wird beim Start geprüft und führt zum Abbruch, nicht zu einer Warnung. | Ohne die Datenbank nichts, in der die eingeschlagenen Datenschlüssel liegen, und ohne den Geheimtextspeicher. Es braucht drei getrennte Dinge, und sie liegen an drei Orten. |
| Die Zugriffsregeln | In der Datenbank, als Datensätze — wer was öffnen darf, auf welcher Grundlage und bis wann. | Sie entscheiden, was eine Kollegin öffnen kann. Auf jemanden, der die Dateien hat und die Schlüssel nicht, wirken sie überhaupt nicht — und für genau diesen Fall ist die Verschlüsselung da. |
| Das Zugriffsprotokoll | In der Datenbank, nur wachsend und hash-verkettet. Jeder Lesezugriff, nicht nur jede Änderung. | Der Nachweis, wer was geöffnet hat. Er wird geschrieben, bevor der Inhalt herausgegeben wird — ein abgebrochener Download steht also trotzdem als Zugriff im Protokoll. |
Alles darüber lässt sich an diesen beiden leichter nachprüfen. Der erste zeigt, was beim Ablegen eines Dokuments geschieht; der zweite, was geschieht, wenn jemand eines sehen will. Lesen Sie den zweiten genau — dort sind die meisten Systeme schwächer, als sie behaupten.
Ein Sitzungsbericht, ein Vorfallsvermerk, ein Ausweisdokument. Sie kommt im Arbeitsspeicher an.
32 Byte aus der kryptografischen Zufallsquelle des Betriebssystems. Nicht aus einem Passwort abgeleitet, nicht von einem anderen Dokument übernommen, nicht von der vorherigen Fassung dieses Dokuments übernommen.
ein Schlüssel je Fassung — erst das macht die Vernichtung genauEin SHA-256 des Klartexts und eine einmalig verwendete 96-Bit-Zahl. Keine Funktion im Verschlüsselungskern nimmt eine Nonce von ihrer Aufruferin entgegen — der klassische Wiederverwendungsfehler ist hier also gar nicht möglich.
AES-256-GCM, mit UUID | Fassungsnummer | Inhaltsfingerabdruck als zusätzliche authentifizierte Daten. Diese Bindung ist verpflichtend. Ein Geheimtext, der später auf ein anderes Dokument oder eine andere Fassung kopiert wird, verweigert die Entschlüsselung, statt sich still unter den Zugriffsregeln der falschen Person zu öffnen.
Mit dem Installationsschlüssel verschlüsselt, mit Schlüsselgeneration und Schlüsselraum versehen und in dieser Form in der Datenbank abgelegt. Der ausgepackte Schlüssel wird unmittelbar aus dem Arbeitsspeicher verworfen.
Zuerst in eine temporäre Datei im Zielverzeichnis geschrieben, auf die physische Platte durchgereicht und dann an ihren Platz umbenannt — ein Absturz mitten im Schreiben kann also keine halb geschriebene Fassung hinterlassen. Die temporäre Datei enthält Geheimtext, nie Klartext.
Speicherpfad, Nonce, beide Prüfsummen, Größe und der eingeschlagene Schlüssel. Nie der Klartext, nie ein ausgepackter Schlüssel, nie der Installationsschlüssel.
Wer sie abgelegt hat, wann, wie groß und welche Art. Nur wachsend und mit den Einträgen davor verkettet.
Eine Behandlerin im Backoffice oder eine Klientin auf ihrer eigenen Aktenseite. Beide gehen durch dieselben Prüfungen; kein Weg umgeht die des anderen.
Auf dem der Klientel zugewandten Weg werden einem Konto mit bloßem Passwort keine Akten gezeigt. Die Verweigerung sagt, was zu tun ist, statt so zu tun, als gäbe es das Dokument nicht.
Eine Ratenbegrenzung je Person auf dem der Klientel zugewandten Weg. Klar benannt, denn es zu sagen verrät nichts und spart einen Supportanruf.
Zuerst die Verbotsregeln — eine einzige ist endgültig. Dann die Erlaubnisregeln: Passt keine, lautet die Antwort nein. Der Notzugriff wird erst an dieser Stelle befragt; er kann also erreichen, was nie gewährt wurde, aber eine Verweigerung nicht aufheben. Vertraulichkeitsstufen werden zuletzt angewendet und können Zugriff nur wegnehmen.
im Zweifel verschlossen · in dieser Prüfung gibt es keinen Zweig für SonderrechteDer Eintrag wird zuerst geschrieben, eine auf halbem Weg abgebrochene Übertragung steht also trotzdem als Zugriff im Protokoll. Das Protokoll wächst nur und ist hash-verkettet; Einträge lassen sich hinterher nicht stillschweigend entfernen, weder von uns noch von Ihrer eigenen Verwaltung.
Bevor ein Schlüssel angefasst wird. Eine Beschädigung im Speicher wird dann als Beschädigung gemeldet, statt später als verwirrender Authentifizierungsfehler aufzutauchen.
Er packt den Datenschlüssel dieser Fassung aus und prüft dabei Schlüsselgeneration und Schlüsselraum. Ein für einen Schlüsselraum eingeschlagener Schlüssel lässt sich nicht als ein anderer auspacken, selbst von jemandem nicht, der beide Installationsschlüssel hat.
Dokumentkennung, Fassungsnummer und Inhaltsfingerabdruck werden neu aufgebaut und müssen übereinstimmen. Manipulation, ein falscher Schlüssel und ein aus einem anderen Datensatz verschobener Geheimtext scheitern alle hier — und alle scheitern auf dieselbe Weise, denn einem Angreifer zu sagen, welcher Teil gescheitert ist, wäre eine kostenlose Auskunft.
Der Datenschlüssel wird aus dem Arbeitsspeicher entfernt. Kein Pfad in diesem Produkt schreibt ein entschlüsseltes Byte auf die Platte — nicht für Vorschauen, nicht für Miniaturbilder, nicht für die Suchindizierung.
Eine vernichtete Fassung meldet, dass ihr Schlüssel nicht mehr existiert. Es gibt keinen Rückfall, keine zwischengespeicherte Kopie und keinen Wiederherstellungsweg — und genau darum vernichtet man sie so.
Ein Schlüssel schützt jeden Datenschlüssel der Installation — sein Umgang ist also der Teil, den man Zeile für Zeile prüfen sollte. Alle folgenden Prüfungen laufen beim Start und alle führen zum Abbruch — der Server startet lieber nicht, als mit einem Schutz zu laufen, den Sie zu haben glauben und nicht haben.
32 Byte aus der Zufallsquelle des Betriebssystems, geschrieben in eine Datei, die in einem einzigen Schritt nur mit Leserecht für die Eigentümerkennung angelegt wird — sie ist also nie kurzzeitig für andere lesbar.
Die Datei muss entweder 32 rohe Byte oder 64 Hexadezimalzeichen enthalten. Sonst wird nichts angenommen — eine Passphrase wird zurückgewiesen statt zu einem Schlüssel gestreckt, denn eine gestreckte Passphrase ist ein schwächerer Schlüssel, der wie ein stärkerer aussieht.
Nicht in der Datenbank. Nicht im Datenverzeichnis von Odoo, nicht im Addons-Pfad, nicht im Dateispeicher. Nicht im Geheimtextspeicher. Und in keinem Verzeichnis, das Sie als Sicherungswurzel angegeben haben.
Das Letzte ist das, was schiefgeht. Eine Sicherung, die Datenbank und Schlüssel enthält, ist ein kompromittierter Schlüssel, und sie stellt die Installation außerhalb des amerikanischen Melde-Schutzraums und der europäischen Ausnahme nach Art. 34 Abs. 3 lit. a — und genau dafür ist die Verschlüsselung überhaupt da.
Den Installationsschlüssel zu wechseln schlägt die Datenschlüssel neu ein und schreibt kein einziges Byte Geheimtext um. Hunderttausend Dokumente wechseln so schnell, wie sich hundert Schlüssel neu verschlüsseln lassen, und nicht so schnell, wie sich hunderttausend Dateien neu schreiben lassen.
Die Generationsnummer steckt in der Umhüllung — ein unter der alten Generation eingeschlagener Schlüssel lässt sich also nicht stillschweigend öffnen, als wäre er der neue.
Eine Fassung zu vernichten überschreibt ihren eingeschlagenen Schlüssel mit Zufallsbytes , statt das Feld zu leeren — es bleibt also nicht einmal auf der Datenbankseite etwas zurückzuholen.
Die Metadatenhülle der Fassung und das gesamte Zugriffsprotokoll bleiben — Sie können also weiterhin belegen, dass Sie das Dokument hielten und es richtig vernichtet haben. Eine Fassung lässt sich nicht löschen, solange ihr Schlüssel noch existiert, die Reihenfolge kann also nie verkehrt herum sein.
Das sind die Stellen, an denen Verschlüsselung üblicherweise fast richtig umgesetzt wird — und im „fast“ steckt der ganze Unterschied.
Wird eine Fassung verschlüsselt, ist die Verschlüsselung an die Kennung dieses Dokuments, seine Fassungsnummer und einen Fingerabdruck seines Inhalts gebunden. In der Kryptografie heißt das zusätzliche authentifizierte Daten, und hier ist es verpflichtend — keine Aufruferin kann es überspringen.
Die Wirkung: Ein Geheimtext, der auf ein anderes Dokument oder eine andere Fassung kopiert wird, verweigert die Entschlüsselung. Er öffnet sich nicht still unter den Zugriffsregeln der falschen Patientin — und genau diesem Angriff ist ein System ohne diese Bindung ausgesetzt.
AES-GCM ist katastrophal schwach, wenn dieselbe Nonce zweimal mit demselben Schlüssel verwendet wird: Wer zwei solche Geheimtexte sieht, kann aus beiden Informationen zurückgewinnen. Es ist der klassische Umsetzungsfehler.
Hier erzeugt jede Verschlüsselung ihre eigene Nonce, und keine Funktion nimmt eine Nonce von der Aufruferin entgegen. Der Fehler wird nicht schwerer gemacht; er wird unmöglich gemacht.
Der Verschlüsselungskern ist als eigenständiges Stück ohne Abhängigkeit vom Anwendungsrahmen geschrieben, damit wer die Verschlüsselungsaussage prüft, ihn für sich lesen und testen kann, ohne ein Kliniksystem zu betreiben.
Wenn Ihr Sicherheitsteam die Aussagen dieser Seite prüfen statt glauben will, ist das die Datei, die man ihm gibt — und sie ist kurz.
Wo das Recht die eigenen Prozessnotizen einer Therapeutin von der Behandlungsakte trennt — die amerikanische Ausnahme für psychotherapeutische Notizen ist der klarste Fall —, werden diese Notizen unter einem zweiten, anderen Installationsschlüsselverschlüsselt. Der Schlüssel, der die gewöhnliche Akte öffnet, öffnet sie nicht.
Das zählt, weil es die Trennung zu einer Eigenschaft des Speichers macht und nicht der Zugriffsregeln. Wären morgen sämtliche Berechtigungen im System falsch, würde der gewöhnliche Schlüssel diese Notizen trotzdem nicht entschlüsseln. Es heißt zugleich, dass der zweite Schlüssel vor dem Start eingerichtet sein muss: Eine solche Notiz ohne ihn abzulegen scheitert , statt still auf den Hauptschlüssel zurückzufallen — ein stiller Rückfall würde die Trennung zerstören, ohne dass es jemandem auffiele.
Beides wird häufig verwechselt. Die Verschlüsselung schützt vor jemandem, der im System überhaupt nichts zu suchen hat. Gegen das weit häufigere Problem hilft sie nicht: jemand, der sehr wohl im System ist und in eine Akte sieht, die ihn nichts angeht.
Dafür ist die Berechtigungsschicht da, und sie folgt einem anderen Grundsatz als die meisten Systeme: Der Zugriff folgt dem Behandlungsverhältnis, nicht der Berufsbezeichnung.
Jedes Mal. Nicht einmalig bei der Anmeldung.
Ausdrücklich gesagt, weil Prüfende danach fragen
Eine Behandlerin braucht manchmal wirklich eine Akte, zu der sie kein Verhältnis hat — eine Krise, ein Anruf außerhalb der Dienstzeit, eine erkrankte Kollegin. Wo Ihre Organisation es zulässt, steht der Notzugriff bereit. Ihn zu nutzen eröffnet eine festgehaltene Sitzung, die danach geprüft wird.
Ein System, das nur je verweigert, ist auf seine eigene Art unsicher, und im Vereinigten Königreich ist es ausdrücklich regelwidrig: Das siebte Caldicott-Prinzip macht die Pflicht zu teilen ebenso wichtig wie die Pflicht zu schützen. Also gibt es den Zugriff — und seine Nutzung ist nie still.
An einer Dokumentart — und diese Art entscheidet über die Regeln, die Aufbewahrungsfrist und darüber, wer sie öffnen darf.
In klaren Worten, und zwar bevor bevor gespeichert wird. Die meisten Fehlablagen entstehen, weil niemand wusste, wo ein Dokument landen würde.
Gebunden an dieses Dokument, diese Fassung und einen Fingerabdruck dieses Inhalts.
Der ausgepackte Schlüssel besteht nur im Arbeitsspeicher, für den Moment, in dem er gebraucht wird.
Mit eigenen Rechten, in einem eigenen Verzeichnis.
Jedes Öffnen wird protokolliert, bevor der Inhalt erscheint.
Als neue Fassung, mit einem eigenen neuen Schlüssel. Das Original bleibt unangetastet und weiterhin lesbar — eine änderbare Akte ist als Beweis nichts wert.
Er verweigert die Entschlüsselung, denn die Verschlüsselung ist an die Identität des ursprünglichen Dokuments gebunden.
Ab dem Ende des Verhältnisses — nicht ab dem Tag, an dem die Akte angelegt wurde.
Das Schlüsselmaterial wird mit Zufallsbytes überschrieben, dann wird die Schlüsselzeile gelöscht. Zuerst zu überschreiben ist Absicht: Bricht der Vorgang ab, ist das Ergebnis ein Dokument, das sich nicht lesen lässt, und nie eines, das überlebt, obwohl es das nicht sollte.
Sie können weiterhin belegen, dass die Akte bestand, wer sie über zwanzig Jahre gesehen hat und dass sie fristgerecht vernichtet wurde. Der Inhalt ist für niemanden mehr lesbar, dauerhaft, auch für uns nicht.
Alles darüber ist das, was das System gut macht. Dieser Abschnitt ist das Gegenteil: die Stellen, an denen etwas Schlimmes geschehen kann und keine Technik es schließt — weil das Schließen mehr Schutz kosten würde, als es einbringt.
Jedes sagt, was tatsächlich geschieht, was wir dagegen tun und was bei Ihnen bleibt. Erzählt Ihnen ein Anbieter, seine Verschlüsselung habe nichts davon, hat er entweder nicht darüber nachgedacht oder hofft, dass Sie es nicht tun.
Was geschieht: Die Schlüsseldatei wird gelöscht, die Platte fällt aus, der Server wird ohne sie neu aufgesetzt, oder die eine Person, die wusste, wo sie lag, ist gegangen. Jedes Behandlungsdokument im System wird dauerhaft unlesbar. Nicht schwer zurückzuholen — unmöglich. Die Datenbank ist unversehrt und wertlos.
Warum wir es nicht beheben: Die einzigen Abhilfen wären eine Kopie beim Anbieter oder eine Hintertür zur Wiederherstellung. Beide zerstören genau die Eigenschaft, für die der ganze Entwurf existiert. Hielten wir eine Kopie, stimmte „eine gestohlene Datenbank ist keine Verletzung“ nicht mehr, und jede Zusage auf dieser Seite darüber, was wir nicht sehen können, wäre falsch. Ein wiederherstellbarer Schlüssel ist ein Schlüssel, den jemand anderes benutzen kann.
Was wir tun: Das System verweigert den Start, wenn der Schlüssel fehlt, statt still zu laufen und Sie das Problem entdecken zu lassen, wenn sich ein Dokument nicht öffnet. Die Startprüfung verweigert auch, wenn die Schlüsseldatei für andere als die Eigentümerkennung lesbar ist oder der falschen Kennung gehört.
Was Ihnen obliegt: Sichern Sie den Schlüssel, getrennt von den Daten, und probieren Sie aus, dass Sie ihn zurückspielen können. Zwei Menschen sollten wissen, wo er liegt. Das ist die betriebliche Pflicht mit den schwersten Folgen in der ganzen Plattform, und sie richtig zu erledigen dauert etwa zehn Minuten.
Was geschieht: Eine Verwaltung schickt die Schlüsseldatei per E-Mail an eine Kollegin, fügt sie in ein Ticket ein, kopiert sie auf einen Laptop, oder eine ausscheidende Technikerin behält eine Kopie. Wer beides hat — diese Datei und eine Kopie der Datenbank —, kann jedes Dokument entschlüsseln, offline, ohne Anmeldung, und nichts davon steht in Ihrem Zugriffsprotokoll — denn das Protokoll hält Zugriffe über die Anwendung fest, und das hier umgeht die Anwendung vollständig.
Warum wir es nicht beheben: Der Schlüssel muss für die Software lesbar sein, die ihn benutzt. Jeder Prozess, der ihn lesen kann, kann ihn kopieren. Hardware-Sicherheitsmodule verschieben dieses Problem, statt es zu lösen — die Software muss das Modul weiterhin bitten können, Schlüssel auszupacken, und wer die Rechte dieser Software hat, bekommt weiterhin Klartext.
Was wir tun: Die Dateirechte werden beim Start durchgesetzt, ein für alle lesbarer Schlüssel hält das System also an, statt unbemerkt durchzugehen. Und weil Sie selbst betreiben, haben wir die Datei überhaupt nie — der Kreis derer, die sie kopieren könnten, sind Ihre Leute, nicht Ihre Leute plus unsere.
Was Ihnen obliegt: Behandeln Sie den Schlüssel wie einen verwahrten Gegenstand. Beschränken Sie, wer sich am Server anmelden kann, nutzen Sie persönliche Verwaltungskonten statt eines gemeinsamen, und wechseln Sie den Schlüssel, wenn jemand mit Serverzugang geht — Abschnitt 06 erklärt, warum der Wechsel billig ist.
Was geschieht: Das stillste und häufigste Versagen. Jemand richtet eine Sicherung ein, die den ganzen Server einsammelt, und die Schlüsseldatei liegt im selben Archiv wie die Datenbank. Nun enthält ein gestohlenes Sicherungsband beide Hälften, die Verschlüsselung schützt nichts — und schlimmer noch, Sie würden in einer Meldung weiterhin die Verschlüsselungsausnahme beanspruchen , denn auf dem Papier war alles verschlüsselt.
Warum es schwierig ist: Am laufenden System sieht nichts anders aus. Es funktioniert einwandfrei. Das Problem besteht nur in der Sicherung und zählt nur an dem Tag, an dem die Sicherung gestohlen wird.
Was wir tun: Das ist das eine auf dieser Liste, gegen das wir zum Teil doch etwas gebaut haben. Sie geben Ihre Sicherungsverzeichnisse in der Konfiguration an, und das System verweigert den Start, wenn die Schlüsseldatei in einem davon liegt. Geben Sie gar keine Sicherungspfade an, warnt es, dass sich die Ausnahme nicht überprüfen lässt — denn eine ungeprüfte Behauptung ist die gefährliche Sorte.
Was Ihnen obliegt: Geben Sie die Sicherungswurzeln ehrlich an, und prüfen Sie, was Ihr Sicherungswerkzeug tatsächlich einschließt, statt dessen, was Sie glauben.
Was geschieht: Eine Therapeutin öffnet die Akte einer Klientin, die zugleich ihre Nachbarin ist. Jemand am Empfang schlägt eine örtliche Berühmtheit nach. Jede Regel war erfüllt — die Person hatte ein gültiges Behandlungsverhältnis oder eine gültige Grundlage und hat sie schlicht missbraucht. Die Verschlüsselung spielt hier keine Rolle. Die Zugriffssteuerung auch nicht, denn der Zugriff war gewährt.
Warum kein System es behebt: Software kann Absichten nicht lesen. Ein System, das es versuchte — den Zugriff sperren, weil ein Name örtlich klingt —, würde im Notfall echte Behandlungsarbeit blockieren, und das ist ein eigener Schaden und im Vereinigten Königreich ein eigener Regelverstoß.
Was wir tun: Es sichtbar machen statt unmöglich. Jedes Öffnen wird festgehalten, bevor Inhalt erscheint, in einem Protokoll, das niemand ändern kann — auch Ihre Verwaltung nicht und auch wir nicht. Behandlungsverhältnisse enden, und mit ihnen endet der Zugriff nach einer kurzen Kulanzzeit; das Fenster ist also schmal. Der Notzugriff ist eine eigene, bewusste, geprüfte Handlung und keine stille Fähigkeit.
Was Ihnen obliegt: Jemand muss das Protokoll auch wirklich Lesezugriff . Das Governance-Modul gibt der Prüfung ein Zuhause — Takt, benannte prüfende Person, Spur der Befunde —, aber ein Protokoll, in das niemand sieht, schreckt niemanden ab. Das ist die Kontrolle, die am häufigsten auf dem Papier steht und nie stattfindet.
Was geschieht: Um einer berechtigten Behandlerin ein Dokument zu zeigen, muss die Software es entschlüsseln. Für diesen Moment besteht es im Arbeitsspeicher des Servers als lesbarer Text. Wer das Betriebssystem vollständig beherrscht, kann es dort im Grundsatz lesen — oder die Software so ändern, dass sie Kopien behält.
Warum kein System es behebt: Das gilt für jedes System, das irgendjemandem je irgendetwas anzeigt. Kann die Maschine das Dokument zeigen, kann die Eigentümerin der Maschine das Dokument bekommen. Verschlüsselung schützt Daten im Ruhezustand und bei der Übertragung; sie kann Daten nicht vor dem Rechner schützen, der sie rechtmäßig verarbeitet.
Was wir tun: Wir halten das Fenster klein — entschlüsselt wird im Arbeitsspeicher für den Moment des Lesens, und der Klartext wird nie auf die Platte geschrieben. Und Eigenbetrieb heißt, Sie sind die Seite mit den Root-Rechten, nicht wir.
Was Ihnen obliegt: Die Serververwaltung ist die Rolle mit den höchsten Rechten, die Sie haben. Wenige Menschen, einzeln benannt, Schlüssel statt Passwörter, und ein Nachweis darüber, wer Zugang hat. Sie gehört auf die Ein- und Austrittscheckliste, neben die Behandlungskonten.
Was geschieht: Eine Aufbewahrungsregel ist falsch eingestellt, oder ein Schreddern läuft über die falsche Auswahl. Die Schlüssel werden überschrieben und die Dokumente sind unlesbar. Es gibt kein Rückgängig, und die Sicherung der letzten Nacht zurückzuspielen hilft nicht — die Sicherung enthält denselben Geheimtext, und sein Schlüssel ist fort.
Warum wir es nicht beheben: Eine umkehrbare Vernichtung ist keine Vernichtung. Der ganze Wert des Krypto-Schredderns gegenüber einer Aufsichtsbehörde liegt darin, dass es sich nicht zurücknehmen lässt. Ein „Papierkorb“ für vernichtete Schlüssel hieße, dass die Daten nie wirklich vernichtet wurden, und jede Löschzusage, die Sie gemacht haben, wäre falsch.
Was wir tun: Schlüssel lassen sich über keinen gewöhnlichen Weg löschen — der Löschvorgang ist schlicht gesperrt, und vernichtet wird nur über den Schredderweg, der dabei einen Prüfeintrag schreibt. Rechtliche Sperren setzen die Vernichtung ganz aus. Die Aufbewahrung rechnet ab gespeicherten Ankerdaten statt ab dem Dateialter — die häufigste Ursache einer Vernichtung zum falschen Datum entsteht also gar nicht.
Was Ihnen obliegt: Prüfen Sie die Aufbewahrungseinstellungen vor dem Start, nicht nach dem ersten Vernichtungslauf. Und vergewissern Sie sich, dass die geplanten Läufe tatsächlich laufen — ein still stehen gebliebener Aufbewahrungslauf ist ein anderes Problem, aber er wird auf dieselbe Weise entdeckt, nämlich zu spät.
Was geschieht: Unterlagen der psychischen Gesundheit werden zwanzig Jahre aufbewahrt, manchmal länger. AES-256 gilt derzeit nicht als brechbar, auch nicht durch die Quantenrechner, über die spekuliert wird — aber keine ehrliche Technikerin verspricht mit ernstem Gesicht irgendetwas über 2046.
Warum es niemand behebt: Gegen ein mathematisches Ergebnis, das es noch nicht gibt, lässt sich kein Schutz kaufen. Wer „quantensicheren“ Speicher für Behandlungsunterlagen verkauft, verkauft eine Geschichte.
Was wir tun: Wir machen Verfahren und Schlüssel austauschbar, ohne Ihre Daten anzufassen. Ein Schlüsselwechsel schlägt jeden Datenschlüssel unter einem neuen Installationsschlüssel neu ein, ohne ein einziges Byte Geheimtext umzuschreiben, er ist also eine Hintergrundaufgabe und kein Migrationsprojekt. Die Kryptografie steckt in einem kleinen, prüfbaren Bauteil, gerade damit sie sich austauschen lässt, wenn es so weit ist.
Was Ihnen obliegt: Wechseln Sie regelmäßig statt nie, und rechnen Sie damit, im Leben einer zwanzigjährigen Akte einmal neu zu verschlüsseln. Planen Sie es als Wartung ein, nicht als Krise.
Sehen Sie, was den sieben gemeinsam ist. In jedem Fall würde die „Abhilfe“, die das Risiko schlösse — ein wiederherstellbarer Schlüssel, eine umkehrbare Vernichtung, ein System, das Absichten liest, Schutz vor der eigenen Verwaltung — etwas Wertvolleres zerstören, als sie schützt. Die Entwurfsentscheidung lautet nicht, dass diese Risiken übersehen wurden. Sie lautet, dass ihr Schließen die übrigen Zusagen unwahr machen würde.
Was für Sie bleibt, ist wenig, genau benannt und meist Verfahren: den Schlüssel getrennt sichern, steuern, wer an den Server kommt, die Sicherungspfade angeben, das Zugriffsprotokoll lesen und die Aufbewahrungseinstellungen einmal prüfen. Diese Liste passt auf eine Seite, und mehr ist es nicht.
Da Risiko 1 und Risiko 2 die beiden folgenschwersten Punkte dieser Seite sind, lohnt es sich, genau zu sagen, welche Teile automatisch laufen und welche bei Ihnen liegen.
| Prüfung | Stand | Was geschieht |
|---|---|---|
| Der Schlüssel ist vorhanden | ✓ | Beim Start geprüft. Ein fehlender Schlüssel hält das System an, statt es laufen und später scheitern zu lassen, Dokument für Dokument, vor den Augen einer Patientin. |
| Nur die Eigentümerkennung kann ihn lesen | ✓ | Ein für die Gruppe oder für alle lesbarer Schlüssel führt beim Start zum Abbruch, nicht zu einer Warnung in einem Protokoll, das niemand liest. |
| Er gehört der richtigen Kennung | ✓ | Gegen die Kennung geprüft, unter der der Dienst läuft. Ein Schlüssel, der der Anmeldung einer ausgeschiedenen Technikerin gehört, ist ein Befund. |
| Er liegt in keinem Sicherungsverzeichnis | ✓ | Sie geben Ihre Sicherungswurzeln an; das System verweigert den Start, wenn der Schlüssel in einer davon liegt. Geben Sie keine an, warnt es, dass sich die Ausnahme bei einer Verletzung nicht überprüfen lässt. |
| Er liegt an keinem Ort, von dem aus er mit den Daten mitreisen würde | ✓ | Eine kurze Liste von Verzeichnissen, in denen der Schlüssel nie liegen darf, wird schlicht zurückgewiesen. |
| Er ist ein echter Schlüssel | ✓ | Angenommen nur als 32 rohe Byte oder 64 Hexadezimalzeichen. Eine abgeschnittene oder beschädigte Datei wird zurückgewiesen, statt damit Dokumente zu erzeugen, die nie jemand öffnen kann. |
| Er ist gesichert, und zwar getrennt | — | Ihre Sache, und die Software kann dabei nicht helfen. Wir können eine Sicherung nicht prüfen, die wir nicht sehen dürfen, und ein System, das seine eigene Schlüsselsicherung prüfen könnte, wäre ein System, das an sie herankommt. Zwei Menschen, zwei Orte, ein erprobtes Zurückspielen. |
| Wer an den Server darf | — | Ihre Sache. Wer Root-Rechte hat, kann den Schlüssel lesen. Diese Liste sollte kurz sein, namentlich geführt und überprüft, wenn Menschen gehen. |
| Schlüsselwechsel, wenn jemand geht | ⚙ | Unterstützt und billig: Der Wechsel schlägt jeden Datenschlüssel unter einem neuen Installationsschlüssel neu ein, ohne Geheimtext umzuschreiben, und abgelöste Schlüssel können aufbewahrt werden, um noch laufende Vorgänge auszupacken. Wann gewechselt wird, entscheiden Sie. Nach dem Ausscheiden einer Serververwaltung ist der naheliegende Moment, und er ist der, der am häufigsten verpasst wird. |
Jede Fassung jedes Behandlungsdokuments ist mit einem eigenen Schlüssel verschlüsselt und an die Identität dieses Dokuments gebunden, sodass sie sich nicht anderswohin verschieben lässt. Diese Schlüssel sind unter einem Installationsschlüssel eingeschlagen, der außerhalb der Datenbank liegt und Ihren Server nie verlässt — eine gestohlene Datenbank ist deshalb keine Offenlegung, und vernichtet wird, indem ein Schlüssel zerstört wird statt eine Zeile gelöscht. Dokumente öffnen sich nur für Menschen mit einem laufenden Behandlungsverhältnis, und jedes Öffnen wird zuerst in ein verkettetes Protokoll geschrieben — Missbrauch wird also sichtbar, selbst wenn der Zugriff berechtigt war. Was sich technisch nicht beheben lässt, steht in Abschnitt 05, und die Kurzfassung Ihres Teils lautet: den Schlüssel getrennt sichern, den Serverzugang kurz und namentlich halten, die Sicherungspfade angeben, das Protokoll lesen und die Aufbewahrungseinstellungen einmal vor dem Start prüfen.
Jede Länderseite stützt sich auf die hier beschriebene Maschinerie und fügt die Rechte- und Governance-Maschinerie hinzu, die ihr eigenes Recht verlangt.
