Control de acceso basado en roles + permisos basados en propiedad de datos

Esta es una muy buena pregunta y se ha identificado como uno de los problemas con RBAC. Ha habido una línea de investigación sobre roles parametrizados (el pdf se puede encontrar en línea) , y más recientemente, surgió la idea del control de acceso basado en relaciones (ver el trabajo de P. Fong et al, por ejemplo este ). Aunque no estoy seguro de cuánto se ha implementado.

Puede configurar un producto moderno de seguridad multinivel (MLS) para solucionar el problema. Estos sistemas están diseñados para la protección de datos de grado militar en infraestructura compartida. Normalmente, los sistemas utilizan Control de acceso basado en roles (RBAC), Control de acceso discrecional (DAC) y Control de acceso obligatorio (MAC) basados en etiquetas de seguridad.

Las etiquetas de seguridad abordan el elemento que falta. En un sistema MLS, todos los objetos tienen una etiqueta para incluir datos y procesos. Las etiquetas proporcionan el esquema para abordar su médico y la situación específica del grupo.

Aquí hay una configuración de ejemplo. El conjunto de etiquetas maestras (conocido como codificaciones del sistema) incluye un esquema de etiquetas que tiene grupos individuales para todos los grupos de médicos en cuestión. La aplicación utilizada por todos los médicos podría estar limitada por el control RBAC que mencionó. Cada médico también tendría su etiqueta de seguridad única en su perfil de cuenta y, por lo tanto, solo podría acceder a los datos definidos por esa etiqueta.

La configuración inicial es un trabajo pesado, pero obtiene muchas otras funciones útiles en su caso, como controlar qué documento se imprime en qué impresora (piense que los límites de hardware son similares a los límites de grupos de médicos).

La página de Wikipedia para MLS proporciona proveedores (cuando no está en apagón de SOPA). El producto Trusted Extensions de Oracle tuvo algunos buenos ejemplos de casos de uso comercial en línea según su pregunta.

Hay un patrón similar que usa Exchange 2010; donde el modelo de acceso está limitado mediante la propiedad "Ámbito" que se aplica a la capa de enlace. En esta implementación, el alcance es la "relación" entre el usuario autenticado y la unidad organizativa en la que se encuentra el "paciente".

Exchange 2010 tiene un modelo de delegación donde los grupos de winrm Los cmdlets de Powershell se agrupan esencialmente en roles, y los roles asignados a un usuario.

( fuente de imagen )

Esto es un gran & Modelo flexible considerando cómo puedo aprovechar todos los beneficios de PowerShell, mientras uso las tecnologías de bajo nivel correctas (WCF, SOAP, etc.) y no requiere software adicional en el lado del cliente.

( Fuente de imagen )

Este es un diseño de aplicación muy moderno, y estoy intentando imitarlo yo mismo. Tengo una pregunta similar sobre StackOverflow aquí

Me doy cuenta de que esta pregunta tiene casi 4 años. Las respuestas, especialmente la dada por userxxxxx, son excelentes.

Desde entonces, un nuevo paradigma de control de acceso ha madurado y aborda las deficiencias de RBAC. Se llama control de acceso basado en atributos (ABAC) y le permite expresar relaciones utilizando estos atributos dentro de las políticas. El lenguaje de la política se basa en un estándar llamado XACML (eXtensible Access Control Markup Language).

Si revisamos el escenario del OP

  

Bob es un médico y tiene la función de privilegio 'ver, detalles del paciente'

     

Bob es un miembro del grupo 'A'.

     

Bob puede ver todos los detalles de pacientes para pacientes asignados al grupo 'A'

La forma en que se reescribiría en ABAC es:

  

Un usuario con el rol == médico puede hacer la acción == ver en un objeto de tipo == detalles del paciente si el grupo asignado del paciente está en la lista de grupos del médico.

Al utilizar ALFA como notación, obtienes

namespace healthcare{
    policyset viewMedicalRecords{
        target clause actionId == "view" and object.nature == "patient details"
        apply firstApplicable       
        policy doctors{
            target clause user.role=="doctor"
            apply firstApplicable
            rule allowSameGroup{
                permit
                condition patient.group == doctor.group
            }
        }       
    }
}

Puede leer más sobre ABAC en el sitio web de NIST (National Institute of Science & Tech). Ellos son los que también definieron RBAC.