Gestión de permisos en aplicaciones empresariales: cómo diseñar roles y accesos

La gestión de permisos en aplicaciones empresariales debe decidir tres cosas para cada operación: quién puede realizarla, sobre qué datos puede hacerlo y en qué condiciones. No basta con que una persona haya iniciado sesión ni con ocultarle un botón: la aplicación debe comprobar la autorización en el servidor o la API que ejecuta cada acción protegida.

El objetivo es aplicar el principio de mínimo privilegio: cada usuario, proceso o integración recibe solo el acceso necesario para trabajar. Ese límite afecta tanto a los datos visibles como a las operaciones permitidas: consultar, crear, editar, eliminar, exportar, aprobar, configurar o administrar usuarios.

Qué debe resolver realmente un sistema de permisos

Conviene separar conceptos que a menudo se mezclan:

• Autenticación: verifica quién es el usuario.
• Autorización: determina qué puede hacer ese usuario una vez identificado.
• Usuario o grupo: la persona, cuenta de servicio o conjunto de personas al que se asigna acceso.
• Rol: una función organizativa, como consulta, ventas, operaciones o administración. Son ejemplos hipotéticos, no una plantilla universal.
• Permiso: una capacidad concreta, como aprobar un descuento o exportar una lista.
• Recurso y alcance: el tipo de dato y el conjunto específico al que puede accederse: todos los clientes, los de una zona, los de un centro o los asignados a una cartera.

Una política adecuada parte de la denegación por defecto: si no existe una regla explícita que permita una acción, la aplicación debe rechazarla. Este enfoque reduce el riesgo de que una pantalla, un recurso nuevo o un endpoint queden accesibles por una configuración incompleta.

El problema de dar demasiado acceso por comodidad

Un único perfil de administrador suele parecer práctico al principio. Con el tiempo, concentra funciones que no corresponden a todos los usuarios y dificulta saber quién necesita realmente cada capacidad. Algo parecido ocurre al conceder permisos persona a persona: cada excepción añade mantenimiento y complica las revisiones posteriores.

Un diseño de permisos debe prevenir dos situaciones distintas:

• Elevación vertical de privilegios: un usuario normal intenta ejecutar una función reservada a administración o a un rol de mayor nivel.
• Elevación horizontal de privilegios: un usuario accede a registros de otra persona pese a tener un nivel funcional similar. Por ejemplo, consultar o modificar una oportunidad que pertenece a otra cartera.

Ocultar una opción de menú mejora la experiencia de uso, pero no es un control de acceso suficiente. Si la API acepta la operación sin validar la identidad, el permiso y el alcance del registro solicitado, alguien podría intentar invocar directamente el endpoint o modificar el identificador de un recurso para acceder a otro registro. El identificador, aunque no sea predecible, no sustituye esa comprobación de autorización.

También conviene vigilar los permisos heredados tras un cambio de puesto, las cuentas inactivas y los accesos concedidos como excepción que nunca se revisan.

Cómo diseñar roles y permisos paso a paso

1. Haz un inventario de los datos, módulos y acciones. Lista los recursos que maneja la aplicación y las operaciones posibles. Distingue especialmente acciones con impacto: eliminar, exportar, aprobar, publicar, modificar configuraciones o gestionar usuarios.
2. Identifica funciones reales. Habla con las áreas implicadas antes de crear roles. El nombre del departamento no siempre describe bien las responsabilidades dentro de un proceso.
3. Asigna capacidades generales a roles. Usa los roles para agrupar permisos que se repiten. Evita asignaciones directas a usuarios salvo cuando exista una excepción justificada y documentada.
4. Define el alcance de los datos. La pregunta no es solo si una persona puede editar clientes, sino cuáles. El límite puede depender, por ejemplo, del centro, la zona, el departamento, el propietario del registro o el estado del proceso.
5. Documenta las excepciones. Registra qué acceso especial se concede, quién lo aprueba, por qué se necesita y cuándo o bajo qué condición debe revisarse.
6. Prueba accesos permitidos y denegados. Incluye casos de usuarios con el rol correcto pero sin acceso a un registro ajeno, peticiones directas a la API y modificaciones de identificadores de recursos.

Ejemplo hipotético de matriz de permisos

La siguiente tabla ilustra cómo separar rol, operación, recurso y alcance. Los roles y reglas son únicamente un ejemplo: cada empresa debe partir de su proceso real.

Esta matriz no sustituye las comprobaciones técnicas. Aunque una persona tenga permiso para editar oportunidades, la aplicación debe validar en cada operación que el registro concreto está dentro de su alcance.

RBAC, ABAC o un enfoque híbrido

RBAC asigna permisos a roles y después vincula esos roles a usuarios o grupos. Puede resultar útil cuando las responsabilidades son relativamente estables y es fácil expresarlas mediante funciones de la organización.

ABAC decide el acceso a partir de atributos del sujeto, del recurso, de la operación y, cuando corresponde, del contexto. Puede encajar cuando una regla depende de variables como departamento, ubicación, propietario del registro, estado del proceso o franja horaria.

