Al llarg d'aquest curs hem anat deixant caps solts, i tots són el mateix cap. A 03-01 vam escriure una regla de tallafoc que permet SSH des del rang d'IAP, i vam dir que el tallafoc no distingeix persones: que "només la Marta i la Lucía puguin entrar" es resol en un altre lloc. A 02-02 vam limitar la Lucía al prefix exportaciones/ del bucket amb una condició que no vam arribar a explicar. A 02-05 vam vincular els pods de GKE a un compte de servei sense fitxers de clau. A 03-03 vam dir que invalidar la memòria cau exigeix un rol que no convé repartir. Aquest altre lloc, aquesta condició i aquest rol són IAM.

IAM és el sistema que respon a una única pregunta, formulada milions de vegades al dia a cada projecte: pot aquesta identitat fer aquesta acció sobre aquest recurs? És, sense exagerar, el servei més important de Google Cloud. Una VM mal dimensionada costa diners; un permís mal donat costa l'empresa. I és també el servei que més gent configura malament, gairebé sempre de la mateixa manera: donant Editor a tothom perquè les coses funcionin i prometent-se ordenar-ho més endavant.

En aquesta lliçó construiràs el model de permisos real d'AlpinaShop: entendràs l'equació identitat + rol + recurs, sabràs per què els permisos es donen a grups i mai a persones, crearàs un rol personalitzat per a la Lucía, dissenyaràs la matriu completa d'accessos de la Marta, el Dani i la Lucía sobre els quatre projectes, entendràs els comptes de servei i per què una clau JSON descarregada és una bomba de rellotgeria, aprendràs a limitar accessos amb condicions, a diagnosticar per què algú no pot fer alguna cosa, i a publicar aplicacions internes i obrir sessions SSH sense VPN gràcies a IAP.

Avís. El disseny de permisos té implicacions de seguretat i, segons el sector, regulatòries. El que segueix és un model docent sòlid i aplicable, però abans de portar a producció un esquema d'accessos que governi dades personals o financeres, l'ha de revisar un professional de seguretat i compliment normatiu.

1. L'equació d'IAM: identitat + rol + recurs
2. Permisos, rols i polítiques: els tres objectes que cal distingir
3. Tipus d'identitat
4. Grups de Google: la decisió que més ho simplifica tot
5. Tipus de rol: bàsics, predefinits i personalitzats
6. Un rol personalitzat real: "analista de catàleg" per a la Lucía
7. Herència per la jerarquia i política efectiva
8. El disseny d'accessos d'AlpinaShop
9. Comptes de servei: identitats per al programari
10. Suplantació i credencials de curta durada
11. Claus JSON: per què són el problema i què fer servir en el seu lloc
12. Condicions d'IAM: accés limitat en el temps i per recurs
13. Diagnòstic: policy-troubleshooter, política efectiva i Recommender
14. Mínim privilegi i separació de funcions, pas a pas
15. IAP: SSH sense IP pública i aplicacions internes sense VPN

Tot IAM es redueix a una frase:

Una política de permisos vincula qui (identitat) amb què pot fer (rol) sobre on (recurs).

Tres conseqüències immediates d'aquest model:

• Tot es denega per defecte. Una identitat sense vinculacions no pot fer absolutament res. No cal "treure" permisos: cal donar-los.
• La política s'adjunta al recurs, no a la persona. No existeix "els permisos de la Lucía"; existeix "la política del projecte alpinashop-datos", on la Lucía apareix. Per això cal saber on mirar.
• Els permisos són additius i s'hereten cap avall. Un rol concedit a la carpeta produccion s'aplica a tots els projectes de dins. I tret que facis servir polítiques de denegació, res no treu el que s'ha concedit més amunt.

Els permisos es corresponen gairebé un a un amb crides a l'API. Quan la consola et diu "no tens permís per fer aquesta acció", el que falta és un permís concret; la feina consisteix a trobar quin rol el conté.

Aquesta segona comanda és or pur: converteix "necessito poder invalidar la memòria cau del CDN" en "necessito roles/compute.loadBalancerAdmin" sense buscar a la documentació.

En l'argot d'IAM, una identitat s'anomena principal i s'escriu amb un prefix que n'indica el tipus:

Les dues formes de federació mereixen distingir-se bé, perquè es confonen:

