Auditoria a tota l’organització: un trail organitzatiu de CloudTrail centrat en la seguretat per a 53 comptes d'AWS

Resum

Vam construir les bases d’auditoria i governança per a una AWS Organization de 53 comptes sense adoptar Control Tower. Cada crida a l’API, a cada compte i regió, acaba ara en un únic bucket xifrat i immutable al qual cap compte de càrrega de treball té accés, i les crides importants arriben a Mattermost en qüestió de minuts.

La clau no és quins serveis vam fer servir, sinó on viu cada cosa. Els logs s’escriuen en un compte, s’emmagatzemen en un altre i es llegeixen des d’un tercer, de manera que comprometre un sol compte no n’hi ha prou per reescriure la història ni per silenciar l’alarma.

• Cobertura: un únic trail organitzatiu multiregió per als 53 comptes, xifrat amb una clau KMS gestionada pel client.
• Integritat: S3 Object Lock, primer en mode governance durant 30 dies i després en mode compliance amb una retenció de 365 dies.
• Accés: un estat de Terraform per compte, aplicat amb sessions de curta durada d’IAM Identity Center. Sense usuaris IAM ni claus de llarga durada.
• Detecció: una Lambda al compte de seguretat converteix una selecció d’esdeveniments en alertes de Mattermost, amb una mediana d’uns 3 minuts des de la crida a l’API fins a l’alerta i un p95 d’uns 6.
• Troballes fins ara: tres troballes reals en les deu primeres setmanes. Cap no era maliciosa, i cadascuna va canviar un procés.

El repte

L’organització havia crescut fins a 51 comptes sense una resposta comuna a una pregunta senzilla: qui va fer què, on i quan?

• No hi havia un registre d’auditoria central. Cada compte tenia la configuració de CloudTrail amb què havia nascut, si és que en tenia. Investigar qualsevol cosa volia dir entrar als comptes un per un amb l’esperança que l’esdeveniment encara fos a l’Event history de 90 dies.
• No hi havia on allotjar les eines de seguretat. No existia un compte de seguretat ni un d’arxiu de logs. Qualsevol cosa que construíssim hauria acabat al compte de gestió, que ha d’estar tan buit com sigui possible, o en un compte de càrrega de treball, que és precisament el que ha de vigilar.
• Els logs eren tan modificables com els sistemes que descrivien. Qualsevol persona amb permisos d’administrador en un compte podia aturar el registre o esborrar les proves. És just el primer que acostuma a fer un atacant que aconsegueix aquests permisos.
• Ningú no se n’assabentava. Fins i tot on els esdeveniments quedaven registrats, ningú no els llegia fins que alguna cosa ja havia anat malament.

Aquest projecte va afegir dos comptes, seguretat i arxiu de logs, amb la qual cosa l’organització va passar a tenir-ne 53: el compte de gestió, els dos nous i 50 comptes de càrrega de treball per a producció, staging i desenvolupament.

Restriccions, i per què no Control Tower

Control Tower és la resposta per defecte a aquest problema, i vam decidir no fer-lo servir. És una landing zone: crea els seus propis comptes d’arxiu de logs i d’auditoria, el seu propi trail i un conjunt de guardrails, i a partir d’aquí espera ser-ne el propietari. Inscriure 50 comptes de càrrega de treball existents implica acceptar aquestes configuracions base compte per compte, i acceptar un servei que reconcilia recursos que, altrament, gestionaríem amb Terraform.

Necessitàvem una cosa més acotada: unes bases d’auditoria que entenguéssim del tot, construïdes amb el mateix Terraform que fem servir per a tota la resta i que poguéssim explicar línia per línia en una revisió. Fer-ho a mà va costar més esforç al principi i ens va donar exactament això.

Les restriccions que ens vam imposar:

1. Tot a Terraform. Res de configuració feta només des de la consola, perquè tot el disseny es pugui revisar i reproduir.
2. Sense credencials de llarga durada. Persones i pipelines s’autentiquen a través d’IAM Identity Center. Sense usuaris IAM ni claus d’accés al disc.
3. El compte de gestió es manté lleuger. Conté l’organització, Identity Center i la definició del trail, i res que processi o emmagatzemi logs.
4. Cap compte no pot reescriure la història tot sol. Escriure, emmagatzemar i llegir els logs passa en comptes diferents, amb persones diferents.
5. Additiu i reversible fins que estigui provat. Res d’irreversible, com la retenció en mode compliance, s’activa fins que no l’hem vist funcionar.

