Vam acabar 04-02 amb la base de dades mercadofresco-pedidos xifrada amb AES-256 i una clau de KMS amb política, rotació i separació de funcions. I tot i així, qualsevol que s'assegui davant del portàtil del Luis es pot connectar a aquesta base de dades, perquè la contrasenya de l'usuari mfadmin està escrita en text pla com a mínim en cinc llocs:

1. Al user data de la plantilla de llançament lt-mercadofresco-tienda, que es pot llegir des del servei de metadades de qualsevol instància de la botiga.
2. A /etc/mercadofresco/tienda.conf dins de cada instància.
3. En un fitxer .env que el Luis es va enviar a si mateix per xat quan va muntar l'entorn de desenvolupament.
4. A l'historial d'ordres de la sessió on la va fer servir per primer cop.
5. Al cap de la Marta, que la va triar fa catorze mesos i que no ha canviat des d'aleshores.

El xifratge no ajuda aquí. Com vam veure a la primera taula de 04-02, el xifratge en repòs protegeix del disc robat i de l'snapshot compartit per error, però no protegeix d'unes credencials vàlides en mans equivocades. Aquesta lliçó resol exactament aquest problema.

AWS ofereix dos serveis per custodiar valors de configuració i credencials: AWS Systems Manager Parameter Store i AWS Secrets Manager. No són competidors, són complementaris, i la meitat d'aquesta lliçó consisteix a saber quin fer servir per a cada cosa.

Advertiment. Els exemples són didàctics i les credencials, fictícies. Tota gestió real de credencials, rotació i compliment (RGPD, PCI DSS) ha de ser revisada per un professional de seguretat abans d'aplicar-se a un entorn amb dades de clients. Un secret mal migrat —especialment una rotació mal configurada— deixa l'aplicació fora de servei i sense manera evident de tornar enrere. No facis servir mai credencials reals en un entorn de proves.

1. Per què les credencials al codi són un problema estructural
2. Què passa exactament quan un secret arriba a Git
3. Configuració i secret no són el mateix
4. Parameter Store: tipus de paràmetre
5. Jerarquia per rutes, versions i nivells
6. La configuració de MercadoFresco a Parameter Store
7. Secrets Manager: secrets, versions i etapes
8. Xifratge amb KMS i polítiques de recurs
9. Rotació automàtica: el cicle de quatre passos
10. Configurar la rotació de mercadofresco/produccion/rds/mfadmin
11. Usuari únic enfront d'alternança de dos usuaris
12. Taula comparativa i la recomanació per a MercadoFresco
13. Consum des de l'aplicació: boto3 i memòria cau
14. Consum des de Lambda, EC2, ECS i CloudFormation
15. Permisos mínims per llegir un secret
16. La migració: treure la contrasenya del user data
17. Què no cal guardar aquí
18. Auditoria de l'accés als secrets
19. Detecció de secrets filtrats al repositori
20. Cost, quotes i neteja

No és descuit, és un problema de disseny. Una credencial escrita en un fitxer de configuració té quatre propietats que la condemnen:

La quarta és la que perpetua el problema. La Marta sap que la contrasenya s'hauria de canviar, però canviar-la significa editar la plantilla de llançament, reiniciar totes les instàncies de l'ASG, avisar el Luis i creuar els dits. Com que el risc de l'operació sembla més gran que el de no fer res, no es fa mai. La rotació automàtica trenca aquest cercle, i per això és el cor d'aquesta lliçó.

Convé ser concret, perquè l'error més car és creure que n'hi ha prou d'esborrar-lo al commit següent:

Això no elimina res. El fitxer continua a l'historial, accessible amb git show <commit-anterior>:.env. I si el repositori va estar en un servidor compartit o algú en va fer un clone, aquestes còpies també el tenen. L'únic procediment correcte és:

1. Rota la credencial immediatament. Considera-la compromesa des del moment en què es va escriure. Aquest pas és obligatori i no és opcional.
2. Reescriure l'historial (git filter-repo, BFG) i forçar el push. Això trenca els clons de tot l'equip, així que cal coordinar-ho.
3. Buscar als registres si la credencial s'ha fet servir des d'algun lloc inesperat.
4. Afegir un escàner que impedeixi que torni a passar.

