Tot el que AlpinaShop ha construït en set mòduls funciona perquè tres persones se'n recorden. La Marta es recorda de no crear VM amb IP pública. En Dani es recorda d'etiquetar els recursos. La Lucía es recorda de no exportar dades a un bucket extern. Els SLO viuen en un tauler que algú manté, els runbooks s'actualitzen perquè algú els revisa, i la política de pressupost d'error es respecta perquè l'equip la va acordar una tarda.

Res d'això no està malament. Tot això és fràgil.

Perquè avui, tècnicament, res no impedeix que demà algú creï una màquina amb IP pública a Iowa, desactivi un registre d'auditoria, comparteixi un bucket amb allUsers, o descarregui una clau JSON d'un compte de servei. Les bones pràctiques del curs són acords, no controls. I un acord es trenca el dia que entra una persona nova, el dia que algú té pressa, o el dia que l'empresa passa de tres persones tècniques a vuit.

Govern és exactament això: convertir els acords en controls que s'apliquen sols, i tenir registre fiable de tot el que passa. És la diferència entre «confiem que ningú no ho faci» i «no es pot fer».

I hi ha un malentès que convé desfer des de la primera línia: el govern no és una cosa que s'implanta quan s'és gran. S'implanta abans, perquè adaptar polítiques a posteriori sobre una organització amb cinquanta projectes i mil recursos és una obra de mesos, mentre que aplicar-les sobre cinc projectes és una tarda. AlpinaShop arriba tard, però no massa tard. Aquesta és l'única raó per la qual aquesta lliçó encara és factible en un dia de feina.

En acabar sabràs estructurar una organització i entendre les conseqüències de cada criteri, aplicar polítiques d'organització que s'hereten i bloquegen de debò, inventariar tot el que existeix i monitorar els canvis en temps real, activar i llegir els registres d'auditoria que importen, muntar retenció immutable en un projecte on ni els administradors puguin escriure, i desplegar tot això de cop com una zona d'aterratge amb Terraform.

I tancaràs el mòdul 7 i, amb ell, el recorregut complet d'AlpinaShop.

1. Què és el govern al núvol i per què es necessita abans del que sembla
2. L'estructura de l'organització: criteris i conseqüències
3. Polítiques d'organització: què són i com s'hereten
4. Les polítiques que AlpinaShop aplica, una a una
5. Mode de prova i el perill de bloquejar l'equip
6. Restriccions personalitzades i la seva relació amb Policy Controller
7. Quotes i límits a nivell d'organització
8. Cloud Asset Inventory: saber què existeix
9. Feeds: monitorar canvis en temps real
10. Cloud Audit Logs de debò
11. Les consultes d'auditoria que cal tenir preparades
12. Retenció immutable en un projecte separat
13. Zones d'aterratge i l'ordre que importa
14. Gestió del canvi: revisions, cicle de vida i excepcions
15. La maduresa d'AlpinaShop, i el que li queda

Govern és el conjunt d'estructures, polítiques i processos que asseguren que l'ús del núvol és coherent amb el que l'organització vol. Cobreix quatre preguntes:

I la raó per la qual es necessita abans de «ser gran», que és purament aritmètica:

El cost no creix amb el nombre de recursos: creix amb el nombre d'excepcions que cal negociar. Aplicar avui la política «prohibit crear VM amb IP pública» afecta zero recursos existents. Aplicar-la d'aquí a cinc anys significa trobar les quaranta VM que la incompleixen, esbrinar per què, parlar amb sis equips i acceptar vint excepcions permanents que buiden la política de contingut.

La regla: les polítiques es posen quan no molesten ningú. Després ja no es posen.

La jerarquia de 01-04, revisada ara amb tot el context:

Dos canvis respecte de 01-04: el projecte alpinashop-red de 07-03 viu a compartido, i apareix una carpeta nova, seguridad, amb alpinashop-auditoria — el projecte de registres immutables de l'apartat 12. Està separat a propòsit: és l'únic on ni la Marta pot escriure.

Poques vegades se n'usa un de sol; l'habitual és combinar dos nivells.

Conseqüències de l'elecció, que és el que gairebé mai no es pensa abans de decidir:

L'elecció d'AlpinaShop és per entorn al primer nivell, i és la correcta per a la seva mida per un motiu concret: la diferència d'exigència entre producció i desenvolupament és molt més gran que la diferència entre equips. Ningú no és owner de producció, però en desenvolupament es pot ser editor sense drama. Amb una estructura per equips, aquesta distinció seria impossible d'expressar.

Quan AlpinaShop tingui quatre productes, l'evolució natural és un segon nivell: produccion/tienda, produccion/alpinapro, desarrollo/tienda… L'estructura de carpetes es pot canviar; moure projectes entre carpetes és una comanda. El que no es pot canviar és el projectId.

L'Organization Policy Service és el que converteix els acords en controls.

L'última fila és l'essència: una política d'organització no és un permís. Encara que tinguis roles/owner al projecte, si la política prohibeix IP públiques, no en pots crear una. Només la pot aixecar qui tingui roles/orgpolicy.policyAdmin al nivell on està definida.

Les polítiques s'hereten d'organització → carpeta → projecte, i a cada nivell es pot:

I la regla que sorprèn tothom: per a les restriccions de llista, una denegació en qualsevol nivell guanya sempre. Un fill no pot permetre el que el pare denega. És el que fa que el model sigui segur: no es pot escapar d'una política cap avall.

Conseqüència pràctica: les polítiques es defineixen al nivell més alt on tinguin sentit, i es relaxen cap avall només amb allow addicionals sobre restriccions que el pare no va denegar explícitament. Si et trobes necessitant «des-denegar» alguna cosa, la política estava mal posada.

Aquestes són les nou, amb el seu motiu, el seu nivell i el seu risc.

Amb l'excepció declarada, si alguna VM legítima la necessités:

Motiu: a AlpinaShop no queda cap VM a la ruta de servei (07-02), i les de desenvolupament surten per Cloud NAT. Una IP pública és superfície d'atac directa des d'internet. Nivell: organització. Risc de bloqueig: baix.

Motiu: residència de la dada a la UE (07-01, 07-04) i control de costos de trànsit intercontinental (07-05). Nivell: organització. Risc: mitjà-alt, i és la política que més disgustos dona. Molts serveis tenen components globals o multiregió, i in:eu-locations és imprescindible perquè BigQuery multiregió i alguns buckets continuïn funcionant. Aquesta es prova en dry-run sí o sí.

Motiu: és el deute #1 de 07-04. Amb federació d'identitat i impersonació ja en ús, no hi ha cap cas legítim que necessiti una clau descarregable. Nivell: organització. Risc: mitjà. Pot trencar integracions antigues — per això primer l'inventari de l'apartat 8, després la política.

I la seva companya, que impedeix que una clau existent valgui eternament:

Motiu: OS Login vincula l'accés SSH a la identitat de Google en lloc de a claus SSH soltes a les metadades. Això significa que donar de baixa una persona al directori li treu l'accés a totes les màquines, que és exactament el que no passa amb les claus a les metadades. Nivell: organització. Risc: baix (amb prou feines queden VM).

Motiu: un bucket públic és la fuita de dades més comuna del núvol, en tots els proveïdors. Nivell: organització. Risc: baix… amb un parany que cal resoldre abans: el bucket alpinashop-catalogo serveix imatges a la botiga. Si aquestes imatges se serveixen a través del balancejador amb bb-catalogo-imagenes (03-02), el bucket no necessita ser públic i la política no trenca res. Si algú les estigués servint per URL directa de Cloud Storage, sí. Comprovar-ho és part de la feina prèvia.

Motiu: desactiva les ACL per objecte, que són un sistema de permisos paral·lel a IAM, invisible a les auditories i responsable d'innombrables fuites. Amb accés uniforme, IAM és l'única veritat.

Motiu: tanca el control de 03-06. La segona política és la que gairebé ningú no posa i evita que algú xifri dades amb una clau d'un projecte que no controles. Nivell: carpeta produccion. Risc: alt. Exigir CMEK trenca la creació de recursos si la clau no té els permisos correctes concedits a l'agent de servei corresponent. dry-run obligatori.

Motiu: és el deute #2 de 07-04. Impedeix que els projectes nous neixin amb el compte per defecte de Compute amb rol Editor. No arregla els projectes existents, que cal corregir a mà.

Motiu: impedeix concedir permisos a comptes de Google alienes a l'organització. És la política que evita l'error de donar accés a [email protected] «temporalment». Risc: alt. Trenca qualsevol col·laboració legítima amb externs, i trenca alguns agents de servei de Google. Requereix excepcions acurades i dry-run llarg.

Les polítiques d'organització admeten mode de prova (dry run), igual que Cloud Armor (03-05), Policy Controller (07-01) i VPC Service Controls (07-03). És el mateix patró per quarta vegada al curs, i no és casualitat: tot control que denega s'ha de mesurar abans d'aplicar-se.

I la consulta del que hauria bloquejat:

El pas 1 és el que se salta tothom i el que evita el desastre. Aplicar dry-run sobre polítiques que ja s'incompleixen genera centenars de violacions que ningú no analitzarà, i el resultat pràctic és que s'ignoren totes.

Reals, totes vistes en producció:

I la salvaguarda que cal preparar abans de tot això: que almenys dues persones tinguin roles/orgpolicy.policyAdmin a l'organització, amb accés verificat. Si l'única persona que pot aixecar una política es bloqueja a si mateixa, la sortida passa pel suport de Google i per un mal dia.

Quan cap restricció predefinida no serveix, s'escriu una restricció personalitzada amb CEL (Common Expression Language):

Un altre exemple, aquesta vegada per a les etiquetes obligatòries de 07-05:

Dos sistemes que fan coses semblants en àmbits diferents. La confusió és habitual:

No competeixen: es complementen. Una política d'organització no pot impedir que un pod s'executi com a root, i Policy Controller no pot impedir que es creï un bucket públic. Una organització amb Kubernetes necessita totes dues.

Per a AlpinaShop, que va retirar les càrregues de producció de GKE a 07-02, les polítiques d'organització són les que importen. Policy Controller queda com a control del clúster de proves, cosa coherent amb el que es va decidir a DA-004.

Les quotes es gestionen per projecte, però es poden governar des de dalt mitjançant polítiques i automatització.

La distinció essencial, ja vista a 07-05 i que aquí es col·loca al seu lloc: els pressupostos avisen, les quotes impedeixen. En una organització governada calen totes dues, i les quotes són l'únic mecanisme que no depèn que algú reaccioni.

