--- { "title": "Elección del modelo de control de acceso para un servidor FHIR genérico", "description": "Garantizar la seguridad de los datos sanitarios es una prioridad absoluta para cualquier sistema de información de salud. Esto es lo que debe tener en cuenta al gestionar el control de acceso para su servidor FHIR.", "date": "2016-01-16", "author": "Nikolai Ryzhikov", "reading-time": "5 min read", "tags": [ "System Design", "Compliance" ], "seo-tags": [ "Fhir", "Access Control Security" ] } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- Todo sistema de información debe gestionar el control de acceso, y el desarrollo de plataformas hace que la elección del modelo de seguridad adecuado sea aún más crítica. Siempre surge la pregunta de cómo minimizar los compromisos. Un subsistema de control de acceso debe responder a la siguiente pregunta: > *¿Puede algún* ***agente*** *realizar* *operaciones* *específicas en un sistema?* En ocasiones resulta conveniente ampliar esta pregunta: > *¿Puede algún* ***agente*** *realizar* ***operaciones*** *específicas sobre* *recursos* *específicos?* Existen dos modelos populares: **RBAC** ([Control de Acceso Basado en Roles](/blog/implementing-role-based-access-control-for-fhir-resources-with-keycloak-and-smart-on-fhir-v2)) y **ACL** (Lista de Control de Acceso). Estos modelos se sitúan en dos polos opuestos: RBAC asocia los permisos al **agente**, mientras que ACL asocia las reglas de acceso al **recurso**. Por tanto, si puede clasificar su sistema como «centrado en el usuario» o «centrado en el recurso», podrá elegir el modelo más adecuado. Ambos requieren ciertos «ajustes» para funcionar en el polo contrario. Los modelos «centrados en el usuario» necesitan modificadores de permiso «mágicos» para gestionar las decisiones de acceso relacionadas con las propiedades y relaciones de los recursos. Es posible encontrar permisos con modificadores de propiedad como **«editar mis publicaciones»**, etc. Las reglas más complejas de este tipo suelen estar simplemente «codificadas de forma fija». Otras anomalías son los conceptos virtuales de agente **«anónimo»** o **«todos»**, que se utilizan para definir reglas de acceso cuando el agente es desconocido, no relevante o abstracto. En los modelos «centrados en el recurso», no siempre resulta obvio cuál es el sujeto (recurso) de las operaciones. Por ejemplo, ¿cuál es el recurso en las operaciones de creación o búsqueda? Aunque ambos modelos funcionan bien en determinados ámbitos, ninguno puede utilizarse para producir un modelo de control de acceso genérico. Solo nos queda una opción: situar la **operación** en el centro del modelo. Podemos introducir el concepto de **política**, que define el acceso a nivel de operación. Una política describe qué agentes (es decir, qué identidades) tienen permiso o no para realizar operaciones específicas sobre recursos específicos bajo determinadas condiciones. Todas las partes de una política pueden ser opcionales o abstractas. Una política puede asociarse a un agente, a un recurso o a ambos. Al asociar una política a un agente, podemos construir un sistema similar a RBAC. Una política sobre un recurso funciona como una ACL. También podemos modelar una solución híbrida en la que, para controlar el acceso, se evalúen conjuntamente la política del agente y la del recurso. Este enfoque puede resolver casos límite como «el médico puede ver a todos los pacientes» y «una celebridad solo debe ser visible para su médico de cabecera». {% embed url="https://youtu.be/OgvXEmAcjm4" %} ## Mejora del control de acceso en FHIR: perspectivas en vídeo y resumen del meetup Vea el vídeo de nuestro reciente FHIR® Access Control Meetup, en el que profundizamos en los entresijos de los modelos de control de acceso para [servidores FHIR](https://www.health-samurai.io/fhir-server). Además, no se pierda [nuestro resumen detallado](https://www.health-samurai.io/news/fhir-access-control-meetup-recap) del evento, que cubre los debates clave sobre políticas de privacidad, matices de autorización y estrategias innovadoras de control de acceso de la mano de John Moehrke, Josh Mandel, Mohammad Jafari y Mike Kulakov. ## Detalles de implementación Health Samurai trabaja en un [servidor FHIR](https://www.health-samurai.io/fhir-server) genérico. El estándar FHIR no define ningún modelo de control de acceso, solo algunas funcionalidades útiles para construir la seguridad, como: etiquetas de seguridad, recursos AuditEvent y Provenance, firma digital y recomendaciones sobre OAuth 2. La plataforma SMART define un conjunto de ámbitos OAuth, pero está demasiado centrada en su escenario principal —proporcionar una interfaz a los sistemas EHR existentes— y delega la mayoría de las decisiones en los sistemas de información subyacentes. Si consideramos el servidor FHIR REST como una plataforma para construir aplicaciones sanitarias desde cero, necesitamos proporcionar un subsistema de control de acceso que permita desarrollar distintos tipos de aplicaciones: desde portales de pacientes y buses de integración hasta soluciones EHR completas. Consideramos que el control de acceso mediante **políticas** es suficientemente flexible para nuestros propósitos. Existen aplicaciones exitosas de este modelo en sistemas reales —Amazon S3, por ejemplo—. El siguiente paso es diseñar una posible implementación de las políticas. ## Política declarativa En ocasiones, una política es tan compleja que requiere la potencia de una máquina de Turing y acceso a todos los datos del sistema y al contexto de la operación para tomar una decisión de acceso. Resulta bastante conveniente representar el control de acceso como una función interceptora/filtro, a la que se le pasan como parámetros la información sobre el agente y la sesión, todos los datos del sistema y los detalles de la operación, y que devuelve verdadero o falso: **if** accessControl(agentInfo, systemData, operationData) **then** allow **else** deny En nuestra plataforma FHIR, es posible proporcionar una función JavaScript como política, que será invocada con el objeto de la solicitud y tiene acceso a toda la base de datos para controlar el acceso. La única limitación es que dicha función no puede llamar a servicios externos. Para gestionar las situaciones en las que se necesita esta información, puede obtenerse de antemano e incluirse en los datos de la solicitud. Para hacer la política más declarativa, debemos dar forma y restringir los parámetros y, idealmente, convertir la política en una función pura (es decir, el resultado de esta función debe depender únicamente de los parámetros). De este modo, podemos representar el control de acceso como una función genérica: accessControl(request, policy) que acepta la solicitud y la definición de la política y proporciona la respuesta. ## JSON schema como política Dado que hablamos principalmente de API REST, podemos representar la solicitud como una solicitud HTTP en forma de estructura de datos JSON (como hacen muchos frameworks web): { **url**: "/patient/", **method**: "POST", **headers**: {...} **body**: {resourceType: 'Patient', ….} **agent**: {....} } La mayoría de los motores de políticas utilizan DSL personalizados para describir las políticas, pero podemos aprovechar el formato JSON schema ya existente, que cuenta con numerosas implementaciones, está bien documentado y resulta familiar para los desarrolladores. Así, una política puede definirse como un JSON schema, y la función de validación del esquema puede utilizarse como función genérica de accessControl. Ilustremos esta idea con algunos ejemplos: { **title**: 'Read Access to everything', **type**: 'Object', **properties**: {**method**: {**enum**: ["GET"}} O podemos restringir la URL mediante una expresión regular: { **title**: "Read Patient", **properties**: { **method**: {**enum**: ["GET"]}, **url**: {**type**: "string", **pattern**: "/patient/.*"} }} Si codificamos la cadena de consulta como un objeto de parámetros, podemos incluso restringir los parámetros de búsqueda: { **title**: "Only search by name and fetch less then 100 items", **properties**: { **params**: { **properties**: { **name**: {**type**: "string"}, **_limit**: {**type**: 'integer', **maximum**: 100} }, **additionalProperties**: false } }} Para las operaciones de creación y actualización, si disponemos de una solicitud con cuerpo JSON, podemos imponer requisitos específicos sobre el recurso. Por ejemplo, permitir recursos POST solo con perfiles específicos. Para que las declaraciones de política sean más expresivas, la primera opción es poblar el objeto de solicitud con información adicional (es decir, ubicación, contexto del agente, contexto de la sesión; incluso la respuesta o el recurso relacionado pueden añadirse). La especificación JSON schema es bastante expresiva y la versión **v5**, con muchas funcionalidades adicionales, está en camino. Para los requisitos específicos de FHIR y de seguridad que puedan no encajar en JSON schema, esta especificación admite extensiones. Actualmente nos encontramos en una fase activa de diseño e implementación, y cualquier comentario y participación son muy bienvenidos. Esperamos que en el futuro el estándar FHIR incluya una especificación de control de acceso basado en políticas y aporte interoperabilidad también en este ámbito. > Comience a utilizar el [servidor FHIR](https://www.health-samurai.io/aidbox) de Aidbox para almacenamiento de datos, integraciones, analítica sanitaria y más, o [contrate a nuestro equipo](https://www.health-samurai.io/services) para dar soporte a sus necesidades de desarrollo de software. [![Aidbox FHIR Platform Free Trial](image-1.avif)](https://www.health-samurai.io/aidbox) Véase también: [Introspección de tokens en FHIR](/blog/token-introspection-in-fhir).