Topologías de Despliegue

Despliegue Agnóstico e Infraestructura

El valor arquitectónico más crítico de esta solución es su Núcleo Aséptico. Toda la lógica de negocio del Backend For Frontend (BFF) y la SPA en React están construidas de forma que desconocen absolutamente en qué entorno de alojamiento se van a ejecutar.

Gracias a las capacidades de compilación estática (HTML/JS) y al empaquetado agnóstico de Quarkus, el mismo código fuente puede materializarse en multitud de plataformas. Pasamos de una abstracción lógica a una vista topológica y física de seguridad de red, pensada para los estrictos estándares de los equipos de Operaciones / SecOps.

Espectro de Despliegue (Topologías de Seguridad)

Los 4 diagramas topológicos siguientes acentúan los perímetros de seguridad (DMZs, VPCs, terminación TLS estricta y segregación de red).

1. PaaS (Platform as a Service) - Google Cloud

Alojamiento Serverless 100% gestionado por GCP. Delega el parcheo del SO directamente al proveedor y garantiza un perímetro férreo basado en las exigencias de operaciones y ciberseguridad interna.

Alineación con Estándares de Seguridad Cloud: Diseñado asumiendo un despliegue Zero-Trust (“Deny by Default”):

Protección Perimetral: Cloud Armor ejerce de WAF absorbiendo ataques, gestionando Rate Limiting, protegiendo de SSRF y aplicando validación estricta de input, además de tener habilitado Data Access Audit Logs.
Identidad (Least Privilege): Cloud Run se ejecuta bajo una Service Account dedicada, erradicando el uso del default compute service account. No emplea roles amplios (Editor, Owner), disponiendo de un acceso restringido y granulado (ej. acceso a secretos concretos a través de Secret Manager sin usar un secretAccessor global).
Segmentación e Interceptación (VPC SC): Ecosistema contenido dentro de un perímetro VPC Service Controls.
Tráfico de Salida (Egress): Por defecto, Cloud Run utiliza IPs efímeras. Para poder atravesar la barrera de restricción de Salesforce (IP Whitelisting), todo el tráfico saliente desde el BFF pasa obligatoriamente por un conector Serverless VPC Access y sale a internet a través de un Cloud NAT mapeado a una IP Pública Estática. Solo así Salesforce puede validar y permitir nuestra conexión de entrada.

2. CaaS / IaaS (Containers en Cloud + Hybrid DB) - Google Cloud

Aloja la capa de cómputo en contenedores orquestados por Google Kubernetes Engine (GKE) (modelo CaaS) y delega la persistencia a servicios gestionados, evitando el mantenimiento pesado de bases de datos granulares.

Alineación con Estándares de Seguridad (GKE):

Protección Perimetral: El External Load Balancer intercepta el tráfico conectando directamente con un bloque Cloud Armor (absorción de DDoS, Rate Limiting y escudos SSRF) antes de tocar el clúster.
Identidad (Least Privilege): Extiende el concepto a K8s usando Workload Identity. El Pod del BFF asume una Service Account de GKE estrechamente vinculada a una Service Account IAM de Google dedicada. Por lo tanto, el Node Pool jamás usa la cuenta default de computación y los secretos se consumen por contexto del Pod.
Segmentación e Interceptación (Network Policies): El namespace del clúster opera bajo la premisa “Deny by Default” configurada a través de NetworkPolicies puras de K8s.
Tráfico de Salida (Egress): Similar al modelo sin servidor, los nodos del clúster usan IPs dinámicas. Para garantizar que Salesforce acepte las peticiones, el tráfico de salida es enrutado a través de un Cloud NAT con IP Estática, consolidando el tráfico en un punto lógico rastreable e integrable en las whitelists externas.
Persistencia Delegada (Hybrid PaaS): Aunque el núcleo operativo es puro CaaS (K8s), la arquitectura delega el estado a Cloud SQL (Managed Postgres). Consumir la base de datos como un PaaS exime a ingeniería de montar complejos StatefulSets o réplicas manuales en GKE, integrándose transparentemente con el clúster a nivel de red mediante Private Services Access.

3. Private Cloud (Contenedores On-Premise)

Estrategia idéntica al escenario 2, pero rigurosamente restringida a centros de datos físicos propios ante extremas regulaciones de soberanía de datos. En este entorno se orquesta sobre servidores Bare Metal o máquinas virtuales controladas internamente de forma centralizada.

Bases de Datos Clásicas: A pesar de ejecutar la capa web en contenedores on-premise, la base de datos subyacente no tiene por qué estar contenida. A menudo el pod del BFF se conecta a granjas de bases de datos relacionales preexistentes ya consolidadas en el Data Center central.
Tráfico de Salida (Egress Proxy): El equivalente exacto al “Cloud NAT & Router” de Google es un Forward Proxy Interno / Firewall Perimetral NAT genérico. Para que Salesforce confíe en las peticiones del backend local, el tráfico del contenedor sale hacia este Proxy Interno, el cual actúa de pasarela y lo expulsa hacia internet portando la IP Pública Principal Autorizada de la compañía.

4. Infraestructura Heredada / Compartida (Legacy / Bare Metal)

Modelo de segregación clásica de red mediante capas de arquitectura físicas o lógicas (Tiers), adaptándose al parque de servidores inmovilizado (aprovechando los servidores de aplicaciones y bases de datos centrales ya existentes en la compañía).