La lliçó anterior va acabar amb una pregunta ajornada quatre vegades: tota la seguretat de TLS descansa en la validació d'un certificat, i qui respon d'aquell certificat? Aquesta lliçó obre aquella caixa i, amb ella, el que el mòdul 2 va anunciar com el problema realment difícil. La seva tesi es pot enunciar en una frase: els algorismes gairebé mai no fallen; la gestió de claus sí. AES no s'ha trencat, RSA no s'ha trencat, SHA-256 no s'ha trencat —però es filtren claus en repositoris, caduquen certificats que ningú no vigilava, es perden claus que calien per restaurar una còpia i es deixen credencials actives anys després que el seu amo se n'anés. Veuràs el cicle de vida complet d'una clau, on ha de viure, com es rota sense tallar el servei, què conté un certificat X.509, com funciona la cadena de confiança i què fa realment una autoritat de certificació.

1. La tesi: els algorismes no fallen, la gestió sí
2. Cicle de vida d'una clau
3. On viu una clau: del .env a l'HSM
4. El secret al repositori: per què esborrar el commit no basta
5. Rotació sense tallar el servei
6. Certificats X.509: què contenen exactament
7. La cadena de confiança i què valida el navegador
8. Autoritats de certificació i tipus de validació
9. ACME i Let's Encrypt: emissió i renovació automàtica
10. Revocació: CRL, OCSP, grapat i els seus límits
11. Transparència de certificats
12. PKI interna: quan muntar una CA pròpia
13. Xifratge de sobre
14. Custòdia, còpia de claus i el dilema de perdre-les

Repassa mentalment els incidents que has estudiat al curs. A Equifax (02-06) la bretxa va entrar per un pedaç pendent, però el que la va convertir en històrica va ser que un certificat caducat va deixar cec durant deu mesos el sistema que inspeccionava el trànsit. Al ransomware de Nimbus (02-06) l'atacant no va trencar res: va trobar un secret oblidat en un .env i amb ell va escalar. A la fuita per bucket mal configurat ni tan sols hi va haver criptografia implicada.

D'aquí que aquest mòdul, que ha dedicat cinc lliçons a les primitives, dediqui la més operativa a la gestió. La pregunta professional no és «quin algorisme faig servir?», sinó «on viu aquesta clau, qui la pot llegir, quan es rota i què passa si la perdo?».

Una clau no és un valor: és un objecte amb estats, i cada transició té preguntes que cal respondre per escrit.

La fase que gairebé ningú no documenta és l'última, i és la que produeix la troballa clàssica: una clau que es va donar de baixa «fa anys» i continua funcionant en un sistema oblidat.

