Segmentación

Los buenos cercos hacen buenos vecinos.

Antes de que podamos empezar a construir pipelines de CI/CD o aprovisionar bases de datos, tenemos que responder 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 Centrales

Un segmento es un término genérico para cualquier límite físico o lógico alrededor de un conjunto de cargas de trabajo, recursos y usuarios dentro de una plataforma. Podemos crear segmentos a niveles muy amplios —como dividir las herramientas internas de toda la empresa de sus aplicaciones orientadas al cliente— o a niveles muy específicos, como un entorno de ejecución aislado para un solo equipo de producto.

Lo más importante de un segmento es que define un conjunto específico de capacidades, guardarraíles y restricciones que son relevantes para tu organización. Estas características sirven como guía: cuando necesitas desplegar un nuevo recurso de plataforma, observas sus requisitos y los comparas con las características de tus segmentos disponibles para saber exactamente dónde debe aterrizar.

Independientemente de su tamaño, un segmento es simplemente el acto de dibujar una valla para separar diferentes partes de nuestra infraestructura, lo que nos permite aplicar estas políticas y configuraciones distintas a cada área.

¿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” (blast radius) es el alcance del impacto cuando algo sale mal. Si tienes una infraestructura única y monolítica, una credencial comprometida o un proceso descontrolado afectan a todo. La segmentación contiene los fallos dentro de límites específicos y aislados.
2. Seguridad y Cumplimiento: Muchos marcos regulatorios, como PCI-DSS o HIPAA, requieren estrictamente que los sistemas que procesan datos sensibles estén completamente aislados de los que no lo hacen.
3. Carga Cognitiva: Al reducir el alcance de un entorno, reduces la cantidad de recursos en los que un desarrollador tiene que pensar. Solo ven la infraestructura relevante para su contexto.
4. Diferentes Reglas para Diferentes Contextos: Las políticas que gobiernan un entorno de producción (acceso estricto, auditoría pesada) 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, debes confiar en configuraciones complejas —reglas de IAM anidadas, Control de Acceso Basado en Roles (RBAC) y políticas de red intrincadas— para prevenir la contaminación cruzada. La segmentación física se basa en límites duros, 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 hace cumplir el aislamiento de manera inherente.

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

Para hacerlo bien, debemos abordar la segmentación en cuatro dimensiones.

Las Cuatro Dimensiones

Si bien hay muchas formas de segmentar una infraestructura, las plataformas resilientes siempre se segmentan a lo largo de cuatro ejes principales: Sector, Tier, Región y Tenant. Utilizando la Notación de Plataforma introducida en el capítulo anterior, podemos definir formalmente estas dimensiones como tipos que forman nuestro sistema de coordenadas.

Sector

La primera y más crítica dimensión separa el contexto interno de la plataforma del contexto de negocio.

• Definición de Tipo: Sector(Nombre)
• Valores Estándar: "platform", "ecommerce"

Utilizo el término Sector para definir estos límites de alto nivel. Aunque “Dominio” podría ser técnicamente más apropiado, es un término excesivamente sobrecargado en nuestra industria. Al usar Sector(Nombre), establecemos un vocabulario inequívoco: un sector es un área distinta de la infraestructura con su propia gobernanza y propósito.

• Sector Interno (Sector("platform")): Aloja las herramientas compartidas, los sistemas de habilitación y los servicios de seguridad que dan soporte a todo el ecosistema. En los estándares de la industria, a menudo se les denomina sectores Foundation o Core. Proporcionan el “plano de gestión” para el resto de la organización.
• Sector de Negocio (Sector("ecommerce")): Aloja las aplicaciones reales orientadas al cliente y las cargas de trabajo que generan ingresos. Es un error común pensar que los equipos de producto son dueños del sector de negocio. En una plataforma bien diseñada, el equipo de plataforma es el dueño y quien aprovisiona el sector, mientras que los equipos de producto lo utilizan para desplegar sus aplicaciones.