• Workforce Identity Federation — per a persones que ja tenen identitat en un proveïdor extern (Microsoft Entra ID, Okta, qualsevol OIDC/SAML). Permet que els empleats entrin a Google Cloud amb les credencials corporatives sense crear comptes de Google. Es configura a nivell d'organització.
• Workload Identity Federation — per a màquines i processos externs: un pipeline de GitHub Actions, un clúster de Kubernetes fora de Google, una càrrega en un altre núvol. El procés extern presenta el seu propi token (per exemple, el token OIDC que GitHub emet a cada execució) i Google l'hi canvia per credencials temporals d'un compte de servei.

Aquesta segona és avui la resposta correcta a "com desplego des de GitHub sense pujar una clau JSON al repositori?". La veurem aplicada a 06-01, però convé saber que existeix des d'ara, perquè elimina d'arrel el pitjor risc d'aquesta lliçó.

És temptador donar permisos directament a les persones. És també la decisió que fa ingovernable l'accés al cap d'un any. Compara:

La regla, sense excepcions pràctiques:

Els rols es concedeixen a grups. Les persones s'afegeixen a grups. Una vinculació user: a la política d'un projecte és una olor de disseny: o és temporal i porta una condició de caducitat, o està malament.

Els grups d'AlpinaShop es creen a Google Workspace (o Cloud Identity, que és gratuït per a aquest ús) i han de tenir noms que diguin què són, no qui hi ha a dins:

Un matís important: IAM no crea ni gestiona grups. Els grups viuen a Cloud Identity / Workspace i IAM només els referencia. La gestió de membres la fa l'administrador d'identitat, que pot ser una persona diferent de l'administrador del núvol. Això, lluny de ser un inconvenient, és una separació de funcions sana.

Per què els bàsics són un antipatró, amb concreció i no com a dogma:

• roles/editor inclou la capacitat de crear comptes de servei i concedir-se permisos a través d'ells en molts escenaris, a més de modificar o esborrar pràcticament qualsevol recurs del projecte. És una escalada de privilegis esperant a passar.
• roles/owner afegeix la capacitat de modificar la política IAM: qui el té es pot donar a si mateix i a qualsevol tot la resta, i pot treure-te'l a tu.
• Tots tres són anteriors a l'existència de la majoria dels serveis. Quan Google llança un producte nou, els seus permisos s'incorporen automàticament a editor. És a dir, els permisos dels teus usuaris creixen sense que ningú no decideixi res.
• Trenquen qualsevol auditoria: "qui pot esborrar la base de dades de producció?" es respon amb una llista de vint persones.

Excepció raonable: en un projecte de laboratori personal, roles/owner per a tu mateix. A alpinashop-prod, mai.

Els predefinits són la resposta el 90 % de les vegades. Estan agrupats per servei i solen venir en tres sabors: viewer (llegir), user/developer (usar), admin (gestionar). Busca'ls així:

La Lucía necessita, a alpinashop-datos, poder:

• Consultar les taules del catàleg i llançar consultes.
• Llegir les exportacions del bucket, però no escriure ni esborrar.
• Veure l'estat de les instàncies per saber si un informe ha fallat perquè la VM estava aturada, però no apagar-les ni encendre-les.

Cap rol predefinit no diu exactament això. roles/viewer li donaria accés de lectura a tot el projecte, incloses les polítiques IAM i les configuracions de xarxa. Aquest és el cas de llibre d'un rol personalitzat.

Primer, descobreix quins permisos existeixen i quins es poden fer servir en un rol personalitzat:

Ara el rol, en un fitxer YAML que ha de ser al repositori d'infraestructura, perquè un rol és codi:

Cinc coses que cal saber sobre els rols personalitzats i que només s'aprenen patint-les:

1. bigquery.jobs.create és el permís oblidat. Sense ell, la Lucía veu les taules però qualsevol consulta falla. La lectura de dades i l'execució de treballs són permisos diferents.
2. stage pot ser ALPHA, BETA, GA o DISABLED. Posar DISABLED és la manera de desactivar un rol sense esborrar-lo, útil per comprovar si algú en depenia.
3. Es creen en un projecte o en una organització, no en una carpeta. Si el rol l'han de fer servir diversos projectes, crea'l a nivell d'organització (--organization=ORG_ID); si no, es duplica.
4. Els mantens tu. Quan Google afegeix un permís nou a un servei, els predefinits l'incorporen sols; el teu rol personalitzat, no. Revisa'ls periòdicament.
5. Comença copiant un predefinit i treu, en lloc de partir de zero: gcloud iam roles copy --source=roles/bigquery.dataViewer --destination=... --dest-project=....