No es pot governar el que no se sap que existeix. Cloud Asset Inventory és el catàleg de tots els recursos, polítiques IAM i configuracions de l'organització, amb el seu historial.

Aquestes dues consultes, executades abans d'aplicar les polítiques 4.1, 4.2 i 4.9, són exactament el pas 1 del procediment de l'apartat 5. Sense elles, s'aplica a cegues.

Amb exportació diària programada (Cloud Scheduler + Workflows, 04-06), s'obté una cosa molt valuosa: l'històric de l'inventari, que permet respondre «què hi havia el 3 de juny?» — una pregunta que apareix en tota investigació i en tota auditoria.

L'inventari diu què hi ha. Els feeds avisen quan alguna cosa canvia, en el moment.

I la funció que decideix què mereix un avís immediat (Cloud Functions 2a gen, 06-03):

Amb una alerta de Cloud Monitoring sobre jsonPayload.alerta_gobierno=true i gravetat CRITICAL, aquests esdeveniments arriben al canal de seguretat en segons.

Això tanca el deute #4 de 07-04 —alertes de canvis d'IAM i creació de claus— i és la diferència entre assabentar-se d'un canvi perillós en el moment o descobrir-lo a la revisió trimestral, sis setmanes després.

S'han esmentat a 03-04, 06-06 i 07-04. Aquí, complets.

Les dues dades que cal retenir:

1. L'activitat d'administrador és gratis i no es pot desactivar. Ni tan sols un atacant amb permisos d'organització pot esborrar l'evidència dels seus canvis de configuració. És el fonament de tota investigació.
2. L'accés a dades està desactivat per defecte. I sense ell, com va demostrar l'exercici de 07-04, no es pot saber qui va llegir les dades dels clients — cosa que converteix una credencial filtrada en una bretxa d'abast indeterminable.

Es fa amb criteri, perquè el volum pot ser enorme:

Les tres decisions que fan això assequible, i són les que converteixen un cost inacceptable en uns 35 € al mes (07-05):

• Cloud Storage sense DATA_READ: el bucket del catàleg serveix milions d'imatges; registrar cada lectura costaria més que tota la plataforma. Es registren escriptures i lectures administratives, que és on hi ha el risc.
• Secret Manager amb tot: són pocs accessos i cadascun importa.
• Només a la carpeta produccion: en desenvolupament no hi ha dades reals.

I una exclusió imprescindible perquè el volum no es dispari:

S'exclouen les lectures que fan els mateixos agents de servei de Google, que són soroll pur i d'altíssim volum.

Els camps que cal saber llegir, per ordre d'importància:

serviceAccountDelegationInfo és el camp que gairebé ningú no mira i el que més importa en una organització que fa servir impersonació: sense ell, un canvi fet per la Marta impersonant sa-deploy-prod apareix atribuït al compte de servei, i es perd el rastre de la persona.

Escrites i desades com a vistes abans de necessitar-les. Un incident no és moment d'aprendre SQL.

1. Qui va canviar una política IAM?

2. Qui va accedir a dades de clients?

3. Qui va apagar o modificar un registre?

Aquesta tercera és la més important de les tres, i la que menys gent té. Manipular el registre és el primer que fa un atacant competent i el primer que fa algú que vol amagar un error. Ha de tenir alerta permanent.

4. Activitat fora d'horari.

El filtre que exclou comptes de servei és essencial: el programari treballa de nit, i sense aquest filtre la consulta retorna milers de línies irrellevants.

5. Denegacions de política: el que algú va intentar i no va poder.

Aquesta consulta té un doble ús que convé entendre: detecta intents maliciosos, i també detecta polítiques mal calibrades que estan destorbant l'equip. Si en Dani apareix vint vegades intentant una cosa legítima, el problema és la política, no en Dani.

Aquí hi ha la peça que fa que l'auditoria sigui creïble.

Un registre que l'administrador pot esborrar no serveix com a evidència.

Si la Marta té permisos per modificar els registres d'auditoria, aleshores davant de qualsevol investigació —interna, d'un client o de l'AEPD— la resposta a «podria algú haver alterat això?» és «sí». I això buida de valor tot el registre.

La solució és un projecte separat amb permisos que ni tan sols els administradors tenen.

I el repartiment de permisos, que és la clau de tot:

La Marta, que administra tota la plataforma, aquí només pot llegir. És la separació de funcions de 07-04 portada a la seva conclusió: qui administra no custodia l'evidència del que administra.

--include-children és el que el fa agregat: recull els registres de tots els projectes i carpetes de l'organització, inclosos els que es creïn en el futur. Sense aquesta bandera, cada projecte nou quedaria fora i ningú no se n'adonaria.

Després cal concedir a l'escriptor de l'abocador permís sobre la destinació:

Aquest pas s'oblida constantment i el símptoma és desconcertant: l'abocador existeix, apareix a la consola, i no arriba res. Sense errors.

⚠️ --locked és irreversible. A partir d'aquest moment ningú, ni Google, ni l'owner de l'organització, ni el suport, pot reduir la retenció ni esborrar el bucket abans que expiri. Aquest és exactament el punt: la garantia és que ni tu pots.

