Leitfäden›Sicherheit & Compliance

Sicherheits- und Datenschutzrecht · Vereinigte Staaten, Europäische Union, Vereinigtes Königreich

Zuerst das Recht, dann die Software, die es ausführt.

Eine Akte der psychischen Gesundheit gehört zu den am stärksten geschützten Daten überhaupt. Ein falscher Blick in eine einzige Akte kann zu einer meldepflichtigen Verletzung werden. Diese Seite beginnt mit den drei Gesetzen, die bestimmen, was Sie tun müssen — HIPAA in den Vereinigten Staaten, die DSGVO in der Europäischen Union und UK GDPR im Vereinigten Königreich. Danach zeigt sie genau, welcher Teil der Plattform jede Pflicht ausführt. Anschließend geht es darum, wie die Software gebaut ist, wie Odoo Community steuert, wer was sieht, wie der Server gehärtet wird — und am Ende um die Teile, die bei Ihrer Organisation bleiben.

Sie ist mit Absicht in klarer Sprache geschrieben. Sie sollen sie einer Datenschutzbeauftragten, einer Sicherheitsprüferin oder einer Führungskraft geben können, die nie eine Verordnung gelesen hat — und alle drei sollen ihr folgen können.

Datenschutzbeauftragte Prüfende der Informationssicherheit Fachliche Leitung Einkauf bei der Prüfung
3behandelte Rechtsordnungen 5Eigenschaften jeder Akte 0Wege, den Zugriff zu übergehen AES-256-GCMVerschlüsselung auf jeder Datei 20 Jahrelängste abgebildete Aufbewahrung
Hier anfangen

Wählen Sie das Land, in dem Sie arbeiten

Das meiste, was folgt, ist überall gleich — die Verschlüsselung, die Zugriffssteuerung, das Prüfprotokoll, die Härtung des Servers. Was sich je Land ändert, ist die Rechte- und Governance-Maschinerie darüber, und die hat eine eigene Seite. Wenn Sie eine Prüfung durchführen, beginnen Sie mit Ihrem eigenen Land und kommen Sie danach zum gemeinsamen Teil zurück.

Vereinigte Staaten USA HIPAA · HITECH · 42 CFR Part 2 · Recht der Bundesstaaten Die größte der drei. Jede Regel der Vereinigten Staaten, die eine Praxis der psychischen Gesundheit erreicht, was dafür jeweils gebaut wurde — und am Ende sieben Schritt-für-Schritt-Durchgänge dessen, was in der Software tatsächlich geschieht.
  • Privacy Rule: jedes Patientenrecht, auch die Teile, die die meisten Systeme auslassen
  • Security Rule: alle acht technischen Schutzmaßnahmen, dazu die organisatorischen und physischen Verzeichnisse
  • Meldung von Verletzungen: vier Faktoren, 60 Tage, Schwellen je Bundesstaat, beide Fristen der Auftragsverarbeiter
  • 42 CFR Part 2, einschließlich der Regel von 2024
  • Sieben Abläufe — ein Auskunftsantrag, eine abgelehnte Berichtigung, eine Offenlegung, eine Verletzung, eine neue Patientin, ein untätiger Bildschirm und das Compliance-Jahr
Europäische Union GDPR Verordnung (EU) 2016/679 Die Rechtsgrundlage nach Artikel 9 Abs. 2 lit. h statt Einwilligung, die Löschung durch Vernichtung des Schlüssels, die Übertragbarkeit als protokollierter Export — und die zwei Meldefristen samt der Ausnahme, die man sich verdienen muss.
  • Warum Behandlungsunterlagen nicht auf Einwilligung ruhen dürfen
  • Eine Löschung, die das Recht erfüllt, ohne den Nachweis zu zerstören
  • Die 72-Stunden-Frist und die Frage nach kompromittierten Schlüsseln
  • Verarbeitungsverzeichnis und Folgenabschätzung als lebende Datensätze
Deutschland Deutschland § 203 StGB · § 630f BGB · NIS2 · SGB V Die europäischen Regeln gelten hier unverändert — und dann legt Deutschland eine eigene Schicht darüber, von der ein Stück Strafrecht ist und darüber entscheidet, ob eine Praxis überhaupt rechtmäßig bei uns kaufen darf.
  • § 203 StGB: warum die Wahl des Anbieters das rechtliche Risiko der Behandelnden ist
  • Was eine Verpflichtung nach § 203 sagt, Klausel für Klausel
  • Zehn Jahre ab Ende der Behandlung, nicht ab dem Datum der Akte
  • NIS2 für Praxisverbünde, und das bereits gebaute Programm
  • Eine ehrliche Darstellung der gesetzlichen Schiene, die wir nicht haben
Vereinigtes Königreich UK GDPR DPA 2018 · NHS Code of Practice 2021 Was das Vereinigte Königreich über die DSGVO legt: die Prüfung auf ernsthaften Schaden als Ablauf, der von selbst verfällt, der NHS-Aufbewahrungsplan als mitgelieferte Daten und ein Recht an den Unterlagen Verstorbener.
  • Eine Zurückhaltung, die eine namentlich benannte Fachperson verlangt und nach sechs Monaten verfällt
  • Zwanzig Jahre nach dem letzten Kontakt für Unterlagen der psychischen Gesundheit
  • Access to Health Records Act 1990
  • Das siebte Caldicott-Prinzip, und warum der Notzugriff eine Funktion ist
Australia Privacy Act 13 APPs · NDB-System · Aufbewahrungsrecht der Bundesstaaten Ein Bundesgesetz ohne Kleinunternehmerausnahme für Gesundheitsanbieter, acht Regelwerke der Bundesstaaten zur Aufbewahrung — und seit Juni 2025 eine Patientin, die klagen kann, ohne eine Aufsichtsbehörde abzuwarten.
  • Alle dreizehn Australian Privacy Principles, einzeln
  • APP 8: warum nichts das Land verlassen muss
  • Sieben Jahre ab dem letzten Eintrag, und bei Kindern bis zum 25. Lebensjahr
  • Der Ablauf bei einer Verletzung, Schritt für Schritt, dazu die 72-Stunden-Meldung bei Ransomware
  • Essential Eight, ISO 27001, RACGP C6.4 — und warum SOCI nicht greift
Kanada PIPEDA & PHIPA 10 Grundsätze · Gesetze der Provinzen · Aufbewahrung nach Kammerrecht Kein HIPAA, kein einzelnes Gesetz: ein Bundesgesetz, ein Gesundheitsgesetz, das sich mit der Provinz ändert, und darüber eine Berufskammer, die festlegt, wie lange eine Akte aufbewahrt wird.
  • Welches Gesetz und welche Aufsicht, Provinz für Provinz
  • Die zehn Grundsätze von PIPEDA, und PHIPA, Verwahrer für Verwahrer
  • Die Lockbox — der eine kanadische Begriff, den wir noch nicht haben
  • Zwei Meldefristen, und der jährliche Statistikbericht jeden März
  • Die Abrechnungsschiene der Provinzen, auf der wir nicht fahren, benannt in Abschnitt 09
Allen sechs gemeinsam Sichere Dokumente Die Maschinerie, auf die sich jede Länderseite stützt Wie eine Behandlungsakte verschlüsselt wird, wer eine öffnen kann, das ganze Leben eines Dokuments von der Ablage bis zur Vernichtung — und am Ende sieben Risiken, die sich technisch nicht beheben lassen.
  • Umschlagverschlüsselung, und warum es zwei Schlüssel sind und nicht einer
  • Ein Zugriff, der dem Behandlungsverhältnis folgt
  • Vernichtung durch Zerstörung eines Schlüssels statt Löschen einer Zeile
  • Sieben Risiken, klar benannt, mit dem, was bei Ihnen bleibt
01 — Beim Recht anfangen

Was HIPAA, DSGVO und UK GDPR tatsächlich von Ihnen verlangen

Die meisten Sicherheitsunterlagen beginnen mit der Technik und lassen das Recht bis zum Schluss. Diese macht es umgekehrt, denn am Recht werden Sie gemessen. Unten steht jede Rechtsordnung in klaren Worten: was sie ist, für wen sie gilt und welche Pflichten sie einer Praxis auferlegt. Darunter steht jeweils der Teil der Plattform, der diese Pflicht ausführt.

Vereinigte Staaten

HIPAA

HIPAA ist der Health Insurance Portability and Accountability Act. Er gilt für Gesundheitsanbieter in den Vereinigten Staaten und für die Unternehmen, die in ihrem Auftrag Gesundheitsdaten verarbeiten. Er besteht aus zwei Hauptteilen. Die Privacy Rule sagt, wer Gesundheitsinformationen sehen darf und was eine Patientin verlangen kann. Die Security Rule sagt, wie elektronische Gesundheitsinformationen zu schützen sind.

  • Erforderliches Mindestmaß. Mitarbeitende dürfen nur die Informationen sehen, die sie für die Aufgabe vor sich brauchen. In der Plattform setzen das die Behandlungsverhältnisse durch: Eine Therapeutin erreicht die Klientinnen ihres eigenen Fallbestands, nicht die der ganzen Praxis.
  • Der benannte Aktenbestand. Eine Patientin kann eine Kopie ihrer Akte verlangen, aber nicht alles, was die Praxis hält. Jede Dokumentart ist als innerhalb oder außerhalb dieses Bestands gekennzeichnet, und ein Antrag kann nicht zurückgeben, was außerhalb liegt.
  • Psychotherapeutische Notizen sind getrennt. HIPAA behandelt die eigenen Prozessnotizen einer Therapeutin anders als die Akte. In der Plattform sind sie unter einem anderen Schlüssel verschlüsselt — der Schlüssel, der die gewöhnliche Akte öffnet, öffnet sie also nicht.
  • Offenlegungsaufstellung. Eine Patientin kann fragen, mit wem ihre Informationen in den letzten sechs Jahren geteilt wurden. Das Offenlegungsregister beantwortet das aus gespeicherten Datensätzen.
  • Meldung von Verletzungen. Werden geschützte Gesundheitsinformationen offengelegt, müssen die Betroffenen unterrichtet werden — es sei denn, die Daten waren ordentlich verschlüsselt. Diese Ausnahme heißt safe harbour, und sie ist der Grund, warum die Verschlüsselung so gebaut ist, wie sie gebaut ist.
  • 42 CFR Part 2 ist eine eigene US-Regel für Unterlagen der Suchtbehandlung. Sie ist strenger als HIPAA und verlangt auf allem, was geteilt wird, einen Hinweis auf das Weitergabeverbot. Die Plattform erzeugt diesen Hinweis, statt ihn Mitarbeitende tippen zu lassen.
Europäische Union

GDPR

Die DSGVO ist die Datenschutz-Grundverordnung. Sie gilt für jede Organisation, die personenbezogene Daten über Menschen in der Europäischen Union verarbeitet. Gesundheitsdaten sind, was die DSGVO besondere Kategorien personenbezogener Daten nennt: Ihre Verarbeitung ist verboten, sofern nicht eine bestimmte Bedingung greift. Wo es bei HIPAA überwiegend um Schutz geht, geht es bei der DSGVO auch um die Rechte des Einzelnen an den eigenen Daten.

  • Eine Rechtsgrundlage für jede Dokumentart. Für Behandlungsunterlagen ist die richtige Bedingung Artikel 9 Abs. 2 lit. h, die Gesundheitsversorgung — nicht die Einwilligung. Eine Einwilligung, die eine Person nicht frei verweigern kann, ist keine wirksame Einwilligung, und in der Behandlung kann sie es in der Regel nicht. Die Plattform hält die Grundlage an der Dokumentart fest, später muss also nie geraten werden.
  • Das Auskunftsrecht (Art. 15). Eine Person kann eine Kopie ihrer Daten verlangen, und für die Antwort gilt eine gesetzliche Frist. Der Antrag läuft als verfolgter Ablauf, an dem diese Frist hängt.
  • Das Recht auf Löschung (Art. 17). Oft Recht auf Vergessenwerden genannt. Die Plattform erfüllt es, indem sie den Schlüssel vernichtet und nicht die Datenbankzeile — der Inhalt ist fort, der Nachweis, dass eine Akte bestand und vernichtet wurde, bleibt.
  • Das Recht auf Datenübertragbarkeit (Art. 20). Eine Person kann ihre Daten in einer Form verlangen, die sie mitnehmen kann. Die Plattform baut eine Zip-Datei im Arbeitsspeicher, liefert sie aus und protokolliert jedes Dokument darin einzeln.
  • Meldung von Verletzungen (Art. 33 und 34). Die Aufsichtsbehörde ist binnen 72 Stunden ab Ihrer Kenntnis zu unterrichten. Auch die betroffenen Personen sind zu unterrichten, es sei denn, die Daten waren verschlüsselt.
  • Governance-Unterlagen (Art. 30 und 35). Sie müssen ein Verzeichnis Ihrer Verarbeitungstätigkeiten führen und für riskante Verarbeitung eine Datenschutz-Folgenabschätzung durchführen. Beides lebt im System als laufend gepflegter Datensatz und nicht als Word-Datei, die veraltet.
