Infraestructura híbrida: cómo conectar la oficina con la nube

Llevar servicios a la nube no elimina la infraestructura: la extiende. Una parte de las aplicaciones y los datos pasa a ejecutarse en Azure, AWS o Google Cloud, otra permanece en la oficina, y ambas deben funcionar como una única red, con la misma seguridad, la misma identidad y una estrategia de copias común. Cuando esto no se diseña, la nube hereda los problemas de la red local y añade los suyos: servicios expuestos a internet, conectividad improvisada, costes sin control y copias de seguridad en el mismo lugar que los datos.

Esta guía recoge los criterios técnicos que aplicamos al diseñar infraestructuras híbridas para empresas: qué llevar a la nube, cómo conectarla con la oficina, cómo diseñar las redes virtuales, la resolución DNS, la identidad, el backup y el control de costes.

1. Qué llevar a la nube y qué mantener en local

No todas las cargas de trabajo se benefician igual de la nube. La decisión debe tomarse aplicación por aplicación, considerando la latencia que tolera, el volumen de datos que mueve con los usuarios, su licenciamiento, sus dependencias con otros sistemas y el coste de operarla en cada entorno.

• Buenos candidatos para la nube: aplicaciones con usuarios distribuidos o en movilidad, servicios con demanda variable, entornos de desarrollo y pruebas, y copias de seguridad fuera de la oficina.
• Candidatos a permanecer en local: sistemas que intercambian grandes volúmenes de datos con los puestos de la oficina, equipamiento con dependencia física (control industrial, CCTV, sistemas de producción) y aplicaciones heredadas cuyo coste de adaptación no compensa.

Criterio: antes de migrar, inventariar las aplicaciones y sus flujos de datos. Un servidor que se mueve a la nube pero que sigue intercambiando ficheros pesados con la oficina a diario traslada el problema al enlace de internet y genera costes de transferencia de salida que no se habían previsto.

2. Conectividad entre la oficina y la nube

El acceso a los recursos privados de la nube debe realizarse por un canal cifrado entre la red de la oficina y la red virtual, no exponiendo servicios a internet. Hay dos aproximaciones principales:

• VPN IPsec site-to-cloud: entre el firewall de la oficina y la pasarela VPN del proveedor (Azure VPN Gateway, AWS Site-to-Site VPN, Google Cloud HA VPN). Es la opción habitual para la mayoría de empresas. Los proveedores ofrecen túneles redundantes y conviene configurarlos todos, idealmente con enrutamiento dinámico BGP.
• Interconexión dedicada: un circuito privado hasta el proveedor (Azure ExpressRoute, AWS Direct Connect, Google Cloud Interconnect), indicada cuando se necesitan anchos de banda elevados, latencia predecible o requisitos de cumplimiento que excluyen el tránsito por internet.

Criterio: en una arquitectura híbrida, la conexión a internet de la oficina pasa a ser un componente crítico: si cae, los usuarios pierden el acceso a las aplicaciones que se ejecutan en la nube. Por eso la redundancia WAN, con dos operadores o respaldo 5G y conmutación automática, forma parte del diseño, no es un añadido. Lo explicamos en la guía sobre cortes de conectividad.

3. Plan de direccionamiento

Uno de los errores más costosos de corregir es el solapamiento de rangos IP. Si la red virtual en la nube utiliza el mismo rango que la oficina, una sede remota o la red doméstica habitual de los usuarios en teletrabajo, el enrutamiento entre ellas no es posible sin recurrir a NAT, con la complejidad que conlleva. Rehacer el direccionamiento de una red virtual en producción implica volver a desplegar recursos.

Criterio: definir un plan de direccionamiento global antes de crear la primera red virtual, asignando bloques no solapados a la oficina, a cada sede, a cada red virtual y a cada entorno (producción, pruebas), y evitando los rangos más comunes en redes domésticas. Documentarlo y reservar espacio para crecer.

4. Diseño de las redes virtuales

Una VPC o VNet es una red, y se diseña con los mismos principios que la de la oficina. Es frecuente encontrar máquinas virtuales con dirección pública y acceso remoto expuesto a internet, todas en una única subred y con reglas de entrada permisivas creadas durante la puesta en marcha y nunca revisadas.

