La lliçó anterior va acabar assenyalant dos deutes que arrossegues des del Mòdul 5, i tots dos són criptogràfics. El primer: db_password està escrita en clar dins de /etc/tramontana/app.conf, i ja has vist que qualsevol fallada de permisos converteix això en una fuita de credencials que cap vigilància no evita. El segon: el trànsit de reserves —amb els noms dels hostes que tanta cura has posat a protegir dins de les còpies— viatja sense xifrar pel port 8080. Aquesta lliçó resol totes dues, perquè són el mateix problema vist des de dos angles: guardar un secret i demostrar una identitat.

Són dues parts clarament separades. A la primera aprendràs a treure un secret d'un fitxer de configuració i a gestionar-lo amb les eines que el sistema ja et dona: permisos estrictes, EnvironmentFile i LoadCredential de systemd, GPG, pass i LUKS. A la segona, què és realment un certificat, com es genera, es llegeix i es verifica, com se n'obté un de gratuït i renovat automàticament de Let's Encrypt, i com vigilar-ne la caducitat — que és la fallada més ximple i més freqüent de producció.

Avís d'abast. Aquí s'obté, s'instal·la i es verifica el material criptogràfic de reserves.tramontana.example. El servidor web que el servirà —Nginx com a servidor intermediari invers davant de l'aplicació del port 8080— es munta al projecte 08-01. És deliberat: el xifratge en trànsit es prepara i es prova ara perquè al Mòdul 8 sigui un detall de configuració i no un tema nou.

Advertiment de compliment. El xifratge de dades personals, en trànsit i en repòs, no és una millora opcional: el RGPD l'exigeix com a mesura tècnica apropiada (art. 32). reserves.csv conté noms d'hostes. En un entorn real, el disseny de la gestió de claus i de la seva custòdia l'ha de revisar el responsable de seguretat, i les decisions sobre dades personals el responsable de protecció de dades.

1. Què és un secret i on no va mai
2. El mínim decent: permisos, EnvironmentFile i LoadCredential
3. Xifratge en repòs de secrets: GPG i pass
4. Xifratge de disc amb LUKS
5. Gestors centralitzats de secrets
6. Rotació de credencials
7. Què garanteix TLS i què conté un certificat
8. Generar, llegir i verificar material criptogràfic amb OpenSSL
9. Let's Encrypt i la renovació automàtica
10. Bones pràctiques de TLS, custòdia de la clau i vigilància de la caducitat

Un secret és una dada el valor de la qual depèn que només la conegui qui ha de fer-ho: una contrasenya, una clau d'API, un testimoni, una clau privada, la frase de pas d'un dipòsit de còpies. Es distingeix d'una dada sensible qualsevol perquè el seu compromís no és un problema de privacitat sinó de control: qui el té pot actuar en nom teu.

La primera regla és negativa, i convé entendre el perquè de cada punt perquè cadascun correspon a una fuita real i freqüent:

Els dos primers mereixen una demostració, perquè la gent els subestima:

Sobre el segon cas convé ser precís, perquè hi ha un matís que sovint es malinterpreta: /proc/<pid>/environ té permisos 0400 i només el poden llegir el propietari del procés i root. Això fa que les variables d'entorn siguin molt millors que la línia d'ordres, però no les converteix en un bon lloc: s'hereten a tot procés fill, apareixen en abocaments de memòria i en traces d'error de molts entorns de treball, i qualsevol escalada a root les exposa totes de cop.

No cal infraestructura per millorar substancialment. Amb el que ja saps de permisos (02-07), usuaris de servei (05-01) i unitats de systemd (05-05), hi ha tres nivells, cadascun millor que l'anterior.

La idea és separar el secret de la configuració: app.conf deixa de contenir la contrasenya i passa a ser un fitxer llegible pel grup, mentre el secret viu en un fitxer a part amb permisos mínims.

I la unitat el carrega a l'entorn del servei, sense que aparegui mai a la línia d'ordres:

Recorda la convenció del curs: app.conf està chattr +i, així que per editar-lo cal treure l'atribut, canviar, i tornar-lo a posar — amb la seva còpia prèvia:

Això ja tanca l'exposició de l'últim exercici de 06-04: un chmod 644 accidental sobre app.conf ja no filtra res. Però el secret continua en clar al disc i a l'entorn del procés.

Ubuntu 24.04 porta la mecànica de credencials de systemd, que és clarament superior: el secret es lliura al servei en un fitxer dins d'un tmpfs privat accessible només per aquell servei, no s'hereta als fills i no apareix a l'entorn.

El servei rep la ruta a la variable CREDENTIALS_DIRECTORY i llegeix el fitxer:

La diferència amb EnvironmentFile en una taula, perquè decideix l'elecció:

El pas que tanca el cercle: systemd-creds xifra el secret amb una clau derivada del sistema (i del TPM si existeix), de manera que el fitxer al disc ja no conté el secret en clar.

Aquell 0 és el resultat que buscaves. El tercer incident obert queda tancat: la contrasenya ja no està en clar en cap fitxer de configuració, no és a l'entorn del procés, no és llegible per cap usuari del sistema, i —conseqüència important— tampoc no viatja en clar dins de la còpia de restic, perquè el que es copia és el fitxer xifrat.

Una limitació honesta: la clau de xifratge de systemd-creds està lligada a la màquina (/var/lib/systemd/credential.secret). Això és exactament el que vols davant de la fuita d'un fitxer, però significa que el fitxer .cred no es pot restaurar en un servidor reconstruït. El secret original ha d'estar també en un lloc del qual el puguis recuperar: això és la secció següent, i és el que ha de constar al manual d'operació de 05-08.

Necessites un lloc on el secret original visqui xifrat, recuperable per una persona autoritzada, amb historial de canvis i fora del servidor. La resposta clàssica a Linux és GPG, i pass construïda al damunt.

La diferència pràctica és de gestió: el mode simètric obliga a transmetre la frase de pas per un altre canal i a canviar-la quan algú deixa l'equip; l'asimètric permet xifrar per a diverses persones i revocar l'accés d'una sense tornar a xifrar per a les altres. En un equip, sempre asimètric.

Fixa't en el > /dev/shm/recuperat.txt del desxifratge: /dev/shm és memòria, no disc. Escriure un secret desxifrat al sistema de fitxers deixa restes recuperables fins i tot després d'esborrar-lo.

pass guarda cada secret en un fitxer xifrat amb GPG dins d'un dipòsit git. És simple, auditable i no depèn de cap servei.

Tres detalls que el fan apte per a producció:

• Historial complet amb git. pass git log --oneline mostra cada alta, canvi i baixa, amb data i autor. És la traçabilitat de la rotació.

• Els fitxers estan xifrats, així que el dipòsit es pot sincronitzar a un remot sense exposar res: pass git remote add origin ... i pass git push. Això resol el «fora del servidor».

• Composició amb scripts. pass escriu a stdout, així que encaixa amb el del Mòdul 4:

  # Generar el fitxer .cred des de pass, sense que el secret toqui el disc en clar
  $ pass tramontana/produccio/db_password \\
      | sudo systemd-creds encrypt --name=db_password - \\
             /etc/tramontana/secrets/db_password.cred
  

  Aquella canonada és la resposta al problema de recuperabilitat de l'apartat anterior: pass és la font de veritat, systemd-creds la còpia operativa lligada a la màquina, i reconstruir el servidor consisteix a tornar a executar aquesta línia.

I l'advertiment obvi: la clau GPG privada i la seva frase de pas són ara la clau mestra. La seva còpia de seguretat (gpg --export-secret-keys, xifrada, en un mitjà físic separat) i la seva custòdia són part del manual d'operació, i la seva pèrdua equival a perdre tots els secrets.

Els secrets ja estan xifrats, però /srv/tramontana/backups conté reserves.csv amb noms d'hostes. Si algú s'endú el disc —o la imatge de la VM, o el disc d'un servidor retirat sense esborrar—, els permisos del sistema de fitxers no protegeixen res: es munten en una altra màquina i es llegeix tot.