La diferència conceptual entre gestor de secrets i KMS mereix precisió, perquè es confonen: un gestor de secrets et lliura el secret de manera controlada i auditada (l'aplicació acaba tenint el valor a la memòria); un KMS o un HSM no et lliuren res, sinó que operen per tu —«xifra això», «signa això»— i la clau mestra no surt mai. Per això el KMS és la peça correcta per a la clau mestra del xifratge de sobre (apartat 13).

Recomanació concreta per a Nimbus, coherent amb la seva mida i pressupost: gestor de secrets per a credencials de base de dades, claus d'API, secret del webhook i clau de signatura de tokens, amb injecció a l'arrencada dels contenidors i zero secrets al repositori; KMS del proveïdor cloud per a la clau mestra que protegeix les claus de dades d'adjunts, notes clíniques i còpies; mòdul segur del dispositiu per a les passkeys de la plantilla, que ja el fan servir sense que ningú el configuri; i HSM no, tret que un client o una norma sectorial ho exigeixi, perquè el seu cost no es justifica davant del risc real de Nimbus.

Aquest és l'escenari que va obrir l'escalada en el cas de ransomware de 02-06: un fitxer .env antic, amb un token d'API sense caducitat, versionat per error.

Com es detecta:

A més de l'escaneig al CI (02-04), convé una alerta que vigili els repositoris públics de l'organització i els forks.

Per què esborrar el commit no basta. És el punt que gairebé tothom entén malament:

Què significa realment rotar. No és «canviar el valor al .env». És: (1) emetre una credencial nova; (2) desplegar-la a tots els consumidors; (3) revocar l'antiga de manera efectiva, comprovant que ja no funciona; (4) revisar els registres d'ús de l'antiga des de la data en què es va exposar, buscant accessos no reconeguts; (5) documentar l'incident. Mentre no s'executi el pas 3, la credencial continua sent vàlida per molt que l'hagis esborrada del codi.

I l'ordre correcte: primer rotar, després netejar l'historial. Netejar l'historial és higiene; rotar és la contenció. Invertir l'ordre deixa la finestra oberta mentre es fa la feina llarga.

Rotar fa por perquè sembla que obliga a un tall: si canvies la clau, tot el que s'ha signat amb l'anterior deixa de validar. La solució és el període de solapament amb dues claus actives i un identificador de clau, el kid, que ja vas veure funcionant en la validació de JWT amb JWKS de 02-05.

La idea: cada objecte signat o xifrat porta escrit amb quina clau es va fer, així que el verificador pot tenir diverses claus carregades i triar la correcta.

Les quatre fases d'una rotació neta:

Punts importants: el kid ve d'un missatge no fiable, així que serveix només per seleccionar la clau, mai per decidir si validar; si el kid no és a la teva llista, es rebutja el token, sense excepcions. I una rotació que només s'executa manualment «quan toca» no s'executa: automatitza el procés i assaja'l almenys una vegada amb calma abans de necessitar-lo amb presses.

Cadències raonables per a Nimbus:

Un certificat digital és un document que uneix una clau pública a una identitat, signat per una autoritat en què el verificador confia. És la resposta a la pregunta que va quedar oberta a 03-03: de qui és aquesta clau pública?

Camp a camp, amb el que cal mirar en una revisió:

L'error de comprensió més freqüent és creure que el navegador compara el domini amb el CN. No ho fa des de fa anys: compara amb el SAN. Un certificat sense el domini al SAN produeix un error de nom per molt correcte que sigui el CN.

Per què existeix la intermèdia. La clau de l'arrel és massa valuosa per fer-la servir cada dia: viu desconnectada, en un HSM, i només se'n treu en cerimònies auditades. La intermèdia fa la feina diària i, si es compromet, es revoca i se substitueix sense invalidar l'arrel —que està instal·lada en milers de milions de dispositius i no es pot canviar fàcilment—.

Què comprova exactament el client en validar, per ordre:

1. Signatura de cada graó: la fulla està signada per la intermèdia, la intermèdia per l'arrel.
2. L'arrel és al magatzem de confiança del sistema o del navegador.
3. Vigència: la data actual cau dins del Validity de tots els certificats de la cadena.
4. Nom: el domini sol·licitat coincideix amb alguna entrada del SAN de la fulla.
5. Usos: Key Usage i Extended Key Usage permeten autenticació de servidor TLS.
6. Basic Constraints: els intermedis són CA:TRUE i la fulla CA:FALSE.
7. Revocació: consulta OCSP o grapat (apartat 10).
8. Transparència: els navegadors exigeixen SCTs vàlids (apartat 11).
9. Signatura de l'encaixada: el CertificateVerify de 03-05 demostra que el servidor posseeix la clau privada. Sense aquest pas, presentar un certificat aliè bastaria.

L'error operatiu més comú és enviar només la fulla i oblidar la intermèdia. Els navegadors d'escriptori solen recuperar-la i dissimulen la fallada; molts clients d'API, l'app mòbil i les llibreries HTTP no, i el resultat és la incidència clàssica de «funciona al navegador però falla a l'app». Per això se serveix fullchain.pem, no cert.pem.

Una CA és una organització en què els fabricants de sistemes operatius i navegadors han decidit confiar, després d'auditories periòdiques. El seu negoci és verificar identitats abans de signar.

La conclusió, que sorprèn molta gent: des del punt de vista tècnic i de l'experiència de l'usuari, DV, OV i EV són equivalents. Els navegadors van deixar de destacar visualment l'EV precisament perquè els estudis mostraven que els usuaris no percebien la diferència, mentre que el cost i la fricció sí que eren reals.

Per a Nimbus: certificats DV emesos amb ACME. Només es pot plantejar OV si un client corporatiu ho exigeix per contracte, i convé saber argumentar que aquella exigència poques vegades aporta seguretat tècnica.

I una limitació honesta del model: qualsevol de les CA del magatzem pot emetre un certificat per a qualsevol domini. Ha passat, per compromís o per error d'una CA. Les respostes a aquest risc són la transparència de certificats (apartat 11), el registre CAA al DNS —que declara quines CA poden emetre per al teu domini— i, en casos concrets, el pinning amb els seus riscos (03-05).

ACME és el protocol que automatitza l'emissió: el client demostra el control del domini superant un repte i rep el certificat sense intervenció humana.

Dos reptes i quan fer servir cadascun: HTTP-01 serveix un fitxer sota /.well-known/acme-challenge/ i és el més simple, però exigeix el port 80 accessible i no permet comodins; DNS-01 publica un registre TXT, funciona sense exposar res i sí que permet comodins, a canvi de necessitar credencials del teu proveïdor de DNS —que al seu torn són un secret que cal gestionar—.

Un certificat caducat és una incidència de disponibilitat. El servei no es degrada: cau, amb un avís de seguretat a pantalla completa que a més destrueix la confiança de l'usuari. I recorda Equifax (02-06): allà el certificat caducat no va tombar un web, sinó que va encegar el sistema d'inspecció de trànsit durant deu mesos, cosa que va permetre que l'exfiltració passés desapercebuda. D'aquí la regla transferible d'aquella lliçó: tot control necessita un control que verifiqui que continua funcionant.

Aplicat a Nimbus: la renovació automàtica no és el control suficient; el control és el monitoratge extern de la data de caducitat, que alerta a 30 i a 7 dies i funciona encara que el procés de renovació s'hagi trencat en silenci. Els tres motius habituals de trencament: el temporitzador es va desactivar després d'una migració, el repte HTTP-01 va deixar de resoldre per un canvi de configuració, o el certificat es renova però ningú no recarrega el servei que el serveix.

Si una clau privada es filtra, el certificat continua sent criptogràficament vàlid fins a la seva caducitat. Cal un mecanisme per dir «aquest ja no val».

La conseqüència incòmoda cal dir-la clarament: la revocació funciona pitjor del que sembla. Com que els clients fallen en obert per no trencar la navegació quan la CA no respon, un atacant que controla la xarxa pot simplement bloquejar la consulta OCSP. Per això la indústria s'ha mogut cap a certificats de vida curta —60 o 90 dies, i baixant— com a substitut pràctic de la revocació: si el certificat caduca aviat, la finestra de dany és curta per construcció.

Què ha de fer Nimbus si es filtra la clau privada del seu certificat: (1) emetre un certificat nou amb una clau nova —mai reutilitzar la clau compromesa—; (2) desplegar-lo; (3) revocar l'anterior, sabent que la revocació és una mesura parcial; (4) revisar registres a la recerca d'ús indegut; (5) analitzar com es va filtrar la clau.

La transparència de certificats (CT) respon al risc de l'apartat 8: que una CA emeti un certificat per al teu domini sense el teu coneixement. Tota CA pública ha de publicar cada certificat que emet en registres públics, append-only i auditables —la mateixa idea que la taula d'auditoria de Nimbus, amb INSERT però sense UPDATE (01-04)—, i el navegador exigeix proves d'aquesta publicació (els SCTs que vas veure al certificat de l'apartat 6).

