Segmentación

Las buenas cercas hacen buenos vecinos.

Antes de que podamos empezar a construir pipelines de CI/CD o aprovisionar bases de datos, necesitamos responder a una pregunta fundamental: ¿cómo estructuramos los entornos subyacentes para que los equipos puedan trabajar de forma autónoma sin interferir entre sí?

Aquí es donde entra la segmentación.

Conceptos Fundamentales

Un segmento es una frontera física o lógica alrededor de un conjunto de cargas de trabajo, recursos y usuarios dentro de una plataforma. Nos permite separar diferentes partes de nuestra infraestructura y aplicar políticas, controles de seguridad y configuraciones distintas a cada una.

¿Por Qué Segmentar?

La segmentación resuelve varios problemas críticos en la infraestructura moderna:

1. Reducción del Radio de Impacto: El “radio de impacto” es el alcance del daño cuando algo sale mal. Si tienes una infraestructura única y monolítica, una credencial comprometida o un proceso descontrolado afecta a todo. La segmentación contiene los fallos dentro de fronteras específicas y aisladas.
2. Seguridad y Cumplimiento Normativo: Muchos marcos regulatorios, como PCI-DSS o HIPAA, exigen estrictamente que los sistemas que procesan datos sensibles estén completamente aislados de los que no lo hacen.
3. Carga Cognitiva: Al acotar el alcance de un entorno, reduces el número de recursos en los que un desarrollador tiene que pensar. Solo ven la infraestructura relevante para su contexto.
4. Reglas Diferentes para Contextos Diferentes: Las políticas que gobiernan un entorno de producción (acceso restringido, auditoría exhaustiva) son contraproducentes en un entorno de desarrollo donde los ingenieros necesitan libertad para experimentar.
5. Aislamiento por Diseño: Si compartes una infraestructura unificada para todas las cargas de trabajo, dependes de configuraciones complejas —reglas IAM anidadas, Control de Acceso Basado en Roles (RBAC) y políticas de red intrincadas— para evitar la contaminación cruzada. La segmentación física se basa en fronteras duras, como cuentas de nube separadas. No necesitas una política perfectamente diseñada para bloquear el tráfico entre dos entornos si están físicamente separados sin una ruta entre ellos. La arquitectura impone el aislamiento de forma inherente.

Sin embargo, la segmentación es un ejercicio de equilibrio. Demasiado poca, y arriesgas un fallo catastrófico. Demasiada, y introduces una complejidad operativa paralizante: de repente tu equipo está gestionando cincuenta clústeres de Kubernetes o cien cuentas de nube anidadas.

Para hacerlo bien, debemos abordar la segmentación a través de cuatro dimensiones.

Las Cuatro Dimensiones de la Segmentación

Aunque hay muchas formas de dividir una infraestructura, y puedes combinar estrategias para adaptarte a cualquier negocio, he comprobado que las plataformas efectivas generalmente segmentan a lo largo de cuatro ejes principales: Sector, Tier, Región y Tenant. Estas cuatro dimensiones forman la decisión sesgada que seguiré a lo largo del resto de este libro. Representan el mínimo que recomiendo para cualquier plataforma seria — puedes añadir más dimensiones según las necesidades de tu organización, pero rara vez necesitarás menos. No necesitas implementar las cuatro desde el primer día, pero entenderlas te ayudará a diseñar una plataforma que escale.

Sector (Dominio / Línea de Negocio)

El primer y más crítico nivel de segmentación separa el dominio de la plataforma de ingeniería del dominio de negocio.

Tus aplicaciones de negocio —el código que tu empresa escribe para generar ingresos— no deberían ejecutarse junto a las herramientas que usas para gestionarlas. Tu stack de observabilidad, los runners de CI/CD y los escáneres de seguridad deberían vivir en un sector diferente al de tu sitio web de e-commerce. Esta separación se inspira en el Diseño Guiado por el Dominio (Domain-Driven Design) [Evans, 2003], agrupando recursos que comparten un contexto de negocio o técnico común.

