¿Qué partes de una aplicación autoalojada necesitan acceso a Internet? Lista de verificación para mapear la exposición

Por qué «accesible públicamente» no es un requisito de despliegue completo

«La aplicación debe ser pública» puede significar varias cosas muy distintas. Puede significar que cualquier persona debe poder cargar un sitio web, que solo empleados identificados deben poder iniciar sesión desde cualquier lugar, que un sistema asociado debe entregar webhooks o que la aplicación simplemente necesita llamar a una API externa. Estos requisitos llevan a decisiones diferentes sobre la exposición de red.

Considera la accesibilidad entrante y la conectividad saliente como decisiones independientes. En las redes de Docker, un contenedor puede establecer conexiones salientes cuando su host tiene acceso a Internet, mientras que un puerto de contenedor normalmente no es accesible desde fuera del host a menos que se publique o enrute deliberadamente. Por tanto, una aplicación puede necesitar acceso a Internet sin requerir un puerto de aplicación accesible públicamente.

El objetivo no es hacer privado cada componente ni público cada componente. El objetivo es autorizar explícitamente cada flujo de datos, exponer solo los puntos de entrada necesarios y registrar por qué existe cada uno. Esto se alinea con el resultado del Marco de Ciberseguridad 2.0 de NIST de mantener representaciones de las comunicaciones de red y los flujos de datos internos y externos autorizados.

• Sustituye «público» por una declaración específica: quién se conecta, desde dónde, a qué nombre de host, mediante qué protocolo y con qué finalidad.
• Separa el acceso desde navegadores, las solicitudes entrantes de sistema a sistema, las llamadas salientes y el acceso de administradores.
• Decide si cada flujo corresponde a la Internet pública, se limita a direcciones IP conocidas, es exclusivo de una red privada o no está permitido.
• Registra los datos intercambiados en cada flujo, especialmente credenciales, datos personales, registros de clientes, archivos y tokens de API.

Empieza con un mapa de exposición: usuarios, administradores, integraciones y servicios de soporte

Un mapa de exposición es un inventario práctico de las rutas de comunicación permitidas de la aplicación. Créalo antes de elegir dominios, abrir reglas de firewall o publicar puertos de contenedor. Debe abarcar más que la pantalla principal de la aplicación: los servicios de soporte, las herramientas administrativas, los sistemas de identidad, los proveedores de correo y los destinos de monitorización también pueden generar dependencias de red.

Empieza enumerando activos y actores. NIST CSF 2.0 considera el software, los servicios, los sistemas, los datos y los servicios de proveedores como activos que deben identificarse y gestionarse. Para un despliegue autoalojado, esto significa documentar tanto los componentes propios como los servicios externos con los que se comunican.

Después, dibuja flechas direccionales. Cada flecha debe tener un responsable y una decisión: permitida, restringida, solo privada o rechazada. Esto hace visibles las suposiciones ocultas desde el principio; por ejemplo, un flujo de trabajo de automatización que debe recibir un webhook de un proveedor o un panel interno que se asumió accesible desde todas las redes de empleados.

• Usuarios: visitantes públicos, clientes, personal, contratistas, usuarios móviles y cuentas de servicio.
• Administradores: administradores de la aplicación, administradores de infraestructura y personal de soporte.
• Integraciones entrantes: webhooks, clientes de API, devoluciones de llamada de proveedores de identidad y sistemas asociados.
• Integraciones salientes: entrega de correo, proveedores de identidad, API externas, descargas de software, descargas de modelos y destinos de monitorización.
• Servicios de soporte: bases de datos, cachés, colas, almacenamiento de objetos, servicios de búsqueda, proxies inversos y paneles administrativos.
• Para cada flujo, registra origen, destino, protocolo y puerto, nombre de host, dirección, método de autenticación, clasificación de datos, responsable y justificación de negocio.

Clasifica el acceso entrante: interfaz web pública, usuarios autenticados, puntos de acceso de socios y receptores de webhooks

El acceso entrante es lo que la mayoría de los equipos entiende por exposición, pero debe dividirse en clases diferenciadas. Una interfaz pública de marketing o publicación tiene un perfil de riesgo distinto al de una aplicación solo para empleados. Un receptor de webhooks puede necesitar aceptar solicitudes desde un sistema externo incluso cuando ninguna interfaz dirigida a personas deba estar ampliamente disponible.

