9 min de lectura

Objetivos de aprendizaje

Al final de este módulo, podrás:

  • Desplegar la forma empresarial probada en IONOS CLOUD: un balanceador público de capa 7 delante de una capa de cómputo sin estado, y un balanceador privado de capa 4 delante de una capa de datos exclusiva para uso privado.
  • Explicar por qué la segmentación y una postura de privacidad por defecto determinan dicho diseño, en lugar de la conveniencia.
  • Colocar contenedores, VMware dedicado, servicios de IA y conectividad híbrida sobre la misma forma.

Unidad 1.2: La arquitectura por capas canónica

Introducción

Existe una forma de arquitectura que se repite en casi todo despliegue empresarial regulado en IONOS CLOUD, y vale la pena aprenderla como predeterminada antes de estudiar cualquier producto individual. La decisión que codifica es dónde se permite que entre el tráfico, hasta dónde se permite que viaje y qué permanece completamente inaccesible desde internet. Definir correctamente ese límite a nivel de topología es mucho más económico que adaptarlo posteriormente, porque en IONOS CLOUD la capa de red en la que se encuentra un recurso es el factor principal que determina si está expuesto. Esta unidad presenta la forma canónica y explica el razonamiento, de modo que los productos por capa de los Módulos 3 a 6 tengan cada uno un lugar evidente.

1. La forma canónica: L7 público, computación sin estado, L4 privado, datos privados

La forma se lee de arriba hacia abajo como una secuencia de confianza decreciente.

En el borde se encuentra un equilibrador de carga de capa 7 público. El Managed Application Load Balancer (ALB) distribuye el tráfico entrante de la capa de aplicación hacia los destinos basándose en políticas definidas por el usuario, y realiza el enrutado según el contenido, como el host y la ruta. Es el único componente diseñado para estar expuesto a internet, y es el punto donde se termina la sesión TLS. Dado que realiza el enrutado según el contenido de la aplicación, también es el lugar donde se expresan las preocupaciones a nivel de solicitud (enrutado basado en ruta, enrutado basado en host).

Detrás de este se encuentra la capa de computación sin estado: los servidores de aplicación. Estos no conservan ningún estado duradero propio. Esta es una propiedad deliberada, no un accidente, ya que permite escalar, reemplazar o realizar la conmutación por error de la capa libremente. Todo lo que debe persistir se desplaza hacia abajo.

Entre la capa de aplicación y los datos de los que depende se encuentra un equilibrador de carga de capa 4 privado. El Managed Network Load Balancer (NLB) opera en la capa 4 de TCP/IP; distribuye cualquier tráfico basado en TCP, y sus reglas y comprobaciones de estado son estrictamente de capa 4. Al estar colocado de forma privada, distribuye las conexiones entre los nodos de la capa de datos sin ser accesible desde internet, y no termina la sesión TLS, por lo que el cifrado de extremo a extremo puede ejecutarse directamente hasta el backend.

En la parte inferior se encuentra la capa de datos solo privada: bases de datos administradas, la caché y el almacenamiento compartido. Estas se alcanzan solo a través de LANs privadas mediante el equilibrador interno. No tienen ninguna interfaz pública.

La composición, de L7 público a computación sin estado, a L4 privado y a datos privados, es la expresión idiomática de la plataforma de la defensa en profundidad. Cada paso hacia abajo elimina la accesibilidad: internet puede comunicarse con el ALB, el ALB puede comunicarse con la capa de aplicación, la capa de aplicación puede comunicarse con la capa de datos a través del NLB, y la capa de datos no puede comunicarse con nadie no invitado.

Para FinCorp, esta es la estructura en la que se integra su carga de trabajo regulada. El ALB público transporta el HTTPS orientado al cliente y termina la sesión TLS en el borde de la UE; los servidores de aplicación sin estado ejecutan la lógica de negocio y externalizan su estado; el NLB privado da servicio al clúster relacional y a la caché; y la base de datos en sí nunca se expone. La historia de cumplimiento, que la Unidad 1.4 desarrolla, es sustancialmente más fácil de lograr cuando la capa de datos es arquitectónicamente incapaz de aceptar una conexión entrante desde fuera del VDC.

2. Por qué es privado por defecto, y dónde se conecta todo lo demás

La disposición no se elige por elegancia; surge de cómo funciona realmente la red de IONOS CLOUD y de cómo se vinculan sus protecciones.