Vereinigtes Königreich

UK GDPR und der DPA 2018

Nach dem Austritt aus der Europäischen Union hat das Vereinigte Königreich die DSGVO nahezu unverändert übernommen und nennt sie UK GDPR. Daneben steht der Data Protection Act 2018 und fügt eigene britische Regeln hinzu, von denen mehrere im Gesundheitswesen erheblich zählen. Die Aufsicht ist das Information Commissioner's Office, das ICO.

  • Alles, was die DSGVO verlangt, gilt weiterhin. Auskunft, Löschung, Übertragbarkeit, Meldung von Verletzungen und die Governance-Nachweise sind dieselben Pflichten wie in der EU.
  • Die Prüfung auf ernsthaften Schaden. Gesundheitsdaten dürfen von der eigenen Auskunft einer Person zurückgehalten werden, wo ihre Herausgabe ihr voraussichtlich ernsthaft schaden würde. Für einen Dienst der psychischen Gesundheit ist das das Gegenstück zur US-Ausnahme für psychotherapeutische Notizen, und das Verfahren darum herum ist streng.
  • Die Aufbewahrungsfristen des NHS. Der NHS Records Management Code of Practice 2021 setzt, wie lange Unterlagen aufbewahrt werden — in der psychischen Gesundheit 20 Jahre nach dem letzten Kontakt. Dieser Plan wird als Startdatenbestand mitgeliefert.
  • Access to Health Records Act 1990. Angehörige einer verstorbenen Person können in bestimmten Fällen deren Unterlagen verlangen. Die DSGVO erfasst Verstorbene überhaupt nicht, das ist also ein allein britisches Recht mit eigenen Regeln darüber, wer fragen darf.
  • Das siebte Caldicott-Prinzip. Die britischen Leitlinien im Gesundheitswesen sagen, dass die Pflicht, Informationen zu teilen, ebenso wichtig sein kann wie die Pflicht, sie zu schützen. Alles zu blockieren ist ein eigenes Versagen — deshalb gibt es den Notzugriff, und deshalb wird er festgehalten statt verboten.
Worin alle vier übereinstimmen

Unter den Unterschieden wollen die vier Rechtsordnungen dieselben fünf Dinge. Die Daten so schützen, dass eine gestohlene Kopie wertlos ist. Nur die Richtigen hineinsehen lassen. Festhalten, wer hineingesehen hat. Sie nur so lange behalten, wie nötig, und danach ordentlich vernichten. Und alle vier Punkte hinterher belegen können. Diese gemeinsame Liste baut die Plattform einmal in die Speicherschicht, für jede Installation. Was sich je Land ändert, ist die Rechtemaschinerie darüber, und die kommt als eigenes Modul, das Sie für Ihren Rechtsraum installieren.

Dafür ist niemand zertifiziert, und wer etwas anderes sagt, will etwas verkaufen

Ein HIPAA-zertifiziertes oder DSGVO-zertifiziertes Produkt gibt es nicht. Keine Behörde stellt dieses Zertifikat aus. Was es gibt, ist eine Liste technischer und organisatorischer Maßnahmen. Software kann die technischen umsetzen und die organisatorischen leicht ausführbar und leicht belegbar machen. Eine Organisation allein rechtskonform machen kann sie nicht. Der letzte Abschnitt dieser Seite sagt genau, welche Teile bei Ihnen bleiben.

02 — Nebeneinander

Überall derselbe technische Kern. Darüber eine jeweils andere Rechtemaschinerie

Verschlüsselung, Zugriffssteuerung, Prüfprotokoll und Aufbewahrung sind in jedem Land gleich. Sie sind einmal gebaut, im gemeinsamen Kern, und jede Installation bekommt sie. Was sich zwischen den Vereinigten Staaten, der Europäischen Union, dem Vereinigten Königreich, Australien und Kanada ändert, ist die Rechte- und Governance-Arbeit über diesem Kern. Deshalb erfüllt ein nach US-Maßstab gebautes System nicht von selbst die EU-Anforderungen, und deshalb kommt jedes Land als eigenes installierbares Modul.

Die letzten zwei Spalten tragen die ehrlichsten Kennzeichnungen. Die Australian Privacy Principles verlangen an zwei Stellen weniger als Europa, und ein australisches Modul gibt es noch nicht — die Rechtemaschinerie, die eine australische Installation heute nutzt, ist der gemeinsame Kern plus Teile des europäischen und des britischen Moduls. Die Australien-Seite benennt jede Naht.

Kanada ist die jüngste und die einzige Spalte, in der sich das Regelwerk innerhalb des Landes ändert. Ein kanadisches Modul gibt es ebenfalls nicht, und eine Pflicht hat auf dieser Tabelle nirgends eine Entsprechung — die Lockbox, eine Anweisung der Patientin, die einen Teil ihrer eigenen Akte innerhalb des Behandlungskreises abgrenzt. Die Kanada-Seite legt dar, was es hieße, sie zu bauen, und welches Gesetz welcher Provinz wo gilt.

Was verlangt wird Vereinigte Staaten
HIPAA · 42 CFR Part 2
Europäische Union
GDPR
Vereinigtes Königreich
UK GDPR · DPA 2018
Australia
Privacy Act 1988 · APPs
Kanada
PIPEDA · PHIPA und Provinzrecht
Verschlüsselung, Zugriffssteuerung, Prüfprotokoll, Aufbewahrung ✓ gemeinsamer Kern ✓ gemeinsamer Kern ✓ gemeinsamer Kern ✓ gemeinsamer Kern ✓ gemeinsamer Kern
Ein festgehaltener Rechtsgrund für jede Dokumentart — so arbeitet HIPAA nicht ✓ Art. 9 Abs. 2 lit. h für Behandlungsunterlagen, nicht Einwilligung ✓ dasselbe, unter UK GDPR ✓ APP 3.3 und s16B, je Dokumentart festgehalten § Zweck und Einwilligung, keine aufgezählte Rechtsgrundlage
Eine Person kann eine Kopie ihrer Akte verlangen ✓ 45 CFR 164.524, begrenzt auf den benannten Aktenbestand ✓ Art. 15, mit gesetzlicher Frist ✓ Art. 15, dazu die Prüfung auf ernsthaften Schaden ✓ APP 12, eine angemessene Frist, und kein Entgelt für die Anfrage ✓ PIPEDA-Grundsatz 9 und PHIPA s. 52 — 30 Tage, verlängerbar
Manches darf ihnen vorenthalten werden ✓ psychotherapeutische Notizen liegen außerhalb des Aktenbestands § eng, und abhängig vom Mitgliedstaat ✓ Prüfung auf ernsthaften Schaden, als Ablauf mit Verfallsdatum ◐ Die Gründe nach APP 12.3 gibt es; der Ablauf kommt mit der britischen Liste ◐ Die PHIPA-Gründe gibt es; der Ablauf kommt mit der britischen Liste
Eine Person kann die Löschung ihrer Daten verlangen § HIPAA gibt kein allgemeines Recht; die Aufbewahrung entscheidet ✓ Art. 17, ausgeführt durch Vernichtung des Schlüssels ✓ dasselbe, mit britischen Ausnahmen § kein allgemeines Löschrecht; die Vernichtung nach APP 11.2 leistet es § kein allgemeines Recht; Aufbewahrung und Vernichtung leisten es
Eine Person kann ihre Daten mitnehmen § über das Auskunftsrecht; HIPAA hat kein eigenes ✓ Art. 20, ausgeliefertes Zip, jede Datei protokolliert ✓ dasselbe § kein Übertragbarkeitsrecht; das Auskunftsrecht trägt es ✓ Das Recht aus Québecs Law 25 landet auf dem DSGVO-Export; auf Bundesebene gibt es keine Entsprechung
Ein Verzeichnis dessen, was geteilt wurde, und mit wem ✓ sechs Jahre, auf Verlangen ✓ was hinausging, an wen, auf welcher Grundlage ✓ dasselbe ✓ APP 6, was hinausging und auf welcher Grundlage ✓ was hinausging, an wen, auf welcher Grundlage und warum
Aufsicht und Betroffene nach einer Verletzung unterrichten ✓ Vier-Faktoren-Prüfung, 60-Tage-Benachrichtigung, Schwellen für Presse und HHS ✓ Art. 33 und 34, 72 Stunden, zwei Fristen, Schlüsselfrage festgehalten ✓ dasselbe, gemeldet an das ICO ✓ NDB-System: 30 Tage zur Prüfung, dann so bald wie praktikabel benachrichtigen ◐ der Datensatz ist vollständig; die zwei Einreichungen und die März-Zählung werden nicht erzeugt
Schriftliche Governance-Nachweise, aktuell gehalten ✓ Richtlinienverzeichnis, in Fassungen, sechs Jahre je Fassung ✓ Folgenabschätzung (Art. 35) und Verarbeitungsverzeichnis (Art. 30) ✓ dasselbe ✓ APP 1: Richtlinienverzeichnis, Risikoverzeichnis, Beschwerden als Datensätze ✓ Richtlinienverzeichnis, Risikoverzeichnis, Beschwerden als Datensätze
Ein einsatzbereit mitgelieferter Aufbewahrungsplan ⚙ je Bundesstaat verschieden, die Fristen setzen also Sie ⚙ je Mitgliedstaat verschieden, die Fristen setzen also Sie ✓ NHS Records Management Code of Practice 2021 ◐ die Fristen sind landesweit bekannt, und nichts wird vorbelegt ⚙ von Ihrer Berufskammer gesetzt, es gibt also keinen landesweiten Plan zum Vorbelegen
Unterlagen Verstorbener ⚙ HIPAA schützt sie 50 Jahre; die Regel ist nicht vorbelegt — Die DSGVO gilt nicht für Verstorbene ✓ Access to Health Records Act 1990 § Das Bundesgesetz endet mit dem Tod; NSW schützt danach 30 Jahre ⚙ Die Gesetze gelten nach dem Tod weiter; die Frist setzt Ihre Berufskammer
Zusätzlicher Schutz für Unterlagen der Suchtbehandlung ✓ 42 CFR Part 2, mit dem Hinweis auf das Weitergabeverbot — keine entsprechende Regel — keine entsprechende Regel — keine entsprechende Regel — keine entsprechende Regel
✓GebautHeute im Modul dieses Rechtsraums, und vorführbar. ⚙Gebaut — den Wert setzen SieDen Mechanismus gibt es, und die Zahl ist Ihre, weil das Recht sie Ihnen oder Ihrem Bundesstaat überlässt. Kein Mangel. §Diese Rechtsordnung verlangt wenigerEs fehlt nichts. Das Recht dieses Landes gibt ein engeres Recht oder kommt auf einem anderen Weg an dieselbe Stelle. ◐Teilweise gebautEtwas fehlt tatsächlich. Die Länderseite benennt genau was. —In dieser Rechtsordnung gar nicht vorhandenDas Recht kennt dieses Recht schlicht nicht.

