La seguretat d'AlpinaShop s'ha construït a trossos. A 03-01 es va tancar el tallafoc. A 03-04 es va dissenyar IAM amb grups, rols personalitzats i comptes de servei sense claus. A 03-05 es va posar Cloud Armor al davant. A 03-06 van arribar Secret Manager i les claus gestionades pel client. A 03-07 es va publicar amb TLS. A 06-02 es va protegir la branca principal. A 07-03 es va aixecar un perímetre al voltant de les dades.

Cada peça es va decidir bé en el seu moment. I ningú no ha mirat mai el conjunt.

Aquesta és la diferència entre tenir controls de seguretat i tenir seguretat. Un atacant no ataca el tallafoc: ataca el baula més feble d'una cadena que tu no has recorregut mai sencera. I en una empresa de quaranta persones amb tres persones tècniques, aquesta baula gairebé mai no és la que un s'imagina — no és una vulnerabilitat exòtica al nucli, és una clau JSON de fa dos anys que continua al portàtil d'un becari que ja no hi treballa.

Aquesta lliçó és la revisió completa. Recorre l'arquitectura capa per capa, aplica els principis que fan que les capes se sostinguin, revisa la cadena de subministrament del programari —que és avui el vector d'atac que més creix—, tanca el cicle de les dades, munta detecció i resposta, aclareix quina part del compliment normatiu és de Google i quina és teva, i acaba amb dues coses que no solen aparèixer als cursos: una llista de comprovació d'enduriment que es pot executar, i la llista honesta del deute de seguretat que AlpinaShop encara té, prioritzada.

Avís, i va de debò. Aquesta lliçó és formació, no una auditoria. El model que es presenta és sòlid i aplicable, però qualsevol arquitectura que tracti dades personals, de pagament o de salut ha de ser revisada per un professional de seguretat i de compliment normatiu abans d'anar a producció, i amb la periodicitat que exigeixi el sector. Cap curs, cap llista de comprovació i cap eina automàtica no substitueix aquesta feina.

1. Defensa en profunditat aplicada a AlpinaShop
2. Els sis principis que sostenen tota la resta
3. Confiança zero i BeyondCorp, amb IAP com a implementació pràctica
4. Identitat: revisió completa del disseny IAM
5. Elevació temporal de privilegis i federació
6. Cadena de subministrament del programari
7. Dades: classificació, xifratge, pseudonimització i esborrat
8. Detecció: Security Command Center i els registres d'auditoria
9. Resposta: les dues primeres hores d'un incident
10. Compliment: què aporta Google i què continua sent teu
11. Llista de comprovació d'enduriment
12. El deute de seguretat d'AlpinaShop, prioritzat

Defensa en profunditat vol dir que cap control no és l'únic. Si un falla, un altre al darrere limita el dany. No és acumular eines: és dissenyar de manera que la fallada de qualsevol capa no sigui catastròfica.

La manera de comprovar si la defensa en profunditat és real és fer-se la pregunta de la fallada única a cada capa:

Les files amb resposta dubtosa són deute, i van a l'apartat 12. Aquesta és la utilitat real de l'exercici: no confirmar el que està bé, sinó trobar el que no.

Les eines canvien; els principis no. Aquests sis expliquen per què cada decisió del curs va ser la correcta.

Cada identitat té exactament els permisos que necessita per a la seva funció, i ni un més.

L'aplicació honesta fa una mica de mal: vol dir que quan algú demana «dona'm Editor per provar una cosa», la resposta és no i cal dedicar quinze minuts a esbrinar quin permís necessita de debò. La drecera de dir que sí és el que ha omplert el món de projectes on tothom és editor.

L'eina que ho fa suportable és el Recommender d'IAM (03-04), que compara permisos concedits amb permisos usats en 90 dies:

Qui construeix no desplega tot sol; qui desplega no aprova tot sol; qui administra no audita.

A AlpinaShop: Dani escriu el codi, Cloud Build el construeix, Marta aprova producció, i els registres d'auditoria els custodia un projecte on cap dels dos no pot escriure (07-07). Cap persona no pot, tota sola, posar codi en producció i esborrar l'evidència.

El que no està explícitament permès, està prohibit.

S'ha aplicat sistemàticament: el tallafoc de 03-01 amb denegació implícita; Cloud Run amb --no-allow-unauthenticated; l'ingress restringit al balancejador; el perímetre de VPC-SC; les polítiques d'organització de 07-07. L'alternativa —permetre per defecte i bloquejar el dolent conegut— és una cursa que es perd sempre.

Quan alguna cosa es comprometi —no si—, fins on arriba?

És el principi que justifica separar en projectes, donar comptes de servei diferents a cada càrrega, i no reutilitzar credencials. La pregunta operativa: si aquesta credencial es filtra avui, què pot fer qui la tingui? Si la resposta és llarga, el disseny està malament.