En muchas aplicaciones internas tiene sentido un enfoque híbrido. El rol concede la capacidad general y los atributos delimitan el alcance. Por ejemplo, un rol comercial podría permitir editar oportunidades, mientras que una regla adicional limita la edición a las oportunidades de la zona o cartera asignada.

Ninguno de estos modelos garantiza la seguridad por sí solo. Su utilidad depende de que las reglas reflejen el proceso real, se implementen en los puntos correctos y se revisen con el tiempo.

Controles que deben existir en la aplicación

• Autorización en servidor o API: cada solicitud relevante debe validarse donde realmente se ejecuta la operación, no solo en la interfaz.
• Denegación por defecto: una capacidad no declarada expresamente no debe quedar disponible.
• Comprobación del recurso concreto: además del permiso funcional, valida que el usuario puede actuar sobre ese registro específico según su alcance.
• Registro de cambios: conserva trazabilidad sobre altas, bajas, activaciones, desactivaciones, roles asignados y cambios de políticas.
• Separación de funciones: en operaciones sensibles, evita que una sola persona pueda iniciar, aprobar y cerrar todo el proceso sin supervisión. Puede ser relevante, por ejemplo, en compras, pagos, descuentos o publicación de información.
• Controles adicionales para acciones de mayor riesgo: según el caso, puede ser razonable exigir una segunda aprobación, autenticación reforzada, un privilegio temporal o caducidad del acceso.
• Permisos mínimos para integraciones: una aplicación conectada o una cuenta de servicio tampoco debería recibir más acceso del estrictamente necesario.

Cuando la aplicación trata datos personales, el artículo 32 del RGPD exige aplicar medidas técnicas y organizativas apropiadas al riesgo, incluido el riesgo de acceso no autorizado, pérdida, alteración o divulgación. No impone un modelo único de permisos; la decisión debe analizarse según los datos, la operativa y las obligaciones que apliquen. Este criterio es contexto general y no sustituye una revisión jurídica o de cumplimiento aplicable a cada empresa.

El ciclo de vida de los permisos

Un buen diseño se deteriora si no contempla qué sucede cuando una persona entra, cambia de función, se ausenta, deja la empresa o necesita un acceso excepcional. Define responsables para cada fase y evita que el acceso dependa solo de peticiones informales.

• En el alta, asigna el acceso base asociado a la función real.
• Ante un cambio de puesto, revisa tanto los nuevos permisos como los que deben retirarse.
• En una baja o suspensión, desactiva o elimina los accesos conforme al procedimiento interno.
• Realiza revisiones periódicas de roles, privilegios, cuentas inactivas y excepciones. La frecuencia debe adaptarse al riesgo, a los datos tratados y a la operativa; no existe una periodicidad válida para todas las empresas.

Negocio, tecnología y seguridad deberían tener responsabilidades diferenciadas: el área responsable del proceso puede validar qué acceso es necesario; el equipo técnico puede implementar y probar las reglas; y seguridad o privacidad deben participar cuando el riesgo o los datos lo requieran.

¿Basta una herramienta estándar o hacen falta reglas a medida?

Una función estándar puede ser suficiente si permite gestionar grupos y roles, permisos por operación, alcance de datos, auditoría y un ciclo coherente de altas, cambios y bajas. Antes de descartarla, comprueba si puede expresar las reglas que el negocio necesita y si esas reglas se pueden revisar y probar.

Puede ser necesaria una aplicación o integración a medida cuando el acceso depende de relaciones entre registros, estados de negocio, datos procedentes de varios sistemas o excepciones complejas. Por ejemplo, si una persona solo puede aprobar un dato cuando no lo ha creado, si el registro pertenece a una combinación concreta de centro y cartera, o si el permiso cambia con una fase del proceso.

Una solución a medida no es automáticamente más segura. Tiene sentido cuando permite expresar las reglas necesarias de forma mantenible y con controles verificables. Para aplicaciones que gestionen nóminas, salud, información financiera, datos de clientes o categorías especiales de datos, conviene contar con profesionales de seguridad, privacidad y cumplimiento antes de modificar los accesos.

Lista de comprobación antes de ponerlo en producción

• ¿Cada usuario dispone únicamente de las operaciones y datos necesarios?
• ¿El acceso se rechaza si no existe una regla explícita que lo permita?
• ¿La API o el servidor valida autorización y alcance en cada operación protegida?
• ¿Se han probado intentos de acceso a funciones de mayor privilegio y a registros ajenos?
• ¿Las operaciones sensibles tienen una separación de funciones adecuada?
• ¿Están definidos el alta, los cambios de puesto, las bajas y la revisión de excepciones?
• ¿Quedan registrados los cambios de cuentas, roles, permisos y políticas?
• ¿Las integraciones tienen solo los permisos necesarios?
• ¿Se ha evaluado el riesgo de los datos personales y la normativa sectorial aplicable?

¿Qué es lo importante?

El criterio principal no es tener muchos roles, sino poder demostrar que cada usuario e integración accede únicamente a las operaciones y registros que necesita. Una herramienta estándar puede bastar si cubre roles, alcance de datos, auditoría y ciclo de vida de los accesos. Si las reglas dependen de relaciones entre registros, estados del proceso o excepciones difíciles de mantener, puede ser necesario diseñar reglas específicas o una aplicación adaptada.