La teva còpia immutable té un permís que l'esborra

«Les nostres còpies són immutables.» Amb aquesta frase es tanquen moltes reunions de seguretat, i és una frase incompleta. Immutable no és una propietat del producte: és un mode de retenció, un termini i una llista de qui se'l pot saltar. Canvia qualsevol dels tres i la mateixa paraula descriu dues situacions diferents.

Tot el que ve a continuació és a la documentació pública dels fabricants. A Amazon S3, la mateixa funció —Object Lock— ofereix dos modes. En un no pot esborrar ni l'usuari arrel del compte. En l'altre pot esborrar qualsevol que tingui un permís concret, i la consola web d'AWS envia per defecte la capçalera que cal per saltar-se'l. Tots dos es diuen immutabilitat. Tots dos surten igual de verds a l'informe mensual.

El 93 % ho demana, el 16 % diu que ho té

L'1 de setembre es va publicar un estudi d'Omdia amb una xifra que ha circulat molt: el 93 % dels responsables enquestats considera que la immutabilitat absoluta de l'emmagatzematge de còpies és un requisit crític davant del ransomware, i només el 16 % diu que el seu entorn actual compleix aquest estàndard. Hi ha una altra xifra al mateix estudi que ens sembla més interessant i que s'ha quedat fora dels titulars: el 89 % diu que les afirmacions d'immutabilitat d'un fabricant no es poden donar per bones sense validació d'un tercer.

Abans de fer servir aquests números, dos avisos que l'estudi es mereix. El primer: l'encarrega i el paga Object First, que ven precisament un aparell d'emmagatzematge immutable, i que Veeam va comprar el gener del 2026. Això no converteix les respostes en falses —el treball de camp el fa Omdia—, però sí que condiciona què es pregunta i quin titular es destaca. El segon avís importa més per a tu: la mostra són 700 persones d'organitzacions de 1.000 a 9.999 empleats als Estats Units, el Regne Unit, Irlanda, França i la regió DACH, entrevistades entre finals de febrer i finals de març del 2026. Ni una pime espanyola. Si la teva empresa té quaranta persones, aquest 16 % no descriu casa teva.

El que sí que es trasllada és la forma del buit: la distància entre el que la gent es pensa que té i el que té configurat. I aquesta distància no es tanca comprant res. Es tanca llegint tres coses que ja són escrites en algun lloc: el mode, el termini i qui té l'excepció.

Dos modes que en la conversa es diuen igual

Amazon S3 Object Lock és el mecanisme en què es basen gairebé tots els productes de còpia que parlen S3, així que val la pena llegir-ne la documentació amb calma. Hi ha dos modes de retenció i la diferència no és de grau:

Aquest requisit de capçalera sona a fricció deliberada: cal demanar-ho a part, a mà, expressament. Però la mateixa documentació d'AWS hi afegeix una nota que el desactiva en el cas més comú. Literalment: «per defecte, la consola d'Amazon S3 inclou la capçalera x-amz-bypass-governance-retention:true. Si intentes esborrar objectes protegits pel mode governance i tens el permís s3:BypassGovernanceRetention, l'operació tindrà èxit».

O sigui que si aquesta identitat té el permís i algú entra per la consola web i prem esborrar, s'esborra. Sense capçalera manual, sense avís especial, sense un diàleg diferent del de qualsevol altre fitxer. La fricció existeix a l'API i desapareix a la interfície per la qual es fa gairebé tot a les tres de la tarda d'un divendres.

Governance està ben dissenyat i fa el que promet. AWS el recomana explícitament per provar terminis de retenció abans de comprometre's amb compliance, i per als casos en què algú ha de poder rectificar. El que es trenca és una cosa anterior: el mode de proves i el mode definitiu es diuen igual a la reunió i només es distingeixen a la configuració.