• Sector(es) de Ingeniería: Propiedad de los equipos internos de habilitación y plataforma. Ejemplos comunes incluyen un sector de Plataforma (CI/CD, monitorización, gestión de identidad) y un sector de Seguridad (SIEM, archivado de logs, detección de amenazas). Estos alojan las herramientas que gobiernan y dan soporte al resto del ecosistema.
• Sector(es) de Negocio: Propiedad de los equipos de producto y desarrollo. Estos alojan las cargas de trabajo del negocio real. Una empresa con múltiples líneas de negocio —Retail, Finanzas, Seguros— podría definir un sector separado para cada una.

Esta separación es vital por dos razones. Primera, cumplimiento normativo: los auditores querrán saber exactamente qué procesos tienen acceso a las bases de datos de producción. Mantener los runners de CI/CD físicamente separados de la lógica de negocio hace que esta frontera sea auditable. Segunda, resiliencia: si tu entorno de negocio sufre una caída o un pico masivo de tráfico, tus herramientas de observabilidad y despliegue deben permanecer en línea para que puedas solucionar el problema.

Tier (Nivel de Criticidad)

La segunda dimensión separa las cargas de trabajo según su criticidad y los datos que manejan. Prefiero llamarlos tiers en lugar de entornos, porque los equipos de desarrollo a menudo usan términos como dev, qa, staging y prod de forma arbitraria. En su lugar, piensa en los tiers como fronteras estrictas que gobiernan el acceso y los datos. Los nombres y el número de tiers son tuyos — podrías usar Sandbox y Live, o Sandbox, Training y Live, o cualquier otra combinación que refleje los límites de riesgo y flujo de trabajo de tu organización. Lo que importa es que cada tier tenga un modelo de acceso y una política de datos claramente definidos. A lo largo de este libro uso dos tiers: Sandbox (no producción) y Live (producción).

• Sandbox (No Producción): El reino de la innovación. Aquí, los ingenieros usan datos sintéticos o fuertemente anonimizados. Los equipos de producto tienen la libertad de probar nuevas ideas, experimentar y romper cosas sin impactar al negocio. Las políticas de seguridad son más relajadas, fomentando la autonomía y la velocidad.
• Live (Producción): El reino de los ingresos. Este tier procesa datos reales de clientes. El acceso está estrictamente controlado, fuertemente auditado y monitorizado. El acceso humano directo a los recursos aquí debería ser la excepción (por ejemplo, acceso de emergencia “break-glass”), con todos los cambios fluyendo a través de pipelines automatizados.

Al crear tiers distintos de Sandbox y Live —frecuentemente implementados como cuentas o suscripciones de nube completamente separadas— te aseguras de que un desarrollador escribiendo un script desordenado en Sandbox nunca pueda borrar accidentalmente una base de datos de Live. Conceptos de entorno como qa o dev se convierten en espacios lógicos dentro del tier Sandbox, mientras que staging y prod viven dentro del tier Live.

Región (Geografía y Disponibilidad)

La tercera dimensión organiza las cargas de trabajo por su ubicación física en el mundo.

La segmentación por región implica desplegar instancias separadas de tu plataforma en diferentes geografías. Despliegas en Estados Unidos y Europa para reducir la latencia para los usuarios locales, o porque las regulaciones de residencia de datos (como el RGPD) exigen que los datos de ciudadanos europeos nunca salgan de servidores europeos.

Incluso dentro de un mismo país, la segmentación regional a menudo implica dividir las cargas de trabajo entre diferentes Zonas de Disponibilidad o configurar clústeres especializados para Alta Disponibilidad frente a Disponibilidad Estándar.

También podrías agrupar regiones en Grupos de Región (por ejemplo, global, europe, americas). Esto te permite colocar recursos que no necesitan estar estrictamente vinculados a un solo centro de datos pero que aún operan dentro de un límite geográfico definido, o identificar recursos verdaderamente global como configuraciones de enrutamiento de tráfico a nivel mundial.

