Del spoofing al MitM: defensa contextual por capas OSI

RESUMEN EJECUTIVO

Global Tech Holding (GTH) inicia una transformación estructural para unificar identidades, modernizar su infraestructura global y reforzar la seguridad en sus tres sedes estratégicas: Madrid, Nueva York y Tokio. Esta primera fase establece un plano de control único basado en Zero Trust Architecture, elimina las antiguas islas de identidad, introduce escalabilidad inteligente y aplica soberanía de datos en tiempo real. El resultado es una plataforma corporativa resiliente, eficiente y preparada para resistir amenazas modernas.

Visión del Arquitecto: Construir una arquitectura coherente, gobernable y alineada con estándares internacionales.

Visión del Atacante: Cada capa añadida reduce mis rutas de ataque y elimina mis movimientos laterales.

MAPA CONCEPTUAL NARRADO

La arquitectura final se sostiene sobre cuatro pilares fundamentales:

1.     Identidad Unificada: un único directorio global con administración segmentada por región.

2.     Infraestructura Elástica: escalado automático, resiliencia zonal y optimización de costes.

3.     Seguridad Adaptativa: acceso condicional, geofencing, protección basada en riesgo y telemetría inteligente.

4.     Red Segmentada: modelo Hub-and-Spoke con microsegmentación estricta mediante NSG y enlaces privados.

Visión del Arquitecto: Identidad gobierna, red protege, infraestructura responde y seguridad evalúa.

Visión del Atacante: El entorno deja de ser un mapa abierto. Cada paso que doy observado y bloqueado.

ESTRUCTURA DE LAS FILIALES REGIONALES

Para nuestro laboratorio hemos dividido el holding en tres sedes estratégicas. Cada una opera como una unidad de negocio independiente pero bajo el paraguas de seguridad centralizado.

Madrid: GTH Iberia S.A. Foco: Operaciones logísticas y cumplimiento legal para Europa. Departamentos: Logística, Legal y Compliance, Recursos Humanos.

Volumen: 50 empleados.

Cargos clave: Operativos de almacén, abogados de cumplimiento, especialistas en nóminas.

Nueva York: GTH Americas Corp. Foco: Finanzas globales, estrategia comercial y sede central.

Departamentos: Tesorería, Ventas Internacionales, Marketing.

Volumen: 60 empleados.

Cargos clave: Analistas financieros, Key Account Managers, directores de arte.

Tokio: GTH Asia-Pacific Ltd. Foco: I+D Tecnológico y soporte técnico 24/7. Departamentos: Ingeniería de Software, Soporte Técnico Global, Seguridad de la Información (SOC).

Volumen: 40 empleados.

Cargos clave:

Desarrolladores senior, ingenieros de soporte, analistas de ciberseguridad.

Visión del Arquitecto: La estructura organizativa define el modelo de identidad y acceso.

Visión del Atacante: Tres sedes significan tres superficies de ataque… hasta que se unifican.

1. RESOLUCIÓN DE LA FRAGMENTACIÓN DE IDENTIDAD

El problema antiguo: GTH operaba con islas de identidad. Cada sede tenía un servidor Active Directory local desconectado. Un directivo de NY en Madrid era un fantasma digital. La gestión de bajas era un riesgo crítico.

La solución Azure Entra ID: Identidad única (SSO), Administrative Units, SSPR, B2B Collaboration.

Visión del Arquitecto: La identidad global elimina duplicidades y permite gobernanza real.

Visión del Atacante: Pierdo mis rutas entre sedes. Ya no puedo moverme lateralmente.

2. SUPERACIÓN DE LA ESCALABILIDAD INEFICIENTE

El problema antiguo: Tokio compraba hardware para el peor escenario. El 90% del tiempo estaba infrautilizado, pero colapsaba en compilaciones.

La solución VMSS: Elasticidad predictiva, orquestación flexible, rolling upgrades, resiliencia zonal.

Visión del Arquitecto: La infraestructura deja de ser estática y se vuelve predictiva. Visión del Atacante: Los picos de carga ya no generan caos que pueda aprovechar.

3. BLINDAJE DE SEGURIDAD GEOGRÁFICA

El problema antiguo: La seguridad dependía de la buena fe. Riesgo de fuga de datos y sanciones regulatorias.

La solución: Named Locations, Purview, Impossible Travel, MFA basado en riesgo.

Visión del Arquitecto: La ubicación se convierte en un factor de seguridad verificable. Visión del Atacante: Ya no puedo esconderme detrás de una VPN o IP anónima.

Señales de Riesgo e Identidad Adaptativa