Una LAN dentro de un VDC es privada hasta que se conecta explícitamente a internet; la exposición es algo que se añade, no algo que se elimina. Esa única propiedad es lo que hace que la privacidad por defecto sea el camino de menor resistencia: deje una capa en una LAN privada y ya es inalcanzable. El razonamiento se refuerza con el lugar donde se aplican los controles de seguridad de IONOS CLOUD. Los firewalls a nivel de NIC y los Network Security Groups se vinculan a las NIC de los servidores únicamente a nivel de VDC; no se aplican al Managed ALB ni al NLB, ni a la abstracción del clúster de Managed Kubernetes. Dado que no puede envolver los equilibradores administrados en un grupo de seguridad, no puede depender de un firewall para compensar el hecho de colocar una base de datos en una ruta pública. La propia topología, es decir, lo que se encuentra en una LAN privada, debe realizar el aislamiento. Por lo tanto, la segmentación es el control estructural fundamental, y la división en tres capas (borde público, aplicación privada, datos privados) es el mínimo que lo expresa de manera clara.

La misma forma absorbe el resto de la plataforma sin cambios:

  • Contenedores. Un grupo de nodos de Managed Kubernetes se conecta a las LANs como cualquier otro recurso de cómputo y asume el rol de la capa de aplicación sin estado. Un manifiesto no aprovisiona automáticamente un equilibrador de IONOS CLOUD; el ALB público y cualquier NLB privado se aprovisionan por separado y se dirigen al clúster, de modo que el clúster se integra en la forma existente en lugar de reemplazarla.
  • VMware dedicado (Private Cloud). Una carga de trabajo de VMware sujeta a regulaciones se ejecuta en el SDDC dedicado y se conecta de vuelta al entorno de cómputo estándar a través de conectividad híbrida, ocupando la capa de cómputo para cargas de trabajo que requieren aislamiento de inquilino único, mientras que el borde elástico permanece en el cómputo estándar.
  • Servicios de IA. El AI Model Hub administrado es una API de inferencia completamente administrada y accesible públicamente (sus puntos de acceso compatibles con OpenAI y nativos están orientados a internet, no solo a LAN privadas); la capa de aplicación lo invoca a través de una ruta saliente de la misma manera en que invoca cualquier API SaaS externa, mientras que los conjuntos de datos en los que se basa pueden seguir ubicados en Object Storage y en una base de datos administrada en la capa de datos privados, por debajo de la capa de aplicación.
  • Conectividad híbrida. Las VPN, las pasarelas NAT y las interconexiones privadas se conectan en el borde y en la ruta de salida, extendiendo la misma trama privada a sitios en las instalaciones, en lugar de abrir nuevos huecos a través de las capas.

Cada módulo posterior completa una banda de este diagrama: la red construye el borde y los dos equilibradores, el cómputo construye la capa de aplicación, los datos construyen la capa inferior, y los contenedores y la IA se conectan por encima y al lado de ella. La forma no cambia; el contenido sí.

Resumen de decisiones

Nivel Constructo de IONOS CLOUD Exposición Regla aplicable
Borde público ALB administrado (capa 7) Orientado a Internet Único punto de entrada público previsto; termina TLS; enruta según el contenido.
Aplicación Cómputo sin estado o grupo de nodos de Kubernetes LAN privada, accesible a través del ALB No mantiene estado persistente, por lo que puede escalar o cambiar a un nodo de respaldo libremente.
Equilibrado interno NLB administrado (capa 4) Solo privado Paso directo de TCP, sin terminación de TLS; nunca orientado a Internet.
Datos Bases de datos administradas, caché, almacenamiento compartido Solo privado, sin interfaz pública Se accede únicamente a través del equilibrador interno mediante LANs privadas.

Adopte esta estructura por defecto y justifique cualquier desviación. La segmentación, y no un conjunto de reglas, es lo que mantiene seguro el nivel de datos, por lo que coloque un nivel en una LAN pública solo cuando esté destinado a estar expuesto a Internet.

Resumen

La arquitectura empresarial canónica de IONOS CLOUD reduce la confianza en cuatro pasos: un ALB de capa 7 público en el borde, un nivel de cálculo sin estado detrás de este, un NLB de capa 4 privado delante de los datos y un nivel de datos solo privado en la base. Es privado por defecto porque las LAN son privadas hasta que se conectan y porque los equilibradores administrados no pueden envolver en un grupo de seguridad, lo que convierte a la topología en el control real de aislamiento. Los contenedores, VMware dedicado, la IA y los enlaces híbridos se conectan a esta estructura sin modificarla, por lo que cada módulo posterior simplemente completa una banda del mismo diagrama.

Puntos clave:

  • La forma por defecto es ALB de capa 7 público a cálculo sin estado a NLB de capa 4 privado a datos solo privados, con cada paso descendente eliminando la accesibilidad.
  • El privado por defecto se mantiene porque una LAN es privada hasta que se conecta explícitamente a internet, por lo que la exposición es algo que usted añade deliberadamente.
  • Los firewalls de NIC y los NSG se vinculan solo a las NIC de los servidores, no al ALB/NLB administrado ni a la abstracción del clúster de Kubernetes, por lo que la segmentación por topología es el control fundamental.
  • Los contenedores, VMware dedicado, los servicios de IA y la conectividad híbrida se conectan a la misma forma en lugar de modificarla; los módulos posteriores completan un nivel cada uno.