Die zwei mittleren Kennzeichnungen waren bis vor Kurzem eine einzige, was sich wie ein Mangel las, obwohl nur eine davon ◐ einer ist. Eine Aufbewahrungsfrist, die Sie setzen, weil Ihr Bundesstaat sie setzt, ist keine fehlende Funktion — und dass HIPAA ein Recht nicht gibt, das die DSGVO gibt, ebenso wenig.

03 — Was geschützt ist

Drei Arten von Daten, und nur eine davon ist gewöhnlich

Nicht alles in einer Praxis braucht denselben Schutz. Behandelt man jedes Feld als höchst vertraulich, wird das System langsam und sperrig, und Mitarbeitende führen ihre Notizen stattdessen in einer Tabelle. Das ist in den meisten Praxen das eigentliche Verletzungsrisiko. Behandelt man nichts als vertraulich, ist das System schlicht unsicher. Die Plattform sortiert Daten deshalb in drei Arten und setzt die schwere Maschinerie nur auf die Art an, die sie braucht.

Art der DatenBeispieleWie sie gespeichert werdenWer an sie herankommt
Gewöhnliche Geschäftsdaten Kontaktangaben, Bestellungen, Rechnungen, Buchungen, Chatnachrichten In der Datenbank, geschützt durch die Zugriffsregeln von Odoo Mitarbeitende, deren Arbeit es verlangt. Die Klientin selbst, über das Portal
Behandlungs- und Berufsunterlagen Sitzungsberichte, Vorfalls- und Kinderschutzakten, Ausweisdokumente Als sichere Dokumente: Fassung für Fassung verschlüsselt, außerhalb des gewöhnlichen Dateibereichs gespeichert Nur das Behandlungsteam dieser Klientin, über eine ausdrückliche Regel. Keine Berufsbezeichnung gewährt es
Finanzunterlagen Rechnungen, Auszahlungen an Fachkräfte, Vertragsfassungen, Buchungen Im Buchhaltungsjournal, das sich nach dem Erstellen einer Buchung nicht mehr ändern lässt Buchhaltung und Leitung. Eine Korrektur hinterlässt eine Spur, statt zu überschreiben
Warum die Grenze an der Akte verläuft und nicht am Feld

Jedes einzelne Feld zu verschlüsseln machte das Suchen unmöglich. Mitarbeitende würden ihre Arbeitsnotizen dann irgendwo außerhalb des Systems führen, wo nichts protokolliert und nichts geschützt ist. Die Plattform zieht die Grenze deshalb an der Art der Akte und nicht am einzelnen Feld. Vertrauliches Material bleibt im System, wo sich jeder Zugriff darauf festhalten lässt.

04 — Das Aktenmodell

Fünf Dinge, die für jede geschützte Akte gelten

Diese fünf sind Eigenschaften der Art, wie die Daten gespeichert werden. Sie sind keine Richtlinien, an die sich Mitarbeitende halten sollen. Dieser Unterschied ist das ganze Argument dieser Seite. Eine Kontrolle, die davon abhängt, dass Menschen sich richtig verhalten, ist eine Kontrolle, die Sie einer Prüferin nicht vorführen können. Eine in den Speicher gebaute Kontrolle können Sie vorführen.

Eigenschaft eins

Jede Fassung ist für sich verschlüsselt

Die Plattform nutzt Umschlagverschlüsselung mit AES-256-GCM. Das heißt: Jede Dokumentfassung bekommt einen eigenen Zufallsschlüssel, und dieser Schlüssel wird dann mit einem zweiten Schlüssel verschlossen, der zur ganzen Installation gehört. Dieser zweite Schlüssel liegt nie in der Datenbank.

  • Wer allein eine Kopie der Datenbank stiehlt, hat nichts Lesbares
  • Die verschlüsselten Dateien liegen außerhalb des gewöhnlichen Dateispeichers von Odoo und werden nie über den üblichen Download-Weg ausgeliefert
  • Den Installationsschlüssel zu wechseln verschließt die kleinen Schlüssel neu, ohne eine einzige verschlüsselte Datei umzuschreiben
  • Die Software verweigert den Start, wenn dieser Schlüssel fehlt, für alle lesbar ist, der falschen Kennung gehört oder dort liegt, wo er zusammen mit den Daten kopiert würde, die er schützt
Eigenschaft zwei

Verschlossen, sofern keine Regel öffnet

Jeder Lesezugriff muss eine Regel finden, die ihn erlaubt, und keine, die ihn verbietet. Geprüft wird jedes Mal, nicht einmalig bei der Anmeldung. Zur Verwaltung zu gehören, Leitung zu sein oder das Dokument selbst geschrieben zu haben gewährt für sich genommen nichts.

  • Es gibt keinen Generalschlüssel und keinen Sonderweg in fachliche Inhalte
  • Der Zugriff folgt dem Behandlungsteam der Klientin, nicht dem Organigramm
  • Wenn Mitarbeitende ein Dokument ablegen, sagt der Dialog in klaren Worten, wer es wird öffnen können — bevor gespeichert wird
Eigenschaft drei

Jeder Lesezugriff wird aufgeschrieben

Protokolliert wird das Öffnen und nicht nur das Ändern. Das Protokoll wächst nur und ist hash-verkettet, das heißt: Jeder Eintrag ist mathematisch an den vorhergehenden gebunden. Einen Eintrag zu entfernen oder zu ändern zerreißt die Kette und wird sichtbar.

  • Der Eintrag wird geschrieben, bevor der Inhalt herausgegeben wird, nicht danach
  • Niemand kann ihn ändern oder löschen, auch die nicht, die das System verwalten
  • Eine vollständige Liste derer, die eine Akte geöffnet haben, lässt sich für eine Klientin, eine Aufsichtsbehörde oder Ihre eigene Rechtsberatung erstellen
  • Lesezugriffe im Portal sind je Person ratenbegrenzt, gezählt aus ebendiesem Protokoll — die Grenze hält also auch über mehrere Serverprozesse hinweg
Eigenschaft vier

Korrekturen fügen hinzu, sie überschreiben nie

Wird etwas berichtigt, wird eine neue Fassung abgelegt. Die frühere bleibt genau so, wie sie war, samt ihren Metadaten. Eine Akte, die sich still ändern lässt, ist als Beweis nichts wert — und eines Tages muss Ihre vielleicht etwas wert sein.

  • Ein Berichtigungsverlangen fügt der Akte etwas hinzu, statt sie zu ersetzen
  • Jede Fassung trägt ihren eigenen Schlüssel, vernichtet werden kann also Fassung für Fassung
  • Eine Änderung ist deshalb in der Historie sichtbar und nicht etwas, das man erschließen muss
Eigenschaft fünf

Die Vernichtung zerstört den Schlüssel

Läuft eine Aufbewahrungsfrist ab, vernichtet die Plattform den Schlüssel, statt die Zeile zu löschen. Der Inhalt wird dauerhaft unlesbar. Die leere Hülle und der Prüfpfad bleiben. Dieses Verfahren heißt Krypto-Schreddern.

  • Die Vernichtung lässt sich belegen statt bloß behaupten
  • Der Nachweis, dass eine Akte einmal bestand und fristgerecht vernichtet wurde, bleibt erhalten
  • Die Aufbewahrung rechnet ab einem echten Ankerdatum: letzter Kontakt, Geburtsdatum oder Sterbedatum
Die bewusste Lücke

Was es nicht tun wird, offen gesagt

Die Plattform kann nicht in verschlüsselten Dokumenten suchen. Das ist eine unmittelbare Folge der Verschlüsselung und keine fehlende Funktion. Dokumente werden darüber gefunden, wen sie betreffen, welche Art sie haben und wann sie abgelegt wurden.

  • Das steht hier, weil ein Anbieter, der starke Verschlüsselung und Volltextsuche über denselben Inhalt verspricht, eines von beiden fälschlich verspricht
  • Es ist ein Dienst für sichere Dokumente und keine elektronische Patientenakte: keine Dokumentation, kein HL7 oder FHIR, keine elektronischen Verordnungen
  • Der Kern weiß nichts vom Gesundheitsrecht. Die Regeln jedes Landes kommen als eigenes Modul darüber
05 — Wer eine Akte öffnen kann

Der Zugriff folgt dem Behandlungsverhältnis, nicht der Berufsbezeichnung

Das ist der wichtigste Gedanke dieser Seite, und er ist das eine, was ein gewöhnliches Dokumentenmanagement nicht ausdrücken kann. Ein Behandlungsverhältnis ist eine festgehaltene Verbindung zwischen einer Behandlerin und einer Klientin, mit einer Art, einem Beginn und einem Ende. Eine Therapeutin erreicht die Unterlagen der Menschen in ihrem eigenen Fallbestand. Nicht im Fallbestand der Praxis. In ihrem eigenen. Endet das Verhältnis, endet der Zugriff — nach einer kurzen Kulanzzeit, die lang genug ist, offene Aufzeichnungen zu beenden.

Erst das macht aus dem „erforderlichen Mindestmaß“ statt einer Richtlinie im Handbuch etwas, das die Software tatsächlich durchsetzt — und etwas, das Sie in einer Prüfung vorführen können.

Was bei jedem einzelnen Lesezugriff geschieht

Fünf Schritte, jedes Mal, für jedes Dokument

  1. Wer fragt?Eine angemeldete Person, aufgelöst auf einen bestimmten Menschen. Keine Rolle und keine Gruppe.
  2. Gibt es eine Regel, die es erlaubt?Weil sie die betroffene Person ist, weil sie zum Behandlungsteam gehört oder weil ihr jemand namentlich Zugriff gewährt hat. Keine Regel, kein Zugriff.
  3. Gibt es eine Regel, die es verbietet?Eine Verweigerung schlägt immer eine Erlaubnis. Psychotherapeutische Notizen, versiegelte Dokumente und zurückgehaltene Akten verweigern auf jedem Weg hinein.
  4. Den Protokolleintrag schreibenDem nur wachsenden Protokoll hinzugefügt, bevor irgendein Inhalt zurückgeht.
  5. Im Arbeitsspeicher entschlüsseln und ausliefernAuf dem Weg hinaus wird nichts auf die Platte geschrieben, und nichts wird aus dem gewöhnlichen Dateibereich ausgeliefert.

Was einen nicht hineinbringt

Ausdrücklich aufgezählt, weil der Einkauf immer danach fragt

  1. Zur Verwaltung zu gehörenEin Verwaltungskonto öffnet für sich genommen keine fachlichen Inhalte. Es gibt keine Hintertür für Support oder Wartung.
  2. Es selbst geschrieben zu habenVorfalls- und Kinderschutzakten sind selbst für die Person verschlossen, die sie eingereicht hat, denn sie werden an die Klinikleitung abgelegt.
  3. Einen höheren Rang zu habenFachliche Rollen entscheiden, welche Bildschirme der Anwendung jemand erreicht. Sie entscheiden nie, was jemand öffnen kann.
  4. Die Klientin zu seinEine Klientin sieht eine Akte über sich selbst nur dann, wenn eine Regel es ausdrücklich gewährt. Das ist eine fachliche und rechtliche Entscheidung, bewusst getroffen und festgehalten mit dem Grund und dem Namen derjenigen, die sie getroffen hat.
  5. Eine Dokumentkennung zu erratenEin Dokument, das Sie nicht sehen dürfen, liefert „nicht gefunden“ und nie „verboten“. Sonst würde das Raten von Kennungen zu einem Weg herauszufinden, wer Akten führt.
Den Notzugriff gibt es, und er ist nie still

Manchmal braucht eine Behandlerin wirklich eine Akte, zu der sie kein Verhältnis hat — eine Krise, ein Anruf außerhalb der Dienstzeit, eine erkrankte Kollegin. Wenn Ihre Organisation es zulässt, steht ein Weg für den Notzugriff bereit. Ihn zu nutzen wird als Ereignis festgehalten und danach von der Datenschutzbeauftragten geprüft.

