Cuando hablo de Zero Trust, quiero saber qué decisiones de acceso estamos tomando y con qué evidencia. El objetivo es reducir la confianza implícita y proteger los recursos según las actividades que el negocio necesita.
Empezar por una decisión que importe
Cuando alguien plantea un proyecto de Zero Trust, yo quiero saber qué decisión de acceso vamos a mejorar primero. Es fácil empezar por una lista de tecnologías; cuesta más explicar qué actividad podrá realizar una persona y qué condiciones impedirán otra. Esa explicación es la que permite discutir el diseño con el negocio.
Elegiría un recurso con un responsable identificable y actividades que podamos probar. Antes de cambiar nada, documentaría cómo se accede hoy, qué permisos existen y qué vías alternativas siguen disponibles. Ese recorrido inicial evita evaluar únicamente el nuevo producto mientras dejamos abierto el camino anterior. También nos permite acordar qué resultado esperamos y quién debe validarlo.
La pregunta de arquitectura
¿Quién o qué solicita acceso, a qué recurso, para realizar qué acción y con qué evidencia? Identidad, dispositivo, sensibilidad del recurso y contexto deben formar parte de la conversación.
Un primer paso práctico
Elegir un servicio crítico y representar su recorrido de acceso. Identificar dónde se autentica, cómo se autoriza, qué privilegios se conceden y cuándo se revisan o revocan.
¿Qué evaluamos antes de permitir el acceso?
- IdentidadQuién solicita acceso y con qué permisos.
- DispositivoQué condiciones cumple y qué señales tenemos.
- Recurso y acciónA qué quiere acceder y qué necesita hacer.
- ContextoCuándo, desde dónde y bajo qué condiciones.
Los cambios relevantes durante la sesión requieren la respuesta definida por la política.
Las señales necesitan una respuesta definida
Conocer el estado de un dispositivo solo ayuda si sabemos qué hacer con esa información. ¿Bloqueamos el acceso cuando falta una condición? ¿Permitimos únicamente una actividad limitada? ¿Quién atiende al usuario si el dato que recibimos es incorrecto? Esas decisiones deben formar parte del diseño.
También revisaría la calidad y la actualidad de las señales. Una comprobación realizada horas antes puede no representar el estado de la sesión actual. Si una fuente deja de responder, necesitamos una conducta prevista según el impacto del recurso. No establecería una única respuesta para toda la organización: el requisito de continuidad y las consecuencias de permitir acceso cambian de un servicio a otro.
Autenticarse no equivale a poder hacer cualquier cosa
En el ejemplo financiero, confirmar la identidad es solo una parte. Podemos necesitar distinguir la consulta de un registro, la modificación de una cuenta de pago y la aprobación final. Cada acción puede requerir permisos y condiciones diferentes, aunque se realice dentro de la misma aplicación.
Si la aplicación no permite esa separación, debemos reconocerlo. Una nueva capa de acceso no garantiza que los permisos internos sean adecuados. Hay que revisar cómo se combinan las políticas de entrada con los roles de la aplicación. También comprobaría que las APIs, las cuentas técnicas y los accesos directos están incluidos en la evaluación. Una interfaz protegida puede convivir con otro camino que permita la misma operación sin ese control.
Ejemplo: acceso a una aplicación financiera
Imaginemos una aplicación con consultas habituales y cambios en cuentas de pago. Ambas acciones pertenecen al mismo servicio, pero no tienen el mismo impacto. Una propuesta de diseño puede permitir la consulta bajo condiciones normales y exigir una comprobación adicional antes de modificar los datos de pago. La decisión debe distinguir a la persona, la acción y el contexto; limitarse a comprobar que el usuario ha iniciado sesión deja esa diferencia sin representar.
Preguntas para la revisión
¿Qué pasa si una sesión ya autorizada cambia de contexto? ¿Se pueden limitar las acciones de mayor impacto? ¿Existe una alternativa operativa cuando falla una dependencia de acceso?
Probar cambios de contexto y fallos
No me quedaría con una prueba en la que un usuario autorizado consigue entrar. Quiero comprobar que una identidad sin permiso no puede ejecutar la acción, que un cambio relevante de contexto produce la respuesta prevista y que la retirada del acceso funciona en la práctica.
Las pruebas deben incluir sesiones ya abiertas. Revocar una asignación y terminar una sesión son operaciones que pueden comportarse de forma diferente. Hay que saber qué ocurre con los tokens y con las operaciones en curso. También probaría el fallo de una dependencia, la pérdida de conectividad y la recuperación del servicio. Registrar lo que no podemos controlar permite definir una limitación concreta en lugar de asumir que el producto lo resuelve todo.
Quién cambia la política y cómo se valida
Una política de acceso también necesita un procedimiento de cambio. Si modificamos una condición para resolver una incidencia, quiero saber a qué usuarios y recursos afecta, quién lo autoriza y cómo verificamos que no hemos ampliado el alcance sin querer. Una regla muy general puede solucionar un caso y abrir otros que no estaban previstos.
Antes de desplegar el cambio, comprobaría escenarios representativos de las actividades afectadas. Después revisaría los registros y el comportamiento de los usuarios que deben seguir trabajando. También definiría cómo volver a la configuración anterior si el resultado no es el esperado. El equipo operativo necesita esa información, junto con una explicación de las dependencias que pueden alterar el efecto de la regla.
En una revisión periódica, elegiría algunas políticas y pediría que se explicaran con ejemplos: qué permiten, qué impiden y qué necesidad las justifica. Si nadie puede responder, debemos investigar antes de conservarlas por costumbre. El mismo criterio aplica a las exclusiones. Una excepción creada durante una incidencia puede seguir activa mucho después, aunque el problema original ya se haya resuelto. Revisar ese ciclo ayuda a que el modelo no se degrade con cada cambio. La arquitectura debe seguir describiendo lo que ocurre en el servicio, también después de meses de operación.
Qué medir y qué evitar
Registrar qué decisiones se tomaron y con qué señales permite detectar excepciones que se convierten en acceso habitual. Conviene distinguir cobertura de efectividad: que un control esté desplegado no demuestra que impida la acción sensible. Tampoco debe confundirse Zero Trust con exigir repetidamente autenticación; cada comprobación necesita un propósito y una respuesta definida.
Implantar por servicios y revisar las excepciones
Avanzaría por servicios o grupos de usuarios con un alcance que podamos operar. Esa progresividad permite resolver incidencias y ajustar políticas antes de ampliar el despliegue. Pero cada fase necesita condiciones de cierre: qué se ha validado, qué accesos anteriores se retiran y qué excepciones siguen pendientes.
Una excepción debe tener finalidad, responsable y revisión. Si la misma necesidad se repite, quizá debamos incorporar un caso de uso al diseño. Para medir el avance miraría cobertura, accesos fuera del modelo, tiempos de revocación y resultados de pruebas de autorización. El número de usuarios incorporados aporta información, pero necesito saber si las decisiones funcionan como habíamos previsto. Esa evidencia es la que permite defender la arquitectura y corregirla cuando cambia el negocio.
Referencias para profundizar
Fuentes oficiales para contrastar y ampliar estos conceptos. Este artículo presenta un enfoque práctico; no reproduce los requisitos completos de las referencias.
Los ejemplos son ilustrativos. Las decisiones de implementación deben adaptarse a los requisitos y dependencias de cada organización.