Seguimiento de llamadas API salientes en tu aplicación por qué importan, qué funcionó y qué no. Hace poco tuvimos que realizar un despliegue on-prem para un cliente especialmente sensible al riesgo del sector fintech. Nuestra plataforma está contenedorizada y ya teníamos artefactos para distintos escenarios de despliegue como Helm charts para Kubernetes y plantillas para ECS en AWS. Sin embargo, faltaba algo crítico para un entorno con cortafuegos saliente estricto una lista exhaustiva de todos los endpoints y dominios a los que nuestra aplicación realiza llamadas salientes.
El problema es más común de lo que parece. En nuestra infraestructura habitual no había restricciones salientes, así que utilizábamos librerías, SDKs y servicios de terceros sin llevar un inventario de los dominios a los que se conectaban. En un despliegue on-prem con políticas de red bloqueadas, esta información se convierte en un requisito imprescindible para construir una whitelist que permita operar sin fricción.
Nuestro primer impulso fue el enfoque manual revisar el archivo de dependencias, mirar los SDKs en uso, localizar las llamadas directas en el código con clientes HTTP conocidos y compilar un listado de dominios. Parecía razonable, pero falló. Los SDKs no siempre mapean a un único dominio. Muchos contactan múltiples endpoints, algunos alternan dominios por redundancia y otros realizan llamadas ocultas a servicios inesperados. Ejemplo real una librería de LLM realizó una petición a Azure Blob Storage para descargar un recurso utilizado en el cálculo de tokens, algo nada evidente en la documentación. El resultado del método manual fue incompleto.
Exploramos varias estrategias. Primera idea parchear dinámicamente el cliente requests para registrar cada llamada. Problema no todos los SDKs usan requests, algunos usan httpx, urllib3 o clientes personalizados y se escapaban del registro. Segunda idea interceptar funciones con herramientas como httpretty o wrapt. De nuevo, solo interceptas lo que has parcheado. Tercera idea middleware de logging alrededor de nuestro backend. Útil solo cuando controlas el código que ejecuta las peticiones, pero ineficaz para SDKs opacos que no pasan por esa capa. También probamos captura de paquetes con tcpdump o wireshark, pero el nivel es tan bajo y ruidoso que el análisis se vuelve lento y propenso a errores. Conclusión ninguna de estas vías ofrecía una visión completa.
La solución fiable fue imponer un proxy de salida para todo y registrar allí absolutamente todas las peticiones. Implementamos mitmproxy por su ligereza y facilidad de uso y empezamos a obtener un log claro y consolidado de cada solicitud saliente del backend. La clave está en asegurarse de que todas las librerías respeten el proxy sin tocar cada SDK por separado. Para ello, configuramos las variables de entorno estándar HTTP_PROXY y HTTPS_PROXY que la mayoría de clientes HTTP respetan por defecto. Así conseguimos enrutar requests, httpx y muchos otros sin modificar el código de negocio. Con el proxy registrando tráfico, por fin obtuvimos un inventario completo de dominios y rutas, suficiente para construir la whitelist que exigía el cortafuegos del cliente.
El backend es solo la mitad de la historia. El frontend también puede llamar directamente a servicios de terceros como sistemas de chat de soporte, analítica o trazado de errores. Para capturar este mapa de dependencias del lado cliente, lo más simple fue usar el panel Network de las DevTools de Chrome. Iniciamos la grabación, recorrimos las páginas y flujos principales de la aplicación y exportamos el archivo HAR al finalizar. Ese HAR contiene todas las peticiones salientes del navegador. Con un script sencillo extraemos los dominios únicos y validamos la lista. Un consejo práctico mantener la grabación activa mientras se usa la app de manera normal durante un día para cubrir casos de borde y eventos diferidos.
Lecciones aprendidas no des por hecho que conoces los dominios que toca tu app, los SDKs pueden sorprenderte. La inspección manual rara vez es suficiente. Un enfoque basado en proxy con registro centralizado ofrece la imagen completa en backend. Para frontend, los HAR de DevTools son la solución más directa y fiable. Además, conviene incorporar este proceso a tu ciclo de despliegue on-prem y a tus pruebas de aceptación, para evitar bloqueos de cliente a última hora y acelerar la puesta en producción.
En Q2BSTUDIO ayudamos a empresas a implantar este tipo de prácticas desde el diseño de arquitectura hasta la operación continua, combinando ciberseguridad, observabilidad, automatización y desarrollo de software a medida. Si necesitas validar tu inventario de llamadas salientes, construir una whitelist mantenible, desplegar proxys de salida con mTLS y certificados internos o reforzar tu postura de seguridad, nuestro equipo puede acompañarte de manera integral. Consulta nuestros servicios de ciberseguridad y pentesting para incorporar controles de red, hardening y pruebas de intrusión en tu ciclo de vida.
Diseñamos aplicaciones a medida y software a medida orientados a entornos regulados y a despliegues híbridos, con pipelines que integran pruebas de seguridad, escaneo de dependencias y verificación de endpoints salientes. Descubre cómo abordamos proyectos end to end en desarrollo de aplicaciones a medida, y cómo potenciamos tu ecosistema con inteligencia artificial, ia para empresas, agentes IA y servicios cloud aws y azure. También implementamos servicios inteligencia de negocio con power bi para que tus equipos monitoricen en tiempo real indicadores de disponibilidad, latencia y consumo de terceros, vinculando métricas técnicas con objetivos de negocio.
Checklist rápido para tu próximo on-prem. Uno identifica todas las superficies de salida backend y frontend. Dos obliga el uso de proxy saliente a través de variables de entorno estándar y políticas del sistema. Tres registra y centraliza logs del proxy con retención y trazabilidad. Cuatro ejecuta recorridos de la aplicación reales y prolongados para capturar edge cases y exporta HAR. Cinco consolida el inventario de dominios, rutas y puertos, documenta responsables y define reglas de whitelist con vigencia y proceso de revisión. Seis integra estas verificaciones en CI CD y en tus auditorías de ciberseguridad.
Con un enfoque pragmático y repetible, podrás cumplir con los requisitos de firewall más estrictos sin frenar la entrega de valor. Ya sea que operes con servicios cloud aws y azure, entornos on-prem puros o arquitecturas híbridas, combinar buenas prácticas de ciberseguridad con herramientas como mitmproxy, métricas y automatización te dará visibilidad completa de las dependencias externas de tu software.