¿Tu aplicación autoalojada necesita una IP de salida estable? Lista de verificación para la inclusión en listas de permitidos
Un dominio personalizado y HTTPS hacen que una aplicación sea accesible desde internet, pero no establecen la dirección de origen que ven los servicios externos cuando la aplicación se conecta hacia fuera. Usa esta lista de verificación para detectar dependencias de salida, comprobar si la inclusión de IP en listas de permitidos es necesaria y planificar cambios seguros.
Empieza por la pregunta correcta: la accesibilidad entrante no es la identidad saliente
Una IP de salida estable es una dirección IP de origen enrutable por internet que un destino ve de forma coherente cuando tu aplicación inicia una conexión. Es importante cuando ese destino permite conexiones únicamente desde direcciones de origen aprobadas previamente, lo que suele denominarse inclusión de IP de origen en listas de permitidos o inclusión de salida en listas de permitidos.
Esto es independiente de cómo llegan las personas a tu aplicación. Un dominio personalizado identifica a dónde envían los usuarios las solicitudes entrantes. Los certificados TLS protegen esas conexiones entrantes y validan el control de los nombres incluidos en el certificado. Un router proxy inverso, como Traefik, recibe solicitudes entrantes, aplica las reglas de enrutamiento configuradas y reenvía las solicitudes coincidentes a un servicio. Ninguna de esas funciones, por sí sola, demuestra qué dirección de origen verá una API de terceros, una base de datos o un endpoint de un socio para el tráfico que sale de la aplicación.
En los despliegues de Airbip, las aplicaciones se ejecutan como cargas de trabajo Docker en servidores en la nube de Airbip, mientras que el enrutamiento y los certificados TLS se automatizan mediante Traefik y Let’s Encrypt. Son capacidades valiosas de acceso entrante, pero no deben tratarse como una promesa de direccionamiento saliente fijo. Establece los requisitos de salida por separado y obtén pruebas específicas del proveedor antes de depender de una lista de IP permitidas.
- Pregunta entrante: ¿qué dominio, puerto, ruta y configuración TLS permiten que los usuarios o webhooks lleguen a la aplicación?
- Pregunta saliente: ¿qué direcciones IPv4 e IPv6 de origen observa cada destino cuando la aplicación, un worker o un proceso de administración se conecta hacia fuera?
- Pregunta de control: ¿la inclusión de IP de origen en listas de permitidos es una política obligatoria del receptor, o simplemente una opción entre controles más sólidos o más fáciles de mantener?
Identifica cada conexión que pueda depender de la inclusión de IP de origen en listas de permitidos
No limites la revisión a la función principal orientada al usuario de la aplicación. La salida suele producirse en trabajos programados, workers de colas, herramientas de importación/exportación, integraciones de monitorización, comprobaciones de actualizaciones, flujos de trabajo relacionados con copias de seguridad y rutas de acceso de administradores. Un despliegue puede parecer saludable en una prueba interactiva mientras que un worker asíncrono falla más tarde porque utiliza un proceso o una ruta de red diferente.
Empieza por los sistemas que se sabe que restringen las direcciones de red de los clientes. Los candidatos habituales incluyen API de terceros, bases de datos gestionadas, sistemas de pagos o finanzas, endpoints privados de socios, redes corporativas internas, sistemas de monitorización, herramientas de gestión, servicios de acceso remoto y administración SSH. Con independencia de las listas de permitidos, las conexiones salientes que manejan tráfico sensible u operacionalmente importante deben usar protocolos cifrados como TLS cuando corresponda; OWASP ASVS incluye explícitamente API externas, bases de datos, sistemas de socios, monitorización, herramientas de gestión, acceso remoto y SSH en sus directrices sobre comunicación entre servicios.
Clasifica cada conexión según su consecuencia para el negocio, no solo por el protocolo técnico. Una llamada opcional de analítica tiene un efecto de fallo diferente de una acción de pago, una exportación financiera, una sincronización de datos de clientes o una conexión a un sistema interno privado.
- Llamadas interactivas de la aplicación realizadas mientras un usuario está activo
- Trabajos programados, tareas similares a cron y generación de informes
- Consumidores de colas, workers y flujos de automatización
- Webhooks, callbacks y llamadas API a servicios SaaS
- Conexiones a bases de datos, transferencia de archivos y redes privadas
- Conexiones de monitorización, alertas, registro, administración y acceso remoto
- Procedimientos de migración, recuperación y conmutación por error que puedan generar tráfico desde un entorno diferente
Crea un inventario de dependencias de salida antes del despliegue
Trata las dependencias de salida como un inventario de sistemas que se mantiene, no como una hoja de cálculo de una sola vez. El control de inventario de componentes de NIST SP 800-53 destaca la documentación precisa, la información de responsabilidad y la revisión periódica. Aplica la misma disciplina a los destinos externos: una regla de lista de permitidos que nadie posee ni revisa se convierte en un riesgo predecible de interrupción.
Registra una fila por cada destino y ruta de tráfico. Si un servidor de aplicaciones y un worker en segundo plano llaman a la misma API por rutas distintas, regístralos por separado hasta contar con pruebas de que sus direcciones de origen observadas son iguales. Incluye ambas familias de direcciones: un resultado IPv4 no establece el comportamiento de IPv6.
Pide al propietario del destino que indique su regla de aceptación real. «Nuestro firewall usa una lista de permitidos» es incompleto. Debes saber si evalúa IPv4, IPv6, un puerto y protocolo específicos, un rango de IP, una conexión privada o una combinación de controles de red y de capa de aplicación.
- Destino: nombre de host, nombre del servicio, entorno y organización receptora
- Ruta de tráfico: proceso de aplicación, worker, programador, host de administración o procedimiento de recuperación
- Protocolo y puerto: por ejemplo, HTTPS, TLS de base de datos, SFTP o SSH
- Autenticación: credencial de API, solicitud firmada, certificado de cliente, credencial de usuario u otro método documentado
- Datos intercambiados: clasificación, dirección y sensibilidad
- Identidad de origen observada: direcciones IPv4 e IPv6 confirmadas, o marcada como no verificada
- Requisito de lista de permitidos: obligatorio, opcional, desconocido o no compatible
- Efecto del fallo: funcionalidad degradada, flujo de trabajo retrasado, transacción fallida, brecha de sincronización de datos o bloqueo operativo","Propietario y ruta de escalado: quién puede cambiar el lado emisor y quién puede cambiar la regla del lado receptor","Notificación de cambios: cómo comunica cada parte cambios de dirección, red, migración o política","Fecha de evidencia: cuándo se probaron por última vez la ruta y la identidad de origen observada"],
Comprueba si una lista de IP permitidas es realmente necesaria
La inclusión de IP de origen en listas de permitidos puede ser una restricción adicional útil, especialmente cuando un servicio receptor tiene opciones limitadas de control de acceso. Sin embargo, no es una prueba de identidad de la carga de trabajo. La traducción de red puede hacer que varias cargas de trabajo aparezcan bajo una dirección externa, mientras que una conmutación por error, migración o cambio de enrutamiento puede alterar la dirección que ve un destino. Las directrices de confianza cero de NIST desplazan el énfasis de la confianza implícita basada solo en la ubicación de red hacia la autenticación y autorización explícitas de sujetos y dispositivos; sus directrices cloud-native destacan de forma similar las identidades de aplicaciones y servicios, al tiempo que permiten usar parámetros de red como entradas adicionales.
Pregunta al servicio receptor qué controles admite y cuáles considera autorizados. Prefiere un diseño por capas: transporte cifrado, autenticación y autorización sólidas, credenciales de alcance limitado y una restricción de IP solo cuando añada una barrera independiente significativa o siga siendo un requisito contractual.
La TLS mutua es una opción especialmente sólida cuando se admite y opera correctamente. OWASP ASVS identifica la autenticación de cliente TLS, respaldada por infraestructura de clave pública y mecanismos resistentes a la repetición, como una forma sólida de verificar endpoints en la comunicación entre servicios. Otros patrones posibles dependen del servicio receptor: credenciales de corta duración, solicitudes firmadas, conectividad privada o un modelo de acceso basado en identidad. No afirmes equivalencia sin comprobar la documentación del destino y los requisitos de gobernanza.
- ¿La regla de IP está exigida por el destino, una política de cliente, un contrato o simplemente una práctica histórica?
- ¿Puede el destino utilizar TLS mutua, credenciales de corta duración, solicitudes firmadas o conectividad privada en su lugar?
- ¿Pueden limitarse las credenciales a las acciones, los datos y el entorno mínimos?
- ¿Está habilitado TLS y correctamente configurada la validación de certificados para la conexión?
- ¿Sería una regla de IP una salvaguarda adicional en lugar del único control?
- ¿Puede rotarse, auditarse y probarse el método elegido sin una ventana de interrupción prolongada?
Comprende la arquitectura detrás de la identidad saliente
La identidad saliente es una propiedad de toda la ruta de tráfico, no de una URL de aplicación. En la traducción de direcciones de red tradicional, una dirección privada puede vincularse a una dirección externa cuando empieza una sesión saliente, y el origen del paquete puede traducirse a una dirección globalmente única. En las redes bridge de Docker en Linux, Docker documenta reglas de NAT y enmascaramiento para el tráfico de contenedores. Docker también distingue este enmascaramiento saliente de los puertos publicados, que se refieren principalmente a permitir que hosts remotos lleguen a los contenedores a través de direcciones del host.
En los despliegues en contenedores, la dirección que acepta tráfico en un puerto publicado puede no ser la que observa un destino remoto para la salida del contenedor. Una declaración significativa sobre la identidad saliente debe definir las cargas de trabajo pertinentes, la familia de direcciones, las rutas y el comportamiento ante fallos o migraciones.
Los entornos de doble pila requieren pruebas explícitas. La selección de origen y destino IPv6 tiene sus propias reglas, y la selección de destino puede preferir IPv6 o IPv4 según las direcciones de origen disponibles. Por tanto, una lista de permitidos solo para IPv4 no establece que un cliente vaya a usar IPv4. Si el destino publica conectividad IPv6, prueba lo que hace realmente tu carga de trabajo y asegúrate de que la política del destino cubra la ruta seleccionada.
- NAT y enmascaramiento: ¿qué dirección se traduce y en qué punto de la ruta se produce la traducción?
- Salida de contenedor a host: ¿comparten una ruta los contenedores de aplicación, los workers y las tareas de mantenimiento?
- IPv4 e IPv6: ¿qué familia se selecciona para cada destino y está incluida en la lista de permitidos?
- Múltiples instancias: ¿pueden las réplicas, los workers o servicios independientes tener identidades de salida diferentes?
- Conmutación por error y migración: ¿qué verá el destino tras una sustitución, restauración o reubicación?
- Cambios de red gestionados por el proveedor: ¿se documentan y comunican los posibles cambios de dirección?
Haz preguntas precisas y basadas en evidencia a los proveedores de infraestructura
Evita preguntar solo: «¿Tenéis una IP estática?». La respuesta puede ser engañosa si no indica la dirección del tráfico y el alcance. Solicita respuestas por escrito vinculadas a la carga de trabajo prevista y a los destinos que requieren restricciones. Un proveedor puede documentar una dirección de servidor entrante sin asumir ningún compromiso sobre todas las rutas de tráfico saliente.
Airbip está diseñado para hacer prácticas las aplicaciones empresariales y de IA autoalojadas mediante la gestión de la infraestructura en la nube circundante, incluidas las cargas de trabajo de aplicaciones basadas en Docker, el enrutamiento, la automatización TLS, las comprobaciones DNS, la gestión del ciclo de vida y las copias de seguridad configurables. Si tu despliegue tiene un requisito estricto de salida estable, confirma ese requisito con Airbip antes del despliegue en vez de inferirlo a partir de un dominio personalizado, una dirección pública de aplicación o el comportamiento del proxy entrante. Si un diseño de salida fijo y controlado por el cliente no es negociable y no puede demostrarse para la ruta requerida, elige un modelo de infraestructura que pueda cumplirlo y documentarlo.
Conserva las respuestas del proveedor junto con tu inventario de dependencias. El resultado útil no es una garantía vaga; es una declaración operativa verificable que describa las direcciones observadas, las rutas cubiertas, las condiciones de cambio y el proceso de notificación.
- ¿Qué direcciones IPv4 e IPv6 salientes utilizará cada carga de trabajo y proceso especificados?
- ¿Están documentadas esas direcciones como estables o pueden cambiar? ¿En qué eventos?
- ¿Qué tráfico está cubierto: contenedor de aplicación, worker, programador, proceso de mantenimiento, copias de seguridad, acceso administrativo y entorno de recuperación?
- ¿La declaración cubre solo el funcionamiento normal o también la conmutación por error, la migración, la reconstrucción y la restauración?
- ¿Qué aviso se da antes de un cambio relevante de dirección de salida y a través de qué canal?
- ¿Puede el proveedor proporcionar un método de prueba seguro o evidencia de la ruta activa?
- ¿Quién es responsable del soporte y la coordinación si un destino rechaza la dirección de origen observada?
Planifica los cambios de listas de permitidos como una entrega controlada
Una actualización de lista de permitidos abarca dos planos de control: la ruta de tráfico real del emisor y la política de aceptación del receptor. Coordina a ambos propietarios, elige una ventana de cambio de bajo riesgo y define el éxito mediante una conexión autenticada real en lugar de una búsqueda DNS o una prueba de navegador. Que un navegador llegue a tu aplicación solo confirma el acceso entrante.
Cuando el servicio receptor lo permita, autoriza temporalmente tanto las direcciones exactas antiguas como las nuevas. Este solapamiento te da una ventana de verificación y permite la reversión si falla la nueva ruta. Elimina la entrada antigua sin demora tras el periodo de validación acordado. No compenses la incertidumbre incluyendo rangos públicos excesivamente amplios en listas de permitidos; eso debilita el límite y dificulta las revisiones posteriores.
Para cada cambio, registra el destino probado, el protocolo, la familia de direcciones, la dirección de origen observada, la marca de tiempo y la función de aplicación. Verifica el trabajo en segundo plano además de una solicitud interactiva. Después actualiza el inventario y asegúrate de que cada parte sepa quién elimina las reglas temporales.
- Designa un responsable del cambio, un responsable del lado receptor, un aprobador y un responsable de reversión.
- Confirma el nombre de host o endpoint exacto del destino, el protocolo, el puerto y el entorno.
- Obtén las direcciones IPv4 e IPv6 de origen propuestas a partir de evidencia, no de supuestos.
- Añade un solapamiento temporal de direcciones exactas si el servicio receptor lo admite.
- Prueba una transacción autenticada y representativa desde cada proceso relevante.
- Comprueba los registros y la evidencia del lado del destino para la dirección de origen realmente observada.
- Fija una fecha límite para eliminar la entrada antigua y registra la confirmación.
- Mantén una vía de contacto de emergencia para una conexión rechazada o una reversión.
Prepárate para los modos de fallo que sorprenden a los equipos
Que un destino rechace una dirección de origen modificada es el fallo más visible, pero no es el único. El patrón común es un alcance incompleto: el equipo validó una solicitud web, mientras un worker, un programador o un procedimiento de recuperación tomó otra ruta. Diseña las pruebas en torno a flujos de trabajo empresariales y eventos operativos, no a un solo comando curl exitoso.
Una ruta IPv6 también puede eludir una regla exclusiva de IPv4 si el cliente y el destino seleccionan IPv6. A la inversa, una prueba exclusiva de IPv4 puede ocultar un destino que no tiene una política IPv6 utilizable. Incluye ambas familias en el plan de pruebas previo al despliegue y documenta una decisión deliberada si una familia está deshabilitada o no es compatible para una conexión específica.
La migración, la reconstrucción, la restauración y la conmutación por error merecen la misma revisión que el despliegue inicial. Si cualquiera de estas puede crear una nueva identidad de salida, la lista de permitidos del lado receptor debe estar preparada antes del evento o el servicio debe tener una ruta de actualización de emergencia probada. Si el tiempo de inactividad o la inclusión estricta en listas de permitidos externas no pueden tolerar esa incertidumbre, una arquitectura de red o modelo de alojamiento diferente puede ser la elección responsable.
- Dirección de origen modificada: activa la regla de solapamiento o revierte el cambio y, después, confirma la dirección de origen en el destino.
- Ruta de worker diferente: prueba cada worker y tarea programada por separado; no te bases en el resultado del proceso web.
- Elusión mediante IPv6: inspecciona la resolución del destino y los registros de conexión; añade la regla IPv6 correcta o impón la ruta compatible prevista.
- Identidad de migración inesperada: pausa los flujos de trabajo dependientes cuando sea seguro, aplica el proceso de cambio preaprobado y ejecuta una verificación representativa.
- Regla sin propietario: asigna un propietario de servicio y un contacto del lado receptor antes de la siguiente ventana de cambio.
- Rango amplio de emergencia propuesto: trátalo como una excepción limitada en el tiempo que requiere aprobación explícita y una fecha de eliminación.
Preguntas frecuentes
¿Un dominio personalizado proporciona a mi aplicación autoalojada una IP de salida estable?
No. Un dominio personalizado forma parte de la nomenclatura y el enrutamiento entrantes. No establece la dirección IP de origen que ven los servicios externos cuando la aplicación inicia conexiones salientes.
¿Un proxy inverso o un certificado TLS determina la identidad de salida?
No. Los proxies inversos como Traefik enrutan las solicitudes entrantes hacia los servicios, y los certificados TLS validan el control de los nombres de dominio y protegen las conexiones. La identidad de origen saliente depende de la ruta de red de salida, incluidos el enrutamiento y la traducción de direcciones.
¿Por qué un contenedor Docker puede tener una identidad saliente distinta de la URL pública de la aplicación?
La publicación de puertos entrantes y el enmascaramiento saliente son funciones de red independientes. Docker documenta reglas NAT tanto para el mapeo de puertos como para el enmascaramiento, por lo que no debe suponerse que la dirección utilizada para el acceso entrante sea la dirección vista por un destino saliente.
¿Debemos usar listas de IP permitidas en lugar de una autenticación sólida?
Por lo general, trata la inclusión de IP en listas de permitidos como una restricción adicional, no como la única decisión de confianza. Cuando sean compatibles, evalúa el transporte cifrado, las credenciales de alcance limitado, las solicitudes firmadas, la TLS mutua, la conectividad privada o los controles basados en identidad. La elección correcta depende del servicio receptor y de tus requisitos de gobernanza.
¿Necesitamos revisar IPv6 para la inclusión de salida en listas de permitidos?
Sí, en un entorno de doble pila. Puede llegarse a un destino mediante IPv6 o IPv4 según las direcciones disponibles y el comportamiento de selección. Prueba la ruta de conexión real y asegúrate de que las reglas del servicio receptor cubren la familia de direcciones en uso.
¿Qué deberíamos preguntar a Airbip antes de desplegar una aplicación con una lista de salida estricta?
Pide evidencia sobre las direcciones IPv4 e IPv6 salientes para las cargas de trabajo y los procesos específicos implicados, si pueden cambiar, qué rutas de tráfico están cubiertas, qué ocurre durante la migración o la recuperación y cómo se comunican los cambios relevantes. No infieras un comportamiento de salida fijo a partir de un subdominio de Airbip, un dominio personalizado, el enrutamiento o la configuración TLS.
Fuentes y lecturas adicionales
- Packet filtering and firewalls — Docker
- Docker with iptables — Docker
- HTTP Router — Traefik Labs
- Challenge Types — Let’s Encrypt / Internet Security Research Group
- RFC 3022: Traditional IP Network Address Translator — IETF / RFC Editor
- RFC 6724: Default Address Selection for IPv6 — IETF / RFC Editor
- Application Security Verification Standard: General Service-to-Service Communication Security — OWASP
- SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments — NIST
- SP 800-207: Zero Trust Architecture — NIST
- SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations — NIST