Esta separación es vital tanto para el cumplimiento como para la resiliencia. Mantener tus runners de CI/CD y herramientas de observabilidad en un sector interno, físicamente separados de la lógica de negocio, garantiza que tus “ojos y manos” permanezca operativos incluso si un pico masivo de tráfico o un incidente de agotamiento de recursos pone de rodillas al sector de negocio.

Tier

La segunda dimensión separa las cargas de trabajo en función de su criticidad y los datos que manejan.

• Definición de Tipo: Tier(Nombre)
• Valores Estándar: "sandbox", "live"

Prefiero llamarlos tiers (niveles) en lugar de entornos, porque los equipos de desarrollo a menudo usan términos como dev, qa, staging y prod de manera arbitraria. En cambio, piensa en los tiers como límites estrictos que rigen el acceso y los datos. A lo largo de este libro utilizo dos tiers: Tier("sandbox") y Tier("live").

• Tier("sandbox") (No Producción): El reino de la innovación. Aquí, los ingenieros usan datos sintéticos o fuentemente anonimizados. Los equipos de producto tienen la libertad de experimentar y romper cosas sin afectar al negocio.
• Tier("live") (Producción): El reino de los ingresos. Este tier procesa datos reales de clientes. El acceso está estrictamente controlado, fuentemente auditado y monitorizado. El acceso humano directo aquí debería ser la excepción, con todos los cambios fluyendo a través de pipelines automatizados.

Al crear Tier("sandbox") y Tier("live") distintos —a menudo implementados como cuentas o suscripciones en la nube completamente separadas— te aseguras de que un error en un Sandbox nunca pueda impactar en producción.

Región

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

• Definición de Tipo: Region(Nombre)
• Valores Estándar: "eu01", "us01", "global"

La segmentación regional implica desplegar instancias separadas de tu plataforma en diferentes geografías. Despliegas en EE. UU. y Europa para reducir la latencia de los usuarios locales, o para cumplir con regulaciones de residencia de datos (como el GDPR).

Tenant

La dimensión final aísla las cargas de trabajo en función del propietario.

• Definición de Tipo: Tenant(Nombre)
• Valores Estándar: "payments", "recommendations"

En una gran organización de ingeniería, segmentas por Equipo interno. Al usar Tenant("payments") te aseguras de que el equipo obtenga su propio espacio aislado, separado de Tenant("recommendations"). Esto limita el radio de impacto, endurece la seguridad y permite una atribución de costos precisa.

El Sistema de Coordenadas

A cada recurso en nuestra plataforma se le asigna una tupla específica que llamamos su coordenada. Siguiendo la gramática de la Notación de Plataforma, siempre utilizamos un formato de cuatro dimensiones: (Sector, Tier, Region, Tenant).

Esta coordenada actúa como la “dirección” de nuestros recursos. No importa cuán simple o complejo sea un recurso, debe aterrizar en algún lugar de la plataforma, y su punto de aterrizaje está definido precisamente por su coordenada. Si una dimensión no es relevante para un recurso específico, utilizamos un guion bajo (_) para indicar que se ignora.

• (Sector, Tier, _, _): Una coordenada para recursos que abarcan todas las regiones y tenants (por ejemplo, una cuenta en la nube).
• (Sector, Tier, Region, _): Una coordenada para recursos que se aplican a todos los tenants en una región específica (por ejemplo, una VPC).
• ("ecommerce", "live", "eu01", "payments"): Una coordenada completamente resuelta para la carga de trabajo de un tenant específico.

Segmentos de Plataforma

Al aplicar uno o más de estos cuatro tipos de dimensión, creamos un segmento. En nuestro modelo estructural, cualquier combinación de dimensiones define un segmento válido. No pensamos en los segmentos como una progresión lineal de lo general a lo específico; cualquier corte a través del sistema de coordenadas de la plataforma crea un límite con sus propias características.