Ser dins de la VPC no és una credencial.

El model clàssic —perímetre dur, interior tou— falla perquè així que algú entra, ho té tot. Es desenvolupa a l'apartat 3.

Dissenya com si ja fossin a dins.

Canvia les prioritats: s'inverteix tant a detectar i limitar com a prevenir. És el que justifica els registres d'auditoria immutables, les alertes de comportament anòmal i l'assaig de la resposta a incidents.

BeyondCorp és el model de seguretat que Google va adoptar internament després de l'atac conegut com a Operació Aurora el 2009, i que va donar origen al terme confiança zero.

A Google Cloud, la implementació pràctica és IAP (Identity-Aware Proxy), que ja es va usar a 03-04 i que aquí convé mirar com a peça d'arquitectura.

El que fa IAP, i pel que val la pena:

• L'aplicació no veu mai trànsit no autenticat. El rebuig passa a la vora de Google.
• No hi ha VPN per mantenir, ni concentrador que cau, ni client per instal·lar.
• Funciona igual des de l'oficina i des de casa, cosa que elimina l'incentiu de saltar-se el control.
• Es combina amb nivells d'accés per context: dispositiu corporatiu verificat, disc xifrat, pantalla bloquejada, país permès.

I el seu límit honest: IAP protegeix l'accés a aplicacions HTTP i a SSH/RDP per túnel. No és un substitut de la segmentació de xarxa ni d'IAM: és una capa més.

Aplicat a AlpinaShop, resol el problema de l'exercici de 07-03 —Lucía treballant des de casa— millor que cap llista d'IP:

Es llegeix així: pot entrar qui faci servir un equip propietat de l'empresa, xifrat, amb bloqueig de pantalla, amb sistema operatiu actualitzat, des d'Espanya, França o Portugal. La IP ha deixat d'importar, que és exactament el punt.

La identitat és el nou perímetre. En un núvol ben muntat, la immensa majoria dels incidents greus comencen per una credencial, no per un port obert.

Owner, Editor i Viewer existeixen des d'abans que IAM tingués rols granulars i no s'haurien d'usar mai en producció:

Auditoria immediata:

El que cal trobar i per què:

El compte per defecte de Compute mereix un paràgraf propi perquè és, amb diferència, la fallada més estesa de Google Cloud. Existeix a tots els projectes, històricament venia amb Editor, i qualsevol VM, funció o servei que no especifiqui un altre compte l'hereta. Una vulnerabilitat a la teva aplicació web passa de «llegir una base de dades» a «administrar el projecte sencer». La política d'organització automaticIamGrantsForDefaultServiceAccounts (07-07) ho evita en projectes nous; en els existents cal arreglar-ho a mà.

Ningú no és Owner de producció. És la decisió de 03-04 que més discussió genera i la que més valor té: si ningú no pot saltar-se els controls, els controls són reals. Per a les emergències existeix el procediment d'accés de trencament de vidre de l'apartat 5, que és auditat i temporal.

La regla, ja establerta a 03-04 i que aquí es tanca:

Una clau JSON de compte de servei descarregada és una contrasenya permanent sense caducitat que qualsevol pot copiar.

Alternatives, per ordre de preferència:

Cerca de claus existents a tota l'organització:

--managed-by=user és la clau de la comanda: filtra les claus descarregables i descarta les que gestiona Google internament, que són inofensives i omplirien la sortida de soroll.

Marta necessita compute.securityAdmin per tocar el tallafoc. L'usa un cop al mes. La resta del temps, aquest permís només aporta risc: si li roben la sessió un dimarts qualsevol, l'atacant pot obrir el tallafoc.

Privileged Access Manager (PAM) ho resol amb permisos que es demanen, es justifiquen, s'aproven i caduquen sols.

El que canvia:

I el matís important per a una pime: si l'aprovador és l'única persona que pot aprovar i és de vacances, el procés bloqueja una emergència. Hi ha d'haver un camí de trencament de vidre: un dret amb aprovació automàtica, durada d'una hora, i alerta immediata al canal de seguretat quan s'usa. No s'impedeix; es fa sorollós. És la mateixa filosofia que el procediment d'emergència de Terraform a 06-07: quan no hi pot haver control preventiu, hi ha d'haver control detectiu.

Workload Identity Federation permet que una identitat externa —GitHub Actions, un clúster d'un altre núvol, un proveïdor OIDC— obtingui credencials de curta durada de Google Cloud sense cap clau. AlpinaShop ja ho fa servir des de 06-02.

El punt de seguretat que gairebé tothom configura malament és la condició d'atributs:

Aquesta condició sembla restrictiva i no ho és tant: si algú crea una organització de GitHub anomenada alpinashop, entra. I encara que no fos així, qualsevol branca o pull request del repositori podria desplegar en producció.

repository_id és numèric i immutable: no es pot suplantar canviant el nom. Aquest és el detall que separa una federació segura d'una que només ho sembla.

És el vector que més ha crescut els darrers anys, i el que menys atenció rep a les pimes. No cal atacar la teva aplicació si es pot atacar una biblioteca que la teva aplicació instal·la.

I el pas que converteix l'escaneig en un control: fer fallar la compilació si hi ha vulnerabilitats crítiques amb pedaç disponible.

El matís de fixedVersion no és un tecnicisme: bloquejar per vulnerabilitats sense pedaç disponible paralitza el desenvolupament sense millorar la seguretat, perquè no hi ha res a fer llevat de canviar de dependència. Es bloqueja el que es pot arreglar; la resta es registra, se'n valora el risc i es decideix.

Sense shell, un atacant que aconsegueixi execució de codi no pot llançar sh, ni curl, ni wget. No és invulnerable, però la majoria de les eines de post-explotació deixen de funcionar.

I la reproduïbilitat, que és el que fa verificable tot l'anterior:

Les tres línies que importen: digest en lloc d'etiqueta, --require-hashes perquè una dependència manipulada faci fallar la instal·lació, i USER 1000 per no executar com a root.

SLSA (Supply-chain Levels for Software Artifacts) és un marc amb nivells de garantia sobre com es va construir un artefacte. Cloud Build genera procedència verificable de manera nativa:

La procedència respon amb signatura criptogràfica a: quin commit exacte, quines instruccions de compilació, quina màquina, quin moment. Serveix per al que en un incident és una pregunta d'hores: aquesta imatge que està corrent en producció es va construir des del nostre codi, o algú la va publicar a mà?

Ja es va presentar a 07-01. Aquí és on encaixa: és el control que impedeix que arribi a producció una imatge que no va passar pel procés.

I aplica a Cloud Run, no només a GKE, cosa que el fa directament rellevant per a AlpinaShop després de 07-02:

Assured Open Source Software és un servei pel qual Google distribueix paquets de codi obert que ell mateix fa servir: els compila a la seva infraestructura, els escaneja, els signa i els dona procedència SLSA.

El seu valor és acotat i convé dir-ho: cobreix un catàleg de paquets populars de Java i Python, no tot el que instal·les. Per a AlpinaShop, amb una desena de dependències comunes, la majoria estarien cobertes. No és una bala de plata; és reduir la superfície on has de confiar cegament.

No es pot protegir el que no se sap què és. La classificació de les dades d'AlpinaShop:

La quarta fila és la millor decisió de seguretat de tot el curs, i no és tècnica: la dada que no guardes no es pot filtrar. AlpinaShop no emmagatzema números de targeta perquè la passarel·la retorna un testimoni. Això elimina de cop l'abast complet de PCI-DSS sobre la seva infraestructura.

A 04-07 es va presentar DLP —avui Sensitive Data Protection— per al govern de la dada. Aquí es fa servir com a control de seguretat: trobar dades personals on no haurien de ser.

Dues decisions del fitxer:

• includeQuote: false: no desar el fragment trobat. Desar el número de targeta detectat a la taula de troballes seria crear una segona còpia del problema. Un error real i freqüent.
• SPAIN_DNI_NUMBER: existeixen detectors específics per país. Fer servir només els genèrics deixa fora el més rellevant a Espanya.

El que es troba sempre, i AlpinaShop no en va ser excepció: correus electrònics en camps de text lliure de comentaris, telèfons al camp «observacions de la comanda», i adreces completes en registres d'aplicació de fa mesos. Cap no era intencionat. Els tres són dades personals a efectes del RGPD.

Google xifra tot en repòs per defecte, sense configurar res. CMEK (03-06) hi afegeix que la clau la controles tu a Cloud KMS:

El «botó vermell» que dona CMEK. Si es detecta una intrusió en curs, deshabilitar la clau fa il·legibles les dades xifrades amb ella en segons, fins i tot per a qui tingui permisos de lectura. És una capacitat de contenció que sense CMEK no existeix.

Amb la seva contrapartida, que cal dir clarament: si perds la clau, perds les dades. Definitivament. Per això KMS impedeix l'esborrat immediat i imposa un període de destrucció programada.

Perquè Lucía analitzi comportament de compra no necessita saber qui és cada client:

Tres tècniques en cinc línies: hash amb sal perquè el mateix client sigui el mateix client_id sense poder revertir-ho; generalització del codi postal als dos primers dígits, que dona la província sense assenyalar el barri; i omissió de nom, adreça i telèfon, que no aporten res a l'anàlisi.