Tenant (Equipo o Cliente)

La última dimensión aísla las cargas de trabajo según el propietario.

En una organización de ingeniería grande, segmentas por equipo interno. El equipo de Payments obtiene su propio espacio aislado, separado del equipo de Recommendations. Esto limita el radio de impacto entre diferentes microservicios, refuerza la seguridad mediante acceso de mínimo privilegio y permite una atribución precisa de costes. Sabes exactamente cuánto cuesta la infraestructura del equipo de Payments.

Alternativamente, si tu empresa desarrolla software B2B, podrías segmentar por cliente, proporcionando infraestructura dedicada para clientes de alto valor que requieren aislamiento estricto de datos respecto a otros tenants.

El Sistema de Coordenadas de la Plataforma

Al combinar estas cuatro dimensiones, creamos lo que llamo el Sistema de Coordenadas de la Plataforma. Cada recurso, carga de trabajo o almacén de datos en tu plataforma se asigna a una coordenada específica (Sector, Tier, Región, Tenant) que define exactamente dónde vive y las políticas que lo gobiernan.

Pero este sistema de coordenadas es mucho más que una convención de nombres. Es la fórmula generativa que impulsa todas las decisiones de infraestructura. Diferentes tipos de recursos se instancian con diferentes granularidades de coordenadas:

Consideremos al equipo de Payments ejecutándose en Europa en el tier live de nuestro sector de e-commerce. Su coordenada de ubicación es (ecommerce, live, eu01, payments). Como la infraestructura está estandarizada, esta ubicación puede mapearse automáticamente a un esquema DNS unificado. Cualquier ingeniero que vea el endpoint interno db.payments.eu01.live.internal.mountainlab.io entiende inmediatamente el contexto exacto, la postura de seguridad y la criticidad de esa base de datos.

Notación de Coordenadas

Para expresar patrones dentro del sistema de coordenadas, usamos dos símbolos especiales:

• * (comodín) significa “todos los valores” de una dimensión. Una Azure Policy aplicada a nivel de suscripción gobierna (ecommerce, live, *, *) — todas las regiones y todos los tenants dentro de esa suscripción.
• _ (ignorar) significa que la dimensión no es relevante para el recurso descrito. Una cuenta de AWS para el tenant de payments existe independientemente de la región: (ecommerce, live, _, payments). Los recursos específicos de región como las VPCs se crean entonces dentro de esa cuenta.

Esta notación se vuelve esencial al mapear el sistema de coordenadas a las estructuras del proveedor de nube, porque las primitivas de cada proveedor expresan diferentes dimensiones de forma natural. Una Azure Subscription podría representar (Sector, Tier), mientras que una AWS Account podría representar (Sector, Tier, _, Tenant). El sistema de coordenadas permanece igual; el mapeo a la nube cambia.

Segmentación y Landing Zones

Si has leído sobre arquitectura en la nube, es casi seguro que te has encontrado con el término landing zone. AWS, Azure y GCP lo usan para describir un entorno de nube preconfigurado, seguro y escalable que sirve como base para todas las cargas de trabajo [Services, 2023] [Cloud, 2023].

Esto vale la pena decirlo con claridad: el Sistema de Coordenadas de la Plataforma y una landing zone no son lo mismo, pero están profundamente relacionados. La segmentación es el concepto — el modelo que usas para decidir cómo se divide tu plataforma. Una landing zone es la implementación — la estructura específica de cuentas de nube, políticas y guardarraíles que hacen cumplir tu modelo de segmentación usando las primitivas nativas de un proveedor de nube.

El mismo modelo de segmentación puede producir diseños de landing zone muy diferentes. Una organización podría crear una única suscripción de producción para todos los tenants en (ecommerce, live) y usar grupos de recursos para el aislamiento de tenants. Otra podría crear una suscripción por tenant, mapeando directamente a (ecommerce, live, _, payments). El sistema de coordenadas permanece igual. La implementación varía según la tolerancia al radio de impacto, los requisitos de cumplimiento y la capacidad operativa.