Aunque generalmente definimos los segmentos en el orden de (Sector, Tier, Region, Tenant), esto no es un requisito. Puedes combinar cualquier número de dimensiones en cualquier orden que se adapte a tus necesidades de infraestructura:

• Segmentos de Una Dimensión: Definen límites organizativos masivos. Por ejemplo, ("platform", _, _, _) representa todo el plano de gestión interno, mientras que ("ecommerce", _, _, _) abarca todas las cargas de trabajo relacionadas con el negocio.
• Segmentos de Dos Dimensiones: Añaden otra capa de clasificación. Por ejemplo, ("ecommerce", "live", _, _) define el entorno de producción para el negocio.
• Segmentos de Tres Dimensiones: Crean alcances organizativos o de infraestructura más enfocados. ("ecommerce", "live", "eu01", _) representa la red de producción europea, pero también podríamos tener una cuenta de AWS en ("ecommerce", "live", _, "payments") que abarque todas las regiones para un tenant específico.
• Segmentos de Cuatro Dimensiones: El límite más granular, identificando a un propietario específico en un contexto específico. ("ecommerce", "live", "eu01", "payments") define el entorno de ejecución aislado para el equipo de Pagos en el entorno de producción europeo.

Cuantas más dimensiones apliquemos, más específico se vuelve el propósito del segmento. Como veremos en la siguiente sección, los segmentos que no incluyen la dimensión Tenant definen típicamente el Core Space, mientras que el segmento tetradimensional completamente resuelto es lo que llamamos un Tenant Space.

Espacios

La verdadera potencia de la segmentación surge cuando vamos más allá de las simples etiquetas y observamos los límites arquitectónicos donde viven realmente las cargas de trabajo. Este modelo se basa en una distinción crítica, fuentemente inspirada en cómo los Sistemas Operativos separan el Espacio de Kernel del Espacio de Usuario. Dividimos nuestra infraestructura en Core Space y Tenant Space.

Una razón fundamental para esta separación es que estos espacios se gestionan de formas completamente diferentes, particularmente en lo que respecta al control de acceso. Para el Core Space, generalmente se necesita un conjunto amplio de permisos, ya que implica configurar la infraestructura central, cuentas de nube, configuraciones globales, etc. En contraste, para trabajar en el Tenant Space, solo necesitas permisos de escritura dentro del segmento del tenant específico, y nunca más allá. Eso es intencionado, y una de las principales razones para la segmentación. Profundizaremos en los permisos para ambos espacios en el Capítulo 5.

flowchart TD
    subgraph CoreSpace [Core Space]
        direction TB
        Network[Redes]
        DNS[Zonas DNS]
        Accounts[Cuentas Cloud]
        Config[Global Configuration]
        K8s[Clústeres Kubernetes]
    end

    subgraph TenantSpace [Tenant Space]
        direction TB
        subgraph PlatformTenant [Tenant de Plataforma]
            Observability[Stack de Observabilidad]
            VCS[Control de Versiones]
            CICD[CI/CD]
        end
        subgraph BusinessTenant [Product Tenant]
            App[Máquinas Virtuales]
            DB[Bases de Datos]
            Storage[Almacenamiento]
        end
    end
    
    CoreSpace -->|Gobierna| TenantSpace

Core Space

En un sistema operativo, el Kernel tiene acceso sin restricciones al hardware subyacente y gestiona los recursos compartidos (memoria, CPU, red). En nuestra plataforma, el Core Space abarca los límites de la infraestructura subyacente. Incluye todo lo que está “bajo el capó”: los recursos compartidos y los límites administrativos que no tienen un Tenant como dimensión.

El Core Space no es solo el lugar de gestión. Es cierto que aquí tenemos servicios para gestionarlo todo, pero también es donde alojamos la infraestructura central: red, DNS, cuentas, suscripciones, configuración global, etc.