Tres detalls més de la mateixa pàgina, i el primer és el que més gent explica malament. El termini de retenció el pot allargar sempre qualsevol amb s3:PutObjectRetention; escurçar-lo només és possible en governance i amb el permís d'excepció —la capçalera de bypass és a la signatura d'aquesta mateixa crida—, mentre que en compliance no es pot mai. Segon: la retenció legal, que bloqueja sense data de caducitat, «la pot posar i treure lliurement qualsevol usuari que tingui el permís s3:PutObjectLegalHold». I tercer, el que gairebé ningú no esmenta: hi ha una retenció variable amb retenció per esdeveniment que AWS recomana literalment «quan vols una finestra de recuperació configurable davant del ransomware o de l'esborrat accidental», i que fixa la data en alliberar el bloqueig.

El mode que sí que aguanta també té factura

La temptació, llegit això, és posar-ho tot en compliance i dormir tranquil. Convé saber què se signa. En aquest mode, si t'equivoques en fixar la retenció, pagues aquest emmagatzematge fins al final: no hi ha manera d'escurçar el termini ni d'alliberar espai. I el radi d'explosió es desplaça: l'única palanca que queda per destruir aquestes dades abans d'hora és tancar el compte. Les teves còpies deixen de dependre de les credencials del servidor de còpies i passen a dependre que ningú no toqui —ni perdi, ni deixi de pagar— el compte que les allotja.

Ho vam escriure nosaltres al juliol, arran de l'esborrat del registre de la propietat romanès: dissenya la còpia assumint que l'atacant ja té les credencials d'administrador. Aquella frase està bé i es queda curta, i per això hi tornem. Dir «immutabilitat» aquí és el principi de la conversa, no el final. L'avís conjunt sobre Gunra que vam comentar a l'agost descriu uns atacants que van esborrar les dades de còpia del centre principal i del de recuperació, abans i després de xifrar. Contra aquest guió, un repositori en governance amb el permís de bypass repartit al mateix domini que acaben de comprometre es converteix en un pas més de la seva llista.

La comprovació òbvia retorna la resposta equivocada

Suposem que ho vols comprovar tu mateix, que és exactament el que demana aquest 89 % que no es fia de la paraula del fabricant. La prova intuïtiva és intentar esborrar un objecte i veure si et deixa. Doncs resulta que aquesta prova menteix, i ho diu la mateixa documentació: si llances un esborrat simple, sense indicar l'identificador de versió, S3 respon 200 OK i col·loca un marcador d'esborrat a sobre. L'objecte continua allà, intacte i protegit, però la resposta que has vist és la d'un esborrat correcte.

L'error es comet en les dues direccions. Qui fa la prova se'n va convençut que la immutabilitat no funciona i obre un tiquet que no cal. I l'atacant que esborra així se'n va convençut del contrari. Amb la versió indicada sí que hi ha resposta útil: un esborrat permanent contra una versió protegida retorna 403 Forbidden. Ara bé, aquest 403 confirma que hi ha un pany i no diu de quina mena és —el retorna igual un objecte en compliance que un en governance provat per algú sense el permís d'excepció—. El mode no es dedueix d'un esborrat: es llegeix amb get-object-retention i get-object-lock-configuration.

I una condició prèvia que cau pel seu propi pes però s'oblida: Object Lock només funciona en buckets amb versionat activat. Sense versionat no hi ha retenció que valgui, perquè no arriba a existir.

El termini de la teva política tampoc no és el termini real

El tercer paràmetre és el termini. Veeam aplica als repositoris d'objectes un mecanisme anomenat block generation: agrupa els blocs escrits en una mateixa finestra perquè comparteixin data de caducitat, de manera que no calgui reescriure el bloqueig dels blocs vells cada nit. El motiu és de cost —menys crides a l'API, menys trànsit— i l'efecte és que aquest període se suma al que tu vas configurar. A la documentació del seu agent per a Windows són 30 dies a Amazon S3 i Google Cloud Storage i 10 dies a la resta d'emmagatzematges d'objectes; la llista canvia segons el producte i el proveïdor, així que el número que et toca a tu s'ha de mirar a la teva versió i no en aquest paràgraf.

Amb aquests valors, poses 30 dies d'immutabilitat a S3 i el que hi ha escrit a l'objecte són 60: més protecció de la que vas demanar i també més emmagatzematge del que vas pressupostar, durant el doble de temps. La xifra que vas escriure a la política no és la xifra que hi ha a l'objecte, i aquí la diferència juga a favor teu. No sempre ho fa.