Das ist der Entwurf in einem Satz: Der Zugriff steht bereit, wenn jemand ihn wirklich braucht, und er ist nie still. Das ist Absicht. Ein System, das nur je blockiert, versagt auf seine eigene Art. Die britischen Leitlinien (das siebte Caldicott-Prinzip) sagen, dass die Pflicht zu teilen ebenso wichtig sein kann wie die Pflicht zu schützen — deshalb ist der Notzugriff eine entworfene Funktion des Kerns und kein offen gelassenes Loch.

06 — Der fachliche Kern

Wie Odoo Community entscheidet, wer Sie sind und was Sie sehen

Die oben beschriebene fachliche Maschinerie sitzt auf Odoo 19 Community, dem quelloffenen Geschäftskern. Odoo bringt ein eigenes Zugriffsmodell mit, und es lohnt sich, es zu verstehen — denn es ist das, was die gewöhnlichen Geschäftsdaten schützt: die Buchungen, Rechnungen, Kontakte und Nachrichten, aus denen der größte Teil des Systems besteht.

Dieser Abschnitt hat sechs Teile: die vier Schichten der Zugriffssteuerung , die entscheiden, was eine angemeldete Person erreichen darf; die Anmeldung — Passwörter, Zwei-Faktor-Authentifizierung, Passkeys und die Regeln darum herum; was „rollenbasiert“ hier tatsächlich heißt , denn der Begriff wird überall lose verwendet; die Trennung der Datenbanken; die OWASP Top Ten mit Odoos Antwort auf jede; und was es tatsächlich wert ist, quelloffen zu sein.

Alles Folgende kommt mit Odoo 19 Community. Nichts davon ist ein kostenpflichtiger Zusatz, und alles ist lesbarer Quelltext, den Ihr eigenes Sicherheitsteam prüfen kann.

Das Zugriffsmodell von Odoo hat vier Schichten. Jede beantwortet eine andere Frage, und eine Anfrage muss alle vier bestehen. Geprüft wird in der Datenschicht selbst, und das ist der entscheidende Punkt: Dieselben Prüfungen greifen, ob ein Datensatz über die Weboberfläche, über das Gateway der mobilen App oder über Odoos entfernte Schnittstelle erreicht wird. Es gibt keinen Weg, der sie umgeht.

Schicht eins

Gruppen — welchen Teil des Systems Sie erreichen

Eine Gruppe ist eine Rolle. Die Zugehörigkeit entscheidet, welche Menüs, Bildschirme und Schaltflächen eine Person überhaupt sieht. Gruppen können andere Gruppen einschließen — eine Supervisorin hat also automatisch alles, was eine Behandlerin hat, ohne dass die Berechtigungen zweimal geschrieben werden.

  • Zu den Rollen dieser Installation gehören behandelnde Fachkraft, Supervision, Klinikleitung, Aktenverwahrung, Empfang und Datenschutzbeauftragte
  • Der Empfang sieht nur Stammdaten: keine fachlichen Inhalte und keinerlei Dokumentzugriff
  • Eine Gruppe gewährt Reichweite, nie Inhalt. Die Rolle der Behandlerin öffnet für sich genommen keine Akte — das tut das Behandlungsverhältnis
Schicht zwei

Modellrechte — was Sie mit einer Art von Datensatz tun dürfen

Für jede Art von Datensatz und jede Gruppe führt Odoo vier getrennte Rechte: lesen, anlegen, ändern und löschen. Sie stehen in einfachen Textdateien, die jedes Modul mitbringt, und lassen sich also lesen und prüfen, ohne irgendetwas auszuführen.

  • Diese Installation erklärt 660 Zugriffseinträge über 35 Module
  • Was nicht aufgeführt ist, wird verweigert. Zugriff entsteht dadurch, dass man ihn benennt, nie dadurch, dass man ihn zu sperren vergisst
  • Lesen ohne Ändern ist mit Absicht häufig: Viele Rollen dürfen einen Datensatz sehen, den sie nicht ändern dürfen
Schicht drei

Datensatzregeln — welche einzelnen Datensätze Sie anfassen dürfen

Eine Datensatzregel ist ein Filter, der auf jede Abfrage gelegt wird. Erst sie macht „die eigenen Klientinnen“ und „das eigene Unternehmen“ zu etwas Wirklichem statt zu einer Frage, welchen Bildschirm jemand gerade öffnet. Globale Regeln gelten immer. An eine Gruppe gehängte Regeln erweitern den Zugriff nur für diese Gruppe.

  • Diese Installation legt 117 Datensatzregeln fest, über die Module für Behandlung, Buchung, Verträge, E-Signatur und Auswertungen hinweg
  • Typische Beispiele: Eine Behandlerin sieht die Behandlungsverhältnisse, in denen sie die Behandlerin ist; eine Portalnutzerin sieht nur Buchungen, die zu ihrem eigenen Kontakt gehören
  • Die Regel wird von der Datenschicht angewendet, sie hält also für Listenansichten, Berichte, Exporte und die entfernte Schnittstelle gleichermaßen
Schicht vier

Feldregeln und die Trennung des Portals

Einzelne Felder lassen sich auf bestimmte Gruppen beschränken — zwei Menschen können also denselben Datensatz öffnen und unterschiedlich viel davon sehen. Unabhängig davon führt Odoo Portalnutzer in einer gänzlich anderen Klasse als Mitarbeitende.

  • Eine Portalnutzerin — eine Klientin oder ein externer Kontakt — hat überhaupt keinen Zugang zum Backoffice, nur zu den Seiten, die ausdrücklich für sie veröffentlicht sind
  • Öffentliche Webseiten laufen als anonyme Nutzerin mit fast keinen Rechten — ein Fehler auf einer öffentlichen Seite kann also keine Mitarbeitendendaten preisgeben
  • Jeder Weg im Controller dieser Installation erklärt, ob er eine angemeldete Person verlangt oder bewusst öffentlich ist: 174 Wege verlangen eine Anmeldung, 57 sind bewusst öffentlich
Schutz durch den RahmenWas Odoo tutWas es verhindert
Abfragen bauenAlle Datenbankabfragen baut der Rahmen aus strukturierten Filtern. Anwendungscode schreibt für gewöhnliches Lesen und Schreiben kein rohes SQLSQL-Einschleusung über Suchfelder, Filter und Adressparameter
Maskierung in VorlagenOdoos Vorlagenmaschine maskiert Werte, die sie in eine Seite schreibt, im Grundzustand. Rohe Ausgabe muss ausdrücklich verlangt werdenCross-Site-Scripting, bei dem von einer Person gespeicherter Text im Browser einer anderen als Code läuft
Formular-TokensWebformulare, die Daten ändern, tragen ein an die Sitzung gebundenes Token, und der Server weist eine Einsendung ohne es zurückCross-Site-Request-Forgery, bei dem eine fremde Website still ein Formular unter Ihrer angemeldeten Kennung absendet
SitzungenDer Sitzungszustand liegt auf dem Server. Der Browser hält nur eine Kennung, in einem Cookie, das so gekennzeichnet ist, dass Skripte der Seite es nicht lesen könnenSitzungsdiebstahl durch ein Skript, das in der Seite läuft
PasswörterNur als Einwegprüfsumme gespeichert, nie in umkehrbarer Form. Das Prüfsummenverfahren lässt sich verbessern, ohne dass alle ihr Passwort neu setzen müssenDass eine gestohlene Nutzertabelle zu einer Liste brauchbarer Passwörter wird
DatenbankverwaltungDie Bildschirme, die ganze Datenbanken anlegen, kopieren, zurückspielen und löschen, sind im Betrieb geschlossen, und ein Hostname ist an genau eine Datenbank gebundenDass wer den Server erreicht, eine Datenbank findet, kopiert oder überschreibt
Vorgänge mit erhöhten RechtenCode kann Zugriffsregeln nur dort umgehen, wo eine Entwicklerin es bewusst geschrieben hat, für einen festgelegten Vorgang, an einer benannten Stelle. Fachliche Inhalte gehören nicht zu diesen StellenBreite, versehentliche Rechteausweitung, verborgen im Anwendungscode
QuelloffenOdoo Community steht unter einer offenen Lizenz, und die Addons dieser Plattform sind vollständig lesbar. Sicherheitskorrekturen veröffentlicht Odoo, und Sie spielen sie in Ihrer eigenen Installation einDass man den Sicherheitsaussagen eines Anbieters vollständig glauben muss

Die Anmeldung: Passwörter, zweite Faktoren und die Regeln darum herum

Die vier Schichten oben entscheiden, was eine angemeldete Person erreichen darf. Das hier ist der Teil davor — wie Odoo feststellt, dass jemand ist, wer er zu sein behauptet, und was es tut, wenn nicht. Alles davon kommt mit Odoo 19 Community; nichts davon ist ein kostenpflichtiger Zusatz.

KontrolleStandWas sie tut, und was Sie entscheiden
Passwörter werden als Prüfsumme geführt, nie gespeichert ✓ Gespeichert als PBKDF2-SHA512-Prüfsumme mit einem Salz je Passwort und einem einstellbaren Arbeitsfaktor. Eine Prüfsumme lässt sich nicht in ein Passwort zurückverwandeln — eine gestohlene Nutzertabelle ist also keine Liste von Anmeldungen. Der Arbeitsfaktor lässt sich erhöhen, wenn die Hardware schneller wird, und die Passwörter werden bei der nächsten Anmeldung jeder Person auf die stärkere Einstellung neu berechnet; niemand muss zurücksetzen.

Niemand kann ein Passwort zurücklesen, auch Ihre eigene Verwaltung nicht und auch wir nicht: Das Feld liest sich immer leer, wer auch immer fragt. Verliert jemand sein Passwort, ist der einzige Weg ein Zurücksetzen — und das ist die richtige Antwort und keine fehlende Funktion.
Zwei-Faktor-Authentifizierung ⚙ Gebaut und in jeder Installation enthalten, mit den üblichen Codes aus Authenticator-Apps (TOTP), die mit Google Authenticator, Authy, 1Password und den übrigen funktionieren. Eine Person kann ein Gerät selbst einrichten, und vertrauenswürdige Geräte lassen sich eine Zeit lang merken.

Sie legen fest: ob sie freiwillig oder verpflichtend ist. Eine Einstellung schaltet sie für alleein, eine andere für alle Mitarbeitendenkonten — und wer keine Authenticator-App hat, bekommt stattdessen einen Einmalcode per E-Mail, das Erzwingen lässt also niemanden stehen. In einer US-Installation sollte das eingeschaltet sein: Die Security Rule erwartet es, und mit der vorgeschlagenen Änderung wird es faktisch verpflichtend.
Der zweite Faktor schließt zugleich die Schnittstellentür ✓ Die Einzelheit, die sie erst wertvoll macht. Sobald eine Person einen zweiten Faktor hat, funktioniert ihr Passwort für den Zugriff von Maschine zu Maschine nicht mehr — eine Anbindung muss stattdessen einen benannten API-Schlüssel nutzen. Ohne diese Regel schützt die Zwei-Faktor-Authentifizierung den Anmeldebildschirm und lässt die Hintertür offen, und genau so wird sie in der Praxis ausgehebelt.
Passkeys ⚙ Odoo 19 unterstützt Passkeys — die Anmeldung mit Fingerabdruck, Gesicht oder einem Hardwareschlüssel statt mit einem Passwort. Es wird nichts getippt, was sich abfischen ließe; damit entfällt die ganze Klasse von Angriffen, bei denen jemand dazu gebracht wird, sein Passwort auf einer überzeugenden Kopie Ihrer Anmeldeseite einzugeben. Ob Sie es anbieten, entscheiden Sie.
API-Schlüssel statt Passwörtern für Anbindungen ✓ Jede Anbindung bekommt einen eigenen benannten Schlüssel mit eigenem Geltungsbereich, geführt bei der Person, die ihn angelegt hat, und einzeln widerrufbar. Ein durchgesickerter Schlüssel wird abgeschaltet, ohne dass jemand sein Passwort ändern muss und ohne dass die anderen Anbindungen kaputtgehen.
Passwortregeln ⚙ Eine Mindestlänge, durchgesetzt beim Setzen des Passworts, mit einer Stärkeanzeige während des Tippens. Sie setzen die Mindestlänge. Ab Werk ist sie null — sie festzulegen gehört also zum Start und ist nichts, was man später entdeckt.