LUKS és l'estàndard de xifratge de bloc a Linux. Xifra el dispositiu complet, per sota del sistema de fitxers.

I aquí hi ha el problema real, que cal plantejar sense adorns: un volum LUKS necessita una frase de pas per obrir-se, i un servidor ha d'arrencar tot sol a les 3 de la matinada. Les opcions, amb el seu compromís:

Per al laboratori, l'opció del fitxer de clau amb nofail és raonable, i és important entendre exactament què protegeix:

Què protegeix i què no protegeix, dit amb precisió: protegeix contra el robatori o la retirada del disc de dades, contra l'accés a la imatge de la VM aturada, i contra la recuperació de dades d'un disc llençat. No protegeix contra un atacant que compromet el servidor en marxa, perquè per a ell el volum està muntat i llegible com per a qualsevol. És xifratge en repòs, no xifratge en ús, i presentar-ho com una altra cosa davant de la Marta seria enganyar-la.

Fixa't a més en la composició amb l'anterior: restic ja xifra el seu dipòsit amb la seva pròpia contrasenya —que ara viu a pass—, així que les còpies tenen dues capes independents. I per a la destinació externa de la regla 3-2-1, el xifratge de restic és el que de debò importa, perquè el mitjà remot no el controles tu.

Tot l'anterior és correcte per a una màquina. Quan n'hi ha diverses, apareix un problema nou: distribuir i rotar secrets en N servidors sense copiar-los a mà.

El salt de rendibilitat té un llindar bastant identificable: quan rotar una credencial deixa de ser una tasca de cinc minuts. Amb un servidor, rotar és canviar pass, regenerar el .cred i reiniciar el servei. Amb vint, sense un gestor central, és una operació manual propensa a deixar màquines a mitges — que és el pitjor dels mons, perquè tens el cost de la rotació sense la garantia.

sops mereix una menció concreta perquè serà rellevant a 07-06: permet tenir a git un fitxer de variables d'Ansible en què les claus són llegibles i els valors estan xifrats, de manera que el diff d'un canvi de configuració continua sent revisable sense exposar els secrets.

L'altre avantatge de Vault que no tenen les altres són els secrets dinàmics: en lloc d'una contrasenya de base de dades fixa, genera credencials amb validesa d'una hora, específiques de cada procés. Un secret que caduca sol no necessita rotació, i una fuita té una finestra d'explotació mínima. És el model cap al qual tendeix la indústria.

Rotar és canviar un secret per un altre de nou. És obligatori perquè la probabilitat que un secret estigui compromès només creix amb el temps: cada còpia, cada registre, cada persona que el va veure, cada màquina on va estar. Rotar limita la finestra d'explotació d'una fuita que potser ja va passar i no ho saps.

Quan rotar, en ordre d'urgència:

1. Immediatament, davant de qualsevol sospita d'exposició. És el que vas fer amb db_password quan va aparèixer a la còpia amb permisos 644, i el que faria el desenllaç B de l'últim exercici de 06-04.
2. Quan algú amb accés deixa l'equip. No és desconfiança: és que el control sobre qui coneix el secret s'ha perdut.
3. Periòdicament, amb un termini escrit. Per a una credencial de servei com aquesta, entre 90 dies i un any és l'habitual, segons l'exposició.

El procediment sense tallar el servei és la part amb contingut tècnic, i depèn d'una propietat del sistema de destinació: que accepti dues credencials vàlides alhora. PostgreSQL no ho fa amb el mateix compte, així que el patró és de dos usuaris:

L'ordre és el que importa: crear, aplicar, verificar, retirar. Invertir els dos últims passos deixa el servei caigut fins que algú se n'adoni, i a les 3 de la matinada això són hores. És la mateixa disciplina de «mesurar abans i després» que vas aplicar a 05-07.

Una generació de contrasenyes decent, per no cedir a la temptació d'inventar-les:

