Definir primero el resultado
El acceso empieza por una pregunta de negocio: quién puede hacer qué sobre qué registro y bajo qué condiciones. Una lista de roles no basta. Identifique acciones, límites de propiedad y autoridad excepcional. Leer, editar, exportar y conceder acceso son poderes distintos.
Elegir el enfoque
Roles simples pueden servir para una aplicación interna pequeña. Propiedad del registro, empresa o estado del proceso pueden exigir comprobaciones adicionales. No cree un rol para cada combinación si pocos atributos explican mejor la regla. OWASP recomienda denegar por defecto y verificar permisos en cada petición; ocultar botones no controla el acceso.
Conciliar un caso concreto
En un portal ficticio, el gestor lee pedidos de su empresa y finanzas descarga facturas. Pruebe cada acción con identificadores de otra empresa, enlaces directos y resultados de búsqueda. Retire después la membresía de alguien con el navegador abierto. La petición protegida siguiente debe aplicar la nueva decisión, no la pantalla cargada antes.
Conservar pruebas útiles
No dé acceso irrestricto permanente al soporte por comodidad. Si necesita una excepción, defina motivo, duración y registro. Examine exportaciones, tareas en segundo plano y credenciales de integración como las pantallas. La matriz de permisos debe convertirse en comprobaciones ejecutables y pruebas negativas.
Construir la matriz con acciones y límites
Ponga acciones en filas y roles en columnas, con límite del registro. Leer solo pedidos de la organización asignada es parte del permiso, no una nota. Incluya búsqueda, descarga, exportación, procesos de fondo y concesión de acceso. Proteger edición y olvidar exportación puede exponer los mismos datos.
Recorra el ciclo de autoridad: invitar, verificar empresa, cambiar rol y retirar. Decida cambios que necesitan otra persona y caducidad de emergencia. Separe operar el negocio y administrar la aplicación. Aprobar compras no exige gestionar autenticación ni ver otras organizaciones. Limite identidades de integración a sus tareas, con propietario y revocación.
Convierta la matriz en casos permitidos y denegados. Pruebe registro válido, otra organización con el mismo rol, membresía revocada y petición que evita la pantalla. Repita para lotes y cola, pues los permisos pueden cambiar. Conserve prueba de quién autorizó sin copiar todo el contenido personal. Pida investigar un rechazo con esa evidencia. Debe proteger el límite y orientar al usuario legítimo sin revelar registros ajenos.
Casos de aceptación de permisos
| Caso | Límite esperado |
|---|---|
| Mismo rol, otra organización | No concede acceso a registros, búsquedas ni adjuntos ajenos. |
| Membresía revocada con sesión abierta | La siguiente acción usa autoridad actual, no el control renderizado antes. |
| Intento de elevarse a sí mismo | Se aplica aprobación configurada y queda rastro sin conceder poder silencioso. |
| Exportación en cola tras cambios | Ejecuta política acordada, sin distribuir datos solo porque existió una selección antigua. |
Preguntas para el responsable
¿Quién concede y revoca? ¿Puede alguien aprobar su propia elevación? ¿Qué registros se separan incluso con el mismo rol? Lleve una matriz rol-acción-registro y ejemplos denegados. Discutir lo prohibido importa tanto como lo permitido.
Fuentes y otras lecturas
Software a medida
Software que sigue la forma de trabajar de tu negocio.
Hablemos de este servicio