No tiene que reconstruir la capa de seguridad en la migración a la nube
En la mayoría de las organizaciones, la migración a la nube se atasca en la misma pregunta: "¿Vamos a reconstruir en Azure la capa de seguridad y entrega que llevamos años madurando en el centro de datos?" Con los servicios nativos de la nube, la respuesta suele ser "sí": los conjuntos de reglas se reescriben, los equipos aprenden una herramienta nueva, las listas de excepciones se crean desde cero y la deriva de políticas entre los dos entornos comienza desde el primer día.
La llegada de TR7 a Azure Marketplace cambia esa ecuación. El mismo software que funciona en los dispositivos TR7 de hardware o virtuales de su centro de datos ahora se levanta en minutos en su suscripción de Azure: el mismo motor WAF, el mismo lenguaje de políticas, la misma interfaz de gestión. Sus algoritmos de balanceo de carga, perfiles SSL/TLS, reglas WAF personalizadas y políticas de acceso se trasladan a Azure sin traducción de reglas.
Este artículo cubre tres cosas: qué aporta en la práctica el despliegue desde el Marketplace, dónde encaja TR7 en su arquitectura de Azure y qué modelo de licencia se ajusta a cada escenario.
¿Por qué su propio ADC y WAF en Azure?
Azure ofrece servicios nativos para el balanceo de carga básico y la protección web basada en firmas. Entonces, ¿por qué las organizaciones llevan a la nube sus propias plataformas de entrega de aplicaciones? Destacan cuatro razones:
Consistencia de políticas
Las reglas WAF probadas y maduradas en el centro de datos funcionan en Azure línea por línea de forma idéntica. Sin traducción de reglas, sin diferencias de comportamiento, sin dos listas de excepciones separadas. En la auditoría presenta un único conjunto de evidencias.
Profundidad más allá de los servicios nativos
Capacidades como la gestión avanzada de bots, el aprendizaje conductual de DDoS, el enmascaramiento de datos sensibles, el parcheo virtual y el registro forense requieren una plataforma de clase empresarial. El hueco que dejan los servicios básicos es exactamente el terreno en el que operan los atacantes.
Portabilidad
Las licencias de TR7 están vinculadas a la organización, no a la plataforma. Se trasladan con su carga de trabajo entre Azure, GCP, VMware o cualquier hipervisor soportado; no se genera bloqueo de nube.
Un único plano de gestión
Todas las instancias TR7 on-prem y en Azure se administran desde un único panel; los logs, las métricas y los registros de eventos se concentran en un solo lugar. No monta un esquema de monitoreo e informes separado para el lado de la nube.
Modelos de despliegue y licencia
La imagen de TR7 en Azure Marketplace puede utilizarse con dos modelos de licencia; para los clientes de hardware existentes hay además una tercera vía híbrida:
| Modelo | Escenario más adecuado | Pago |
|---|---|---|
| PAYG (a través de la factura de Azure) | Arranque rápido, cargas variables, PoC y proyectos de corta duración | Por horas, sin compromiso previo |
| Fixed-Term BYOL | Cargas de producción planificadas, capacidad predecible | Licencia por período; portable a Azure y a otras plataformas |
| Híbrido (hardware + Azure) | Expansión gradual a la nube, recuperación ante desastres, capacidad de desbordamiento | Licencia de hardware existente + instancia en la nube |
¿Dónde encaja TR7 en su arquitectura de Azure?
La ubicación más común es el borde de la VNet hub en una topología hub-spoke. TR7 se posiciona como punto de entrada único de todo el tráfico entrante: la terminación SSL/TLS, la inspección WAF, la gestión de bots y el balanceo de carga se aplican en una sola pasada; el tráfico limpio se distribuye a las cargas de trabajo de las VNets spoke. Los clústeres de AKS, las aplicaciones de App Service y los conjuntos de escalado de VMs se definen como pools de backend — las capacidades de enrutamiento de capa 7, afinidad de sesión y monitoreo de salud de TR7 funcionan exactamente igual delante de estos servicios.
Para la alta disponibilidad, las instancias TR7 se agrupan en clúster activo-activo entre zonas de disponibilidad (availability zones). Ante la pérdida de una zona, el tráfico se transfiere sin interrupción a la instancia de la zona sana; la configuración y el estado de sesión se sincronizan dentro del clúster.
En el escenario híbrido entra en juego TR7 GTM sobre la conexión ExpressRoute o VPN entre el centro de datos y Azure: el tráfico de usuarios se enruta entre las patas on-prem y Azure según la ubicación geográfica, la latencia o la salud del centro de datos. Esta es también la columna vertebral de la migración gradual — primero Azure como pata pasiva/DR, después el despliegue activo-activo y, al final, si lo desea, la nube completa.
Puesta en producción en cinco pasos
Seleccione el plan en el Marketplace
Busque TR7 en Azure Marketplace; elija el plan PAYG o BYOL y despliéguelo en su suscripción.
Defina la red y el tamaño
Seleccione la configuración de VNet, subnet e IP pública; determine el tamaño de instancia adecuado para el perfil de tráfico esperado.
Active la licencia
En el asistente de arranque inicial, la activación es automática en PAYG y con su clave de licencia en BYOL.
Importe las políticas
Importe su configuración TR7 existente, sus reglas WAF y sus certificados; defina los pools de backend.
Dirija el tráfico de forma gradual
Con DNS o GTM, envíe una parte del tráfico a la pata de Azure; tras la validación, aumente la proporción.
Las licencias existentes de la plataforma virtual TR7 pueden trasladarse a Azure sin coste adicional. Es posible empezar con PAYG y pasar a BYOL tras la validación; la licencia sigue a su carga de trabajo entre Azure y las demás plataformas soportadas. En la planificación de capacidad, las instancias de hardware y de nube se gestionan como un inventario único.
Pruebe TR7 en Azure
Lleve a Azure las políticas de protección y entrega de su centro de datos con el mismo motor. Explore las capacidades de la plataforma virtual TR7 o solicite a nuestro equipo una demo personalizada para su despliegue en Azure.
Explore la plataforma virtual TR7