Todo lo que AlpinaShop ha construido en siete módulos funciona porque tres personas se acuerdan. Marta se acuerda de no crear VM con IP pública. Dani se acuerda de etiquetar los recursos. Lucía se acuerda de no exportar datos a un bucket externo. Los SLO viven en un panel que alguien mantiene, los runbooks se actualizan porque alguien los revisa, y la política de presupuesto de error se respeta porque el equipo la acordó una tarde.

Nada de eso está mal. Todo eso es frágil.

Porque hoy, técnicamente, nada impide que mañana alguien cree una máquina con IP pública en Iowa, desactive un log de auditoría, comparta un bucket con allUsers, o descargue una clave JSON de una cuenta de servicio. Las buenas prácticas del curso son acuerdos, no controles. Y un acuerdo se rompe el día que entra una persona nueva, el día que alguien tiene prisa, o el día que la empresa pasa de tres personas técnicas a ocho.

Gobierno es exactamente eso: convertir los acuerdos en controles que se aplican solos, y tener registro fiable de todo lo que ocurre. Es la diferencia entre "confiamos en que nadie lo haga" y "no se puede hacer".

Y hay un malentendido que conviene deshacer desde la primera línea: el gobierno no es algo que se implanta cuando se es grande. Se implanta antes, porque retrofitear políticas sobre una organización con cincuenta proyectos y mil recursos es una obra de meses, mientras que aplicarlas sobre cinco proyectos es una tarde. AlpinaShop llega tarde, pero no demasiado tarde. Esa es la única razón por la que esta lección todavía es factible en un día de trabajo.

Al terminar sabrás estructurar una organización y entender las consecuencias de cada criterio, aplicar políticas de organización que se heredan y bloquean de verdad, inventariar todo lo que existe y monitorizar los cambios en tiempo real, activar y leer los logs de auditoría que importan, montar retención inmutable en un proyecto al que ni los administradores puedan escribir, y desplegar todo eso de una vez como una zona de aterrizaje con Terraform.

Y cerrarás el módulo 7 y, con él, el recorrido completo de AlpinaShop.

1. Qué es el gobierno en la nube y por qué se necesita antes de lo que parece
2. La estructura de la organización: criterios y consecuencias
3. Políticas de organización: qué son y cómo se heredan
4. Las políticas que AlpinaShop aplica, una a una
5. Modo de prueba y el peligro de bloquear al equipo
6. Restricciones personalizadas y su relación con Policy Controller
7. Cuotas y límites a nivel de organización
8. Cloud Asset Inventory: saber qué existe
9. Feeds: monitorizar cambios en tiempo real
10. Cloud Audit Logs de verdad
11. Las consultas de auditoría que hay que tener preparadas
12. Retención inmutable en un proyecto separado
13. Zonas de aterrizaje y el orden que importa
14. Gestión del cambio: revisiones, ciclo de vida y excepciones
15. La madurez de AlpinaShop, y lo que le queda

Gobierno es el conjunto de estructuras, políticas y procesos que aseguran que el uso de la nube es coherente con lo que la organización quiere. Cubre cuatro preguntas:

Y la razón por la que se necesita antes de "ser grande", que es puramente aritmética:

El coste no crece con el número de recursos: crece con el número de excepciones que hay que negociar. Aplicar hoy la política "prohibido crear VM con IP pública" afecta a cero recursos existentes. Aplicarla dentro de cinco años significa encontrar las cuarenta VM que la incumplen, averiguar por qué, hablar con seis equipos y aceptar veinte excepciones permanentes que vacían la política de contenido.

La regla: las políticas se ponen cuando no molestan a nadie. Después ya no se ponen.

La jerarquía de 01-04, revisada ahora con todo el contexto:

Dos cambios respecto a 01-04: el proyecto alpinashop-red de 07-03 vive en compartido, y aparece una carpeta nueva, seguridad, con alpinashop-auditoria — el proyecto de logs inmutables del apartado 12. Está separado a propósito: es el único al que ni Marta puede escribir.

Rara vez se usa uno solo; lo habitual es combinar dos niveles.

Consecuencias de la elección, que es lo que casi nunca se piensa antes de decidir:

La elección de AlpinaShop es por entorno en el primer nivel, y es la correcta para su tamaño por un motivo concreto: la diferencia de exigencia entre producción y desarrollo es mucho mayor que la diferencia entre equipos. Nadie es owner de producción, pero en desarrollo se puede ser editor sin drama. Con una estructura por equipos, esa distinción sería imposible de expresar.

Cuando AlpinaShop tenga cuatro productos, la evolución natural es un segundo nivel: produccion/tienda, produccion/alpinapro, desarrollo/tienda… La estructura de carpetas se puede cambiar; mover proyectos entre carpetas es un comando. Lo que no se puede cambiar es el projectId.

El Organization Policy Service es lo que convierte los acuerdos en controles.

La última fila es la esencia: una política de organización no es un permiso. Aunque tengas roles/owner en el proyecto, si la política prohíbe IP públicas, no puedes crear una. Solo puede levantarla quien tenga roles/orgpolicy.policyAdmin en el nivel donde está definida.

Las políticas se heredan de organización → carpeta → proyecto, y en cada nivel se puede:

Y la regla que sorprende a todo el mundo: para las restricciones de lista, una denegación en cualquier nivel gana siempre. Un hijo no puede permitir lo que el padre deniega. Es lo que hace que el modelo sea seguro: no se puede escapar de una política hacia abajo.

Consecuencia práctica: las políticas se definen en el nivel más alto donde tengan sentido, y se relajan hacia abajo solo con allow adicionales sobre restricciones que el padre no denegó explícitamente. Si te encuentras necesitando "des-denegar" algo, la política estaba mal puesta.

Estas son las nueve, con su motivo, su nivel y su riesgo.

Con la excepción declarada, si alguna VM legítima la necesitara:

Motivo: en AlpinaShop no queda ninguna VM en la ruta de servicio (07-02), y las de desarrollo salen por Cloud NAT. Una IP pública es superficie de ataque directa desde internet. Nivel: organización. Riesgo de bloqueo: bajo.

Motivo: residencia del dato en la UE (07-01, 07-04) y control de costes de tráfico intercontinental (07-05). Nivel: organización. Riesgo: medio-alto, y es la política que más disgustos da. Muchos servicios tienen componentes globales o multirregión, y in:eu-locations es imprescindible para que BigQuery multirregión y algunos buckets sigan funcionando. Esta se prueba en dry-run sí o sí.

Motivo: es la deuda #1 de 07-04. Con federación de identidad e impersonación ya en uso, no hay ningún caso legítimo que necesite una clave descargable. Nivel: organización. Riesgo: medio. Puede romper integraciones antiguas — por eso primero el inventario del apartado 8, después la política.

Y su compañera, que impide que una clave existente valga eternamente:

Motivo: OS Login vincula el acceso SSH a la identidad de Google en lugar de a claves SSH sueltas en los metadatos. Eso significa que dar de baja a una persona en el directorio le quita el acceso a todas las máquinas, que es exactamente lo que no ocurre con las claves en metadatos. Nivel: organización. Riesgo: bajo (apenas quedan VM).

Motivo: un bucket público es la fuga de datos más común de la nube, en todos los proveedores. Nivel: organización. Riesgo: bajo… con una trampa que hay que resolver antes: el bucket alpinashop-catalogo sirve imágenes a la tienda. Si esas imágenes se sirven a través del balanceador con bb-catalogo-imagenes (03-02), el bucket no necesita ser público y la política no rompe nada. Si alguien las estuviera sirviendo por URL directa de Cloud Storage, sí. Comprobarlo es parte del trabajo previo.

Motivo: desactiva las ACL por objeto, que son un sistema de permisos paralelo a IAM, invisible en las auditorías y responsable de innumerables fugas. Con acceso uniforme, IAM es la única verdad.

Motivo: cierra el control de 03-06. La segunda política es la que casi nadie pone y evita que alguien cifre datos con una clave de un proyecto que no controlas. Nivel: carpeta produccion. Riesgo: alto. Exigir CMEK rompe la creación de recursos si la clave no tiene los permisos correctos concedidos al agente de servicio correspondiente. dry-run obligatorio.

Motivo: es la deuda #2 de 07-04. Impide que los proyectos nuevos nazcan con la cuenta por defecto de Compute con rol Editor. No arregla los proyectos existentes, que hay que corregir a mano.

Motivo: impide conceder permisos a cuentas de Google ajenas a la organización. Es la política que evita el error de dar acceso a [email protected] "temporalmente". Riesgo: alto. Rompe cualquier colaboración legítima con externos, y rompe algunos agentes de servicio de Google. Requiere excepciones cuidadosas y dry-run largo.

Las políticas de organización admiten modo de prueba (dry run), igual que Cloud Armor (03-05), Policy Controller (07-01) y VPC Service Controls (07-03). Es el mismo patrón por cuarta vez en el curso, y no es casualidad: todo control que deniega debe medirse antes de aplicarse.

Y la consulta de lo que habría bloqueado:

El paso 1 es el que se salta todo el mundo y el que evita el desastre. Aplicar dry-run sobre políticas que ya se incumplen genera cientos de violaciones que nadie va a analizar, y el resultado práctico es que se ignoran todas.

Reales, todas vistas en producción:

Y la salvaguarda que hay que preparar antes de todo esto: que al menos dos personas tengan roles/orgpolicy.policyAdmin en la organización, con acceso verificado. Si la única persona que puede levantar una política se bloquea a sí misma, la salida pasa por soporte de Google y por un mal día.

Cuando ninguna restricción predefinida sirve, se escribe una restricción personalizada con CEL (Common Expression Language):

Otro ejemplo, esta vez para las etiquetas obligatorias de 07-05:

Dos sistemas que hacen cosas parecidas en ámbitos distintos. La confusión es habitual:

No compiten: se complementan. Una política de organización no puede impedir que un pod se ejecute como root, y Policy Controller no puede impedir que se cree un bucket público. Una organización con Kubernetes necesita las dos.

Para AlpinaShop, que retiró las cargas de producción de GKE en 07-02, las políticas de organización son las que importan. Policy Controller queda como control del clúster de pruebas, que es coherente con lo decidido en DA-004.

Las cuotas se gestionan por proyecto, pero se pueden gobernar desde arriba mediante políticas y automatización.

