Respuesta.

Historia de la pregunta:

Con el aumento de usuarios y módulos en los sistemas de TI, la distribución de roles y la definición de permisos se ha convertido en una tarea crítica. Los errores en el diseño de un esquema de acceso conducen a vulnerabilidades, funciones que no funcionan y riesgos de filtración de datos.

Problema:

La falta de una metodología única para construir la matriz de permisos, la falta de coherencia entre diferentes módulos y la descripción incorrecta de los escenarios de acceso conllevan inconvenientes para los usuarios y conflictos, y a veces incluso consecuencias legales.

Solución:

Se aplica el método de matriz de acceso (access matrix), donde para cada módulo del sistema se describen los roles (Control de Acceso Basado en Roles, RBAC), tipos de operaciones y los correspondientes escenarios de uso. Se documenta:

Lista de roles con su descripción: administrador, operador, usuario, invitado, etc.
Lista de operaciones (CRUD, lanzamiento de procesos, exportación de datos, etc.) disponibles para cada rol
Restricciones y excepciones para casos especiales
Ejemplos de escenarios de usuario: quién y cuándo hace qué, cuáles son los resultados

Todo esto se documenta en una tabla resumen de “roles y permisos”, generalmente utilizando hojas de cálculo, constructores de esquemas o mediante diagramas UML especializados (por ejemplo, diagrama de casos de uso).

Características clave:

Formalización de roles independientemente de la estructura organizativa
Verificación de la coherencia entre módulos
Desarrollo no solo de la concesión, sino también de la revocación/cambio de permisos

Preguntas capciosas.

¿Es suficiente describir solo los roles básicos (admin, usuario) para todo el sistema?

No, es necesario detallar los roles a nivel de tareas y módulos, de lo contrario, aparecerán zonas grises y brechas en la seguridad.

¿Se pueden construir los permisos de acceso únicamente a partir de la estructura organizativa existente?

No, la estructura organizativa cambia rápidamente, mientras que los procesos de negocio tienen una vida más larga. Se deben identificar los roles basándose en los escenarios de negocio y áreas de responsabilidad.

¿Es necesario documentar solo los permisos de acceso permitidos?

No, es obligatorio describir no solo los permisos, sino también las prohibiciones (deny rules), así como prever procedimientos de escalada y concesión temporal de permisos.

Errores típicos y anti-patrones

Un esquema de permisos “plano” en todo el sistema, falta de detalle a nivel de módulos
Transferencia de la jerarquía organizativa al ámbito de TI sin tener en cuenta las particularidades
Documentación solo de permisos positivos (permitidos) sin escenarios de revocación o acceso temporal

Ejemplo de la vida real

Caso negativo:

En un gran sistema CRM, todos los permisos estaban descritos solo a nivel de dos roles básicos. En la práctica, surgieron muchos conflictos: los gerentes ordinarios eliminaban accidentalmente datos importantes, y los operadores no tenían acceso a sus funciones.

Ventajas:

Simplificación de la puesta en marcha

Desventajas:

Aumento de riesgos de acceso a datos críticos, número elevado de errores debido a la falta de coherencia

Caso positivo:

El analista dividió los permisos por roles y módulos, realizó un taller de diseño con los usuarios, describió los casos de delegación y revocación de permisos. Creó una matriz de acceso resumida, alineó las plantillas del recorrido del usuario para diferentes tipos de empleados.