I l'advertiment honest: la pseudonimització no és anonimització. Amb la sal, la dada continua sent reidentificable i per tant continua sent una dada personal a efectes del RGPD. Redueix el risc; no elimina l'obligació.

El RGPD obliga a no conservar dades personals més temps del necessari, i a poder esborrar-les a petició de l'interessat.

I l'esborrat a petició, que és on la majoria d'empreses descobreix que la seva arquitectura no ho contemplava:

Fixa't en el punt 1: les comandes no s'esborren, s'anonimitzen, perquè la normativa fiscal obliga a conservar les factures. El dret de supressió no és absolut i col·lideix amb altres obligacions legals; resoldre aquesta col·lisió no és una decisió tècnica i s'ha de documentar amb assessorament jurídic.

SCC és el centre de seguretat de Google Cloud. Detecta configuracions insegures, vulnerabilitats i amenaces actives.

Què detecta de debò el nivell gratuït, que és el que farà servir una pime:

Amb Premium s'hi afegeix Event Threat Detection, que analitza els registres en temps real buscant comportament —no configuració—: mineria de criptomonedes en una VM, exfiltració de dades de BigQuery, ús de credencials des d'una geografia impossible, creació d'un compte de servei seguida immediatament d'una concessió de permisos.

El criteri honest per a AlpinaShop: començar amb el nivell gratuït i atendre de debò les seves troballes, que ja és més del que fa la majoria. Premium es justifica quan hi ha alguna cosa a vigilar activament, un requisit de compliment normatiu que ho exigeixi, o algú amb temps per respondre al que detecti. Comprar detecció que ningú no mira és pitjor que no comprar-la, perquè genera la sensació d'estar protegit.

Es desenvolupen a fons a 07-07. Aquí, el mínim indispensable:

Que «accés a dades» estigui desactivat per defecte té una conseqüència que cal assumir conscientment: sense activar-ho, no pots saber qui va llegir les dades dels teus clients. Per a AlpinaShop, activar-ho a alpinashop-datos i als buckets amb dades personals no és opcional si vol respondre a una bretxa.

Tres consultes que cal tenir escrites abans de necessitar-les:

La tercera mereix una alerta permanent: en una organització que federa identitats i fa servir impersonació, crear una clau JSON és un esdeveniment excepcional que sempre s'ha de mirar.

Aquí hi ha el que gairebé cap curs inclou i el que de debò marca la diferència. Un guió realista per a un equip de tres persones.

Escenari: són les 23:40 d'un dijous d'octubre, en plena campanya. Arriba una alerta d'SCC: «Anomalous IAM grant: el compte sa-informes-nocturnos ha concedit roles/owner a un compte extern».

No es toca res encara. El primer impuls —esborrar el compte, tallar accessos— destrueix evidència i de vegades avisa l'atacant. El primer és respondre tres preguntes:

1. És real o un fals positiu? Hi ha un canvi programat aquesta nit? Hi ha algú treballant?
2. Està en curs? Continua havent-hi activitat d'aquesta identitat ara mateix?
3. Quin abast té? Què pot tocar aquesta credencial?

Si és real, tallar sense destruir. L'ordre importa:

El pas 3 és el que s'oblida sempre. Deshabilitar un compte no invalida els testimonis d'accés ja emesos, que viuen fins a una hora. Durant aquesta hora, l'atacant continua a dins encara que el tauler digui que el compte està deshabilitat.

Les preguntes, en aquest ordre:

La cerca de persistència és la part que més es descuida i la que fa que un incident es repeteixi la setmana següent:

Les 72 hores del RGPD per notificar l'autoritat de control no són negociables i el rellotge comença quan en tens coneixement, no quan acabes la investigació. És la raó número u per la qual cal trucar a l'assessor jurídic la primera hora, encara que encara no se'n conegui l'abast.

Un incident no és moment d'improvisar. La carpeta que cal tenir escrita avui:

• Telèfons: intern, direcció, assessor jurídic, asseguradora, suport de Google Cloud.
• La comanda de contenció ja escrita, provada i amb permisos verificats.
• Un bucket d'evidència amb retenció bloquejada i creat fora del projecte que pot estar compromès.
• Un canal de comunicació alternatiu — si el correu corporatiu està compromès, no et pots coordinar per correu.
• L'accés d'emergència provat: que Marta pugui entrar encara que el seu compte habitual estigui bloquejat.
• Un simulacre a l'any. Mitja hora en una sala, sobre un escenari escrit. Descobreix més forats que qualsevol auditoria de configuració.

El repartiment de 01-05, revisat ara amb tot el context:

Les certificacions de Google —ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3, PCI-DSS com a proveïdor, ENS a Espanya, esquemes sectorials— acrediten la seva infraestructura. Es descarreguen del Compliance Reports Manager.

I aquí hi ha el malentès més car del compliment normatiu al núvol:

Que Google estigui certificat en ISO 27001 no certifica la teva empresa. Que la seva infraestructura sigui apta per a PCI-DSS no fa conforme la teva botiga. El que et donen és que la capa de sota ja està auditada, cosa que redueix molt el teu abast — però la teva configuració, el teu codi, els teus processos i les teves persones continuen sent teus i continuen sent auditables.

Per a AlpinaShop, com a botiga en línia espanyola:

La documentació que cal tenir, i que en una inspecció es demana abans que cap configuració tècnica:

1. Registre d'activitats de tractament (art. 30 RGPD).
2. Contracte d'encarregat del tractament amb Google Cloud.
3. Avaluació d'impacte (AIPD) si hi ha tractament d'alt risc.
4. Política de seguretat de la informació, encara que siguin quatre pàgines.
5. Procediment de resposta a bretxes, amb els terminis de l'apartat 9.
6. Registre d'accessos a dades personals — que és just el que donen els registres d'accés a dades.
7. Anàlisi de transferències internacionals i garanties aplicades.

Es repeteix perquè importa: aquesta taula és orientativa i docent. Un professional de compliment normatiu ha de validar què s'aplica al teu cas concret, especialment pel que fa al RGPD, a les transferències internacionals i a l'abast de PCI-DSS.

Accionable sobre tot el que s'ha construït al curs. La columna d'estat és la d'AlpinaShop avui.

Resultat: 20 ✅, 11 ⚠️, 12 ❌. No està malament per a una empresa de quaranta persones. I no és suficient.

Cap empresa no està al 100 %. El que distingeix una organització madura no és no tenir deute, sinó saber quin té, haver-lo prioritzat i estar-lo pagant. Priorització per risc (probabilitat × impacte) davant d'esforç.

Els quatre sumen menys de dos dies de feina i són el que més redueix el risc. Començar per aquí no és opinable.

I això també forma part de la maduresa: decidir no fer una cosa, per escrit, amb motiu.

Un risc acceptat i documentat no és una fallada de seguretat: és una decisió de gestió. Un risc que ningú no ha mirat, sí.

• Confondre tenir eines amb tenir seguretat. SCC activat i ningú mirant les troballes és pitjor que no tenir-lo: genera falsa confiança.
• Deixar el compte per defecte de Compute amb Editor. És la fallada més estesa de Google Cloud i converteix qualsevol vulnerabilitat en un compromís total del projecte.
• Crear claus JSON «per provar». No s'esborren mai. Busca-les periòdicament amb --managed-by=user.
• Federar identitat sense condició d'atributs estricta. Sense repository_id i ref, qualsevol branca o repositori amb el mateix nom d'organització pot desplegar en producció.
• Esborrar el compte compromès durant un incident. Destrueix evidència. Es deshabilita.
• Oblidar que els testimonis vius sobreviuen a la deshabilitació fins a una hora.
• Desar el fragment detectat per DLP. Crear una taula amb els números de targeta trobats és duplicar el problema, no resoldre'l.
• Creure que la pseudonimització és anonimització. Amb la sal, continua sent dada personal a efectes del RGPD.
• Pensar que les certificacions de Google certifiquen la teva empresa. Certifiquen la capa de sota. La teva configuració és teva.
• Bloquejar compilacions per vulnerabilitats sense pedaç disponible. Paralitza l'equip sense millorar res. Es bloqueja el que es pot arreglar.
• Activar tots els controls alhora. VPC-SC, Binary Authorization i polítiques d'organització el mateix dia és garantia de caiguda. Un cada vegada, en mode de prova primer.
• Deixar el pla de resposta per quan calgui. L'incident és el pitjor moment per escriure'l.
• Consell: fes la pregunta de la fallada única a cada capa. És mitja hora i troba més que qualsevol escàner.
• Consell: la millor mesura de seguretat és la dada que no guardes. Abans de protegir una dada, pregunta si cal emmagatzemar-la.
• Consell: un simulacre de mitja hora a l'any descobreix més forats reals que una auditoria de configuració.
• Consell: escriu el deute acceptat. Converteix un forat en una decisió, i fa que es revisi.

Escriu un script d'auditoria que, sobre els cinc projectes d'AlpinaShop, detecti i informi de:

1. Qualsevol vincle amb rols bàsics (owner, editor, viewer).
2. Vincles amb allUsers o allAuthenticatedUsers en projectes i en buckets.
3. Comptes de servei amb claus gestionades per l'usuari, amb la seva antiguitat.
4. Comptes de servei que no s'han fet servir en 90 dies.
5. Comptes de servei amb rols d'administrador.