La distinción esencial, ya vista en 07-05 y que aquí se coloca en su sitio: los presupuestos avisan, las cuotas impiden. En una organización gobernada hacen falta los dos, y las cuotas son el único mecanismo que no depende de que alguien reaccione.

No se puede gobernar lo que no se sabe que existe. Cloud Asset Inventory es el catálogo de todos los recursos, políticas IAM y configuraciones de la organización, con su historial.

Estas dos consultas, ejecutadas antes de aplicar las políticas 4.1, 4.2 y 4.9, son exactamente el paso 1 del procedimiento del apartado 5. Sin ellas, se aplica a ciegas.

Con export diario programado (Cloud Scheduler + Workflows, 04-06), se obtiene algo muy valioso: el histórico del inventario, que permite responder a "¿qué había el 3 de junio?" — una pregunta que aparece en toda investigación y en toda auditoría.

El inventario dice qué hay. Los feeds avisan cuando algo cambia, en el momento.

Y la función que decide qué merece un aviso inmediato (Cloud Functions 2ª gen, 06-03):

Con una alerta de Cloud Monitoring sobre jsonPayload.alerta_gobierno=true y gravedad CRITICAL, esos eventos llegan al canal de seguridad en segundos.

Esto cierra la deuda #4 de 07-04 —alertas de cambios de IAM y creación de claves— y es la diferencia entre enterarse de un cambio peligroso en el momento o descubrirlo en la revisión trimestral, seis semanas después.

Se han mencionado en 03-04, 06-06 y 07-04. Aquí, completos.

Los dos datos que hay que retener:

1. La actividad de administrador es gratis y no se puede desactivar. Ni siquiera un atacante con permisos de organización puede borrar la evidencia de sus cambios de configuración. Es el cimiento de toda investigación.
2. El acceso a datos está desactivado por defecto. Y sin él, como demostró el ejercicio de 07-04, no se puede saber quién leyó los datos de los clientes — lo que convierte una credencial filtrada en una brecha de alcance indeterminable.

Se hace con criterio, porque el volumen puede ser enorme:

Las tres decisiones que hacen esto asequible, y son las que convierten un coste inaceptable en unos 35 € al mes (07-05):

• Cloud Storage sin DATA_READ: el bucket del catálogo sirve millones de imágenes; registrar cada lectura costaría más que toda la plataforma. Se registran escrituras y lecturas administrativas, que es donde está el riesgo.
• Secret Manager con todo: son pocos accesos y cada uno importa.
• Solo en la carpeta produccion: en desarrollo no hay datos reales.

Y una exclusión imprescindible para que el volumen no se dispare:

Se excluyen las lecturas que hacen los propios agentes de servicio de Google, que son ruido puro y de altísimo volumen.

Los campos que hay que saber leer, en orden de importancia:

serviceAccountDelegationInfo es el campo que casi nadie mira y el que más importa en una organización que usa impersonación: sin él, un cambio hecho por Marta impersonando sa-deploy-prod aparece atribuido a la cuenta de servicio, y se pierde el rastro de la persona.

Escritas y guardadas como vistas antes de necesitarlas. Un incidente no es momento de aprender SQL.

1. ¿Quién cambió una política IAM?

2. ¿Quién accedió a datos de clientes?

3. ¿Quién apagó o modificó un log?

Esta tercera es la más importante de las tres, y la que menos gente tiene. Manipular el registro es lo primero que hace un atacante competente y lo primero que hace alguien que quiere ocultar un error. Debe tener alerta permanente.

4. Actividad fuera de horario.

El filtro que excluye cuentas de servicio es esencial: el software trabaja de noche, y sin ese filtro la consulta devuelve miles de líneas irrelevantes.

5. Denegaciones de política: lo que alguien intentó y no pudo.

Esta consulta tiene un doble uso que conviene entender: detecta intentos maliciosos, y también detecta políticas mal calibradas que están estorbando al equipo. Si Dani aparece veinte veces intentando algo legítimo, el problema es la política, no Dani.

Aquí está la pieza que hace que la auditoría sea creíble.

Un log que el administrador puede borrar no sirve como evidencia.

Si Marta tiene permisos para modificar los logs de auditoría, entonces ante cualquier investigación —interna, de un cliente o de la AEPD— la respuesta a "¿podría alguien haber alterado esto?" es "sí". Y eso vacía de valor todo el registro.

La solución es un proyecto separado con permisos que ni siquiera los administradores tienen.

Y el reparto de permisos, que es la clave de todo:

Marta, que administra toda la plataforma, solo puede leer aquí. Es la separación de funciones de 07-04 llevada a su conclusión: quien administra no custodia la evidencia de lo que administra.

--include-children es lo que lo hace agregado: recoge los logs de todos los proyectos y carpetas de la organización, incluidos los que se creen en el futuro. Sin esa bandera, cada proyecto nuevo quedaría fuera y nadie se daría cuenta.

Después hay que conceder al escritor del sumidero permiso sobre el destino:

Este paso se olvida constantemente y el síntoma es desconcertante: el sumidero existe, aparece en la consola, y no llega nada. Sin errores.

⚠️ --locked es irreversible. A partir de ese momento nadie, ni Google, ni el owner de la organización, ni el soporte, puede reducir la retención ni borrar el bucket antes de que expire. Ese es exactamente el punto: la garantía es que ni tú puedes.