La jerarquia d'AlpinaShop, que vas definir a 01-04:

La política efectiva d'un recurs és la unió de les polítiques de tots els seus avantpassats més la seva pròpia. Conseqüències:

• Un rol donat a l'organització s'aplica als quatre projectes i a tots els seus recursos. Per això hi ha molt poques coses que s'hi hagin de concedir.
• No es pot restar heretant. Si algú té roles/editor a la carpeta produccion, no hi ha manera de "treure-l'hi" a alpinashop-prod mitjançant una política de permisos. L'única eina que resta són les polítiques de denegació (gcloud iam policies), que s'avaluen abans que les de permís i guanyen sempre; són l'excepció, no el mecanisme habitual, i es tracten juntament amb el govern a escala a 07-07.
• La regla pràctica: concedeix al nivell més baix que resolgui el problema. Si el permís només cal sobre un bucket, dona'l sobre el bucket, no sobre el projecte.

Molts recursos accepten política pròpia. Compara la granularitat:

Aquest és el resultat de l'exercici de disseny, i el que has de poder justificar línia a línia:

Llegeix-ho amb atenció, perquè les decisions interessants són les que no hi apareixen:

• Ningú no té owner a alpinashop-prod. Ni tan sols la Marta. L'administració de la política IAM de producció es fa mitjançant una elevació temporal explícita (apartat 12), no amb un rol permanent.
• El Dani no pot modificar producció. Pot mirar —mètriques, registres, estat de les instàncies— perquè necessita diagnosticar incidents, i pot entrar per SSH via IAP per depurar. Però no pot desplegar a mà: els canvis entren pel pipeline d'alpinashop-cicd (06-01). Això no és desconfiança, és traçabilitat: tot canvi en producció té un commit al darrere.
• La Marta sí que és owner a alpinashop-dev. L'entorn de desenvolupament es trenca i es refà; allà la fricció no aporta res.
• La Lucía no té absolutament res a producció. Les seves dades arriben a alpinashop-datos per replicació i exportació. Si necessités llegir directament de la rèplica alpinashop-pedidos-replica-informes, el permís seria roles/cloudsql.client sobre aquesta instància concreta, amb condició, i no un rol de projecte.
• La facturació es veu a nivell d'organització, no de projecte, perquè les preguntes de cost són transversals (07-05).
• roles/iam.securityReviewer permet llegir totes les polítiques IAM sense poder modificar-ne cap. És el rol correcte per a auditoria i per respondre a "qui té accés a què?".

Aplicat amb gcloud, el disseny s'escriu així:

--condition=None és obligatori quan la política ja conté vinculacions condicionals; sense ell, gcloud pregunta de forma interactiva i el bucle s'atura.

Un compte de servei és una identitat que pertany a l'aplicació, no a una persona. Té un correu amb la forma [email protected] i és alhora dues coses, cosa que desconcerta al principi:

• Una identitat: se li concedeixen rols, com a un usuari.
• Un recurs: té la seva pròpia política IAM, que diu qui el pot fer servir.

Aquesta segona faceta és la que gairebé ningú no veu al principi i la que explica la meitat dels errors de permisos.

Els comptes de servei d'AlpinaShop fins ara, i per què són diversos i no un:

Un compte de servei per càrrega de treball. No un per projecte, no un per equip. Quan una credencial es veu compromesa, el radi de dany és exactament el d'aquesta càrrega. I quan revises els registres, saps qui va fer què sense ambigüitat.

Dos avisos concrets:

• No facis servir mai el compte de servei per defecte de Compute Engine. Es crea automàticament, ve amb roles/editor al projecte i totes les VM el fan servir si no dius una altra cosa. És a dir: qualsevol codi en qualsevol VM pot fer gairebé qualsevol cosa al projecte. Crea't el teu i assigna'l explícitament a la plantilla d'instància.
• roles/iam.serviceAccountUser sobre un compte de servei és més poderós del que sembla. Permet llançar recursos amb aquesta identitat, i per tant heretar-ne els permisos. Donar-lo sobre un compte potent equival a donar aquests permisos.

La manera correcta que una persona executi alguna cosa amb els permisos d'un compte de servei no és descarregar-ne la clau: és suplantar-lo (impersonation). Google emet un token de vida curta —típicament una hora— i no existeix cap fitxer de credencials per robar.

