A 04-02 vam xifrar les còpies de seguretat de mercadofresco-pedidos amb la clau alias/mercadofresco-datos, i vam dir que KMS registra escrupolosament cada operació criptogràfica. A 04-03 vam desar la contrasenya de mfadmin al secret mercadofresco/produccion/rds/mfadmin i vam dir que cada lectura queda anotada. A 04-01 vam crear el rol rol-mercadofresco-tienda i vam dir que cada AssumeRole deixa rastre.

Cap d'aquestes tres coses no és mentida. Totes estan registrades. I ningú no les ha mirat mai.

Aquest registre es diu AWS CloudTrail, i respon a una pregunta que ni CloudWatch ni X-Ray no poden contestar. CloudWatch sap el que la teva aplicació diu de si mateixa. X-Ray sap per on va passar una petició d'un client. CloudTrail sap qui va cridar l'API d'AWS, quan, des d'on, amb quins paràmetres i amb quin resultat. És la diferència entre saber que la botiga va lenta i saber que algú, a les 03:42 d'un dimarts, des d'una IP d'un país on no tens oficines, va cridar kms:Decrypt sobre la còpia de la base de dades.

Aquesta lliçó munta el trail trail-mercadofresco, ensenya a llegir un esdeveniment real, i contesta per fi la tercera pregunta que va deixar oberta el mòdul 4.

Avís de compliment. Els registres d'auditoria solen tenir requisits legals de conservació. Segons el sector i el país, poden anar de 6 mesos a 10 anys, i en alguns casos han de ser inalterables i estar en custòdia separada. Aquest material és didàctic: les decisions de retenció, immutabilitat i accés als registres d'auditoria d'un sistema real les ha de validar un professional de compliment o l'assessor legal de la teva organització. No les prenguis tu a partir d'un curs.

1. Què registra CloudTrail i què no
2. CloudTrail enfront de CloudWatch Logs
3. L'historial d'esdeveniments de 90 dies, gratuït
4. Crear el trail trail-mercadofresco
5. El bucket que ningú no ha de poder esborrar
6. Validació d'integritat dels fitxers
7. Anatomia d'un esdeveniment: el JSON comentat
8. userIdentity: els sis tipus i com es llegeixen
9. Qui va desxifrar l'última còpia
10. Esdeveniments de gestió enfront d'esdeveniments de dades
11. Esdeveniments d'Insights
12. Trails multiregió i d'organització
13. Enviar el trail a CloudWatch Logs
14. Filtres de mètriques i alarmes de seguretat
15. Consultar amb Athena
16. Les consultes que responen preguntes reals
17. CloudTrail Lake
18. Investigació d'un incident, pas a pas
19. Relació amb IAM Access Analyzer
20. Retenció, cost i neteja

CloudTrail registra crides a l'API d'AWS. Totes. Tant se val que les faci una persona a la consola, la CLI, un SDK, un servei d'AWS actuant en nom teu o una funció Lambda: per sota tot són crides HTTPS signades a les API d'AWS, i CloudTrail les veu totes.

El que no registra:

Aquesta última fila importa: CloudTrail registra que algú va cridar GetSecretValue sobre mercadofresco/produccion/rds/mfadmin, però no registra la contrasenya. Els camps sensibles s'ometen o s'ofusquen per disseny. El mateix amb kms:Decrypt: registra la crida i l'identificador de clau, no el text clar.

I una propietat estructural que cal entendre: CloudTrail sempre està encès. No és una cosa que s'«activa»: els últims 90 dies d'esdeveniments de gestió són disponibles gratis al teu compte des del primer dia, encara que no hagis creat cap trail. El que s'activa és la persistència.

És la confusió número u d'aquest mòdul, i es mereix una taula:

Un cas concret per fixar-ho. Algú esborra el bucket mercadofresco-registros-web:

• CloudWatch Logs: res. La teva aplicació no ha escrit res perquè no ha estat la teva aplicació.
• CloudTrail: un esdeveniment DeleteBucket, amb la identitat que ho va fer, l'hora exacta, la IP d'origen, l'agent d'usuari (aws-cli/2.15.0 o console.amazonaws.com), i si es va fer amb MFA.

I el cas invers. La botiga retorna 500 en confirmar una comanda:

• CloudTrail: res. Ningú no va cridar cap API d'AWS de manera anòmala.
• CloudWatch Logs: la traça completa de l'error.

No competeixen: cobreixen universos diferents.

Abans de crear res, hi ha una cosa que ja funciona:

Els atributs de cerca disponibles són limitats i cal conèixer-los, perquè és el que es pot fer sense infraestructura: EventId, EventName, EventSource, ReadOnly, ResourceName, ResourceType, Username, AccessKeyId.

Les cinc limitacions de l'historial gratuït, que són exactament les raons per crear un trail:

1. Només 90 dies. Una investigació d'un incident detectat tard es queda sense dades.
2. Només esdeveniments de gestió. No hi ha esdeveniments de dades (accessos a objectes d'S3, invocacions de Lambda).
3. Un sol atribut de cerca per consulta. No pots creuar «aquest usuari» i «aquesta acció».
4. No és exportable ni consultable amb SQL. No hi ha anàlisi seriosa possible.
5. No és immutable ni verificable. No serveix com a prova en una auditoria formal.

Un trail persisteix els esdeveniments en un bucket d'S3, indefinidament, i permet tot l'anterior.

Pas 1: el bucket dedicat.

Aquest BucketKeyEnabled: true no és cosmètic: redueix fins a un 99 % les crides a KMS —i el seu cost— quan s'escriuen milers d'objectes petits, que és exactament el que fa CloudTrail. Ho vam veure a 04-02.

Pas 2: la política del bucket. CloudTrail necessita permís per escriure:

Les condicions aws:SourceArn són importants i no sempre s'hi posen: sense elles, en teoria un trail d'un altre compte podria escriure al teu bucket (el confused deputy que vam veure a 04-01).

Pas 3: el trail.

L'error de l'any: create-trail crea el trail però no comença a registrar. Cal cridar start-logging. Hi ha comptes amb trails creats fa anys que mai no han gravat una línia. Comprova-ho sempre:

Les quatre banderes de la comanda, explicades:

La primera és la més important des del punt de vista de seguretat. Un trail d'una sola regió és una càmera que només enfoca la porta principal.

Un registre d'auditoria que l'atacant pot esborrar no és un registre d'auditoria. És la primera cosa que fa qualsevol que sap el que fa: entrar, esborrar el rastre, seguir.

Hi ha quatre nivells de protecció, i convé entendre què protegeix cadascun:

Nivell 3, Object Lock, és el que de debò tanca la porta:

Els dos modes, i la diferència és enorme:

Aquests 2.555 dies són 7 anys. I aquí hi ha el perill: amb COMPLIANCE, cada objecte que CloudTrail escrigui serà inesborrable durant set anys, i el pagaràs durant set anys. Si t'equivoques de valor, no hi ha marxa enrere.

Aquesta és exactament la decisió que ha de validar un professional de compliment. El període de retenció dels registres d'auditoria depèn del teu sector, el teu país i les teves obligacions contractuals. No el triïs per intuïció, i no copiïs el 2555 d'aquest curs.

Nivell 2, MFA Delete, només el pot activar el compte arrel amb un dispositiu MFA, i per això no encaixa amb el principi de 04-01 de no usar l'arrel. MercadoFresco no el fa servir; usa Object Lock.

Nivell 4, compte separat, és la resposta professional completa: el bucket d'auditoria viu en un compte de registre diferent, al qual el compte de producció només pot escriure. Encara que algú comprometi del tot 111122223333, els registres queden fora del seu abast. Requereix AWS Organizations, que és la lliçó 09-04. MercadoFresco ho té anotat com el pas següent.

I una defensa complementària que es munta avui mateix: una alarma que avisi si algú atura o esborra el trail. És a la secció de filtres de mètriques.

Amb --enable-log-file-validation, CloudTrail fa una cosa elegant: cada hora publica un fitxer de resum (digest) que conté el hash SHA-256 de cada fitxer de registre d'aquella hora, més el hash del resum anterior. És una cadena: cada resum signa l'anterior.

Conseqüència pràctica: no es pot alterar un fitxer de registre, ni esborrar-lo, ni substituir un resum, sense trencar la cadena. Els resums estan signats amb la clau privada de CloudTrail, així que tampoc no es poden regenerar.

La verificació:

Una sortida sana acaba amb Results requested for ... Results found for N digest files ... All files verified. Qualsevol menció a fitxers modificats o absents és una troballa de seguretat immediata.

La Marta l'executa el primer dilluns de cada mes i desa la sortida. En una auditoria formal, aquesta sortida és el que demostra que els registres no s'han tocat.

Aquest és un esdeveniment real de kms:Decrypt, que és exactament el que buscàvem. Comentat camp a camp:

Lectura camp a camp del que aquest esdeveniment ens està dient:

Tres camps mereixen comentari a part:

• responseElements és null en les operacions de només lectura. En una operació d'escriptura —CreateBucket, RunInstances— conté el que va retornar l'API: l'ID del recurs creat. És el camp que et diu què es va crear.
• errorCode i errorMessage apareixen només quan la crida va fallar. AccessDenied, UnauthorizedOperation, Client.InvalidParameterValue. Que CloudTrail registri també les crides que fallen és una de les seves propietats més valuoses: un atacant provant portes deixa un reguer d'AccessDenied que és el senyal més net de reconeixement.
• encryptionContext és el que a 04-02 vam explicar com les «dades addicionals autenticades» del xifratge de sobre. Aquí es veu el seu valor de debò: és el que converteix un esdeveniment genèric de Decrypt en «algú va desxifrar la còpia del 27 de juliol de mercadofresco-pedidos». Sense ell, l'esdeveniment només diria que es va fer servir una clau.

El camp userIdentity és on viu la resposta a «qui?», i té sis formes diferents:

El més habitual, i el més confús, és AssumedRole. La instància EC2 de MercadoFresco no apareix com a «instància»: apareix com el rol rol-mercadofresco-tienda amb un nom de sessió que és l'ID de la instància. I quan la Marta assumeix un rol des del seu usuari, apareix com el rol amb el nom de sessió que ella va triar.

D'aquí surt una de les pràctiques més útils de tot aquest mòdul: si a AssumeRole no hi poses un nom de sessió identificatiu, CloudTrail et dirà «algú amb el rol d'administració va esborrar el bucket» i no podràs saber qui. Amb --role-session-name marta.costa sí:

A 04-01 vam introduir això de passada. Aquí es veu per què importa: el nom de sessió és el que converteix un rol compartit en una persona identificable. Amb AWS IAM Identity Center això es fa sol, amb el correu de l'usuari federat com a nom de sessió.

I una nota sobre AWSService. Molts esdeveniments legítims tenen invokedBy amb valors com autoscaling.amazonaws.com o dlm.amazonaws.com. Són AWS actuant en nom teu: l'ASG llançant una instància, DLM creant una instantània (02-02). No són alertes; són el sistema funcionant. Filtrar-los correctament és la meitat de la feina de reduir el soroll en una investigació.

Ara sí, la resposta a la pregunta del mòdul 4. La consulta directa contra l'historial de 90 dies:

Sortida real:

Tres línies i tres lectures completament diferents:

1. rds-backup-service a les 03:00: és el mateix RDS xifrant la còpia automàtica. Normal, és la finestra de còpia que vam configurar a 02-04.
2. rol-mercadofresco-tienda des de 10.0.11.24: una instància de l'ASG, IP privada de la subxarxa d'aplicació (03-01), desxifrant dades de l'aplicació. Normal.
3. rol-restauracion-copias a les 03:42, des de 198.51.100.77, sense MFA, sobre la còpia snapshot-2026-07-27: això s'ha d'investigar.

I les preguntes que se'n deriven, en aquest ordre:

• És 198.51.100.77 una IP coneguda? L'oficina? La VPN? El domicili d'algú?
• Qui va assumir rol-restauracion-copias? El nom de sessió diu sesion-marta-copias, però això és una cadena que va triar qui va fer la crida, no una identitat verificada. Cal buscar l'esdeveniment AssumeRole corresponent per veure qui el va assumir de debò.
• Hi ha un esdeveniment RestoreDBInstanceFromDBSnapshot a prop? Es va restaurar la còpia en algun lloc?
• Hi va haver un AccessDenied abans, senyal de temptejar?

Això no és una resposta, és el principi d'una investigació. I aquesta és precisament la lliçó: CloudTrail no diu si alguna cosa va malament. Diu què va passar, amb prou precisió perquè una persona decideixi. La investigació completa és més avall.

És la distinció que decideix la factura de CloudTrail:

El càlcul que cal fer abans d'activar esdeveniments de dades a S3. MercadoFresco serveix unes 40 milions de peticions al mes a mercadofresco-catalogo-fotos (fotos de producte, encara que CloudFront en guarda la majoria a la memòria cau). Registrar-les totes:

40.000.000 × 0,10 / 100.000 = 40 USD/mes, més l'emmagatzematge a S3 d'un volum enorme de JSON, més el que costi consultar-ho amb Athena.

I no aporta gairebé res: són lectures públiques de fotos de tomàquets.

La regla és: activa esdeveniments de dades amb selectors d'abast mínim, només sobre el que importa.

El que aconsegueix aquesta configuració:

De 40 USD a 0,06 USD sense perdre res rellevant. Aquest readOnly: false sobre el catàleg és la decisió clau: llegir una foto de tomàquet no interessa a ningú; que algú pugi o esborri una foto sí, perquè és una modificació del contingut del lloc.

Els tipus de recurs disponibles per a esdeveniments de dades inclouen AWS::S3::Object, AWS::Lambda::Function, AWS::DynamoDB::Table (mòdul 6), AWS::SQS::Queue (07-01) i uns quants més.

CloudTrail Insights analitza el volum de crides i detecta pics anòmals d'activitat d'escriptura o d'errors. No mira el contingut: mira el ritme.

Casos que detecta bé:

• Un script mal escrit que crida DescribeInstances 40.000 vegades en una hora.
• Un augment sobtat d'AccessDenied: algú provant permisos.
• Un pic de TerminateInstances a les 4 de la matinada.

Cost: 0,35 USD per cada 100.000 esdeveniments de gestió analitzats. Amb ~150.000 esdeveniments mensuals, MercadoFresco paga uns 0,53 USD/mes. És de les coses més barates d'aquest mòdul i de les que avisa més aviat.

Les dues limitacions honestes: necessita almenys 7 dies de línia base abans de servir per a res, i només detecta anomalies de volum, no d'intenció. Una sola crida maliciosa perfectament executada no genera cap insight. Per a això hi ha les alarmes específiques de la secció següent.

Multiregió ja ho vam activar amb --is-multi-region-trail, i val la pena insistir en per què. Un trail d'una sola regió és com una càmera de seguretat que només enfoca la porta principal: un atacant que aconsegueixi credencials crearà les seves instàncies de mineria a ap-southeast-2, on ningú no mira mai. Amb el trail multiregió, aquestes crides apareixen al mateix bucket.

Cost de la multiregió: zero. La primera còpia dels esdeveniments de gestió és gratuïta a totes les regions. No hi ha cap raó per no activar-la.

Trail d'organització: si tens diversos comptes sota AWS Organizations, un sol trail creat al compte de gestió registra tots els comptes membre, i aquests no el poden desactivar ni veure. És la configuració correcta per a qualsevol organització amb més d'un compte, i és la lliçó 09-04. MercadoFresco té un sol compte avui; la separació entre producció, preproducció i registre és un objectiu declarat.

El bucket d'S3 és l'arxiu. Per reaccionar en calent cal que els esdeveniments arribin també a CloudWatch Logs, on poden convertir-se en mètriques i alarmes (05-01).

Fixa-t'hi: 90 dies a CloudWatch Logs, 7 anys a S3. Els dos destins tenen propòsits diferents i retencions diferents. Logs és per alarmar i consultar el que és recent; S3 és l'arxiu legal. Duplicar 7 anys a CloudWatch Logs costaria una fortuna sense aportar res.

El rol que CloudTrail necessita:

Amb la política de permisos:

Cost: la ingesta dels esdeveniments de gestió de MercadoFresco són uns 0,4 GB al mes: 0,25 USD. Si activessis esdeveniments de dades d'alt volum, això es dispararia; és una altra raó per als selectors restrictius.

Aquí és on CloudTrail i CloudWatch es troben i es converteixen en detecció, no només en registre. Aquestes són les cinc alarmes que munta MercadoFresco, i les cinc són estàndard en qualsevol auditoria de seguretat (apareixen al CIS Benchmark d'AWS, que veurem a 05-04).

1. Ús del compte arrel. Després de 04-01, l'arrel no s'hauria de fer servir mai:

Aquest $.userIdentity.invokedBy NOT EXISTS exclou els esdeveniments en què un servei d'AWS actua en nom del compte, que són legítims i freqüents. Sense ell, l'alarma seria pur soroll.

2. Aturada o esborrat d'un trail. La primera acció de qualsevol que vulgui amagar el seu rastre:

Amb la seva alarma amb llindar 0, exactament igual que l'anterior. Aquesta és l'alarma més important d'aquesta lliçó: és la que avisa que el sistema d'auditoria està sent atacat.

3. Ús de KMS sobre les còpies de la base de dades. La que respon directament a la pregunta del mòdul 4, però en calent:

Aquest $.userIdentity.type != "AWSService" exclou el mateix RDS xifrant les seves còpies automàtiques cada nit, que és la línia 1 de la nostra investigació. El que queda és activitat humana o d'script sobre una còpia de la base de dades, i això sempre mereix un avís.

4. Accessos denegats repetits. El reguer que deixa el reconeixement:

Aquí el llindar no és 0, i la raó és honesta: els AccessDenied són constants en qualsevol compte viu. Un desenvolupador provant, una eina que consulta alguna cosa que no pot, un SDK que sondeja. 20 en cinc minuts sostinguts durant dos períodes sí que és un senyal.

5. Canvis en la política d'un grup de seguretat o a IAM.

Amb llindar 0 en horari nocturn seria massa sorollós durant un desplegament diürn. MercadoFresco el posa a llindar 0 amb període de 5 minuts, acceptant el soroll: prefereix assabentar-se de tots els canvis de seguretat. Que l'alarma sigui informativa i no urgent és una decisió vàlida, sempre que estigui documentada i no acabi sent ignorada per costum.

Per investigar de debò cal consultar els fitxers d'S3 amb SQL. Amazon Athena executa SQL directament sobre els objectes d'un bucket, sense carregar res en cap base de dades.

Athena es veu amb més profunditat al mòdul 6 quan es parla d'analítica. Aquí en fem servir el just per investigar CloudTrail, que és el seu cas d'ús més comú.

Pas 1: la taula. La manera còmoda de crear-la és des de la consola de CloudTrail («Create Athena table»), que genera aquest DDL. Convé entendre'l:

Dues coses que cal veure en aquest DDL:

• requestParameters i responseElements són STRING, no estructures. El seu contingut varia segons l'esdeveniment, així que es consulten amb funcions JSON: json_extract_scalar(requestParameters, '$.keyId').
• PARTITIONED BY és el que decideix el cost. Athena cobra 5 USD per TB escanejat. Sense particions, cada consulta llegeix tots els fitxers del bucket. Amb particions i un WHERE sobre elles, llegeix només els dies que demanis.

Pas 2: registrar les particions. Amb la projecció de particions s'automatitza:

Sense això caldria executar MSCK REPAIR TABLE o ALTER TABLE ADD PARTITION cada dia. Amb la projecció, Athena dedueix les particions del patró de rutes.

1. Qui va assumir rol-mercadofresco-tienda, i quan?

2. Qui va llegir el secret de mfadmin? La pregunta que vam deixar pendent a 04-03:

El que s'espera en el resultat: el rol de la botiga llegint-lo en arrencar cada instància, i rol-rotacion-mfadmin cada 30 dies fent la rotació (04-03). Qualsevol altra identitat és una troballa.

3. Totes les crides denegades, agrupades. La consulta de reconeixement:

Aquesta consulta té un ús doble molt valuós, i convé subratllar-ho:

• Seguretat: una identitat desconeguda amb 400 AccessDenied sobre 30 serveis diferents en deu minuts és reconeixement. Algú està mapant el que pot fer.
• Operació: rol-mercadofresco-tienda amb 3.000 AccessDenied sobre s3:GetObject significa que a pol-mercadofresco-tienda li falta un permís i hi ha una funcionalitat trencada que ningú no ha reportat. Els AccessDenied són també un detector d'errors de configuració.

4. Activitat fora d'horari, que és la que sol delatar.

Filtrar userIdentity.type != 'AWSService' és imprescindible: si no, la sortida s'omple de còpies automàtiques, instantànies de DLM i activitat de l'ASG a les 3 de la matinada, que és completament normal.

5. Totes les IP d'origen, per detectar les desconegudes.

Una IP que apareix per primer cop, fa 12 crides i desapareix és molt més sospitosa que una que en fa 40.000 des de fa mesos.

6. La consulta de la còpia desxifrada, ara en SQL.

Control de cost a Athena: cada consulta cobra per TB escanejat. Posar sempre el WHERE de partició (anio, mes, dia) és la diferència entre 0,01 USD i uns quants euros per consulta. I es pot fixar un límit dur per grup de treball:

Deu GiB màxim per consulta. Si algú escriu un SELECT * sense WHERE, la consulta es cancel·la sola en lloc de generar una factura.

CloudTrail Lake és l'alternativa gestionada a muntar Athena a mà: un magatzem d'esdeveniments gestionat per AWS, amb SQL directe des de la consola de CloudTrail i sense taules per crear.

La decisió de MercadoFresco: es queda amb S3 + Athena. Amb 0,4 GB mensuals d'esdeveniments, Lake costaria 1 USD al mes d'ingesta —no és dramàtic— però el bucket d'S3 ja existeix, ja està protegit amb Object Lock i ja alimenta l'arxiu legal de 7 anys. Lake s'anota com a opció a reconsiderar si el compte creix i muntar particions a mà comença a fer mal.

Amb molts comptes i equips que no són de plataforma, Lake guanya clarament: ningú no ha d'aprendre a crear taules externes a Athena per investigar un incident.

Tornem a la troballa: rol-restauracion-copias va desxifrar la còpia snapshot-2026-07-27 a les 03:42 des de 198.51.100.77, sense MFA. Aquest és el procediment complet, i serveix com a plantilla per a qualsevol investigació.

Pas 0. Congelar l'evidència. Abans de res.

Això es fa primer i sempre. Si l'incident acaba en un procediment formal, el que importa no és el que vas descobrir, sinó que puguis demostrar que les dades no van canviar mentre investigaves.

Pas 1. Qui va assumir el rol? El nom de sessió sesion-marta-copias és text lliure triat per qui va fer la crida. Cal buscar l'AssumeRole:

Resultat: arn:aws:iam::111122223333:user/luis.dev, a les 03:41:52, des de 198.51.100.77, mfaAuthenticated: false, agent aws-cli/2.15.30.

Pas 2. Reconstruir tota la sessió. L'accessKeyId temporal (ASIA...) identifica la sessió completa:

Resultat:

Pas 3. Interpretar. El patró és coherent i força llegible: algú va restaurar una còpia, va intentar crear una instantània nova (denegat), i al cap de 45 minuts va esborrar la instància restaurada. No hi ha exfiltració visible —cap crida a S3, cap CreateDBSnapshot amb èxit, cap instància deixada en marxa—. Sembla feina legítima feta malament: restaurar una còpia per comprovar alguna cosa, de matinada, sense avisar i sense MFA.

Pas 4. Confirmar amb la persona. I aquí una advertència important, perquè és on més s'equivoca la gent: CloudTrail diu què va passar, no per què. No s'acusa mai ningú amb un registre a la mà sense parlar-hi primer. La conversa amb el Luis aclareix que estava comprovant si una còpia era restaurable després d'un avís de la Sara, i que ho va fer de matinada per no carregar la base de dades en hores de producció. Intenció correcta, procediment incorrecte.

Pas 5. Comprovar que no hi ha res més. Encara que l'explicació quadri, es verifica:

Si aquesta IP només apareix en horari de feina del Luis durant mesos, és casa seva o la seva oficina. Si apareix una vegada, a les 3 de la matinada, i mai més, la conversa és una altra.

Pas 6. Accions correctives. Sense culpables i amb dates, igual que el post-mortem de 04-04:

Fixa't en l'última fila i en l'anterior: la resposta correcta a «el Luis va restaurar una còpia d'amagat» no és prohibir-ho. És fer que provar restauracions sigui fàcil, visible i rutinari. Una prova de restauració és una pràctica excel·lent que a 02-04 vam recomanar explícitament; el problema era el procediment, no l'activitat.

CloudTrail no només serveix per investigar: serveix per construir permisos correctes. IAM Access Analyzer pot llegir el teu historial de CloudTrail i generar una política de privilegi mínim amb exactament les accions que una identitat ha fet servir de debò en un període.

Això tanca el cercle amb 04-01. Allà vam escriure pol-mercadofresco-tienda a mà, raonant sobre què havia de poder fer la botiga. Amb dos mesos de CloudTrail, Access Analyzer diu què va fer de debò, i la diferència entre les dues llistes és un regal:

• Accions que són a la política i no es fan servir mai: candidates a treure.
• Accions que l'aplicació intenta i li són denegades: funcionalitat trencada que ningú no va reportar.

Access Analyzer fa més coses —detectar recursos accessibles des de fora del compte, validar polítiques— però aquesta és la seva relació directa amb CloudTrail i amb el que vam aprendre a 04-01.

És de les coses més barates que es poden muntar a AWS, i l'argument definitiu: la primera còpia dels esdeveniments de gestió multiregió és gratuïta. No hi ha cap excusa tècnica ni econòmica per no tenir un trail. Que un compte de producció no en tingui és sempre una troballa d'auditoria.

Cicle de vida a S3, perquè els 7 anys no es paguin a preu d'emmagatzematge estàndard:

Compte amb dues coses: DEEP_ARCHIVE triga fins a 12 hores a restaurar, cosa que pot ser inacceptable en una investigació urgent —per això els dos primers anys es queden en classes d'accés ràpid—, i si has activat Object Lock en mode COMPLIANCE, la regla de cicle de vida no pot expirar objectes abans que venci la retenció. Els pot canviar de classe, no esborrar-los.

Neteja, si has muntat això només per practicar:

El bucket no s'esborra a la lleugera. Si vas activar Object Lock en mode COMPLIANCE, els objectes no es poden esborrar fins que venci la retenció —ni tu, ni el compte arrel, ni el suport d'AWS—, i el bucket no es pot eliminar mentre contingui objectes. És una propietat desitjada, no una fallada. Practica Object Lock en un compte de proves i amb retencions de dies, mai d'anys.

1. Crear el trail i no cridar start-logging. create-trail no arrenca el registre. Comprova sempre amb get-trail-status que IsLogging és true.

2. Trail d'una sola regió. Un atacant crea recursos on ningú no mira. La multiregió és gratis i no té contrapartida.

3. Un bucket d'auditoria que es pot esborrar. Sense política de Deny, sense versionat i sense Object Lock, el registre dura el que trigui algú a executar una comanda. I el nivell definitiu és un compte separat (09-04).

4. Activar esdeveniments de dades sense selectors. Registrar tots els GetObject d'un bucket de fotos són desenes d'USD al mes per dades inútils. Selectors per prefix i readOnly: false.

5. No posar nom de sessió en assumir un rol. CloudTrail dirà «algú amb aquest rol», i no hi haurà manera de saber qui. --role-session-name amb el nom de la persona.

6. Buscar a CloudTrail el que diu la teva aplicació. No hi és. CloudTrail registra crides a l'API d'AWS; els errors del teu codi són a CloudWatch Logs (05-01).

7. Consultes d'Athena sense WHERE de partició. Escanegen el bucket sencer a 5 USD per TB. Posa sempre anio, mes i dia, i fixa BytesScannedCutoffPerQuery al grup de treball.

8. Ignorar els AccessDenied. Són alhora el detector de reconeixement i el detector de permisos mal configurats. Revisar-los setmanalment troba coses trencades que ningú no va reportar.

9. No verificar mai la integritat. validate-logs un cop al mes, amb la sortida desada. Sense això, la validació està activada però no serveix de res.

10. Retenció infinita a CloudWatch Logs per als esdeveniments de CloudTrail. L'arxiu llarg va a S3, que costa 20 vegades menys. A Logs, 90 dies.

11. Acusar algú amb un registre a la mà. CloudTrail diu què va passar, no per què. Cal investigar, contrastar i després parlar amb la persona. Un incident mal gestionat fa més mal que l'incident.

12. Activar Object Lock en mode COMPLIANCE amb 7 anys «per provar». No hi ha marxa enrere. Practica amb GOVERNANCE i amb retencions de dies.

13. Suposar que el nom de sessió identifica algú. És una cadena lliure. La identitat real és a l'esdeveniment AssumeRole corresponent.

Consell final: revisa CloudTrail quan no hi ha incidents. Mitja hora al mes executant les consultes d'IP desconegudes, AccessDenied agrupats i activitat fora d'horari troba coses —permisos trencats, processos zombis, claus oblidades d'un antic proveïdor— que d'altra manera només apareixen el dia que hi ha un problema de debò.

Els tres exercicis treballen sobre la taula auditoria_mercadofresco.cloudtrail_mercadofresco i el trail trail-mercadofresco definits en aquesta lliçó.

MercadoFresco vol activar esdeveniments de dades, però amb criteri i amb un pressupost de 5 USD al mes. Volum mensual real:

Requisits: cal poder saber sempre qui ha llegit o tocat una còpia de la base de dades; cal detectar si algú descarrega massivament els informes de negoci; cal detectar si algú altera les fotos del catàleg; el pressupost és de 5 USD.

Escriu els selectors avançats complets en JSON, calcula el cost de cadascun, justifica què deixes fora i per què, i proposa quina alarma muntaries sobre els esdeveniments de dades que sí que registres.

Un dilluns al matí, l'alarma mercadofresco-accesos-denegados ha saltat dues vegades durant el cap de setmana. Aquestes són les dades inicials:

• Dissabte 02:14 a 02:31: 340 esdeveniments amb errorCode = AccessDenied.
• Tots des de sourceIPAddress = 203.0.113.201.
• Tots amb userIdentity.type = "IAMUser", userName = "integracion-proveedor".
• userAgent: aws-cli/2.9.19 Python/3.9.11 Windows/10.
• Els serveis afectats: iam, s3, ec2, rds, secretsmanager, kms, organizations.
• Diumenge 22:40: 6 esdeveniments sense errorCode des de la mateixa IP i el mateix usuari: ListBuckets, GetBucketLocation, ListObjectsV2 sobre mercadofresco-informes-analitica, GetObject × 3.

Escriu: les consultes SQL exactes que executaries i en quin ordre; quina conclusió treus de cadascuna; quines accions de contenció prendries i en quin ordre exacte; i què et diu el fet que les 340 crides fallessin però 6 tinguessin èxit. Indica també quina informació no podràs obtenir de CloudTrail i on la buscaries.

La Marta vol passar d'investigar després a detectar en el moment. Defineix cinc deteccions addicionals a les cinc alarmes de la lliçó, orientades al risc real de MercadoFresco:

1. Algú crea una clau d'accés permanent per a un usuari IAM (després de 04-01, ningú no ho hauria de fer).
2. Algú modifica la política de la clau alias/mercadofresco-datos.
3. Un rol d'aplicació es fa servir des d'una IP fora de la VPC.
4. Algú desactiva el xifratge d'un bucket o activa l'accés públic.
5. Es crea un recurs en una regió que MercadoFresco no fa servir.

Per a cadascuna: escriu el patró del filtre de mètriques, decideix el llindar i els períodes de l'alarma, digues si ha de despertar algú de matinada o només generar un correu, i explica quin fals positiu esperes i com l'evitaries. Per a les que no es puguin resoldre amb un filtre de mètriques, indica quina eina faries servir (i avança quina serà la lliçó que la cobreixi).

Solució 1

Càlcul de partida. Registrar-ho tot:

Deu vegades el pressupost, i amb el 97 % de la despesa en lectures de fotos de tomàquets.

Selectors proposats:

Cost resultant:

Molt per sota dels 5 USD i complint els tres requisits.

Què queda fora i per què:

• Lectures del catàleg (40 M): són fotos públiques de producte servides per CloudFront. Llegir-les no té cap valor de seguretat i costa 40 USD. Si algun dia calgués analitzar patrons d'accés, hi ha els registres d'accés d'S3 i els de CloudFront, molt més barats.
• mercadofresco-registros-web (8 M): és l'ALB escrivint els seus propis registres. Registrar que l'ALB escriu els seus registres és recursiu i inútil: 8 USD per confirmar el que ja sabem.
• Invocacions de Lambda (1,28 M): 1,28 USD, i ja tenim millor visibilitat d'aquestes funcions amb les mètriques d'AWS/Lambda, els seus registres i les traces d'X-Ray (05-02). CloudTrail només diria «es va invocar», que és el menys informatiu de tot.

Alarmes sobre els esdeveniments de dades que sí que registrem:

Amb llindar 0: ningú no té per què descarregar una còpia de la base de dades sense que algú se n'assabenti.

Aquí el llindar no pot ser 0: la Sara llegeix informes cada dia, és la seva feina. 500 objectes en cinc minuts no és llegir un informe, és descarregar-se el magatzem sencer.

Aquest últim és el patró més valuós dels tres: llista blanca d'identitats esperades, alarma sobre tota la resta. És més robust que enumerar el que és dolent, perquè cobreix també el que no has previst.

Solució 2

Lectura inicial de les dades. Tres senyals molt clars, abans d'executar cap consulta:

1. 340 AccessDenied en 17 minuts sobre 7 serveis diferents, incloent-hi iam i organizations. Això no és una aplicació amb un permís mal posat: una aplicació falla sempre a la mateixa crida. Això és enumeració sistemàtica de permisos.
2. IAMUser amb clau permanent, exactament el que 04-01 diu que no ha d'existir. Un usuari d'«integració amb proveïdor» és el vector clàssic: clau que es va crear una vegada, es va posar en un fitxer de configuració, i que ningú no ha rotat en tres anys.
3. 20 hores de silenci i després 6 crides amb èxit, quirúrgiques, sobre els informes de negoci. Aquest espaiat és el patró: primer es mapa què es pot fer, després es torna a buscar el que funciona.

Consulta 1: tota l'activitat d'aquest usuari, no només la del cap de setmana.

Què busco: quan va començar tot, si aquella IP havia aparegut abans, i què feia aquest usuari normalment. Si la seva activitat legítima és un PutObject diari a les 06:00 des d'una altra IP, tot el del cap de setmana és intrusió.

Consulta 2: què va tenir èxit. És l'únic que importa de debò.

Què busco: l'abast exacte de la bretxa. Els 340 errors són soroll; els 6 èxits són l'incident. Aquí surt quins tres objectes concrets es van descarregar de mercadofresco-informes-analitica, i això determina si hi ha dades personals implicades i si hi ha obligació de notificar.

Consulta 3: la clau d'accés, per veure si es va fer servir des de més llocs.

Què busco: si la clau es fa servir també des de la IP legítima del proveïdor, està compromesa però segueix en ús legítim, i desactivar-la trencarà una integració. Si només es fa servir des de 203.0.113.201 des de fa un mes, el proveïdor ja no la fa servir i desactivar-la no trenca res.

Consulta 4: d'on va sortir aquesta clau i quan.

Què busco: si la clau es va crear fa dos anys i mai no es va rotar, o si es va crear el divendres passat, cas en què el compromís és més profund: algú ja tenia accés i es va obrir una porta del darrere.

Consulta 5: correlació per IP, més enllà d'aquest usuari.

Què busco: si aquesta IP ha fet servir altres identitats, l'abast és molt més gran.

Contenció, en aquest ordre exacte:

Què significa que 340 fallessin i 6 tinguessin èxit. És la millor notícia possible: el privilegi mínim va funcionar. La feina de 04-01 és el que va impedir que aquelles 340 crides —a IAM, a KMS, a Secrets Manager, a RDS, a Organizations— fessin mal. La bretxa es va limitar als permisos que aquell usuari tenia legítimament, que era llegir informes.

I alhora és la pitjor notícia sobre el disseny: aquell usuari mai no hauria d'haver tingut una clau permanent. L'accés d'un proveïdor s'ha de fer amb un rol assumible amb condició d'identitat externa (sts:ExternalId, 04-01), amb credencials temporals que caduquen soles. Aquest és l'arranjament de fons.

El que CloudTrail NO et pot dir:

Aquesta taula és la lliçó més important de l'exercici: CloudTrail és una peça de la investigació, no la investigació sencera. Dona el «qui, què, quan, des d'on» del pla de control d'AWS. Tota la resta és en altres fonts, i per això aquest mòdul sencer té sentit com a conjunt.

Solució 3

Detecció 1: creació de clau d'accés permanent.

Detecció 2: canvi en la política de la clau KMS.

Val la pena subratllar-ho: a 04-02 vam veure que esborrar una clau KMS té un període d'espera de 7 a 30 dies precisament per donar temps a reaccionar. Aquesta alarma és el que converteix aquell període d'espera en una defensa real: sense ella, l'espera passa sense que ningú se n'assabenti.

Detecció 3: rol d'aplicació fet servir des de fora de la VPC.

Un filtre de mètriques no pot fer això bé. La sintaxi de patrons de CloudWatch Logs no admet comparacions de rang d'IP ni negació de prefixos de manera fiable. Es pot aproximar:

…però és fràgil i generarà falsos positius, perquè les crides a través d'un punt d'enllaç de VPC (vpce-mercadofresco-s3) o des de certs serveis apareixen amb altres adreces.

L'eina correcta és una altra, i aquí cal ser honest:

• Amazon GuardDuty té una troballa específica per a això: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration, que detecta credencials de rol d'instància usades des de fora d'AWS. És exactament aquest cas i funciona sense configuració.
• Alternativament, una condició a la política de confiança del rol amb aws:SourceVpc, que directament impedeix l'ús des de fora en lloc de detectar-lo. Prevenir és millor que detectar (04-01).

GuardDuty i Security Hub es veuen en visió general a 05-04.

Detecció 4: xifratge desactivat o accés públic en un bucket.

Però aquesta detecció té un límit seriós: només detecta el canvi, no l'estat. Si el xifratge ja estava desactivat des d'abans de crear l'alarma, mai no saltarà. I no ho pot corregir.

Per a això existeix una eina específica, que és la lliçó següent: AWS Config. Config avalua l'estat actual de tots els recursos contra regles, detecta les desviacions existents —no només les noves— i les pot corregir automàticament. És exactament la cinquena pregunta que va deixar oberta el mòdul 4.

Detecció 5: recurs creat en una regió no utilitzada.

Aquesta detecció depèn completament que el trail sigui multiregió. Sense --is-multi-region-trail no veuries absolutament res, i és l'argument definitiu per activar-lo.

I la prevenció, millor que la detecció: una política de control de serveis (SCP) que denegui tot fora de les regions permeses. Requereix Organizations: 09-04.

Resum de les cinc:

La conclusió de l'exercici: CloudTrail detecta esdeveniments, no estats. És perfecte per a «algú ha fet X», i insuficient per a «el bucket Y està mal configurat des de fa tres mesos». Aquesta segona pregunta necessita una altra eina, i és la lliçó següent.

MercadoFresco ja sap qui va fer què. Tens clara la diferència essencial que defineix aquest servei: CloudTrail registra crides a l'API d'AWS; CloudWatch Logs registra el que diu la teva aplicació. L'un respon «qui va esborrar el bucket?», l'altre «per què va fallar el pagament?». No competeixen: cobreixen universos diferents, i buscar en el que no toca costa hores.

Saps que l'historial d'esdeveniments de 90 dies sempre hi és, gratis, i coneixes les seves cinc limitacions —90 dies, només gestió, un atribut per cerca, sense SQL, sense immutabilitat— que són exactament les raons per crear un trail. Has creat trail-mercadofresco amb les quatre banderes que importen: multiregió (gratis, i sense ella un atacant crea recursos on ningú no mira), esdeveniments globals, validació d'integritat i xifratge amb alias/mercadofresco-datos. I saps que create-trail no arrenca el registre: cal cridar start-logging i comprovar-ho amb get-trail-status.

Has muntat el bucket mercadofresco-auditoria-cloudtrail amb les quatre capes de protecció —política amb Deny d'esborrat, versionat, Object Lock en mode COMPLIANCE que ni el compte arrel no pot saltar-se, i el compte separat com a pas pendent de 09-04— perquè un registre d'auditoria que l'atacant pot esborrar no és un registre d'auditoria. I coneixes la cadena de resums signats que fa impossible alterar un fitxer sense trencar-la, amb validate-logs executat el primer dilluns de cada mes.

Saps llegir un esdeveniment complet: eventTime, eventSource, eventName, sourceIPAddress, userAgent, requestParameters, responseElements (nul en les lectures) i errorCode, que només apareix quan la crida falla —i que és una de les propietats més valuoses de CloudTrail, perquè un atacant provant portes deixa un reguer d'AccessDenied—. Domines els sis tipus de userIdentity, amb AssumedRole com el més freqüent i el més confús, i saps que el nom de sessió és l'única cosa que converteix un rol compartit en una persona identificable, i que és text lliure: la identitat real és a l'AssumeRole corresponent.

I has respost la tercera pregunta del mòdul 4. Qui va desxifrar l'última còpia: tres esdeveniments de Decrypt, dos de normals —RDS xifrant la seva còpia automàtica i una instància de l'ASG des de 10.0.11.24— i un que no ho era: rol-restauracion-copias, a les 03:42, des de 198.51.100.77, sense MFA, sobre snapshot-2026-07-27. Gràcies a l'encryptionContext de 04-02, que és el que converteix un esdeveniment genèric de KMS en «algú va desxifrar la còpia del 27 de juliol de mercadofresco-pedidos».

Saps distingir esdeveniments de gestió (primera còpia gratis) d'esdeveniments de dades (0,10 USD per 100.000, i volum milionari), i has escrit selectors avançats que baixen la factura de 40 USD a 0,06 USD sense perdre res: tot sobre les còpies i els informes, només escriptures sobre el catàleg, res sobre els registres web. Coneixes Insights per 0,53 USD al mes, i les seves dues limitacions: 7 dies de línia base i que només detecta anomalies de volum.

Has enviat el trail també a CloudWatch Logs —90 dies allà, 7 anys a S3, cada destí amb el seu propòsit— i has muntat les cinc alarmes de seguretat estàndard: ús del compte arrel, canvis al trail (la més important de totes, perquè avisa que l'auditoria està sent atacada), desxifratge de còpies excloent-hi el mateix RDS, pics d'AccessDenied amb llindar realista, i canvis de configuració de seguretat. I saps consultar amb Athena —amb el WHERE de partició sempre posat i BytesScannedCutoffPerQuery com a xarxa de seguretat— per respondre qui va assumir un rol, qui va llegir el secret de mfadmin, quines crides van fallar i quines IP desconegudes han aparegut; amb CloudTrail Lake com a alternativa gestionada, avaluada i descartada amb criteri.

Has recorregut una investigació completa: congelar l'evidència abans de res, trobar l'AssumeRole real, reconstruir la sessió sencera per accessKeyId, interpretar el patró, parlar amb la persona abans de concloure res —CloudTrail diu què va passar, no per què— i tancar amb accions correctives amb responsable i data, entre elles la més important: fer que provar restauracions sigui fàcil i visible en lloc de prohibir-ho. I coneixes IAM Access Analyzer generant polítiques de privilegi mínim a partir de l'ús real, que tanca el cercle amb 04-01. Tot per 1,59 USD al mes.

Però fixa't en el que aquest servei no pot fer, perquè l'exercici 3 ho va deixar clar: CloudTrail detecta esdeveniments, no estats. Sap que algú va cridar DeleteBucketEncryption aquest matí. No sap que el bucket mercadofresco-registros-web fa cinc mesos que està sense xifrar perquè mai no es va configurar. No sap que hi ha un grup de seguretat amb 0.0.0.0/0 al port 22 des d'una prova de març. No pot dir quants recursos incompleixen la política d'etiquetatge obligatori de MercadoFresco. I no cal dir que no ho pot arreglar sol.

Aquesta és la cinquena i última pregunta que va deixar oberta el mòdul 4: res no avisa si algú desactiva el xifratge d'un bucket o obre un grup de seguretat al món. A la lliçó 05-04, «AWS Config», veurem què és l'element de configuració d'un recurs i la seva línia temporal, en què es diferencia exactament de CloudTrail —qui va fer la crida enfront de com va quedar el recurs—, com s'activa l'enregistrador de configuració amb el seu canal de lliurament, les regles gestionades que MercadoFresco necessita (s3-bucket-server-side-encryption-enabled, restricted-ssh, required-tags i companyia), les regles pròpies amb Lambda i amb Guard, la remediació automàtica amb documents de Systems Manager que torna a xifrar un bucket o tanca un grup de seguretat sense que ningú intervingui, els paquets de conformitat alineats amb CIS i PCI DSS, i el cost real per element de configuració, que és la partida que més fàcilment es dispara de tot aquest mòdul.