A lo largo de este libro, el sistema de coordenadas es nuestra landing zone agnóstica a la nube. Cuando hablemos de infraestructura, redes, CI/CD y observabilidad en capítulos posteriores, cada decisión de diseño hará referencia a coordenadas.

El Espectro de Aislamiento

No todas las fronteras son iguales. Una cuenta de nube separada proporciona un aislamiento mucho más fuerte que un namespace de Kubernetes, pero también cuesta más operar. Para tomar decisiones informadas sobre dónde colocar cada frontera, es útil pensar en el aislamiento como un espectro de más duro a más suave.

En la parte superior del espectro, un sistema air-gapped en un centro de datos desconectado ofrece aislamiento absoluto — sin red no hay contaminación cruzada. Este es el mundo de las cargas de trabajo militares y gubernamentales clasificadas. En la parte inferior, un namespace de Kubernetes con RBAC proporciona separación lógica, pero las cargas de trabajo comparten el mismo API server, scheduler y kernel del nodo. Un vecino molesto (noisy neighbor) puede agotar los recursos compartidos.

La heurística de diseño es directa: usa la frontera más dura que tu presupuesto permita para Sector y Tier, y fronteras más suaves para Región y Tenant. En la práctica, esto significa cuentas o suscripciones de nube en el Nivel 3 para tus segmentaciones más críticas, redes separadas en el Nivel 4 para el aislamiento regional, y grupos de recursos o namespaces en los Niveles 5–6 para el aislamiento de tenants dentro de esas fronteras endurecidas.

Silo, Pool y Bridge

El AWS Well-Architected SaaS Lens [Services, 2023] introduce tres modelos de aislamiento que se mapean bien al espectro:

• Silo: Cada tenant obtiene recursos dedicados. Una instancia de base de datos dedicada por tenant. Un clúster dedicado por equipo. Aislamiento fuerte, coste alto.
• Pool: Los tenants comparten recursos con separación lógica. Un clúster de Kubernetes compartido con namespaces. Una base de datos compartida con seguridad a nivel de fila. Eficiente, pero con riesgo de vecino molesto.
• Bridge: Diferentes tipos de recursos dentro de la misma coordenada usan diferentes niveles de aislamiento. Tu base de datos podría estar aislada en silo (instancia dedicada por tenant) mientras tu cómputo está aislado en pool (clúster compartido, namespace dedicado).

La mayoría de las plataformas del mundo real son modelos bridge. El sistema de coordenadas lo permite de forma natural — eliges el nivel de aislamiento por tipo de recurso, por coordenada. El equipo de Payments podría justificar una base de datos dedicada (silo) pero compartir un clúster de cómputo (pool) con otros equipos, todo dentro de la misma coordenada (ecommerce, live, eu01, payments).

Traduciendo la Segmentación a Estructura de Nube

Aunque las cuatro dimensiones son conceptos abstractos, eventualmente deben mapearse a primitivas estructurales dentro de tu proveedor de nube. El objetivo es usar las fronteras nativas que el proveedor ofrece para imponer el aislamiento, en lugar de depender puramente de reglas complejas definidas por software.

Cada proveedor de nube ofrece diferentes primitivas estructurales, y no hay un único mapeo “correcto”. Los ejemplos a continuación muestran un diseño común por nube, con alternativas discutidas. Tu organización debe elegir qué granularidad de coordenada se mapea a qué primitiva de nube según su tolerancia al radio de impacto, requisitos de cumplimiento y capacidad operativa.

Mapeo Estructural en Microsoft Azure

Azure proporciona una jerarquía bien definida de ámbitos de gestión. Un enfoque común mapea Sector a Management Groups y Tier a Subscriptions:

graph TD
    Root["Grupo Raíz del Tenant (Entra ID)"]
    Root --> PMG["Management Group: Platform\n(Sector)"]
    Root --> ECMG["Management Group: ECommerce\n(Sector)"]
    PMG --> PS["Subscription: Platform-Sandbox\n(Platform, Sandbox)"]
    PMG --> PL["Subscription: Platform-Live\n(Platform, Live)"]
    ECMG --> ECS["Subscription: ECommerce-Sandbox\n(ECommerce, Sandbox)"]
    ECMG --> ECL["Subscription: ECommerce-Live\n(ECommerce, Live)"]
    ECS --> RG1["RG: rg-payments-eu01-sandbox\n(ECommerce, Sandbox, EU01, Payments)"]
    ECL --> RG2["RG: rg-payments-eu01-live\n(ECommerce, Live, EU01, Payments)"]

Los Management Groups aplican Azure Policy y RBAC a nivel de Sector. Puedes anidar sub-management-groups para herencia de políticas más granular si es necesario. Las Subscriptions proporcionan aislamiento de facturación, identidad (service principals separados en Entra ID) y límites de API — aquí mapeadas a (Sector, Tier). Los Resource Groups proporcionan delegación de RBAC y agrupación de recursos — aquí mapeados a la coordenada completa (Sector, Tier, Región, Tenant).

Este enfoque ofrece a los clientes de Azure una jerarquía clara e integrada: Management Group → Subscription → Resource Group.

Para organizaciones que requieren un aislamiento más estricto de tenants, una alternativa es crear suscripciones por (Sector, Tier, _, Tenant) — por ejemplo, una Subscription dedicada Payments-Live. Esto intercambia simplicidad operativa por fronteras más duras entre tenants.

Mapeo Estructural en Amazon Web Services

AWS se basa principalmente en Accounts aisladas unidas por una Organization. Dado que AWS no tiene un equivalente a los Resource Groups de Azure, la frontera de la cuenta a menudo absorbe la dimensión de Tenant:

graph TD
    Root["Raíz de la Organización AWS"]
    Root --> POU["OU: Platform\n(Sector)"]
    Root --> ECOU["OU: ECommerce\n(Sector)"]
    POU --> PSA["Account: Platform-Sandbox\n(Platform, Sandbox)"]
    POU --> PLA["Account: Platform-Live\n(Platform, Live)"]
    ECOU --> SBOU["Sub-OU: Sandbox\n(Agrupación de Tier)"]
    ECOU --> LOU["Sub-OU: Live\n(Agrupación de Tier)"]
    SBOU --> PaySb["Account: Payments-Sandbox\n(ECommerce, Sandbox, _, Payments)"]
    LOU --> PayLv["Account: Payments-Live\n(ECommerce, Live, _, Payments)"]
    PayLv --> VPC["VPC: payments-live-eu01\n(ECommerce, Live, EU01, Payments)"]

Las Organizational Units (OUs) aplican Service Control Policies (SCPs) y las más recientes Resource Control Policies (RCPs) a nivel de Sector. Las Sub-OUs pueden proporcionar capas adicionales de política para la agrupación de Tier. Las Accounts proporcionan la frontera de aislamiento más dura — IAM, facturación y límites de API están todos acotados a la cuenta. Aquí se mapean a (Sector, Tier, _, Tenant), con recursos específicos de región como las VPCs creados dentro de cada cuenta.

Para organizaciones más pequeñas, una alternativa más simple es usar cuentas por (Sector, Tier) únicamente — ECommerce-Sandbox y ECommerce-Live — con el aislamiento de tenants manejado mediante fronteras de IAM dentro de la cuenta. Es más simple pero ofrece un aislamiento más débil entre tenants.

Mapeo Estructural en Google Cloud Platform

GCP usa una jerarquía de recursos de Organization, Folders y Projects. Los Projects son la primitiva principal de aislamiento, análogos a las AWS Accounts:

graph TD
    Root["Organización GCP"]
    Root --> PF["Folder: Platform\n(Sector)"]
    Root --> ECF["Folder: ECommerce\n(Sector)"]
    PF --> PP["Project: platform-sandbox\n(Platform, Sandbox)"]
    PF --> PPL["Project: platform-live\n(Platform, Live)"]
    ECF --> SBF["Folder: Sandbox\n(Agrupación de Tier)"]
    ECF --> LF["Folder: Live\n(Agrupación de Tier)"]
    SBF --> PSP["Project: payments-sandbox\n(ECommerce, Sandbox, _, Payments)"]
    LF --> PLP["Project: payments-live\n(ECommerce, Live, _, Payments)"]

Los Folders (anidables hasta 10 niveles) proporcionan herencia de Organization Policy y agrupación de IAM — usados aquí para Sector y agrupación de Tier. Los Projects son la frontera dura: facturación, IAM y cuotas están acotados al proyecto. GCP no tiene equivalente a Resource Group; los recursos pertenecen directamente a los proyectos. Los recursos específicos de región se crean dentro de los proyectos, mapeando a la coordenada completa (Sector, Tier, Región, Tenant).

GCP recomienda mantener la jerarquía de carpetas por encima de los proyectos lo más plana posible, ya que cada capa de anidamiento puede definir excepciones de política que añaden sobrecarga de gestión. También vale la pena señalar que GCP desaconseja explícitamente cargar las preocupaciones de facturación en la jerarquía de recursos [Cloud, 2023]. Usa Billing Accounts separadas vinculadas a proyectos para la atribución de costes, y confía en labels para metadatos adicionales de coste.

Microsegmentación

El modelo de segmentación que hemos construido hasta ahora — Sector, Tier, Región, Tenant — maneja las fronteras gruesas. Pero, ¿qué pasa dentro de un segmento?

Incluso dentro del namespace de un solo tenant, los servicios se comunican entre sí. La segmentación tradicional se centra en el tráfico norte-sur: el tráfico que cruza el perímetro (peticiones de usuario llegando a un balanceador de carga, llamadas API entrando desde internet). Pero en las arquitecturas modernas, la mayoría del tráfico es este-oeste: comunicación servicio a servicio dentro de un segmento. Un servicio de pagos llamando a un servicio de detección de fraude. Un receptor de webhooks consultando una base de datos.

La microsegmentación controla este tráfico este-oeste. No es una quinta dimensión del sistema de coordenadas — es un mecanismo de aplicación dentro de los segmentos, operando con la granularidad más fina. Piensa en ella como la última capa de defensa:

Frontera de Sector         → nivel de organización de nube
  └── Frontera de Tier       → nivel de cuenta / suscripción
      └── Frontera de Red      → nivel de VPC / VNet
          └── Frontera de Tenant   → nivel de namespace / grupo de recursos
              └── Microsegmentación  → políticas servicio a servicio

El rol del equipo de plataforma es proporcionar la microsegmentación como infraestructura — desplegando una interfaz de red de contenedores (CNI) que soporte políticas de red, o un service mesh que aplique autenticación mutua — y establecer una política base de denegación por defecto. Los equipos de aplicación entonces abren explícitamente las rutas de comunicación que sus servicios necesitan, definidas como código y revisadas mediante pull requests.

Esto es particularmente importante en entornos regulados. PCI-DSS v4.0 reconoce explícitamente la microsegmentación como mecanismo de acotación para el Entorno de Datos del Titular de Tarjeta (Cardholder Data Environment). Si puedes demostrar que solo servicios específicos dentro de un segmento pueden alcanzar tu procesador de pagos, el resto de tu infraestructura queda fuera del alcance del cumplimiento.

No profundizaremos en la implementación aquí — las redes, las elecciones de CNI y los patrones de service mesh pertenecen al Capítulo 4 (Infraestructura) y al Capítulo 7 (Seguridad y Cumplimiento). Pero el concepto importa para el diseño de segmentación: tus segmentos definen los muros, y la microsegmentación controla las puertas dentro de esos muros.

Patrones y Anti-Patrones

Al diseñar las fronteras de tu plataforma, ten en cuenta estas trampas comunes y buenas prácticas.

Anti-Patrón: El Mega-Clúster