Segona meitat de la lliçó. TLS (Transport Layer Security, el successor d'SSL) dona tres garanties, i convé separar-les perquè la tercera és la que gairebé tothom oblida:

La tercera és la raó que existeixin els certificats. El xifratge sense autenticació és inútil davant d'un intermediari: si un atacant s'hi interposa, negocia una connexió xifrada amb tu i una altra amb el servidor real, ho llegeix tot. És el mateix raonament de l'avís d'empremta d'SSH a 06-02.

I el que TLS no garanteix: que el servidor sigui honest, que l'aplicació sigui segura, que les dades estiguin xifrades en repòs, ni que qui es connecta sigui qui diu (per a això cal autenticar el client).

El problema a resoldre és d'arrencada: com confiar en la clau pública d'un servidor que no havies vist mai. La solució és delegar en un tercer en qui ja confies.

La verificació consisteix a comprovar, cap amunt, que cada certificat està signat pel següent, fins a arribar a una arrel que ja és al magatzem local (/etc/ssl/certs/, del paquet ca-certificates). L'autoritat de certificació arrel signa poc i viu molt protegida; les intermèdies fan la feina del dia a dia i es poden revocar sense invalidar l'arrel.

Un certificat és la clau pública del servidor més un conjunt d'afirmacions, tot signat per l'autoritat de certificació:

El punt sobre el SAN és pràctic, no anecdòtic: des de fa anys els navegadors i les biblioteques TLS ignoren el CN i validen exclusivament contra el SAN. Un certificat amb CN=reserves.tramontana.example i sense SAN és rebutjat. És una font clàssica d'hores perdudes en generar certificats a mà.

L'encaixada de mans de TLS 1.3, en cinc línies i sense entrar en criptografia:

1. El client envia els algorismes que admet i la seva aportació a l'intercanvi de claus.
2. El servidor tria, envia la seva i el seu certificat.
3. El client verifica el certificat contra el seu magatzem d'autoritats de certificació i comprova que el nom és al SAN.
4. Tots dos deriven la mateixa clau de sessió sense haver-la transmès mai.
5. A partir d'aquí, tot va xifrat amb aquella clau. Un sol viatge d'anada i tornada.

openssl és la navalla suïssa de l'àrea. Quatre operacions cobreixen el 90 % de la feina.

La CSR (Certificate Signing Request) conté la clau pública i els noms sol·licitats, i va signada amb la clau privada per demostrar que la posseeixes. La clau privada no surt mai del servidor.

Aquell -copy_extensions copyext és imprescindible: sense ell, el SAN de la CSR no es copia al certificat i n'obtens un d'inservible. És l'error més freqüent en generar certificats de prova a mà.

Un autosignat serveix per provar la configuració del servidor, i només per a això: cap autoritat de certificació no el respatlla, així que tot client avisarà. Mai en producció.

Aquella última comprovació resol una fallada desconcertant i freqüent: el servidor no arrenca o rebutja les connexions perquè la clau i el certificat no són parella, típicament després de regenerar-ne una i oblidar l'altra. Si les dues sumes coincideixen, són parella.

I la inspecció d'un servidor en marxa:

El -servername és obligatori quan hi ha diversos llocs a la mateixa IP: és l'extensió SNI, que indica quin certificat vols. Sense ell rebràs el certificat per defecte i creuràs que hi ha un problema on no n'hi ha.

Let's Encrypt és una autoritat de certificació gratuïta i automatitzada. El seu protocol, ACME, funciona sobre una idea simple: per demostrar que controles un domini, l'autoritat de certificació et demana que facis una cosa que només el seu titular podria fer.

El DNS-01 és imprescindible en dos casos: certificats comodí (*.tramontana.example) i servidors que no exposen el port 80 — i requereix que el proveïdor de DNS tingui API, o fer-ho a mà en cada renovació, que no és viable.

I aquí s'aplica l'avís d'abast del principi: Nginx es munta a 08-01, així que ara es fa servir el mode --standalone, en què certbot aixeca el seu propi servidor temporal al port 80. Recorda que a 06-03 vas deixar el 443 obert però el 80 no: cal obrir-lo abans.

Els quatre fitxers que genera, perquè cada servidor en demana un de diferent:

Servir cert.pem en lloc de fullchain.pem és un error clàssic: funciona al navegador d'escriptori, que sol tenir la intermèdia a la memòria cau, i falla en clients mòbils i a curl. Es detecta amb openssl s_client mirant si la cadena està completa.

Els certificats de Let's Encrypt duren 90 dies. Això obliga a automatitzar, que és intencionat: una renovació automatitzada i provada falla menys que una d'anual feta a mà.

--dry-run és la línia més important d'aquesta secció. La renovació falla, típicament, pel port 80 tancat per una regla nova del tallafocs, per un servei ocupant aquell port, o per un --deploy-hook trencat. I falla en silenci, 60 dies després que introduïssis el canvi, quan ja ningú no recorda haver-lo fet. Provar en sec després de cada canvi de xarxa o de tallafocs és la disciplina que evita aquell escenari.

El ganxo de desplegament és el que recarrega el servei després de renovar:

Un certificat renovat que el servei no ha recarregat no serveix: el procés continua presentant el vell fins que es reiniciï. És una altra fallada silenciosa clàssica.

Sobre mTLS (autenticació mútua), breument: el servidor exigeix també un certificat de client. És excel·lent per a la comunicació entre serveis —molt millor que una clau d'API— i desaconsellable per a persones, pel cost de distribuir i renovar certificats a cada dispositiu.

Els criteris vigents, que s'aplicaran a 08-01 en configurar Nginx:

• Només TLS 1.2 i TLS 1.3. SSL 3.0, TLS 1.0 i 1.1 estan retirats per vulnerabilitats conegudes i cap client actual no els necessita.
• Suites amb confidencialitat persistent (ECDHE), perquè el compromís futur de la clau privada no permeti desxifrar trànsit capturat en el passat.
• HSTS, la capçalera Strict-Transport-Security, que diu al navegador que faci servir HTTPS sempre per a aquest domini. Compte: és difícil de revertir, així que primer amb max-age curt.
• No inventis la llista de suites. Fes servir el generador de ssl-config.mozilla.org i el seu perfil intermediate, que és l'equilibri raonable entre seguretat i compatibilitat, i revisa'l periòdicament.

640 root:ssl-cert és el patró: root escriu, el grup ssl-cert llegeix, ningú més. El procés que necessita la clau s'afegeix a aquell grup — mai no es fa la clau llegible per tothom.

Si la clau privada es filtra, no n'hi ha prou de generar-ne una de nova: cal revocar l'anterior, perquè continua sent vàlida fins a la seva caducitat i permetria a qui la tingui suplantar el teu servei:

Amb honestedat sobre la seva eficàcia: la revocació depèn que el client la comprovi, i molts no ho fan o fallen de manera permissiva. És necessària però no suficient; el pla de resposta ha d'assumir que la clau filtrada continua sent utilitzable un temps.

La fallada més ximple i més freqüent de producció és un certificat caducat. Passa fins i tot amb renovació automàtica, perquè l'automatització també es trenca. La mesura és un control independent que no confiï en el mecanisme de renovació, en la línia de comprovar_copia.sh de 05-08:

Els 20 dies de llindar no són arbitraris: amb certificats de 90 dies, certbot renova als 60, així que queden 30 dies de marge. Un avís als 20 significa que la renovació automàtica ha fallat dues vegades i encara hi ha gairebé tres setmanes per arreglar-ho amb calma.

I com que l'script retorna 0/1/2 igual que revisio_salut.sh, s'integra sense fricció amb la comprovació general i amb el monitoratge.

• Generar un certificat sense SAN. El CN ja no es valida. Sense -addext "subjectAltName=..." a la CSR i sense -copy_extensions copyext en autosignar, obtens un certificat que tot client rebutja.
• Servir cert.pem en lloc de fullchain.pem. Funciona al teu navegador —té la intermèdia a la memòria cau— i falla en mòbils i a curl. Verifica sempre amb openssl s_client des d'una altra màquina.
• No provar la renovació en sec. certbot renew --dry-run després de cada canvi de tallafocs o de servidor web. Si no, te n'assabentes 60 dies després, quan el certificat caduca de debò.
• Oblidar el ganxo de desplegament. Un certificat renovat que el servei no ha recarregat no serveix de res: el procés continua presentant el vell.
• Passar un secret per la línia d'ordres. --password=X és visible a ps per a tot el sistema. Fes servir un fitxer, l'entrada estàndard o el mecanisme de credencials del programa.
• Desxifrar un secret a un fitxer al disc. Deixa restes recuperables. Fes servir /dev/shm, una canonada, o pass -c amb porta-retalls temporal.
• Creure que LUKS protegeix un servidor en marxa. Protegeix el disc robat o llençat, no el sistema compromès, on el volum ja està muntat. Dir-ho malament en un informe és pitjor que no posar-ho.
• Rotar retirant la credencial antiga abans de verificar la nova. Crear, aplicar, verificar, retirar. Aquell ordre, sempre.
• Perdre la clau GPG de pass sense còpia. És la clau mestra de tots els teus secrets. La seva còpia xifrada i la seva custòdia són part del manual d'operació, no un detall.
• Consell de mètode. Anota al manual d'operació, per a cada secret: on és la font de veritat, qui el pot recuperar, quan es va rotar per última vegada i cada quant toca. Un inventari de secrets sense dates és un inventari que ningú no manté.

restic necessita la seva contrasenya de dipòsit per executar la còpia nocturna sense intervenció humana. Avui és en un fitxer 600 propietat de root llegit per copia_tramontana.sh. Redissenya la solució fent servir pass com a font de veritat i el mecanisme de credencials de systemd, i explica el problema de recuperabilitat que apareix i com el resols.

Reps aquest avís i l'has de diagnosticar:

certbot.timer està actiu i certbot renew no ha donat cap error visible al journal. Enumera les causes possibles en ordre de probabilitat, amb l'ordre que confirma o descarta cadascuna.

La Marta et demana per escrit «que el xifratge protegeixi les dades dels hostes». Redacta l'informe amb les tres capes de xifratge que has muntat —secrets amb systemd-creds i pass, disc amb LUKS, trànsit amb TLS—, indicant per a cadascuna què protegeix i què no protegeix, i quin risc sobre les dades d'hostes continua obert malgrat les tres.

Solució 1

I a l'script, restic llegeix la contrasenya d'un fitxer, que és just el que la credencial li lliura:

Tres decisions que convé justificar:

• RESTIC_PASSWORD_FILE en lloc de RESTIC_PASSWORD: la contrasenya no passa per l'entorn, només la ruta al fitxer.
• ${CREDENTIALS_DIRECTORY:?...} amb missatge: si l'script s'executa a mà en lloc de per systemd, falla immediatament i amb un missatge clar, en comptes d'intentar copiar sense credencial. És l'expansió de 04-02 aplicada a una cosa real.
• La credencial la munta systemd en un tmpfs privat del servei: ni el luis, ni el becari, ni el mateix svc-tramontana des d'un altre procés no la poden llegir.

El problema de recuperabilitat, que és el fons de l'exercici: el fitxer .cred està xifrat amb una clau derivada d'aquesta màquina (/var/lib/systemd/credential.secret). Si el servidor es perd —l'escenari (c) de restauració de 05-08, o una reinstal·lació després d'un compromís—, aquell fitxer és indesxifrable. I sense la contrasenya de restic no hi ha manera de llegir les còpies: tindries les còpies i no les podries restaurar, que és el pitjor dels fracassos possibles.

Es resol en dos fronts:

1. pass és la font de veritat, i viu fora. El dipòsit de pass se sincronitza a un remot (pass git push), i la clau GPG privada té còpia xifrada en un mitjà físic separat. Reconstruir el servidor és: instal·lar, restaurar pass, i tornar a executar la canonada del pas 2.
2. El manual d'operació ho documenta explícitament, amb aquella canonada escrita literalment i la ubicació de la clau GPG. El manual d'operació ja és fora del servidor per la disciplina de 05-08.

La regla general que se n'extreu: un secret lligat a la màquina no pot ser mai l'única còpia. La credencial de systemd és una memòria cau operativa; la font de veritat és en un altre lloc i és recuperable per una persona autoritzada.

Solució 2

Que certbot renew no donés error és la pista principal: cal distingir «va renovar i alguna cosa posterior va fallar» de «no va renovar i ningú no se'n va assabentar». La primera comprovació separa les dues branques:

Branca A — el certificat al disc és nou (caduca en ~90 dies). La renovació va funcionar; el problema és després.

1. El servei no es va recarregar (el més probable). El procés continua a memòria amb el certificat vell:

   $ ls -l /etc/letsencrypt/renewal-hooks/deploy/
   $ sudo journalctl -u certbot --since "40 days ago" | grep -iE 'hook|deploy|reload'
   $ systemctl show nginx -p ActiveEnterTimestamp
   

   Si la marca d'arrencada del servei és anterior a la renovació, és això. S'arregla recarregant, i es corregeix d'arrel revisant el ganxo de desplegament.
2. El servidor apunta al fitxer equivocat: a un cert.pem copiat a una altra ruta en el seu dia, en lloc de a l'enllaç de live/ que certbot actualitza.

   $ grep -rE 'ssl_certificate' /etc/nginx/
   

3. Estàs mirant un altre certificat: sense -servername, openssl s_client retorna el lloc per defecte. El mateix script el passa, però comprova-ho si ho has provat a mà.

Branca B — el certificat al disc també caduca en 6 dies. No s'ha renovat res. certbot renew no falla sorollosament quan el desafiament no es pot completar en una execució no interactiva, així que cal provocar l'error:

Causes en ordre de probabilitat:

1. El port 80 està tancat. És la causa número u, perquè qualsevol revisió del tallafocs s'endú per davant aquella regla «que no semblava necessària»:

   $ sudo ufw status verbose | grep -E '^80|http'
   $ sudo nft list ruleset | grep -E 'dport 80|dport { .*80'
   

2. Un altre procés ocupa el 80 i --standalone no pot aixecar el seu servidor:

   $ sudo ss -tulpn | grep ':80 '
   

3. El temporitzador no s'executa de debò, encara que estigui active:

   $ systemctl list-timers certbot.timer --no-pager
   $ sudo journalctl -u certbot.service --since "70 days ago" | tail -20
   

   Un LAST buit amb el temporitzador actiu significa que mai no s'ha disparat.
4. DNS: el nom ja no resol a aquesta màquina, així que el desafiament HTTP-01 arriba a un altre lloc:

   $ dig +short reserves.tramontana.example
   $ getent hosts reserves.tramontana.example
   

5. Límit de peticions de l'autoritat de certificació, si hi va haver molts intents fallits. La sortida de --dry-run ho diu, i es distingeix perquè fa servir l'entorn de proves i no consumeix quota.

La lliçó de mètode: l'avís va arribar amb 6 dies de marge perquè el llindar era 20 i el control és independent del mecanisme de renovació. Si la vigilància hagués consistit a confiar en certbot, te n'hauries assabentat amb el servei caigut. Per això els controls de verificació no han de compartir mecanisme amb allò que verifiquen.

Solució 3

Informe per a Marta Vidal — Xifratge de les dades d'hostes a srv-tramontana 18 d'agost de 2026

S'han implantat tres capes de xifratge. Cadascuna cobreix un risc diferent i cap no substitueix les altres. Detallo què protegeix i què no protegeix cadascuna, i el risc que continua obert.

Capa 1 — Secrets (systemd-creds + pass) La contrasenya de la base de dades i la del dipòsit de còpies ja no estan en clar en cap fitxer de configuració ni a l'entorn de cap procés. Estan xifrades al disc i systemd les lliura al servei en un espai privat a memòria. La font de veritat és en un gestor amb historial, fora del servidor. Protegeix: la fuita de credencials per un error de permisos, per una còpia mal feta, per un registre o per la lectura de l'entorn d'un procés. Tanca l'incident obert des de la còpia amb permisos 644. No protegeix: contra un atacant amb privilegis de root a la màquina en marxa, que pot llegir la credencial de la mateixa manera que el servei.

Capa 2 — Disc de còpies (LUKS) El volum /srv/tramontana/backups està xifrat a nivell de bloc. A més, el dipòsit de restic té el seu propi xifratge, així que les còpies tenen dues capes independents. Protegeix: el robatori o la pèrdua física del disc, l'accés a la imatge de la màquina apagada, i la recuperació de dades d'un disc retirat sense esborrat segur. No protegeix: contra un atacant que compromet el servidor en marxa. Per a ell, el volum està muntat i llegible. És xifratge en repòs, no en ús.

Capa 3 — Trànsit (TLS) El material criptogràfic de reserves.tramontana.example està emès per Let's Encrypt, verificat, amb renovació automàtica provada i vigilància independent de la caducitat amb avís a 20 dies. Protegeix: la lectura i la modificació de les dades de reserva pel seu camí per la xarxa, i la suplantació del servei. No protegeix: les dades un cop arriben al servidor, ni la seguretat de la mateixa aplicació.

Risc obert, i és important que hi consti Les dades d'hostes viatgen avui sense xifrar: l'aplicació escolta en HTTP al port 8080. El certificat està a punt i verificat, però el component que el presentarà —el servidor intermediari invers davant de l'aplicació— està previst a la fase següent del projecte. Fins que es desplegui, el xifratge en trànsit no està en vigor, encara que el material estigui preparat. Mitigació provisional: el 8080 no és accessible des d'Internet, així que l'exposició es limita a la xarxa interna.

Risc residual comú a les tres capes Cap capa no protegeix contra el compromís del servidor en marxa amb privilegis de root. Contra aquell escenari actuen els controls de la fase anterior: detecció de canvis amb AIDE, auditoria d'accessos amb auditd, i el procediment de resposta a incidents amb reconstrucció.

Compliment. El xifratge de dades personals en trànsit i en repòs és una obligació del RGPD (art. 32), no una millora opcional, i el risc obert del punt anterior és rellevant a aquests efectes. Recomano que el disseny de la custòdia de claus i la decisió sobre el termini de desplegament del servidor intermediari invers els revisi el responsable de protecció de dades.

Els dos deutes criptogràfics del curs estan saldats, cadascun a la seva manera. La db_password ja no existeix com a text en cap fitxer de configuració: viu xifrada en un .cred que només systemd pot desxifrar i que només el servei pot llegir, amb pass com a font de veritat versionada i sincronitzada fora del servidor. El volum de còpies està xifrat amb LUKS, sabent amb precisió què protegeix això i què no. I el material de reserves.tramontana.example està emès, verificat amb openssl, amb renovació automàtica provada en sec i amb un control de caducitat independent que avisa amb vint dies de marge. El tercer incident obert queda tancat, i saps per què LoadCredentialEncrypted és millor que EnvironmentFile, per què el SAN mana sobre el CN, i per què l'ordre d'una rotació és crear, aplicar, verificar i retirar.

En queda un. El 18 d'agost a les 06:12, unattended-upgrades va aplicar la correcció d'un CVE de TLS sobre openssl i libssl3t64 — la biblioteca que sosté tot el que acabes de muntar a la segona meitat d'aquesta lliçó — i va deixar serveis en execució que continuen fent servir la versió antiga carregada a memòria. Un pedaç instal·lat que ningú no ha aplicat de debò és una vulnerabilitat amb paperassa. A la lliçó 06-06: Assegurant Sistemes Linux es tanca aquell incident amb needrestart i es fa una cosa més ambiciosa: reunir tot el que has après en un model d'amenaces explícit i una postura de seguretat coherent. Reduiràs la superfície d'atac, enfortiràs l'autenticació amb PAM —el deute que vas deixar pendent a 05-01—, escriuràs un perfil d'AppArmor per a l'aplicació, aplicaràs els sysctl d'enfortiment del nucli i els muntatges amb noexec, apujaràs la puntuació de systemd-analyze security amb criteri, i tancaràs amb una llista de comprovació d'enfortiment de srv-tramontana que digui amb honestedat què està fet, què s'ha decidit assumir i què excedeix l'abast d'un administrador.