Utiliza el proxy inverso como punto de entrada entrante intencional. En el modelo de Traefik, los puntos de entrada reciben tráfico TCP o UDP, los enrutadores hacen coincidir las solicitudes entrantes y los servicios reciben el tráfico de backend enrutado. Esto permite un diseño en el que el proxy acepta solo tráfico aprobado mientras los contenedores de la aplicación permanecen detrás de él.

Cuando un punto de acceso se utiliza únicamente por partes conocidas, documenta si una regla basada en IP es adecuada además de la autenticación a nivel de aplicación. Traefik proporciona un mecanismo de lista de permitidos de IP que acepta o rechaza solicitudes antes de que lleguen a un backend. Esto puede reducir la exposición innecesaria, pero depende de direcciones de origen estables e identificadas correctamente y no debe considerarse un sustituto de una autenticación adecuada.

• Interfaz web pública: destinada a visitantes no autenticados; expón solo las rutas web y el nombre de host necesarios.
• Acceso de usuarios autenticados: destinado a clientes o personal; define los requisitos de identidad, inicio de sesión, sesión y acceso en el diseño de la aplicación.
• Punto de acceso de API para socios: define el socio, el método de autenticación, la red de origen esperada, las expectativas de tasa y las rutas exactas.
• Receptor de webhooks: define el emisor, la validación de firma o autenticación, la ruta, los datos de carga útil esperados y la gestión de fallos.
• Interfaz administrativa: clasifícala por separado de la aplicación principal; no supongas que pertenece al nombre de host público.
• Rechaza la exposición comodín: un puerto o nombre de host accesible externamente debe tener una finalidad y un responsable identificados.

Identifica las dependencias salientes antes de asumir que la aplicación puede ejecutarse de forma privada

El acceso entrante privado no significa que una aplicación no tenga dependencia de Internet. Muchas cargas de trabajo empresariales, de automatización y de IA necesitan iniciar conexiones a servicios fuera del host. Estas pueden incluir servicios de entrega de correo, proveedores de identidad, API de terceros, fuentes de paquetes, descargas de modelos o destinos de monitorización.

Para cada dependencia, determina si es necesaria durante la instalación, al inicio, según una programación o durante la actividad normal de los usuarios. Esta distinción importa en entornos restringidos. Una descarga única de software o modelo se puede gestionar de forma distinta de una conexión permanente a un proveedor de identidad o a una API empresarial externa.

No describas el acceso saliente como un único permiso general. Identifica el nombre de host o servicio de destino, el protocolo, la finalidad operativa, los datos enviados y recibidos, la credencial utilizada y el comportamiento alternativo cuando el destino no está disponible. Revisa la documentación oficial de la aplicación e integración concretas, ya que las dependencias varían según el producto y la configuración.

• Entrega de correo: identifica el proveedor, el método de conexión, la identidad del remitente y si la aplicación necesita enviar restablecimientos de contraseña, notificaciones o mensajes de flujos de trabajo.
• Proveedor de identidad: identifica los puntos de acceso de autenticación, los puntos de acceso de tokens, los detalles del emisor y si el inicio de sesión deja de funcionar cuando no se puede contactar con el proveedor.
• API externas: enumera cada proveedor por separado, los datos intercambiados, el enfoque de almacenamiento de credenciales y si las llamadas se activan por usuarios o se automatizan.
• Descargas de paquetes, plugins o modelos: establece si se necesita acceso a Internet solo durante la configuración o las actualizaciones, o habitualmente durante la ejecución.
• Monitorización e informes de errores: establece qué datos de telemetría o eventos salen del entorno y quién aprueba esa transferencia.
• Comprobaciones de actualizaciones y llamadas relacionadas con licencias: verifícalas directamente en la documentación oficial del proveedor en lugar de asumir que son necesarias o que no existen.

Mantén los servicios de datos privados de forma predeterminada

Una base de datos, caché, cola, almacén de objetos o servicio de búsqueda suele ser un componente de soporte, no un producto orientado a Internet. Parte de un acceso exclusivamente privado y añade una ruta solo cuando exista una razón operativa documentada. En una configuración de puente de Docker, los servicios conectados al host o a la misma red pueden comunicarse según se configure, mientras que los puertos de contenedor no son accesibles desde fuera del host de forma predeterminada a menos que se publiquen o enruten deliberadamente de otro modo.