Microsoft Entra ID Identity Protection introduce señales de riesgo basadas en comportamiento, credenciales comprometidas, ubicaciones anómalas y patrones de ataque. Estas señales alimentan políticas adaptativas que bloquean accesos sospechosos sin intervención humana.

Visión del Arquitecto: La seguridad deja de ser reactiva y se convierte en predictiva. Visión del Atacante: Cada intento de acceso anómalo activa alertas automáticas que me delatan.

 

4. AISLAMIENTO DE CARGAS DE TRABAJO

El problema antiguo: Red plana. Un virus podía viajar libremente.

La solución: VNets, NSG, Bastion, Private Links.

Visión del Arquitecto: La red deja de ser plana y se convierte en microdominios seguros. Visión del Atacante: Cada subnet es una muralla. El movimiento lateral muere.

BLOQUE DOCTRINAL CENTRAL

Este despliegue integral para Global Tech Holding (GTH) no solo se limita a la configuración de servicios, sino que incorpora los estándares más rigurosos de la arquitectura de seguridad moderna. A lo largo del proyecto se implementan los pilares de Zero Trust Architecture basados en el estándar NIST SP 800‑207, asegurando que cada acceso sea verificado explícitamente. Se adoptan niveles de seguridad de autenticación (AAL) y federación (FAL) alineados con NIST SP 800‑63, avanzando hacia métodos de autenticación moderna sin contraseñas mediante tecnologías como FIDO2, WebAuthn y Passkeys. Esta base normativa permite construir identidades resilientes capaces de resistir ataques avanzados de suplantación desde el primer día de operación de la IT corporativa.

En las fases de infraestructura, el diseño evoluciona desde la segmentación tradicional con VLANs y DMZ hacia una microsegmentación avanzada basada en identidad, controlando minuciosamente el tráfico tanto de entrada/salida (North‑South) como el movimiento lateral (East‑West). Se utiliza Microsoft Entra ID para la gobernanza mediante PIM (Privileged Identity Management) y revisiones de acceso, integrando además conceptos de orquestación de identidades y flujos adaptativos propios de Okta Identity Engine y Ping DaVinci. Finalmente, se blindan las cargas de trabajo multicloud incorporando la arquitectura de seguridad de IBM, utilizando Security Verify para el SSO, QRadar para la centralización forense de logs y Guardium para la protección y clasificación crítica de los datos financieros y operativos de las sedes en Madrid, Nueva York y Tokio.

Integración Multicloud y Coherencia Zero Trust

La arquitectura incorpora IBM Security Verify para federación avanzada, QRadar para correlación forense y Guardium para protección de datos críticos. Estos sistemas se integran con Entra ID mediante SCIM, SAML y APIs de auditoría, garantizando coherencia Zero Trust entre nubes.

Visión del Arquitecto: La seguridad no depende de un proveedor; depende del diseño. Visión del Atacante: La multicloud deja de ser una oportunidad y se convierte en un cerco.

Riesgos Mitigados

·        Eliminación del movimiento lateral entre sedes.

·        Reducción del riesgo de fuga de datos transfronteriza.

·        Desaparición de cuentas huérfanas.

·        Bloqueo automático de accesos desde países no autorizados.

·        Eliminación de exposición pública de servicios críticos.

·        Reducción del riesgo por componentes obsoletos.

·        Control total del offboarding global.

·        Prevención de ataques por Impossible Travel.

·        Eliminación de RDP/SSH públicos.

·        Reducción del riesgo de shadow IT.

Visión como Arquitecto: Ningún permiso debe ser permanente. Las revisiones periódicas garantizan que cada acceso sea necesario, vigente y justificado, alineando la gobernanza con los principios de Zero Trust y el control A.9.2.5 de ISO 27001.

Visión como Atacante: Las revisiones me exponen. Cualquier privilegio que intente mantener oculto será detectado y revocado por el director regional o por el Hub.

Implementación Técnica: Configuración de Access Reviews trimestrales para los grupos SEC‑MAD‑LOGISTICS‑MGMT, SEC‑NYC‑FINANCE‑MGMT y SEC‑TOK‑ENG‑MGMT. Cada revisión requiere aprobación explícita del propietario del grupo y genera auditoría automática en Entra ID.

Resultado: Eliminación de privilegios obsoletos, reducción del riesgo de escalación indebida y cumplimiento continuo de normativas internacionales.

Lecciones Aprendidas

1.     La identidad es el verdadero perímetro.

2.     La administración debe ser local, pero la identidad global.

3.     El autoscaling elimina el sobreaprovisionamiento.

4.     La seguridad basada en ubicación supera a la basada en contraseñas.

5.     La microsegmentación es la defensa real contra el movimiento lateral.

