S3 guarda les teves dades, però qui pot veure-les o modificar-les? Controlar l'accés als teus buckets és un dels aspectes més crítics de la seguretat al núvol. Les filtracions de dades per buckets mal configurats han estat notícia moltes vegades. En aquest subcapítol aprendràs a controlar qui accedeix a què, i els errors que mai has de cometre.

Bona notícia per començar: per defecte, un bucket nou és completament privat. Només el teu compte pot accedir-hi. Perquè algú més (un altre compte, un servei, o el públic) hi pugui accedir, ho has de concedir explícitament. AWS aplica aquí el principi de «denegar per defecte».

El problema gairebé sempre ve quan algú obre l'accés de més sense voler. Vegem les eines per obrir-lo (amb cura).

Hi ha diverses maneres de gestionar permisos a S3. Les principals:

Una bucket policy és un document (en format JSON) que s'adjunta a un bucket i defineix regles detallades sobre qui pot fer què amb els objectes.

Analogia: És com el reglament d'accés d'un edifici, penjat a l'entrada: «els repartidors poden entrar al magatzem; el públic només a la recepció; ningú entra a les oficines sense targeta».

Una política de bucket especifica, en cada regla:

• Qui (quin compte, usuari o servei, o «tothom»).
• Quina acció (llegir, escriure, esborrar…).
• Sobre quins objectes (tot el bucket o una part).
• Permetre o denegar.

Exemple conceptual d'una política:

Això serviria, per exemple, per a una web estàtica (subcapítol 5.5) on vols que tothom vegi certs fitxers però no d'altres.

Aquí tens un exemple real de bucket policy que permet lectura pública d'una carpeta:

No et preocupis per entendre cada línia ara; ho veurem en detall amb IAM al Capítol 7. L'important: Effect és permetre/denegar, Principal és qui, Action és què pot fer i Resource és sobre què.

Les ACLs (Access Control Lists, llistes de control d'accés) són un mecanisme més antic i simple per donar permisos bàsics a objectes o buckets.

Recomanació d'AWS: evita les ACLs. Avui dia AWS recomana usar polítiques de bucket i IAM en el seu lloc, perquè són més clares i potents. De fet, AWS ara desactiva les ACLs per defecte als buckets nous. Has de saber que existeixen (les veuràs en documentació antiga), però no les facis servir si ho pots evitar.

També pots controlar l'accés des del costat de l'usuari amb polítiques d'IAM (Capítol 7): «aquest usuari pot llegir d'aquests buckets». És complementari a les polítiques de bucket. La diferència: les polítiques de bucket s'adjunten al recurs (el bucket), les d'IAM s'adjunten a la identitat (l'usuari o rol).

AWS va aprendre dels molts incidents de buckets exposats i va crear una protecció extra anomenada Block Public Access (bloquejar l'accés públic).

És un interruptor de seguretat que, quan està activat (ho està per defecte en buckets nous), impedeix que el bucket es faci públic, encara que algú escrigui per error una política que ho permeti. És com un doble segur.

⚠️ Regla d'or: Deixa Block Public Access activat tret que tinguis una raó molt concreta i conscient per desactivar-lo (com allotjar una web pública). I tot i així, valora posar CloudFront davant en lloc d'exposar el bucket directament. Desactivar-lo «per provar» i oblidar-se'n és exactament com passen les filtracions.

Aquests són els errors que han causat filtracions de dades famoses:

1. Fer un bucket públic sense voler. Si poses dades sensibles (dades de clients, còpies de seguretat) en un bucket públic, qualsevol a internet pot descarregar-les. Això ha exposat milions de registres en empreses reals.
2. Desactivar Block Public Access sense necessitat.
3. Donar permisos massa amplis («que qualsevol pugui escriure/esborrar»). Un atacant podria esborrar o segrestar les teves dades.
4. Fer servir ACLs heretades en lloc de polítiques clares.

Cas real (patró repetit): Nombroses empreses han patit filtracions perquè un desenvolupador va deixar un bucket amb dades de clients configurat com a públic «temporalment» i se'n va oblidar. Investigadors de seguretat (i atacants) escanegen internet buscant aquests buckets oberts. La lliçó: tracta cada bucket com a privat per defecte i obre només el que sigui imprescindible.

• Privat per defecte: obre accés només quan sigui estrictament necessari.
• Mínim privilegi: dona els permisos justos, ni un més (concepe clau que veurem al Capítol 7).
• Fes servir polítiques de bucket i IAM, no ACLs.
• Mantén Block Public Access activat tret d'excepció justificada.
• Xifra les dades (S3 xifra en repòs per defecte; ho veurem amb KMS al Capítol 23).
• Per webs públiques, serveix a través de CloudFront en lloc d'exposar el bucket directament.

• Els buckets són privats per defecte; tu concedeixes l'accés explícitament.
• Les polítiques de bucket (JSON) són la forma principal i recomanada de controlar l'accés: defineixen qui, quina acció, sobre què i si es permet o es denega.
• Les ACLs són el mètode antic: evita-les, AWS les desactiva per defecte.
• Block Public Access és una xarxa de seguretat que impedeix exposar el bucket per error: deixa-ho activat.
• L'error més greu i freqüent és fer públic un bucket amb dades sensibles. Privat per defecte, mínim privilegi.

A l'últim subcapítol de S3 veurem un ús molt pràctic i popular: allotjar un lloc web estàtic directament a S3.