Esto no significa que los tenants no utilicen estos recursos. Por ejemplo, una AzureSubscription(Sector, Tier) pertenece al Core Space y es gestionada exclusivamente por el equipo de plataforma, pero todas las cargas de trabajo de los tenants dentro de ese sector y nivel se ejecutarán dentro de ella. Cuando los tenants se sitúan dentro de estos espacios, heredan todas las características del espacio —como límites estrictos de IAM o redes relajadas— pero no los gestionan. Las vallas las construye y mantiene el equipo de plataforma.

Tenant Space

El Espacio de Usuario en un SO está estrictamente sandboxed; las aplicaciones se ejecutan allí y deben usar APIs para solicitar recursos al kernel. De manera similar, el Tenant Space representa la coordenada completamente resuelta que incluye la dimensión Tenant. Este es el entorno de ejecución aislado aprovisionado para un equipo de producto.

En la práctica, un Tenant Space se parece a una combinación de un Namespace de Kubernetes, un Grupo de Recursos de Cloud dedicado y roles de IAM limitados. Los tenants tienen una alta autonomía dentro de este límite: pueden desplegar sus aplicaciones y gestionar sus configuraciones internas. Sin embargo, su radio de impacto está estrictamente contenido. Interactúan con el Core Space a través de APIs o de un Portal Interno del Desarrollador (IDP), tal como las aplicaciones de usuario realizan llamadas al sistema a un kernel de SO.

El Tenant de Plataforma

Dado que el equipo de plataforma tiene un acceso amplio al Core Space, existe el riesgo persistente de “contaminación de sectores”: desplegar servicios compartidos como runners de CI/CD o stacks de observabilidad directamente en el plano de gestión central. Estos servicios no pertenecen al Core Space. Si se ven comprometidos, toda la infraestructura está en peligro.

En su lugar, gestionamos esos servicios dentro de un Tenant de Plataforma, operando enteramente dentro del Tenant Space (por ejemplo, Compute("platform", "live", "eu01", "platform")). Esto obliga al equipo de plataforma a jugar con las mismas reglas que cualquier otro tenant, garantizando que el Core Space permaneciera puro y validando de primera mano cuál es la experiencia de los desarrolladores.

Segmentación vs. 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 utilizan para describir un entorno de nube preconfigurado, seguro y escalable que sirve como base para todas las cargas de trabajo.

Vale la pena decirlo claramente: la estrategia de segmentación de tu plataforma es el concepto —el modelo que utilizas 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 ese modelo utilizando los primitivos nativos 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 cuenta 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 principio arquitectónico subyacente de separar los espacios se mantiene igual. La implementación varía según la tolerancia al radio de impacto, los requisitos de cumplimiento y la capacidad operativa.

Cada decisión de diseño que tomemos en capítulos posteriores con respecto a la infraestructura, las redes, el CI/CD y la observabilidad hará referencia a las coordenadas donde los recursos “aterrizan” dentro de estos espacios.

El Espectro de Aislamiento

No todos los límites son creados de la misma manera. Para diseñar una plataforma efectiva, debemos entender el Espectro de Aislamiento. Este determina qué tan “cerca” están dos cargas de trabajo entre sí y qué capas de protección existen entre ellas.

La clave es identificar qué se está compartiendo. Una cuenta de nube separada es un límite administrativo poderoso, pero es un error común asumir que garantiza el aislamiento físico. En realidad, múltiples cuentas de nube a menudo comparten el mismo servidor físico. Si tu objetivo es evitar un “vecino ruidoso” o un ataque de canal lateral en la CPU, el límite de la cuenta por sí solo no es suficiente.

Comprendiendo la Profundidad

