# Separe su borde web público de la aplicación | SwissOctet Insights https://swissoctet.com/es/insights/separate-the-web-edge-from-the-app/ SwissOctet / Perspectivas / Web y onion Web y onion Aplicado · 4 min de lectura Separe su borde web público de la aplicación Asigne responsabilidades distintas al servidor web, al proxy inverso y a la aplicación, con acceso deliberado al origen, TLS, límites de solicitudes y una ruta de incidentes. Por SwissOctet Editorial Guardar guía Copiar enlace EN ESTA PÁGINA 01 Una solicitud web atraviesa varias responsabilidades 02 Utilice el borde para organizar el comportamiento de HTTP 03 Un proxy inverso no elimina la exposición del origen 04 Aplique las decisiones de acceso dentro de la aplicación 05 Planifique la denegación de servicio en más de una capa 06 Haga que la recuperación forme parte de la publicación Su lista de verificación práctica Fuentes y lecturas adicionales Volver a la biblioteca LA RESPUESTA DIRECTA Separe la publicación de HTTP de la ejecución de la aplicación y los datos persistentes. Un proxy inverso puede organizar el enrutamiento y los límites, pero el acceso al origen, la autorización de la aplicación, la capacidad ascendente y la recuperación requieren cada uno sus propios controles. 01 Una solicitud web atraviesa varias responsabilidades Un servidor web recibe solicitudes HTTP y puede servir archivos estáticos. Un proceso de aplicación ejecuta el comportamiento dinámico del proyecto, como comprobar una cuenta o consultar una base de datos. Un proxy inverso recibe solicitudes en nombre de ese proceso y las reenvía a un upstream. Un programa puede cumplir varias funciones, pero separar las responsabilidades facilita el razonamiento sobre la configuración y la recuperación. Siga una solicitud desde la resolución del nombre de host hasta la respuesta. Registre dónde termina TLS, qué proceso elige la ruta y qué componente puede leer los datos de la aplicación. Haga lo mismo con una solicitud administrativa. Este ejercicio suele exponer un listener o nombre de host que se creó para pruebas y permaneció accesible por accidente. El diagrama debe describir la ruta implementada en lugar de la arquitectura que esperaba construir. 02 Utilice el borde para organizar el comportamiento de HTTP NGINX documenta tanto el servicio de contenido estático como el reenvío de solicitudes a un upstream. Su arquitectura de workers y sus módulos HTTP proporcionan mecanismos de configuración, pero una configuración concreta sigue determinando el comportamiento. Defina deliberadamente los nombres de host, los upstreams y las raíces del sistema de archivos. Restrinja los archivos que se pueden servir para que la configuración, las credenciales y los metadatos del repositorio nunca se vuelvan descargables por el simple hecho de estar cerca de la aplicación. Establezca límites adecuados para los cuerpos de las solicitudes, los tiempos de espera y las conexiones según la aplicación. Trate las cachés como una decisión sobre datos: el contenido vinculado a un usuario o permiso no puede heredar de forma segura una regla de caché compartida sin revisión. Pruebe juntos la autenticación y el comportamiento de la caché. Mantenga una configuración reproducible y valide los cambios antes de recargar el servicio, con una ruta conocida de vuelta a la versión de trabajo anterior. Capa Responsabilidad útil Comprobar antes del lanzamiento Borde web público TLS, enrutamiento por nombre de host y límites de HTTP Certificados, raíces y nombres de host previstos Proceso de aplicación Lógica de negocio y autorización Autenticación, comprobaciones de entrada y fallo de dependencias Servicio de datos interno Estado persistente de la aplicación Acceso restringido y restauración probada Red del proveedor upstream El servicio de red contratado Alcance de la protección y ruta de escalado 03 Un proxy inverso no elimina la exposición del origen Si el origen sigue siendo accesible públicamente, un cliente puede alcanzarlo sin usar la ruta de proxy prevista. Restrinja el acceso al origen mediante el diseño de red y la configuración de la aplicación cuando el despliegue requiera ese límite. En una sola máquina, un backend a menudo puede escuchar en loopback o en un socket local. Entre máquinas, utilice rutas restringidas explícitas y una protección adecuada para la conexión upstream. Las cabeceras reenviadas también necesitan una regla de confianza. Acepte información sobre el cliente original solo de intermediarios de confianza, e impida que llamadores arbitrarios proporcionen valores que la aplicación trate como autoritativos. Decida qué aparece en los registros de acceso y en los informes de errores. Un proxy puede cambiar la información disponible en cada capa; no borra los identificadores de cuenta ni hace que la aplicación sea anónima para su propio operador. 04 Aplique las decisiones de acceso dentro de la aplicación La arquitectura Zero Trust de NIST se centra en las decisiones de acceso a los recursos en lugar de la confianza implícita basada únicamente en la ubicación de red. Aplique ese principio de forma concreta: autentique al llamador, autorice la operación solicitada y otorgue a las cuentas de servicio solo el alcance que necesitan. Una solicitud que llega desde una subred interna no debería convertirse automáticamente en una solicitud de administrador. Separe las funciones públicas y administrativas cuando sea práctico. Vuelva a comprobar el permiso cuando un usuario acceda a un registro en lugar de confiar solo en el inicio de sesión inicial. Mantenga distintas las credenciales del proxy, la aplicación y la base de datos. Introduzca los cambios por etapas que se puedan probar, comenzando por una ruta sensible estrecha. Llamar Zero Trust a un despliegue es menos útil que demostrar que una acción prohibida realmente se deniega en el componente responsable de ella. 05 Planifique la denegación de servicio en más de una capa Un enlace de red saturado y una solicitud de aplicación costosa fallan en lugares diferentes. La limitación de velocidad en el borde web puede ayudar a restringir los patrones de solicitudes, mientras que los límites de la aplicación pueden acotar el trabajo, como búsquedas, cargas o exportaciones. El módulo de límite de solicitudes de NGINX proporciona un mecanismo; la clave y los umbrales deben ajustarse a los usuarios reales y probarse para evitar rechazar tráfico legítimo. La guía de prevención de denegación de servicio de OWASP también aborda el agotamiento de recursos en el comportamiento de la aplicación. Ponga límites de tiempo y tamaño al trabajo costoso, utilice colas acotadas y supervise las señales de fallo. Los controles locales no pueden crear capacidad en un enlace upstream que ya está saturado. Confirme la protección de red específica incluida en la oferta elegida y prepare una ruta de escalado. Nunca asuma que la protección de capa 3–4 de un catálogo también demuestra protección para cada carga de trabajo HTTP. 06 Haga que la recuperación forme parte de la publicación Compruebe el sitio desde un cliente externo utilizando su nombre de host previsto. Verifique HTTPS, las redirecciones, los recursos estáticos, los inicios de sesión y una transacción representativa de la aplicación. Confirme que los listeners administrativos y los archivos privados siguen siendo inaccesibles. Simule un upstream detenido y compruebe que el borde devuelve un fallo controlado en lugar de exponer detalles internos o esperar sin límite. Para Canvas, lea los controles disponibles dentro de la cuenta de alojamiento. Para un VPS, mantenga el borde web y la aplicación como parte de su propio plan operativo. Un puerto de red grande es una especificación de capacidad, no una prueba de que la aplicación pueda sostener ese rendimiento. Mantenga la supervisión, la restauración y los contactos del proveedor en el runbook. Publique solo después de haber verificado la ruta de solicitud real y una ruta de recuperación práctica. CONVIÉRTALO EN ACCIÓN Su lista de verificación práctica. ✓ Rastree una solicitud pública y una administrativa. ✓ Defina las raíces servidas y los listeners upstream. ✓ Confíe en las cabeceras reenviadas solo de intermediarios aprobados. ✓ Pruebe la autorización y los límites de la caché. ✓ Prepare límites y escalado para fallos de red y de aplicación. Descargar lista de verificación PREGUNTAS FRECUENTES Los detalles que importan. ¿Puede un servidor web actuar también como proxy inverso? + Sí. NGINX es un ejemplo documentado. Sus funciones dependen de la configuración, y la aplicación sigue necesitando su propia autorización y mantenimiento. ¿Un proxy inverso oculta automáticamente el origen? + No. El origen puede seguir siendo accesible a menos que el enrutamiento, el firewall y la configuración de los listeners impongan el límite previsto. ¿La limitación de solicitudes detendrá todos los ataques DDoS? + No. Aborda patrones de solicitudes HTTP seleccionados. La saturación de red y otros fallos de recursos requieren controles adecuados en el upstream y en la aplicación. REFERENCIAS PRINCIPALES Vaya a la fuente. Estas referencias respaldan los conceptos técnicos de esta guía. Consulte la documentación actual antes de cambiar un sistema de producción. NGINX: Guía para principiantes nginx.org NGINX: Limitación de solicitudes HTTP nginx.org NIST SP 800-207: Arquitectura Zero Trust nvlpubs.nist.gov OWASP: Prevención de denegación de servicio cheatsheetseries.owasp.org Orientación editorial de SwissOctet. Los ejemplos son ilustrativos. Las especificaciones del servicio, las opciones disponibles y las condiciones contractuales deben verificarse por separado. CONECTE EL CONOCIMIENTO Infraestructura relacionada. Canvas Web Suiza Vector VPS Suiza Pulse NVMe Suiza Transit 40 Suiza MANTENGA EL HILO Sus próximas notas de campo. Explore todas las guías NOTA DE CAMPO / 01 + Operaciones del día dos Aplicado Una base de endurecimiento de Linux VPS que pueda mantener Administre de forma segura, exponga solo los servicios necesarios y establezca actualizaciones y recuperación sin quedarse fuera. 6 min de lectura Lea la guía NOTA DE CAMPO / 02 + Web y onion Fundamentos Alojamiento web o una VPS: elija el trabajo que quiere asumir Compare los requisitos de la aplicación, el control y las responsabilidades de mantenimiento en lugar de tratar una VPS como el siguiente paso automático para cualquier sitio web. 6 min de lectura Lea la guía NOTA DE CAMPO / 03 + Web y onion Aplicado Un runbook de cambio de dominio, DNS y TLS para un nuevo servidor Prepare el enrutamiento de nombres de host, los certificados y la reversión en conjunto para que una migración cambie el servidor sin romper la identidad del sitio ni las conexiones seguras. 4 min de lectura Lea la guía