Hi va haver una restricció més, derivada d’on operem. Les nostres càrregues de treball s’executen a Frankfurt (eu-central-1), i el bucket del trail i la seva clau també hi són. El trail registra totes les regions, però les dades d’auditoria mai no surten de la UE.

Arquitectura

El disseny segueix una única regla: els logs s’escriuen en un compte, s’emmagatzemen en un altre i es llegeixen des d’un tercer. CloudTrail escriu des del compte de gestió, el compte d’arxiu de logs només emmagatzema, i el compte de seguretat només llegeix i alerta.

El recorregut en morat és la vida d’un fitxer de log: una crida a l’API en qualsevol punt de l’organització, lliurada pel trail organitzatiu, xifrada amb la clau KMS del compte d’arxiu, bloquejada al bucket, i després llegida pel compte de seguretat i convertida en una alerta.

Dos comptes nous, dues funcions diferents

Vam crear des de zero un compte d’arxiu de logs i un de seguretat en lloc d’aprofitar-ne algun d’existent. Un compte existent arrossega història: usuaris, rols i relacions de confiança que ningú no recorda del tot. Un compte nou comença buit, de manera que cada permís que conté és un que hem deixat per escrit.

La separació existeix perquè l’abast de qualsevol compromís aïllat sigui petit i evident:

• Compte de càrrega de treball compromès: no pot aturar el trail organitzatiu, perquè els comptes membres el poden veure però no modificar. Tampoc no pot arribar al bucket, que és en un altre compte.
• Compte de seguretat compromès: pot llegir logs i silenciar alertes, però no pot alterar ni esborrar el que ja s’ha escrit.
• Compte d’arxiu de logs compromès: Object Lock en mode compliance fa que ni tan sols el seu usuari root pugui esborrar una versió bloquejada abans que acabi la retenció.

Dos administradors amb nom i cognoms poden accedir al compte de gestió, tots dos a través d’Identity Center. El seu usuari root està protegit per un procediment d’emergència (break-glass) documentat: MFA per maquinari, credencials en un magatzem a part i un runbook que indica qui el pot obrir i què cal registrar després. Els comptes membres no tenen cap credencial root; la secció de resultats explica per què.

Un trail per a cada compte i cada regió

Un únic trail organitzatiu va substituir la configuració compte per compte. Els trails organitzatius registren els esdeveniments del compte de gestió i de tots els comptes membres, i els comptes nous queden coberts en el moment que s’hi uneixen. Els comptes membres poden veure el trail, però no modificar-lo ni esborrar-lo.

És multiregió expressament. Un trail d’una sola regió només registra les regions que fem servir, i als atacants els agraden les que no fem servir: una flota de mineria de criptomonedes en una regió que ningú no mira és un clàssic. També es capturen els esdeveniments de serveis globals, com IAM i Identity Center.

Xifratge amb una clau KMS gestionada pel client. El xifratge SSE-S3 per defecte protegeix el disc; una clau gestionada pel client protegeix les dades davant de les persones. Llegir un log requereix ara dos permisos diferents, s3:GetObject al bucket i kms:Decrypt a la clau, i cada desxifratge queda registrat al seu torn. La clau viu al compte d’arxiu de logs, al costat del bucket. La seva política:

• permet a CloudTrail generar claus de dades només quan la petició prové del nostre trail, comprovat amb la condició aws:SourceArn i el context de xifratge de CloudTrail;
• concedeix kms:Decrypt a un únic rol de lectura al compte de seguretat, i a ningú més;
• deixa l’administració de la clau en mans del rol de desplegament de Terraform del compte d’arxiu de logs.

La validació d’integritat dels fitxers de log està activada. CloudTrail escriu cada hora fitxers de resum (digest) signats, de manera que podem demostrar que un fitxer de log no ha canviat des que es va lliurar, amb independència d’Object Lock.

El trail registra tots els esdeveniments de gestió, tant de lectura com d’escriptura. La primera còpia dels esdeveniments de gestió és gratuïta, i les crides de lectura com ListBuckets o GetSecretValue sovint són el primer senyal que algú està xafardejant. Els esdeveniments de dades estan desactivats de moment. Els esdeveniments de dades de S3 als buckets amb dades de clients són el pas següent, un cop n’haguem calculat el cost per cada 100.000 esdeveniments.

Terraform: un estat per compte, sense secrets compartits

Cada compte és el seu propi mòdul arrel de Terraform amb el seu propi estat. L’estat es desa en un bucket S3 versionat dins del compte que descriu, amb el bloqueig natiu d’estat a S3 (use_lockfile), així que tampoc no hi ha una taula de bloqueig compartida. Un plan al compte de seguretat no pot veure, bloquejar ni corrompre l’estat del compte d’arxiu de logs, i un error en un stack té un abast d’un sol compte.