• Subredes por función: separar frontales públicos, aplicaciones, bases de datos y gestión, con la mayoría de recursos en subredes privadas sin dirección pública.
• Filtrado: Security Groups o Network Security Groups con mínimo privilegio, denegando por defecto y referenciando grupos en lugar de rangos amplios.
• Salida a internet controlada: mediante NAT gateway o firewall en la nube, para que los recursos privados puedan actualizarse sin ser accesibles desde fuera.
• Acceso de administración: RDP y SSH nunca abiertos a internet; acceso a través de la VPN o de un servicio bastión gestionado.
• Servicios gestionados por red privada: bases de datos y almacenamiento accesibles mediante endpoints privados en lugar de sus direcciones públicas.

Los principios son los mismos que en la red local, y los tratamos en la guía de segmentación de red.

5. DNS híbrido

La resolución de nombres es el punto que más incidencias genera en entornos híbridos, y uno de los menos planificados. Los equipos de la oficina necesitan resolver los nombres privados de los recursos en la nube, incluidos los endpoints privados de los servicios gestionados, y los recursos en la nube necesitan resolver los nombres del dominio interno de la oficina. Si no se configura, los clientes resuelven la dirección pública del servicio en lugar de la privada y el tráfico sale por internet o falla.

Criterio: reenvío condicional en ambos sentidos. En la nube, mediante el servicio de resolución híbrida del proveedor (Azure DNS Private Resolver, Amazon Route 53 Resolver con endpoints de entrada y salida, zonas de reenvío de Google Cloud DNS); en la oficina, reenviadores condicionales en los servidores DNS internos hacia esos endpoints. Verificar la resolución desde ambos lados antes de migrar cada servicio.

6. Identidad y permisos

En la nube, la identidad es el perímetro: quien obtiene credenciales con permisos suficientes puede crear, modificar o borrar infraestructura completa desde cualquier lugar. Los hallazgos habituales son cuentas raíz o de propietario usadas en el día a día, credenciales compartidas entre varias personas, claves de acceso de larga duración en scripts y permisos de administración asignados por comodidad.

• Identidad centralizada, integrada con el directorio corporativo cuando existe, y MFA obligatorio para todos los accesos administrativos.
• Cuenta raíz o de propietario protegida y reservada para emergencias.
• Permisos por rol con mínimo privilegio y revisión periódica.
• Identidades de servicio o roles para las aplicaciones, en lugar de claves estáticas.
• Separación de entornos en cuentas, suscripciones o proyectos distintos.

7. Backup y continuidad

Que un servicio se ejecute en la nube no significa que sus datos estén protegidos. La alta disponibilidad del proveedor protege frente a fallos de su infraestructura, no frente a un borrado accidental, un error de configuración o un ataque de ransomware que cifre o elimine los datos con credenciales legítimas. Una copia almacenada en la misma cuenta y con los mismos permisos que los datos originales puede perderse en el mismo incidente.

Criterio: definir RPO y RTO por servicio y diseñar las copias en consecuencia: al menos una copia separada de la infraestructura principal, en otra cuenta, región o proveedor, con inmutabilidad o retención bloqueada para que no pueda borrarse desde el entorno de producción. Lo mismo aplica en sentido inverso: los servidores locales deben tener una copia fuera de la oficina. Y, sobre todo, probar la restauración periódicamente: una copia que nunca se ha restaurado no es una garantía.

8. Costes, gobierno y monitorización

En la nube, cada recurso olvidado sigue facturando. Las desviaciones de coste habituales proceden de máquinas sobredimensionadas, recursos de pruebas que nadie elimina, discos y direcciones IP sin asociar, instantáneas acumuladas y transferencia de datos de salida no prevista.

• Etiquetado obligatorio por proyecto, entorno y responsable, para saber qué es cada recurso y a quién pertenece.
• Presupuestos y alertas de coste configurados desde el primer día.
• Revisión periódica del dimensionado según el uso real y eliminación de recursos huérfanos.
• Infraestructura como código para que cada entorno sea reproducible y los cambios queden registrados.
• Monitorización unificada: estado de los túneles VPN, latencia entre oficina y nube, disponibilidad de los servicios y registros de flujo de red, integrados con la monitorización de la red local.

Cuándo es necesaria una intervención especializada

En nuestros proyectos de cloud e infraestructura híbrida diseñamos la arquitectura completa: análisis de las aplicaciones, plan de direccionamiento, conectividad con la oficina, redes virtuales seguras, identidad, backup con RPO y RTO definidos y migración por fases sin detener la actividad, en Azure, AWS o Google Cloud.

Como la nube depende de cómo llega la oficina hasta ella, lo abordamos junto con la arquitectura de red y la seguridad perimetral, y lo integramos en la monitorización. Para una valoración general de su infraestructura, puede utilizar nuestro autodiagnóstico de red.