Ja saps que les polítiques són els documents que defineixen els permisos a AWS. Però hi ha dues formes d’aplicar-les, segons on les adjuntis: a una identitat o a un recurs. Entendre la diferència t’ajudarà a llegir i escriure permisos correctament, i a resoldre el clàssic misteri de «per què aquest permís no funciona?».

Una política IAM és un document JSON. La seva peça central és la declaració (statement), que respon a:

• Effect: Allow (permetre) o Deny (denegar).
• Action: què es pot fer (s3:GetObject = llegir objectes de S3).
• Resource: sobre quin recurs (identificat pel seu ARN, l’identificador únic de qualsevol recurs a AWS).

Aquesta política diu: «Permetre l’acció llegir objectes sobre els objectes del bucket informes-2026». No et preocupis per memoritzar la sintaxi; l’important és entendre el concepte.

S’adjunten a una identitat: un usuari, un grup o un rol. Responen a la pregunta:

«Què pot fer AQUESTA identitat?»

Exemple: Adjuntes a la usuària Maria una política que diu «pot llegir del bucket informes-2026». El permís viatja amb la Maria: allà on actuï, pot llegir aquest bucket.

És la forma més comuna. Quan dones permisos als teus usuaris i rols, normalment utilitzes polítiques basades en identitat.

S’adjunten al recurs en si: un bucket de S3, una cua SQS, una funció Lambda… Responen a la pregunta:

«Qui pot accedir a AQUEST recurs?»

Exemple: Adjuntes al bucket informes-2026 una política que diu «el compte de l’empresa col·laboradora pot llegir els meus objectes». El permís viatja amb el bucket: defineix qui pot entrar-hi.

Ja vas veure un exemple al Capítol 5: les bucket policies de S3 són polítiques basades en recurs.

Analogia de l’edifici:

• Una política basada en identitat és com el que la teva targeta d’empleat pot obrir. La portes amb tu; defineix a quines portes pots entrar tu.
• Una política basada en recurs és com la llista de persones autoritzades enganxada a la porta d’una sala concreta. Defineix qui pot entrar a aquella sala en particular.

A vegades, per entrar a una sala, ambdues han de coincidir: la teva targeta ha de permetre obrir aquella porta i el teu nom ha d’estar a la llista de la sala.

El cas estrella de les polítiques basades en recurs és l’accés entre comptes (cross-account): quan algú d’un altre compte d’AWS necessita accedir a alguna cosa teva, la política basada en recurs és la que ho permet, perquè s’aplica al recurs sense importar de quin compte vingui qui accedeix.

Quan algú intenta fer alguna cosa, AWS avalua totes les polítiques que apliquen (les d’identitat i les de recurs) amb aquestes regles, en aquest ordre:

1. Per defecte, tot està denegat. Si res no ho permet, es denega.
2. Un Allow explícit concedeix el permís (pot venir de la política d’identitat o de la de recurs).
3. Un Deny explícit SEMPRE guanya. Si qualsevol política diu «denegar», es denega, encara que una altra digui «permetre».

Regla mental: «Deny guanya a Allow, i sense Allow no hi ha permís.» Aquesta regla resol gairebé tots els misteris de permisos a AWS.

Exemple del misteri típic: «Li vaig donar a la Maria permís per llegir el bucket, però no pot.» Possibles causes: hi ha un Deny explícit en algun lloc (que guanya), o la política del recurs (bucket) no l’inclou, o falta l’Allow a la seva identitat. Coneixent la lògica d’avaluació, saps on mirar.

Per acabar, dues formes d’organitzar les polítiques (no confondre amb identitat/recurs):

• Gestionades (managed): polítiques reutilitzables que adjuntes a diverses identitats. AWS n’ofereix moltes de predefinides (com AmazonS3ReadOnlyAccess), i pots crear les teves. Recomanades per ser reutilitzables i fàcils de mantenir.
• En línia (inline): polítiques escrites directament dins d’una sola identitat. Útils per a permisos molt específics d’un únic usuari o rol.

• Una política defineix permisos amb Effect (allow/deny), Action (què) i Resource (sobre què, via ARN).
• Basada en identitat: s’adjunta a un usuari/grup/rol → «què pot fer aquesta identitat?». És el més comú.
• Basada en recurs: s’adjunta al recurs (bucket, cua…) → «qui pot accedir a aquest recurs?». Clau per a l’accés entre comptes.
• Lògica d’avaluació: tot denegat per defecte, un Allow concedeix, i un Deny explícit guanya sempre.
• «Deny guanya a Allow, i sense Allow no hi ha permís» resol la majoria de dubtes.

Al següent subcapítol veurem dos pilars de la seguretat d’accés: l’autenticació multifactor (MFA) i les credencials temporals (STS).