Si només t’emportes una idea de tot el capítol de seguretat, que sigui aquesta: el principi de mínim privilegi. És la regla d’or de la seguretat al núvol (i a tota la informàtica). Entendre’l i aplicar-lo t’estalviarà incidents greus i és el que distingeix un professional d’un principiant descuidat.

El principi de mínim privilegi (least privilege) diu:

Dóna a cada usuari, servei o aplicació NOMÉS els permisos que necessita per fer la seva feina, i ni un més.

Ni més permisos «per comoditat», ni més «per si de cas». Exactament els necessaris, res extra.

Analogia: Imagina un hotel. Al personal de neteja li dónes una targeta que obre les habitacions, però no la caixa forta ni l’oficina del director. Al cuiner, accés a la cuina, però no a les habitacions. Cadascú té accés només al que necessita per la seva feina. No dónes a tothom una clau mestra «per simplificar», perquè seria un risc enorme.

La raó és simple: reduir el dany quan alguna cosa surt malament. I alguna cosa, tard o d’hora, surt malament.

Imagina dos escenaris amb un usuari les credencials del qual són robades per un atacant:

El mínim privilegi limita el radi de l’explosió. Si una credencial es veu compromesa (i passa més del que et penses), l’atacant només pot fer el poc que aquella identitat podia fer.

Exemple real (patró comú): Un desenvolupador puja sense voler les seves claus d’accés a un repositori públic de GitHub. Bots automàtics les detecten en segons i les utilitzen. Si aquelles claus tenien permisos d’administrador, l’atacant llança desenes de servidors caríssims per minar criptomonedes i la víctima rep una factura de milers d’euros. Si les claus tenien permisos mínims (només llegir un bucket), l’atacant no pot fer pràcticament res. El mínim privilegi converteix un desastre en un ensurt.

Aplicar el mínim privilegi és una manera de pensar més que un botó. Aquestes són les pautes:

A AWS, per defecte, tot està denegat fins que ho permets explícitament. Aprofita-ho: parteix de zero i afegeix només els permisos que es demostrin necessaris, en comptes de donar molt i treure després.

No donis permís sobre «tots els buckets» si només se’n necessita un. No donis permís sobre «totes les accions» si només cal llegir.

Malament (massa ampli): «Pot fer qualsevol cosa amb qualsevol bucket de S3.» Bé (mínim): «Pot llegir objectes només del bucket informes-2026.»

Donar AdministratorAccess (permís total) és còmode però perillós. Reserva’l per a les poquíssimes identitats que de veritat ho necessiten. La majoria d’usuaris i serveis necessiten molt menys.

Com vam veure al subcapítol 7.1, dóna a cada servei (una instància EC2, una funció Lambda) un rol amb exactament els permisos que necessita, no més.

Els permisos tendeixen a acumular-se («permission creep»). Revisa’ls periòdicament i treu el que ja no s’utilitzi. AWS té eines (IAM Access Analyzer, que veurem al subcapítol 7.5) que t’indiquen quins permisos s’atorguen però mai s’utilitzen.

Siguem honestos: el mínim privilegi dona més feina que donar permisos amplis. És temptador deixar anar un AdministratorAccess i oblidar-se’n. Però aquest atajo és exactament l’origen de la majoria d’incidents de seguretat greus.

Mentalitat correcta: una mica d’incomoditat ara (configurar permisos ajustats) a canvi d’evitar un desastre després. Els professionals assumeixen aquesta petita fricció com a part normal de la feina ben feta.

Un truc pràctic per trobar l’equilibri: comença amb els permisos que creus que es necessiten, executa l’aplicació, i si falla per falta de permisos, afegeix exactament el que falta. Així arribes al mínim real sense passar-te.

Aquest principi no és només d’IAM; ja l’has vist per tot el llibre:

• Security Groups (Capítol 4): obre només els ports necessaris.
• Subxarxes privades (Capítol 6): no exposis a internet el que no ho necessita.
• Polítiques de bucket S3 (Capítol 5): dóna accés només a qui ho ha de tenir.

És una filosofia transversal de tota la seguretat al núvol.

• Mínim privilegi: dóna a cada identitat només els permisos que necessita, ni un més.
• El seu objectiu és limitar el dany si una credencial es veu compromesa (reduir el «radi d’explosió»).
• A la pràctica: parteix de zero, sigues específic amb accions i recursos, evita permisos d’administrador, fes servir rols per serveis i revisa periòdicament.
• Dona una mica més de feina que donar permisos amplis, però aquest petit esforç prevé desastres.
• És una filosofia transversal: s’aplica també a xarxes, Security Groups i polítiques de S3.

Al següent subcapítol aprofundirem en com s’escriuen els permisos: les polítiques basades en identitat vs en recurs.