L'ordre importa: rotar primer. Reescriure l'historial mentre la credencial continua sent vàlida és tractar el símptoma. Si el repositori és públic, els bots que rastregen GitHub troben credencials d'AWS en qüestió de minuts, i el cost d'un compte utilitzat per minar criptomonedes es compta en milers de dòlars al dia.

Aquesta distinció decideix quin servei fer servir:

Casos frontera que convé resoldre per endavant:

• El nom d'usuari de la base de dades (mfadmin) és configuració. La contrasenya és secret. Però es guarden junts, perquè la rotació canvia tots dos en el cas d'alternança.
• El punt d'enllaç d'RDS és configuració: no és secret i ja és públic dins la teva VPC.
• Una clau d'API d'un proveïdor de pagaments és un secret, encara que sigui d'un entorn de proves.
• L'identificador de la distribució de CloudFront (E2QWERTY123ABC) és configuració.

Parameter Store és un component d'AWS Systems Manager. Guarda parells clau-valor amb tres tipus:

Notes sobre SecureString:

• Si no indiques --key-id, es fa servir la clau gestionada per AWS alias/aws/ssm, que és gratuïta però no controlable. Per a valors que importen, fes servir la teva clau.
• Per llegir el valor desxifrat cal --with-decryption i permís kms:Decrypt sobre la clau. És la mateixa doble autorització d'SSE-KMS.

La jerarquia per rutes és la característica que fa útil Parameter Store. Els noms s'estructuren com a rutes i es poden llegir en bloc:

Amb una sola crida l'aplicació carrega tota la seva configuració:

I la jerarquia es converteix directament en control d'accés: una política que concedeix ssm:GetParametersByPath sobre /mercadofresco/produccion/* deixa fora tot l'entorn de desenvolupament sense enumerar ni un sol paràmetre.

Versions. Cada put-parameter --overwrite crea una versió nova i conserva les anteriors. Es pot llegir una versió concreta amb nom:numero, i etiquetar una versió amb un àlies:

Tornar enrere després d'un canvi desafortunat és canviar l'etiqueta estable a la versió anterior. No hi ha cap desplegament pel mig.

Nivells.

MercadoFresco cap de sobres al nivell estàndard: zero euros per tota la seva configuració. El nivell avançat es justifica quan necessites més de 4 KB —un certificat, per exemple— o les polítiques de caducitat, que avisen quan un paràmetre fa massa temps que no canvia.

Hi ha a més un mode de rendiment alt (--parameter-tier, amb ssm:GetParameters a 3.000 peticions per segon) que es factura a part; només cal si l'aplicació llegeix paràmetres al camí crític de cada petició, cosa que no hauria de fer: per a això hi ha la memòria cau.

Fixa't que l'usuari mfadmin és aquí i la contrasenya no. El nom d'usuari és configuració; la contrasenya va a l'altre servei. I observa l'efecte col·lateral: el user data de lt-mercadofresco-tienda, que fins ara era una llista de valors incrustats, passa a ser una crida genèrica idèntica a tots els entorns.

Un secret de Secrets Manager és un valor —normalment un JSON— xifrat amb KMS, amb versions i un mecanisme de rotació. La peça que cal entendre bé són les etapes de versió.

Cada versió d'un secret porta una o diverses etiquetes d'etapa:

Aquestes tres etiquetes són el mecanisme que fa que la rotació no talli el servei. Durant uns segons coexisteixen la contrasenya vella (AWSCURRENT) i la nova (AWSPENDING), i només quan la nova s'ha provat s'intercanvien les etiquetes. Cap aplicació no es queda sense credencial vàlida en cap moment.

Crear el secret de MercadoFresco:

L'estructura del JSON no és arbitrària: aquests noms de camp (engine, host, port, dbname, username, password) són exactament els que espera la funció de rotació gestionada d'AWS per a PostgreSQL. Si els canvies, la rotació no funcionarà. És un dels detalls que fa perdre més temps.

