IAM protegeix el que té identitat. Però el visitant que recorre el catàleg d'AlpinaShop a mil peticions per segon per copiar els preus no té identitat. Tampoc no en té el que prova deu mil contrasenyes contra el formulari d'accés, ni el que escriu ' OR 1=1-- al cercador a veure què passa. Aquest trànsit arriba a alpinashop-lb-ip com qualsevol client legítim i, sense res al davant, acaba a les instàncies del MIG.

Cloud Armor és el tallafoc d'aplicació (WAF) i el sistema de protecció davant de denegació de servei de Google Cloud. Com Cloud CDN, no és un producte que es desplegui a part: és una política que s'adjunta al servei de backend del balancejador que vas construir a 03-02, i s'aplica a la vora de la xarxa de Google, als mateixos punts de presència on es fa el balanceig i la memòria cau. El trànsit maliciós es descarta a milers de quilòmetres d'europe-west1, sense consumir ni un sol cicle de les teves instàncies.

Aquesta lliçó té un cas concret: la campanya de tardor d'AlpinaShop. La Marta detecta dos problemes simultanis. Un competidor està rastrejant el catàleg sencer cada nit, cosa que dispara l'autoescalat del MIG i enfonsa la ràtio d'encerts del CDN. I el formulari d'accés rep intents de força bruta des de diversos centenars d'adreces. Construirem la política pol-catalogo-web que resol tots dos, i sobretot la desplegarem de la manera correcta, que consisteix a no bloquejar res fins a estar-ne segurs.

Avís important. Un WAF no substitueix el codi segur, i una política de seguretat mal calibrada bloqueja clients legítims, cosa que és un incident comercial tan real com el que intentaves evitar. Tot el que segueix és un model docent vàlid, però abans d'aplicar regles de bloqueig en un entorn de producció real, el disseny l'ha de revisar un professional de seguretat, i tota decisió de filtratge per geografia l'ha de validar a més el responsable legal i comercial.

1. Què és un WAF, què cobreix i què no
2. On actua Cloud Armor: el recorregut d'una petició
3. Polítiques, regles, prioritats i la regla per defecte
4. Regles per adreça IP
5. Regles per geografia i les seves implicacions
6. Regles preconfigurades de l'OWASP Top 10
7. Falsos positius: el problema real d'un WAF
8. El llenguatge d'expressions: regles a mida per a AlpinaShop
9. Mode de vista prèvia: l'única manera correcta de desplegar
10. Limitació de taxa i rate-based-ban
11. Protecció adaptativa davant de DDoS de capa 7
12. reCAPTCHA Enterprise per distingir persones de bots
13. Nivells Standard i Enterprise, i cost
14. La política completa de la campanya de tardor

Un tallafoc d'aplicació web inspecciona el contingut de les peticions HTTP —ruta, capçaleres, paràmetres, cos— i decideix si deixar-les passar. És diferent del tallafoc de VPC que vas configurar a 03-01: aquell treballa amb adreces IP i ports, i no té ni idea del que viatja a dins; aquest entén HTTP.

Què cobreix bé Cloud Armor:

• Atacs d'injecció als paràmetres: SQLi, XSS, inclusió de fitxers locals o remots, execució remota de comandes.
• Denegació de servei volumètrica (capes 3 i 4), de forma automàtica i sense configuració, pel simple fet de ser darrere del balancejador global.
• Denegació de servei d'aplicació (capa 7): rastreig massiu, força bruta, abús d'endpoints cars.
• Filtratge per origen: adreces, rangs, països, reputació de la IP.
• Bots bàsics i escàners automatitzats.

Què no cobreix, i és igual d'important saber-ho:

• Fallades de lògica de negoci. Si el teu endpoint permet demanar la comanda d'un altre client canviant un identificador a la URL, cada petició és perfectament legítima als ulls del WAF. Aquesta fallada s'arregla al codi.
• Credencials robades. Un inici de sessió amb la contrasenya correcta és un inici de sessió correcte.
• Vulnerabilitats a les teves dependències. Pot mitigar l'explotació d'algunes de conegudes, i guanya temps mentre apedaces, però no apedaça res.
• Errors de configuració de permisos. Això és IAM.
• Atacs des de dins o que no passin pel balancejador. Si una VM té IP pública i s'hi pot arribar directament, el WAF no se n'assabenta.