Per a cada troballa, indica gravetat i acció recomanada. Explica a més per què el punt 4 és més important del que sembla.

Escenari. Un dilluns al matí, un desenvolupador extern publica en un fòrum públic que ha trobat un repositori de GitHub d'AlpinaShop amb un fitxer credenciales.json a l'historial de commits. El fitxer és una clau de sa-dataflow-pedidos, esborrada del repositori fa vuit mesos però present a l'historial. Aquest compte té roles/bigquery.dataViewer sobre alpinashop_analitica i roles/storage.objectAdmin sobre alpinashop-datalake.

Escriu el pla de resposta complet amb marques de temps: què es fa en els primers 10 minuts, en els primers 30, en la primera hora i en les primeres 24 hores. Inclou les comandes, les decisions de comunicació (amb qui i quan), com es determina si hi va haver accés indegut, i quins canvis estructurals es fan després perquè no torni a passar.

La direcció d'AlpinaShop aprova 10 dies de feina de Marta i 3.000 € per a seguretat aquest trimestre. No n'hi ha més.

De la llista de deute de l'apartat 12, tria què es fa i què no, justificant cada decisió amb criteri de risc davant d'esforç. Elabora un pla per setmanes i, el més important, escriu què li dius a direcció sobre el que queda sense fer, en llenguatge que un director general entengui.

Solució 1 — Auditoria d'identitat

Taula de troballes, gravetat i acció:

Per què el punt 4 és més important del que sembla. Un compte de servei sense ús és un objectiu silenciós: ningú no vigila la seva activitat, ningú no notaria un ús anòmal, i com que no s'utilitza, ningú no recorda per què existeix ni quins permisos té. A més d'eliminar superfície d'atac, la neteja aporta una cosa més valuosa: cada compte que s'elimina redueix el soroll de l'auditoria, i una llista de vint comptes dels quals se n'entenen vint és infinitament més segura que una de seixanta dels quals se n'entenen vint.

La tècnica correcta és deshabilitar abans d'esborrar (gcloud iam service-accounts disable): si alguna cosa es trenca, es reactiva en un segon; si s'ha esborrat, cal recrear-lo i reconstruir tots els seus permisos. Trenta dies d'espera és un termini raonable, perquè captura els processos mensuals.

Solució 2 — Dissenyar la resposta a un incident concret

T+0 a T+10 min — Valorar sense actuar.

La primera decisió: això ja és públic. A diferència d'una detecció interna, aquí l'atacant potencial no només existeix: hi ha un fòrum sencer que sap de la clau. La urgència és màxima i la discreció ja no aporta res, cosa que canvia el càlcul respecte de l'apartat 9.

Es busca una sola cosa: peticions des d'IP que no siguin les de Dataflow. Si apareixen, l'incident passa de «credencial exposada» a «accés confirmat», amb implicacions legals immediates.

T+10 a T+30 min — Contenir.

La decisió difícil d'aquests vint minuts: deshabilitar el compte trenca el pipeline de comandes cap a BigQuery. Es fa igualment. Davant d'una credencial pública amb accés al data lake, l'analítica pot esperar unes hores. I és exactament la decisió que cal haver pensat abans, no en calent.

El punt 4 mereix atenció: si el perímetre hagués estat aplicat en lloc d'en mode de prova (deute #7), la clau filtrada no hauria pogut treure ni un sol byte fora de l'organització. L'incident il·lustra per què un control a mitges no és mig control.

T+30 min a T+1 h — Determinar si hi va haver accés.

I aquí apareix el problema que converteix aquest exercici en la millor demostració de per què el deute #5 importa: els registres d'accés a dades estan desactivats. AlpinaShop té els registres d'activitat d'administrador —sabrà si algú va canviar permisos— però no pot saber si algú va llegir la taula de comandes.

Conseqüència pràctica, i és greu: en no poder demostrar que no hi va haver accés, jurídicament cal tractar el cas com si hagués pogut haver-n'hi. Es passa de «credencial exposada sense evidència d'ús» a «possible bretxa de dades personals amb un abast que no es pot acotar». Això canvia completament la notificació a l'AEPD.

Vies alternatives d'evidència, totes pitjors:

T+1 a T+2 h — Comunicar.

T+2 a T+24 h — Abast i erradicació.

T+24 a T+72 h — Notificació. Si l'assessor jurídic determina que hi ha risc per als drets dels interessats, notificació a l'AEPD dins de les 72 hores. En no poder descartar l'accés, el més probable és que calgui notificar. La notificació descriu: què va passar, quines dades podrien estar afectades, quines mesures s'han pres, i per què no es pot acotar l'abast — cosa que, dit amb claredat, és en si mateixa una troballa desfavorable sobre l'organització.