--kms-key-id alias/mercadofresco-datos connecta aquesta lliçó amb l'anterior: el secret es xifra amb la clau que vam construir a 04-02, i per tant queda subjecte a la seva política. Qui no pugui fer servir la clau no podrà llegir el secret encara que tingui secretsmanager:GetSecretValue. Un altre cop la doble autorització.

Com un bucket, una cua o una clau, un secret admet política de recurs. Serveix per a dues coses: accés entre comptes i reforç amb Deny.

És un Deny amb StringNotEquals: «denega la lectura a tothom que no sigui un d'aquests tres». Recorda de 04-01 que un Deny guanya sempre, així que ni una política d'identitat amb secretsmanager:* sobre * se'l pot saltar. És la manera més robusta de blindar el secret més sensible del compte, i cal incloure a la llista el rol de rotació o la rotació fallarà.

--block-public-policy rebutja la política si concedís accés públic. Fes-lo servir sempre.

Aquí hi ha el valor diferencial de Secrets Manager. La rotació l'executa una funció Lambda, que AWS proporciona ja escrita per als motors de base de dades habituals, i que s'invoca quatre vegades amb un pas diferent cada cop.

Els quatre passos, amb el que importa de cadascun:

La conseqüència pràctica més important és la que gairebé ningú no anticipa: entre setSecret i finishSecret hi ha una finestra en què la base de dades ja té la contrasenya nova però AWSCURRENT encara retorna la vella. Si la teva aplicació desa el secret a la memòria cau durant una hora i obre una connexió nova just en aquesta finestra, rebrà un error d'autenticació.

Per això el patró correcte a l'aplicació és:

1. Desar el secret a la memòria cau (una lectura per petició és caríssima i lenta).
2. En rebre un error d'autenticació, invalidar la memòria cau i reintentar un cop.

Aquest reintent d'una línia és el que converteix la rotació en una cosa transparent. Sense ell, cada rotació produeix un grapat d'errors als registres.

La manera més senzilla és deixar que Secrets Manager creï la Lambda des de la seva plantilla gestionada:

Els paràmetres de --rotation-rules:

• AutomaticallyAfterDays: 30: cada 30 dies.
• ScheduleExpression: quan exactament. Aquí, els dimarts a les 3 de la matinada. És deliberat: mai un dijous ni un divendres, pel pic de comandes.
• Duration: "2h": finestra de dues hores dins la qual pot començar.

La Lambda de rotació necessita tres coses que s'obliden constantment:

1. Accés de xarxa a la base de dades. Ha d'estar a la VPC vpc-mercadofresco, a les subxarxes snet-mercadofresco-app-a/-b, i sg-mercadofresco-basedatos ha d'acceptar el 5432 des del seu grup de seguretat. Aquí s'aplica el que vam veure a 03-02: referenciar l'SG d'origen en lloc d'un CIDR.
2. Accés a l'API de Secrets Manager. Com que és a subxarxes privades i la seva sortida a internet passa per nat-mercadofresco-a, o bé s'accepta aquest cost o bé es crea un endpoint de VPC d'interfície per a secretsmanager, igual que vam fer amb vpce-mercadofresco-s3 a 03-01. Sense una de les dues coses, la Lambda es queda penjada fins a esgotar el temps d'espera i el símptoma no diu res.
3. Permisos. El seu rol necessita secretsmanager:GetSecretValue, PutSecretValue, UpdateSecretVersionStage, DescribeSecret, GetRandomPassword, més kms:Decrypt i kms:GenerateDataKey sobre alias/mercadofresco-datos.

Rotació manual immediata, molt útil per provar abans de confiar en el calendari:

Prova la rotació en desenvolupament abans d'activar-la a producció. És el consell més important d'aquesta lliçó: una rotació mal configurada deixa la botiga sense base de dades, i l'error de setSecret a mitges pot requerir canviar la contrasenya a mà per recuperar-se.

Hi ha dues estratègies de rotació, i l'elecció té conseqüències reals de disponibilitat:

MercadoFresco comença amb usuari únic perquè és més simple i la botiga implementa el reintent. Quan el volum creixi —o quan entrin en joc contenidors que arrenquen i moren constantment, al mòdul 10— l'alternança de dos usuaris serà l'opció sensata. La plantilla gestionada d'AWS existeix per als dos casos: SecretsManagerRDSPostgreSQLRotationSingleUser i ...RotationMultiUser.