Un WAF és una capa de mitigació, no una absolució. És el que et dona marge per arreglar les coses, no el que les arregla.

Els quatre fets que importen d'aquest diagrama:

1. Cloud Armor s'avalua a la vora, al mateix punt de presència on entra el client. El paquet maliciós no creua mai fins a europe-west1.
2. S'avalua abans que la memòria cau. Una petició bloquejada no consulta la memòria cau ni consumeix emplenament; i a la inversa, activar el CDN no crea un camí pel qual el trànsit esquivi el WAF.
3. S'avalua abans que IAP. El bot que ataca el tauler d'informes es descarta abans d'arribar tan sols a la pantalla d'inici de sessió.
4. La resposta de bloqueig la genera la vora. Les teves instàncies no veuen la petició, no la registren als seus registres i no gasten CPU.

Les polítiques s'adjunten a un servei de backend:

Per als backends de bucket com bb-catalogo-imagenes existeix una variant anomenada política de seguretat de vora (--edge-security-policy), que admet menys tipus de regla —filtratge per IP, geografia i algunes expressions bàsiques— però s'aplica també al contingut servit des de la memòria cau. És la manera de protegir les imatges sense renunciar al CDN.

Una política de seguretat és un contenidor ordenat de regles. Cada regla té:

• Una prioritat (enter). S'avaluen de menor a major i guanya la primera que coincideix; la resta ni es miren.
• Una condició: o una llista de rangs IP, o una expressió.
• Una acció: allow, deny-403, deny-404, deny-502, throttle, rate-based-ban, redirect.