I per a conservació a llarg termini, amb bloqueig de retenció de Cloud Storage:

Això és el que es coneix com a emmagatzematge WORM (Write Once, Read Many), i és el que exigeixen molts marcs de compliment normatiu. També és, dit sigui de passada, la millor defensa contra ransomware que existeix: un atacant amb permisos totals no pot xifrar ni esborrar el que està sota bloqueig de retenció.

Amb una contrapartida que cal assumir conscientment: si es bloquegen 7 anys, es paguen 7 anys d'emmagatzematge, sense excepció. Abans de bloquejar, es calcula el volum i es comprova que el número té sentit.

Una zona d'aterratge (landing zone) és l'organització preparada abans que arribi la primera càrrega de treball: jerarquia, polítiques, xarxa, identitat, auditoria i facturació, tot desplegat amb codi.

AlpinaShop ho ha fet a l'inrevés, com gairebé tothom: primer les càrregues, després el govern. Ha funcionat perquè és petita. La forma correcta, i la que cal conèixer per al pròxim projecte, és aquesta.

Les quatre raons per les quals aquest ordre concret i no un altre:

1. L'auditoria (5) va abans que la xarxa i les càrregues. Si l'abocador es crea després, els registres de tot el que es va fer mentrestant no estan capturats. La construcció de la plataforma és precisament el període amb més canvis de permisos, i és el que més interessa tenir registrat.
2. Les polítiques en dry-run (4) van abans que els projectes de càrrega (8). Així es mesuren sobre recursos que es van creant, i les violacions es corregeixen sobre la marxa en lloc d'acumular-se.
3. La xarxa (6) abans que els projectes de servei (8). Un projecte de servei necessita que existeixi l'amfitrió.
4. Les polítiques aplicades (9) abans que les càrregues (10). És l'únic moment en què aplicar una política no trenca res, perquè no hi ha res per trencar.

depends_on explícit a cada mòdul, encara que no hi hagi referències entre ells. És el cas legítim de depends_on que 06-07 assenyalava com a excepció: l'ordre aquí no ve de dependències de dades, sinó d'una seqüència lògica que Terraform no pot inferir.

Google publica els blueprints de fonamentació (Cloud Foundation Fabric, Terraform Example Foundation), que implementen tot això amb criteri. Mereixen un advertiment honest: estan pensats per a organitzacions grans i porten molta més estructura de la que necessita una pime. Fes-los servir com a referència i com a font de decisions ben pensades, no com a plantilla per copiar.

Quatre dies de feina repartits en quatre setmanes. Aquest és el preu de governar la plataforma, i explica per què l'aritmètica de l'apartat 1 importa: d'aquí a dos anys serien quatre setmanes de feina i sis mesos de calendari.

Les polítiques tècniques no basten. Calen processos, i per a un equip de tres persones han de ser lleugers o no es faran.

La data de caducitat obligatòria als projectes de prova és la mesura que més despesa fantasma evita (07-05), perquè ataca la causa en lloc del símptoma. S'implementa amb una etiqueta caduca=2026-12-31 i una feina setmanal que avisa dels vençuts.

I els 30 dies d'espera abans d'esborrar no són burocràcia: esborrar un projecte és irreversible passat el període de gràcia, i sempre apareix algú que necessitava alguna cosa d'allà.

Tota política acabarà tenint excepcions. Sense procés, es concedeixen de paraula i es converteixen en permanents.

La data de caducitat és el que separa una excepció d'una derogació. Sense ella, la política queda buida de contingut per sempre i ningú no recorda per què.

A curt termini (aquest trimestre):

1. Acabar d'aplicar les polítiques d'organització. Estan en dry-run; cal travessar les 4 setmanes de l'apartat 13.
2. Documentació de compliment normatiu actualitzada, amb assessoria professional. És la casella més endarrerida i l'única amb conseqüències legals.
3. Provar el procediment de dret de supressió d'extrem a extrem, amb un client de prova.

A mitjà termini (aquest any):

4. Multiregió per a Cloud SQL, que és l'única cosa que impedeix l'alta disponibilitat regional completa (07-06).
5. Detecció activa d'amenaces, quan hi hagi algú que la pugui atendre (07-04).
6. Elevació temporal de privilegis amb PAM.
7. Revisió externa de seguretat sobre l'arquitectura ja endurida.

El que NO farà, i està bé:

Aquesta última taula és la més valuosa de la lliçó, perquè una organització madura no és la que ha adoptat més tecnologia: és la que sap justificar el que ha decidit no adoptar. Les sis files tenen la seva decisió escrita, el seu motiu, i —en el cas de DA-004— les seves condicions de revisió.

Val la pena mirar enrere una vegada.

AlpinaShop va començar el mòdul 1 sense compte de Google Cloud, amb una botiga que funcionava en algun lloc i tres persones que no sabien què era una regió. Va acabar el mòdul 2 amb l'aplicació migrada i una decisió pendent. El mòdul 3 li va donar xarxa, balanceig, identitat i secrets. El 4, una plataforma de dades. El 5, models que prediuen. El 6, lliurament continu i observabilitat. I el 7 ha resolt el que quedava: l'híbrid, el còmput definitiu, la xarxa avançada, la seguretat revisada, la factura entesa, la fiabilitat mesurada i el govern aplicat.

