Compartir a través de


Diseñar roles de forma eficaz

En muchos escenarios, la seguridad basada en roles es un mecanismo muy eficaz, pero hay situaciones en las que es menos eficaz. Debe tener en cuenta varios factores al decidir dónde y cómo aplicar la seguridad basada en roles a una aplicación determinada.

Características de usuario y datos y idoneidad de los roles

Los roles funcionan muy bien para caracterizar grupos de usuarios y, sobre esa base, filtrar qué acciones pueden realizar esos usuarios. A menudo, esto se lleva a cabo en la práctica mediante la creación de roles que reflejan el lugar de un usuario dentro de una organización, por ejemplo, los roles "Administradores" y "Tellers", "Administradores" y "Lectores", "Project One Employees" y "Project Two Employees". En tales casos, cuando los datos a los que se accede es bastante genérico con respecto a los usuarios, los roles se pueden usar de forma eficaz para aplicar reglas de negocios como las siguientes:

  • "Los gerentes pueden transferir cualquier cantidad de dinero. Los tellers solo pueden transferir hasta $10.000".

  • "Los administradores pueden cambiar cualquier cosa. Todos los demás solo pueden leer".

  • "Los empleados de Project One pueden acceder a una determinada base de datos. Nadie más puede."

Los usuarios pueden caer naturalmente en varios roles, en función de cómo modele los roles la estructura organizativa de una empresa.

Sin embargo, los roles no funcionan muy bien cuando una decisión de acceso de seguridad se basa en las características de un fragmento de datos determinado. Por ejemplo, sería difícil usar roles para reflejar relaciones complicadas de datos de usuario, como las siguientes:

  • "Un administrador determinado puede acceder a los datos del personal solo para sus informes".

  • "Joe Consumer puede buscar su saldo de cuenta".

En tales casos, la comprobación de seguridad debe realizarse a menudo en la propia base de datos, donde es más fácil tener en cuenta las características innatos de los datos a los que se accede. Esto significa que debe usar la suplantación para pasar la identidad de cliente a la base de datos y permitir que la base de datos valide la solicitud. Esto puede afectar al rendimiento y puede afectar al diseño de la aplicación; por ejemplo, la agrupación de conexiones podría no funcionar cuando se abre una conexión en una identidad de usuario determinada. Para obtener una explicación de los problemas implicados, consulte Multi-Tier Application Security and Client Impersonation and Delegation.

Complejidad y escalabilidad de una directiva de autorización de Role-Based

Cualquier directiva de seguridad que haya implementado será tan eficaz como su implementación por parte de los administradores del sistema que implemente la aplicación. Si los administradores cometen errores al asignar usuarios a los roles correctos según la directiva de seguridad, la directiva no funcionará según lo previsto. Es más probable que se produzcan problemas en las siguientes circunstancias:

  • Ha creado una directiva basada en roles muy compleja, con muchos roles y usuarios que se asignan a numerosos roles.
  • Los roles se crean con criterios ambiguos para los que deben pertenecer a ellos.
  • Hay muchos usuarios en el sitio donde se instala la aplicación y los usuarios se mueven con frecuencia dentro de la organización, cambiando con respecto a los roles que ha creado.
  • Hay muchos administradores en el sitio donde se instala la aplicación, con división de responsabilidades, para que un administrador familiarizado con los requisitos de seguridad de la aplicación no esté familiarizado con los grandes grupos de usuarios que deben usarlo. Esto es de particular preocupación a medida que los usuarios se mueven dentro de la organización; esta información debe comunicarse bien.

Además, a medida que aumenta el número de roles asignados a una aplicación, por lo que la cantidad de tiempo que COM+ debe dedicar a buscar la pertenencia del autor de la llamada en esos roles, con una posible degradación del rendimiento.

Para administrar la complejidad y mitigar estos problemas, puede usar las siguientes directrices:

  • Elija los nombres de rol que sean autodescriptivas. Haga que sea lo más obvio posible qué usuarios deben pertenecer a qué roles.
  • Haga que la directiva basada en roles sea lo más sencilla posible (y no sea más sencilla). Elija los pocos roles que pueda, a la vez que mantiene una directiva eficaz.
  • Documente claramente la directiva basada en roles que construye para los administradores, si la pertenencia a roles es obvia (para usted). En concreto, use el campo de descripción disponible para cada rol para describir la intención del rol. Si no puede describir generalmente quién debe pertenecer al rol en un par de oraciones, es probable que sea demasiado complicado.
  • Sugiera encarecidamente que los administradores de la aplicación rellenen roles con grupos de usuarios en lugar de usuarios individuales. Se trata de una solución mucho más escalable. Facilita la reasignación o eliminación de usuarios a medida que se mueven dentro de la organización y aíslan a los administradores de una determinada cantidad de supervisión y problemas en la comunicación.

Límites de seguridad

Información de contexto de llamada de seguridad

Security Context (propiedad)

Uso de roles para la autorización de cliente