Planificar los permisos del portal con una matriz
Una matriz completa para dos empresas y tres roles vincula tareas permitidas, alcance de los datos y comprobaciones concretas.
«El cliente ha iniciado sesión» no determina qué documentos puede leer ni qué pedidos puede crear. Un plan de permisos relaciona a la persona, la acción solicitada y el alcance de los datos afectados.
El siguiente portal es completamente hipotético. Sus empresas C10 y C20, roles y comprobaciones describen un diseño, no una prueba de seguridad realizada.
De las tareas a la matriz
En el ejemplo, los lectores consultan documentos de su empresa, quienes realizan pedidos también pueden pedir y los administradores de cada empresa cliente gestionan las cuentas de su empresa. El rol de administrador de empresa no es automáticamente superior: aquí no tiene permiso para pedir.
Empresa | Rol | Leer documentos de su empresa | Pedir para su empresa | Gestionar cuentas de su empresa | Otra empresa |
|---|---|---|---|---|---|
| Lector | Sí | No | No | Sin acceso |
| Responsable de pedidos | Sí | Sí | No | Sin acceso |
| Administrador de empresa | Sí | No | Sí | Sin acceso |
| Lector | Sí | No | No | Sin acceso |
| Responsable de pedidos | Sí | Sí | No | Sin acceso |
| Administrador de empresa | Sí | No | Sí | Sin acceso |
Esta asignación es una decisión de ejemplo. Si los administradores de empresa necesitan pedir, la asignación adicional debe planificarse y probarse expresamente. También hay que definir qué roles de empresa pueden asignar. De ello no se derivan permisos sobre toda la plataforma.
Aplicar el límite al objeto
Ocultar un menú no impide solicitar directamente un documento. El servidor debe comprobar si la persona puede actuar por la empresa seleccionada y si el documento concreto pertenece al alcance permitido. El identificador de empresa enviado por el navegador es una selección, no una prueba de pertenencia.
La comprobación no se limita al detalle. Las listas, las exportaciones y las operaciones de escritura necesitan la misma limitación adecuada. Este diseño no concede acceso a combinaciones sin permiso explícito.
Probar los caminos permitidos y denegados
La matriz permite definir resultados esperados antes de implementar:
Un lector puede abrir un documento de su empresa; crear un pedido con ese rol se rechaza.
Un administrador de
C10no recibe documentos deC20, ni siquiera por la dirección directa.La gestión autorizada modifica solo cuentas de su empresa y asigna únicamente los roles previstos.
Tras retirar una pertenencia o un permiso, la acción protegida sigue bloqueada incluso con una sesión abierta anteriormente.
Pruebe los casos permitidos y los rechazados. Una aplicación que bloquea todo no cumple la matriz. Registre roles, asignación de datos y resultado esperado para la versión probada.
La matriz aclara una parte de las reglas. No sustituye su implementación técnica ni una evaluación completa de seguridad. Los cambios de roles, recorridos de datos o pertenencias deben incorporarse al plan y sus comprobaciones.
Fuentes
Escrito por
- Nora HenningRedactora de seguridad informáticaNora Henning se encarga en ASES de los contenidos editoriales sobre seguridad informática. Escribe sobre la seguridad de las aplicaciones y explica la relación entre los derechos de acceso y la protección de los datos de la empresa.
Seguir leyendo
Todos los artículos
Desarrollo de software con ASES
Software a medida, aplicaciones web y móviles