Y para conservación a largo plazo, con bloqueo de retención de Cloud Storage:

Esto es lo que se conoce como almacenamiento WORM (Write Once, Read Many), y es lo que exigen muchos marcos de cumplimiento. También es, dicho sea de paso, la mejor defensa contra ransomware que existe: un atacante con permisos totales no puede cifrar ni borrar lo que está bajo bloqueo de retención.

Con una contrapartida que hay que asumir conscientemente: si se bloquean 7 años, se pagan 7 años de almacenamiento, sin excepción. Antes de bloquear, se calcula el volumen y se comprueba que el número tiene sentido.

Una zona de aterrizaje (landing zone) es la organización preparada antes de que llegue la primera carga de trabajo: jerarquía, políticas, red, identidad, auditoría y facturación, todo desplegado con código.

AlpinaShop lo ha hecho al revés, como casi todo el mundo: primero las cargas, después el gobierno. Ha funcionado porque es pequeña. La forma correcta, y la que hay que conocer para el próximo proyecto, es esta.

Las cuatro razones por las que este orden concreto y no otro:

1. La auditoría (5) va antes que la red y las cargas. Si el sumidero se crea después, los logs de todo lo que se hizo mientras tanto no están capturados. La construcción de la plataforma es precisamente el periodo con más cambios de permisos, y es el que más interesa tener registrado.
2. Las políticas en dry-run (4) van antes que los proyectos de carga (8). Así se miden sobre recursos que se van creando, y las violaciones se corrigen sobre la marcha en lugar de acumularse.
3. La red (6) antes que los proyectos de servicio (8). Un proyecto de servicio necesita que exista el host.
4. Las políticas aplicadas (9) antes que las cargas (10). Es el único momento en que aplicar una política no rompe nada, porque no hay nada que romper.

depends_on explícito en cada módulo, aunque no haya referencias entre ellos. Es el caso legítimo de depends_on que 06-07 señalaba como excepción: el orden aquí no viene de dependencias de datos, sino de una secuencia lógica que Terraform no puede inferir.

Google publica los blueprints de fundación (Cloud Foundation Fabric, Terraform Example Foundation), que implementan todo esto con criterio. Merecen una advertencia honesta: están pensados para organizaciones grandes y traen mucha más estructura de la que necesita una pyme. Úsalos como referencia y como fuente de decisiones bien pensadas, no como plantilla a copiar.

Cuatro días de trabajo repartidos en cuatro semanas. Ese es el precio de gobernar la plataforma, y explica por qué la aritmética del apartado 1 importa: dentro de dos años serían cuatro semanas de trabajo y seis meses de calendario.

Las políticas técnicas no bastan. Hacen falta procesos, y para un equipo de tres personas tienen que ser ligeros o no se harán.

La fecha de caducidad obligatoria en los proyectos de prueba es la medida que más gasto fantasma evita (07-05), porque ataca la causa en lugar del síntoma. Se implementa con una etiqueta caduca=2026-12-31 y un trabajo semanal que avisa de los vencidos.

Y los 30 días de espera antes de borrar no son burocracia: borrar un proyecto es irreversible pasado el periodo de gracia, y siempre aparece alguien que necesitaba algo de ahí.

Toda política acabará teniendo excepciones. Sin proceso, se conceden a voz y se convierten en permanentes.

La fecha de caducidad es lo que separa una excepción de una derogación. Sin ella, la política queda vacía de contenido para siempre y nadie recuerda por qué.

A corto plazo (este trimestre):

1. Terminar de aplicar las políticas de organización. Están en dry-run; hay que atravesar las 4 semanas del apartado 13.
2. Documentación de cumplimiento actualizada, con asesoría profesional. Es la casilla más atrasada y la única con consecuencias legales.
3. Probar el procedimiento de derecho de supresión de extremo a extremo, con un cliente de prueba.

A medio plazo (este año):

4. Multirregión para Cloud SQL, que es lo único que impide la alta disponibilidad regional completa (07-06).
5. Detección activa de amenazas, cuando haya alguien que pueda atenderla (07-04).
6. Elevación temporal de privilegios con PAM.
7. Revisión externa de seguridad sobre la arquitectura ya endurecida.

Lo que NO va a hacer, y está bien:

Esa última tabla es la más valiosa de la lección, porque una organización madura no es la que ha adoptado más tecnología: es la que sabe justificar lo que ha decidido no adoptar. Las seis filas tienen su decisión escrita, su motivo, y —en el caso de DA-004— sus condiciones de revisión.

Vale la pena mirar atrás una vez.

AlpinaShop empezó el módulo 1 sin cuenta de Google Cloud, con una tienda que funcionaba en algún sitio y tres personas que no sabían qué era una región. Terminó el módulo 2 con la aplicación migrada y una decisión pendiente. El módulo 3 le dio red, balanceo, identidad y secretos. El 4, una plataforma de datos. El 5, modelos que predicen. El 6, entrega continua y observabilidad. Y el 7 ha resuelto lo que quedaba: el híbrido, el cómputo definitivo, la red avanzada, la seguridad revisada, la factura entendida, la fiabilidad medida y el gobierno aplicado.