Només sessions de curta durada

Cada apply s’executa sobre una sessió d’IAM Identity Center: aws sso login i després un perfil amb nom per compte al bloc del provider. Les sessions caduquen en hores, no en anys. No hi ha cap usuari IAM de què oblidar-se ni cap clau en una variable de CI, i donar de baixa algú és un únic canvi a Identity Center. Un portàtil perdut conté, com a molt, una sessió a punt de caducar.

Valors passats explícitament, no llegits d’altres estats

Els stacks depenen els uns dels altres. El trail necessita el nom del bucket i l’ARN de la clau del compte d’arxiu; la política de la clau necessita l’ARN del trail; l’stack d’alertes els necessita tots dos. La drecera habitual és una font de dades terraform_remote_state que llegeix l’estat d’un altre compte.

No la vam agafar. Llegir un fitxer d’estat vol dir llegir el fitxer sencer, no un sol output: tots els atributs de tots els recursos, incloses les dades sensibles. Donar al compte de seguretat accés de lectura a l’estat del compte d’arxiu hauria reconstruït sense fer soroll la confiança entre comptes que acabàvem de separar.

En comptes d’això, cada stack exposa uns quants outputs, i l’stack que els consumeix els rep com a variables d’entrada tipades en un fitxer .tfvars versionat al repositori:

Dos valors resolen el que sembla el problema de l’ou i la gallina. L’ARN del trail es dedueix de l’ID del compte, la regió i el nom del trail, així que la política de la clau el pot referenciar abans que el trail existeixi. El rol de lectura és més complicat, perquè KMS i S3 rebutgen polítiques que esmenten un principal que encara no existeix. Per això les polítiques confien en el compte de seguretat i fixen el rol amb una condició aws:PrincipalArn. Així l’ordre d’aplicació va en una sola direcció: arxiu de logs, després gestió i després seguretat.

El preu és copiar a mà cada vegada que canvia un output, cosa que amb aquests valors no passa gairebé mai. Les regles de validació de variables detecten un valor enganxat amb un format incorrecte abans que arribi a un plan.

Object Lock: primer governance, compliance un cop provat

L’última línia de defensa és que els logs no es puguin esborrar de cap manera. S3 Object Lock ho ofereix en dos modes, i la diferència és si algú ho pot desfer:

• Mode governance: un principal amb s3:BypassGovernanceRetention pot escurçar la retenció o esborrar una versió bloquejada enviant explícitament la capçalera de bypass.
• Mode compliance: ningú no pot escurçar la retenció ni esborrar una versió bloquejada abans que caduqui. Ni un administrador, ni l’usuari root.

L’objectiu és el mode compliance, i també és una porta d’un sol sentit. Si configures un període de retenció equivocat, o bloqueges objectes que una regla de cicle de vida havia de netejar, pagues aquest emmagatzematge durant tot el període sense marxa enrere. Així que vam començar en mode governance i el vam tractar com un assaig. Durant aquest període vam comprovar que:

1. Els logs dels 53 comptes i de totes les regions habilitades arribaven sota el prefix de l’organització.
2. La validació dels digest funcionava d’extrem a extrem.
3. Les regles de cicle de vida (transició a emmagatzematge més fred i expiració després de la retenció) es comportaven correctament amb versions bloquejades.
4. El rol de lectura de seguretat podia desxifrar i llegir, i res més no podia fer-ho.
5. El cost d’emmagatzematge previst amb la retenció completa era assumible.
6. El període de retenció estava acordat amb qui és responsable del compliment normatiu, i no l’havia triat l’enginyer de torn.

Després vam canviar el mode per defecte del bucket a compliance. Aquí importa un detall: canviar el mode per defecte només afecta els objectes escrits a partir d’aquell moment. Les versions escrites durant la fase de governance mantenen la retenció governance fins que caduquen, llevat que es tornin a marcar, per exemple amb S3 Batch Operations.

La retenció és de 365 dies. Una regla de cicle de vida mou els fitxers de log a S3 Glacier Instant Retrieval als 90 dies i els fa caducar quan acaba la retenció. La fase de governance va durar 30 dies. Vam deixar que aquells objectes caduquessin sols en lloc de tornar-los a marcar: expirarien en menys d’un any igualment, i una feina de Batch Operations hauria costat més que el risc que eliminava.

De la crida a l’API a Mattermost

Uns logs que ningú no llegeix són un arxiu, no un control. Una funció Lambda al compte de seguretat llegeix cada nou fitxer de log, compara els esdeveniments amb una llista curta i seleccionada, i publica les coincidències en un canal de Mattermost que l’equip ja vigila.