6.     Eliminar puertos públicos reduce el 80% de los vectores de ataque.

7.     La telemetría es tan importante como la autenticación.

8.     La gobernanza evita la deriva operativa.

9.     La resiliencia zonal es supervivencia.

10.  Zero Trust es disciplina, no producto.

La arquitectura consolida logs de Entra ID, Defender for Cloud, Azure Firewall y VNets en Microsoft Sentinel y QRadar. La correlación cruzada permite detectar patrones de ataque distribuidos entre regiones.

Métricas de Impacto

·        30% menos tickets de recuperación de contraseña.

·        60% de ahorro en costes en Tokio.

·        100% de eliminación de cuentas duplicadas.

·        0 servicios críticos expuestos públicamente.

·        3 zonas de disponibilidad activas.

·        100% de documentos financieros cifrados.

·        95% de reducción de accesos desde países no autorizados.

·        100% de administradores bajo PIM.

Visión del Arquitecto: Los números validan la estrategia.

Visión del Atacante: Mis oportunidades se reducen.

Referencias Normativas

·        NIST SP 800‑207

·        NIST SP 800‑63

·        CIS Controls v8

·        ISO/IEC 27001

·        MITRE ATT&CK

·        IBM Cloud Security Framework

·        Microsoft Zero Trust Guidance

·        ISO 27001 Controles A.9, A.12 y A.13

Visión del Arquitecto: Cumplir estándares es gobernanza real.

Visión del Atacante: Cada estándar es una barrera más.

Estado Final de la Arquitectura

GTH opera ahora con una identidad global coherente, una red segmentada, cargas de trabajo elásticas y seguridad basada en señales. La organización reduce costes, aumenta resiliencia y cumple estándares internacionales.

Visión del Arquitecto: La arquitectura está lista para escalar y evolucionar.

Visión del Atacante: El terreno ya no es favorable. Cada paso es observado y bloqueado.

Conclusión Ejecutiva

La Fase 1 consolida una arquitectura moderna, resiliente y alineada con Zero Trust. GTH pasa de islas de identidad y redes planas a un ecosistema global gobernado por identidad, segmentado por diseño y protegido por telemetría inteligente. Este proyecto habilita crecimiento, reduce costes y prepara a la organización para las siguientes fases de madurez tecnológica.

BLOQUE I: IDENTIDAD Y GOBERNANZA RAÍZ (Controles 01‑10)

1. Visión como Arquitecto (SC‑100/AZ‑305) Nuestro primer objetivo es evitar el "Directorio Plano". Estableceremos la jerarquía en Madrid como Hub Central para asegurar que la soberanía de datos (GDPR) dicte las reglas del Tenant desde el segundo uno.

2. Visión como Atacante (Red Team) Mi objetivo es el compromiso total del Tenant. Si no hay controles iniciales, buscaré crear un usuario con privilegios de "Global Admin" sin MFA para persistir en el sistema. Los controles 01 y 06 neutralizan esta posibilidad.

 

 

 

3. Ejecución Técnica: Los primeros pasos

Control	Acción en el Portal de Azure	Propósito Técnico
Control #01	Tenant Branding & Region: Configurar el nombre de la organización como Global Tech Holding y validar la región primaria en España.	Establece la jurisdicción legal de los datos.
Control #02	AU - Madrid (Hub): Crear la Administrative Unit AU‑MAD‑CENTRAL.	Crea el silo de gestión para la sede central.
Control #03	AU - New York (Spoke): Crear la Administrative Unit AU‑NYC‑AMERICAS.	Segmenta la administración de la filial de EE.UU.
Control #04	AU - Tokyo (Spoke): Crear la Administrative Unit AU‑TOK‑APAC.	Segmenta la administración de la filial de Japón.
Control #05	Custom Domain Verification (Simulado): Asociar el dominio gtholding.com.	Evita el uso de dominios .onmicrosoft.com que son más fáciles de rastrear.

TAREA 1: LA FUNDACIÓN

Arquitecto, para empezar "desde cero", necesito que realice estas acciones manuales:

1.     Entre en Microsoft Entra ID (antiguo Azure AD).

2.     Cree las 3 Unidades Administrativas (AUs):

o   AU‑MAD‑CENTRAL

o   AU‑NYC‑AMERICAS

o   AU‑TOK‑APAC

Bloque I: Arquitectura Estructural (El Esqueleto)

Este bloque resuelve el problema de la fragmentación de identidad y establece los silos de gobernanza necesarios para proteger las tres sedes estratégicas de la corporación. +1

Control #01: Creación de la Unidad Administrativa Raíz (Madrid Hub)

