Tout système d'information doit gérer le contrôle d'accès, et le développement de plateformes rend le choix du bon modèle de sécurité encore plus crucial. La question est toujours de savoir comment minimiser les compromis.
Un sous-système de contrôle d'accès doit répondre à la question suivante :
Un certain agent peut-il effectuer des opérations spécifiques dans un système?
Il est parfois commode d'élargir cette question :
Un certain agent peut-il effectuer des opérations spécifiques sur des ressources spécifiques?
Il existe deux modèles populaires : RBAC (Contrôle d'accès basé sur les rôles) et ACL (liste de contrôle d'accès). Ces modèles se situent à deux pôles opposés : le RBAC associe les permissions à l'agent, tandis que l'ACL associe les règles d'accès à la ressource.
Ainsi, si vous pouvez qualifier votre système de « centré sur l'utilisateur » ou de « centré sur la ressource », vous pouvez choisir le modèle approprié. Ces deux modèles nécessitent quelques « astuces » pour fonctionner à l'autre pôle. Les modèles « centrés sur l'utilisateur » ont besoin de modificateurs de permissions « magiques » pour traiter les décisions d'accès liées aux propriétés et aux relations des ressources. On peut ainsi voir des permissions avec des modificateurs de propriété comme « modifier mes billets », etc. Les règles plus complexes de ce type sont souvent simplement « codées en dur ». D'autres anomalies sont les concepts virtuels d'agent « anonyme » ou « tous », utilisés pour définir des règles d'accès lorsque l'agent est inconnu, sans importance ou abstrait. Pour les modèles « centrés sur la ressource », il n'est pas toujours évident de déterminer quel est le sujet (ressource) des opérations. Par exemple, quelle est la ressource pour les opérations de création ou de recherche?
Bien qu'ils fonctionnent assez bien dans certains domaines, aucun de ces deux modèles ne peut être utilisé pour produire un modèle de contrôle d'accès générique. Il ne nous reste qu'une seule option : placer l'opération au centre du modèle. Nous pouvons introduire le concept de politique, qui définit l'accès au niveau de l'opération. Une politique décrit quels agents (c'est-à-dire quelles identités) sont autorisés ou non à effectuer des opérations spécifiques sur des ressources spécifiques dans certaines conditions. Toutes les parties d'une politique peuvent être optionnelles ou abstraites. Une politique peut être associée à un agent, à une ressource, ou aux deux. Lorsque nous attachons une politique à un agent, nous pouvons construire un système de type RBAC. Une politique sur une ressource fonctionne comme une ACL. Nous pouvons également modéliser une solution hybride, dans laquelle, pour contrôler l'accès, nous évaluons conjointement la politique de l'agent et celle de la ressource. Cette approche peut résoudre des cas particuliers tels que « un médecin peut consulter tous les patients » et « une célébrité ne doit être visible que par son médecin traitant principal ».
Améliorer le contrôle d'accès FHIR : aperçus vidéo et compte-rendu de la rencontre
Visionnez la vidéo de notre récente rencontre sur le contrôle d'accès FHIR®, dans laquelle nous explorons les subtilités des modèles de contrôle d'accès pour les serveurs FHIR. Et ne manquez pas notre compte-rendu détaillé de l'événement, qui couvre les principales discussions sur les politiques de confidentialité, les nuances d'autorisation et les stratégies innovantes de contrôle d'accès présentées par John Moehrke, Josh Mandel, Mohammad Jafari et Mike Kulakov.
Détails d'implémentation
Health Samurai travaille sur un serveur FHIR générique. La norme FHIR ne définit aucun modèle de contrôle d'accès, mais propose quelques fonctionnalités utiles pour renforcer la sécurité, telles que : les étiquettes de sécurité, les ressources AuditEvent et Provenance, la signature numérique et les recommandations OAuth 2. La plateforme SMART définit un ensemble de portées OAuth, mais elle est trop étroitement axée sur son scénario principal — fournir une interface aux systèmes DSE existants — et délègue la plupart des décisions aux systèmes d'information sous-jacents. Si nous considérons un serveur FHIR REST comme une plateforme permettant de créer des applications de santé de toutes pièces, nous devons fournir un sous-système de contrôle d'accès qui rend possible la création de différents types d'applications : des portails patients et des bus d'intégration jusqu'aux solutions DSE complètes.
Nous estimons que le contrôle d'accès par politique est suffisamment flexible pour nos besoins. Ce modèle a été appliqué avec succès dans des systèmes réels — Amazon S3, par exemple. La prochaine étape consiste à concevoir une implémentation possible des politiques.
Politique déclarative
Parfois, une politique est si complexe qu'elle nécessite la puissance d'une machine de Turing ainsi que l'accès à toutes les données du système et au contexte de l'opération pour prendre une décision d'accès. Il est assez pratique de représenter le contrôle d'accès comme une fonction intercepteur/filtre, à laquelle sont transmis des informations sur l'agent et la session, toutes les données du système et les détails de l'opération en tant que paramètres, et qui retourne vrai ou faux :
if accessControl(agentInfo, systemData, operationData) then allow else deny
Dans notre plateforme FHIR, vous pouvez fournir une fonction JavaScript comme politique, qui sera appelée avec l'objet de requête et aura accès à toute la base de données pour contrôler l'accès. La seule limitation est que cette fonction ne peut pas appeler de services externes. Pour gérer les situations où vous avez besoin de cette information, vous pouvez l'obtenir d'une autre façon au préalable et l'injecter dans les données de la requête.
Pour rendre la politique plus déclarative, nous devons structurer et contraindre les paramètres et, idéalement, transformer la politique en une fonction pure (c'est-à-dire que le résultat de cette fonction ne dépend que de ses paramètres). Nous pouvons alors représenter le contrôle d'accès comme une fonction générique :
accessControl(request, policy)
qui accepte une requête et une définition de politique, et fournit la réponse.
Schéma JSON comme politique
Puisque nous parlons principalement d'une API REST, nous pouvons représenter une requête comme une requête HTTP sous forme de structure de données JSON (comme le font de nombreux cadriciels Web) :
{ url: "/patient/", method: "POST", headers: {...} body: {resourceType: 'Patient', ….} agent: {....} }
La plupart des moteurs de politique utilisent des DSL personnalisés pour décrire les politiques, mais nous pouvons tirer parti du format de schéma JSON existant, qui dispose de nombreuses implémentations, est bien documenté et familier aux développeurs. Ainsi, une politique peut être définie comme un schéma JSON, et la fonction de validation de schéma peut être utilisée comme fonction générique de contrôle d'accès.
Illustrons cette idée avec quelques exemples :
{ title: 'Read Access to everything', type: 'Object', properties: {method: {enum: ["GET"}}
Ou nous pouvons contraindre l'URL par une expression régulière :
{ title: "Read Patient", properties: { method: {enum: ["GET"]}, url: {type: "string", pattern: "/patient/.*"} }}
Si nous encodons la chaîne de requête sous forme d'objet de paramètres, nous pouvons même contraindre les paramètres de recherche :
{ title: "Only search by name and fetch less then 100 items", properties: { params: { properties: { name: {type: "string"}, _limit: {type: 'integer', maximum: 100} }, additionalProperties: false } }}
Pour les opérations de création et de mise à jour, si nous disposons d'une requête avec un corps JSON, nous pouvons imposer des exigences spécifiques sur la ressource. Par exemple, autoriser les ressources POST uniquement avec des profils spécifiques.
Pour rendre les énoncés de politique plus expressifs, la première option consiste à enrichir l'objet de requête avec des informations supplémentaires (c'est-à-dire la localisation, le contexte de l'agent, le contexte de la session; même la réponse ou la ressource associée peuvent être ajoutées). La spécification du schéma JSON est assez expressive, et la v5, avec de nombreuses fonctionnalités supplémentaires, est en cours de développement. Pour les exigences spécifiques à FHIR et à la sécurité qui pourraient ne pas correspondre au schéma JSON, cette spécification prend en charge les extensions.
Nous sommes actuellement en phase active de conception et d'implémentation, et tout retour d'information et toute participation sont grandement appréciés.
Nous espérons qu'à l'avenir, la norme FHIR pourra inclure une spécification de contrôle d'accès basé sur des politiques et favoriser l'interopérabilité dans ce domaine également.
Démarrez avec le serveur FHIR Aidbox pour le stockage de données, les intégrations, l'analytique de santé, et plus encore, ou engagez notre équipe pour soutenir vos besoins en développement de logiciels.
Voir aussi : Introspection de jetons dans FHIR.
