L'incident amb què vam tancar el mòdul 5 ho va dir tot: la clau privada TLS de MediNube no va caure per una fallada matemàtica, va caure per un git push. Tota la criptografia que hem construït al llarg del curs —AEAD, Argon2id, signatures Ed25519, mTLS— comparteix un únic punt de fallada: les claus. Si una clau viu al lloc equivocat, tant se val com de perfecta sigui la primitiva que la fa servir. Aquesta lliçó respon la pregunta que portem ajornant des del mòdul 1: on haurien de viure els secrets de MediNube? I de pas salda diversos deutes pendents: el diccionari CLAUS_API de 01-04, la clau mestra d'historials de 02-03, el pepper de 03-03 i l'envelope encryption que vam anticipar a 04-05.

1. El problema real: els secrets es filtren per descuit
2. Inventari de secrets de MediNube
3. Jerarquia de claus: envelope encryption amb DEK i KEK
4. L'escala de maduresa de la gestió de secrets
5. Variables d'entorn: ús correcte i límits
6. Fitxers xifrats al repositori: sops i age
7. Gestors de secrets: Vault i KMS a la pràctica
8. Rotació de la clau mestra: la criptoagilitat es cobra
9. El pepper, per fi ben fet
10. Prevenció: que el secret no arribi al repositori

Cap atacant realista factoritzarà el mòdul RSA-3072 de MediNube. El que sí que farà MalloryClinic és buscar als llocs on els desenvolupadors deixem secrets sense voler:

• Repositoris git: el privkey.pem de l'incident de 05-03. El commit es va esborrar, però l'historial de git i els bots que escanegen GitHub no perdonen (un secret pujat a un repositori públic es considera compromès en minuts).
• Logs: un logger.debug(f"Connectant amb la clau {api_key}") escrit durant una depuració i oblidat.
• Fitxers .env compartits: per correu, per Slack, "només aquesta vegada perquè puguis arrencar el projecte".
• Imatges Docker: un COPY .env /app/ congela el secret a cada capa de la imatge, encara que després s'esborri el fitxer.
• Codi font directament: el clàssic. El nostre vell conegut de 01-04:

Aquest diccionari incompleix la regla d'or 2 (l'enemic coneix el sistema: qualsevol amb accés al repositori coneix les claus) i fa impossible la rotació sense desplegar codi nou. Avui el jubilem.

Abans de decidir on desar cada secret cal saber quins tenim. Aquest és l'inventari acumulat durant el curs — fer aquesta taula al teu propi projecte és el primer pas real de qualsevol pla de gestió de secrets:

Fixa't en un detall: no tots els secrets són iguals. La clau mestra d'historials protegeix dades sanitàries amb obligacions RGPD de dècades; la clau d'un webhook protegeix notificacions. El nivell de protecció pot (i ha de) ser proporcional a l'impacte.

A 04-05 vam construir el sobre híbrid i vam anticipar que el patró DEK/KEK era "just el que fan els KMS". Ha arribat el moment de saldar aquesta promesa. La idea de l'envelope encryption (xifratge de sobre) és organitzar les claus en jerarquia:

• DEK (Data Encryption Key): la clau que xifra les dades. Viu junt a les dades, però xifrada.
• KEK (Key Encryption Key): la clau que xifra les DEK. Viu al KMS i mai no en surt.

El flux operatiu és el punt clau, perquè sol malentendre's:

1. L'app vol desxifrar un historial. Junt a la dada té desada la DEK xifrada.
2. Envia la DEK xifrada al KMS: "desxifra'm això" (operació decrypt).
3. El KMS verifica que l'app està autoritzada, desxifra la DEK amb la KEK i retorna la DEK en clar.
4. L'app fa servir la DEK en memòria per a l'AES-GCM de medinube.cripto i la descarta en acabar.

Les dades mai no passen pel KMS. Pel KMS només viatgen claus de 32 bytes, no historials de megabytes. Això fa el patró ràpid, barat i auditable: el KMS registra cada operació (qui ha demanat desxifrar quina DEK i quan), i rotar la KEK només obliga a rexifrar DEK (unes poques), no terabytes de dades.

No totes les organitzacions necessiten un HSM. L'important és saber en quin esglaó estàs i quin és el següent:

MediNube, amb historials mèdics i obligacions RGPD, hauria d'estar al nivell 3, amb la KEK idealment recolzada per HSM (els KMS cloud ja ho fan per sota). El .env del nivell 1 continua sent legítim... per a la màquina del desenvolupador amb dades de prova.

Les variables d'entorn són el mecanisme estàndard per lliurar un secret a un procés, i estan bé per a això. Però convé conèixer-ne els límits:

Explicació: en lloc de tenir els valors al codi, el codi només coneix el nom del secret. Fallar sorollosament (RuntimeError) si en falta un és deliberat: un secret absent ha d'impedir l'arrencada, no degenerar en un valor per defecte insegur.

Límits que has de conèixer:

• Visibles a /proc: a Linux, cat /proc/<pid>/environ mostra l'entorn d'un procés. Qualsevol usuari que pugui llegir aquest fitxer (root, o el mateix usuari) veu els secrets.
• S'hereten: tot procés fill rep l'entorn complet. Aquell script de tercers que llances també veu MEDINUBE_MASTER_KEY.
• Acaben en logs i bolcats: molts frameworks imprimeixen l'entorn complet en informar d'un error. Configura el teu gestor d'errors perquè redacti variables amb noms com *_KEY, *_SECRET, *_PASSWORD.
• No es roten soles: canviar el valor exigeix reiniciar el procés.

De vegades vols versionar la configuració amb secrets inclosos (per exemple, per a infraestructura). La resposta no és "commitejar el secret", és commitejar-lo xifrat. La parella sops + age és l'estàndard lleuger:

L'elegància de sops és que xifra valor a valor: el diff de git continua mostrant quina clau ha canviat, sense revelar el contingut. I pot fer servir com a backend age, un KMS cloud o PGP — criptoagilitat també aquí. El límit: descentralitza la rotació (rexifrar i redesplegar) i no dona auditoria d'accessos. És un nivell 2,5 en la nostra escala: perfecte per a configuració d'infraestructura, insuficient com a gestor central de MediNube.

Un gestor de secrets (HashiCorp Vault, OpenBao, o el KMS/Secrets Manager del teu núvol) aporta el que cap nivell anterior té: autenticació de l'aplicació, secrets amb caducitat i auditoria central. El flux conceptual, comú a tots els proveïdors:

1. L'app s'autentica davant el gestor. No amb "un altre secret hardcodejat" (seria el problema de sempre!), sinó amb una identitat de plataforma: el service account de Kubernetes, el rol IAM de la instància cloud, un certificat mTLS de la nostra PKI de 05-01.
2. El gestor retorna un token amb TTL (temps de vida) i, per a molts secrets, un lease: el secret en si caduca (pensa en credencials de BD generades al vol, vàlides 1 hora).
3. L'app renova el lease mentre viu; en morir, el secret expira sol. És la mateixa moralitat de les vides curtes dels certificats de 05-03 aplicada a tots els secrets.

Amb la llibreria hvac (client Python de Vault) el codi queda així — tracta aquest exemple com a flux, no com a lligam a un proveïdor:

Detalls a saborejar: el ciphertext del motor transit comença per vault:v2: — versionat del format, exactament com el nostre byte 0x01 de medinube.cripto. Tothom arriba a la mateixa conclusió: sense versió no hi ha rotació.

Nota de compliment: per a MediNube, el gestor de secrets no és només bona enginyeria: el RGPD exigeix "mesures tècniques adequades" (art. 32), i davant una auditoria, el registre d'accessos del gestor és l'evidència de qui va poder tocar la clau dels historials. Coordina l'elecció de nivell amb el teu responsable de seguretat i el teu DPO.

A 02-03 vam dissenyar el format v1 = 0x01 || nonce(12) || xifrat+tag amb AAD f"pacient={id};format=v1" i vam dir que aquell byte de versió "algun dia ens salvaria". Avui és aquell dia: cal rotar la clau mestra d'historials (bona higiene periòdica, i obligatori si sospites d'un compromís). El pla, gràcies al versionat:

1. Es crea la clau nova al gestor (o una nova versió de la KEK, que rexifra les DEK).
2. Es defineix v2: format idèntic, byte 0x02, AAD format=v2, clau nova.
3. Escriptura: tot xifrat nou surt en v2.
4. Lectura: desxifrar_historial mira el primer byte i tria la clau. v1 continua sent llegible.
5. Rexifrat progressiu: un job de fons llegeix cada historial v1, el desxifra i el reescriu en v2. Sense parada de servei.
6. Quan no queda cap v1 a la BD, la clau vella es destrueix (o s'arxiva segons política de retenció).

Sense aquell byte inicial, la rotació hauria exigit endevinar amb quina clau s'havia xifrat cada fila (provar i capturar excepcions: lent i lleig) o rexifrar-ho tot de cop amb el servei aturat. La regla d'or 8 —criptoagilitat— acaba de pagar-se sola.

A 03-03 vam deixar el pepper "per quan tinguéssim un lloc segur on desar-lo". Ja el tenim. Recordatori: la sal va junt al hash a la BD (és pública); el pepper és un secret global que viu fora de la BD, de manera que un bolcat de la base de dades no basti per atacar els hashes fora de línia. La forma correcta no és concatenar, és HMAC (03-02):

Ara MalloryClinic necessita dues bretxes (la BD i el gestor de secrets) per muntar un atac de diccionari. Compte: el pepper és difícil de rotar (caldria refer el hash al següent inici de sessió de cada usuari, com la migració de 03-03), així que protegeix-lo bé des del principi.

El runbook de l'incident de 05-03 era reactiu. La versió madura és impedir la filtració abans del commit i detectar-la a CI:

Complements imprescindibles:

• .gitignore defensiu: .env, *.pem, *.key, credentials.json han d'estar ignorats abans que existeixin.
• Escaneig de l'historial ja publicat: gitleaks sobre tot l'historial descobreix secrets filtrats fa mesos. Si apareix alguna cosa, aplica el runbook de 05-03 generalitzat: rotar primer (el secret ja es considera compromès), després netejar l'historial, avisar [email protected] i buscar usos sospitosos als logs. Netejar l'historial sense rotar és teatre.
• Redacció als logs: filtres al logger que emmascarin valors amb aspecte de secret.

• Error: esborrar el commit i donar-se per salvat. El secret continua al reflog, als forks, a les memòries cau dels escàners. L'única resposta vàlida a una filtració és la rotació.
• Error: autenticar l'app davant Vault amb un token hardcodejat. Has mogut el problema, no l'has resolt. Fes servir identitat de plataforma (IAM, service account, mTLS).
• Error: passar historials sencers pel KMS. El KMS xifra claus (DEK), no dades. L'envelope encryption existeix justament per a això.
• Error: un sol secret "per a tot". Una clau per propòsit (regla que ja apliquem amb HKDF a 02-04): així una filtració no arrossega tot el sistema, i cada clau es pot rotar per separat.
• Consell: mesura la teva maduresa amb la taula de nivells i puja un esglaó cada vegada. Passar del nivell 0 al nivell 1 en una tarda elimina el 80 % del risc immediat.
• Consell: tracta l'inventari de secrets com a documentació viva. Cada secret nou entra a la taula amb el seu propietari, el seu impacte i el seu pla de rotació.

1. Auditoria expressa: clona (mentalment o de veritat) un projecte teu i localitza els seus secrets. Classifica'ls amb la taula de nivells de maduresa: en quin nivell està cadascun? Quin és el salt de nivell més urgent?
2. Rotació amb versionat: partint del desxifrar_historial multi-versió d'aquesta lliçó, escriu xifrar_historial_v2 i l'esquelet del job de rexifrat progressiu rexifrar_pendents(lot=100) que busca blobs que comencen per 0x01, els desxifra i els reescriu en v2.
3. Caçador de secrets: escriu una expressió regular per detectar en pre-commit les claus d'API de MediNube (sk_live_ + 16 hex) i els blocs PEM de claus privades. Per què convé afegir-la també a CI encara que ja estigui al pre-commit?

1. Resposta oberta, però el patró típic: claus d'API al nivell 0 o 1, contrasenya de BD al nivell 1 o 2, certificats al nivell 2. El salt més urgent gairebé sempre és treure del codi el que estigui al nivell 0 (una tarda de feina) i afegir gitleaks a CI (una hora).

2. def xifrar_historial_v2(dades: bytes, pacient_id: str) -> bytes:
       nonce = os.urandom(12)
       aad = f"pacient={pacient_id};format=v2".encode()
       ct = AESGCM(CLAUS[0x02]).encrypt(nonce, dades, aad)
       return bytes([0x02]) + nonce + ct
   
   def rexifrar_pendents(lot: int = 100) -> int:
       files = bd.query("SELECT id, pacient_id, historial FROM historials "
                        "WHERE get_byte(historial, 0) = 1 LIMIT %s", [lot])
       for fila in files:
           dades = desxifrar_historial(fila.historial, fila.pacient_id)
           nou = xifrar_historial_v2(dades, fila.pacient_id)
           bd.execute("UPDATE historials SET historial = %s WHERE id = %s",
                      [nou, fila.id])
       return len(files)
   

   Claus del disseny: el job és idempotent (si s'interromp, la propera passada troba els que en falten), treballa per lots per no saturar la BD, i fa servir l'AAD correcte de cada versió (rexifrar canvia l'AAD de v1 a v2, per això cal desxifrar i tornar a xifrar, no "canviar el byte").

3. Patrons: sk_live_[0-9a-f]{16} i -----BEGIN( [A-Z]+)? PRIVATE KEY-----. Cal també a CI perquè els hooks de pre-commit són opcionals i locals: un company sense el hook instal·lat (o un git commit --no-verify) se'ls salta; CI és la xarxa de seguretat que ningú pot eludir.

Hem tancat la ferida per la qual sagnava tot el curs: els secrets de MediNube ja no viuen en diccionaris del codi ni en .env compartits, sinó en un gestor amb autenticació, TTL i auditoria; la clau mestra d'historials rota gràcies al versionat v1/v2 que vam sembrar al mòdul 2; el pepper per fi existeix de veritat; i gitleaks vigila que la història del privkey.pem no es repeteixi. L'envelope encryption DEK/KEK ha passat de promesa (04-05) a arquitectura.

Però tenir les claus ben guardades és només la meitat del mapa: ara cal decidir què es xifra, on i contra quina amenaça a cada racó de l'arquitectura de MediNube — del navegador d'Ana Pérez a la fila de PostgreSQL, passant per les còpies de seguretat. Aquest mapa complet del xifratge en repòs i en trànsit és la propera lliçó. Ens veiem allà.