Canvis estructurals després:

La reflexió final de l'exercici. La clau es va pujar fa vuit mesos, es va esborrar del repositori, i tothom va pensar que el problema estava resolt. Esborrar un fitxer de Git no esborra el seu historial: qualsevol amb accés al repositori —o al repositori públic, o a un fork— podia recuperar-lo amb git log -p. És un malentès tan estès que mereix una regla:

Un secret que ha estat en un repositori, encara que sigui un minut, està compromès. L'única resposta correcta és rotar-lo. Esborrar-lo de l'historial és neteja, no remediació.

Solució 3 — Prioritzar amb pressupost limitat

Restriccions: 10 dies de Marta, 3.000 €, un trimestre. I una premissa que cal respectar: Marta també ha d'operar la plataforma, així que 10 dies de seguretat són 10 dies reals, no elàstics.

El que es fa:

Sobren 2.100 €. I aquí ve la proposta que dona més valor per euro:

Contractar una revisió externa de seguretat de mig dia (~1.500-2.000 €) al final del trimestre, sobre l'arquitectura ja endurida.

El raonament: Marta ha construït aquesta plataforma i té els punts cecs de qui la va construir. Una mirada externa sobre un sistema ja ordenat troba coses diferents de les que trobaria sobre un de desordenat — i per això es contracta després de pagar el deute de prioritat 1 i 2, no abans. A més aporta una cosa que a dins no es pot fabricar: un informe signat per un tercer, que és el que demana un client corporatiu, una asseguradora o una inspecció.

El que NO es fa, i per què:

El que se li diu a direcció — i aquesta és la part que més costa i més importa:

«Amb aquests deu dies tanquem els quatre forats que avui ens exposen més: una contrasenya permanent que vam perdre fa més d'un any i que continua funcionant, un compte intern que dona permís per esborrar qualsevol cosa, un sistema automàtic que ho pot tocar tot, i la manca d'avís quan algú canvia permisos.

A més fem dues coses que avui no tenim i que són obligació legal o de sentit comú: saber qui accedeix a les dades dels nostres clients —avui no podríem respondre aquesta pregunta davant de l'Agència de Protecció de Dades, i no poder respondre-la és en si mateix un problema— i comprovar que les nostres còpies de seguretat es poden restaurar de debò, cosa que no hem verificat mai. I assagem què faríem si demà passa alguna cosa, perquè el dia de l'incident és el pitjor dia per improvisar.

El que queda sense fer, i vull que consti per escrit: no tindrem vigilància activa d'amenaces —si algú entra sense fer soroll, ens n'assabentaríem tard—; no impedirem tècnicament que es desplegui programari no aprovat; els permisos administratius continuaran sent permanents en lloc de temporals; i no contractarem un atac simulat professional. Cadascuna d'aquestes quatre coses és una decisió de pressupost, no un descuit, i les revisem el trimestre que ve.

Amb el que fem passem d'un risc que jo qualificaria d'alt a un de mitjà. Arribar a baix requereix una persona dedicada a seguretat o un servei gestionat, i això és una conversa diferent que convé tenir quan siguem seixanta persones o quan un client gran ens ho exigeixi per contracte.»

Els tres elements que fan bona aquesta comunicació, i que es poden reutilitzar en qualsevol empresa: es parla de riscos de negoci i no de noms de productes; es diu explícitament el que queda sense cobrir en lloc de deixar que la direcció assumeixi que tot està resolt; i es fixa quan es revisa, cosa que converteix una retallada pressupostària en una decisió conscient amb data en lloc de en un silenci.

AlpinaShop ha passat de tenir controls de seguretat a tenir seguretat revisada, i —el que és més útil— a saber exactament què li falta.

Has aplicat defensa en profunditat capa per capa —vora, identitat, xarxa, càrrega de treball, dades, detecció— i sobretot has après la pregunta de la fallada única, que és l'eina més barata i més eficaç de tota la lliçó: per a cada capa, si això falla, què ho conté? Les respostes dubtoses són el deute.

Tens els sis principis que expliquen totes les decisions del curs: mínim privilegi amb el Recommender que el fa suportable, separació de funcions —Dani escriu, Cloud Build construeix, Marta aprova, i ningú no pot desplegar i esborrar l'evidència—, denegar per defecte, radi d'explosió limitat amb la seva pregunta operativa, no confiar en la xarxa, i assumir la bretxa.

Entens confiança zero i BeyondCorp amb IAP com a implementació pràctica, i has vist que un nivell d'accés basat en el dispositiu —corporatiu, xifrat, bloquejat, actualitzat, des d'una regió permesa— resol el teletreball molt millor que qualsevol llista d'IP, perquè fa que la IP deixi d'importar.