Es gibt bewusst keine Einstellung für erzwungene Zeichenklassen — ein Großbuchstabe, eine Ziffer, ein Sonderzeichen. Das ist kein Versäumnis. Forschung und die aktuellen NIST-Leitlinien halten solche Regeln beide für kontraproduktiv: Sie drängen Menschen zu vorhersehbaren Ersetzungen und dazu, Passwörter aufzuschreiben, und sie bringen weniger als Länge. Länge plus zweiter Faktor ist die Kombination, die wirkt.
Schutz vor Durchprobieren ✓ Im Grundzustand eingeschaltet. Nach zehn Fehlversuchen wird jeder weitere sechzig Sekunden lang abgewiesen, gerechnet ab dem letzten Fehlversuch — ein Rateangriff wird also auf einen Versuch je Minute gedrosselt statt auf Tausende. Beide Zahlen sind Einstellungen, die eine Datenbankverwaltung ändern (oder abschalten kann, indem sie die erste auf null setzt). Es wirkt, ohne dass jemand den Angriff bemerken muss.
Erneute Anmeldung bei heiklen Handlungen ✓ Sicherheitseinstellungen zu ändern, einen zweiten Faktor einzurichten oder einen API-Schlüssel anzulegen verlangt von der Person, sich erneut auszuweisen, auch mitten in der Sitzung. Ein unbeaufsichtigter Bildschirm lässt sich also nicht dazu nutzen, das angemeldete Konto zu schwächen.
Ein Passwortwechsel beendet jede Sitzung ✓ Die Gültigkeit einer Sitzung leitet sich vom Konto selbst ab — ein Passwortwechsel oder das Deaktivieren eines Kontos entwertet also jede bestehende Sitzung überall auf einmal: jeder Browser, jedes Gerät, sofort. Erst das macht aus „Jemand ist gegangen, sperren Sie ihn aus“ eine einzige Handlung statt einer Hoffnung.
Unternehmensanmeldung, wo Sie sie nutzen ⚙ Odoo kann sich gegen Ihr bestehendes Verzeichnis (LDAP oder Active Directory) oder einen OAuth2-Anbieter anmelden — Ein- und Austritte werden also einmal an der Stelle erledigt, an der Ihre Organisation sie ohnehin erledigt. Freiwillig, und nur lohnend, wenn Sie so etwas schon betreiben.
Portaldokumente hinter einem zweiten Faktor ⚙ Das ist unseres und nicht Odoos, und es gibt es, weil die Anmeldung einer Klientin der schwächste Punkt jedes Behandlungssystems ist. Schalten Sie es ein, kann sich eine Portalnutzerin ohne zweiten Faktor weiterhin anmelden und sehen, dass es Dokumente gibt — aber keines öffnen, bis sie einen eingerichtet hat. Es betrifft Menschen, die das Portal bereits nutzen, sagen Sie es ihnen also vor dem Einschalten.
✓Im Grundzustand eingeschaltetWirkt ab dem Moment, in dem das System installiert ist. ⚙Gebaut — Sie schalten es einVorhanden und unterstützt. Ob Sie es nutzen und wie streng, entscheiden Sie.

Was „rollenbasiert“ hier tatsächlich heißt

Fast jedes System behauptet, rollenbasiert zu sein. Der Begriff lohnt das Auspacken, denn in den meisten Produkten heißt er, dass sich das Menü ändert, und in Odoo heißt er, dass sich die Daten ändern.

Eine Rolle ist in Odoo eine Gruppe. Gruppen können andere Gruppen enthalten — eine Supervisorin hat also automatisch alles, was eine Behandlerin hat, ohne dass jemand die Berechtigungen zweimal schreibt, und wird eine Berechtigung berichtigt, ist sie für alle berichtigt, die sie erben. Was eine Gruppe gewährt, ist kein Bildschirm. Es sind vier getrennte Rechte (lesen, anlegen, ändern, löschen) auf jede Art von Datensatz, dazu Filter, die entscheiden, welche Datensätze dieser Art, dazu die Möglichkeit, einzelne Felder zu verbergen.

Die wichtige Folge: Ein Menü zu verbergen ist keine Berechtigung. In einem System, in dem Rollen nur das Menü ändern, erreicht jede Person die dahinterliegenden Daten, sobald sie eine Adresse kennt. In Odoo sitzen die Prüfungen in der Datenschicht — dieselbe Verweigerung erfolgt also, ob der Datensatz über einen Bildschirm, einen Bericht, einen Export, eine Suche oder die entfernte Schnittstelle erreicht wird. Es gibt keinen Weg, der sie auslässt.

01Rollen sind nach der Aufgabe benannt

Behandelnde Fachkraft, Supervision, Klinikleitung, Aktenverwahrung, Empfang, Datenschutzbeauftragte, Buchhaltung, Vertragsverwaltung. Der Empfang sieht nur Stammdaten — keine fachlichen Inhalte und keinerlei Dokumentzugriff.

Beantwortet„Zeigen Sie mir, was der Empfang sehen kann“
02Rollen gewähren Reichweite, nie Inhalt

Die Rolle der Behandlerin öffnet für sich genommen keine Akte. Das tut das Behandlungsverhältnis. Das ist der wichtigste Satz über den Zugriff auf dieser ganzen Website.

Beantwortet„Kann eine Therapeutin die Akten der ganzen Praxis lesen?“
03Vier Rechte, nicht eines

Lesen, anlegen, ändern und löschen sind für jede Art von Datensatz getrennt. Lesen ohne Ändern ist mit Absicht häufig: Viele Rollen müssen etwas sehen, das sie nicht ändern dürfen.

Beantwortet„Wer kann eine Rechnung ändern, nachdem sie gestellt ist?“
04Zeilenfilter entscheiden, welche Datensätze

„Die eigenen Klientinnen“, „das eigene Unternehmen“, „die eigenen Buchungen“. Auf jede Abfrage angewendet, sie halten also für Listen, Berichte, Exporte und die Schnittstelle gleichermaßen.

Beantwortet„Was hindert einen Export daran, alles herauszuziehen?“
05Globale Regeln lassen sich nicht erweitern

Eine Regel, die an keiner Gruppe hängt, gilt für alle und wird mit jeder anderen Regel verknüpft — sie verengt den Zugriff also und lässt sich nie dadurch umgehen, dass man eine Rolle hinzufügt. Die Trennung der Unternehmen ist so gebaut.

Beantwortet„Kann eine Praxis die Daten einer anderen sehen?“
06Einzelne Felder lassen sich verbergen

Zwei Menschen können denselben Datensatz öffnen und unterschiedlich viel davon sehen. Hier genutzt für Kosten- und Margenzahlen und für die Felder, die nur die Aktenverwahrung lesen sollte.

Beantwortet„Sieht jede, die einen Vertrag sieht, auch seine Marge?“
07Klientinnen sind eine andere Klasse von Nutzenden

Eine Portalnutzerin hat überhaupt keinen Zugang zum Backoffice — keine eingeschränkte Ansicht davon, gar keine. Sie erreicht nur die für sie veröffentlichten Seiten. Öffentliche Webseiten laufen als anonyme Nutzerin mit fast keinen Rechten.

Beantwortet„Was ist der schlimmste Fall, wenn die Anmeldung einer Klientin gestohlen wird?“
08Jeder Weg erklärt seinen eigenen Zugriff

Jede Adresse dieser Installation sagt, ob sie eine angemeldete Person verlangt oder bewusst öffentlich ist: 174 verlangen eine Anmeldung, 57 sind bewusst öffentlich. Nichts ist versehentlich öffentlich.

Beantwortet„Welche Ihrer Adressen funktionieren ohne Anmeldung?“
09Alles davon ist lesbare Konfiguration

Die Berechtigungen kommen als einfache Textdateien in jedem Modul. Ihr eigenes Sicherheitsteam kann lesen, wer was bekommt, ohne das System zu betreiben, und es zwischen Versionen vergleichen.

Beantwortet„Können wir die Berechtigungen selbst prüfen?“

Eine Datenbank je Praxis, und kein Weg hinüber

Ihre Daten liegen in einer eigenen Datenbank. Es ist keine gemeinsame Tabelle mit einer Kundenspalte darin — und genau diese Anordnung ist die, bei der eine falsche Abfrage fremde Akten zurückgibt.

Odoo setzt diese Trennung an der Verbindung durch: Eine Anfrage trägt einen Hostnamen, der Hostname wählt genau eine Datenbank, und es gibt keinen Weg von einer Datenbank in eine andere auf demselben Server. Nichts in der Anwendung kann eine Datenbank ansprechen, mit der es nicht verbunden wurde. Dazu kommt, dass die Bildschirme, die ganze Datenbanken anlegen, kopieren, zurückspielen und löschen, im Betrieb geschlossen sind — wer auf dem Server stöbert, kann also nicht aufzählen, was da ist.

In Ihrer eigenen Datenbank leistet eine zweite Schicht dasselbe zwischen Unternehmen: Betreiben Sie mehr als eine Praxis auf einer Installation, ist die Trennung als globale Regeln geschrieben — die Sorte, die für alle gilt und die sich nie durch das Hinzufügen einer Rolle erweitern lässt.

Die OWASP Top Ten, und wo Odoo bei jeder steht

Das Open Web Application Security Project veröffentlicht die Liste der häufigsten Wege, auf denen in Webanwendungen eingebrochen wird. Es ist die Liste, die eine Sicherheitsprüferin durchgeht, hier also mit Odoos Antwort auf jeden Punkt. Das Muster, das auffällt: Das meiste davon verhindert der Entwurf des Rahmens und nicht die Sorgfalt, an die Entwicklerinnen denken müssen — und nur diese Art der Verhinderung übersteht den Kontakt mit einem Abgabetermin.

