Authelia en el CPD de Tecnidom: 2FA y control de acceso delante de los servicios

Authelia con doble factor de autenticación en el CPD de Tecnidom

Publicar una aplicación interna en Internet sin añadir una capa de control de acceso específica aumenta innecesariamente la superficie de exposición.

En la evolución del CPD de Tecnidom utilizamos Authelia como una capa adicional delante de determinados servicios web, integrada con el reverse proxy y con una idea muy simple: el acceso debe validarse antes de llegar a la aplicación.

Qué aporta Authelia

Authelia permite centralizar autenticación, aplicar segundo factor y definir políticas distintas según el servicio, el usuario o la red de origen.

  • Autenticación multifactor mediante TOTP o WebAuthn.
  • Políticas de acceso por aplicación.
  • Integración con reverse proxy.
  • Gestión centralizada del acceso a múltiples servicios.
  • Posibilidad de mantener la plataforma bajo control propio.

El reverse proxy como punto de entrada

La arquitectura funciona mejor cuando las aplicaciones no están expuestas directamente. El tráfico entra por el reverse proxy, pasa por la política de autenticación y solo después llega al servicio correspondiente.

Esto simplifica certificados, reduce puertos expuestos y permite aplicar una política coherente a varias aplicaciones.

2FA no sustituye una buena arquitectura

El doble factor reduce mucho el riesgo asociado a contraseñas comprometidas, pero no arregla servicios desactualizados, permisos excesivos o configuraciones inseguras.

Por eso lo integramos dentro de una estrategia más amplia: segmentación, firewall, monitorización, actualizaciones y acceso mínimo necesario.

Alta disponibilidad y dependencias

Authelia puede desplegarse con componentes externos como Redis y PostgreSQL cuando el servicio necesita mayor resiliencia. La elección depende del impacto real de una caída y del nivel de complejidad que la organización pueda operar correctamente.

No toda pyme necesita una arquitectura distribuida para cada componente. Sí necesita conocer qué dependencia introduce y cómo recuperarla.

El objetivo

La finalidad no es añadir otra pantalla de login. Es establecer un control coherente delante de aplicaciones que contienen información o funciones que no deberían quedar accesibles únicamente con usuario y contraseña.

La seguridad mejora cuando cada capa tiene una función concreta y cuando una credencial comprometida no equivale automáticamente a acceso completo.

Qué servicios merece la pena proteger detrás de una capa adicional

No todas las aplicaciones necesitan el mismo patrón. Authelia resulta especialmente útil cuando varios servicios web internos comparten usuarios o cuando queremos aplicar MFA y políticas homogéneas antes de que el tráfico alcance la aplicación.

Para un servicio ya integrado de forma nativa con un proveedor de identidad corporativo puede tener más sentido utilizar esa capacidad directamente.

Políticas por contexto

Una política puede ser distinta según aplicación, grupo o red de origen. Por ejemplo, un panel de monitorización puede permitirse desde una VPN corporativa y requerir segundo factor desde otras redes.

El principio importante es evitar excepciones informales que después nadie recuerda.

Qué pasa si Authelia falla

Introducir una capa de autenticación crea una nueva dependencia. Si cae y bloquea todas las aplicaciones críticas, el diseño debe contemplar recuperación y acceso de emergencia.

La resiliencia necesaria depende del impacto: no todos los servicios justifican Redis, PostgreSQL y alta disponibilidad, pero todos necesitan un procedimiento conocido.

Preguntas frecuentes

¿Authelia sustituye el login de cada aplicación?

No siempre. Puede actuar como control previo mediante el reverse proxy, mientras la aplicación mantiene su propia autenticación o integración SSO.

¿2FA elimina el riesgo de phishing?

Lo reduce, pero no lo elimina. El método de segundo factor y el diseño del flujo de autenticación también importan.

¿Es mejor proteger todo con la misma política?

No necesariamente. La política debe seguir el riesgo del servicio y el contexto de acceso.

Identidad y acceso como arquitectura

En Tecnidom combinamos autenticación con segmentación, firewall y monitorización. Esa visión forma parte de nuestras soluciones de redes e infraestructura.

Antonio Domenech Pico
Sobre el autor

Antonio Domenech Pico

Antonio Domenech Pico es administrador de sistemas y fundador de Tecnidom. Cuenta con más de 30 años de experiencia en informática, trabajando con infraestructura, servidores, redes, monitorización, automatización y ciberseguridad para empresas.

Tecnidom

¿Necesitas ayuda con la tecnología de tu empresa?

Podemos revisar contigo qué está ocurriendo, qué riesgos existen y por dónde tiene sentido empezar.