La recomanació per a MercadoFresco, escrita com a norma de l'equip:

Tot allò que sigui una credencial capaç de donar accés a dades de clients va a Secrets Manager, amb rotació activada. Tota la resta va a Parameter Store.

Aplicat:

Cost d'aquesta divisió: 2 secrets × 0,40 = 0,80 USD al mes, més uns cèntims de crides. Tota la configuració, gratis. Si ho haguéssim ficat tot a Secrets Manager, els 25 valors costarien 10 USD mensuals; si ho haguéssim ficat tot a Parameter Store, no tindríem rotació. La divisió no és purisme, és economia.

Un detall pràctic molt còmode: Parameter Store pot llegir secrets de Secrets Manager fent servir el prefix /aws/reference/secretsmanager/. Així l'aplicació utilitza una sola API per a tot:

La versió ingènua —llegir el secret a cada petició— té tres problemes: latència de desenes de mil·lisegons, cost per crida i risc de superar la quota de peticions. La correcta fa servir memòria cau amb invalidació davant d'error d'autenticació:

El bucle for intent in (1, 2) és tota la lògica que cal: primer intent amb la memòria cau, segon amb recàrrega forçada, i només es reintenta si l'error és d'autenticació. Un error de xarxa o de temps d'espera es propaga tal qual, perquè recarregar el secret no ho arreglaria.

Per a producció existeix la biblioteca oficial, que afegeix caducitat per temps i és més completa:

Amb secret_refresh_interval=3600 es fan 24 crides al dia per instància en lloc d'una per petició: de desenes de milers a dues dotzenes.

Lambda: l'extensió de paràmetres i secrets. AWS publica una capa que arrenca un petit servidor HTTP local dins l'entorn d'execució i en fa la memòria cau per tu. S'afegeix la capa, es configura amb variables d'entorn i es consulta per localhost:

L'extensió manté la memòria cau entre invocacions que reutilitzen el mateix entorn d'execució —recorda el model d'arrencades en fred i en calent de 02-05—, així que a la pràctica una funció molt invocada fa una crida cada cinc minuts en lloc d'una per invocació.

EC2. Amb el rol rol-mercadofresco-tienda assignat, boto3 troba les credencials sol. No hi ha res a configurar tret dels permisos.

ECS. Les definicions de tasca permeten injectar secrets directament com a variables d'entorn, sense que el codi cridi l'API. Es veurà a 10-01.

CloudFormation: referències dinàmiques. Es pot referenciar un secret sense escriure'l a la plantilla:

La sintaxi {{resolve:secretsmanager:<secret>:SecretString:<camp>}} es resol en el moment del desplegament i el valor no apareix mai a la plantilla ni als esdeveniments de la pila. Es desenvolupa a 09-01.

Aquesta és la política que s'adjunta a rol-mercadofresco-tienda:

Tres detalls que importen:

• Els sis interrogants finals de l'ARN. Secrets Manager afegeix un sufix aleatori de 6 caràcters a l'ARN de cada secret (...mfadmin-AbCdEf). Si escrius l'ARN sense sufix, la política no coincideix amb res. -?????? fa servir el comodí d'un caràcter per cobrir-ho. És l'error número u amb Secrets Manager i el seu símptoma —AccessDenied amb una política aparentment correcta— desconcerta qualsevol. L'alternativa és acabar en -*, una mica més laxa.
• kms:ViaService limitat a secretsmanager. La botiga pot desxifrar a través de Secrets Manager i d'S3 (per la declaració de 04-02), però no pot cridar kms:Decrypt directament contra qualsevol blob que aconsegueixi.
• ssm:GetParametersByPath acotat a /mercadofresco/produccion/*. La botiga de producció no veu la configuració de desenvolupament, ni a l'inrevés.

I el que no hi ha: secretsmanager:ListSecrets, que revelaria els noms de tots els secrets del compte, ni accés a cap altre secret. La botiga llegeix exactament un. Si demà s'afegeix el secret de la passarel·la de pagament, caldrà una decisió explícita per concedir-lo.

Estat inicial del user data de lt-mercadofresco-tienda, tal com va quedar a 02-01:

El pla de migració, en ordre i sense tallar el servei:

El pas 1 és crucial i contraintuïtiu: es guarda la contrasenya actual, sense canviar-la. Així els passos 1 a 7 no alteren res funcionalment i es poden revertir en qualsevol moment. La contrasenya només canvia al pas 8, quan tota la resta ja està provada.

Nou user data, sense ni una credencial:

La contrasenya no s'escriu en cap fitxer: el user data deixa el nom del secret, i l'aplicació el llegeix en memòria en arrencar i quan el necessita. El user data, que és visible des de les metadades de la instància, ja no conté res aprofitable.

Desplegament amb renovació progressiva, com a 02-01:

I per fi el pas 10, la neteja, que és la part que s'oblida:

• Esborrar /etc/mercadofresco/tienda.conf de les instàncies antigues (que es destrueixen soles amb la renovació).
• Esborrar el .env dels portàtils i reescriure l'historial de Git si va arribar a pujar-se.
• Purgar l'historial d'ordres de les sessions on es va fer servir.
• I, sobretot, rotar: la contrasenya anterior s'ha de considerar compromesa.

Ni Secrets Manager ni Parameter Store no són un magatzem de propòsit general:

Un cas que mereix menció: per a RDS existeixen a més les credencials gestionades (--manage-master-user-password), on RDS crea i rota el secret automàticament sense que configuris res. És el més senzill si la base de dades és nova; MercadoFresco no ho fa servir perquè mercadofresco-pedidos ja existia, però per a una instància nova és la primera opció a considerar.

Cada crida a GetSecretValue queda registrada a CloudTrail (05-03), amb qui, quan, des de quina IP i amb quin resultat. És la propietat que cap fitxer .env no pot oferir:

El que la Marta vigila:

• Lectures des de principals inesperats —qualsevol que no sigui rol-mercadofresco-tienda o el rol de rotació.
• Lectures fora d'horari o des d'IP desconegudes.
• Un pic de lectures, que suggereix que algú està enumerant secrets.
• DeleteSecret o PutResourcePolicy, que haurien de ser raríssims.

A 05-01 convertirem això en una alarma real de CloudWatch que avisi el tema alertas-mercadofresco; de moment n'hi ha prou de saber que el rastre existeix.

Prevenir és més barat que rotar. Dues capes:

Al portàtil, abans del commit. git-secrets instal·la un hook que rebutja commits amb patrons de credencials:

--scan-history revisa tot l'historial, no només l'estat actual. Executar-lo el primer cop en un repositori amb anys de vida sol donar sorpreses.

Al pipeline. L'escaneig local es pot saltar; el del pipeline no. Eines com gitleaks, trufflehog o l'escaneig de secrets de la plataforma s'executen a cada git push i aturen la construcció. L'integrarem a la fase de compilació a 08-02, juntament amb les proves i l'anàlisi estàtica.

I una regla d'higiene que val més que qualsevol eina:

Càlcul per a MercadoFresco:

Menys d'un dòlar al mes per eliminar el risc més comú i més car d'una infraestructura. Compara-ho amb el cost d'una bretxa notificable sota el RGPD i la discussió es tanca sola.

Neteja. Un secret no s'esborra immediatament: hi ha un període de recuperació d'entre 7 i 30 dies, per la mateixa raó que a KMS.

Compte amb l'asimetria: els paràmetres s'esborren a l'instant i no es recuperen. Abans d'esborrar en bloc una ruta de Parameter Store, exporta'n una còpia.

Oblidar el sufix de sis caràcters a l'ARN del secret. És l'error més freqüent amb Secrets Manager. L'ARN real és ...secret:mercadofresco/produccion/rds/mfadmin-AbCdEf, i una política que acabi en mfadmin sense més no coincideix amb res. Fes servir -?????? o -*.

Desar el secret a la memòria cau sense invalidar-la davant d'un error d'autenticació. Cada rotació produeix llavors una tongada d'errors. El reintent únic són quatre línies de codi i ho resol.

Posar la Lambda de rotació fora de la VPC. No es podrà connectar a mercadofresco-pedidos i la rotació fallarà a setSecret, que és el pitjor moment possible. Ha d'estar a les subxarxes d'aplicació i sg-mercadofresco-basedatos ha d'acceptar el seu grup de seguretat.

Oblidar la sortida a l'API de Secrets Manager des de la subxarxa privada. La Lambda es queda penjada fins a esgotar el temps d'espera i el missatge d'error no diu res útil. Necessita NAT o un endpoint d'interfície.

Canviar els noms dels camps del JSON del secret. La funció de rotació gestionada espera engine, host, port, dbname, username, password. Si els reanomenes «perquè es llegeixin millor», la rotació no funciona.

Activar la rotació a producció sense haver-la provat. Prova-la primer en una còpia de la base de dades, i amb --rotate-immediately per no esperar 30 dies a descobrir que alguna cosa falla.

Guardar-ho tot a Secrets Manager perquè és «el lloc segur». 25 valors són 10 USD al mes en lloc de 0,80. La configuració no sensible va a Parameter Store.

Programar la rotació un dijous a la nit. El pic de MercadoFresco és el divendres. Rota els dimarts de matinada, quan hi ha dos dies laborables per endavant per reaccionar.

Consell: fes servir una convenció de noms des del primer dia. <projecte>/<entorn>/<servei>/<recurs> permet escriure polítiques per prefix i veure d'un cop d'ull a quin entorn pertany cada cosa.

Consell: guarda el punt d'enllaç dins del secret a més de a Parameter Store. És el que espera la rotació gestionada, i evita que l'aplicació hagi de combinar dues fonts per obrir una connexió.

Consell: posa una alarma sobre NextRotationDate. Una rotació que fa 45 dies que no s'executa en un secret configurat a 30 és una rotació trencada que ningú no ha vist.

Consell: audita cada trimestre qui pot llegir cada secret. L'accés creix sol, i list-secrets amb les polítiques de recurs dona la foto en un minut.

MercadoFresco integra una passarel·la de pagament i un proveïdor de missatgeria. Apareixen aquests vuit valors:

1. Clau d'API de producció de la passarel·la de pagament (rota cada 90 dies per política del proveïdor).
2. URL base de l'API de la passarel·la: https://api.pasarela.example/v2.
3. Identificador de comerç: MF-2026-ES-0042.
4. Secret de signatura dels webhooks entrants de la passarel·la.
5. Temps màxim d'espera de la passarel·la: 8 segons.
6. Usuari i contrasenya de l'SFTP del proveïdor de missatgeria.
7. Llista de codis postals amb repartiment en 24 h.
8. Contrasenya d'una segona base de dades d'informes, de només lectura.

Decideix per a cadascun el servei, el tipus i el nom complet, seguint la convenció de MercadoFresco, i justifica els tres casos que consideris més discutibles. Calcula el cost mensual resultant.

La Marta activa la rotació de mercadofresco/produccion/rds/mfadmin. La rotació s'executa i falla. Als registres de la Lambda apareix:

I a Secrets Manager, describe-secret mostra una versió amb etapa AWSPENDING que fa tres hores que hi és, mentre AWSCURRENT continua apuntant a la versió antiga.

Respon: (a) en quin pas del cicle ha fallat i què significa exactament aquest missatge?; (b) enumera en ordre les quatre causes més probables i com comprovar cadascuna; (c) està l'aplicació caiguda en aquest moment i per què?; (d) què cal netejar abans de reintentar-ho?

Escriu la política de permisos completa del rol rol-rotacion-mfadmin, que assumeix la Lambda de rotació. Ha de poder: llegir i escriure el secret mercadofresco/produccion/rds/mfadmin (i només aquest), moure etapes de versió, generar contrasenyes aleatòries, fer servir alias/mercadofresco-datos a través de Secrets Manager, escriure els seus propis registres i funcionar dins de vpc-mercadofresco.

Solució 1

Casos discutibles:

• L'identificador de comerç (3). Sembla sensible perquè identifica l'empresa davant del proveïdor, però per si sol no autoritza res: sense la clau d'API no serveix de res, i apareix a les factures. És configuració. Si el proveïdor el tractés com a credencial, canviaria la decisió.
• El secret de signatura de webhooks (4). Podria semblar configuració perquè no «obre» res: només es fa servir per verificar signatures entrants. Però qui el conegui pot falsificar notificacions de pagament confirmat, és a dir, aconseguir comandes gratis. És un secret de primer ordre.
• Els codis postals (7). No és secret en absolut —està publicat al web— però és configuració que canvia sovint i convé tenir-la fora del codi per poder ampliar la cobertura sense desplegar. StringList amb get-parameter i --query 'Parameter.Value' retorna la cadena separada per comes.

Cost: 4 secrets nous × 0,40 = 1,60 USD/mes, més els 2 anteriors = 2,40 USD/mes a Secrets Manager. Parameter Store: 4 paràmetres més, 0 USD. Si s'haguessin ficat els vuit valors a Secrets Manager: 3,20 USD només per aquests vuit, quatre vegades més, sense cap avantatge per als quatre que no roten.

Solució 2

(a) Ha fallat al pas setSecret, el segon del cicle. El missatge concret —«unable to connect with previous secret»— diu que la Lambda ha intentat connectar-se a la base de dades amb la credencial actual (AWSCURRENT) per poder executar l'ALTER USER, i no ha pogut. És a dir: el problema no és la contrasenya nova, és que la Lambda no aconsegueix autenticar-se amb la vella.

(b) Quatre causes, en ordre de probabilitat:

1. Xarxa. La Lambda no és a vpc-mercadofresco, o és a les subxarxes equivocades, o sg-mercadofresco-basedatos no accepta el 5432 des del seu grup de seguretat. Comprovació: aws lambda get-function-configuration --query 'VpcConfig' i revisar les regles d'entrada de l'SG de la base de dades amb describe-security-groups.
2. La contrasenya d'AWSCURRENT no és la real. Si en crear el secret s'hi va posar una contrasenya inventada en lloc de la que realment té mfadmin, la Lambda no es pot autenticar. Comprovació: intentar connectar-s'hi manualment amb psql amb el valor d'AWSCURRENT des d'un bastió.
3. Els camps del JSON no són els esperats. Si falta dbname, port o engine, o si estan escrits d'una altra manera, la Lambda construeix malament la cadena de connexió. Comprovació: llegir el secret i comparar camp a camp amb el format esperat.
4. El punt d'enllaç és incorrecte —per exemple, va quedar l'antic després de la migració a la instància xifrada de 04-02, que va canviar el DNS. Comprovació: aws rds describe-db-instances --query 'DBInstances[].Endpoint.Address' i comparar.

(c) No, l'aplicació no està caiguda. I aquesta és exactament la virtut del disseny d'etapes: AWSCURRENT continua apuntant a la versió antiga, que és la que continua funcionant a la base de dades, i és la que retorna get-secret-value. La rotació fallida és un problema operatiu urgent, però no un incident de servei. Si hagués fallat després de setSecret —amb la contrasenya ja canviada a la base de dades però AWSCURRENT sense promocionar— llavors sí que hi hauria tall.

(d) Abans de reintentar-ho cal eliminar la versió penjada a AWSPENDING, o Secrets Manager intentarà continuar la rotació a mitges en lloc de començar de zero:

Després, corregir la causa, provar en desenvolupament i reintentar amb --rotate-immediately.

Solució 3

Justificació de cada bloc:

• El secret, un de sol, amb el sufix -?????? i la condició secretsmanager:resource/AllowRotationLambdaArn, que assegura que aquest rol només pot operar sobre secrets la rotació dels quals està assignada precisament a aquesta Lambda. És una defensa extra davant que algú reutilitzi el rol.
• GetRandomPassword no admet ARN de recurs; per això "Resource": "*". No és perillós: genera cadenes aleatòries i no dona accés a res.
• KMS acotat amb kms:ViaService a Secrets Manager: el rol no pot desxifrar objectes d'S3 amb la mateixa clau.
• Els registres del grup propi de la funció, amb el :* final.
• Les tres accions d'ec2: són obligatòries per a qualsevol Lambda dins d'una VPC: crea i destrueix una interfície de xarxa elàstica a cada arrencada en fred. No admeten ARN concret perquè la interfície encara no existeix quan es comprova el permís. És una de les poquíssimes vegades en què "Resource": "*" és inevitable, i es pot acotar amb condicions sobre ec2:Subnet i ec2:SecurityGroup si es vol apurar.

No hi apareix secretsmanager:ListSecrets, que revelaria l'inventari de secrets del compte, ni cap acció d'RDS: la Lambda canvia la contrasenya connectant-s'hi per SQL, no per l'API d'AWS.

La contrasenya de mfadmin ja no és on no havia de ser. Ha sortit del user data de lt-mercadofresco-tienda, del fitxer de configuració de les instàncies, del .env del Luis i de l'historial d'ordres, i viu a mercadofresco/produccion/rds/mfadmin, un secret xifrat amb alias/mercadofresco-datos, protegit per una política de recurs que denega la seva lectura a tot principal que no sigui rol-mercadofresco-tienda, marta o el rol de rotació, i que rota sola cada 30 dies, els dimarts de matinada, sense que ningú no se n'hagi de recordar ni assumir el risc de fer-ho a mà.

Entens per què la rotació no talla el servei: el mecanisme d'etapes de versió —AWSCURRENT, AWSPENDING, AWSPREVIOUS— i el cicle de quatre passos createSecret → setSecret → testSecret → finishSecret, on la contrasenya nova es crea, s'aplica i es prova abans de promocionar-se, i on una fallada a testSecret avorta tot el procés deixant la vella intacta. Saps també on és la finestra perillosa —entre setSecret i finishSecret— i per què l'aplicació ha d'invalidar la memòria cau i reintentar un cop davant d'un error d'autenticació: quatre línies que converteixen la rotació en una cosa invisible.

Distingeixes configuració de secret, i amb això quin dels dos serveis fer servir. La configuració de MercadoFresco viu a Parameter Store sota /mercadofresco/produccion/..., amb jerarquia per rutes que permet carregar-la sencera amb una crida i escriure permisos per prefix, amb versions i etiquetes per tornar enrere sense desplegar, i gratis al nivell estàndard. Els secrets viuen a Secrets Manager, a 0,40 USD cadascun. El total de la lliçó és 0,82 USD al mes, i saps argumentar per què ficar-ho tot al servei car hauria costat deu vegades més sense aportar res.

En la pràctica saps llegir un secret des de boto3 amb memòria cau i invalidació, des de Lambda amb l'extensió de paràmetres i secrets que en fa memòria cau entre invocacions, des d'EC2 amb el rol i sense configurar res, i des de CloudFormation amb referències dinàmiques {{resolve:secretsmanager:...}} que no escriuen mai el valor a la plantilla (09-01); a ECS s'injecten a la definició de tasca i ho veurem a 10-01. Coneixes els permisos mínims per llegir un secret —inclòs el sufix de sis caràcters de l'ARN, l'error que fa perdre més temps— i saps que el rastre de cada lectura queda a CloudTrail (05-03) i que l'escaneig de secrets s'automatitza a 08-02.

MercadoFresco ja té la casa endreçada cap endins: identitats mínimes, dades xifrades i credencials rotades. Però tot això protegeix d'amenaces que passen per la porta de l'API. Queda l'altra meitat del problema, la que arriba per la porta del davant i no necessita cap credencial. Recorda la regla DENY numerada 50 amb què a 03-02 vam bloquejar aquella IP que feia milers de peticions per minut: va funcionar perquè era una adreça. Si demà arriben peticions des de deu mil adreces diferents repartides per tot el món, aquesta regla no serveix de res, la NACL té un límit dur d'entrades, i el grup d'Auto Scaling reaccionarà com està dissenyat per reaccionar —arrencant instàncies— convertint l'atac en una factura. A la lliçó 04-04, «AWS Shield», veurem què és realment un atac de denegació de servei distribuïda, en què es diferencien els atacs volumètrics dels de capa d'aplicació, quina protecció ja tens activada i gratis a CloudFront, Route 53 i l'ALB, què hi afegeix Shield Advanced per 3.000 USD al mes —i si això té sentit per a una empresa de la mida de MercadoFresco—, i com es distingeix en calent un atac d'un pic legítim d'un divendres a la tarda.