Avui AlpinaShop té una plataforma que una persona pot operar, qualsevol pot entendre llegint un repositori, i es reconstrueix sencera amb terraform apply. No és perfecta —té una llista de deutes escrita i prioritzada, que és exactament el que ha de tenir— però és defensable davant d'un client, davant d'un auditor i davant de la persona que entri a treballar el mes que ve.

• Deixar el govern per «quan siguem grans». El cost creix amb les excepcions que cal negociar, no amb el nombre de recursos. Es fa ara o no es fa.
• Aplicar polítiques sense inventariar abans el que les incompleix. Es generen centenars de violacions que ningú no analitza i el dry-run deixa de servir.
• Oblidar in:eu-locations a resourceLocations. BigQuery multiregió i alguns buckets deixen de crear-se.
• allowedPolicyMemberDomains sense excepcions per als agents de servei de Google. Serveis interns fallen de maneres inexplicables.
• Exigir CMEK sense donar permisos a l'agent de servei sobre la clau. Els recursos nous no es poden crear.
• Aplicar polítiques un divendres. Cap de setmana sense poder desplegar.
• Que només una persona tingui orgpolicy.policyAdmin. Si es bloqueja a si mateixa, la sortida és el suport de Google.
• Abocador sense --include-children. Els projectes nous queden fora i ningú no se n'assabenta.
• Oblidar donar logging.bucketWriter a la writerIdentity de l'abocador. L'abocador existeix i no arriba res, sense errors.
• Crear el projecte d'auditoria al final. Els registres de la fase de construcció, que és la de més canvis, es perden.
• Que l'administrador pugui escriure als registres d'auditoria. Aleshores no valen com a evidència.
• Bloquejar la retenció sense calcular el volum. --locked és irreversible i pagues tots els anys que vas posar.
• Activar DATA_READ en un bucket que serveix imatges. Milions d'entrades i una factura absurda.
• No mirar serviceAccountDelegationInfo. En una organització amb impersonació, sense aquest camp es perd el rastre de la persona.
• Excepcions sense data de caducitat. Deixen de ser excepcions i buiden la política.
• Copiar un blueprint de fonamentació tal qual. Estan fets per a organitzacions grans i porten estructura que no necessites.
• Consell: la consulta de «qui va tocar un registre» mereix alerta permanent. És el primer que manipula qui vol amagar alguna cosa.
• Consell: posa data de caducitat obligatòria als projectes de prova. Ataca la causa de la despesa fantasma, no el símptoma.
• Consell: fes servir les denegacions de política com a termòmetre. Si algú de l'equip apareix vint vegades, la política està mal calibrada.
• Consell: escriu el que decideixes NO adoptar. És el que distingeix una organització madura d'una que simplement no hi va arribar.

AlpinaTech, una consultora de 25 persones, arrenca a Google Cloud des de zero. Dades:

• Tres equips: desenvolupament (12), dades (5), infraestructura (3). La resta no és tècnica.
• Treballen per a clients externs, i alguns exigeixen que les seves dades no surtin de la UE.
• Dos consultors autònoms amb compte de Gmail col·laboren en projectes concrets.
• Un client exigeix certificació ISO 27001 en 18 mesos.
• Pressupost: 2.500 €/mes de núvol.

Dissenya: la jerarquia de carpetes i projectes amb el seu criteri justificat, el conjunt complet de polítiques d'organització amb el seu nivell i el seu risc, com resols el cas dels autònoms sense desactivar allowedPolicyMemberDomains, i l'ordre de desplegament de la zona d'aterratge.

Un dilluns al matí, la consulta d'auditoria mensual revela això:

Era dissabte a la nit. No hi havia cap desplegament programat. El compte sa-mantenimiento no apareix al Terraform d'AlpinaShop.

Escriu la investigació completa: quines consultes executes i en quin ordre, què busques a cadascuna, com determines si va ser un atac o una automatització legítima no documentada, què contens i en quin ordre, i quins controls de govern haurien detectat o impedit això abans.

La direcció d'AlpinaShop pregunta per què cal dedicar quatre dies a «posar regles» quan el sistema funciona perfectament i no hi ha hagut cap incident.

Escriu la resposta de la Marta: quin risc concret cobreix cada bloc de feina, què passaria sense ell amb exemples reals del curs, quin cost té fer-ho ara davant de fer-ho d'aquí a dos anys, i què li demanes a més del temps. Màxim una pàgina, en llenguatge no tècnic.

Solució 1 — Dissenyar les polítiques d'AlpinaTech

Jerarquia, i el criteri que la decideix.

El factor determinant no és la mida ni els equips: és que treballen per a clients externs amb requisits diferents. Això fa que l'aïllament per client sigui més important que l'aïllament per entorn.

Per què carpeta per client i entorn a dins:

L'última fila és la que més importa amb autònoms pel mig, i enllaça amb el punt següent.

Conjunt de polítiques.

Fixa't en la política 2 a nivell de carpeta clientes i no d'organització. Aplicar-la a l'organització obligaria la web corporativa i les eines internes a ser a la UE, cosa que probablement estigui bé però és una restricció que no es necessita. Les polítiques es posen al nivell més alt on tinguin sentit, no al més alt possible.

El cas dels autònoms — la part interessant de l'exercici.

