Fronteras de confianza, identidad y permisos
¿Por qué ocultar el botón «Cancelar reserva» en la pantalla de otros usuarios no impide que alguien cancele una reserva ajena? En el Curso I adelantamos este problema al evaluar el informe de un agente. Ahora estudiaremos el fundamento sistémico que lo explica: las fronteras de confianza y la diferencia entre identidad, autenticación y autorización.
Objetivos y conocimientos previos
Partiendo de Componentes y responsabilidades, aprenderás a trazar fronteras de confianza entre lo que ocurre dentro del dispositivo del usuario y lo que ocurre en el servidor del sistema, a distinguir las tres piezas del control de acceso y a exigir que toda regla de permisos se verifique antes de leer o modificar datos.
Qué es una frontera de confianza
En un sistema conectado, no todos los componentes se ejecutan bajo el mismo nivel de control:
- Entorno fuera de tu control (Cliente): El navegador web, la aplicación móvil o cualquier programa que corre en el dispositivo del usuario. El usuario (o un atacante en su nombre) puede inspeccionar lo que hay en su pantalla, mostrar botones ocultos, modificar variables locales y enviar solicitudes fabricadas directamente a través de la red.
- Entorno bajo control del sistema (Servidor y Almacenamiento): La infraestructura donde se ejecutan tus reglas de dominio y se custodia la base de datos.
La línea que separa ambos lados es una frontera de confianza:
- Entorno del Cliente (No confiable: interfaz visual modificable por el usuario)
- Frontera de Confianza (Verificación obligatoria de identidad, permisos y reglas)
- Servidor de Dominio y Base de Datos (Entorno protegido del sistema)
Regla fundamental de seguridad en sistemas: Las comprobaciones en el cliente (como deshabilitar un botón o comprobar que un campo no vaya vacío antes de enviarlo) sirven para ofrecer una buena experiencia de uso inmediata. Las comprobaciones al cruzar la frontera del servidor son las únicas que ofrecen seguridad e integridad real.
Identidad, Autenticación y Autorización
Para decidir si una solicitud que cruza la frontera puede ejecutarse, el sistema debe resolver tres preguntas distintas en orden estricto:
| Concepto | Pregunta que responde | Ejemplo en el sistema de reservas | Fallo típico al confundirlos |
|---|---|---|---|
| 1. Identidad | ¿Quién afirma ser el actor que realiza la solicitud? | La cuenta de usuario con identificador U-42 (perteneciente a Ana). | Confiar en un identificador enviado libremente en la solicitud ("soy U-42") sin exigir prueba de ello. |
| 2. Autenticación | ¿Qué evidencia demuestra que realmente es esa persona o sistema? | Credenciales verificadas o una sesión/credencial firmada emitida por el servidor tras iniciar sesión. | Creer que pedir solo el correo electrónico sin verificar contraseña, código o sesión equivale a autenticar. |
| 3. Autorización (Permisos) | Sabemos con certeza quién es (U-42); ahora bien, ¿tiene permiso para realizar esta acción sobre este recurso concreto? | Comprobar si la reserva R-900 que intenta cancelar pertenece realmente a U-42 (o si U-42 tiene rol de administrador). | Fallo de autorización por objeto: comprobar que U-42 ha iniciado sesión (está autenticado), pero permitirle cancelar o leer cualquier reserva (R-901 de Bruno) solo con cambiar el número de reserva en la petición. |
Observa la diferencia entre el paso 2 y el paso 3: estar autenticado no significa estar autorizado para todo. Que una persona tenga llave para entrar al edificio no le da derecho a abrir los buzones de todos los vecinos.
Protección tanto en escritura como en lectura
Un error habitual es proteger las operaciones que modifican datos (cancelar, borrar, pagar), pero olvidar proteger las consultas (lecturas):
- Si cualquier usuario autenticado puede pedir «dame el detalle de la factura
F-502» y el servidor devuelve el nombre, dirección e importe sin comprobar primero queF-502pertenece a quien pregunta, existe una fuga de información privada. - Incluso los mensajes de error deben diseñarse con cuidado: si un usuario sin permiso intenta cancelar una reserva ajena, el sistema debe denegar la acción sin revelar datos privados del titular real de esa reserva.
Principio de mínimo privilegio (también para agentes y servicios)
El control de permisos no se aplica solo a personas humanas; se aplica también a componentes técnicos y agentes de IA:
- Si un módulo del sistema solo necesita consultar las categorías de gasto para generar una gráfica, no debería tener permisos para borrar facturas.
- Si integras un asistente de IA para que responda dudas de un cliente sobre sus reservas, la consulta de datos que ejecute en nombre de ese cliente debe estar sujeta exactamente a la misma regla de autorización: el asistente solo puede leer las reservas del usuario autenticado en esa sesión, nunca toda la base de datos de todos los clientes.
Practica
Auditas un sistema de facturación donde cada cliente puede ver y descargar sus facturas desde el navegador a través de una dirección como /api/facturas?id_factura=F-104. El agente que lo programó te asegura:
«Es totalmente seguro porque:
- En la página web del cliente solo muestro la lista de sus propias facturas.
- Además, el endpoint
/api/facturascomprueba siempre que el usuario haya iniciado sesión antes de devolver el PDF de la factura».
Responde razonadamente:
- Explica por qué el punto 1 (lo que muestra la página web) está en el lado equivocado de la frontera de confianza.
- Utilizando los conceptos de autenticación y autorización, explica qué ocurre en el punto 2 si el cliente
C-101(que sí ha iniciado sesión) escribe manualmente en su navegador/api/facturas?id_factura=F-888, dondeF-888es una factura del clienteC-205. - Escribe la regla lógica exacta que debe comprobar el servidor antes de devolver o permitir pagar una factura.
Criterio de comprensión: debes distinguir que el servidor está comprobando autenticación (sesión iniciada) pero ha omitido la autorización sobre el recurso concreto, y formular la condición usuario_autenticado == factura.id_cliente (o rol autorizado explícito) verificada dentro del servidor antes de entregar cualquier dato.
Profundiza con IA
Esta es mi revisión de seguridad sobre fronteras de confianza, autenticación y autorización en el caso de las facturas: [tu respuesta]. Evalúa mi regla. Después, plantéame un escenario donde un administrador de soporte técnico necesita ver la factura de un cliente para ayudarle, pero no debe poder emitir pagos con la tarjeta del cliente, y pídeme que defina cómo modelaría esos permisos por acción y rol.
Siguiente lectura
Ya sabemos qué componentes existen y qué frontera de confianza los protege. ¿Cómo acuerdan exactamente dos componentes el formato, las reglas y el ritmo de los mensajes que intercambian? Continúa con Contratos y comunicación entre sistemas.