Visión como Arquitecto: Se establece Madrid como el Hub de identidad global para garantizar el cumplimiento normativo de GDPR en todas las operaciones europeas de GTH Iberia S.A..

Visión como Atacante: La creación de esta AU limita el radio de explosión; un compromiso en una filial no permite automáticamente la gestión de la identidad raíz en el Hub central.

Implementación Técnica: Configuración manual de la unidad administrativa con descripción detallada de responsabilidades legales y logísticas.

·        Campo Name: AU-MAD-CENTRAL

·        Campo Description: Unidad Administrativa Raíz de GTH Holding. Ejerce la gobernanza centralizada para la sede de Madrid (GTH Iberia S.A.). Punto de control primario para el cumplimiento de normativas GDPR y supervisión legal/logística de la Unión Europea. Esta unidad actúa como el Hub de identidad global para la corporación.

·        Campo Restricted management: No

·        Estado: Propiedades validadas para Review + create.

Creación AU-MAD-CENTRAL

Control #02: Segregación Administrativa para la Filial Américas

Visión como Arquitecto: Aplicación del principio de segregación de funciones (SoD) para GTH Americas Corp, restringiendo el alcance administrativo a los departamentos de Finanzas y Ventas de Nueva York.

Visión como Atacante: Se neutraliza el vector de movimiento lateral administrativo hacia el Hub central de Madrid.

Implementación Técnica: Definición de límites geográficos y funcionales en los metadatos de la unidad.

·        Campo Name: AU-NYC-AMERICAS

·        Campo Description: Silo administrativo delegado para GTH Americas Corp. Gestiona exclusivamente las identidades y recursos del departamento de Finanzas, Ventas y Marketing de la sede de Nueva York. El alcance administrativo está restringido para evitar el movimiento lateral hacia la sede central en Madrid o la rama APAC.

·        Campo Restricted management: No

·        Estado: Configuración de propiedades lista para asignación de roles.

 

Creación AU-NYC-AMERICAS

Control #03: Aislamiento de Propiedad Intelectual (Tokio APAC)

Visión como Arquitecto: Protección de los activos críticos de I+D y el SOC global en GTH Asia-Pacific Ltd mediante un silo de gestión independiente. +1

Visión como Atacante: El aislamiento administrativo protege el código fuente y las señales de seguridad del SOC frente a posibles brechas en las otras unidades de negocio.

Implementación Técnica: Creación de la unidad con foco en la autonomía operativa del soporte técnico 24/7 de Tokio.

·        Campo Name: AU-TOK-APAC

·        Campo Description: Unidad Administrativa delegada para GTH Asia-Pacific Ltd. Supervisa el ciclo de vida de identidades para los departamentos de I+D Tecnológico y el SOC Global en Tokio. Implementa el aislamiento administrativo necesario para proteger la propiedad intelectual y el desarrollo de software frente a otras regiones.

·        Campo Restricted management: No

·        Estado: Validación de términos de descripción técnica finalizada.

 

 

Creación AU-TOK-APAC

Control #04: Consolidación de la Estructura Organizativa Global

Visión como Arquitecto: Verificación de la jerarquía completa del Tenant para asegurar que no existan directorios planos que vulneren el modelo Zero Trust.

Visión como Atacante: La visibilidad de una estructura organizada dificulta el camuflaje de cuentas falsas o el aprovisionamiento no autorizado de administradores fuera de las AUs.

Implementación Técnica: Auditoría visual del panel principal de Unidades Administrativas tras el despliegue inicial.

Ubicación: Microsoft Entra ID > Roles and administrators > Administrative units.

Listado de Recursos:

·        AU-MAD-CENTRAL (Membership type: Assigned)

·        AU-NYC-AMERICAS (Membership type: Assigned)

·        AU-TOK-APAC (Membership type: Assigned)

 

Estructura de gobernanza base desplegada exitosamente.

Bloque II: Gestión de Identidad Adaptativa (Aprovisionamiento)

Procedemos con la fase de Aprovisionamiento de Identidades Críticas, aplicando el estándar de nomenclatura ENI (Esquema de Nomenclatura de Identidad) para garantizar la trazabilidad forense exigida por la tesis de GTH.

Este bloque se enfoca en la creación de los tres pilares de liderazgo regional. Cada identidad se asignará a su respectiva Unidad Administrativa (AU) creada en el paso anterior, asegurando que la gestión de Madrid como Hub central sea efectiva desde el origen.

Control #05: Definición del Estándar ENI y Atributos Forenses

Visión como Arquitecto: Se implementa un esquema de nombres basado en el estándar Nombre.Apellido.Sede@gtholding.com. Se añaden metadatos obligatorios (Puesto, Departamento, Ciudad) para que las futuras políticas de Acceso Condicional puedan filtrar accesos por atributos de usuario.