En crear-la, Google afegeix automàticament la regla per defecte, amb prioritat 2147483647 (l'enter més gran de 32 bits amb signe) i acció allow. És la que atrapa tot el que no ha coincidit amb res anterior.

Aquesta regla planteja la decisió de disseny més important de la lliçó:

Per al catàleg públic d'AlpinaShop, el model és forçosament llista negra: qualsevol persona del món ha de poder veure una motxilla. Per a una API interna o un tauler d'administració, la llista blanca sí que és viable i és el correcte.

Deixa sempre un forat de prioritats. Numera de 100 en 100 (1000, 1100, 1200…) per poder inserir regles entremig sense renumerar-ho tot:

La regla més simple i la que sempre ha d'anar primer: l'oficina d'AlpinaShop i el proveïdor de proves de càrrega no han de ser bloquejats mai per res, ni tan sols per una regla de l'OWASP mal calibrada.

Detalls pràctics:

• S'admeten fins a diversos milers de rangs per política, però mantenir llistes enormes a mà és insostenible. Per a això hi ha la intel·ligència d'amenaces del nivell Enterprise (apartat 13).
• Bloquejar per IP té data de caducitat. Les adreces domèstiques són dinàmiques: la que avui és d'un atacant demà és la d'un client. Documenta la data de revisió a la descripció, com a l'exemple, i revisa aquestes llistes.
• Darrere d'un proxy o d'un altre CDN, origin.ip és la del proxy. Si aquest és el teu cas, l'expressió correcta fa servir la IP de l'X-Forwarded-For de confiança; configura-ho amb cura, perquè aquesta capçalera la pot falsificar el client si no es valida bé.

Cloud Armor coneix el país d'origen de cada petició i l'exposa com a origin.region_code, amb codis ISO de dues lletres.

I una variant molt més raonable: en lloc de bloquejar el catàleg sencer, restringir només el tauler d'administració, que sí que té un origen legítim perfectament acotat.

Fixa't en deny-404 en lloc de deny-403: a l'atacant no li confirmem que existeixi un tauler d'administració. És una diferència petita que redueix la informació que regales.

Els tres advertiments del bloqueig geogràfic, i cap no és tècnic:

1. És trivial d'esquivar. Una VPN de tres euros al mes l'anul·la. Frena el soroll automatitzat, no un atacant decidit.
2. Bloqueja clients reals. Un client espanyol de vacances, un expatriat, algú darrere d'una VPN corporativa. En una botiga, cada bloqueig és una venda perduda i una trucada a atenció al client.
3. Pot tenir implicacions legals i comercials. Bloquejar països és una decisió de negoci, i en alguns contextos de compliment normatiu. Que no la prengui l'equip tècnic en solitari.

La postura recomanable: fes servir la geografia per restringir rutes sensibles (/admin, /api/interna) i per puntuar el risc en combinació amb altres senyals, no per tancar la botiga a un continent.

Aquí hi ha el valor principal d'un WAF gestionat. Google manté conjunts de regles basats en el ModSecurity Core Rule Set, actualitzats pel seu equip de seguretat, que s'invoquen amb la funció evaluatePreconfiguredWaf().

La creació de les regles, amb sensibilitat i sempre en vista prèvia la primera vegada:

La sensibilitat va d'1 a 4 i funciona com un llindar acumulatiu:

Un avís que estalvia molt de temps: si la teva aplicació és Python amb Flask i PostgreSQL, no activis php-v33-stable, nodejs-v33-stable ni java-v33-stable. No aporten protecció i cada regla activa costa diners i afegeix probabilitat de fals positiu.

Aquesta és la part que els fullets no expliquen. Les regles de l'OWASP funcionen buscant patrons, i molts patrons legítims s'assemblen a un atac. Casos reals que es donen en una botiga com AlpinaShop:

Hi ha tres maneres de resoldre-ho, en ordre de preferència:

1. Desactivar regles concretes del conjunt, en lloc de baixar la sensibilitat global:

Els identificadors de regla surten del registre: cada bloqueig registra exactament quina regla del conjunt ha disparat. Això és cirurgia, davant del cop de destral de baixar la sensibilitat.

2. Excloure rutes concretes de l'anàlisi, quan saps que un endpoint rep text lliure per disseny:

Amb una condició molt seriosa: si exclous una ruta del WAF, aquesta ruta ha d'estar impecablement validada al codi. Estàs renunciant a la xarxa de seguretat justament on entra text arbitrari.

3. Baixar la sensibilitat. És el més ràpid i el menys precís. Vàlid com a mesura temporal durant un incident.

I el consell que engloba els tres: el procediment correcte no és reaccionar als falsos positius en producció, sinó descobrir-los abans amb el mode de vista prèvia.

Cloud Armor fa servir CEL (Common Expression Language), el mateix llenguatge de les condicions d'IAM que vas veure a 03-04. Els atributs disponibles:

Cas 1: el bot que arrasa el catàleg. El competidor rastreja amb un client que s'identifica i no executa JavaScript. Se'l reconeix per la combinació d'agent d'usuari i absència de capçaleres de navegador real:

La condició !has(request.headers['accept-language']) és la més útil de les quatre: pràcticament tots els navegadors reals envien aquesta capçalera i pràcticament cap script senzill no es molesta a posar-la. I és precisament la que ha de passar més temps en vista prèvia, perquè també l'ometen alguns clients legítims.

Cas 2: protegir un endpoint car. L'exportació del catàleg en CSV triga segons i consumeix base de dades. Només s'ha de fer servir des de l'oficina:

Cas 3: rebutjar mètodes que l'aplicació no fa servir. El catàleg només serveix GET, HEAD i POST:

Cas 4: evitar l'accés per IP directa. Tota petició legítima arriba amb el Host correcte; les que arriben amb la IP al Host són escaneig indiscriminat:

Tota regla admet --preview. En aquest mode, la regla s'avalua i es registra, però no s'aplica. La petició continua el seu curs normal.

Això no és una comoditat: és el procediment. Una regla de l'OWASP amb sensibilitat mal triada pot bloquejar el cercador de la teva botiga el dia de més vendes de l'any, i el pitjor és que no te n'assabentaràs per una alerta, sinó per una caiguda de conversió que ningú no relaciona amb el WAF.

El procediment de desplegament, pas a pas:

El camp previewSecurityPolicy.preconfiguredExprIds és el que dona els identificadors concrets de regla del conjunt OWASP, que són els que necessites per a l'opt_out_rule_ids de l'apartat 7.

Un recompte agregat, per decidir amb números en lloc d'amb impressions:

Aquest recompte es llegeix així: la regla 1000 tal com està bloquejaria 847 cerques legítimes en una setmana. No s'activa: es depura amb opt_out_rule_ids o s'exclou la ruta del cercador, i torna a vista prèvia una altra setmana.

La distinció entre els dos camps del registre és la clau de tot l'apartat:

I una regla d'or operativa: no activis mai regles noves el dia abans d'una campanya. La campanya de tardor d'AlpinaShop comença el 15 de setembre; les regles es posen en vista prèvia l'1 d'agost i s'activen, com a molt tard, l'1 de setembre.

El segon problema de la Marta és la força bruta contra /acceso. Aquí no hi ha cap patró maliciós per detectar: cada petició individual és legítima. L'anòmal és la freqüència.

Cloud Armor ofereix dues accions:

• throttle: per damunt del llindar, es rebutgen les peticions que excedeixen, però tan bon punt baixa el ritme es torna a servir. És un limitador continu.
• rate-based-ban: per damunt del llindar, es veta aquest client durant un temps fix, encara que deixi d'insistir. És el càstig.

La clau d'agrupació (--enforce-on-key) decideix per qui es compta, i triar-la malament invalida la protecció:

Dos consells de calibratge que valen més que qualsevol regla:

• Mesura abans de posar un número. El percentil 99 de peticions per minut i per IP del teu trànsit real és al registre del balancejador. Posa el llindar en dues o tres vegades aquest valor, no en un número rodó triat a ull.
• deny-429 i no deny-403. El codi 429 (Too Many Requests) és el semànticament correcte, els clients legítims saben reintentar amb espera i els cercadors l'interpreten com a "torna més tard" en lloc de "això està prohibit", cosa que protegeix el teu posicionament.

Les regles anteriors depenen que algú hagi previst l'atac. La protecció adaptativa no: entrena models amb el trànsit normal de la teva aplicació i detecta desviacions anòmales, proposant regles concretes.

Com funciona a la pràctica:

1. Necessita entre diversos dies i una setmana de trànsit per tenir una línia base. Activa-la molt abans de necessitar-la.
2. Quan detecta una anomalia, genera una alerta amb la signatura de l'atac: agents d'usuari implicats, rangs d'origen, rutes atacades, i una puntuació de confiança.
3. Suggereix una regla de Cloud Armor llesta per aplicar, amb un impacte estimat sobre el trànsit legítim.
4. La decisió d'aplicar-la continua sent teva. Es pot aplicar automàticament, però en una botiga és preferible la revisió humana.

Convé tenir clar què protegeix i què no: els atacs volumètrics de capa 3 i 4 (SYN flood, amplificació UDP) els absorbeix la infraestructura de Google automàticament pel simple fet de ser darrere del balancejador global, sense configurar res. La protecció adaptativa és per als atacs de capa 7, aquests que consisteixen en peticions HTTP perfectament formades però en quantitat i patró anòmals, que són molt més difícils de distingir del trànsit real.

Quan el bot és sofisticat —executa JavaScript, rota adreces IP, envia capçaleres de navegador real— cap regla estàtica no el distingeix. La resposta és reCAPTCHA Enterprise, integrat nativament amb Cloud Armor.

El flux és interessant perquè no és el CAPTCHA clàssic de "selecciona els semàfors":

1. L'aplicació inclou l'script de reCAPTCHA, que avalua el comportament de l'usuari en segon pla i emet un token amb una puntuació de 0,0 (gairebé segur un bot) a 1,0 (gairebé segur una persona).
2. Cloud Armor llegeix aquest token a la vora i actua segons la puntuació.
3. Només si la puntuació és dubtosa es mostra un desafiament visible. La majoria dels usuaris no veuen mai res.

La decisió de disseny aquí és redirect i no deny: davant del dubte, en una botiga mai no es bloqueja, es pregunta. Un fals positiu amb deny és una venda perduda; amb redirect, un segon de fricció. Aquest criteri —bloquejar l'evident, desafiar el dubtós— és el que separa una política de seguretat usable d'una que fa perdre diners.

La intel·ligència d'amenaces mereix una menció perquè resol el problema de l'apartat 4: en lloc de mantenir llistes d'IP a mà, Google manté llistes categoritzades i actualitzades:

Altres llistes disponibles inclouen nodes de sortida de Tor, proxies anònims, escàners de cerca i els rangs dels grans proveïdors de núvol (útil: gairebé cap client legítim d'una botiga no navega des d'un centre de dades).

Cost orientatiu de Standard, com a ordre de magnitud:

Amb la política d'aquesta lliçó (unes quinze regles) i uns 10 milions de peticions al mes, surten de l'ordre de 25-30 $/mes. Comparat amb el que costa un incident, o simplement amb el que costen les instàncies addicionals que aixeca l'autoescalat durant un rastreig massiu, és de les inversions més rendibles de la plataforma. Verifica sempre les tarifes vigents a la documentació oficial, perquè canvien i varien per regió.

La protecció de la factura davant de DDoS d'Enterprise mereix una reflexió: en un atac volumètric gran, el cost no és en el dany, és en la factura de sortida de dades i de còmput que genera absorbir-lo. Aquesta assegurança és la raó principal per la qual una empresa amb exposició real contracta Enterprise.

Aquest és el resultat final per a AlpinaShop, ordenat per prioritat. Llegeix-lo com un document de disseny:

I la comprovació que funciona, que sempre s'ha de fer des de fora de l'oficina, perquè la regla 100 t'eximeix de tot:

• Activar regles sense vista prèvia. És l'error greu d'aquesta lliçó. Una regla de SQLi mal calibrada bloqueja el cercador i ningú no relaciona la caiguda de vendes amb el WAF.
• Començar amb sensibilitat 3 o 4. Sensibilitat 1 i només es puja si l'anàlisi del registre ho justifica.
• No numerar deixant forats. Prioritats correlatives obliguen a renumerar per inserir una regla.
• Oblidar la regla d'exempció de l'oficina a la prioritat més baixa. Si et bloqueges a tu mateix durant un incident, la depuració es torna un infern.
• Provar des de l'oficina. La regla 100 et deixa passar sempre; semblarà que no funciona res. Prova des d'una xarxa externa.
• Bloquejar països sense consultar. És una decisió comercial i de vegades legal, no tècnica.
• Confondre throttle amb rate-based-ban. El primer limita mentre dura l'excés; el segon veta durant un temps fix. Per a força bruta, vet.
• Llindars de taxa triats a ull. Mesura el percentil 99 real al registre del balancejador i multiplica per dos o tres.
• enforce-on-key=IP sense pensar en les IP compartides. Un institut o una empresa surten per una sola adreça; un llindar baix bloqueja trenta persones legítimes.
• Retornar deny-403 als limitadors de taxa. El codi correcte és 429.
• Activar conjunts de regles de tecnologies que no fas servir. php-v33-stable en una aplicació Python: costa diners i afegeix falsos positius sense aportar res.
• Creure que el WAF substitueix la validació al codi. Consultes parametritzades, escapat de sortida i validació d'entrada continuen sent obligatoris. El WAF és la segona línia.
• No activar el registre VERBOSE durant la vista prèvia. Sense els identificadors de regla concrets no pots fer servir opt_out_rule_ids i només et queda el cop de destral de baixar la sensibilitat.
• Consell: gestiona la política com a codi (06-07) i exporta el seu estat abans de cada canvi: gcloud compute security-policies describe pol-catalogo-web --format=yaml > politica-$(date +%F).yaml.
• Consell: posa una alerta sobre el nombre de peticions denegades. Un pic de bloquejos pot ser un atac, però també un desplegament de la teva pròpia aplicació que ha començat a enviar alguna cosa que el WAF no reconeix.

Després de set dies amb totes les regles en vista prèvia, el recompte per prioritat és:

Una mostra de les peticions de la regla 1000 mostra que el 90 % són de la forma /buscar?q=camiseta+t%C3%A9cnica+O%27Neill i /buscar?q=%22gore-tex%22. Les de la 1100 són majoritàriament POST /api/resenas amb text que conté <3 i >>.

Decideix, regla per regla, què activar, què depurar i què deixar en vista prèvia, i escriu les comandes.

AlpinaShop llança una API pública per a botigues associades: POST /api/socios/pedidos, autenticada amb una capçalera X-Alpina-Api-Key. Requisits:

• Màxim 100 peticions per minut i per clau d'API (no per IP: diverses botigues comparteixen operador).
• Les peticions sense la capçalera es rebutgen a la vora, sense arribar a l'aplicació.
• Només s'accepta POST.
• Les botigues associades són a Espanya, Portugal i França.
• Un soci que superi el límit tres vegades seguides ha de quedar vetat 15 minuts.

Escriu les regles amb les seves prioritats i justifica l'ordre.

Són les 22:00 d'un divendres. La botiga va lentíssima, el MIG és a 10 instàncies (el seu màxim) i la Marta veu al registre del balancejador que el 80 % del trànsit són peticions GET /buscar?q=<aleatori> des d'unes 4 000 adreces IP diferents repartides per tot el món, amb agents d'usuari de navegador plausibles i sense capçalera Referer.

Descriu la resposta immediata, la de les 24 hores següents i l'estructural. Per què no serveix aquí una regla per IP?

Solució 1

Regla 1000 (SQLi) — depurar, continuar en vista prèvia. Els 1204 bloquejos són gairebé tots falsos positius: apòstrofs de cognoms i cometes de cerques de marca. Bloquejar-la deixaria sense cercador els clients. Dues correccions combinades:

L'exempció de la ruta exigeix verificar abans amb el Dani que el cercador fa servir consultes parametritzades de veritat. Si no fos així, la prioritat seria arreglar el codi, no relaxar el WAF.

Regla 1100 (XSS) — depurar, continuar en vista prèvia. El problema està localitzat a /api/resenas, un endpoint que rep text lliure per disseny. Es crea l'exempció de l'apartat 7 (prioritat 950) i es comprova que les ressenyes s'escapen en renderitzar. Amb aquesta exempció posada, una altra setmana de vista prèvia.

Regla 2000 (rastreig) — vista prèvia, anàlisi manual. 156 en una setmana és poc trànsit: cal mirar d'on vénen. Si són unes poques adreces sostingudes, és el competidor i es pot activar. Si estan disperses, probablement hi hagi clients legítims entre elles (agregadors de preus contractats per la mateixa AlpinaShop, per exemple) i cal afinar l'expressió abans.

Regles 1400 (escàners), 1200 (LFI) i 900 (CVE) — activar ja.

Volums baixos i patrons que no tenen cap explicació legítima: són atacs reals. S'activen sense més discussió.

Solució 2

Justificació de l'ordre. Les regles s'avaluen de menor a major prioritat i guanya la primera coincidència, així que van del més barat i categòric al més costós:

1. Mètode incorrecte (4900) i capçalera absent (4910) són comprovacions trivials que descarten trànsit escombraria sense avaluar res més. Com abans, millor.
2. Geografia (4920) en vista prèvia, perquè un soci francès que faci servir un proxy a Bèlgica quedaria fora i això cal confirmar-ho amb l'equip comercial abans d'activar-ho.
3. Limitació de taxa (4930) al final: és la regla més cara d'avaluar i només té sentit aplicar-la a peticions que ja han superat els filtres anteriors.

El punt clau és --enforce-on-key=HTTP_HEADER amb --enforce-on-key-name. Comptar per IP fallaria en tots dos sentits: penalitzaria injustament diverses botigues que comparteixen operador i no impediria que un soci abusiu rotés d'adreça. Amb l'advertiment corresponent: la capçalera la controla el client, així que la validació real de la clau se segueix fent a l'aplicació; Cloud Armor només la fa servir per agrupar el recompte.

Solució 3

Per què no serveix una regla per IP. Són 4 000 adreces distribuïdes, probablement una botnet o un servei de proxies residencials. Bloquejar adreces una a una és perseguir un objectiu que es mou més ràpid del que escrius.

Resposta immediata (minuts). El que hi ha en comú no és l'origen, és el comportament: rutes /buscar amb termes aleatoris i sense Referer.

El redirect a reCAPTCHA és la millor eina en un incident de bots en una botiga: les persones continuen comprant, els bots cauen.

Següents 24 hores.

• Activar la protecció adaptativa si no ho estava (encara que trigarà a tenir línia base, i aquesta és la lliçó: s'activa abans, no durant).
• Analitzar el registre agrupant per rangs, agent d'usuari i sistema autònom, buscant una signatura més precisa que permeti afinar la regla d'emergència i reduir-ne l'impacte en clients reals.
• Revisar l'impacte col·lateral: quantes cerques legítimes van caure amb 429 mentre va durar la regla 3050.
• Apujar temporalment el màxim de l'autoescalat del MIG si continua havent-hi pressió.

Estructural.

• Desar les cerques freqüents a la memòria cau del CDN (03-03): una cerca que se serveix des de la vora no toca la base de dades.
• Revisar per què el cercador és tan car. Un límit de taxa que salva la botiga és un pedaç sobre un endpoint que hauria d'aguantar més; potser falta un índex o convé moure la cerca a un servei dedicat.
• Deixar les regles d'emergència documentades i amb data de revisió, no permanents amb un llindar de crisi.
• Avaluar Cloud Armor Enterprise: en un atac així, la intel·ligència d'amenaces hauria reconegut bona part d'aquests orígens i la protecció de factura hauria cobert el sobrecost.

AlpinaShop ja no rep tot el que li arriba. Saps què és un WAF i, sobretot, què no resol: no arregla fallades de lògica de negoci, no detecta credencials robades i no apedaça dependències vulnerables. És una capa de mitigació que compra temps, no una absolució, i per això les consultes parametritzades i la validació d'entrada continuen sent obligatòries al codi del Dani.

Entens on actua Cloud Armor: a la vora, al mateix punt de presència on entra el client, abans de la memòria cau i abans d'IAP, adjuntat com a política al servei de backend bs-catalogo-web i com a política de vora al backend de bucket bb-catalogo-imagenes. Domines el model de polítiques, regles i prioritats, amb la regla per defecte allow a l'extrem, l'exempció de l'oficina a la prioritat 100 i el costum de numerar de cent en cent per poder inserir.

Has construït pol-catalogo-web completa: regles per IP i per geografia —amb l'advertiment que bloquejar països és una decisió comercial i legal, no tècnica—, els conjunts preconfigurats de l'OWASP amb sensibilitat 1 i el seu problema real, que són els falsos positius del cercador i de les ressenyes, i les tres maneres de tractar-los per ordre de precisió: opt_out_rule_ids, exempció de ruta i baixada de sensibilitat. Has escrit regles pròpies en CEL per al rastrejador del competidor, l'endpoint car d'exportació, els mètodes HTTP inútils i les peticions amb Host invàlid. I has après el procediment que fa tot això segur: --preview primer, registre VERBOSE, una setmana de trànsit real, recompte per prioritat, depuració, activació per fases i mai la vigília d'una campanya, llegint la diferència entre previewSecurityPolicy i enforcedSecurityPolicy al registre.

Has protegit el formulari d'accés amb rate-based-ban i el cercador amb throttle, triant la clau d'agrupació amb criteri i retornant 429 en lloc de 403. Coneixes la protecció adaptativa de capa 7 i per què cal activar-la abans de necessitar-la, l'ús de reCAPTCHA Enterprise amb redirect en lloc de deny —davant del dubte, en una botiga es pregunta, no es bloqueja—, i la diferència entre Standard i Enterprise, amb la intel·ligència d'amenaces i la protecció de la factura com a arguments de pes.

Queda, tanmateix, un assumpte incòmode. La contrasenya de l'usuari app_catalogo d'alpinashop-pedidos continua viatjant en una variable d'entorn de l'startup-script de la plantilla del MIG: en text clar, visible per a qualsevol que pugui llegir les metadades d'una instància, impossible de rotar sense tornar a desplegar i present a cada còpia de la plantilla. Hem protegit la vora amb cura mentre la clau de la base de dades és sota l'estora. A la lliçó següent, 03-06, Secrets i xifratge: Secret Manager i Cloud KMS, traiem aquesta contrasenya d'aquí i la portem a un magatzem amb versions, permisos per secret i rotació; i de passada entenem com xifra Google Cloud les teves dades en repòs, què són les claus gestionades pel client (CMEK) i quan compensa assumir la responsabilitat de gestionar-les tu.