Respuesta breve

Ninguna capa de seguridad debería darse por buena sola. Si una falla o se configura mal, la siguiente tiene que seguir cerrando el paso. Para una herramienta interna pequeña, eso se traduce en identidad antes de llegar a nada, un servicio que vuelve a comprobar la sesión en cada petición y datos con permisos propios. El principio más útil es fallar cerrado: si falta configuración, el servicio no sirve nada. Es preferible un error visible a una herramienta abierta sin que nadie lo sepa.

Puntos clave

  • Ninguna capa de seguridad debería darse por buena sola: si una falla o se configura mal, la siguiente tiene que seguir cerrando el paso.
  • Una herramienta interna pequeña no necesita VPN: un código de un solo uso enviado al correo y una lista de personas autorizadas resuelven la entrada.
  • El servicio debe comprobar la sesión en cada petición, mantener su propia lista de correos permitidos y fallar cerrado si le falta configuración.
  • Lo que vive en la oficina puede publicarse con una conexión saliente hacia el borde de la red, sin abrir puertos en el router y siempre con la identidad delante.
  • En la documentación, los registros y las conversaciones con asistentes de IA debe aparecer el nombre de un secreto, nunca su valor.

Identidad antes de llegar a nada

Un equipo pequeño no necesita contraseñas que recordar ni que se puedan filtrar. Un código de un solo uso enviado al correo y una política con la lista de personas autorizadas resuelven la entrada a una herramienta privada, sin VPN ni nada que instalar.

Detrás de esa puerta, el propio servicio debería comprobar el token de sesión en cada petición: algoritmo, emisor, audiencia, caducidad, correo y firma. Y mantener su propia lista de correos permitidos, de modo que si la política de acceso se amplía por error, la herramienta siga cerrada.

El mismo error para todos los fallos

Un token falsificado, uno caducado y uno sin correo deberían recibir la misma respuesta, sin explicar qué comprobación falló. Decir «el token ha caducado» ayuda a quien ataca a afinar; decir «vuelve a entrar» basta a quien usa la herramienta.

Si el servicio no tiene configurados sus parámetros de verificación, debe responder que el acceso no está configurado y no servir nada, aunque el token fuera válido. Un despliegue incompleto no puede ser un despliegue abierto.

Túneles, no puertos abiertos

Lo que vive en la oficina (una base de datos, un equipo que lee documentos) puede publicarse con una conexión saliente hacia el borde de la red, sin abrir ningún puerto en el router. La identidad va siempre delante, también para una prueba rápida.

Para formularios públicos, una comprobación contra bots sin captchas molestos, un campo trampa y la dirección IP guardada solo como hash reducen el ruido sin pedir nada a la persona. Y una política de contenido estricta en el navegador evita que un script ajeno se cuele en la página.

Secretos solo por su nombre

En la documentación, en las conversaciones con asistentes de IA y en los registros debería aparecer el nombre del secreto, nunca su valor. El valor vive en el gestor de secretos del servicio y en un fichero local ignorado por el control de versiones.

Una clave de despliegue por repositorio, un guardián que revisa cada commit en busca de algo con forma de secreto y una lista corta de acciones que requieren aprobación humana (desplegar, cambiar un secreto, tocar la configuración de acceso o el DNS) completan una higiene que cuesta poco y evita incidentes.

Preguntas frecuentes

¿Cómo protejo el acceso a una herramienta interna pequeña sin montar una VPN?

Poniendo la identidad antes de llegar a nada: un código de un solo uso enviado al correo y una política con la lista de personas autorizadas, sin contraseñas ni nada que instalar. Detrás, el propio servicio debería comprobar el token de sesión en cada petición (algoritmo, emisor, audiencia, caducidad, correo y firma) y mantener su propia lista de correos permitidos. Así, si la política de acceso se amplía por error, la herramienta sigue cerrada.

¿Qué significa que una herramienta interna «falle cerrado»?

Significa que, si le falta configuración, el servicio no sirve nada. Si no tiene configurados sus parámetros de verificación, debe responder que el acceso no está configurado, aunque el token fuera válido. Es preferible un error visible a una herramienta abierta sin que nadie lo sepa: un despliegue incompleto no puede ser un despliegue abierto.

¿Qué mensaje de error debe mostrar una herramienta interna cuando falla la comprobación de acceso?

El mismo para todos los fallos, sin explicar qué comprobación falló. Un token falsificado, uno caducado y uno sin correo deberían recibir la misma respuesta. Decir «el token ha caducado» ayuda a quien ataca a afinar, mientras que «vuelve a entrar» basta a quien usa la herramienta.

¿Qué medidas básicas evitan que se filtren las claves y secretos de una herramienta interna?

En la documentación, en los registros y en las conversaciones con asistentes de IA debe aparecer el nombre del secreto, nunca su valor, que vive en el gestor de secretos del servicio y en un fichero local ignorado por el control de versiones. A eso se suman una clave de despliegue por repositorio y un guardián que revisa cada commit en busca de algo con forma de secreto. Una lista corta de acciones que requieren aprobación humana, como desplegar, cambiar un secreto o tocar la configuración de acceso o el DNS, completa una higiene que cuesta poco y evita incidentes.