I per a les biblioteques client de Python, la suplantació també funciona sense claus:

Avantatges davant d'una clau descarregada, que convé enumerar perquè és l'argument que hauràs de donar a algú:

• Caduca sola. Una hora després no val res.
• Deixa rastre. Els registres d'auditoria enregistren que lucia@ va suplantar sa-informes-nocturnos, amb la qual cosa l'acció té amo humà.
• Es revoca traient un rol, no perseguint fitxers pels portàtils de l'equip.
• Encadena bé: un procés pot suplantar un altre compte si la política ho permet, formant cadenes auditables.

Relacionat, i molt útil des del punt de vista organitzatiu: Privileged Access Manager permet concedir elevacions temporals amb aprovació i caducitat automàtica —"la Marta necessita ser administradora d'IAM en producció durant dues hores per arreglar això"— sense que ningú no tingui aquest rol de forma permanent. És la resposta moderna a "ningú no és owner en producció, però algú ha de poder arreglar-ho a les 3 de la matinada".

Aquesta comanda existeix, funciona, i l'hauries de tractar com l'últim recurs:

Aquest fitxer conté una clau privada RSA que no caduca mai i que autentica el compte de servei des de qualsevol punt d'internet. Sense segon factor, sense restricció de xarxa, sense caducitat. El que passa després és sempre la mateixa història: acaba en un repositori de Git, en un canal de Slack, en un .env copiat a tres portàtils, o a la imatge d'un contenidor publicada en un registre.

Alternatives, en ordre de preferència:

Si acabes a l'última fila, com a mínim:

I bloqueja la creació de claus de forma preventiva amb la restricció de política d'organització constraints/iam.disableServiceAccountKeyCreation, que s'explica a 07-07. És una de les tres o quatre mesures amb millor relació esforç/risc de tota la plataforma.

Una vinculació condicional només concedeix el rol si es compleix una expressió CEL. Serveix per a dues coses molt pràctiques.

Cas 1: accés temporal. Un consultor extern necessita veure registres de producció durant una setmana:

Això elimina el deute d'accés per construcció: el permís es retira sol, encara que ningú no se'n recordi. És la manera correcta de donar qualsevol accés excepcional.

Cas 2: accés limitat per recurs. És la condició que vam deixar pendent a 02-02, la que restringeix la Lucía al prefix exportaciones/:

Altres atributs disponibles a les expressions:

Limitacions que cal conèixer abans de dissenyar sobre això:

• No tots els serveis admeten condicions sobre resource.name. Cloud Storage, Compute Engine, Secret Manager i BigQuery sí, en distinta mesura; d'altres ignoren l'atribut i la condició no es compleix mai, deixant la persona sense accés i tu confós. Comprova-ho sempre a la documentació del servei concret.
• Les condicions no es poden fer servir amb rols bàsics.
• Compliquen el diagnòstic. Una persona amb el rol correcte i una condició que no es compleix veu exactament el mateix error que una persona sense el rol. Per això existeix l'apartat següent.

La pregunta més freqüent de qualsevol administrador del núvol és "per què aquest usuari no pot fer això?". Hi ha una eina que la respon directament:

La resposta no és un sí o un no: és la llista de totes les vinculacions examinades a tota la jerarquia, amb el veredicte de cadascuna i el motiu. Allà es veu si el rol no hi és, si hi és però al projecte equivocat, o si hi és amb una condició que no es compleix. És la diferència entre diagnosticar i endevinar.

Les altres tres eines del kit:

La comanda 3 és la que respon de veritat a "quin accés té aquesta persona?" abans d'una baixa o d'una auditoria. La 2 només mira un projecte; la 3 escombra organització, carpetes, projectes i recursos.

IAM Recommender tanca el cicle: analitza noranta dies d'ús real i proposa treure permisos que ningú no ha exercit.

Sobre aquestes recomanacions, dos matisos de sentit comú: hi ha permisos que es fan servir una vegada l'any —el procés de tancament comptable, la restauració d'una còpia— i l'anàlisi de noranta dies no els veu. Revisa abans d'aplicar, i aplica primer sobre els comptes de servei, on el patró d'ús és molt més estable que el d'una persona.

Mínim privilegi: cada identitat té exactament els permisos que necessita, ni un més. A la pràctica és un procediment, no una virtut:

1. Parteix de zero. Mai d'Editor amb la intenció de retallar; aquesta retallada no arriba mai.
2. Deixa que falli. Executa el treball real i anota quin permís reclama cada error.
3. Tradueix el permís a rol amb gcloud iam roles list --filter="includedPermissions:...".
4. Concedeix el predefinit més petit que el contingui; si encara és massa gran, rol personalitzat.
5. Concedeix-lo al nivell més baix possible: recurs abans que projecte, projecte abans que carpeta.
6. Revisa als tres mesos amb Recommender i amb search-all-iam-policies.

Separació de funcions: que cap identitat no pugui completar sola una cadena crítica. Aplicat a AlpinaShop:

I el corol·lari que ja és a la taula de l'apartat 8: ningú no és owner de producció de forma permanent. Quan cal, s'eleva de forma temporal, amb motiu i amb caducitat.

Identity-Aware Proxy aplica IAM a l'accés a l'aplicació, no només a l'API. És el pont entre el que vas aprendre de xarxa a 03-01 i el que acabes d'aprendre d'identitat. La seva idea és la de la confiança zero: l'autorització depèn de qui ets, no d'on ets.

Té dos usos, i a AlpinaShop fem servir tots dos.

Ús 1: reenviament TCP per a SSH. Ja vas escriure la regla fw-allow-ssh-iap que permet el port 22 només des de 35.235.240.0/20. El que faltava era el permís:

Aquí hi ha per fi la resposta a l'exercici pendent de 03-01: "només la Marta i la Lucía poden entrar per SSH" s'implementa amb roles/iap.tunnelResourceAccessor i roles/compute.osLogin, no amb una regla de tallafoc. El tallafoc obre la porta al rang d'IAP; IAM decideix qui la creua. I si volguéssim que la Lucía entrés només a la VM d'informes i no a les del catàleg, seria una vinculació condicional sobre resource.name.

Ús 2: publicar aplicacions internes sense VPN. La Marta vol que el tauler d'informes interns sigui accessible des de casa, sense VPN, només per al personal autoritzat. La solució tradicional seria una VPN; la d'IAP consisteix a posar el tauler darrere d'un balancejador extern i activar IAP al seu servei de backend:

Flux d'una petició:

Tres detalls que fan que això sigui segur de veritat:

• L'aplicació no veu trànsit no autenticat. IAP filtra abans.
• IAP injecta la identitat en capçaleres signades (X-Goog-IAP-JWT-Assertion), que l'aplicació ha de validar criptogràficament. Si et limites a llegir el correu d'una capçalera sense verificar-ne la signatura, qualsevol que arribi al backend directament pot suplantar qui vulgui.
• Per això mateix, el tallafoc ha de continuar impedint que ningú arribi al backend saltant-se el balancejador: IAP no substitueix les regles de xarxa de 03-01, les complementa.

I es combina de forma natural amb el que ve: Cloud Armor (03-05) filtra per reputació i patrons abans que IAP demani credencials, de manera que el trànsit automatitzat ni tan sols arriba a la pantalla d'inici de sessió.

• Concedir roles/editor "perquè funcioni". És l'error més car de l'ecosistema. Dedica quinze minuts a trobar el rol predefinit correcte.
• Donar permisos a persones en lloc de a grups. Funciona el primer mes i es converteix en impossible d'auditar el primer any.
• Fer servir el compte de servei per defecte de Compute Engine. Porta roles/editor de fàbrica i l'hereten totes les VM que no diguin una altra cosa.
• Descarregar claus JSON. No caduquen, no tenen segon factor i acaben a Git. Suplantació o Workload Identity Federation, gairebé sempre.
• Oblidar que un compte de servei és també un recurs. "Té els rols correctes però no el pot fer servir" gairebé sempre significa que falta serviceAccountUser o serviceAccountTokenCreator a la política del compte.
• Concedir a l'organització el que només cal en un projecte. S'hereta cap avall i no es pot restar.
• Creure que es pot "treure" un permís heretat amb una altra vinculació. Els permisos són additius; només les polítiques de denegació resten (07-07).
• Condicions sobre serveis que no les admeten. La vinculació es crea sense error i no funciona mai. Verifica el suport del servei.
• Confondre autenticació amb autorització. gcloud auth login diu qui ets; IAM diu què pots. Un error de permisos no s'arregla tornant-se a autenticar.
• Aplicar les recomanacions del Recommender a cegues. Noranta dies no veuen un procés anual.
• Oblidar --condition=None als scripts. La comanda es queda esperant entrada interactiva i el bucle es penja.
• Consell: gestiona IAM com a codi. Terraform (06-07) per a les vinculacions, YAML versionat per als rols personalitzats. Un permís concedit a mà a la consola és un permís que ningú no recordarà per què existeix.
• Consell: documenta cada excepció al mateix description de la condició. El teu jo d'aquí a sis mesos t'ho agrairà.

