Jedes Informationssystem befasst sich mit Zugriffskontrolle, während die Entwicklung von Plattformen die Wahl des richtigen Sicherheitsmodells noch wichtiger macht. Es stellt sich immer die Frage, wie Kompromisse minimiert werden können.
Ein Zugriffskontroll-Subsystem sollte folgende Frage beantworten:
Kann ein bestimmter Agent bestimmte Operationen in einem System ausführen?
Manchmal ist es sinnvoll, diese Frage zu erweitern:
Kann ein bestimmter Agent bestimmte Operationen an bestimmten Ressourcen ausführen?
Es gibt zwei verbreitete Modelle: RBAC (rollenbasierte Zugriffskontrolle) und ACL (Access Control List). Diese Modelle befinden sich an zwei entgegengesetzten Polen: RBAC weist Berechtigungen dem Agenten zu, während ACL Zugriffsregeln mit der Ressource verknüpft.
Wenn Sie Ihr System als „benutzerzentriert" oder „ressourcenzentriert" einordnen können, wählen Sie das jeweils passende Modell. Beide erfordern gewisse „Tricks", um auch am jeweils anderen Pol zu funktionieren. „Benutzerzentrierte" Modelle benötigen „magische" Berechtigungsmodifikatoren, um Zugriffsentscheidungen zu treffen, die sich auf Ressourceneigenschaften und -beziehungen beziehen. Sie kennen möglicherweise Berechtigungen mit Eigentumsmodifikatoren wie „eigene Beiträge bearbeiten" usw. Kompliziertere Regeln dieser Art sind häufig schlicht „hartcodiert". Weitere Anomalien sind die virtuellen Agenten-Konzepte „anonym" oder „alle", die verwendet werden, um Zugriffsregeln zu definieren, wenn der Agent unbekannt, unwichtig oder abstrahiert ist. Bei „ressourcenzentrierten" Modellen ist es nicht immer offensichtlich, was das Subjekt (die Ressource) von Operationen ist. Was ist beispielsweise die Ressource bei Erstellungs- oder Suchoperationen?
Obwohl beide Modelle in bestimmten Bereichen gut funktionieren, eignen sie sich nicht zur Erstellung eines generischen Zugriffskontrollmodells. Es bleibt nur eine Option: die Operation in den Mittelpunkt des Modells zu stellen. Wir können das Konzept einer Policy einführen, die den Zugriff auf Operationsebene definiert. Eine Policy beschreibt, welchen Agenten (d. h. Identitäten) es erlaubt oder untersagt ist, bestimmte Operationen an bestimmten Ressourcen unter bestimmten Bedingungen durchzuführen. Alle Bestandteile einer Policy können optional oder abstrakt sein. Eine Policy kann einem Agenten, einer Ressource oder beiden zugeordnet werden. Wenn wir eine Policy einem Agenten zuordnen, können wir ein RBAC-ähnliches System aufbauen. Eine Policy auf einer Ressource funktioniert wie eine ACL. Wir könnten auch eine hybride Lösung modellieren, bei der zur Zugriffskontrolle sowohl die Agenten-Policy als auch die Ressourcen-Policy gemeinsam ausgewertet werden. Dieser Ansatz kann Sonderfälle lösen wie: „Ein Arzt darf alle Patienten einsehen" und „Eine prominente Person darf nur für ihren Hausarzt sichtbar sein".
FHIR-Zugriffskontrolle verbessern: Video-Einblicke und Meetup-Rückblick
Sehen Sie sich das Video von unserem kürzlich stattgefundenen FHIR® Access Control Meetup an, in dem wir uns eingehend mit den Feinheiten von Zugriffskontrollmodellen für FHIR-Server befassen. Außerdem empfehlen wir Ihnen unseren ausführlichen Rückblick auf die Veranstaltung, der die wichtigsten Diskussionen über Datenschutzrichtlinien, Autorisierungsdetails und innovative Zugriffskontrollstrategien von John Moehrke, Josh Mandel, Mohammad Jafari und Mike Kulakov zusammenfasst.
Implementierungsdetails
Health Samurai arbeitet an einem generischen FHIR-Server. Der FHIR-Standard definiert kein Zugriffskontrollmodell, sondern lediglich einige hilfreiche Funktionen für die Sicherheit, wie z. B.: Security Labels, AuditEvent- und Provenance-Ressourcen, digitale Signaturen sowie OAuth-2-Empfehlungen. Die SMART-Plattform definiert einen Satz von OAuth-Scopes, ist jedoch zu stark auf ihr primäres Szenario ausgerichtet – die Bereitstellung einer Schnittstelle zu bestehenden EHR-Systemen – und delegiert die meisten Entscheidungen an die darunterliegenden Informationssysteme. Wenn wir einen FHIR-REST-Server als Plattform betrachten, um Gesundheitsanwendungen von Grund auf neu zu entwickeln, müssen wir ein Zugriffskontroll-Subsystem bereitstellen, das den Aufbau verschiedener Anwendungstypen ermöglicht: von Patientenportalen und Integrationsbussen bis hin zu vollständigen EHR-Lösungen.
Wir sind der Ansicht, dass Zugriffskontrolle mittels Policy für unsere Zwecke flexibel genug ist. Es gibt erfolgreiche Anwendungen dieses Modells in realen Systemen – zum Beispiel Amazon S3. Der nächste Schritt besteht darin, eine mögliche Implementierung von Policies zu entwerfen.
Deklarative Policy
Manchmal ist eine Policy so komplex, dass sie die Leistungsfähigkeit einer Turing-Maschine sowie Zugriff auf alle Systemdaten und den Operationskontext erfordert, um eine Zugriffsentscheidung zu treffen. Es ist recht praktisch, Zugriffskontrolle als Interceptor-/Filterfunktion darzustellen, der Informationen über den Agenten und die Sitzung, alle Systemdaten sowie Operationsdetails als Parameter übergeben werden und die „wahr" oder „falsch" zurückgibt:
if accessControl(agentInfo, systemData, operationData) then allow else deny
In unserer FHIR-Plattform können Sie eine JavaScript-Funktion als Policy bereitstellen, die mit dem Request-Objekt aufgerufen wird und Zugriff auf die gesamte Datenbank zur Zugriffskontrolle hat. Die einzige Einschränkung besteht darin, dass diese Funktion keine externen Dienste aufrufen kann. Um Situationen zu bewältigen, in denen Sie diese Informationen benötigen, können Sie diese vorab auf anderem Wege beziehen und in die Request-Daten einfügen.
Um eine Policy deklarativer zu gestalten, müssen wir die Parameter formen und einschränken und die Policy idealerweise in eine reine Funktion (Pure Function) überführen (d. h. das Ergebnis dieser Funktion sollte ausschließlich von den Parametern abhängen). Dann können wir Zugriffskontrolle als generische Funktion darstellen:
accessControl(request, policy)
die eine Anfrage und eine Policy-Definition entgegennimmt und eine Antwort liefert.
JSON-Schema als Policy
Da wir hauptsächlich über REST-APIs sprechen, können wir eine Anfrage wie einen HTTP-Request als JSON-Datenstruktur darstellen (wie es viele Web-Frameworks tun):
{ url: "/patient/", method: "POST", headers: {...} body: {resourceType: 'Patient', ….} agent: {....} }
Die meisten Policy-Engines verwenden benutzerdefinierte DSLs zur Beschreibung von Policies, aber wir können das vorhandene JSON-Schema-Format nutzen, das viele Implementierungen besitzt, gut dokumentiert und Entwicklern vertraut ist. Eine Policy kann also als JSON-Schema definiert werden, und die Schema-Validierungsfunktion kann als generische accessControl-Funktion verwendet werden.
Lassen Sie uns diese Idee anhand einiger Beispiele veranschaulichen:
{ title: 'Read Access to everything', type: 'Object', properties: {method: {enum: ["GET"}}
Oder wir können die URL durch einen regulären Ausdruck einschränken:
{ title: "Read Patient", properties: { method: {enum: ["GET"]}, url: {type: "string", pattern: "/patient/.*"} }}
Wenn wir den Query-String als Parameterobjekt kodieren, können wir sogar Suchparameter einschränken:
{ title: "Only search by name and fetch less then 100 items", properties: { params: { properties: { name: {type: "string"}, _limit: {type: 'integer', maximum: 100} }, additionalProperties: false } }}
Für Erstellungs- und Aktualisierungsoperationen können wir bei Anfragen mit JSON-Body spezifische Anforderungen an die Ressource stellen. So lässt sich beispielsweise das Erstellen (POST) von Ressourcen nur mit bestimmten Profilen erlauben.
Um Policy-Aussagen ausdrucksstärker zu gestalten, besteht die erste Möglichkeit darin, das Request-Objekt mit zusätzlichen Informationen anzureichern (z. B. Standort, Agenten-Kontext, Sitzungskontext – sogar die Antwort oder eine verwandte Ressource können hinzugefügt werden). Die JSON-Schema-Spezifikation ist recht ausdrucksstark, und v5 mit vielen zusätzlichen Funktionen ist in Vorbereitung. Für FHIR- und sicherheitsspezifische Anforderungen, die möglicherweise nicht in das JSON-Schema passen, unterstützt diese Spezifikation Erweiterungen.
Wir befinden uns derzeit in einer aktiven Design- und Implementierungsphase, und jedes Feedback sowie jede Mitarbeit sind sehr willkommen.
Wir hoffen, dass der FHIR-Standard künftig eine Policy-basierte Zugriffskontrollspezifikation umfassen und damit auch in diesem Bereich Interoperabilität fördern wird.
Starten Sie mit dem Aidbox FHIR-Server für Datenspeicherung, Integrationen, Gesundheitsanalytik und mehr, oder beauftragen Sie unser Team zur Unterstützung Ihrer Softwareentwicklung.
Siehe auch: Token Introspection in FHIR.
