Seguridad y calidad
Identidad, permisos y auditoría
Se puede responder en cualquier momento quién tiene acceso a qué datos, por qué motivo y quién se lo concedió.
Cuando una aplicación crece, los permisos suelen crecer a golpe de excepción: un usuario que necesitaba ver un informe acaba con acceso de administrador porque era lo más rápido. Con el tiempo nadie sabe quién puede hacer qué, y retirar un acceso da miedo por si algo deja de funcionar. Diseñar la identidad y los permisos desde el principio evita ese desorden. Se decide cómo se autentican las personas, qué roles existen, cuándo un permiso depende de atributos como el centro o el proyecto, cómo se aíslan los datos de distintas organizaciones y qué acciones deben quedar registradas. Es un trabajo poco visible que condiciona la confianza en todo lo demás, y que se acuerda con quien responde de los datos.
- Entrada de datos
- Proveedor de identidad corporativo
- Altas y bajas de recursos humanos
- Validación
- Segundo factor según riesgo
- Organización y atributos del usuario
- Procesamiento
- Roles combinados con atributos
- Filtro en la capa de datos
- Control humano
- Aprobación de accesos elevados
- Campañas de revisión de permisos
- Trazas
- Accesos a datos sensibles
- Cambios de permisos y su aprobador
- Sistemas de salida
- Acceso concedido o denegado
- Informe de revisión de accesos
Antes y después
Qué cambiaría en la operación
Ejemplo hipotético: una red de clínicas que comparte una aplicación de citas e historiales administrativos entre sus distintos centros.
01 · Antes
Muchos usuarios tienen perfil de administrador por comodidad, las bajas se retiran tarde y no hay forma de saber quién consultó la ficha de un paciente.
02 · Sistema propuesto
Inicio de sesión con las cuentas corporativas, roles reducidos combinados con el centro como atributo, filtro en el servidor y permisos elevados con caducidad.
03 · Después
Cada centro ve solo sus fichas, los accesos temporales vencen solos y la revisión periódica muestra qué permisos confirmó o retiró cada responsable.
Alcance
Qué resuelve y qué no
Qué puede resolver
- Definir roles y permisos que reflejen funciones reales, con el mínimo acceso necesario para cada una.
- Aplicar reglas por atributos cuando el rol no basta: ver solo los expedientes del propio centro, proyecto o cliente.
- Separar datos entre organizaciones, filiales o clientes que comparten la misma plataforma.
- Integrar el inicio de sesión con el directorio corporativo y activar un segundo factor donde el riesgo lo justifique.
- Registrar accesos, cambios de permisos y operaciones sensibles en una traza consultable.
Qué no resuelve
- No hace que una organización cumpla por sí misma una normativa de protección de datos o de seguridad; el software aporta controles y evidencias, y la evaluación corresponde a sus responsables.
- No sustituye la revisión periódica de accesos: si nadie retira permisos a quien cambia de puesto, el modelo se degrada.
- No protege frente a credenciales compartidas o contraseñas débiles si la organización no establece y hace cumplir sus políticas.
Escenarios operativos
Cómo funcionaría en la práctica
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Plataforma compartida por varias empresas del grupo
- Entrada
- Usuarios de distintas sociedades, cada uno vinculado a su organización y a uno o varios roles.
- Procesamiento
- Cada consulta se filtra por la organización del usuario en la capa de datos, no solo en la interfaz, y los roles transversales se conceden de forma explícita y registrada.
- Salida
- Cada sociedad ve únicamente sus datos, con una lista auditable de las personas que tienen acceso a más de una.
02
Permisos por proyecto en una ingeniería
- Entrada
- Directorio de empleados, asignaciones a proyectos y clasificación de la documentación por confidencialidad.
- Procesamiento
- Las reglas combinan el rol con la asignación al proyecto y el nivel de la documentación para decidir lectura, edición o descarga.
- Salida
- Acceso concedido o denegado de forma coherente y registro de cada descarga de documentos clasificados.
03
Solicitud y aprobación de un acceso elevado
- Entrada
- Petición de un usuario para obtener un permiso temporal con justificación y duración.
- Procesamiento
- La solicitud pasa por el responsable del área y, si procede, por el propietario de los datos; el permiso se concede con caducidad automática.
- Salida
- Permiso activo durante el tiempo autorizado, retirada automática al vencer y traza completa de la aprobación.
04
Revisión periódica de accesos
- Entrada
- Listado de usuarios, roles, últimos accesos y cambios de puesto comunicados por recursos humanos.
- Procesamiento
- Se genera una campaña de revisión en la que cada responsable confirma o retira los permisos de su equipo; las cuentas inactivas se marcan.
- Salida
- Informe de la revisión con permisos retirados, cuentas desactivadas y decisiones registradas por responsable.
Integración
Cómo se conecta con lo que ya existe
Lo habitual es no crear otro almacén de contraseñas, sino delegar la autenticación en el proveedor de identidad que ya usa la organización mediante protocolos estándar de inicio de sesión federado. La aplicación conserva la autorización: qué puede hacer cada identidad dentro de ella. Se define cómo llegan las altas y bajas, cómo se sincronizan grupos o atributos y dónde se guarda la traza de auditoría para que no pueda alterarse desde la propia aplicación.
- Inicio de sesión federado con el proveedor de identidad corporativo
- Segundo factor de autenticación según el riesgo de cada función
- Altas, bajas y cambios de grupo sincronizados desde el directorio
- Filtro por organización o atributos aplicado en la capa de datos
- Registro de auditoría en almacenamiento separado y de solo escritura para la aplicación
Modalidades de despliegue que suelen plantearse
Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.
Antes de desarrollar
Datos, validaciones y permisos
- Mapa de funciones y de los datos que cada una necesita consultar o modificar, validado por los responsables de área.
- Identificación del propietario de cada conjunto de datos sensibles, que decide quién puede acceder.
- Proceso de altas, bajas y cambios de puesto conectado con recursos humanos o con el directorio.
- Acuerdo sobre qué acciones se auditan, durante cuánto tiempo se conservan los registros y quién puede consultarlos.
- Requisitos legales o contractuales concretos aportados por la organización y sus asesores, si existen.
Supervisión
Riesgos, límites y mantenimiento
- Un modelo con demasiados roles finos se vuelve inmanejable; conviene pocos roles claros y atributos para los matices.
- Filtrar solo en la interfaz deja los datos expuestos a través de la API; la autorización se aplica en el servidor.
- Los registros de auditoría pueden contener datos personales; su acceso y conservación se definen con el responsable del tratamiento.
- Las cuentas técnicas e integraciones suelen acumular permisos excesivos; también se inventarían y revisan.
Sectores, servicios y lecturas relacionadas
Sectores donde se aplicaría
Cómo se contrata
Preguntas frecuentes
¿Roles o atributos: qué modelo de permisos conviene?
Los roles son fáciles de entender y bastan cuando las funciones están bien delimitadas. Los atributos permiten reglas como «solo su centro» o «solo sus proyectos» sin multiplicar roles. En la práctica suele combinarse un conjunto reducido de roles con algunas reglas por atributos.
¿Podemos usar las cuentas corporativas que ya tenemos?
Normalmente sí. Si la organización dispone de un proveedor de identidad compatible con inicio de sesión federado, la aplicación delega en él la autenticación y las personas usan sus credenciales habituales, con las políticas de contraseña y segundo factor ya definidas.
¿Qué debe registrar una traza de auditoría útil?
Quién actuó, sobre qué registro, qué cambió, cuándo y desde qué sesión. No hace falta registrarlo todo: se priorizan accesos a datos sensibles, cambios de permisos y operaciones con efectos económicos o legales, para que el registro sea consultable y no un volcado inmanejable.
Cuéntanos quién necesita acceder a qué en tu sistema
Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.