El flux: CloudTrail lliura un fitxer de log al bucket, el bucket envia una notificació d’objecte creat a una cua SQS al compte de seguretat, i la Lambda llegeix el fitxer amb el rol de lectura de seguretat, desxifrant-lo gràcies al permís de KMS descrit abans. SQS ens dona reintents i una cua de missatges fallits (dead-letter queue) sense codi addicional. La URL del webhook de Mattermost es desa a Secrets Manager, no en una variable d’entorn, i es guarda a la memòria cau durant la vida de cada contenidor de Lambda.

El nostre servidor de Mattermost només accepta trànsit d’IP permeses, així que la Lambda s’executa en una VPC i surt a través d’un NAT gateway amb una Elastic IP fixa que és a la llista de permeses.

Sobre què alertem

Cada alerta ha de ser una cosa sobre la qual una persona actuaria. La llista és curta expressament:

Dues regles van canviar després de la primera setmana, que va generar unes 40 alertes. Els inicis de sessió fallits aïllats eren gairebé sempre contrasenyes mal escrites, així que ara aquesta regla només salta amb cinc o més errors d’un mateix usuari en deu minuts. Les crides AttachRolePolicy fetes pels rols de desplegament de Terraform se suprimeixen, perquè cadascuna ja ha passat per una merge request revisada. Després de l’ajust, el canal rep entre quatre i sis alertes per setmana.

Quant triga una alerta?

El límit inferior el marca el mateix CloudTrail. AWS indica que CloudTrail sol lliurar els logs en una mitjana d’uns 5 minuts des de la crida a l’API. La notificació, la cua i la Lambda hi afegeixen segons.

Vam mesurar 58 alertes durant 30 dies, des de l’eventTime de l’esdeveniment fins a la marca de temps de la publicació a Mattermost. La mediana va ser de 3 minuts i 10 segons, el p95 de 6 minuts i 5 segons, i la més lenta va trigar 11 minuts. La Lambda en representa entre 2 i 4 segons; la resta és el lliurament de CloudTrail.

Minuts és el que cal per a un control d’auditoria. No ho és per aturar un atac en curs. D’això tracta el compromís sobre EventBridge que expliquem més avall.

Decisions clau i compromisos

Qui administra el trail

Els trails organitzatius es poden crear al compte de gestió o, des de finals del 2022, mitjançant un administrador delegat de CloudTrail, un compte membre com el de seguretat. En tots dos casos, el compte de gestió continua sent el propietari del trail.

Vam mantenir el trail al compte de gestió. Delegar-lo al compte de seguretat hauria reduït els inicis de sessió al compte de gestió, però també hauria donat a seguretat el poder de modificar o esborrar el trail. Això trenca la regla sobre la qual es basa tot el disseny: seguretat llegeix, mai no escriu.

En qualsevol cas, el compte de gestió encara pot esborrar el trail. Aquest risc es cobreix en dues capes: esborrar-lo dispara una alerta, i res del que ja s’ha escrit no es pot eliminar.

Disparador d’alertes: notificacions de S3, EventBridge o CloudWatch Logs

• Notificacions de S3 sobre l’arxiu (la nostra elecció): un únic punt d’integració per a tots els comptes i regions, que llegeix exactament el que conté l’arxiu. La latència és el temps de lliurament de CloudTrail, és a dir, minuts.
• EventBridge: gairebé en temps real, però els esdeveniments de CloudTrail arriben a EventBridge al compte i la regió on es produeixen. Cobrir tota l’organització implica regles a cada compte i cada regió que reenviïn a un bus central. És molta més fontaneria a canvi d’alertes més ràpides.
• CloudWatch Logs: els filtres de mètriques són còmodes, però el grup de logs del trail organitzatiu és al costat del compte de gestió, cosa que hauria portat el processament al compte que volíem mantenir lleuger.

Vam triar cobertura i simplicitat per davant de segons. Una via ràpida per a un grapat d’esdeveniments crítics és a la llista de més avall.

Detectiu, encara no preventiu

Vam començar només amb detecció. Una SCP que denegui directament StopLogging, DeleteTrail i LeaveOrganization seria preventiva, però una SCP equivocada pot trencar producció a tots els comptes alhora, i volíem veure trànsit real primer.

Sis setmanes després de la posada en marxa, l’historial d’alertes no mostrava cap ús legítim d’aquestes crides. Llavors vam vincular a tots els comptes membres una SCP que denega StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors i LeaveOrganization. Les SCP no s’apliquen al compte de gestió, així que allà el control continua sent l’alerta.