Hoy AlpinaShop tiene una plataforma que una persona puede operar, cualquiera puede entender leyendo un repositorio, y se reconstruye entera con terraform apply. No es perfecta —tiene una lista de deudas escrita y priorizada, que es exactamente lo que debe tener— pero es defendible ante un cliente, ante un auditor y ante la persona que entre a trabajar el mes que viene.

• Dejar el gobierno para "cuando seamos grandes". El coste crece con las excepciones que hay que negociar, no con el número de recursos. Se hace ahora o no se hace.
• Aplicar políticas sin inventariar antes lo que las incumple. Se generan cientos de violaciones que nadie analiza y el dry-run deja de servir.
• Olvidar in:eu-locations en resourceLocations. BigQuery multirregión y algunos buckets dejan de crearse.
• allowedPolicyMemberDomains sin excepciones para los agentes de servicio de Google. Servicios internos fallan de formas inexplicables.
• Exigir CMEK sin dar permisos al agente de servicio sobre la clave. Los recursos nuevos no se pueden crear.
• Aplicar políticas un viernes. Fin de semana sin poder desplegar.
• Que solo una persona tenga orgpolicy.policyAdmin. Si se bloquea a sí misma, la salida es soporte de Google.
• Sumidero sin --include-children. Los proyectos nuevos quedan fuera y nadie se entera.
• Olvidar dar logging.bucketWriter a la writerIdentity del sumidero. El sumidero existe y no llega nada, sin errores.
• Crear el proyecto de auditoría al final. Los logs de la fase de construcción, que es la de más cambios, se pierden.
• Que el administrador pueda escribir en los logs de auditoría. Entonces no valen como evidencia.
• Bloquear la retención sin calcular el volumen. --locked es irreversible y pagas todos los años que pusiste.
• Activar DATA_READ en un bucket que sirve imágenes. Millones de entradas y una factura absurda.
• No mirar serviceAccountDelegationInfo. En una organización con impersonación, sin ese campo se pierde el rastro de la persona.
• Excepciones sin fecha de caducidad. Dejan de ser excepciones y vacían la política.
• Copiar un blueprint de fundación tal cual. Están hechos para organizaciones grandes y traen estructura que no necesitas.
• Consejo: la consulta de "quién tocó un log" merece alerta permanente. Es lo primero que manipula quien quiere ocultar algo.
• Consejo: pon fecha de caducidad obligatoria a los proyectos de prueba. Ataca la causa del gasto fantasma, no el síntoma.
• Consejo: usa las denegaciones de política como termómetro. Si alguien del equipo aparece veinte veces, la política está mal calibrada.
• Consejo: escribe lo que decides NO adoptar. Es lo que distingue una organización madura de una que simplemente no llegó.

AlpinaTech, una consultora de 25 personas, arranca en Google Cloud desde cero. Datos:

• Tres equipos: desarrollo (12), datos (5), infraestructura (3). El resto no es técnico.
• Trabajan para clientes externos, y algunos exigen que sus datos no salgan de la UE.
• Dos consultores freelance con cuenta de Gmail colaboran en proyectos concretos.
• Un cliente exige certificación ISO 27001 en 18 meses.
• Presupuesto: 2.500 €/mes de nube.

Diseña: la jerarquía de carpetas y proyectos con su criterio justificado, el conjunto completo de políticas de organización con su nivel y su riesgo, cómo resuelves el caso de los freelance sin desactivar allowedPolicyMemberDomains, y el orden de despliegue de la zona de aterrizaje.

Un lunes por la mañana, la consulta de auditoría mensual revela esto:

Era sábado por la noche. No había ningún despliegue programado. La cuenta sa-mantenimiento no aparece en el Terraform de AlpinaShop.

Escribe la investigación completa: qué consultas ejecutas y en qué orden, qué buscas en cada una, cómo determinas si fue un ataque o una automatización legítima no documentada, qué contienes y en qué orden, y qué controles de gobierno habrían detectado o impedido esto antes.

La dirección de AlpinaShop pregunta por qué hay que dedicar cuatro días a "poner reglas" cuando el sistema funciona perfectamente y no ha habido ningún incidente.

Escribe la respuesta de Marta: qué riesgo concreto cubre cada bloque de trabajo, qué pasaría sin él con ejemplos reales del curso, qué coste tiene hacerlo ahora frente a dentro de dos años, y qué le pides además del tiempo. Máximo una página, en lenguaje no técnico.

Solución 1 — Diseñar las políticas de AlpinaTech

Jerarquía, y el criterio que la decide.

El factor determinante no es el tamaño ni los equipos: es que trabajan para clientes externos con requisitos distintos. Eso hace que el aislamiento por cliente sea más importante que el aislamiento por entorno.

Por qué carpeta por cliente y entorno dentro:

La última fila es la que más importa con freelance de por medio, y enlaza con el punto siguiente.

Conjunto de políticas.

Nótese la política 2 a nivel de carpeta clientes y no de organización. Aplicarla en la organización obligaría a la web corporativa y a las herramientas internas a estar en la UE, lo cual probablemente esté bien pero es una restricción que no se necesita. Las políticas se ponen en el nivel más alto donde tengan sentido, no en el más alto posible.

El caso de los freelance — la parte interesante del ejercicio.

Desactivar allowedPolicyMemberDomains para dar acceso a dos cuentas de Gmail sería tirar por la borda la política más valiosa del conjunto. Hay cuatro opciones, y la última es la correcta:

La solución: [email protected] gestionada por la empresa, con MFA obligatorio, condición de IAM con fecha de caducidad (03-04) coincidente con el fin del contrato, y permisos únicamente sobre el proyecto en el que trabajan.

El acceso caduca solo. No depende de que nadie se acuerde de revocarlo el 31 de diciembre, que es exactamente el tipo de tarea que se olvida. Y el coste de una licencia de Cloud Identity es ridículo comparado con el riesgo de que un consultor mantenga acceso a datos de un cliente durante dos años después de terminar.

Orden de despliegue.

1. Cloud Identity, dominio, grupos (at-desarrollo@, at-datos@, at-infra@, at-seguridad@), MFA obligatorio desde el minuto uno.
2. Organización y carpetas.
3. Facturación: cuenta, exportación a BigQuery, presupuesto global de 2.500 € y uno por carpeta de cliente.
4. alpinatech-auditoria con sumidero agregado y retención bloqueada. Antes que nada más, para capturar toda la construcción.
5. Políticas 1-11 en dry-run.
6. alpinatech-red con VPC compartida.
7. alpinatech-cicd con Workload Identity Federation.
8. Primer proyecto de cliente como plantilla, con módulo de Terraform reutilizable.
9. Políticas en modo aplicado.
10. Cargas de trabajo.

Ventaja decisiva de AlpinaTech sobre AlpinaShop: empieza en el paso 1 con la casilla vacía. No tendrá que negociar ninguna excepción, porque cuando aplique las políticas no habrá nada que las incumpla. Es literalmente el mejor momento posible, y solo ocurre una vez.

Sobre la ISO 27001 a 18 meses: prácticamente todo lo de esta lección es evidencia directa para la certificación —control de accesos, registro de auditoría inmutable, gestión de cambios, revisión periódica de permisos, clasificación de datos—. Hacerlo ahora significa llegar a la auditoría con 18 meses de registros; hacerlo dentro de un año significa llegar con seis. El auditor mira el histórico, no la foto del día.

Solución 2 — Investigar el cambio sospechoso

Lectura inicial de los indicios. Cuatro señales, y ninguna es concluyente por separado pero juntas dibujan un patrón muy reconocible:

Paso 1 — ¿Quién actuó de verdad? (5 minutos)

sa-deploy-prod es una cuenta de servicio; no actúa sola. La pregunta es quién la usó:

Los tres campos que deciden el caso:

Paso 2 — ¿Qué se concedió exactamente? (5 minutos)

Si el resultado incluye ADD roles/owner o ADD roles/editor a sa-mantenimiento, o cualquier concesión a una identidad externa, es un incidente y se activa el guion de 07-04.

Paso 3 — ¿Se usó la clave creada? (10 minutos)

Esta es la pregunta que determina el alcance:

Y el cambio sobre el bucket del data lake, que es el objetivo evidente:

Si buckets.update añadió allUsers, el data lake estuvo público. Eso convierte el caso en una brecha de datos personales con notificación a la AEPD en 72 horas.

Paso 4 — ¿Ataque o automatización no documentada? (15 minutos)

El indicio que más pesa es la creación de la clave. El pipeline de AlpinaShop usa Workload Identity Federation desde 06-02 y no necesita ni ha creado nunca una clave JSON. Una clave nueva en producción, un sábado a las 23:48, es casi con certeza persistencia de un atacante. Y el nombre sa-mantenimiento es exactamente el tipo de nombre plausible que se elige para pasar desapercibido en una lista.

Paso 5 — Contención, en este orden.

El orden importa: primero la credencial (paso 1), porque mientras exista el atacante sigue dentro; después la cuenta; después los permisos. Y el paso 7 nunca se omite: quien establece persistencia rara vez lo hace en un solo sitio.

Qué controles de gobierno lo habrían detectado o impedido.

Y la conclusión que da sentido a la lección entera: de las siete medidas, la primera habría impedido el ataque por completo y la segunda lo habría detectado en segundos. Ambas son de esta lección, ambas cuestan menos de una hora de configuración, y ninguna estaba puesta el sábado por la noche.

Un control preventivo que cuesta una hora vale más que la investigación más brillante.

Solución 3 — Justificar el gobierno ante dirección

Por qué dedicamos cuatro días a poner reglas en la nube Marta Ruiz, responsable de infraestructura

Es verdad que el sistema funciona y que no hemos tenido ningún incidente grave. También es verdad que funciona porque las tres personas del equipo nos acordamos de hacer las cosas bien, no porque nada lo impida. Hoy, cualquiera de nosotros —o cualquiera que entre a trabajar el mes que viene— puede, sin querer y sin que salte ninguna alarma, dejar un almacén de datos abierto a internet, crear una contraseña permanente que nadie sepa que existe, o poner datos de clientes en un servidor fuera de Europa.

No es una hipótesis. Este año hemos tenido dos casos. Encontramos una contraseña de acceso a datos que llevaba catorce meses perdida y seguía funcionando. Y descubrimos dos servicios encendidos que nadie usaba y que nos habían costado 1.500 €. Los dos se resolvieron, pero los dos los encontramos por casualidad, meses después.

Qué cubre cada bloque de trabajo:

Reglas automáticas (día 1). Impiden técnicamente lo que hoy solo evitamos por costumbre: nada de servidores expuestos a internet, nada de datos fuera de la UE, y —la más importante— nadie puede crear contraseñas permanentes. Sin esto, el caso de la contraseña perdida puede repetirse mañana.

Registro protegido (día 2). Guardamos en un sitio aparte, y con un candado que ni yo puedo abrir, el registro de todo lo que se hace en la plataforma. Sirve para tres cosas: si algo pasa, sabemos exactamente qué y quién; si un cliente o la Agencia de Protección de Datos nos lo pide, podemos demostrarlo; y como ni siquiera el administrador puede modificarlo, vale como prueba. Un registro que yo pudiera borrar no serviría de nada.

Avisos en el momento (día 3). Hoy, si alguien se concede permisos de administrador un sábado por la noche, nos enteraríamos en la revisión del mes siguiente. Con esto nos enteramos en segundos.

Inventario y revisiones (día 4). Saber en todo momento qué existe, quién tiene acceso a qué, y qué está costando dinero sin dar servicio.

Por qué ahora y no más adelante. Es una cuestión de aritmética, y es el argumento más importante de esta nota. Hoy tenemos cinco proyectos y unos ciento veinte recursos: poner las reglas afecta a cero cosas existentes, porque ya lo hacemos todo bien. Dentro de dos años, con quince proyectos y seiscientos recursos, poner esas mismas reglas significará encontrar todo lo que no las cumple, hablar con cada equipo y aceptar excepciones permanentes que dejarían las reglas casi vacías. Cuatro días ahora son cuatro semanas dentro de dos años, y probablemente ya no se haga.

Y hay un motivo comercial que también conviene tener presente: cuando un cliente grande nos pida un cuestionario de seguridad —y nos lo van a pedir— la diferencia entre responder "sí, y aquí está el registro de los últimos dieciocho meses" y responder "confiamos en nuestro equipo" puede ser la diferencia entre firmar el contrato o no.

Lo que pido además del tiempo:

1. Que una segunda persona tenga las llaves maestras. Hoy soy la única que puede levantar estas reglas. Si me equivoco o no estoy disponible, el equipo se queda bloqueado.
2. Media hora al trimestre para revisar juntos quién tiene acceso a qué. Es rápido y evita que los permisos se acumulen solos, que es lo que siempre acaba pasando.
3. Aceptar que durante dos semanas iremos algo más despacio, mientras medimos el impacto de las reglas antes de activarlas. No vamos a encender nada sin haberlo probado primero: bloquear al equipo por prisa sería el peor resultado posible.

Las cuatro decisiones de comunicación:

1. Reconocer que tienen razón antes de rebatir. "Es verdad que funciona" desarma la objeción en lugar de enfrentarse a ella. Lo que se corrige es el porqué funciona, no el hecho.
2. Dos incidentes reales en lugar de riesgos hipotéticos. "Podría pasar" se descarta; "nos pasó en marzo y lo encontramos en julio" no. Y ambos casos se resolvieron, lo que permite contarlos sin parecer alarmista ni incompetente.
3. El argumento aritmético como eje. Cuatro días ahora frente a cuatro semanas dentro de dos años es un razonamiento que un director financiero entiende inmediatamente y con el que no se puede discutir, porque no depende de valorar el riesgo: depende de contar.
4. El ángulo comercial al final. Convierte el gobierno de coste en habilitador de ingresos. Es el argumento que más peso tiene en un consejo y por eso va después de los demás, no antes: puesto primero parecería una excusa; puesto al final, remata.

Y una quinta, que se ve en las peticiones: se pide explícitamente ir más despacio dos semanas. Anunciar el coste antes de que se note evita que la primera fricción se interprete como un error de planificación.

El módulo 7 termina donde tenía que terminar: convirtiendo en controles lo que hasta ahora eran acuerdos.

Sabes qué es el gobierno y respondes a sus cuatro preguntas con mecanismos concretos: qué se puede crear (políticas de organización), qué existe (Asset Inventory), quién hizo qué (Audit Logs) y quién paga (estructura y etiquetas). Y tienes el argumento que decide cuándo implantarlo: el coste no crece con los recursos, crece con las excepciones que hay que negociar. Las políticas se ponen cuando no molestan a nadie; después ya no se ponen.

Sabes estructurar una organización con los tres criterios —entorno, equipo, aplicación— y, más importante, con sus consecuencias en permisos, políticas heredadas, facturación, cuotas y radio de explosión. Entiendes por qué AlpinaShop estructura por entorno y por qué AlpinaTech, con clientes externos, debe hacerlo por cliente.

Dominas las políticas de organización: qué las distingue de IAM —no son permisos, y no las salta ni un owner—, sus tres tipos, y la herencia con su regla clave: una denegación en cualquier nivel gana siempre. Tienes las nueve políticas de AlpinaShop con su motivo, su nivel y su riesgo, incluidas las dos que cierran deudas críticas de 07-04.

Sabes aplicarlas sin bloquear al equipo: el patrón dry-run por cuarta vez en el curso, el procedimiento de ocho pasos que empieza por inventariar lo que ya incumple, las cinco formas reales de bloquearse a uno mismo, y la salvaguarda que hay que preparar antes de todo: dos personas con orgpolicy.policyAdmin.