Desactivar allowedPolicyMemberDomains per donar accés a dos comptes de Gmail seria llençar per la borda la política més valuosa del conjunt. Hi ha quatre opcions, i l'última és la correcta:

La solució: [email protected] gestionat per l'empresa, amb MFA obligatori, condició d'IAM amb data de caducitat (03-04) coincident amb el final del contracte, i permisos únicament sobre el projecte on treballen.

L'accés caduca sol. No depèn que ningú es recordi de revocar-lo el 31 de desembre, que és exactament el tipus de tasca que s'oblida. I el cost d'una llicència de Cloud Identity és ridícul comparat amb el risc que un consultor mantingui accés a dades d'un client durant dos anys després d'acabar.

Ordre de desplegament.

1. Cloud Identity, domini, grups (at-desarrollo@, at-datos@, at-infra@, at-seguridad@), MFA obligatori des del minut u.
2. Organització i carpetes.
3. Facturació: compte, exportació a BigQuery, pressupost global de 2.500 € i un per carpeta de client.
4. alpinatech-auditoria amb abocador agregat i retenció bloquejada. Abans que res més, per capturar tota la construcció.
5. Polítiques 1-11 en dry-run.
6. alpinatech-red amb VPC compartida.
7. alpinatech-cicd amb Workload Identity Federation.
8. Primer projecte de client com a plantilla, amb mòdul de Terraform reutilitzable.
9. Polítiques en mode aplicat.
10. Càrregues de treball.

Avantatge decisiu d'AlpinaTech sobre AlpinaShop: comença al pas 1 amb la casella buida. No haurà de negociar cap excepció, perquè quan apliqui les polítiques no hi haurà res que les incompleixi. És literalment el millor moment possible, i només passa una vegada.

Sobre la ISO 27001 a 18 mesos: pràcticament tot el d'aquesta lliçó és evidència directa per a la certificació —control d'accessos, registre d'auditoria immutable, gestió de canvis, revisió periòdica de permisos, classificació de les dades—. Fer-ho ara significa arribar a l'auditoria amb 18 mesos de registres; fer-ho d'aquí a un any significa arribar amb sis. L'auditor mira l'històric, no la foto del dia.

Solució 2 — Investigar el canvi sospitós

Lectura inicial dels indicis. Quatre senyals, i cap no és concloent per separat però juntes dibuixen un patró molt reconeixible:

Pas 1 — Qui va actuar de debò? (5 minuts)

sa-deploy-prod és un compte de servei; no actua sol. La pregunta és qui el va fer servir:

Els tres camps que decideixen el cas:

Pas 2 — Què es va concedir exactament? (5 minuts)

Si el resultat inclou ADD roles/owner o ADD roles/editor a sa-mantenimiento, o qualsevol concessió a una identitat externa, és un incident i s'activa el guió de 07-04.

Pas 3 — Es va fer servir la clau creada? (10 minuts)

Aquesta és la pregunta que determina l'abast:

I el canvi sobre el bucket del data lake, que és l'objectiu evident:

Si buckets.update va afegir allUsers, el data lake va estar públic. Això converteix el cas en una bretxa de dades personals amb notificació a l'AEPD en 72 hores.

Pas 4 — Atac o automatització no documentada? (15 minuts)

L'indici que més pesa és la creació de la clau. El pipeline d'AlpinaShop fa servir Workload Identity Federation des de 06-02 i no necessita ni ha creat mai una clau JSON. Una clau nova en producció, un dissabte a les 23:48, és gairebé amb certesa persistència d'un atacant. I el nom sa-mantenimiento és exactament el tipus de nom plausible que es tria per passar desapercebut en una llista.

Pas 5 — Contenció, en aquest ordre.

L'ordre importa: primer la credencial (pas 1), perquè mentre existeixi l'atacant continua a dins; després el compte; després els permisos. I el pas 7 no s'omet mai: qui estableix persistència poques vegades ho fa en un sol lloc.

Quins controls de govern ho haurien detectat o impedit.

I la conclusió que dona sentit a la lliçó sencera: de les set mesures, la primera hauria impedit l'atac per complet i la segona l'hauria detectat en segons. Totes dues són d'aquesta lliçó, totes dues costen menys d'una hora de configuració, i cap no estava posada el dissabte a la nit.

Un control preventiu que costa una hora val més que la investigació més brillant.

Solució 3 — Justificar el govern davant de direcció

Per què dediquem quatre dies a posar regles al núvol Marta Ruiz, responsable d'infraestructura

És veritat que el sistema funciona i que no hem tingut cap incident greu. També és veritat que funciona perquè les tres persones de l'equip ens recordem de fer les coses bé, no perquè res ho impedeixi. Avui, qualsevol de nosaltres —o qualsevol que entri a treballar el mes que ve— pot, sense voler i sense que salti cap alarma, deixar un magatzem de dades obert a internet, crear una contrasenya permanent que ningú no sàpiga que existeix, o posar dades de clients en un servidor fora d'Europa.

No és una hipòtesi. Aquest any hem tingut dos casos. Vam trobar una contrasenya d'accés a dades que portava catorze mesos perduda i continuava funcionant. I vam descobrir dos serveis encesos que ningú no feia servir i que ens havien costat 1.500 €. Tots dos es van resoldre, però tots dos els vam trobar per casualitat, mesos després.

Què cobreix cada bloc de feina:

Regles automàtiques (dia 1). Impedeixen tècnicament el que avui només evitem per costum: res de servidors exposats a internet, res de dades fora de la UE, i —la més important— ningú no pot crear contrasenyes permanents. Sense això, el cas de la contrasenya perduda es pot repetir demà.

Registre protegit (dia 2). Desem en un lloc a part, i amb un cadenat que ni jo puc obrir, el registre de tot el que es fa a la plataforma. Serveix per a tres coses: si passa alguna cosa, sabem exactament què i qui; si un client o l'Agència de Protecció de Dades ens ho demana, ho podem demostrar; i com que ni tan sols l'administrador ho pot modificar, val com a prova. Un registre que jo pogués esborrar no serviria de res.

Avisos en el moment (dia 3). Avui, si algú es concedeix permisos d'administrador un dissabte a la nit, ens n'assabentaríem a la revisió del mes següent. Amb això ens n'assabentem en segons.

Inventari i revisions (dia 4). Saber en tot moment què existeix, qui té accés a què, i què està costant diners sense donar servei.

Per què ara i no més endavant. És una qüestió d'aritmètica, i és l'argument més important d'aquesta nota. Avui tenim cinc projectes i uns cent vint recursos: posar les regles afecta zero coses existents, perquè ja ho fem tot bé. D'aquí a dos anys, amb quinze projectes i sis-cents recursos, posar aquestes mateixes regles significarà trobar tot el que no les compleix, parlar amb cada equip i acceptar excepcions permanents que deixarien les regles gairebé buides. Quatre dies ara són quatre setmanes d'aquí a dos anys, i probablement ja no es faci.

I hi ha un motiu comercial que també convé tenir present: quan un client gran ens demani un qüestionari de seguretat —i ens el demanaran— la diferència entre respondre «sí, i aquí teniu el registre dels últims divuit mesos» i respondre «confiem en el nostre equip» pot ser la diferència entre signar el contracte o no.

El que demano a més del temps:

1. Que una segona persona tingui les claus mestres. Avui soc l'única que pot aixecar aquestes regles. Si m'equivoco o no soc disponible, l'equip es queda bloquejat.
2. Mitja hora al trimestre per revisar junts qui té accés a què. És ràpid i evita que els permisos s'acumulin sols, que és el que sempre acaba passant.
3. Acceptar que durant dues setmanes anirem una mica més a poc a poc, mentre mesurem l'impacte de les regles abans d'activar-les. No encendrem res sense haver-ho provat primer: bloquejar l'equip per pressa seria el pitjor resultat possible.

Les quatre decisions de comunicació:

1. Reconèixer que tenen raó abans de rebatre. «És veritat que funciona» desarma l'objecció en lloc d'enfrontar-s'hi. El que es corregeix és el perquè funciona, no el fet.
2. Dos incidents reals en lloc de riscos hipotètics. «Podria passar» es descarta; «ens va passar al març i ho vam trobar al juliol» no. I tots dos casos es van resoldre, cosa que permet explicar-los sense semblar alarmista ni incompetent.
3. L'argument aritmètic com a eix. Quatre dies ara davant de quatre setmanes d'aquí a dos anys és un raonament que un director financer entén immediatament i amb el qual no es pot discutir, perquè no depèn de valorar el risc: depèn de comptar.
4. L'angle comercial al final. Converteix el govern de cost en habilitador d'ingressos. És l'argument que més pes té en un consell i per això va després dels altres, no abans: posat primer semblaria una excusa; posat al final, remata.

I una cinquena, que es veu a les peticions: es demana explícitament anar més a poc a poc dues setmanes. Anunciar el cost abans que es noti evita que la primera fricció s'interpreti com un error de planificació.

El mòdul 7 acaba on havia d'acabar: convertint en controls el que fins ara eren acords.