Això no impedeix una emissió indeguda, però la fa impossible d'amagar. I aquí hi ha el seu valor per a Nimbus: converteix un atac invisible en un de detectable.

Com ho fa servir Nimbus, en concret: (1) subscriure's al monitoratge de CT per a nimbusreservas.example i tots els seus subdominis, amb notificació a la Lucía i a la Marta; (2) revisar cada alerta, perquè un certificat que Nimbus no ha sol·licitat és un incident que s'activa immediatament; (3) publicar un registre CAA al DNS declarant l'única CA autoritzada, cosa que a més redueix el soroll del monitoratge; i (4) fer servir CT també com a inventari, perquè la llista de certificats emesos revela subdominis oblidats que ningú no recordava, alguns amb serveis exposats —és a dir, és una eina de reducció de superfície d'atac (01-04) a més de detecció—.

Per a l'mTLS entre serveis interns (03-05) no serveixen les CA públiques, perquè no emeten certificats per a noms interns ni per a identitats de servei. L'alternativa és una CA privada l'arrel de la qual s'instal·la als sistemes propis.

Els riscos de fer-ho malament, que són seriosos: una arrel interna instal·lada als portàtils pot emetre certificats vàlids per a qualsevol domini, inclosos els de la banca de l'empleat; si la seva clau es filtra, l'atacant pot suplantar qualsevol lloc davant d'aquells equips. A més, una CA sense revocació operativa, sense renovació automatitzada o sense inventari es converteix en una font de caigudes, i una arrel amb vint anys de validesa i sense pla de substitució és un deute que hereta qui vingui després.