Der AngriffStandWarum er hier nicht funktioniert
Einschleusung, vor allem SQL-Einschleusungfeindliche Eingabe, als Befehl behandelt ✓ Anwendungscode schreibt Datenbankabfragen nicht von Hand. Der Rahmen baut sie aus strukturierten Filtern, und jeder Wert wird getrennt von der Abfrage übergeben — getippter Text kann also nie Teil des Befehls werden. Eine Entwicklerin müsste sich eigens Mühe geben, eine rohe Abfrage zu schreiben, und die fachlichen Module tun das nicht.
Cross-Site-Scriptingvon einer Person gespeicherter Text läuft bei einer anderen als Code ✓ Alles, was in eine Seite geschrieben wird, ist im Grundzustand maskiert. Rohen Inhalt in eine Seite zu setzen muss ausdrücklich verlangt werden und ist dann im Code sichtbar. Der Grundzustand ist sicher — etwas zu vergessen erzeugt also etwas Hässliches und nichts Gefährliches.
Cross-Site-Request-Forgeryeine fremde Seite sendet ein Formular unter Ihrer angemeldeten Kennung ✓ Jedes Formular, das Daten ändert, muss ein an die Sitzung dieser Person gebundenes Token tragen, und der Server weist eine Einsendung ohne es zurück. Das Token gibt es nur, weil die Person Ihre Seite wirklich geladen hat, und die Seite eines Angreifers kommt nicht daran.
Ausführung eingeschleuster Dateienden Server dazu bringen, selbst gelieferten Code auszuführen ✓ Es gibt keine Funktion, die eine entfernte Datei einbindet. Wo Nutzende mit erhöhten Rechten kleine Ausdrücke schreiben können, um Verhalten anzupassen, laufen diese in einem Sandkasten, der den Zugriff auf das Dateisystem, auf das Netz und auf alles sperrt, dessen Name mit einem doppelten Unterstrich beginnt — eine bewusst kurze Liste erlaubter Vorgänge statt einer Liste verbotener.
Unsichere direkte Objektverweiseeine Zahl in einer Adresse ändern, um an fremde Akten zu kommen ✓ Das ist der Punkt, an dem die meisten Systeme scheitern, und Odoos Antwort ist baulich: Die Zugriffssteuerung ist nicht in den Bildschirmen umgesetzt. Eine Datensatznummer in einer Adresse zu ändern trifft dieselbe Prüfung in der Datenschicht wie alles andere und wird dort abgewiesen. Dass eine Kennung sichtbar ist, birgt kein Risiko, denn die Kennung ist nicht das, was Zugriff gewährt.
Fehlende Beschränkung von Adresseneine Seite erreichen, indem man ihre Adresse kennt ✓ Dieselbe Antwort, und sie lohnt die Wiederholung, denn darin liegt der Unterschied zwischen echter Zugriffssteuerung und einem aufgeräumten Menü. Die Sicherheit beruht hier nicht darauf, dass ein Link verborgen ist. Wo eine Seite wirklich ohne Anmeldung funktionieren muss — eine Klientin bestätigt einen Termin aus einer E-Mail heraus —, trägt die Adresse ein signiertes Token, das für diesen Datensatz und diese Person einmalig ist.
Unsichere kryptografische SpeicherungZugangsdaten schwach oder gar nicht geschützt ✓ Passwörter werden mit PBKDF2-SHA512 und Schlüsselstreckung als Prüfsumme geführt, wie oben beschrieben, und lassen sich örtlich ganz vermeiden, indem man sich gegen das eigene Verzeichnis oder einen Identitätsanbieter anmeldet. Behandlungsunterlagen gehen noch weiter: Fassung für Fassung verschlüsselt, unter Schlüsseln außerhalb der Datenbank.
Unsichere ÜbertragungDatenverkehr im Klartext ✓ Durchgehend verschlüsselte Verbindungen, unverschlüsselte Anfragen werden umgeleitet statt beantwortet, und Browser-Kopfzeilen verweigern eine Herabstufung. Weil diese Plattform selbst betrieben wird, ist das eine Kontrolle der Installation und keine Eigenschaft der Software — sie wird als Teil einer Standardinstallation eingerichtet und ist beschrieben in Abschnitt 07.
An Internes über die Schnittstelle kommenetwas aufrufen, das nie zum Aufruf gedacht war ✓ Steht nicht auf der OWASP-Liste, lohnt aber die Ergänzung, denn hier vermuten Menschen eine Lücke. Die entfernte Schnittstelle verweigert den Aufruf jeder internen Methode — alles, dessen Name mit einem Unterstrich beginnt, dazu eine benannte Liste gefährlicher. Von außen erreichbar sind nur bewusst veröffentlichte Methoden, was scharf begrenzt, was ein Fehler im Anwendungscode preisgeben kann.

Quelloffen, und was das tatsächlich wert ist

„Quelloffen“ wird oft gesagt, als wäre es für sich genommen eine Sicherheitsfunktion. Ist es nicht. Was es Ihnen gibt, ist etwas Bestimmtes und lohnt die genaue Benennung.

Sie können prüfen statt glauben

Jede Zeile von Odoo Community und jede Zeile der fachlichen Module kann Ihr eigenes Sicherheitsteam lesen oder eine von Ihnen beauftragte Prüferin. Die Berechtigungen kommen als einfache Textdateien. Nichts auf dieser Seite muss geglaubt werden, und das ist eine andere Lage als bei einem geschlossenen Produkt, wo dieselben Aussagen nur behauptet werden können.

Das ist eine Einladung zur Prüfung und kein Ersatz für eine.

Viel mehr Menschen sehen hinein

Odoo wird weltweit laufend von Nutzenden, Beitragenden und unabhängigen Sicherheitsforschenden untersucht, und Fehlermeldungen aus der Gemeinschaft sind eine echte Quelle sicherheitsrelevanter Rückmeldungen. Odoo betreibt ein Programm für verantwortungsvolle Offenlegung und veröffentlicht Korrekturen als Hinweise.

Der eigene Entwicklungsprozess schließt eine Code-Durchsicht ein, bei der die Sicherheit einer der geprüften Punkte ist, für neuen wie für beigesteuerten Code.

Sie bestimmen, wann Korrekturen landen

Eigenbetrieb heißt, dass Sicherheitskorrekturen nach Ihrem Zeitplan in Ihre Installation kommen und nicht über Nacht erscheinen. Das ist ein Vorteil für einen Behandlungsdienst, der Änderungen prüfen muss — und zugleich eine Pflicht, denn eine Korrektur, die niemand einspielt, schützt niemanden.

Aktuell zu bleiben steht auf der Liste der Betreibenden in Abschnitt 07, und es ist der mit Abstand häufigste Weg, auf dem eine sonst gut gebaute Installation kompromittiert wird.

Eine Unterscheidung, bei der man vorsichtig sein sollte

Odoo veröffentlicht eine eigene Sicherheitsseite, und Teile davon beschreiben den Cloud-Dienst von Odoo — deren gehärtete Server-Abbilder, deren Einspielen von Korrekturen, die kleine Zahl ihrer Technikerinnen, die an eine Maschine kommen, und das nur über einen verschlüsselten Schlüssel von einem verschlüsselten Laptop aus. Das ist alles wahr, und es ist nicht nicht Ihres, denn diese Plattform läuft selbst betrieben auf Ihrer eigenen Infrastruktur.

Alles auf dieser Seite oberhalb der Linie ist eine Eigenschaft der Software und gilt für Sie genau so, wie es dasteht. Die Entsprechungen auf der Serverseite — gehärtetes Betriebssystem, Einspielen von Korrekturen, wer SSH-Zugang hat, Vollverschlüsselung der Rechner, von denen aus verwaltet wird — betreiben Sie, und sie stehen ehrlich in Abschnitt 07, einschließlich der Teile, die denen gehören, die die Server betreiben. Odoos Cloud-Seite zu lesen und anzunehmen, sie beschreibe Ihre Installation, ist der häufigste Irrtum über selbst betriebenes Odoo — und die Sorte Irrtum, die in einer Prüfung auffliegt.

Wo Odoos Modell aufhört und das fachliche anfängt

Odoos vier Schichten sind stark, gut erprobt und für gewöhnliche Geschäftsdaten ausreichend. Für eine Behandlungsakte reichen sie allein nicht, und zwar aus einem Grund: Sie sind Konfiguration, und Konfiguration kann jemand mit der richtigen Rolle ändern. Deshalb sind Behandlungsunterlagen zusätzlich unter Schlüsseln außerhalb der Datenbank verschlüsselt, und deshalb nutzen psychotherapeutische Notizen noch einmal einen anderen Schlüssel. Wären morgen sämtliche Odoo-Regeln im System falsch, ließe sich der verschlüsselte Inhalt trotzdem nicht öffnen.

07 — Der Server

Wie die Maschine selbst gehärtet wird

Sicherheit in der Anwendung zählt nur, wenn der Server darunter ordentlich geschlossen ist. Die Plattform wird selbst betrieben, sie läuft also auf einer Infrastruktur, die Sie beherrschen, und nicht in der Cloud eines Anbieters. Das ist ein echter Vorteil für einen Gesundheitsdienst, und es kommt mit einer echten Pflicht: Die folgende Härtung gehört zur Installation, und sie muss danach wahr bleiben.

Alles in der ersten Tabelle wird als Teil einer Standardinstallation eingerichtet und ist in den Installationsanleitungen beschrieben. Die zweite Tabelle ist der Teil, der denen gehört, die die Server betreiben.

BereichWie es eingerichtet istWarum es so gemacht wird
Nichts liegt unmittelbar offen Die Anwendungsdienste lauschen nur auf der Maschine selbst. Aller Verkehr von außen kommt über einen nginx-Reverse-Proxy, und der ist das Einzige auf einem öffentlichen Port Eine Vordertür statt mehrerer. Zertifikate, Kopfzeilen, Grenzen und Protokollierung greifen alle an einer Stelle
Verschlüsselung bei der Übertragung TLS-Zertifikate von Let's Encrypt, automatisch ausgestellt und erneuert. Einfaches HTTP wird auf HTTPS umgeleitet statt beantwortet Es gibt keinen unverschlüsselten Weg hinein, auch nicht versehentlich, und an die Erneuerung muss kein Mensch denken
Sicherheitskopfzeilen im Browser Strict-Transport-Security für ein Jahr, X-Frame-Options auf same-origin, X-Content-Type-Options auf nosniff Der Browser verweigert die Herabstufung auf HTTP, verweigert, dass eine fremde Seite die Website einrahmt, und verweigert das Raten von Dateitypen
Firewall Nur die Ports 80 und 443 sind zur Welt hin offen. Die Anwendungsports, die Datenbank und Redis sind von außerhalb der Maschine nicht erreichbar Die Datenbank ist aus dem Internet nie ansprechbar. Ein Telefon ist von jeder Zeile mindestens zwei Schritte entfernt
Ratenbegrenzung Grenzen am Proxy für eingehende Anfragen, dazu Token-Eimer in Redis im Gateway für öffentliche Wege und Dokumentzugriffe im Portal Der Proxy stoppt Fluten. Die Redis-Zähler halten über mehrere Serverprozesse hinweg, eine Grenze je Person bedeutet also, was sie sagt
Ein Hostname, eine Datenbank Odoo ist so eingerichtet, dass der Hostname der Anfrage genau eine Datenbank wählt, und die Bildschirme der Datenbankverwaltung sind geschlossen Wer auf dem Server stöbert, kann keine Datenbank auflisten, kopieren, zurückspielen oder löschen
Dienste, keine Konsolen Gateway und Odoo laufen als verwaltete Systemdienste unter eigenen Kennungen, automatisch gestartet und bei einem Fehler neu gestartet Nichts läuft unter einer Verwaltungskennung, und ein Neustart hängt nicht daran, dass jemand angemeldet ist
Geheimnisse nur auf dem Server Signaturschlüssel und Zugangsdaten Dritter liegen in einer Umgebungsdatei, die nur die Dienstkennung lesen kann. Die mobile App bringt nichts davon mit Die App lässt sich auseinandernehmen, und man erfährt nichts. Eine gewechselte Zugangsdatei wirkt für alle auf einmal, ohne neue App-Version
Verschlüsselte Dokumente liegen abseits Der Geheimtext landet in einem eigenen Verzeichnis mit eigenen Rechten, außerhalb des gewöhnlichen Dateispeichers von Odoo, und wird nie über den üblichen Download-Weg ausgeliefert Ein falsch eingestellter Webserver kann keine Behandlungsunterlagen versehentlich veröffentlichen
Der Hauptschlüssel wird beim Start geprüft Das Verschlüsselungsmodul liest den Schlüssel von einem eigenen Pfad und verweigert den Start, wenn die Datei fehlt, für alle lesbar ist, der falschen Kennung gehört oder in einem Verzeichnis liegt, das mit den Daten gesichert wird Das häufigste Versagen in der Praxis ist, dass der Schlüssel in derselben Sicherung landet wie die Daten, die er schützt. Die Software prüft darauf, statt einem Verfahren zu vertrauen
WebSocket auf demselben Kanal Chat, Anwesenheit und Gesprächssignalisierung werden über denselben Proxy und dasselbe Zertifikat hochgestuft wie alles andere Eine Verbindung, eine Regel, kein zweiter Lauscher, der eigens abzusichern wäre
Nachverfolgung von Anfragen Jede Anfrage trägt eine Kennung durch das Gateway und in den Antwortkopfzeilen wieder hinaus, samt ihrer Dauer Ein Vorfall lässt sich über die Dienste hinweg rekonstruieren, statt ihn aus getrennten Protokolldateien zu erraten

Die Härtung, die denen gehört, die die Server betreiben

