«Necesitamos una excepción. Solo será durante unas semanas».
La petición puede tener todo el sentido del mundo. Hay un servicio que debe seguir funcionando, una integración que todavía no está terminada o una aplicación que no soporta el modelo de seguridad que queremos aplicar.
Hasta ahí, ningún problema. Las arquitecturas se construyen sobre entornos reales, con limitaciones reales. Lo interesante viene después.
Pasan las semanas. La integración se retrasa. Cambia el responsable. Aparecen otras prioridades. Y aquella excepción que iba a durar un mes sigue funcionando dos años después.
La pregunta es bastante sencilla: ¿sigue siendo una excepción o ya forma parte de nuestra arquitectura, aunque nadie lo haya decidido expresamente?
Primero, entender para qué se necesita
Antes de hablar de aprobar o rechazar, hay que entender qué intenta conseguir el negocio.
Quién necesita hacer qué, sobre qué servicio, con qué finalidad y durante cuánto tiempo.
Porque «necesitamos una excepción» describe una petición, pero explica bastante poco sobre la necesidad.
Imaginemos que un proveedor necesita acceso remoto para terminar una migración. ¿Necesita acceder a toda la red? ¿A varios servidores? ¿A una aplicación concreta? ¿Durante todo el día o únicamente en las ventanas de intervención?
Y, sobre todo, ¿qué impide utilizar el acceso previsto para ese servicio?
Si no hacemos estas preguntas, podemos terminar autorizando algo mucho más amplio de lo que hacía falta. Y después será bastante más difícil retirarlo, porque alguien habrá empezado a utilizar esa amplitud como parte de su forma habitual de trabajar.
Entender la necesidad permite buscar una solución proporcionada. A veces habrá que conceder una excepción. Otras veces descubriremos que existe una alternativa que no se había considerado.
Una excepción necesita límites
«Acceso temporal para el proveedor» no me dice lo suficiente.
Necesito saber qué identidades van a utilizarlo, a qué recursos podrán llegar, qué acciones podrán realizar y cuándo dejará de estar permitido.
También necesito saber qué control estamos dejando de aplicar y qué consecuencias puede tener.
No es lo mismo permitir una conexión concreta entre dos sistemas que mantener acceso administrativo permanente a un entorno completo.
Tampoco es lo mismo trabajar sobre un entorno de pruebas sin información real que hacerlo sobre otro que contiene una copia de los datos de producción. Llamarlo «no productivo» no elimina el riesgo de los datos que hay dentro.
Cuanto más precisa sea la excepción, más fácil será controlarla y, llegado el momento, cerrarla.
Si no podemos explicar con claridad qué estamos autorizando, probablemente tampoco podremos comprobar si se está utilizando como habíamos previsto.
¿Quién asume la decisión?
Aquí suele aparecer otra frase interesante: «Esto lo ha aprobado Seguridad».
Seguridad puede evaluar el riesgo, proponer condiciones y explicar las consecuencias. Pero el proceso debe dejar claro quién tiene autoridad para aceptar ese riesgo y quién responde por el servicio afectado.
Una aprobación técnica no sustituye esa responsabilidad.
Para mí, una excepción debería permitir responder, sin tener que reconstruir una cadena de correos, a unas preguntas básicas: quién la solicita y por qué; quién es responsable del servicio; quién acepta el riesgo, conforme al modelo de gobierno de la organización; quién implementa y mantiene las condiciones acordadas; y quién debe ejecutar el plan para eliminarla.
Pueden intervenir varias personas. Lo importante es que las responsabilidades estén claras.
Porque si todo el mundo participa, pero nadie tiene que resolverla, la excepción tiene muchas posibilidades de quedarse.
La anatomía de una excepción controlada
Ejemplo ilustrativo · acceso de un proveedor durante una migración
Completar la migración manteniendo la continuidad del servicio.
- ALCANCEQuién · a qué · para qué
- Identidades nominativas, destinos concretos, acciones y ventanas autorizadas.
- RESPONSABILIDADQuién decide · quién ejecuta
- Responsable del servicio, autoridad que acepta el riesgo y equipo que aplica los controles.
- RIESGO Y CONTROLESQué falta · cómo lo limitamos
- Control no disponible, medidas compensatorias y riesgo que permanece.
- SALIDAQué debe cambiar · quién lo entrega
- Acciones para retirar la excepción, responsable y plazo de resolución.
- Revisión
- Antes del vencimiento
- Caducidad
- Límite de la autorización
- Cierre
- Retirada técnica verificada
Una aprobación sin alcance, responsable ni salida deja el problema abierto.
Mientras exista, ¿cómo reducimos el riesgo?
Que un control no pueda aplicarse exactamente como queremos no significa que tengamos que dejar el acceso sin más condiciones.
Volvamos al proveedor de la migración.
Si todavía no podemos utilizar el mecanismo de acceso previsto, quizá podamos limitar los destinos, habilitar el acceso únicamente durante las intervenciones, exigir autenticación adicional en un punto intermedio o supervisar las sesiones.
Dependerá del caso. No todas estas medidas estarán disponibles y ninguna debería darse por equivalente al control original sin evaluarlo.
La cuestión es entender qué riesgo sigue existiendo después de aplicar esas medidas.
Guardar registros, por ejemplo, puede ayudarnos a investigar lo ocurrido. Por sí solo, no impide que alguien acceda a un recurso que no debería.
Y una revisión manual puede ser útil, siempre que haya alguien encargado de hacerla y una frecuencia definida. Si depende de que una persona se acuerde cuando tenga tiempo, su eficacia será bastante limitada.
Los controles compensatorios también necesitan responsables y evidencias de que funcionan.
Poner una fecha no resuelve el problema
Una fecha de caducidad es necesaria, pero no basta.
«Vence el 30 de junio» establece un límite. No explica qué tiene que suceder antes del 30 de junio para que podamos retirar la excepción.
¿Hay que actualizar una aplicación? ¿Cambiar la forma de conexión del proveedor? ¿Migrar un servicio? ¿Comprar una licencia? ¿Asignar a un equipo para terminar una integración?
Ese es el trabajo que debe quedar identificado.
Una excepción temporal necesita un camino de salida: acciones, responsables y plazos razonables. Si la solución depende de un proyecto que nadie ha aprobado ni financiado, conviene reconocerlo desde el principio.
De lo contrario, la fecha será simplemente el día en que alguien pida una prórroga.
Llega el vencimiento y el negocio sigue necesitándola
Esto va a pasar. Los proyectos se retrasan y las dependencias cambian.
Pero «seguimos necesitándolo» debería iniciar una revisión, no una renovación automática.
Primero comprobaría si la necesidad sigue siendo la misma. Después, si el alcance continúa siendo adecuado, si los controles acordados se han aplicado y qué ha ocurrido con el plan de salida.
También hay que entender qué pasa si se retira el acceso. ¿Se detiene un servicio crítico? ¿Se bloquea una tarea puntual? ¿Existe una alternativa operativa?
Con esa información se puede decidir si procede ampliar el plazo, reducir el alcance, añadir condiciones o elevar la decisión al nivel correspondiente.
No se trata de desconectar un servicio sin evaluar el impacto. Se trata de evitar que la continuidad del negocio se utilice como explicación permanente para no resolver nada.
Una prórroga debería explicar qué ha cambiado y qué vamos a hacer durante el nuevo plazo.
Si cada renovación contiene exactamente el mismo texto, merece la pena mirar qué está ocurriendo.
Al vencer, hay que decidir de nuevo
Revisar la necesidad y el impacto antes de que termine la autorización.
- Definir y evaluarNecesidad, alcance y riesgo. Sin justificación, no se concede.
- Decidir y operarAutorización expresa, condiciones y evidencias de control.
¿Sigue siendo necesaria? ¿Se cumplen las condiciones? ¿Qué impide retirarla?
- La causa está resueltaCerrar
Retirar acceso o regla y comprobarlo antes de cerrar el registro.
- El bloqueo sigue siendo temporalProrrogar con condiciones
Reevaluar el riesgo y el impacto. Decisión expresa, nuevo plazo y acciones de salida.
- La necesidad es permanenteRediseñar
Resolver la arquitectura y planificar la transición; la nueva solución también requiere evaluación.
Toda prórroga vuelve a la operación y a una nueva revisión. Nunca es automática.
Decisiones ilustrativas, sujetas al modelo de gobierno de cada organización. La revisión puede terminar en denegación o escalado; no garantiza la continuidad del acceso.
Si todos necesitan la misma excepción, revisemos el modelo
También hay que saber mirar hacia dentro.
Si distintos equipos solicitan repetidamente la misma excepción, quizá estamos ante una limitación del servicio que ofrecemos desde Seguridad.
Puede que el acceso previsto sea demasiado lento. Que no cubra una necesidad legítima. Que la herramienta no soporte determinados casos. O que el proceso sea tan complicado que los equipos busquen otro camino para poder trabajar.
Eso no justifica cualquier alternativa, pero sí aporta información que debemos utilizar.
La arquitectura tiene que permitir que el negocio funcione con un nivel de riesgo conocido y gestionado. Si el modelo obliga continuamente a salir de él, habrá que revisar el modelo.
Y si una necesidad es permanente, debemos tratarla como tal: diseñar una solución sostenible, evaluar sus riesgos y establecer sus controles.
Encadenar autorizaciones temporales durante años solo aplaza esa decisión.
¿Estamos cerrando excepciones o acumulándolas?
Tener un registro es un buen comienzo. Después hay que utilizarlo.
Me interesa saber cuántas excepciones están activas, qué antigüedad tienen, cuáles han vencido y cuántas veces se han prorrogado. También cuáles afectan a privilegios, datos sensibles o servicios especialmente relevantes.
Pero hay otra pregunta que me parece igual de importante: ¿cuántas se han cerrado porque hemos resuelto la causa que las hacía necesarias?
Una excepción puede desaparecer del registro y seguir existiendo técnicamente. Por eso, cerrar el expediente debería incluir comprobar que se ha retirado el acceso, eliminado la regla o aplicado el control pendiente, según corresponda.
Y conviene revisar el uso real. Puede que estemos renovando un acceso que hace meses que nadie utiliza.
Medir ayuda a distinguir las necesidades vigentes de las inercias.
La excepción también necesita arquitectura
No espero un entorno sin excepciones. Espero un entorno en el que podamos explicar las que existen.
Para qué sirven, qué permiten, quién responde por ellas, qué riesgo mantienen y qué tiene que ocurrir para cerrarlas.
Eso exige hablar con el negocio, conocer la tecnología y entender cómo se opera el servicio. Aprobar una solicitud es solo una parte del trabajo.
Porque una excepción puede ser razonable hoy y dejar de serlo dentro de seis meses.
Y si dos años después sigue siendo necesaria, habrá que tomar una decisión sobre cómo vamos a prestar ese servicio.
¿Seguimos necesitando una excepción o lo que necesitamos es resolver la arquitectura?
Los ejemplos son ilustrativos. Las decisiones de implementación deben adaptarse a los requisitos y dependencias de cada organización.