Visión como Atacante: Un esquema rígido de nombres facilita la detección de anomalías. Si aparece un usuario que no sigue el patrón ENI, el SOC en Tokio lo identificará inmediatamente como un posible vector de persistencia.

Implementación Técnica: Creación manual de usuarios con llenado exhaustivo de campos en la sección de "Properties".

Control #05: Aprovisionamiento Manual del Director de Logística y Legal (Hub Madrid)

Certificaciones Relacionadas:

·        SC-300: Implementación de una estrategia de gestión de identidades.

·        AZ-104: Administración de objetos de usuario en Microsoft Entra ID.

Propósito Técnico: Generar la identidad raíz del Hub Central (Madrid) asegurando que cada atributo laboral esté poblado manualmente para habilitar la gobernanza basada en atributos (ABAC).

Pasos de Ejecución Manual:

Inicio de Creación: Acceder a Microsoft Entra ID > Users > New user > Create new user.

Identidad (Identity):

·        Introducir manualmente el UPN: javier.garcia.mad@gtholding.com.

·        Establecer el Display Name: Javier García.

Configuración de Propiedades (Llenado Exhaustivo): Sin guardar aún, navegar a la sección de Properties para completar:

Job Information:

·        Job title: Director Logística y Legal

·        Department: Legal y Compliance

·        Company name: GTH Iberia S.A.

·        Manager: Se busca y asigna manualmente la cuenta Admin.Global.MAD.

Settings:

·        Usage location: Spain (Parámetro crítico para cumplimiento de GDPR).

Employee Information (Lifecycle):

·        Employee hire date: 2026-02-14 (Introducido manualmente para trazabilidad de antigüedad).

·        Employee type: Permanent.

Finalización: Revisar que todos los campos de identidad y trabajo coincidan con la ficha técnica y hacer clic en Create.

 

Ambas capturas documentan el panel de creación manual con los campos Job Title, Department, Manager y Hire Date poblados antes de la confirmación final del objeto.

En un próximo articulo: Identidades Completas en Azure Entra ID: Pilar de Zero Trust, ABAC y Cumplimiento Normativo Global.

Control #06: Aprovisionamiento Manual del Director de Finanzas (Spoke Nueva York)

Certificaciones Relacionadas: SC-100 (Diseño de seguridad de identidad para activos críticos).

Propósito: Creación del responsable financiero de la filial de Américas bajo normativas de cumplimiento SEC.

Pasos de Ejecución Manual:

Creación: Seleccionar Create new user en el panel de usuarios.

Identidad: Asignar UPN michael.smith.nyc@gtholding.com y Display Name Michael Smith.

Properties (Trazabilidad Forense):

·        Job title: Director de Finanzas

·        Department: Tesorería y Finanzas

·        Manager: Asignar manualmente a javier.garcia.mad@gtholding.com para establecer la línea de reporte hacia el Hub de Madrid.

·        Usage location: United States.

·        Employee hire date: 2026-02-14.

·        Account Expiration: En la sección de Settings, establecer manualmente la fecha de vencimiento de cuenta a 12 meses vista para forzar la recertificación de acceso anual. Configurar Account Expiration no es una práctica administrativa opcional: es un control de seguridad, gobernanza y cumplimiento normativo. En una arquitectura moderna basada en Zero Trust, cada identidad debe tener un ciclo de vida definido, verificable y auditable. La ausencia de una fecha de expiración convierte una cuenta en un riesgo operativo y de seguridad, profundizaremos de Account Expiration en un próximo articulo

 

 

Muestra el formulario de Michael Smith con la asignación manual del Manager y la ubicación en USA.

Control #07: Aprovisionamiento Manual de la Directora de I+D (Spoke Tokio)

Certificaciones Relacionadas: SC-300 (Configuración de unidades administrativas y usuarios).

Propósito: Registro manual de la identidad técnica responsable de la propiedad intelectual en APAC.

Pasos de Ejecución Manual (Secuencia Real):

Creación: Iniciar Create new user para Yuki Tanaka.

Identity: UPN yuki.tanaka.tok@gtholding.com.

Properties (Detalle Arquitecto):

·        Job title: Directora de Ingeniería e I+D

·        Department: Ingeniería de Software e I+D

·        Manager: Asignar a javier.garcia.mad@gtholding.com.

·        Usage location: Japan.

·        Employee hire date: 2026-02-14.

Guardado: Validar que la información de contacto y oficina esté completa antes de ejecutar la creación.

Documenta el perfil completo de Yuki Tanaka, incluyendo su departamento técnico y reporte jerárquico a Javier García.