Das sind keine Lücken in der Software. Es sind Entscheidungen und Routinen, die nur die betreibende Seite treffen kann, und kein Anbieter kann sie für Sie treffen. Sie stehen hier offen aufgezählt, damit niemand annimmt, sie wären abgedeckt.

  • Korrekturen für das Betriebssystem. Ein Zeitplan für Sicherheitsaktualisierungen auf dem Wirtsrechner, und jemand, dessen Aufgabe es ist zu bestätigen, dass sie eingespielt wurden.
  • Plattenverschlüsselung auf dem Wirtsrechner. Dokumente verschlüsselt die Plattform einzeln, aber eine Vollverschlüsselung schützt alles Übrige auf der Maschine, einschließlich Protokollen und temporären Dateien.
  • Sicherungen und deren Verschlüsselung. Wohin Sicherungen gehen, wie sie verschlüsselt werden, wer sie zurückspielen kann und wie lange sie aufbewahrt werden. Eine Sicherung ist eine vollständige Kopie Ihrer Daten, an der keine Ihrer Zugriffsregeln hängt.
  • Der Hauptschlüssel wird getrennt gesichert. Geht der Schlüssel verloren, ist jedes verschlüsselte Dokument dauerhaft verloren — das ist der Sinn des Entwurfs. Er muss gesichert werden, und er darf nicht neben den Daten gesichert werden.
  • Verwaltungszugang zum Server. SSH-Schlüssel statt Passwörtern, keine direkte Root-Anmeldung, eine Liste derer, die Zugang haben, und der Entzug an dem Tag, an dem jemand geht.
  • Erprobung des Zurückspielens. Eine Sicherung, die nie jemand zurückgespielt hat, ist eine Hoffnung und keine Kontrolle. Erproben Sie sie nach Plan und halten Sie schriftlich fest, dass Sie es getan haben.
  • Überwachung und Alarmierung. Jemand muss erfahren, wenn ein Dienst stehen bleibt, eine Platte volläuft, ein Zertifikat abzulaufen droht oder ein geplanter Aufbewahrungslauf nicht mehr läuft.
  • Mehr-Faktor-Anmeldung für Mitarbeitendenkonten. Dringend empfohlen für alle, die an fachliche Inhalte kommen, und faktisch verpflichtend, wenn die vorgeschlagene Änderung der HIPAA Security Rule in Kraft tritt. Fragen Sie Ihre Verwaltung, ob sie in Ihrer Installation eingeschaltet ist.
  • Platzierung im Netz. Ob die Datenbank auf derselben Maschine liegt oder auf einer eigenen, was an sie herankommt und ob die Verwaltung über ein privates Netz oder ein VPN läuft.
  • Penetrationstests. Die ganze Landschaft ist quelloffen und selbst betrieben, gerade damit Ihre eigenen Prüfenden sie richtig untersuchen können. Das ist eine Einladung und kein Ersatz dafür, es auch zu tun.
08 — Gestaffelte Verteidigung

Vier Schichten, und jede weist etwas ab, das die nächste nie zu sehen bekommt

Gestaffelte Verteidigung heißt, sich auf keinen einzelnen Schutz zu verlassen. Eine Anfrage muss an allen vier Schichten unten vorbei. Der Wert liegt nicht darin, dass eine davon unmöglich zu brechen wäre. Er liegt darin, dass sie auf verschiedene Weise versagen — ein Fehler in einer ist also höchst unwahrscheinlich ein Fehler in allen vier.

1 · Gerät und Oberfläche Was ein Mensch in der Hand hält Nicht vertrauenswürdig
Keine Geheimnisse auf dem GerätDie App trägt nur öffentliche Schlüssel. Man kann sie auseinandernehmen und erfährt nichts.
Biometrische Anmeldung und App-SperreZusätzlich zur Bildschirmsperre des Telefons, nicht an ihrer Stelle.
Tokens im sicheren SpeicherIm Schlüsselbund des Systems gehalten, nicht in gewöhnlichen App-Dateien.
Die Datenbank ist unerreichbarDie App kann die Datenbank überhaupt nicht ansprechen, in keinem Netz.
HTTPS · kurzlebiges Token
2 · Gateway Das einzige Hintergrundsystem, das die App kennt Hält die Geheimnisse
Jeder Schlüssel Dritter liegt hierZugangsdaten für Zahlung, KI, Nachrichten und Speicher verlassen den Server nie.
Kurzlebige signierte TokensJedes trägt, für wen es ist, wann es ausgestellt wurde, wann es abläuft, und eine eindeutige Kennung. Erneuert statt langlebig.
Passwort-PrüfsummenEinweg, und das Verfahren lässt sich verbessern, ohne zurückzusetzen.
RatenbegrenzungZähler in Redis, geteilt über jeden Serverprozess.
Prüfung der EingabenFehlerhafte Anfragen werden hier abgewiesen, bevor der fachliche Kern sie je sieht.
Signierte Links mit AblaufMedien werden vermittelt. Nichts wird von einer erratbaren Adresse ausgeliefert.
Dienstkennung · geringstmögliche Rechte
3 · Fachlicher Kern Wo die Regeln tatsächlich liegen Maßgeblich
Gruppen, Zugriffsrechte und DatensatzregelnOdoos vier Schichten, angewendet, wie auch immer der Datensatz erreicht wird.
Auflösung des BehandlungsteamsDie eine Stelle, die entscheidet, wer eine Behandlungsakte öffnen darf.
Fachliche RollenEntscheiden, welchen Teil der Anwendung jemand erreicht. Nie, was er öffnen kann.
Ein Journal, das sich nicht ändern lässtEine gestellte Rechnung steht fest. Eine Korrektur ist eine Gutschrift.
Datierte VertragsfassungenBedingungen lassen sich nicht rückdatieren, und die Historie bleibt.
im Ruhezustand verschlüsselt · Schlüssel getrennt verwahrt
4 · Speicher und Schlüssel Was einen gestohlenen Datenträger überlebt Kryptografie
Verzeichnis für GeheimtextAußerhalb des Dateispeichers, außerhalb der Datenbank, mit eigenen Rechten.
Der HauptschlüsselAuf der Platte, im Eigentum der Dienstkennung, nie in derselben Sicherung wie die Daten.
Ein zweiter Schlüssel für therapeutische NotizenDer gewöhnliche Schlüssel öffnet sie nicht, was auch immer die Regeln sagen.
Hash-verkettetes PrüfprotokollNur wachsend. Manipulation ist erkennbar und nicht bloß unerwünscht.
09 — Praxis der Gesundheitsbranche

Die Kontrollen, nach denen eine fachliche Prüferin ausdrücklich fragt

Firewalls und Verschlüsselung erwartet man von jedem System. Die folgenden neun sind die, die gerade in einer Prüfung im Bereich der psychischen Gesundheit zur Sprache kommen und die ein allgemeines Dokumentenmanagement überhaupt nicht ausdrücken kann. Jede steht hier mit der Frage, die sie beantwortet, denn meist kommt sie in dieser Form.

01Behandlungsverhältnisse

Eine festgehaltene Verbindung zwischen einer Behandlerin und einer Klientin, mit Art, Beginn und Ende. Endet das Verhältnis, endet auch der Zugriff — nach einer Kulanzzeit, die lang genug ist, offene Aufzeichnungen zu beenden.

Beantwortet„Wie setzen Sie das erforderliche Mindestmaß durch?“
02Ablage an die Leitung

Vorfälle, Beschwerden und Kinderschutzmeldungen gehen an die Klinikleitung und sind für die Person verschlossen, die sie eingereicht hat, und für jede, über die sich beschwert wird.

Beantwortet„Kann eine Mitarbeiterin die Beschwerde über sich selbst lesen?“
03Betroffenenanträge als Abläufe

Auskunftsanträge tragen ihre gesetzliche Frist. Berichtigungsanträge fügen eine Fassung hinzu, statt zu überschreiben. Einschränkungsanträge versiegeln die erfassten Dokumente.

Beantwortet„Zeigen Sie mir einen Auskunftsantrag von Anfang bis Ende“
04Offenlegungsregister

Was den Dienst verlassen hat, an wen und auf welcher Rechtsgrundlage. Das ist der Nachweis, von dem eine Person in den Vereinigten Staaten sechs Jahre verlangen darf.

Beantwortet„Mit wem haben Sie die Daten dieser Person geteilt?“
05Aufbewahrungsanker

Letzter Kontakt, Geburtsdatum und Sterbedatum werden als Daten gespeichert, ab denen gerechnet wird — denn eine in Jahren geschriebene Regel ist ohne Ausgangspunkt bedeutungslos.

Beantwortet„Woher wissen Sie, wann das zu vernichten ist?“
06Nachfassen über den Zustand, nie über den Inhalt

Überfällige Sitzungsberichte werden über ihre Frist und ihren Zustand gefunden. Die Leitung kann sehen, dass ein Bericht fehlt, ohne einen vorhandenen zu öffnen.

Beantwortet„Liest die Leitung fachliche Notizen, um die Praxis zu führen?“
07Identitäts- und Altersprüfung

Zuerst eine automatische Gesichtsprüfung, dann bei Bedarf eine Prüfliste für Menschen. Die Ausweisdokumente sind verschlüsselt, solange sie vorgehalten werden, und werden nach Abschluss der Prüfung automatisch gelöscht.

Beantwortet„Was geschieht danach mit dem Ausweisdokument?“
08Elektronische Signatur im Behandlungskontext

Bestätigung der Einwilligungsfähigkeit, Unterschrift stellvertretend für eine Klientin, Gegenzeichnung durch die Supervision und eine Einwilligung, die sich später widerrufen lässt, statt eines einmaligen Häkchens.

Beantwortet„Wie wird die Einwilligung erfasst, und lässt sie sich widerrufen?“
09Das Unterschreiben bleibt im Haus

Der Signaturdienst läuft auf Ihren eigenen Servern, mit eigener hash-verketteter Spur. Kein Dokument geht zum Unterschreiben an ein fremdes Unternehmen, und es gibt keine Anbieterrechnung je Unterschrift.

Beantwortet„Welche Dritten sehen unsere unterschriebenen Dokumente?“
10 — Wenn etwas schiefgeht

Zwei Fristen aus einem Moment, und eine Ausnahme, die man sich verdienen muss

Die Verschlüsselung hat weitgehend wegen dieses Abschnitts die Form, die sie hat. DSGVO und HIPAA erkennen beide an, dass ordentlich verschlüsselte Daten unlesbar und damit keine echte Offenlegung sind. Diese Ausnahme hält aber nur, wenn Sie zeigen können, dass die Schlüssel nicht mit entwendet wurden. Der ganze Entwurf der Schlüsselverwahrung gibt es, damit Sie es zeigen können.

Die Kenntnis

Beide Fristen unten beginnen mit dem Moment Ihrer Kenntnis, nicht mit dem Moment des Vorfalls. Diesen Moment festzustellen und festzuhalten ist deshalb das Erste, was Sie tun, und nicht etwas, das später rekonstruiert wird.

Die Aufsicht unterrichten

Artikel 33 DSGVO gibt Ihnen 72 Stunden ab Kenntnis, um die Aufsichtsbehörde zu unterrichten — das ICO im Vereinigten Königreich, die zuständige nationale Behörde in der Europäischen Union. Diese Frist gilt, ob die Daten verschlüsselt waren oder nicht.

Die betroffenen Personen unterrichten

Artikel 34 verlangt, auch die Betroffenen zu unterrichten, es sei denn, die Daten waren verschlüsselt. Artikel 34 Abs. 3 lit. a behandelt ordentlich verschlüsselte Daten als unlesbar für den, der sie entwendet hat. HIPAA kennt denselben Gedanken und nennt ihn safe harbour.

Wurden auch die Schlüssel entwendet?