Ten especial cuidado con la publicación por conveniencia. Docker documenta que publicar un puerto sin especificar una dirección de host lo vincula a todas las direcciones del host de forma predeterminada, lo que puede hacer que el servicio sea accesible externamente. Si un servicio está destinado solo al host local en el escenario documentado de modo NAT, vincularlo a loopback es una forma de impedir que hosts remotos accedan a ese puerto publicado.

Los planos de control administrativos merecen el mismo tratamiento privado por defecto. Traefik advierte que su API y panel de producción pueden exponer elementos de configuración, incluidos datos confidenciales, y recomienda restringir su puerto de API a redes internas. Aplica este principio también a las interfaces de administración de aplicaciones, las interfaces de gestión de contenedores y las herramientas de observabilidad.

• Bases de datos: permite el acceso solo desde los componentes de la aplicación y las rutas de mantenimiento aprobadas.
• Cachés y colas: mantenlas en redes privadas; no las expongas simplemente para facilitar la solución de problemas.
• Almacenamiento de objetos y servicios internos de archivos: define qué componentes de la aplicación requieren acceso y cómo interactúan las copias de seguridad con ellos.
• Servicios de búsqueda, vectores y soporte de IA: documenta si son backends internos o API deliberadas para otros sistemas.
• Paneles de proxy, paneles de administración de aplicaciones y planos de control de infraestructura: utiliza rutas de acceso separadas y restringidas.
• Antes del lanzamiento, revisa cada puerto publicado y confirma su vinculación de host, los clientes previstos y el responsable.

Revisa los casos límite comunes que cambian el diseño de acceso

Varios detalles del despliegue se descubren fácilmente demasiado tarde, después de que ya se haya elegido un nombre de host o una política de firewall. Abórdalos pronto porque pueden determinar si se requiere un nombre de host público, una ruta de devolución de llamada estable o una fuente de red determinada.

OAuth es un ejemplo clave. Las URL de redirección y devolución de llamada son requisitos de despliegue, no ajustes estéticos. RFC 9700 exige que los servidores de autorización usen coincidencia exacta de cadenas con las URI de redirección preregistradas, salvo el tratamiento de localhost especificado para aplicaciones nativas. Por tanto, un cambio de esquema, nombre de host, ruta o barra final puede interrumpir el inicio de sesión.

Protege también la propia ruta de devolución de llamada. RFC 9700 advierte que los puntos de acceso de URI de redirección no deben actuar como redireccionadores abiertos. También identifica un riesgo cuando las páginas que manejan respuestas OAuth enlazan a páginas controladas por atacantes o cargan contenido de terceros que podría revelar la URL de respuesta de autorización mediante la cabecera Referer. Mantén el manejo de devoluciones de llamada deliberadamente limitado y evita contenido de terceros incrustado innecesario en esa página.

• OAuth y SSO: confirma la URL externa exacta, el protocolo, el nombre de host y la ruta de devolución de llamada que deben registrarse con el proveedor de identidad.
• Contenido incrustado: identifica iframes, scripts, imágenes o widgets que se conecten a terceros, especialmente en las páginas de respuesta de autenticación.
• Clientes móviles y de escritorio: confirma si requieren un punto de acceso público, un nombre de host fijo, tratamiento de localhost o una ruta de red privada.
• Listas de permitidos de IP: valida las direcciones de origen reales después de considerar intermediarios, NAT, redes de distribución de contenido o infraestructura de socios.
• Correo entrante o transferencias de archivos: determina si se entregan directamente a la aplicación o se recuperan de forma saliente desde otro servicio.
• WebSockets, streaming y conexiones de larga duración: verifica los requisitos del proxy y de la aplicación en la documentación oficial en lugar de asumir que los valores predeterminados de HTTP ordinario son suficientes.

Preguntas que verificar en la documentación oficial de la aplicación antes del despliegue

La documentación de la aplicación es la autoridad para los requisitos específicos de cada producto. No infieras que una aplicación admite un despliegue privado, un comportamiento concreto de proxy, un proveedor de SSO o un patrón de webhooks solo porque otra aplicación sí lo hace. Confirma los requisitos con la documentación oficial de la versión y configuración que piensas utilizar.