El període en mode governance

Començar en mode governance va deixar una finestra en què un principal amb el permís de bypass podia esborrar logs. Ho vam acceptar, vam limitar aquest permís a un únic rol de Terraform i vam configurar una alerta davant de qualsevol bypass. L’alternativa era un error que no podríem desfer durant tot el període de retenció.

Una llista seleccionada, no un producte de detecció

La Lambda aplica la nostra pròpia política: per exemple, qualsevol CreateAccessKey és una troballa perquè no tenim usuaris IAM. No és detecció d’anomalies. Un servei gestionat com GuardDuty cobreix un altre terreny i la complementa, no la substitueix.

Què va fallar

Durant el desplegament van fallar tres coses, i cadascuna va canviar el disseny.

• El trail no va lliurar res durant la primera hora, i a la consola tot semblava correcte. La política de la clau KMS fixava aws:SourceArn a un ARN de trail construït amb l’ID del compte d’arxiu de logs. L’ARN d’un trail organitzatiu porta l’ID del compte de gestió, així que CloudTrail no podia generar claus de dades. Només aws cloudtrail get-trail-status ho mostrava, a LatestDeliveryError. Vam corregir l’ARN i vam afegir aquesta comprovació al runbook de desplegament.
• La política del bucket rebutjava els logs dels comptes membres. La política permetia escriptures sota AWSLogs/<management-account-id>/, que només cobreix els esdeveniments propis del compte de gestió. Els trails organitzatius escriuen els logs dels comptes membres sota AWSLogs/<org-id>/. Afegir la ruta de l’organització ho va solucionar, i ho vam detectar durant l’assaig en mode governance.
• Una caiguda de Mattermost va fer que rebéssim cada alerta dues vegades. Un fitxer de log conté molts esdeveniments, així que quan una publicació fallava, SQS tornava a lliurar el fitxer sencer i les alertes que ja s’havien enviat es publicaven de nou. Ara la Lambda registra cada eventID publicat en una petita taula de DynamoDB amb un TTL de 24 hores i se salta els repetits.

Resultats

L’organització té ara un únic lloc on respondre «qui va fer què, on i quan», i serveix per a tots els comptes, inclosos els que encara no existeixen.

Els set usuaris IAM van sortir de l’inventari que vam fer durant el desplegament. La majoria eren antics usuaris de CI i de còpies de seguretat; cadascun es va substituir per un perfil d’Identity Center o per un rol IAM.

L’inici de sessió root d’un dissabte. Tres setmanes després de la posada en marxa, la regla d’activitat root va saltar en un compte de staging un dissabte al matí. Era un company que actualitzava un contacte de facturació amb unes credencials root desades feia anys en un gestor de contrasenyes compartit. Res de maliciós, però va demostrar que qualsevol persona amb accés a aquell magatzem encara podia fer servir les credencials root dels comptes membres. Vam activar la gestió centralitzada de l’accés root a AWS Organizations, vam eliminar les credencials root dels 52 comptes membres i vam posar el root del compte de gestió darrere del procediment d’emergència.

Les altres dues troballes van ser menors. Un desenvolupador havia creat una clau d’accés per a un script local; es va substituir per un perfil d’Identity Center aquell mateix dia. I un permission set d’administrador s’havia assignat al grup equivocat a Identity Center, cosa que vam detectar i corregir en minuts.

Què faria diferent

• Alertar del silenci, no només dels esdeveniments. Si el trail deixa de lliurar, la Lambda d’alertes simplement no té res a dir. Un heartbeat que salti quan no hagi arribat cap fitxer de log en 15 minuts hauria detectat la nostra fallada de KMS de la primera hora sense que ningú hagués de mirar.
• Afegir una via ràpida per als pocs esdeveniments que no poden esperar. Regles d’EventBridge només per a la manipulació del trail i els inicis de sessió root, al costat de la via de S3, els passarien de minuts a segons sense refer el flux.
• Passar abans del detectiu al preventiu. L’SCP es va activar a les sis setmanes. Amb dues n’hi hauria hagut prou: les crides que bloqueja no van tenir mai un ús legítim.
• Fer que l’arxiu es pugui consultar des del primer dia. Athena sobre el bucket, o CloudTrail Lake, converteix el «tenim els logs» en «podem respondre la pregunta en un minut» durant una investigació.
• Enviar les alertes de costos al mateix canal. Les alertes de pressupost com un subscriptor més posarien la despesa a la mateixa imatge operativa que la seguretat.

Fonts

• Creating a trail for an organization
• CloudTrail organization delegated administrator
• Working with CloudTrail log files (delivery time)