Sabes escribir restricciones personalizadas con CEL y distinguirlas de Policy Controller, que actúa sobre Kubernetes y no compite sino que complementa. Y sabes que las cuotas impiden donde los presupuestos solo avisan.

Manejas Cloud Asset Inventory para saber qué existe, buscar recursos y políticas IAM, exportar a BigQuery y construir el histórico que responde a "¿qué había el 3 de junio?". Y montas feeds que avisan en segundos de una concesión de owner, un bucket público o —el más importante— la creación de una clave de cuenta de servicio.

Conoces los Cloud Audit Logs de verdad: los cuatro tipos, con los dos datos que hay que retener —la actividad de administrador es gratis y no se puede desactivar; el acceso a datos está apagado por defecto y sin él no se puede acotar una brecha— y las tres decisiones que hacen su coste asumible. Sabes leer una entrada campo a campo, incluido serviceAccountDelegationInfo, que casi nadie mira y sin el cual se pierde el rastro de la persona detrás de una impersonación.

Tienes las cinco consultas de auditoría guardadas antes de necesitarlas, con la de "quién tocó un log" señalada como la más importante y la menos frecuente, y con las denegaciones de política usadas como termómetro de si tus reglas están bien calibradas.

Y has montado la pieza que hace creíble todo lo demás: retención inmutable en un proyecto separado, con sumidero agregado a nivel de organización e --include-children para que ningún proyecto futuro quede fuera, con logging.bucketWriter concedido a la writerIdentity —el paso que se olvida siempre—, y con --locked irreversible. Donde Marta, que administra toda la plataforma, solo puede leer. Porque un log que el administrador puede borrar no sirve como evidencia.

Sabes qué es una zona de aterrizaje y —lo que importa— por qué el orden es el que es: la auditoría antes que la red y las cargas, para no perder los logs del periodo con más cambios de toda la vida de la plataforma. Con los depends_on explícitos de Terraform como caso legítimo, y con los blueprints de Google como referencia y no como plantilla.

Y tienes los procesos de gestión del cambio dimensionados para tres personas: revisiones con su periodicidad y su script, ciclo de vida de proyectos con fecha de caducidad obligatoria en los de prueba, y un proceso de excepciones donde la fecha de caducidad es lo único que separa una excepción de una derogación permanente.

Y aquí termina el módulo 7. Mira dónde está AlpinaShop.

Empezó este módulo con una aplicación que se construía, se desplegaba y se observaba sola, y con una lista de conversaciones aplazadas. Hoy la lista está vacía. DA-004 decidió no adoptar la plataforma híbrida y conectar Sabadell con un túnel, con sus condiciones de revisión escritas. DA-001, prometida en el módulo 2 y arrastrada durante cinco, está cumplida: el catálogo corre en Cloud Run, el MIG está apagado, y no queda una sola máquina virtual en la ruta de servicio. La red es una VPC compartida con permisos por subred, conectividad híbrida real y un perímetro que impide que los datos salgan. La seguridad se ha revisado entera capa por capa, con un checklist de 43 controles y una deuda priorizada de la que ya está pagada la parte crítica. La factura ha bajado un 60 % y —más importante— se entiende, se atribuye y se sigue por coste unitario. La fiabilidad tiene números: cuatro SLI, cuatro SLO, presupuesto de error con política, plan de recuperación con RTO y RPO, y una restauración probada que encontró cinco problemas que nadie sospechaba. Y el gobierno convierte todo eso en controles que no dependen de que nadie se acuerde.

Queda deuda, escrita y priorizada. Y queda una lista de cosas que AlpinaShop ha decidido no hacer, con su motivo — que es lo que de verdad distingue a una organización madura de una que simplemente no llegó.

Has recorrido siete módulos siguiendo a Marta, a Dani y a Lucía. Has visto crear una cuenta y una jerarquía, migrar una aplicación, elegir entre cinco servicios de cómputo, montar redes, identidades y secretos, construir una plataforma de datos, entrenar y servir modelos, automatizar la entrega, observar el sistema, resolver un incidente de extremo a extremo, escribir la infraestructura como código, y ahora asegurarla, medirla, abaratarla y gobernarla. Has visto tomar decisiones y también deshacerlas: App Engine se descartó, GKE se retiró, Anthos se rechazó, un endpoint se apagó. Has visto cuatro decisiones de arquitectura documentadas, revisadas y —algunas— cumplidas años después de escribirse.

Lo que no has hecho todavía es decidir tú.

El módulo 8 es tu proyecto. Ya no hay una AlpinaShop a la que seguir: hay una empresa, un problema y un conjunto de restricciones que tendrás que resolver de principio a fin. Vas a recoger requisitos y traducirlos a decisiones (08-01), diseñar la arquitectura completa justificando cada elección igual que se justificó DA-001 (08-02), implementarla con infraestructura como código y entrega continua (08-03), probarla y desplegarla con canario, SLO y plan de recuperación (08-04), y presentarla y defenderla ante quien te pregunte por qué elegiste lo que elegiste (08-05). Y terminarás mirando hacia adelante, hacia las certificaciones de Google Cloud y hacia lo que viene después de este curso (08-06).

Todo lo que necesitas está en los siete módulos que acabas de recorrer. Ahora te toca a ti.