• Nivel 1 (Físico): El “estándar de oro”. Se utiliza para sistemas air-gapped donde no existe conexión física entre segmentos.
• Nivel 2 (Hardware): Tienes un host físico dedicado (Bare Metal). Incluso si se gestiona a través de una API de nube, no compartes CPU, RAM o E/S local con ningún otro cliente o cuenta.
• Nivel 3 (Administrativo): Este es el punto de partida para la segmentación en la nube. Tu CloudAccount(Sector, Tier) suele mapearse aquí. Aísla la identidad, la facturación y las cuotas de API. Sin embargo, en este nivel, tus cargas de trabajo todavía comparten hardware físico (y el hipervisor) con otros desconocidos en la nube.
• Nivel 4 (Red): Existen múltiples redes dentro del mismo límite administrativo. Comparten el mismo plano de gestión pero no tienen una ruta directa para hablar entre sí.
• Nivel 5 (Runtime): Las cargas de trabajo comparten la misma red y el mismo plano de gestión, pero están aisladas por un hipervisor. Este es el aislamiento estándar de “VM separada”.
• Nivel 6 (Lógico): El aislamiento más ligero. Las cargas de trabajo comparten el mismo kernel del Sistema Operativo. Una brecha o una fuga de recursos aquí es lo más probable que impacte a los vecinos.

La Heurística de Diseño

La regla general es: utiliza el límite Administrativo (Nivel 3: Cuenta) como el aislamiento mínimo para Sector y Tier.

Si tienes requisitos extremos de seguridad, rendimiento o regulatorios que prohíben compartir hardware con desconocidos, debes subir al Hardware Dedicado (Nivel 2). Dentro de esos segmentos endurecidos, utiliza límites de Red y Lógicos (Niveles 4–6) para aislar Tenants y Regiones según tu tolerancia al riesgo y tu presupuesto.

Exploraremos cómo mapear este modelo arquitectónico a estructuras de nube concretas (como Cuentas de AWS, Suscripciones de Azure y Proyectos de GCP) en detalle en el Capítulo 6: Infraestructura.

Microsegmentación

El modelo de segmentación que hemos construido hasta ahora —Sector, Tier, Region, Tenant— maneja los límites gruesos. Pero, ¿qué sucede dentro de un segmento?

Incluso dentro de un único Tenant Space, los servicios se comunican entre sí. La segmentación tradicional se enfoca en el tráfico norte-sur: el tráfico que cruza el perímetro (solicitudes de usuarios que llegan a un balanceador de carga, llamadas API que entran desde internet). Pero en las arquitecturas modernas, la mayoría del tráfico es este-oeste: comunicación de 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 de nuestro modelo; es un mecanismo de cumplimiento dentro de los segmentos, que opera a la granularidad más fina. Piénsalo como la última capa de defensa.

El rol del equipo de plataforma es proporcionar la microsegmentación como infraestructura. Por ejemplo, desplegando una interfaz de red de contenedores (CNI) que soporte políticas de red o un service mesh que imponga autenticación mutua.

En muchas plataformas, el punto de partida dentro de un segmento (especialmente en un tier Sandbox) es una política de permiso predeterminado (default-allow), donde todos los servicios en ese segmento pueden comunicarse libremente. La microsegmentación se implementa entonces para añadir capas de restricciones donde más importan. Esto puede ocurrir a nivel de tenant —donde los equipos restringen explícitamente qué otros tenants pueden llegar a sus servicios— o incluso a nivel de aplicación, donde un solo tenant restringe el tráfico entre sus propios microservicios individuales para seguir un modelo de confianza cero (zero-trust).

Esto es particularmente importante en entornos regulados. PCI-DSS v4.0 reconoce explícitamente la microsegmentación como un mecanismo de alcance para el Entorno de Datos del Titular de la Tarjeta. 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 opciones de CNI y los patrones de service mesh pertenecen al Capítulo 6 (Infraestructura) y al Capítulo 9 (Seguridad y Cumplimiento). Pero el concepto importa para el diseño de la segmentación: tus segmentos definen las paredes, y la microsegmentación controla las puertas dentro de esas paredes.