Saps què és el govern i respons a les seves quatre preguntes amb mecanismes concrets: què es pot crear (polítiques d'organització), què existeix (Asset Inventory), qui va fer què (Audit Logs) i qui paga (estructura i etiquetes). I tens l'argument que decideix quan implantar-lo: el cost no creix amb els recursos, creix amb les excepcions que cal negociar. Les polítiques es posen quan no molesten ningú; després ja no es posen.

Saps estructurar una organització amb els tres criteris —entorn, equip, aplicació— i, més important, amb les seves conseqüències en permisos, polítiques heretades, facturació, quotes i radi d'explosió. Entens per què AlpinaShop estructura per entorn i per què AlpinaTech, amb clients externs, ho ha de fer per client.

Domines les polítiques d'organització: què les distingeix d'IAM —no són permisos, i no se les salta ni un owner—, els seus tres tipus, i l'herència amb la seva regla clau: una denegació en qualsevol nivell guanya sempre. Tens les nou polítiques d'AlpinaShop amb el seu motiu, el seu nivell i el seu risc, incloses les dues que tanquen deutes crítics de 07-04.

Saps aplicar-les sense bloquejar l'equip: el patró dry-run per quarta vegada al curs, el procediment de vuit passos que comença per inventariar el que ja incompleix, les cinc maneres reals de bloquejar-se a un mateix, i la salvaguarda que cal preparar abans de tot: dues persones amb orgpolicy.policyAdmin.

Saps escriure restriccions personalitzades amb CEL i distingir-les de Policy Controller, que actua sobre Kubernetes i no competeix sinó que complementa. I saps que les quotes impedeixen on els pressupostos només avisen.

Manegues Cloud Asset Inventory per saber què existeix, buscar recursos i polítiques IAM, exportar a BigQuery i construir l'històric que respon «què hi havia el 3 de juny?». I muntes feeds que avisen en segons d'una concessió d'owner, un bucket públic o —el més important— la creació d'una clau de compte de servei.

Coneixes els Cloud Audit Logs de debò: els quatre tipus, amb les dues dades que cal retenir —l'activitat d'administrador és gratis i no es pot desactivar; l'accés a dades està apagat per defecte i sense ell no es pot acotar una bretxa— i les tres decisions que fan el seu cost assumible. Saps llegir una entrada camp a camp, inclòs serviceAccountDelegationInfo, que gairebé ningú no mira i sense el qual es perd el rastre de la persona darrere d'una impersonació.

Tens les cinc consultes d'auditoria desades abans de necessitar-les, amb la de «qui va tocar un registre» assenyalada com la més important i la menys freqüent, i amb les denegacions de política usades com a termòmetre de si les teves regles estan ben calibrades.

I has muntat la peça que fa creïble tota la resta: retenció immutable en un projecte separat, amb abocador agregat a nivell d'organització i --include-children perquè cap projecte futur no quedi fora, amb logging.bucketWriter concedit a la writerIdentity —el pas que s'oblida sempre—, i amb --locked irreversible. On la Marta, que administra tota la plataforma, només pot llegir. Perquè un registre que l'administrador pot esborrar no serveix com a evidència.

Saps què és una zona d'aterratge i —el que importa— per què l'ordre és el que és: l'auditoria abans que la xarxa i les càrregues, per no perdre els registres del període amb més canvis de tota la vida de la plataforma. Amb els depends_on explícits de Terraform com a cas legítim, i amb els blueprints de Google com a referència i no com a plantilla.

I tens els processos de gestió del canvi dimensionats per a tres persones: revisions amb la seva periodicitat i el seu script, cicle de vida de projectes amb data de caducitat obligatòria als de prova, i un procés d'excepcions on la data de caducitat és l'única cosa que separa una excepció d'una derogació permanent.

I aquí acaba el mòdul 7. Mira on és AlpinaShop.

Va començar aquest mòdul amb una aplicació que es construïa, es desplegava i s'observava sola, i amb una llista de converses ajornades. Avui la llista és buida. DA-004 va decidir no adoptar la plataforma híbrida i connectar Sabadell amb un túnel, amb les seves condicions de revisió escrites. DA-001, promesa al mòdul 2 i arrossegada durant cinc, està complerta: el catàleg corre a Cloud Run, el MIG està apagat, i no queda ni una sola màquina virtual a la ruta de servei. La xarxa és una VPC compartida amb permisos per subxarxa, connectivitat híbrida real i un perímetre que impedeix que les dades surtin. La seguretat s'ha revisat sencera capa per capa, amb una llista de comprovació de 43 controls i un deute prioritzat del qual ja està pagada la part crítica. La factura ha baixat un 60 % i —més important— s'entén, s'atribueix i se segueix per cost unitari. La fiabilitat té números: quatre SLI, quatre SLO, pressupost d'error amb política, pla de recuperació amb RTO i RPO, i una restauració provada que va trobar cinc problemes que ningú no sospitava. I el govern converteix tot això en controls que no depenen que ningú se'n recordi.

Queda deute, escrit i prioritzat. I queda una llista de coses que AlpinaShop ha decidit no fer, amb el seu motiu — que és el que de debò distingeix una organització madura d'una que simplement no hi va arribar.

Has recorregut set mòduls seguint la Marta, en Dani i la Lucía. Has vist crear un compte i una jerarquia, migrar una aplicació, triar entre cinc serveis de còmput, muntar xarxes, identitats i secrets, construir una plataforma de dades, entrenar i servir models, automatitzar el lliurament, observar el sistema, resoldre un incident d'extrem a extrem, escriure la infraestructura com a codi, i ara assegurar-la, mesurar-la, abaratir-la i governar-la. Has vist prendre decisions i també desfer-les: App Engine es va descartar, GKE es va retirar, Anthos es va rebutjar, un endpoint es va apagar. Has vist quatre decisions d'arquitectura documentades, revisades i —algunes— complertes anys després d'escriure's.

El que encara no has fet és decidir tu.

El mòdul 8 és el teu projecte. Ja no hi ha una AlpinaShop a qui seguir: hi ha una empresa, un problema i un conjunt de restriccions que hauràs de resoldre de principi a fi. Recolliràs requisits i els traduiràs a decisions (08-01), dissenyaràs l'arquitectura completa justificant cada elecció igual que es va justificar DA-001 (08-02), la implementaràs amb infraestructura com a codi i lliurament continu (08-03), la provaràs i la desplegaràs amb canari, SLO i pla de recuperació (08-04), i la presentaràs i defensaràs davant de qui et pregunti per què vas triar el que vas triar (08-05). I acabaràs mirant endavant, cap a les certificacions de Google Cloud i cap al que ve després d'aquest curs (08-06).

Tot el que necessites és als set mòduls que acabes de recórrer. Ara et toca a tu.