Control #08: Consolidación de Miembros en Unidades Administrativas (AU Mapping)

Certificaciones Relacionadas:

·        SC-300: Gestión de identidades y accesos (Configuración de unidades administrativas).

·        SC-100: Arquitecto de Ciberseguridad (Diseño de gobernanza regional).

Propósito Técnico: Ejecutar el aislamiento de identidades mediante la asignación de usuarios a contenedores lógicos (AUs), permitiendo la delegación de permisos granular y evitando el compromiso global del tenant.

Pasos de Ejecución Manual y Documentación de Evidencias

Paso 1: Selección de la Unidad Administrativa Raíz

En el portal de Microsoft Entra ID, se accede a la sección de Unidades Administrativas para iniciar el mapeo del Hub Central.

Acción: Localizar y seleccionar la unidad AU-MAD-CENTRAL.

_

Navegación al recurso de gobernanza centralizado en Madrid antes de la fase de asignación de miembros.

Paso 2: Localización y Asignación de la Identidad Hub

Dentro del panel de la unidad administrativa de Madrid, se procede a vincular al Director Regional para establecer el silo de gestión.

Acción: En el panel de búsqueda de usuarios, localizar y seleccionar manualmente a Javier García.

Proceso de búsqueda manual y selección del usuario javier.garcia.mad para su confinamiento administrativo en la AU-MAD-CENTRAL.

Paso 3: Verificación de la Jerarquía Global y Estado de Membresía

Tras repetir el proceso para NYC y Tokio, se realiza la auditoría visual de la estructura completa para confirmar la integridad del despliegue.

Acción: Regresar a la vista general de Administrative units.

Puntos de control:

·        Confirmar que la columna Membership type indica Assigned.

·        Verificar que el conteo de miembros refleja las acciones realizadas.

Vista consolidada de la gobernanza de GTH; se valida que las tres sedes poseen sus directores asignados correctamente bajo un modelo de membresía estática, finalizando la estructura de aislamiento regional.

Control #08.1 — Automatización del Ciclo de Vida (Lifecycle Workflows)

Visión como Arquitecto: La gobernanza real no depende de tareas manuales. Lifecycle Workflows automatiza altas, bajas y recertificaciones, eliminando el riesgo de cuentas huérfanas y garantizando cumplimiento continuo.

Visión como Atacante: La automatización destruye mis oportunidades de persistencia. Ya no puedo aprovechar cuentas olvidadas o privilegios no revocados.

Implementación Técnica: Configuración de flujos automáticos para onboarding, offboarding y recertificación anual, vinculados a atributos como hireDate, employeeType y accountExpiration.

Resultado: Identidades con ciclo de vida gobernado, auditable y sin intervención manual.

Bloque III: Consolidación de Grupos de Seguridad y RBAC

Este bloque establece los contenedores de identidad necesarios para la segmentación regional. Implementamos grupos de seguridad estáticos para gestionar el acceso de la alta dirección en el Hub y los Spokes.

Control #09: Creación de Grupos de Seguridad Regionales (Security Groups)

Certificaciones: SC-300 (Gobernanza de identidades) y AZ-104 (Administración de Azure).

Propósito Técnico: Configurar grupos de tipo Assigned para delegar la administración regional y aplicar controles de acceso granulares.

Pasos de Ejecución Manual y Documentación de Evidencias

Paso 1: Validación de Creación del Grupo (Hub Madrid)

Acción: Tras completar el formulario de creación en Microsoft Entra ID, se verifica la ficha técnica del grupo principal.

Vista de Overview del grupo SEC-MAD-LOGISTICS-MGMT. Se confirma el Membership type: Assigned y la descripción técnica para el control de la VNet de Madrid.

Paso 2: Gestión de Jerarquía y Propietarios (Secuencia de 2 Fotos)

Se documenta el proceso de delegación administrativa para el director regional de Madrid.

Acción A (Selección): En el panel de Add owners, se busca y selecciona la identidad del director.

Interfaz de selección de propietarios; se identifica a Javier García para asignarle privilegios administrativos sobre el grupo.

Acción B (Confirmación): Verificación de la lista de propietarios tras la asignación.

Confirmación en la sección Owners; se valida que Javier García figura como el único propietario del grupo con su Object ID correspondiente.

Paso 3: Verificación de Consolidación Regional (Lista Global)

Una vez creados los grupos para las tres sedes internacionales siguiendo el estándar de nomenclatura unificado, se realiza la auditoría visual de la lista completa.

Acción: Navegar a All groups y filtrar por los grupos de seguridad regionales creados.

Puntos de Control:

·        Confirmar la existencia de SEC-MAD-LOGISTICS-MGMT.

·        Confirmar la existencia de SEC-NYC-FINANCE-MGMT.

·        Confirmar la existencia de SEC-TOK-ENG-MGM.

Auditoría de la lista de grupos; se valida que los tres grupos están presentes, con el Group type: Security y Membership type: Assigned, cumpliendo con el estándar de diseño.

Bloque IV: Implementación de RBAC y Gobernanza

Control #10: Asignación de Roles sobre Suscripciones Regionales

Certificaciones Relacionadas:

·        AZ-104: Asignación de permisos RBAC y gestión de suscripciones.

·        SC-300: Configuración de roles para la gestión de identidades y recursos.

Propósito Técnico: Aplicar el Principio de Privilegio Mínimo (PoLP). Se otorga el rol de Virtual Machine Contributor a cada grupo de seguridad sobre su suscripción correspondiente, permitiendo la gestión de recursos de cómputo sin otorgar permisos de administración de acceso o red.

Pasos de Ejecución Manual y Documentación de Evidencias

Paso 1: Navegación al Control de Acceso (IAM) del Hub

Instrucciones paso a paso:

·        En el portal de Azure, buscar y seleccionar la Suscripción de Madrid (Hub).

·        En el menú de la izquierda, seleccionar Access control (IAM).

·        Hacer clic en + Add y seleccionar Add role assignment.

·        En la pestaña Role, buscar y seleccionar Virtual Machine Contributor.

·        Hacer clic en Next.

·        En la pestaña Members, marcar User, group, or service principal.

·        Hacer clic en + Select members, buscar el grupo SEC-MAD-LOGISTICS-MGMT, seleccionarlo y hacer clic en Select.

·        Hacer clic en Review + assign.

Evidencia 1:

Selección y configuración del rol Virtual Machine Contributor para el grupo de Madrid; se establece la restricción de privilegios a nivel de cómputo para la administración de la sede.

Paso 2: Validación de la Jerarquía de Permisos (NYC y Tokio)

Instrucciones paso a paso:

·        Repetir el proceso de asignación en las suscripciones de NYC y Tokio vinculando sus respectivos grupos regionales.

·        Para verificar, situarse en la pestaña Role assignments de la suscripción.

·        Filtrar por el nombre del grupo para confirmar que la asignación es activa.

Evidencia 2:

Verificación en el panel IAM; se confirma que el grupo regional aparece correctamente con el rol asignado, validando la propagación de permisos en la suscripción regional.

Paso 3: Punto de Control de Auditoría (Identity vs. Resource)

Instrucciones paso a paso:

·        En la misma pantalla de Role assignments, localizar la columna Assignment type.

·        Comprobar que el acceso se concede a través del objeto de grupo y no de forma individual.

Evidencia 3:

Validación de la procedencia del permiso; se verifica que el tipo de asignación es Direct para el grupo, asegurando que los usuarios heredan el acceso de forma gobernada.

 

Control #10.2 — Revisiones Periódicas de Acceso (Access Reviews)

Visión como Arquitecto: Ningún permiso debe ser permanente. Las revisiones periódicas garantizan que cada acceso sea necesario, vigente y justificado, alineando la gobernanza con los principios de Zero Trust y el control A.9.2.5 de ISO 27001.

Visión como Atacante: Las revisiones me exponen. Cualquier privilegio que intente mantener oculto será detectado y revocado por el director regional o por el Hub.

Implementación Técnica: Configuración de Access Reviews trimestrales para los grupos SEC‑MAD‑LOGISTICS‑MGMT, SEC‑NYC‑FINANCE‑MGMT y SEC‑TOK‑ENG‑MGMT. Cada revisión requiere aprobación explícita del propietario del grupo y genera auditoría automática en Entra ID.

Resultado: Eliminación de privilegios obsoletos, reducción del riesgo de escalación indebida y cumplimiento continuo de normativas internacionales.

Bloque V: Arquitectura de red y segmentación

Control #10.1: Creación de Grupos de Recursos (Resource Groups)

Certificación Azure: AZ‑104 (Administración de Grupos de Recursos)

Propósito Técnico: Establecer los contenedores lógicos regionales para Global Tech Holding. Esto permite segmentar la administración, aplicar etiquetas de facturación y definir el ciclo de vida de los recursos para Madrid, NYC y Tokio de forma independiente.

Paso 1: Despliegue de Resource Groups Regionales

Acciones realizadas:

·        Acceder a Resource groups en el portal de Azure.

·        Crear RG-MAD-LOGISTICS-01 en Spain Central.

·        Crear RG-NYC-FINANCE-01 en East US.

