Claves
- Separar los roles (quién es alguien) de los permisos (lo que exige una acción).
- Añadir los ámbitos (sede, departamento, propiedad) como segunda dimensión.
- Comprobar el acceso en el servidor en cada petición; la interfaz solo oculta lo que no está permitido.
- Registrar cada cambio de rol y cada acceso sensible.
El control de acceso suele empezar con un indicador de «admin» y acabar en una maraña de casos especiales. Una estructura de roles, permisos y ámbitos que sigue siendo comprensible a medida que crece la organización.
Cómo se degrada el control de acceso
La mayoría de los sistemas empiezan con dos tipos de usuario: administradores y todos los demás. Con el crecimiento llegan las excepciones: un responsable que puede aprobar pero no borrar, una sucursal que solo debe ver sus propios registros, un auditor que puede leerlo todo y no cambiar nada. Cada excepción se convierte en una condición en el código, y pronto nadie sabe con certeza quién puede hacer qué.
Roles y permisos son cosas distintas
Defina los permisos como las acciones que admite su sistema: crear una factura, aprobar un permiso, exportar un informe. Defina los roles como conjuntos con nombre de permisos que corresponden a funciones reales. El código comprueba permisos, nunca nombres de roles.
Esta sola regla abarata los cambios. Cuando aparece una función nueva, crea un rol con permisos existentes en lugar de modificar el código en decenas de sitios.
El ámbito como segunda dimensión
Los permisos responden a «¿puede esta persona aprobar un permiso?». Los ámbitos responden a «¿para quién?». En un sistema hospitalario, un jefe de servicio solo aprueba para su servicio; en un colegio con varias sedes, el director solo ve su centro.
- Ámbito organizativo: empresa, región, sucursal, departamento.
- Ámbito de propiedad: registros que el usuario creó o tiene asignados.
- Ámbito de relación: las familias solo ven los datos de sus propios hijos.
Aplicarlo en el servidor, siempre
Ocultar un botón es una medida de usabilidad, no un control de seguridad. Cada petición a la API debe comprobar el permiso y el ámbito en el servidor, idealmente en una capa común para que ningún endpoint pueda olvidarlo. Cuando la base de datos lo admite, las políticas a nivel de fila añaden una red de seguridad adicional.
Hacer el acceso auditable
Registre cada cambio de roles y asignaciones y cada acceso a registros sensibles. Cuando un cliente, un auditor o un regulador pregunte quién podía ver qué y cuándo, la respuesta debe salir de una consulta, no de la memoria de alguien.
¿Le ha gustado? Reciba el próximo por correo.