I la còpia de Microsoft 365 on aterra?

Ja vam explicar que la còpia nativa de Microsoft 365 no surt mai de Microsoft, que és una limitació de disseny i no pas un descuit. Quan contractes una còpia de debò d'un tercer, aquestes dades acaben escrites en algun lloc, i aquest lloc sol ser un emmagatzematge d'objectes amb els mateixos tres comandaments: mode, termini i permisos.

La conversa de compra, en canvi, es queda un pas abans. Es parla de retenció —set anys sona bé, tot i que aquesta xifra no surt de l'RGPD, que no fixa terminis i obliga justament al contrari, sinó de normativa mercantil i fiscal— i no es parla de mode. Són coses diferents: la retenció diu quant de temps es guarda; el mode diu qui pot escurçar aquest temps. En una còpia de Microsoft 365, el mode i el termini han de ser escrits al lliurament juntament amb la retenció. Si no hi són, la paraula «immutable» del contracte no es pot verificar.

La frase que ha de poder acabar qui porta les teves còpies

No cal una auditoria ni una eina. Cal una frase amb quatre buits. Demana-la a qui opera les teves còpies —el teu equip, el teu proveïdor, nosaltres si som nosaltres— i escolta quant triga:

Si triga més d'un minut, ja tens el resultat. No pas perquè sigui mal professional: perquè aquestes quatre dades viuen en quatre llocs diferents —la política del producte de còpia, la configuració del bucket, la política IAM i el gestor de credencials— i gairebé mai no s'han mirat juntes. L'últim buit és el que més gent es salta, i és el que ho decideix tot: si aquestes credencials viuen al mateix directori que la resta de l'empresa, l'atacant que té el directori té també el permís de bypass.

Quan això no va amb tu

Un article que comença parlant d'un estudi patrocinat per un fabricant d'aparells immutables hauria d'acabar dient-te que en compris un. No ho farem. Si les teves còpies acaben en una cinta que algú treu de la unitat i desa en un armari, tens immutabilitat absoluta i no t'ha costat ni una llicència ni una política IAM: un objecte que no està connectat a res no s'esborra per xarxa. És incòmode, és lent de restaurar i cal recordar-se de treure'l; també és l'únic mode que no té una casella que el desactivi.

I ho diem sabent de quin costat cobrem: venem còpies gestionades i recuperació davant de desastres, així que un article titulat «les teves còpies no són el que et penses» ens convé. Per això el contrapès: si pots acabar la frase de més amunt sense consultar ningú, la part difícil ja està feta i no necessites contractar res. El problema el té qui descobreix el mode del bucket el dia que va a restaurar.

El que no afirmem

Fonts (verificades el 29 de setembre del 2026): modes de retenció compliance i governance, permís s3:BypassGovernanceRetention, la nota sobre la capçalera que la consola inclou per defecte, la retenció variable amb retenció per esdeveniment recomanada davant del ransomware, la retenció legal amb s3:PutObjectLegalHold, la regla que el termini només es pot escurçar en governance i amb el permís d'excepció, el requisit de versionat i el comportament de l'esborrat simple (200 OK més marcador) davant del permanent (403) — documentació d'Amazon S3, «Locking objects with Object Lock»; període de block generation de 30 dies a Amazon S3 i Google Cloud Storage i de 10 dies a la resta d'emmagatzematges d'objectes, i el seu motiu declarat (reduir peticions, trànsit i cost) — documentació de Veeam per a l'agent de Windows, «Block Generation»; xifres de l'estudi (93 % / 16 %, 89 % que exigeix validació de tercers) — nota de l'estudi d'Omdia patrocinat per Object First (01-09-2026), amb la metodologia (700 enquestats, organitzacions de 1.000 a 9.999 empleats als EUA, el Regne Unit, Irlanda, França i DACH, treball de camp entre el 26 de febrer i el 25 de març del 2026) recollida a Compare the Cloud; adquisició d'Object First per part de Veeam, confirmada el 14 de gener del 2026, i fundació de la companyia el 2022 per Ratmir Timashev i Andrei Baronov — Blocks & Files.