Die Ausnahme hängt vollständig an dieser einen Frage — das System stellt sie deshalb ausdrücklich, und eine unbeantwortete Frage wirkt gegen die Ausnahme. Eine Verletzung als nicht meldepflichtig zu schließen verlangt den Nachweis — denn eine ohne Nachweis beanspruchte Ausnahme bricht zusammen, sobald sie geprüft wird.

Ein gemeinsamer Verletzungsdatensatz, und darüber die Regeln jedes Landes

Der Verletzungsdatensatz selbst liegt im gemeinsamen Kern: wann Sie Kenntnis erlangten, was betroffen war, wer betroffen war, ob die Daten verschlüsselt waren und ob die Schlüssel entwendet wurden. Jedes Rechtsraummodul legt dann seine eigenen Pflichten auf diesen einen Datensatz. Das europäische Modul fügt die 72-Stunden-Frist des Artikels 33 und die Entscheidung nach Artikel 34 hinzu. Das US-Modul fügt die Vier-Faktoren-Risikoprüfung hinzu, die 60-Tage-Frist gegenüber Einzelnen, die Presseschwelle oberhalb von 500 Einwohnerinnen eines Bundesstaats und die Meldung an das Department of Health and Human Services. Ein Vorfall, einmal geprüft, gegen die Regeln, die für Sie gelten.

Das Zugriffsprotokoll ist die Untersuchung

Weil jeder Lesezugriff protokolliert wurde, bevor Inhalt herausgegeben wurde, hat die Frage „Was war tatsächlich offengelegt, und gegenüber wem?“ eine echte Antwort statt einer Schätzung. Das ist der Unterschied zwischen elf Menschen zu benachrichtigen und allen in der Datenbank.

11 — Kontrollen der Plattform

Die gewöhnlichen Fragen, an einer Stelle beantwortet

Nichts in dieser Tabelle ist ungewöhnlich. Sie steht hier, weil eine Prüferin danach fragen wird — und weil ein Anbieter, der diese Fragen nicht schnell beantworten kann, die schwierigeren meist auch nicht beantworten kann.

BereichWas vorhanden istWarum es so gemacht wird
AnmeldungPasswörter nur als Einwegprüfsummen gespeichert. Kurzlebige signierte Tokens, die tragen, wer die Person ist, wann das Token ausgestellt wurde, wann es abläuft, und eine eindeutige KennungEin gestohlenes Token läuft von selbst ab, und das Prüfsummenverfahren lässt sich verbessern, ohne dass jemand sein Passwort zurücksetzen muss
Verwahrung von GeheimnissenJede Zugangsdatei Dritter liegt auf dem Server. Die mobile App trägt nur öffentliche SchlüsselDie App lässt sich dekompilieren, und nichts geht verloren. Ein gewechselter Schlüssel wirkt für alle auf einmal, ohne neue Version im App-Store
ÜbertragungHTTPS überall, auch für den WebSocket für Chat, Anwesenheit und GesprächssignalisierungEine Verbindung, eine Regel, und kein Rückfall auf Klartext
RatenbegrenzungGrenzen am Proxy, dazu Redis-Zähler auf öffentlichen Wegen und bei Dokumentzugriffen im PortalAus gemeinsam genutztem Zustand gezählt — eine Grenze je Person hält also über jeden Serverprozess hinweg und nicht je Prozess
MedienÜber das Gateway vermittelt, mit signierten Links, die ablaufen. Nichts wird von einem erratbaren Pfad ausgeliefertDer Speicher wird von einem Endgerät nie unmittelbar angesprochen
DatenbankVon keinem Endgerät erreichbar. Das Gateway verbindet sich über eine Dienstkennung mit dem Kern, die nur die nötigen Rechte hatZwei getrennte Schritte zwischen einem Telefon und einer Zeile, und jeder kann für sich verweigern
Öffentliche FormularereCAPTCHA auf den Formularen der Website, und Telefonnummern werden bei der Eingabe normiertSpam und fehlerhafte Eingaben werden abgewiesen, bevor daraus Datensätze werden, die jemand aufräumen muss
Kennungen erratenEin Dokument, das Sie nicht sehen dürfen, liefert „nicht gefunden“ und nie „verboten“Sonst verrät der Unterschied zwischen beiden Antworten einem Angreifer, welche Akten es gibt
Konten der KlientelPortalnutzende haben überhaupt keinen Zugang zum Backoffice. Die Zwei-Faktor-Anmeldung kommt mit der Plattform und lässt sich mit einer Einstellung für alle Mitarbeitenden oder für alle verpflichtend machen — und der Dokumentzugriff im Portal lässt sich dahinter legenDer schlimmste Fall bei einer kompromittierten Klientenanmeldung sind die eigenen Daten dieser einen Klientin — und mit eingeschalteter Portalsperre nicht einmal das
Aussetzung gegenüber DrittenZahlungen, künstliche Intelligenz, Nachrichten und Speicher sitzen jeweils hinter einer Schnittstelle, auf deren anderer Seite ein Schalter eine Attrappe bereithältAnbieter lassen sich tauschen. Vorführungen und Tests laufen ohne ein einziges echtes Anbieterkonto und ohne echte Daten
Lizenz und BetriebOdoo 19 Community und durchgehend quelloffene Bestandteile, betrieben auf Ihrer eigenen InfrastrukturIhr eigenes Sicherheitsteam kann den Code lesen, statt einem Anbieter zu glauben
12 — Was Sie belegen können

Der Unterschied zwischen einer Kontrolle und einem Versprechen

In einer Prüfung, einer Ausschreibung oder einer Beschwerde zählt nicht, was Sie beabsichtigt haben. Es zählt, was Sie vorführen können. Unten stehen die sechs Fragen, die am häufigsten kommen, und was das System auf jede hin hervorbringt.

Wer hat diese Akte gelesen?Zugriffsprotokoll
Eine vollständige, hash-verkettete Liste, die niemand hätte ändern können — auch Ihre eigene Verwaltung nicht
Wurde diese Akte verändert?Fassungshistorie
Korrekturen sind neue Fassungen und die frühere bleibt unversehrt — eine Änderung ist also sichtbar und nichts, was man erschließen muss
Wurden abgelaufene Daten vernichtet?Vernichtung des Schlüssels
Der Schlüssel ist fort, und die leere Hülle belegt, dass die Akte bestand und fristgerecht vernichtet wurde
Mit wem haben wir sie geteilt?Offenlegungsregister
Was den Dienst verlassen hat, an wen und auf welcher Rechtsgrundlage — sechs Jahre davon, auf Verlangen
Hätte die Verwaltung sie sehen können?Berechtigungsmodell
Im Zweifel verschlossen, ohne Generalschlüssel. Ein Verwaltungskonto gewährt nichts, und der Notzugriff ist ein protokolliertes, geprüftes Ereignis
Ist das Journal vertrauenswürdig?Finanzkontrollen
Gestellte Rechnungen lassen sich nicht ändern, Honorarzeilen tragen die Vertragsfassung, die sie bepreist hat, und nichts wird ohne die Bestätigung eines Menschen abgerechnet
13 — Wo die Software aufhört

Was keine Plattform für Sie tun kann

Software macht eine Organisation nicht rechtskonform. Sie macht Rechtskonformität erreichbar und belegbar. Über diese Grenze klar zu sein ist in einer Prüfung mehr wert als eine längere Liste von Behauptungen — hier also die Grenze in voller Länge.

Das ist keine Rechtsberatung, und kein Produkt ist zertifiziert

Nichts auf dieser Seite ist Rechtsberatung. Kein Softwareprodukt ist HIPAA- oder DSGVO-zertifiziert, denn keine Behörde stellt diese Zertifikate für Produkte aus. Was es gibt, ist ein Satz technischer und organisatorischer Maßnahmen. Diese Plattform setzt die technischen um und unterstützt die organisatorischen. Der Rest gehört Ihrer Organisation, und eine gute Beratung wird Ihnen genau dasselbe sagen.

  • Die Verträge unterschreiben Sie. Business-Associate-Vereinbarungen in den Vereinigten Staaten, Auftragsverarbeitungsverträge und Bedingungen für Unterauftragnehmer in der EU und im Vereinigten Königreich. Die Plattform bildet sie ab. Sie schließt sie nicht für Sie.
  • Ihre Rechtsberatung bestätigt den Wortlaut. Der Hinweis auf das Weitergabeverbot nach 42 CFR Part 2 wird erzeugt und nicht getippt, gerade damit er über die Zeit nicht abdriftet. Die Vorschrift schreibt seinen Inhalt aber vor, und er braucht eine rechtliche Prüfung vor dem Start.
  • Örtliches Recht geht über die Grundlinie hinaus. Gesetze der US-Bundesstaaten — der kalifornische CMIA und unter anderem Regeln in New York und Texas — gehen über HIPAA hinaus. In der EU kommt das Recht der Mitgliedstaaten zur DSGVO hinzu: Der deutsche § 203 StGB und § 630f BGB sind Beispiele. Vor allem die Aufbewahrungsfristen müssen mit einer Rechtsberatung für Ihr eigenes Land bestätigt werden.
  • Das Verhalten der Mitarbeitenden ist keine Kontrolle der Software. Schulung, Ein- und Austritte, das Dienstrecht und überhaupt die Frage, wer ein Behandlungsverhältnis bekommt, sind Entscheidungen, die das System festhält und nicht trifft.
  • Die physische Sicherheit und die der Infrastruktur gehört den Betreibenden. Wo die Server stehen, wer an sie herantreten kann, wie Sicherungen verschlüsselt und außer Haus verwahrt werden, wie der Hauptschlüssel gehalten wird — und der Notfalltest, den Sie tatsächlich durchführen, nicht der, der im Plan steht.
  • Penetrationstests und der Umgang mit Schwachstellen sind ein Programm und keine Funktion. Die ganze Landschaft ist quelloffen und selbst betrieben, damit Ihr eigenes Team oder Ihre eigenen Prüfenden sie richtig untersuchen können. Das ist eine Einladung und kein Ersatz.
  • NHS-nahe Organisationen füllen das Data Security and Protection Toolkit aus. Diese Bewertung betrifft Ihre Organisation und ihre Menschen und liegt außerhalb der Reichweite jeder Software.
  • Jemand muss die Aufbewahrungsmaschine im Blick behalten. Aufbewahrung und Vernichtung laufen als geplante Läufe. Ein geplanter Lauf, der still stehen bleibt, ist ein Compliance-Problem, das erst in einer Prüfung auftaucht — deshalb steht die Kontrolle auf der monatlichen Runde.
Die ganze Seite in einem Absatz, für eine Prüferin in Eile

Behandlungsunterlagen werden Fassung für Fassung verschlüsselt, unter Schlüsseln, die außerhalb der Datenbank liegen. Sie öffnen sich nur, wenn eine ausdrückliche Regel es erlaubt, und diese Regel folgt dem Behandlungsverhältnis und nicht dem Dienstgrad. Jeder Lesezugriff wird in ein Protokoll geschrieben, das niemand ändern kann. Korrekturen kommen als neue Fassungen hinzu, statt die alte zu überschreiben. Läuft die Aufbewahrung ab, wird der Schlüssel vernichtet: Der Inhalt wird unlesbar, und der Nachweis, dass er bestand und vernichtet wurde, bleibt. Über diesem gemeinsamen Kern fügt ein Rechtsraummodul die Rechte- und Governance-Maschinerie für die Vereinigten Staaten, die Europäische Union oder das Vereinigte Königreich hinzu. Darunter schützt das vierschichtige Zugriffsmodell von Odoo Community die gewöhnlichen Geschäftsdaten, und der Server ist hinter einem einzigen Proxy mit TLS, einer Firewall und Ratenbegrenzungen geschlossen.

14 — Wohin als Nächstes

Das übrige Bild

Diese Seite ist die Position zu Sicherheit und Compliance. Der Systemüberblick zeigt, wie die Teile zusammenpassen, der Katalog listet die Module, in denen diese Kontrollen tatsächlich liegen, und der Bauplan der Verwaltung beschreibt die Routine, die all diese Nachweise Monat für Monat wahr hält.