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) — construido sobre Quarkus, detallado en Decisiones Tecnológicas — 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 — SSO y Token Handler Pattern, Arquitectura Frontend — 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 interactuar con las APIs de Salesforce, la IP de origen debe estar en su whitelist. Por ello, todo el tráfico saliente desde el BFF pasa obligatoriamente por un conector Serverless VPC Access y sale a través de un Cloud NAT con IP estática, garantizando que Salesforce siempre recibe peticiones desde una dirección conocida y autorizada.

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 Kubernetes.
Tráfico de Salida (Egress): Similar al modelo sin servidor, los nodos del clúster usan IPs dinámicas. Para que Salesforce acepte las peticiones, la IP de origen debe estar en su whitelist. El tráfico de salida se enruta a través de un Cloud NAT con IP estática, consolidando el tráfico en una dirección fija, conocida y autorizada.
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 (PostgreSQL, MySQL) preexistentes ya consolidadas en el Data Center central. La elección del Session Store para este entorno está documentada en Decisiones Tecnológicas — Gestión de Estado.
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 (ej. Squid, HAProxy). Para que Salesforce acepte las peticiones del backend, la IP de origen debe estar en su whitelist. El tráfico del contenedor sale a través de este proxy, el cual actúa de pasarela consolidando el egress en una dirección IP estable y autorizada por Salesforce.

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

Modelo de segregación clásica de red mediante capas de arquitectura físicas o lógicas (N-Tier), adaptándose al parque de servidores inmovilizado — aprovechando los servidores de aplicaciones y bases de datos centrales ya existentes en la compañía. El BFF se distribuye como un Fat JAR de Quarkus (modo JVM clásico, sin contenedores). Véanse los patrones de implementación Java del BFF.