El Dani intenta actualitzar la plantilla del MIG a alpinashop-prod des del seu portàtil i rep PERMISSION_DENIED: compute.instanceGroupManagers.update. Escriu la seqüència de diagnòstic i decideix què fer. Tingues en compte la matriu d'accessos de l'apartat 8 abans de respondre "concedir-li el rol".

El procés batch de la Lucía s'executa cada nit a alpinashop-informes-1 i ha de:

• Llegir la rèplica alpinashop-pedidos-replica-informes a través de l'Auth Proxy.
• Escriure un fitxer CSV a gs://alpinashop-catalogo/exportaciones/<fecha>/.
• Carregar aquest fitxer en una taula de BigQuery del projecte alpinashop-datos.
• Llegir la contrasenya de la rèplica des de Secret Manager.
• No ha de poder esborrar res, ni llegir les imatges del catàleg, ni veure altres secrets.

Dissenya la solució completa: compte de servei, rols (predefinits o personalitzats), condicions i en quin nivell de la jerarquia es concedeix cada cosa. Escriu les comandes.

Una consultora externa farà una auditoria de seguretat durant dues setmanes, de l'1 al 15 de setembre de 2026. Necessiten llegir les configuracions de xarxa, les polítiques IAM i els registres del balancejador d'alpinashop-prod, però no han de veure dades de clients ni modificar res. Dissenya l'accés i justifica cada decisió.

Solució 1

Diagnòstic:

Resultat esperat: el Dani pertany a gcp-desarrollo@, que a alpinashop-prod només té rols de lectura. El permís és a roles/compute.instanceGroupManagerAdmin i a roles/compute.admin.

Què fer: no concedir-l'hi. La matriu de l'apartat 8 és una decisió deliberada de separació de funcions: els canvis en producció entren pel pipeline, amb un commit, una revisió i traçabilitat. Concedir-li el rol resoldria el símptoma i destruiria la propietat que fa fiable el sistema.

Les respostes correctes, en ordre:

1. Desplegar pel pipeline (06-01): el canvi es fa al repositori, es revisa i l'aplica sa-despliegue, que sí que té el rol a alpinashop-prod.
2. Si és una emergència real, una elevació temporal amb Privileged Access Manager, o si no una vinculació condicional amb caducitat d'hores i una descripció que expliqui l'incident:

3. Si el Dani necessita això cada setmana, el que falla no són els permisos sinó el pipeline. Arregla el pipeline.

Solució 2

Decisions clau i el seu perquè:

• objectCreator en lloc d'objectAdmin. Permet crear objectes però no esborrar-los ni sobreescriure'ls. Compleix el requisit de "no esborrar res" per construcció, no per confiança.
• La condició de prefix impedeix que el procés escrigui a productos/ encara que tingués una fallada de programació. I com que no té objectViewer, tampoc no pot llegir les imatges.
• El secret es concedeix a nivell de secret. roles/secretmanager.secretAccessor al projecte donaria accés a tots els secrets, inclosa la clau de la passarel·la de pagament.
• cloudsql.client va a alpinashop-prod, que és on viu la instància, encara que el compte de servei pertanyi a alpinashop-datos. Una identitat d'un projecte pot tenir rols en un altre; és completament normal.
• Cap clau JSON. La VM porta el compte assignat i les biblioteques de Python el detecten soles.
• Un rol personalitzat no aporta res aquí: els predefinits, acotats amb condicions i aplicats al recurs correcte, ja són prou estrets. No creïs rols personalitzats si un predefinit ben col·locat resol el cas.

Solució 3

Justificació:

• Un grup propi, encara que siguin tres persones de fora. Es donen d'alta i de baixa al grup, i la política no es toca.
• Caducitat a totes les vinculacions. L'accés desapareix sol el dia 16. Aquest és l'ús canònic de les condicions i evita el clàssic "el consultor continua tenint accés dos anys després".
• roles/iam.securityReviewer permet llegir les polítiques IAM sense poder modificar-les: exactament el que necessita una auditoria.
• roles/compute.networkViewer en lloc de roles/compute.viewer: veuen la xarxa, les regles de tallafoc i el balancejador, però no les metadades de les instàncies, que poden contenir informació sensible.
• Cap rol sobre dades. Res de cloudsql.viewer, storage.objectViewer ni bigquery.dataViewer: poden auditar la configuració de la base de dades sense llegir ni una sola fila de clients. Si necessitessin veure dades, hauria d'intervenir el responsable de protecció de dades i probablement n'hi hauria prou amb dades anonimitzades.
• Sense accés a alpinashop-dev ni alpinashop-datos, tret que l'abast de l'auditoria ho exigeixi per escrit.
• Addicionalment, revisar a 07-07 que els registres d'auditoria d'accés a dades estiguin activats durant el període, perquè quedi constància de què va consultar la consultora.

IAM ha deixat de ser el lloc on un va a "donar permisos" per convertir-se en el disseny que sosté tot la resta. Has interioritzat l'equació identitat + rol + recurs = política de permisos, amb les seves tres propietats: tot està denegat per defecte, la política s'adjunta al recurs i els permisos s'hereten cap avall sense poder restar-se. Distingeixes permís, rol, vinculació i política, i saps traduir un PERMISSION_DENIED en el rol que el resol amb gcloud iam roles list --filter="includedPermissions:...".

Coneixes els tipus d'identitat —usuaris, grups, comptes de servei i les dues federacions, Workforce per a persones i Workload per a màquines— i has adoptat la regla que més simplifica l'operació a llarg termini: els rols es concedeixen a grups i les persones es mouen entre grups. Saps per què Owner, Editor i Viewer són un antipatró (creixen sols, permeten escalada, arruïnen l'auditoria) i has construït el disseny real d'AlpinaShop: gcp-infra@, gcp-desarrollo@, gcp-datos@, gcp-facturacion@ i gcp-seguridad@ amb rols diferents a cadascun dels quatre projectes, sense que ningú sigui owner de producció. Has creat el rol personalitzat analistaCatalogo per a la Lucía en YAML versionat, amb el permís bigquery.jobs.create que gairebé tothom oblida.

Has entès la doble naturalesa dels comptes de servei —identitat i recurs alhora—, la regla d'un per càrrega de treball, i per què el compte per defecte de Compute Engine no s'ha de fer servir mai. Saps suplantar comptes amb --impersonate-service-account per obtenir credencials que caduquen en una hora i deixen rastre, i tens la llista ordenada d'alternatives a la clau JSON descarregada, que és la pitjor credencial que existeix: no caduca, no té segon factor i acaba a Git. Has limitat accessos en el temps i per prefix de recurs amb condicions CEL, resolent per fi la restricció de la Lucía a exportaciones/ que va quedar pendent a 02-02. I tens les quatre eines de diagnòstic: policy-troubleshoot per al "per què no pot", get-iam-policy per a la foto, asset search-all-iam-policies per escombrar l'organització sencera abans d'una baixa, i el Recommender per retallar el que ningú no fa servir.

Finalment, IAP ha tancat el cercle entre xarxa i identitat: la regla fw-allow-ssh-iap de 03-01 obre la porta al rang 35.235.240.0/20, i roles/iap.tunnelResourceAccessor decideix qui la creua; i el tauler d'informes de la Lucía es pot publicar a internet sense VPN perquè IAP exigeix identitat corporativa i segon factor abans que la petició arribi al backend.

Però IAM protegeix davant de qui té una identitat. No diu res sobre el visitant anònim que recorre el catàleg a mil peticions per segon per copiar els preus, ni sobre el que prova deu mil contrasenyes contra el formulari d'accés, ni sobre el que injecta ' OR 1=1-- al cercador. Aquest trànsit arriba al balancejador sense cap identitat i cal filtrar-lo abans, a la vora. A la lliçó següent, 03-05, Cloud Armor, posem un tallafoc d'aplicació davant del balancejador global: regles per IP i geografia, protecció davant de l'OWASP Top 10, limitació de taxa contra la força bruta, l'imprescindible mode de vista prèvia per no bloquejar els teus propis clients, i la política pol-catalogo-web aplicada a bs-catalogo-web just a temps per a la campanya de tardor.