Poner a todos los equipos, todos los tiers y todas las aplicaciones en una sola cuenta de nube o un único clúster masivo de Kubernetes separado solo por namespaces. Aunque ahorra dinero al principio, una sola política de IAM mal configurada o un vecino molesto tirará abajo toda la empresa. La historia inicial de Mountain Lab es un ejemplo de libro.

Anti-Patrón: Granularidad Prematura

Lo opuesto al mega-clúster. Una startup con veinte ingenieros decide dar a cada desarrollador su propia cuenta de nube y clúster de Kubernetes dedicados. La sobrecarga de infraestructura paraliza instantáneamente al equipo de ingeniería, que pasa todo su tiempo actualizando versiones de clústeres y gestionando redes entre cuentas en lugar de construir producto.

Anti-Patrón: Jerarquía Dirigida por Facturación

Estructurar tu organización de nube para que coincida con centros de coste en lugar de necesidades de seguridad y aislamiento. Esto crea fronteras débiles donde necesitas fuertes (entre entornos que manejan diferentes clasificaciones de datos) y fronteras fuertes donde no las necesitas (entre centros de coste que comparten la misma postura de seguridad). La atribución de costes debería manejarse mediante tags y labels como una capa de metadatos, no a través de la jerarquía estructural.

Patrón: Matriz Cuenta-por-(Sector, Tier)

Un enfoque probado para organizaciones de todos los tamaños es mapear Sectores y Tiers directamente a la primitiva de frontera más dura del proveedor de nube [Services, 2023]. Una configuración base estándar implica una cuenta o suscripción dedicada para cada combinación de (Sector, Tier):

• Platform-Sandbox
• Platform-Live
• ECommerce-Sandbox
• ECommerce-Live

Al adoptar esta matriz, aprovechas las fronteras de seguridad y atribución de costes más fuertes del proveedor de nube para tus segmentaciones más críticas. Luego puedes usar con seguridad fronteras más suaves — como namespaces, grupos de recursos y políticas de red — para la segmentación de Región y Tenant operando dentro de esas cuentas endurecidas.

Patrón: Red-por-(Sector, Tier, Región)

Crea redes virtuales separadas para cada combinación de (Sector, Tier, Región). Sin enrutamiento por defecto entre ellas. La conectividad entre redes es explícita y controlada mediante peering o transit gateways. Esto aplica aislamiento a nivel de red alineado con los requisitos geográficos y de residencia de datos. Cubriremos la implementación de redes en detalle en el Capítulo 4.

Patrón: Modelo de Aislamiento Bridge

Diferentes tipos de recursos dentro de la misma coordenada usan diferentes niveles de aislamiento. La base de datos del equipo de Payments está aislada en silo (instancia dedicada) mientras su cómputo está aislado en pool (clúster compartido, namespace dedicado). Así es como funcionan la mayoría de las plataformas del mundo real. El sistema de coordenadas lo permite — eliges el nivel de aislamiento por tipo de recurso, no un único nivel para todos los recursos en una coordenada dada.

Patrón: Sector de Seguridad Dedicado

Aísla las herramientas de seguridad — archivos de logs, sistemas de auditoría, SIEM — en un sector dedicado, separado tanto de las cargas de trabajo de plataforma como de negocio. Si la infraestructura de negocio se ve comprometida, tu observabilidad de seguridad debe permanecer intacta para investigar y responder. Los tres grandes proveedores de nube recomiendan esto en su guía de landing zones.

Marcos de Decisión

¿Cómo eliges tu nivel de segmentación? Considera la madurez, la industria y los recursos de tu organización.