Regles mínimes si Nimbus la munta: arrel fora de línia amb la clau protegida i respatllada; intermèdia per a l'emissió diària; vides curtes i emissió automatitzada (per exemple, amb la PKI d'un gestor de secrets, que fa aquesta feina bé); abast acotat a noms interns, mai a dominis públics; inventari de tots els certificats emesos; i un pla escrit de rotació de l'arrel.

El xifratge de sobre (envelope encryption) és el patró estàndard per xifrar moltes dades amb poques claus mestres, i és l'aplicació del xifratge híbrid de 03-03 a l'emmagatzematge.

Com funciona a Nimbus, pas a pas: (1) en pujar un adjunt, l'API demana al KMS una clau de dades i rep dues versions, una en clar per fer servir ara i una altra xifrada amb la clau mestra; (2) xifra l'adjunt amb la clau en clar fent servir AES-256-GCM amb nonce únic i AAD amb el tenant_id (03-02); (3) descarta la clau en clar de la memòria i desa al costat de l'objecte la clau de dades xifrada, el nonce i l'identificador de la clau mestra; (4) per desxifrar, demana al KMS que desxifri la clau de dades, la fa servir i la torna a descartar.

Els quatre avantatges que expliquen per què és el patró dominant:

Aquesta última fila és un control de detecció infravalorat: si algú intenta desxifrar deu mil adjunts en una hora, el registre del KMS ho mostra encara que l'aplicació estigui compromesa.

Aquí hi ha la tensió més incòmoda de tota la gestió de claus, i no té una solució elegant:

No existeix un punt mitjà automàtic: és una decisió de negoci que cal prendre explícitament i per escrit, diferent per a cada tipus de clau.

Bones pràctiques de custòdia, quan la resposta és sí:

• Còpia xifrada i en una ubicació diferent de les dades que protegeix, amb control d'accés independent.
• Repartiment entre diverses persones quan la clau és crítica: la reconstrucció exigeix, per exemple, dos de tres custodis. Evita el punt únic de fallada i també el punt únic d'abús.
• Assaig de recuperació almenys una vegada l'any, documentat. Una custòdia que mai no s'ha provat és una suposició, exactament igual que una còpia de seguretat no restaurada (02-04).
• Procediment escrit de qui pot sol·licitar la recuperació, qui l'aprova i com es registra.

Nota de validació professional. Quan la clau protegeix dades que revelen informació de salut —com les notes clíniques de les clíniques clientes de Nimbus—, el disseny de custòdia té implicacions legals: qui pot accedir a la dada, amb quina base jurídica, durant quant de temps es conserva i què passa amb les claus al final del període de conservació. La destrucció de la clau pot ser, de fet, un mecanisme vàlid de supressió de dades, però això s'ha de validar amb el responsable de protecció de dades i amb assessoria jurídica abans de recolzar-s'hi. El marc normatiu es tracta a 06-03.