Patrones y Antipatrones

Al diseñar el modelo de segmentación de tu plataforma, ten en cuenta estas trampas estratégicas y mejores prácticas.

Antipatrón: Mezcla de Tiers (Contaminación de Entornos)

El fallo de segmentación más común es ejecutar cargas de trabajo con diferente criticidad o clasificaciones de datos dentro del mismo segmento. Mezclar cargas de trabajo sandbox y live —incluso con separación lógica— es una receta para el desastre. Como vimos en la historia de apertura de Mountain Lab, una prueba de carga en un espacio de no producción puede agotar fácilmente los recursos de producción si comparten los mismos límites subyacentes.

Antipatrón: Contaminación de Sectores

Esto ocurre cuando las herramientas internas de la plataforma (runners de CI/CD, agentes de monitorización, escáneres de seguridad) se despliegan en el sector de negocio. Esto crea una dependencia circular: si el sector de negocio experimenta un fallo masivo, las herramientas que necesitas para diagnosticarlo y solucionarlo podrían estar caídas también. Mantén tus sectores Interno y de Negocio estrictamente separados.

Antipatrón: Jerarquía impulsada por la Facturación

Estructurar tu modelo de segmentación para que coincida con los centros de costes corporativos en lugar de con las necesidades de seguridad y aislamiento. Esto crea límites débiles donde necesitas límites fuertes (entre entornos que manejan diferentes clasificaciones de datos) y límites fuertes donde no (entre centros de costes que comparten la misma postura de seguridad). La atribución de costes es una capa de metadatos (etiquetas/rótulos), no una dimensión estructural.

Patrón: Modelo de Aislamiento Bridge

No todos los recursos en una coordenada específica necesitan el mismo nivel de aislamiento. Este es el patrón más común en el mundo real: eliges el nivel de aislamiento por tipo de recurso, por coordenada. El Tenant("payments") podría justificar una base de datos dedicada y aislada por cumplimiento, pero pueden compartir de forma segura un pool de cómputo con otros equipos dentro de su Tenant Space ("ecommerce", "live", "eu01", "payments").

Patrón: Sector de Seguridad Dedicado

Aísla la observabilidad de seguridad —archivos de logs, sistemas de auditoría, SIEM— en un sector interno dedicado. Al separar estos de las cargas de trabajo tanto de la plataforma como del negocio, garantizas que tu rastro de seguridad permaneciera intacto incluso si la infraestructura principal se ve comprometida.

Marcos de Decisión

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

• Startups (Antes del Product Market Fit): Mantenlo simple. Dos tiers: Tier("sandbox") and Tier("live"), cada uno en su propia cuenta de nube o suscripción. Un sector está bien. No sobre-diseñes. Estás en la parte inferior del espectro de aislamiento (Niveles 5–6 para la mayoría de los recursos), y eso es adecuado. Céntrate en encontrar el encaje en el mercado.
• Scale-ups (Fase de Crecimiento): Introduce Sector("platform") para sacar las herramientas compartidas de los límites de producto. Añade la dimensión Tenant lógicamente —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 Regulado: Implementa las cuatro dimensiones con límites físicos duros. CloudAccount(Sector, Tier) como mínimo, posiblemente CloudAccount(Sector, Tier, Tenant) para cargas de trabajo sensibles. Microsegmentation dentro de los segmentos. Aislamiento estricto de red y aplicación de políticas para satisfacer a auditores y marcos de cumplimiento. Estás operando en los Niveles 2–4 en todos los ámbitos.

Preocupaciones Transversales

Las cuatro dimensiones definen los límites estructurales de tu plataforma. Pero varias preocupaciones atraviesan esos límites como capas de políticas superpuestas: 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 Tier: tu nivel Live maneja datos Confidenciales y Restringidos, pero no todas las cargas de trabajo Live tocan 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é límites justifican subir en el espectro de aislamiento.