Las respuestas deben incluirse en el mapa de exposición y revisarse cuando cambien las integraciones. Si la documentación deja una pregunta sin resolver, trátala como un riesgo de implementación en lugar de llenar el vacío con una suposición.

Esta verificación es especialmente importante para las aplicaciones que combinan una interfaz web con trabajadores en segundo plano, motores de automatización, servicios de modelos de IA o múltiples contenedores de soporte. La interfaz visible en el navegador suele ser solo una parte del diseño operativo.

• ¿Qué puertos y protocolos entrantes se requieren, si se requiere alguno, y qué componente termina TLS?
• ¿Puede la aplicación funcionar detrás de un proxy inverso y necesita ajustes de proxy de confianza o de URL externa?
• ¿Qué URL canónica o base requiere la aplicación?
• ¿Qué rutas deben recibir webhooks, devoluciones de llamada OAuth, aserciones SSO o solicitudes de API de socios?
• ¿Qué nombres de host salientes o categorías de servicio se requieren para el funcionamiento normal, la configuración, las actualizaciones, el correo, la identidad, la monitorización o las integraciones opcionales?
• ¿Qué servicios de datos se requieren y deben sus puertos permanecer privados?
• ¿Se requieren procesos o contenedores de trabajo separados y a qué necesitan conectarse?
• ¿Qué datos de copia de seguridad, ubicaciones de almacenamiento y pasos de restauración se requieren? Airbip proporciona copias de seguridad diarias, semanales y mensuales configurables, pero el propietario de la aplicación aún debe decidir qué datos se incluyen y probar procedimientos de restauración adecuados para su entorno.

Integra dominios, TLS y proxies inversos en el diseño sin exponer servicios innecesarios

Elige los dominios después de identificar los puntos de entrada previstos. Un nombre de host debe representar una finalidad de acceso deliberada, como una aplicación orientada al usuario, un punto de acceso de webhooks de alcance limitado o una ruta de administración con restricciones adicionales. Evita crear nombres DNS públicos para servicios internos solo porque son cómodos de recordar.

La validación de certificados TLS también forma parte del diseño de exposición. Con la validación HTTP-01 de Let’s Encrypt, la autoridad de certificación recupera un archivo de desafío en el nombre de host, y el desafío HTTP-01 está limitado al puerto 80. Puede ser apropiado para un punto de acceso web público, pero es un requisito concreto de accesibilidad que se debe planificar. La validación DNS-01 de Let’s Encrypt puede validar nombres cuyos servidores web no están expuestos a la Internet pública, porque la validación se realiza mediante un registro TXT de DNS.

Un proxy inverso permite a un equipo convertir el proxy, y no cada componente de la aplicación, en el perímetro público seleccionado. Puede enrutar nombres de host y rutas aprobados hacia servicios de backend mientras los puertos de backend permanecen privados. Esto no hace automáticamente segura una arquitectura; el equipo aún necesita una configuración correcta de la aplicación, controles de acceso, propiedad de DNS, renovación de certificados y control de cambios.

Airbip despliega aplicaciones del catálogo como cargas de trabajo de Docker en servidores cloud de Airbip y automatiza el enrutamiento y los certificados TLS mediante Traefik y Let’s Encrypt. Los clientes pueden utilizar un subdominio de Airbip o un dominio personalizado compatible. Estas capacidades son útiles cuando el diseño documentado requiere un punto de acceso público gestionado para la aplicación, pero no eliminan la necesidad de decidir qué rutas y flujos de datos están aprobados.

• Asigna un responsable para cada zona DNS y nombre de host.
• Documenta si la validación de certificados utiliza una ruta HTTP pública o validación DNS, según el diseño de acceso.
• Expón los puntos de entrada del proxy inverso requeridos por los servicios públicos aprobados; mantén privados los puertos de los servicios de backend.
• Utiliza nombres de host separados o rutas cuidadosamente delimitadas cuando las funciones públicas y restringidas no puedan separarse claramente dentro de la aplicación.
• Prueba el resultado visible externamente desde fuera de la red del servidor, no solo desde el propio host.
• Revisa las responsabilidades de renovación de certificados y cambios de DNS como parte de la propiedad operativa.