1. Secrets al repositori. El més freqüent i el més car. Escàner al CI i ganxos de pre-commit.
2. Creure que esborrar el commit resol alguna cosa. Només la rotació efectiva ho resol; i primer es rota, després es neteja.
3. No saber quantes claus hi ha. Sense inventari —clau, propòsit, amo, ubicació, data de rotació— no hi ha gestió possible.
4. No rotar mai «perquè funciona». Una clau sense rotació acumula exposició: cada persona que va passar per l'equip la va poder veure.
5. Rotar sense kid ni solapament. Converteix una operació rutinària en un tall de servei, i per això es deixa de fer.
6. Desar la clau al costat de la dada xifrada. Xifratge decoratiu. Especialment greu amb les còpies.
7. Confiar només en la renovació automàtica de certificats. Cal monitoratge extern de la caducitat, amb alerta a 30 i 7 dies.
8. Servir només la fulla sense la intermèdia. Funciona al navegador i falla a l'app mòbil.
9. Validar el CN en lloc del SAN.
10. Suposar que la revocació funciona. Falla en obert. Vides curtes i rotació són la defensa real.
11. Muntar una CA interna sense mantenir-la. Una arrel interna mal custodiada és una clau mestra per atacar els teus propis equips.
12. No fer còpia de la clau mestra de dades, o fer-la i no provar-la mai. Totes dues coses acaben igual de malament.

Consells

• Comença per l'inventari: llista totes les claus, secrets i certificats amb amo, propòsit, ubicació i data de rotació. És una tarda de feina i canvia per complet la conversa.
• Automatitza el que puguis: emissió ACME, renovació, rotació amb solapament, escaneig de secrets. El que és manual no es fa.
• Assaja una rotació completa i una recuperació des de custòdia abans de necessitar-les.
• Aplica el principi de propòsit únic: una clau, una funció. Deriva amb HKDF (03-02) en lloc de reutilitzar.
• I recorda la tesi: si algun dia tens un incident criptogràfic, el més probable és que la causa sigui una clau mal gestionada, no un algorisme trencat.

Un escaneig detecta que fa catorze mesos es va pujar al repositori un fitxer deploy/.env.produccio amb la contrasenya de PostgreSQL, la clau de l'API de la passarel·la i el secret de signatura de tokens. El repositori és privat, amb accés dels cinc de l'equip i de dues persones de la consultora (A-19).

Es demana: (a) ordena les accions de les primeres quatre hores i justifica'n l'ordre; (b) explica què significa exactament rotar cadascun dels tres secrets i quin risc de tall té cada rotació; (c) indica quins registres revisaries i amb quina finestra temporal; (d) digues si això és un incident de seguretat notificable i quina informació necessites per decidir-ho; (e) proposa les tres mesures preventives que impedeixen que torni a passar.

L'app mòbil de Nimbus falla amb «certificat no vàlid» mentre el web funciona correctament al navegador. La sortida d'openssl s_client mostra:

Es demana: (a) diagnostica la causa exacta; (b) explica per què el navegador funciona i l'app no; (c) indica la correcció concreta al servidor; (d) proposa la comprovació automàtica que detectaria aquesta fallada abans que la reporti un client; (e) enumera tres motius diferents més pels quals un certificat vàlid pot fallar en un client.

La Marta demana un document d'una pàgina amb l'esquema de gestió de claus.