·        Crear RG-TOK-ENG-01 en Japan East.

Evidencia 1:

Vista del panel de Resource Groups mostrando los contenedores regionales creados para Madrid, Nueva York y Tokio.

 

Microsegmentación Avanzada con ASG y UDR

ASG (Application Security Groups): Permiten segmentar cargas por función, no por IP, habilitando una microsegmentación dinámica.

UDR (User Defined Routes): Fuerzan el tráfico Este‑Oeste hacia el Hub, evitando bypass del Firewall y controlando el movimiento lateral.

Visión del Arquitecto: La red se convierte en un conjunto de dominios aislados gobernados por identidad.

Visión del Atacante: Cada salto lateral es bloqueado por diseño.

 

Control #11: Configuración de VNets Regionales y Direccionamiento IP

Certificación Azure: AZ‑104 (Redes Virtuales)

Propósito Técnico: Implementar la topología de red sobre los Grupos de Recursos validados, asegurando un espacio de direccionamiento IP único por región para permitir la futura interconexión y microsegmentación.

Paso 1: Creación de la VNet del Hub (Madrid)

Acciones realizadas:

·        Dentro de RG-MAD-LOGISTICS-01, crear la red VNET-MAD-HUB-01.

·        Definir el espacio de direcciones 10.0.0.0/16.

Evidencia:

Pantalla de creación de la VNet del Hub, validando el espacio de direcciones y la región.

Paso 2: Segmentación de Subredes (Subnets)

Acciones realizadas:

·        En VNET-MAD-HUB-01, crear:

o   snet-management → 10.0.1.0/24

o   snet-workload → 10.0.2.0/24

Evidencia 3:

Vista del panel de subredes mostrando la segmentación en snet‑management y snet‑workload.

Paso 3: Despliegue de VNets en Spokes (NYC y Tokio)

Acciones realizadas:

·        Crear VNET-NYC-SPOKE-01 en RG-NYC-FINANCE-01 con rango 10.1.0.0/16.

·        Crear VNET-TOK-SPOKE-01 en RG-TOK-ENG-01 con rango 10.2.0.0/16.

·        Verificar que no existe solapamiento entre VNets.

 

Evidencia 4:

Listado global de VNets mostrando las redes del Hub y los Spokes distribuidas en España, Estados Unidos y Japón.

Bloque VI: Conectividad Híbrida y Seguridad Perimetral

Control #12: Implementación de VNet Peering (Hub-and-Spoke)

Certificaciones Azure: AZ‑104 (Interconexión de redes virtuales)

Propósito Técnico: Establecer una topología Hub‑and‑Spoke para centralizar el flujo de identidad y gestión, asegurando el aislamiento entre Spokes según el modelo Zero Trust definido en el Bloque 2.

Paso 1: Configuración de Peering (Extremo Local y Remoto)

Acciones realizadas:

·        En VNET-MAD-HUB-01, acceder a Peerings > + Add.

·        Configurar el enlace local:

o   peering-mad-to-nyc

o   Traffic to remote: Allow

o   Forwarded traffic: Allow

o   Gateway: None

·        Configurar el enlace remoto:

o   peering-nyc-to-mad

o   Remote VNet: VNET-NYC-SPOKE-01

o   Traffic to remote: Allow

o   Forwarded traffic: Allow

Evidencia 1:

Configuración del peering MAD ↔ NYC; se habilita el reenvío de tráfico para permitir que el Hub actúe como nodo de tránsito regional.

Paso 2: Replicación de Peering hacia Tokio

Acciones realizadas:

·        Repetir el proceso desde el Hub hacia Tokio.

·        Local link: peering-mad-to-tok

·        Remote link: peering-tok-to-mad

·        Seleccionar red remota: VNET-TOK-SPOKE-01

·        Mantener Allow en Traffic y Forwarded Traffic.

Evidencia 2:

Establecimiento del peering MAD ↔ TOK; se completa la topología radial con reenvío de tráfico habilitado para sincronización y tránsito seguro.

Paso 3: Validación de estado “Connected”

Acciones realizadas:

·        Revisar la lista de Peerings en VNET-MAD-HUB-01.

·        Confirmar:

o   Peering status: Connected

o   Peering state: Fully Synchronized

o   Forwarded traffic: Enabled

Evidencia 3:

Validación final del estado operativo; ambos peerings muestran sincronización completa y aceptación de tráfico reenviado.

 

Este documento forma parte del proyecto técnico‑pedagógico de pergaminodigital.es, una iniciativa dedicada a la estandarización, documentación estructural y divulgación profesional de arquitecturas, laboratorios y marcos de ciberseguridad aplicados a entornos corporativos modernos.