Cuando el negocio me pide una solución de acceso remoto, mi primera pregunta suele ser bastante sencilla: ¿para qué la necesitas realmente?
Porque “necesitamos acceso remoto” todavía no me dice qué tenemos que resolver. Necesito entender qué quiere hacer el negocio, qué actividad quiere cubrir y si estamos hablando de un equipo concreto o de toda la compañía.
Puede parecer evidente, pero de esa conversación salen muchas de las decisiones que después van a determinar la arquitectura. Si empezamos directamente por el producto, estamos eligiendo una solución antes de haber definido bien el problema.
Primero, entender qué necesita el negocio
Antes de hablar de tecnología, quiero saber qué actividad queremos habilitar.
¿Necesitamos que un equipo pueda trabajar desde fuera de la oficina? ¿Que un proveedor mantenga una aplicación? ¿Que auditoría consulte información? ¿O estamos preparando una alternativa para cuando el acceso habitual no esté disponible?
Todas esas situaciones pueden requerir acceso remoto. Pero no necesitan necesariamente los mismos permisos, las mismas condiciones ni el mismo modelo operativo.
También hay una pregunta que conviene hacer pronto: ¿por qué creemos que lo necesita todo el mundo?
A veces hay una necesidad real y generalizada. Otras veces se plantea un alcance muy amplio por comodidad, por anticiparse a posibles peticiones o porque todavía no hemos identificado bien quién lo necesita.
Yo prefiero aclararlo antes de implantar la solución. Dar acceso a toda la compañía y descubrir después que solo lo utiliza una parte también tiene consecuencias: permisos que mantener, revisiones, soporte y, según la solución, licencias.
Dónde encaja SABSA
Para mí, SABSA ayuda a mantener el vínculo entre lo que necesita el negocio y lo que diseñamos.
Si el negocio pide un acceso “robusto”, tenemos que bajar esa palabra a requisitos concretos. ¿Qué disponibilidad necesita? ¿Qué sucede si el servicio falla? ¿Cuánto tiempo puede estar interrumpida la actividad? ¿Existe una alternativa?
Si quiere saber quién hace qué y a dónde puede acceder, debemos definir qué identidades vamos a utilizar, qué permisos corresponden a cada actividad y qué información necesitamos registrar.
Son preguntas que influyen directamente en la solución.
El enfoque SABSA parte de los objetivos del negocio y permite mantener su trazabilidad hasta la arquitectura. Esa es la parte que me interesa aplicar: poder explicar por qué existe cada requisito y qué necesidad estamos cubriendo con él.
Quién, a qué, para qué y durante cuánto tiempo
Una vez entendido el problema, necesito concretar el acceso.
Quién. ¿Quién lo necesita realmente? Que una persona pertenezca a un departamento no significa que deba tener los mismos permisos que todos sus compañeros.
A qué. ¿Dónde tiene que conectarse? “Al entorno” es demasiado amplio. Necesitamos identificar aplicaciones, servicios o recursos.
Para qué. ¿Qué tiene que hacer? Consultar información, modificarla y administrar una plataforma son actividades distintas.
Durante cuánto tiempo. ¿Es una necesidad habitual, algo periódico o una tarea que termina en una fecha determinada?
Estas cuatro preguntas permiten definir un acceso que tenga sentido. También nos dejan una base para revisarlo después.
Si no podemos explicar para qué necesita alguien un permiso, nos falta información para concederlo con criterio.
- Necesidad de negocio
- Requisitos y alcance · SABSA
- Decisiones de acceso · Zero Trust
- Implantación y operación
- Revisión de uso, permisos y excepciones
La revisión vuelve a alimentar los requisitos y el alcance.
Aplicar Zero Trust al acceso
Con el alcance definido, aplico los principios de Zero Trust para reducir al mínimo la confianza implícita.
Una persona no debería recibir acceso amplio simplemente porque trabaja en la compañía o porque ya ha conseguido conectarse. Tenemos que evaluar su identidad, el recurso solicitado y las condiciones en las que se produce ese acceso.
NIST SP 800-207 recoge ese enfoque: el acceso se evalúa por sesión y la autorización a un recurso no concede automáticamente acceso a los demás.
A partir de ahí, toca definir cómo lo llevamos a la práctica. Qué autenticación necesitamos, qué condiciones debe cumplir el dispositivo, qué acciones se permiten y qué cambios obligan a revisar el acceso.
También debemos conocer las limitaciones. Hay aplicaciones que permiten perfiles muy detallados y otras que apenas distinguen entre unos pocos niveles de permisos.
Si la tecnología no permite aplicar el alcance que necesitamos, hay que ponerlo sobre la mesa. Ese problema sigue existiendo aunque la solución se comercialice como Zero Trust.
¿Y las excepciones?
Las excepciones aparecen. Un caso bastante habitual es alguien de otro departamento que necesita consultar información sin estar pidiéndosela continuamente al equipo que la gestiona.
Por ejemplo, auditoría interna.
La necesidad puede estar perfectamente justificada. Pero todavía tenemos que responder a varias preguntas: ¿qué información necesita?, ¿puede ser acceso de lectura?, ¿requiere descargar datos?, ¿durante cuánto tiempo?, ¿quién valida el alcance?
A partir de esas respuestas podemos buscar la forma adecuada de habilitarlo.
Lo que intento evitar es que una necesidad de consulta termine en un permiso amplio y permanente porque era la opción más rápida.
Para mí, una excepción necesita un motivo claro, un responsable y una revisión. Y si la misma excepción se pide una y otra vez, debemos revisar el diseño. Quizá estamos ante un caso de uso recurrente que merece su propio perfil de acceso.
Mi criterio es mantener las excepciones al mínimo. Las que existan deben poder explicarse y seguir teniendo sentido.
La solución también hay que operarla
La arquitectura tiene que funcionar cuando llegan las solicitudes, los cambios y las incidencias.
¿Quién valida que una persona necesita acceso? ¿Quién lo habilita? ¿Quién revisa los permisos? ¿Quién actúa si cambia de puesto? ¿Y quién responde cuando el servicio no funciona?
Eso también hay que diseñarlo.
Para definir un modelo operativo y un RACI, necesito conocer bien cómo funciona la tecnología. Aunque no sea yo quien la administre a diario, tengo que entender sus capacidades, sus dependencias y sus limitaciones.
De lo contrario, podemos terminar asignando responsabilidades que un equipo no puede cumplir o dejando actividades que todo el mundo supone que hace otro.
El modelo operativo debe permitir resolver esas situaciones con claridad.
Después, comprobar quién lo utiliza
Una vez implantada la solución, me interesa contrastar lo que pensábamos con lo que ocurre realmente.
Si hemos habilitado acceso para una población determinada, ¿cuántas personas lo utilizan? ¿Con qué frecuencia? ¿Para qué actividades?
Un indicador útil es comparar los usuarios con acceso habilitado con los usuarios que realmente han utilizado el servicio durante un periodo definido:
Adopción observada = usuarios únicos que han utilizado el servicio / usuarios con acceso habilitado × 100
Antes de utilizarlo, hay que acordar qué entendemos por uso y cómo contamos las altas y bajas. También conviene separar perfiles: una persona que trabaja a diario mediante ese acceso tiene una necesidad distinta de otra que lo utiliza para una revisión trimestral.
El objetivo es comprobar si el alcance inicial estaba bien definido.
Porque a veces se piensa que hace falta para todo el mundo y, cuando revisamos los datos, resulta que no es así.
Poco uso no significa automáticamente que sobre
Aquí hay que interpretar los datos.
Puede haber usuarios que no lo necesitan, pero también puede haber problemas de funcionamiento, falta de información o una actividad que todavía no ha comenzado.
Y existen accesos poco frecuentes que siguen siendo necesarios. Una solución de continuidad puede pasar meses sin utilizarse en condiciones normales. En ese caso, debemos comprobar que sigue justificada y que funciona cuando se prueba.
Por eso no retiraría un acceso únicamente porque no haya tenido uso durante un periodo. Revisaría el motivo por el que existe y la frecuencia con la que esperábamos utilizarlo.
El KPI nos ayuda a hacer mejores preguntas. La decisión necesita contexto.
Uso y seguridad son cosas que debemos medir por separado
Que la solución se utilice mucho no demuestra que los permisos estén bien definidos.
Para comprobarlo necesitamos revisar otros aspectos: si cada perfil tiene el acceso que le corresponde, si las excepciones siguen justificadas, si podemos atribuir las actividades a una identidad y si los permisos se revisan cuando cambia la necesidad.
La adopción nos dice si se está utilizando el servicio. Las revisiones de acceso nos ayudan a comprobar si se está utilizando con el alcance adecuado.
Necesitamos ambas cosas para valorar el resultado.
Mantener el criterio con el que empezamos
El negocio cambia. Aparecen nuevas aplicaciones, nuevas actividades y nuevas necesidades de acceso.
Por eso la arquitectura necesita revisión durante la vida del servicio. La relación entre necesidad y permiso debe seguir siendo explicable.
Así es como entiendo la combinación de SABSA y Zero Trust: partir de lo que el negocio necesita, definir el acceso con el menor grado posible de confianza implícita y comprobar después que el alcance sigue siendo adecuado.
Y cuando aparezca una nueva petición, volver a las mismas preguntas:
¿Quién necesita acceso, a qué, para qué y durante cuánto tiempo?
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.