Es demana: construeix una taula amb almenys sis claus o secrets de Nimbus (signatura de tokens, xifratge d'adjunts, xifratge de còpies, credencials de base de dades, secret del webhook, certificat TLS) indicant per a cadascun: on viu, qui hi pot accedir, cadència de rotació, si té còpia de seguretat i on, i què passa si es perd. Justifica després les dues decisions més discutibles de la teva taula.

Exercici 1

(a) Primeres quatre hores, per ordre:

1. Considerar els tres secrets compromesos. Sense discussió: catorze mesos i nou persones amb accés, incloses dues d'externes.
2. Rotar primer la clau de la passarel·la de pagament. És la de més impacte econòmic directe i la rotació és la menys disruptiva (es coordina amb el proveïdor).
3. Rotar el secret de signatura de tokens amb el mecanisme de solapament de l'apartat 5, per no expulsar tots els usuaris.
4. Rotar la contrasenya de PostgreSQL, coordinada amb un desplegament, ja que afecta tots els processos que connecten.
5. En paral·lel, revisar registres d'ús dels tres secrets.
6. Després, netejar l'historial del repositori i comunicar-ho a l'equip i a la consultora.

L'ordre respon al fet que rotar és contenció i netejar l'historial és higiene: mentre la credencial continuï sent vàlida, esborrar el commit no canvia res.

(b) Què significa rotar cadascun:

(c) Registres i finestra. Finestra: des de la data del commit (catorze mesos) fins avui, no només des de la detecció. Registres: accessos i transaccions al panell de la passarel·la; connexions a PostgreSQL per origen, usuari i horari inusual; emissió i ús de tokens amb signatures anòmales; accessos al bucket A-05; i activitat del repositori (clons, forks, accessos dels comptes de la consultora). Es busquen orígens desconeguts, horaris fora de patró i volums anòmals, igual que en l'anàlisi de 02-06.

(d) És notificable? És un incident de seguretat amb certesa. És notificable si hi ha indicis d'accés no autoritzat a dades personals. Per decidir-ho calen: registres suficients i amb retenció adequada per cobrir catorze mesos (si no n'hi ha, això ja és una troballa greu i empeny cap a la prudència), evidència d'accessos anòmals, i l'abast de les dades assolibles amb aquelles credencials —que aquí inclou dades que revelen indirectament salut—. La decisió es pren amb assessoria jurídica i amb el responsable de protecció de dades, dins del termini de 72 hores de l'RGPD (06-03).

(e) Tres mesures preventives: (1) escàner de secrets al CI i ganxo de pre-commit que bloquegi el commit, més un .gitignore correcte; (2) gestor de secrets amb injecció a l'arrencada, de manera que no existeixi cap .env amb valors reals; (3) rotació automàtica programada amb solapament, perquè cap credencial no acumuli catorze mesos de vida i perquè rotar sigui una operació rutinària i no una emergència.

Exercici 2

(a) Causa exacta. El servidor envia només el certificat de fulla (0 s:), sense el certificat intermedi de Let's Encrypt. El codi 20 significa literalment que el client no pot obtenir l'emissor local: no pot construir la cadena fins a una arrel de confiança.

(b) Per què el navegador sí que funciona. Els navegadors d'escriptori solen tenir l'intermedi a la memòria cau de visites anteriors o el descarreguen mitjançant l'extensió Authority Information Access del certificat. Aquella recuperació és una cortesia, no part de la validació estàndard, i moltes llibreries HTTP i clients mòbils no la implementen: exigeixen que el servidor enviï la cadena completa, com mana l'estàndard.

(c) Correcció. Configurar ssl_certificate apuntant a fullchain.pem (fulla + intermèdia), no a cert.pem, i recarregar Nginx. Verificar després amb openssl s_client, on han d'aparèixer els dos graons i Verify return code: 0 (ok).

(d) Comprovació automàtica. Una tasca programada externa que, per a cada domini, executi openssl s_client sense fer servir el magatzem local d'intermedis i verifiqui tres coses: codi de retorn 0, nombre de certificats a la cadena més gran que un, i dies restants de validesa per sobre del llindar. Alerta a la Lucía si falla qualsevol dels tres. És el «control que verifica que el control funciona» d'Equifax aplicat aquí.

(e) Tres motius més: (1) el domini no és al SAN (encara que el CN sigui correcte); (2) data del client desajustada, que fa que un certificat vigent sembli caducat o encara no vàlid —freqüent en mòbils i en dispositius acabats d'instal·lar—; (3) pinning desactualitzat a l'app després d'una renovació de certificat (03-05). Un quart d'habitual: l'arrel corresponent no és al magatzem d'un sistema antic sense actualitzar.

Exercici 3

Les dues decisions més discutibles:

1. No fer còpia de la clau de signatura de tokens. Discutible perquè perdre-la expulsa tots els usuaris alhora. Es justifica perquè l'impacte és molèstia, no pèrdua de dades: els usuaris tornen a entrar. Una còpia, en canvi, seria una superfície permanent per a un secret que permet suplantar qualsevol usuari. El risc de la còpia supera el del tall.
2. Desar la clau de les còpies en un compte diferent, amb dos de tres custodis. Discutible per la fricció que afegeix a una restauració urgent: si la Lucía està de baixa i falta un custodi, la restauració es retarda. Es justifica per la lliçó directa del ransomware de 02-06: la clau i les còpies al mateix entorn significa que qui compromet producció s'emporta totes dues. La mitigació de la fricció és tenir tres custodis i assajar la recuperació una vegada l'any, de manera que el procediment estigui provat abans de necessitar-lo.

Has entrat en el problema difícil i en surts amb la seva tesi interioritzada: els algorismes gairebé mai no fallen; la gestió de claus sí. Ho has vist en els incidents del curs —el certificat caducat d'Equifax que va encegar la detecció deu mesos, el .env de Nimbus que va obrir l'escalada— i en el contrast entre el que la gent tem i el que realment passa. Tens el cicle de vida complet d'una clau, amb les preguntes que cal respondre a cada fase i la constatació que la fase que ningú no documenta —la destrucció— és la que produeix credencials actives anys després. Saps on pot viure una clau, del codi font a l'HSM, amb la distinció precisa entre un gestor de secrets, que et lliura el valor, i un KMS o HSM, que operen per tu sense lliurar-te res; i amb la recomanació concreta per a Nimbus: gestor de secrets per a credencials, KMS per a la clau mestra de dades, mòdul del dispositiu per a les passkeys i HSM només si algú ho exigeix.

Has après què significa realment rotar —emetre, desplegar, revocar de manera efectiva, revisar registres i documentar—, per què esborrar el commit no revoca res i per què es rota abans de netejar l'historial; i has vist com es rota sense tallar el servei amb solapament i kid, la mateixa peça que sostenia la validació de JWT de 02-05. A la part de PKI has obert un certificat X.509 camp a camp i saps que el que valida el navegador és el SAN i no el CN; entens la cadena de confiança i per què existeix la intermèdia, els nou passos que comprova el client i la fallada clàssica de servir la fulla sense la intermèdia; saps que DV, OV i EV són tècnicament equivalents i que qualsevol CA del magatzem pot emetre per al teu domini; manejes ACME i saps que la renovació automàtica no és el control suficient —el control és el monitoratge extern de la caducitat—; coneixes els límits reals de la revocació, que falla en obert i ha estat substituïda a la pràctica per certificats de vida curta; i saps fer servir la transparència de certificats per detectar emissions indegudes i, de passada, com a inventari de subdominis oblidats. Hi afegeixes quan té sentit una PKI interna i els seus riscos, el xifratge de sobre amb clau de dades i clau mestra —que a més deixa auditoria per objecte al KMS— i el dilema honest de la custòdia: copiar de més multiplica la superfície, copiar de menys converteix el xifratge en pèrdua definitiva, i no hi ha punt mitjà automàtic, només una decisió escrita per tipus de clau.

Ja tens totes les peces del mòdul: les primitives, els protocols que les assemblen i la gestió que les sosté. A Aplicacions de la Criptografia (03-07) tanquem recorrent el sistema de Nimbus de punta a punta i assenyalant què protegeix què: el xifratge en repòs amb els seus tres nivells —disc, base de dades i aplicació— i el punt clau que el xifratge de disc no protegeix davant d'una API compromesa; el xifratge camp a camp de les notes clíniques amb el problema pràctic que introdueix, que ja no es pot cercar ni indexar; les còpies xifrades amb la clau fora de l'entorn; la signatura d'artefactes al CI/CD i la seva connexió amb SolarWinds; els tokens i les URL signades de 120 segons explicades per dins; i la diferència real entre pseudonimització i anonimització, amb el motiu pel qual el hash d'un DNI no és anonimització.