Alineación de Identidad

Tu gestión de identidad y acceso debe alinearse con el modelo de segmentación. Separate identity providers o tenants para Tier("sandbox") y Tier("live"). Principales de servicio separados por Sector. Tokens de corta duración en lugar de credenciales de larga duración. A medida que la arquitectura de confianza cero (zero trust) gana tracción, la identidad es cada vez más el límite de cumplimiento primario, no la red. Exploramos esto en detalle en el Capítulo 5: Gestión de Identidad y Acceso.

Atribución de Costes

La atribución de costes es una capa de metadatos, no una dimensión estructural. El modelo estructural la permite de forma natural: cada recurso dentro del Tenant Space ("ecommerce", "live", "eu01", "payments") es atribuible al equipo de Pagos. Utiliza etiquetas y rótulos para enriquecer esto aún más, pero resiste la tentación de reestructurar tu jerarquía de nube en torno a la facturación. La jerarquía debe servir primero a la seguridad y al aislamiento; el seguimiento de costes sigue a través de los metadatos.

Aislamiento del Pipeline de CI/CD

Los pipelines de construcción y despliegue deben respetar los límites de segmentación. Los runners de construcción de Tier("sandbox") no pueden acceder a los secretos de Tier("live"). Las credenciales del pipeline deben estar limitadas por (Sector, Tier, _, _) como mínimo. Cubriremos esto en profundidad en el Capítulo 7, pero el principio es simple: tu sistema de CI/CD es tan seguro como su alcance de credencial más débil.

Definiendo tu Política de Segmentación

Diseñar un modelo de segmentación es solo la mitad de la batalla. Para que las coordenadas tengan sentido, debes definir la política y los guardarraíles que se aplican a cada valor en tus dimensiones.

Asique avanzas por los próximos capítulos sobre IAM, Infraestructura y CI/CD, los matices de estas políticas determinarán cómo configuras cada primitivo de la nube. Antes de continuar, deberías ser capaz de responder estas preguntas para tu propia plataforma:

La Política de Sector

¿Qué diferencia a tu sector Interno (Sector("platform")) de tu sector de Negocio (Sector("ecommerce"))?

• Gobernanza: ¿Quién es el propietario administrativo? (Pista: En ambos, suele ser el equipo de plataforma, pero los usuarios cambian).
• Controles de Seguridad: ¿El sector Interno tiene un filtrado de salida más estricto porque maneja secretos? ¿El sector de Negocio requiere reglas de WAF más intensas para el tráfico público?
• Auditoría: ¿Se archivan los logs del sector Interno en un bucket separado e inmutable para análisis forense?

La Política de Tier

¿Cuáles son las “reglas del camino” para Tier("sandbox") frente a Tier("live")?

• Política de IAM: ¿Se requiere acceso JIT (Just-In-Time) para Tier("live") pero no para Tier("sandbox")?
• Infraestructura: ¿Estás usando instancias spot en Tier("sandbox") para ahorrar costes, mientras requieres instancias reservadas y multi-AZ en Tier("live") para mayor resiliencia?
• Política de Datos: ¿Están los datos de producción estrictamente prohibidos en Tier("sandbox")? ¿Es obligatoria la anonimización?

La Política de Región

¿Dónde “se permite” que exista tu plataforma?

• Disponibilidad: ¿Qué regiones están habilitadas para cada Tier? Podrías permitir cualquier región global para Tier("sandbox"), pero restringir Tier("live") solo a aquellas con conectividad específica de baja latencia con tu sede central.
• Cumplimiento: ¿Existen regiones específicas que no pueden compartir datos debido a leyes de soberanía (por ejemplo, UE frente a EE. UU.)?

La Política de Tenant

¿Cómo tratas a los diferentes Equipos?