Has revisat la identitat a fons: eliminar els rols bàsics, l'script que els troba, i les tres troballes que apareixen sempre —una persona amb Owner, Cloud Build amb Editor i, sobretot, el compte per defecte de Compute amb Editor, que és la fallada més estesa de Google Cloud i la que converteix qualsevol vulnerabilitat d'aplicació en un compromís total. Coneixes les alternatives sense claus per a cada situació i la comanda amb --managed-by=user que troba les que queden. Saps muntar elevació temporal amb PAM —amb el camí de trencament de vidre que no impedeix sinó que fa soroll— i federació d'identitat amb la condició d'atributs per repository_id i ref que separa una federació segura d'una que només ho sembla.

Domines la cadena de subministrament: escaneig que bloqueja només el que té pedaç, imatges base mínimes —amb la taula que va de python:3.12 a distroless— fixades per digest i amb --require-hashes, USER 1000 en lloc de root, procedència SLSA que respon a «aquesta imatge va sortir del nostre codi?», Binary Authorization —que també aplica a Cloud Run— i Assured Open Source amb el seu abast honest.

Has tancat el cicle de les dades: classificació en quatre nivells amb la millor decisió de seguretat del curs —no emmagatzemar targetes, perquè la dada que no guardes no es filtra—, descobriment amb Sensitive Data Protection i detectors espanyols, includeQuote: false per no duplicar el problema, CMEK amb el seu «botó vermell» de deshabilitar la clau i la seva contrapartida irreversible, pseudonimització amb hash salat i generalització —que no és anonimització— i retenció amb el procediment de supressió que anonimitza les comandes en lloc d'esborrar-les perquè l'obligació fiscal mana.

Saps detectar: Security Command Center amb els seus tres nivells, el que el gratuït troba de debò, i el criteri honest que comprar detecció que ningú no mira és pitjor que no comprar-la. I tens els quatre tipus de registre d'auditoria amb la dada que ho canvia tot — accés a dades està desactivat per defecte, i sense això no pots saber qui va llegir les dades dels teus clients— juntament amb les tres consultes que cal tenir escrites abans de necessitar-les.

Tens un guió de resposta realista: deu minuts per valorar sense tocar res, vint per contenir sense destruir evidència —deshabilitar i no esborrar, i revocar els testimonis vius que sobreviuen una hora—, mitja hora per a l'abast incloent-hi la cerca de persistència, i la comunicació amb les 72 hores del RGPD comptant des del coneixement i no des de la conclusió. Amb la carpeta que cal preparar avui, inclòs el canal de comunicació alternatiu i el simulacre anual.

Saps quin compliment normatiu aporta Google i quin continua sent teu, amb el malentès més car aclarit: les seves certificacions acrediten la capa de sota, no la teva empresa. I tens la llista dels set documents que es demanen abans que cap configuració tècnica.

I t'endús dues coses que valen més que cap apartat teòric: la llista de comprovació de 43 controls amb l'estat real d'AlpinaShop —20 ✅, 11 ⚠️, 12 ❌— i el deute prioritzat en tres blocs, amb quatre tasques de prioritat 1 que sumen menys de dos dies i són el que més risc elimina. Més la llista de deute acceptat conscientment, perquè un risc documentat és una decisió de gestió i un risc que ningú no ha mirat és un forat.

L'exercici de la clau filtrada ha deixat la lliçó més incòmoda de totes, i convé endur-se-la literal: un secret que ha estat en un repositori, encara que sigui un minut, està compromès; esborrar-lo de l'historial és neteja, no remediació.

I l'exercici del pressupost ha deixat l'altra: la seguretat d'una pime no es decideix amb la llista del que és ideal, sinó triant deu dies ben gastats i dient a direcció, per escrit i en el seu idioma, el que queda sense cobrir.

Dos fils d'aquesta lliçó queden explícitament oberts. Un apunta a 07-06: la restauració de còpies no s'ha provat mai, i apareix com a risc crític tant a la llista de comprovació com a la priorització. L'altre apunta a 07-07: les polítiques d'organització, els registres d'auditoria immutables en un projecte separat i la revisió periòdica d'accessos són govern, i allà es resolen.

Però abans hi ha una conversa que porta set mòduls ajornant-se. Cada lliçó ha afegit serveis; cap no ha tancat la factura. Aquesta mateixa lliçó ha proposat activar els registres d'accés a dades —que costen—, ha descartat SCC Premium per preu, i ha repartit 3.000 € com si fossin molts diners, que per a una empresa de quaranta persones ho són. Cap d'aquestes tres decisions no es pot prendre bé sense entendre d'on surt cada euro de la factura d'AlpinaShop. La lliçó següent obre la factura sencera, línia a línia, i l'explica.