• Startups (Pre-Product Market Fit): Mantenlo simple. Dos tiers: Sandbox y Live, cada uno en su propia cuenta o suscripción de nube. Un solo sector es suficiente. No sobreingenieres. Estás en la parte baja del espectro de aislamiento (Niveles 5–6 para la mayoría de los recursos), y eso es apropiado. Concéntrate en encontrar el product-market fit.
• Scale-ups (Fase de Crecimiento): Introduce el sector Platform para sacar las herramientas compartidas de las fronteras de producto. Añade la dimensión de Tenant de forma lógica — namespaces y grupos de recursos — para rastrear costes y gestionar el acceso a medida que crece la plantilla. Empieza a mover los recursos críticos hacia arriba en el espectro de aislamiento, a los Niveles 3–4.
• Enterprise / Altamente Reguladas: Implementa las cuatro dimensiones con fronteras físicas duras. Cuenta-por-(Sector, Tier) como mínimo, posiblemente cuenta-por-(Sector, Tier, _, Tenant) para cargas de trabajo sensibles. Microsegmentación dentro de los segmentos. Aislamiento estricto de red y aplicación de políticas para satisfacer a auditores y marcos de cumplimiento. Operas en los Niveles 2–4 en general.

Preocupaciones Transversales

Las cuatro dimensiones definen las fronteras estructurales de tu plataforma. Pero varias preocupaciones cruzan esas fronteras como superposición de políticas (policy overlays) — influyen en cómo configuras los segmentos, pero no son dimensiones que creen nueva infraestructura.

Clasificación de Datos

No todos los datos son iguales. Un modelo común clasifica los datos en cuatro niveles: Público, Interno, Confidencial y Restringido. Esto se superpone a la dimensión de Tier — tu tier Live maneja datos Confidenciales y Restringidos, pero no toda carga de trabajo en Live toca datos de titulares de tarjetas PCI o registros médicos. Solo un subconjunto de coordenadas necesita el aislamiento más estricto. La clasificación de datos te ayuda a decidir qué coordenadas justifican subir en el espectro de aislamiento.

Alineación de Identidad

Tu gestión de identidad y acceso debe alinearse con el sistema de coordenadas. Proveedores de identidad o tenants separados para los tiers Sandbox y Live. Service principals separados por Sector. Tokens de corta duración en lugar de credenciales de larga duración. A medida que la arquitectura zero trust gana tracción [nist2020sp800207?], la identidad es cada vez más la frontera principal de aplicación — no la red.

Atribución de Costes

La atribución de costes es una capa de metadatos, no una dimensión estructural. El sistema de coordenadas la habilita de forma natural: cada recurso en (ECommerce, Live, EU01, Payments) es atribuible al equipo de Payments. Usa tags y labels para enriquecer esto aún más, pero resiste la tentación de reestructurar tu jerarquía de nube alrededor de la facturación. La jerarquía debe servir a la seguridad y el aislamiento primero; el seguimiento de costes viene después a través de metadatos.

Aislamiento de Pipelines de CI/CD

Los pipelines de build y despliegue deben respetar las fronteras de segmentación. Los runners de build de Sandbox no pueden acceder a secretos de Live. Las credenciales de pipeline deben estar acotadas por (Sector, Tier) como mínimo. Cubriremos esto en profundidad en el Capítulo 5, pero el principio es simple: tu sistema de CI/CD es tan seguro como el alcance de su credencial más débil.

Resumen

• La segmentación protege al negocio: Al limitar el radio de impacto, los fallos se mantienen localizados y no se propagan en cascada por el sistema.
• Cuatro dimensiones definen el modelo: Sector separa plataforma de producto. Tier separa sandbox de live. Región separa geografías. Tenant separa equipos o clientes.
• El sistema de coordenadas es generativo: (Sector, Tier, Región, Tenant) no solo etiqueta recursos — impulsa qué infraestructura se crea, con qué granularidad y con qué políticas.
• El aislamiento es un espectro: Desde hardware air-gapped hasta namespaces compartidos, ajusta el nivel de aislamiento al riesgo real y a tu capacidad operativa.
• La mayoría de las plataformas son modelos bridge: Diferentes tipos de recursos con diferentes niveles de aislamiento dentro de la misma coordenada. Una base de datos en silo junto a un clúster de cómputo en pool.
• Empieza simple, evoluciona según necesites: Aplica dimensiones progresivamente a medida que la complejidad y las necesidades regulatorias de tu organización escalan.