• Aislamiento Predeterminado: ¿Todos los tenants comienzan con una política de red de “permiso predeterminado” dentro de su namespace, o están aislados de sus vecinos por defecto?
• Plantillas de Cuotas: ¿Cuál es la cuota de cómputo “Pequeña” frente a la “Grande” disponible para un tenant?

Combinaciones Dimensionales

El verdadero poder del modelo surge cuando defines políticas para las combinaciones:

• (Sector, Tier, _, _): ¿Cuál es el límite de IAM raíz en el Core Space? Este suele ser el nivel donde aprovisionas tu CloudAccount.
• (Sector, Tier, Region, _): ¿Cuál es la política de enrutamiento de red en el Core Space? ¿Puede ("ecommerce", "live", "us01", _) hablar con ("ecommerce", "live", "eu01", _)?
• (Sector, Tier, Region, Tenant): ¿Cuáles son los guardarraíles de despliegue específicos para el Tenant Space? ¿Puede Tenant("payments") desplegar en Tier("live") sin un escaneo de seguridad?

Definir estas características ahora simplificará cada decisión de implementación que tomes más adelante en el libro.

Resumen

• La segmentación protege el negocio: La segmentación efectiva es la defensa primaria contra los fallos en cascada. Al definir límites estrictos, garantizas que un incidente en un área —ya sea una prueba de carga descontrolada o una brecha de seguridad— permanezca aislado, protegiendo la estabilidad de toda la organización.
• El Sistema de Coordenadas de la Plataforma: La tupla de coordenadas (Sector, Tier, Region, Tenant) proporciona un lenguaje unificado para toda la organización. Aleja la gestión de la infraestructura de las etiquetas arbitrarias y la dirige hacia un modelo estructural donde cada recurso tiene una dirección precisa impulsada por políticas.
• Arquitectura Tetradimensional:
  • Sector separa el plano de gestión (Interno) del plano de ingresos (Negocio).
  • Tier separa los entornos experimentales (Sandbox) de los entornos de alta criticidad (Live).
  • Region aborda los requisitos de residencia geográfica, latencia y alta disponibilidad.
  • Tenant aísla a los equipos y clientes, permitiendo una entrega autónoma y una atribución de costes granular.
• Core Space frente a Tenant Space: Una plataforma profesional refleja la separación de preocupaciones que se encuentra en los sistemas operativos. El equipo de plataforma reconoce gestiona el Core Space (el kernel), proporcionando el hardware subyacente, las redes y la gobernanza. Los desarrolladores operan dentro del Tenant Space (espacio de usuario), disfrutando de autonomía dentro de vallas seguras y preconfiguradas.
• El Espectro de Aislamiento: No todos los límites requieren el mismo mecanismo. Adapta tu estrategia de aislamiento —desde namespaces lógicos hasta cuentas de nube administrativas y hardware físico— al riesgo real y a los requisitos regulatorios de la carga de trabajo.
• Modelos de Aislamiento Bridge: Las plataformas resilientes aprovechan los modelos “bridge”, donde diferentes recursos en la misma coordenada utilizan diferentes niveles de aislamiento. Esto te permite optimizar tanto la seguridad como el coste, proporcionando bases de datos dedicadas donde el cumplimiento lo exige mientras se comparten pools de cómputo para servicios estándar.
• Evoluciona a través de la Política: Comienza con las dimensiones mínimas necesarias para la escala de tu organización, pero define pronto las políticas y guardarraíles para cada dimensión. Esta previsión garantiza que, a medida que tu infraestructura crezca, tus segmentos sigan siendo consistentes y tu radio de impacto permanezca contenido.

Al establecer estos límites, hemos construido el “terreno” donde vivirá nuestra plataforma. Sin embargo, una valla solo es útil si sabemos quién tiene las llaves de la puerta. En el próximo capítulo, construiremos sobre este modelo estructural para definir cómo se autentican y obtienen acceso los usuarios y servicios a través de estos segmentos.

Skills para este capítulo