Seguretat en producció per a equips mitjans: la base que el teu projecte necessita abans del go-live

La seguretat en producció se sol abordar al revés. Els equips activen opcions, afegeixen regles, configuren alertes i assumeixen que el sistema està cobert. Però allò que obtenen no és seguretat, sinó un conjunt d'intencions.

El problema apareix quan aquestes intencions es posen a prova. Un compte que no hauria d'existir segueix actiu, una credencial acaba en un log, una base de dades és accessible des d'internet perquè ningú no va revisar una drecera inicial, una còpia de seguretat que sembla crear-se correctament però no es pot restaurar. I les alertes generen tant de soroll que la important queda ignorada.

Un sistema en producció no és segur perquè s'han aplicat configuracions d'un document, sinó quan l'equip pot explicar quin risc redueix aquesta configuració, verificar que funciona i mantenir-lo mentre el sistema canvia.

Aquest article no és un programa de seguretat corporatiu, sinó una base pràctica per a projectes mitjans: les condicions que s'haurien de complir abans de considerar que un sistema està llest per a la producció.

Per què serveix aquest article (i per què no)

Per la majoria dels equips, la seguretat en producció no va atacants avançats ni de models d'amenaça exòtics. Va d'evitar errors que es repeteixen una vegada i una altra en projectes normals.

Els problemes habituals són sempre els mateixos: un compte administratiu compromès, una credencial filtrada, una base de dades exposada perquè ningú no va revisar una configuració temporal, una còpia de seguretat que sembla sana però no restaura gens útil, o un flux d'alertes tan sorollós que el senyal important es perd.

L'objectiu és convertir aquests riscs en garanties concretes. A cada àrea, el teu equip hauria de poder respondre tres coses amb claredat: què ha de ser cert, quin risc redueix aquesta veritat i com es verificaria en condicions reals. Si aquestes respostes són vagues, el model de seguretat també ho és.

Fonaments de seguretat en producció: accés, secrets i exposició

La primera capa de seguretat no és glamurosa, però és on comencen molts incidents evitables. Abans de pensar en problemes d'aplicació, el vostre equip hauria de tenir clar que l'accés està controlat, els secrets són manejables i el sistema només exposa el que pretén exposar.

Identitat i control d'accés

La majoria dels equips subestima quants problemes comencen amb accessos normals —no amb una vulnerabilitat desconeguda ni amb un atac sofisticat, sinó amb un compte que ja no hi hauria d'haver, un privilegi que mai no es va revisar o una autenticació reforçada que faltava en el moment equivocat.

El principi és senzill: només les persones correctes haurien de tenir accés, només a allò que necessiten, i d'una manera que es pugui atribuir i revocar.

Això implica més que mètodes de login més forts. Un entorn de producció segur no hauria de dependre de comptes compartits, excepcions puntuals ni coneixement informal sobre qui té accés a què. L‟accés administratiu hauria de ser personal i revisable, el model de permisos hauria de seguir el principi de mínim privilegi (no el de la conveniència) i la baixa d‟accessos hauria de formar part de l‟operació normal.

En equips mitjans apareix ràpidament un altre risc. L'accés a producció es fragmenta entre infraestructura, repositoris, DNS, correu, monitoratge, CI/CD i API de tercers. Encara que cada compte individual estigui protegit, el model complet es torna fràgil si ningú no el pot veure com un sol sistema.

La prova important no és si hi ha una política d'accés, sinó si una revocació real es pot fer amb rapidesa i de manera completa. Si aquesta nit roben el portàtil dun desenvolupador principal, pot el teu equip retirar en minuts el seu accés a tot? Infraestructura, desplegaments, logs, proveïdors externs. Si la resposta és "depèn de qui estigui disponible", el control d'accés és més feble del que sembla.

Secrets i configuració sensible

Molts equips tracten els secrets com si fossin només una altra categoria de configuració. Això és un error.

Els secrets no són valors normals d'execució, sinó actius d'alt impacte amb un cicle de vida propi: es poden filtrar, copiar, reutilitzar, rotar, invalidar o oblidar. Un sistema de producció no està llest si només respon a “on guardem els secrets?”. També ha de respondre a “què passa quan un s'exposa?”.

L'objectiu és que els secrets estiguin separats del codi, limitats a l'abast, protegits durant l'operació i reemplaçable sense pànic.

Les fugides poques vegades semblen dramàtiques al principi. Un token apareix en un log. Una credencial queda en un bolcat dentorn. Una clau privada es copia en una nota de desplegament. Un secret dintegració es reutilitza entre entorns perquè una vegada va ser còmode. Amb el temps, el sistema acumula una fragilitat invisible.

Una manera més sòlida de pensar en els secrets és fer-ho en termes de durada i abast. Si un secret es filtra, el que importa és quant de temps continua sent vàlid, a què pot accedir, si es pot reemplaçar de forma neta i si apareix en logs, llistats de processos o informes de fallada.

En un projecte Django desplegat a AWS oa un VPS, els secrets haurien de viure en variables d'entorn o en un gestor dedicat. AWS Secrets Manager o HashiCorp Vault són opcions habituals. Mai al repositori. El fitxer .env en local serveix per al desenvolupament. En producció, els valors s'han d'injectar de manera controlada a través del pipeline de desplegament.

La prova correcta no és “usem un magatzem de secrets?”. És "podem rotar una credencial de producció de forma segura i ràpida?". Si la resposta requereix coordinar tres persones i tocar quatre serveis a mà, el model continua sent fràgil.

Exposició de xarxa i límits d´infraestructura

Una de les maneres més simples de reduir el risc és exposar menys. Cada port públic, endpoint, panell administratiu o subdomini oblidat amplia la superfície datac.

Els projectes mitjans poques vegades necessiten una exposició pública àmplia. Però molts acaben amb serveis interns accessibles des d'internet perquè va ser la manera més ràpida que alguna cosa funcionés. És habitual trobar un panell d'administració de Django sense restricció d'IP, un endpoint de debug que va quedar actiu, un servei de staging accessible sense VPN o dominis antics que segueixen apuntant a sistemes en viu.

L'objectiu és claredat: els punts d'entrada públics han de ser deliberats, els serveis interns han de continuar sent interns i l'accés administratiu ha d'estar restringit per IP, per VPN o per tots dos.

En infraestructura AWS, els security groups i les VPCs fan aquesta feina. En un VPS, les regles de tallafocs (iptables, ufw) i una configuració neta de Nginx. En tots dos casos, la verificació no pot ser només interna.

Revisar les regles de tallafocs previstes no n'hi ha prou. Reviseu un diagrama d'infraestructura tampoc. La seguretat aquí s'ha de comprovar des de fora: verificar què respon des d'una xarxa pública, quins ports són accessibles, quins dominis continuen resolent i quines interfícies exposen més del que cal.

La veritat de l'exposició de xarxa no és dins del servidor. És el que veu un escaneig extern.

Aplicació i runtime: què se li permet confiar al sistema

Un cop coberts els fonaments, la pregunta següent és si el sistema en execució es comporta de manera segura. Aquí és on molts equips se centren primer. Però la seguretat d'aplicació només funciona bé quan el model operatiu que l'envolta ja és raonable.

Límits de confiança de l'aplicació

La majoria de les fallades de seguretat en aplicacions són fallades de límits.

L'aplicació va confiar en una entrada en què no hauria d'haver confiat. Va assumir que un usuari autenticat estava autoritzat per a tot. Va tractar trànsit intern com a assegurança només perquè venia de la xarxa privada. Va exposar detalls interns d'error perquè ningú no va revisar la ruta d'excepció. Va reutilitzar dades de producció en un lloc on mai no haurien d'haver acabat.

El marc més útil per pensar la seguretat de laplicació no és una llista de noms de vulnerabilitats. És un mapa de límits de confiança.

L'entrada de l'usuari, els fitxers importats i les peticions del navegador s'han de tractar com a no fiables. Les peticions de serveis interns també s'han d'avaluar segons allò que realment poden fer, perquè autenticació no és el mateix que autorització, i “intern al sistema” no és el mateix que segur.

Això importa especialment en sistemes que creixen per iteració. Una ruta comença com a comoditat interna i després passa a formar part d'un flux sensible. Un procés en segon pla rep més permisos dels previstos perquè era més fàcil. Un model de rols esdevé inconsistent amb el temps.

En un projecte Django això es tradueix en mesures concretes: validació estricta de formularis i serializers, permisos per vista (no només per login), protecció CSRF activa i rutes d'error que no revelin stack traces ni configuració. El DEBUG = True que tothom fa servir en desenvolupament ha d'estar a False en producció. Sembla obvi, però continua apareixent a auditories reals.

Les fallades de producció també entren aquí. Les rutes derror no haurien de revelar detalls dimplementació ni context sensible. L'aplicació hauria de fallar de manera segura per als usuaris i de manera útil per als qui l'operen. És aquí on una eina com Sentry aporta valor real: captura el context complet de l'error sense exposar-lo a l'usuari final.

La comprovació és directa: pot un usuari inesperat, una petició, un fitxer o un trucador intern creuar un límit que el teu equip dóna per protegit? Si això no s'ha provat deliberadament, els límits són més febles del que s'esperava.

Runtime, cadena de subministrament i comportament públic

La seguretat no acaba a la lògica de l'aplicació. Allò que s'executa en producció, com s'executa, d'on ve i allò que veu l'exterior afecten el perfil real de risc.

L'objectiu és mantenir l'entorn d'execució comprensible, controlat i limitat en privilegis: els serveis no s'haurien d'executar amb més permisos dels necessaris, els artefactes de producció s'haurien de poder traçar fins a un canvi controlat i les dependències no s'haurien d'acumular sense revisió.

Aquí és freqüent que els equips confonguin estable amb assegurança. Components que no s'han revisat en molt de temps poden continuar funcionant, però també tendeixen a tornar-se opacs: ningú no sap exactament quines versions estan en producció, ningú vol tocar l'arbre de dependències i ningú no confia en l'impacte d'una actualització necessària.

En un projecte Django amb Python, el requirements.txt o pyproject.toml hauria d'estar auditat periòdicament. Eines com pip-audit o Dependabot revisen vulnerabilitats conegudes a les teves dependències de forma automàtica. En una app Flutter, les dependències de pub.dev mereixen la mateixa atenció.

El mateix problema apareix a la capa pública. El vostre equip configura l'aplicació d'una forma i assumeix que el protocol de transport, les redireccions, les galetes i les capçaleres es comporten en conseqüència. Però mai no verifica la resposta pública. Sobre el paper tot sembla correcte. A la pràctica, l'endpoint públic pot explicar una història diferent.

L'estàndard pràctic és clar. El teu equip hauria de poder relacionar un artefacte de producció amb un canvi controlat, identificar quines dependències estan en ús i detectar un comportament anòmal abans que els usuaris el reportin. I les respostes públiques haurien de coincidir amb les garanties que creus estar oferint.

La configuració segura no és la que hi ha al repositori. És la que el món exterior pot observar.

Resiliència operativa: com canvia l'equip i recupera el sistema

Un sistema pot tenir controls sòlids i continuar sent fràgil. La seguretat en producció no consisteix només a evitar mals resultats. També consisteix a canviar el sistema amb seguretat, detectar problemes aviat i recuperar-se de manera controlada.

Seguretat en desplegaments i operació

Molts incidents de producció els introdueix el propi equip —no per negligència, sinó per canvis normals fets sota pressió: un desplegament precipitat, una correcció manual no revisada, un rollback que en realitat no restaura l'estat anterior o una ordre d'emergència que resol un problema mentre en crea un altre.

L'objectiu és que el canvi en producció sigui predictible, atribuïble i reversible. Un sistema és més segur quan els desplegaments segueixen un camí controlat, quan les accions d'emergència tenen regles clares i quan la recuperació no depèn d'improvisar.

Això importa perquè les dreceres operatives acumulen risc ocult. Els equips solen creure que tenen un procés de desplegament fiable, però a la pràctica en tenen dos o tres: el documentat, el no oficial i el que algú fa servir quan tot va malament. Així la configuració es desvia de l'estat esperat, es perden secrets i la producció acaba en un estat que ningú no pot explicar del tot.

Un model més fort defineix tres coses: una forma normal de canviar producció (el pipeline de CI/CD), una alternativa limitada quan aquesta via no està disponible i un punt clar en què un incident deixa de ser “provar coses” i passa a ser un escenari de recuperació.

Si la via principal de desplegament no funciona, el teu equip pot recuperar el sistema sense fer-lo menys fiable? Si la resposta depèn d'ordres no documentades o que una persona recordi la seqüència correcta sota pressió, la seguretat operativa és més feble del que sembla.

Còpies de seguretat, recuperació, RTO i RPO

Molts equips es tranquil·litzen quan hi ha còpies de seguretat. Aquesta tranquil·litat sol ser prematura.

L'objectiu no és tenir fitxers de backup, sinó poder restaurar servei i dades dins de límits acceptables quan alguna cosa falla.

Aquí és on els objectius de recuperació esdevenen útils. El RTO (Recovery Time Objective) defineix quant de temps pot estar caigut el sistema abans que el dany sigui seriós. El RPO (Recovery Point Objective) defineix quantes dades recents es poden perdre. Aquestes no són preguntes abstractes. Determinen si esteu planificant un reinici de servei, una restauració de base de dades o la pèrdua completa del host.

Aquí molts equips descobreixen la diferència entre administrar backups i estar preparats per recuperar. Un job es pot executar cada hora i no servir a la necessitat del negoci perquè els punts de restauració reals són més gruixuts. Hi pot haver una política de retenció i no conservar el punt que importa. Un fitxer pot semblar sa i no restaurar res útil.

El senyal real de maduresa no és la freqüència del backup, sinó la confiança en la restauració.

Aquesta confiança ve d'un procés de recuperació que hi ha fora del cap de les persones. Si aquest vespre el teu equip hagués de restaurar una base de dades de producció, hauria de saber quin escenari aplica, quins artefactes necessita i com es valida l'èxit. "Una cosa s'ha trencat" no és un únic incident. Reiniciar un servei, corregir una corrupció lògica i recuperar-se de la pèrdua total d‟infraestructura són esdeveniments diferents amb camins diferents.

És perquè un runbook de restauració importa. No com a documentació de rebliment, sinó com a una seqüència pràctica que algú pugui executar sota pressió. La recuperació no hauria de dependre de reconstruir decisions a partir de missatges vells mentre laplicació no està operativa.

La prova és simple: quan va ser la darrera prova realista de restauració, quant va trigar i si les credencials i artefactes necessaris estaven disponibles fora dels sistemes afectats. Si la resposta és "no ho hem provat mai d'extrem a extrem", els backups encara no són fiables.

Monitorització i detecció d'incidents

Un sistema de producció sense monitorització va amb retard. S'assabenta dels problemes més tard que els usuaris o quan l'incident ja s'ha tornat car.

L'objectiu no és la màxima observabilitat, sinó una monitorització útil.

Els equips solen recopilar massa i detectar-ne poc. Acumulen logs, mètriques, traces, dashboards i regles d'alerta fins que el sistema es torna prou sorollós per forçar tothom a ignorar-lo. Quan això passa, hi ha monitorització, però no preparació real.

Un entorn de producció segur hauria de poder confirmar ràpidament si el sistema està disponible, si funciona correctament, si s'està degradant i si ha canviat alguna cosa que no hauria d'haver canviat. Els esdeveniments rellevants per a seguretat han de ser visibles i accessibles per investigar-los.

Això inclou tant errors tècnics com comportaments rellevants per a seguretat: errors repetits d'autenticació, accions administratives inusuals, errors de backup, problemes de desplegament, canvis estranys de trànsit o canvis de privilegis. No són simples detalls operatius, sinó una part de la postura de seguretat del sistema.

Però la relació senyal-soroll importa més del que molts equips admeten. Una alerta hauria de significar que algú potser hagi dactuar. Si les alertes de seguretat acaben en una carpeta que ningú no revisa, el sistema no funciona.

Segons les pràctiques documentades al Google SRE Book , les alertes han de requerir accions, no només ser informatives. Una alerta que no requereix acció immediata hauria de ser un tiquet o una entrada a un dashboard, no una alerta.

La comprovació correcta no és si hi ha alertes. És si l'equip hi confia i si els primers minuts d'un incident estan prou estructurats per convertir el senyal en l'acció requerida.

Obligacions sobre les dades: més enllà de l'uptime

Els equips tècnics solen tractar aquesta part com una cosa separada de l'enginyeria, però no ho és.

L'objectiu és assegurar-se que el sistema pot assumir les obligacions reals associades a les dades que emmagatzema, processa i exporta. Per a un equip tècnic, la manera més útil de pensar-ho no és amb llenguatge de compliment normatiu, sinó com a capacitat de cicle de vida de les dades.

El vostre sistema hauria de poder identificar on viuen les dades de cada usuari, esborrar-les mitjançant un procés operatiu raonable i exportar-les sense cirurgia manual sobre la base de dades. Els períodes de retenció per a registres de negoci, logs i còpies de seguretat haurien d'estar definits. I els tercers que processen dades haurien d'estar identificats i revisats.

Moltes fallades legals i de privadesa són fallades d'enginyeria. El sistema no pot esborrar netament un usuari perquè les dades es van dispersar en massa llocs. La política de backups conserva dades més temps del previst perquè ningú no va modelar la retenció. Una exportació de suport conté més del que cal perquè mai no es van aclarir els límits. Un proveïdor extern processa dades sota supòsits que ningú no va documentar.

En un projecte Django, la capacitat d'esborrament i exportació hauria de ser una funcionalitat del sistema, no pas un script que algú executa a mà quan arriba una sol·licitud. El RGPD no és opcional si tens usuaris europeus, i complir-lo des del disseny del producte és més barat que retroadaptar-lo després.

El vostre equip no necessita ser expert en dret per millorar aquest punt. Necessita prou claredat per saber què ha de ser capaç de fer el sistema amb les dades que reté. Aquest és un requisit tècnic, no només legal.

Abans del go-live: què s'hauria de complir

Abans de sortir a producció, el teu equip no hauria de dependre de l'optimisme, del coneixement local ni de l'esperança que res estrany passi al principi.

La base s'hauria de veure ja en la manera com s'opera el sistema. Els accessos es poden revocar ràpid, els secrets es poden rotar sense pànic, l'exposició pública és deliberada i verificable des de fora. L'aplicació fa complir els límits de confiança fins i tot quan les peticions vénen des de dins. El comportament públic coincideix amb les suposicions sobre transport, redireccions, capçaleres i galetes.

El mateix estàndard s'aplica a l'operació. Els canvis en producció segueixen un camí controlat i la decisió d'aquest camí no obliga l'equip a improvisar. Les expectatives de recuperació s'entenen en termes pràctics: quantes dades es podrien perdre, quant trigaria la restauració i què cal per executar-la. La fallada dels backups es detecta abans que calgui restaurar. Les alertes són prou creïbles per actuar-hi. L'esborrament, l'exportació i la retenció de dades existeixen com a capacitats del sistema.

Si aquestes condicions encara no es compleixen, el problema no és que el sistema hagi suspès un checklist formal. El problema és que els supòsits de producció continuen ocupant el lloc de les garanties de producció.

Seguretat en producció: una base, no una insígnia

La manera més fàcil de fer que la seguretat en producció sembli completa és anomenar moltes configuracions. La manera més difícil –i més útil– és definir les garanties que el sistema ha d'oferir i verificar-les a mesura que evoluciona.

Aquest és lenfocament que necessiten els projectes mitjans. No teatre corporatiu. No culte les eines. No una col·lecció d'ajustaments que resulten tranquil·litzadors en documents interns, però en realitat es comportin d'una altra manera.

Una base de seguretat en producció és molt més pràctica que això: l'accés està controlat, els secrets són manejables, l'exposició és intencional, l'aplicació fa complir els límits, l'entorn d'execució és comprensible, els canvis estan controlats, els backups realment restauren, les alertes signifiquen alguna cosa i les obligacions sobre dades es reflecteixen en el comportament del sistema.

La implementació variarà d'un projecte a un altre, però les garanties no ho haurien de fer. I els suposats, en producció, tenen una esperança de vida molt curta.

Checklist de seguretat en producció

Aquesta llista està pensada per revisar-se a cada projecte abans del go-live i periòdicament després. Cada punt s'hauria de poder verificar amb un sí o un no. Si la resposta és “no” o “no ho sé”, aquest punt necessita atenció. Alguns punts estan pensats per al stack de Mecexis i/o poden ser opcionals segons el projecte, però segur que els pots traslladar fàcilment a les particularitats de les teves tecnologies, entorn i equip.

Accés i identitat

• Tot accés administratiu a producció és personal i nominatiu (no hi ha comptes compartits ni genèrics).
• Cada persona té activada l'autenticació en dos passos (2FA) a tots els serveis de producció.
• Els permisos segueixen el principi de mínim privilegi: ningú no té més accés del que necessita per a la seva feina.
• La baixa d'accessos forma part del procés d'offboarding (quan algú deixa l'equip o el projecte, se'n retira l'accés el mateix dia).
• Una revocació completa d'accés (infraestructura, repositoris, DNS, CI/CD, serveis de tercers) es pot fer en menys d'una hora.
• Hi ha un inventari actualitzat de tots els accessos a producció, incloent qui té accés a què i amb quin nivell de permisos.
• Els accessos es revisen periòdicament per detectar comptes obsolets o permisos excessius.
• Les claus SSH de producció estan associades a persones concretes i es roten periòdicament.

Secrets i credencials

• Cap secret (tokens, claus API, contrasenyes, claus privades) és al codi font ni a l'historial de git.
• Els secrets de producció viuen en variables d'entorn o gestor dedicat (AWS Secrets Manager, HashiCorp Vault o un altre equivalent).
• Cap secret no apareix en logs, bolcats d'entorn, informes d'error ni missatges d'error.
• Els secrets de producció i els de staging/desenvolupament són diferents (no es reutilitzen entre entorns).
• Tota credencial de producció es pot rotar ràpidament sense necessitat d'un desplegament d'emergència.
• Cada secret té un abast limitat: només accedeix al recurs que necessita, amb els permisos mínims.
• Hi ha un procés documentat per actuar quan s'exposa un secret (rotació, notificació, verificació d'impacte).
• El fitxer .env o equivalent és al .gitignore i mai no es puja al dipòsit.

Exposició de xarxa i infraestructura

• Els punts dentrada públics (dominis, ports, endpoints) són deliberats, documentats i revisats.
• Els serveis interns (bases de dades, cues, caches) no són accessibles des d'internet.
• El panell d'administració de Django (o equivalent) està restringit per IP, VPN o tots dos.
• Els ports oberts a servidors de producció estan justificats i documentats (només HTTP/HTTPS i SSH com a mínim).
• No hi ha dominis antics, subdominis de prova ni registres DNS apuntant a sistemes en viu sense revisar.
• Els entorns de staging i desenvolupament no són accessibles públicament sense autenticació.
• La configuració de tallafocs (security groups a AWS, iptables/ufw a VPS) s'ha verificat amb un escaneig extern.
• El certificat SSL/TLS està configurat correctament i es renova automàticament.
• Les redireccions HTTP → HTTPS estan actives a tots els dominis de producció.

Aplicació i codi

• L'entrada de l'usuari es valida i sanititza a totes les rutes de l'aplicació (formularis, API, uploads).
• Autenticació i autorització són controls separats: estar loguejat no vol dir tenir permís per a tot.
• Les rutes derror no revelen stack traces, configuració interna, rutes del servidor ni dades sensibles.
• DEBUG = False en producció (verificat, no només assumit).
• La protecció CSRF està activa a tots els formularis i endpoints que modifiquen dades.
• Les capçaleres de seguretat estan configurades: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security.
• Els uploads de fitxers estan validats per tipus i mida, i s'emmagatzemen fora del directori web públic.
• Les dependències de Python (requirements.txt o pyproject.toml) s'auditen periòdicament amb pip-audit, Dependabot o equivalent.
• Les dependències de Flutter (pubspec.yaml) també es revisen per a vulnerabilitats conegudes.
• Els artefactes desplegats en producció es poden traçar fins a un commit concret al repositori.
• No hi ha endpoints de debug, test o desenvolupament accessibles a producció.

Desplegaments i operació

• Els desplegaments a producció segueixen un camí controlat i reproduïble a través del pipeline de CI/CD.
• El pipeline executa tests automàtics abans de cada desplegament (cap codi arriba a producció sense passar els tests).
• Hi ha una alternativa documentada per desplegar si el pipeline principal no està disponible.
• Tot canvi en producció és atribuïble: qui ho va fer, quan i què va canviar.
• El rollback a la versió anterior funciona i s'ha provat com a mínim una vegada.
• Els desplegaments no requereixen accés SSH directe al servidor en condicions normals.
• Els canvis de configuració en producció (variables d'entorn, DNS, regles de tallafocs) també es registren i són traçables.
• Hi ha un criteri clar per distingir quan un incident es resol amb un fix ràpid i quan requereix un rollback.

Backups i recuperació

• Les còpies de seguretat de base de dades s'executen automàticament amb la freqüència que el negoci necessita (RPO definit i documentat).
• El temps màxim acceptable de caiguda del sistema està definit (RTO documentat).
• Les còpies de seguretat s'emmagatzemen en una ubicació separada del servidor de producció (una altra regió d'AWS, un altre proveïdor o emmagatzematge extern).
• La integritat dels backups es verifica automàticament (no n'hi ha prou que el job digui "OK").
• L'última prova real de restauració va ser en els darrers tres mesos i va ser reeixida.
• Les credencials i artefactes necessaris per restaurar estan disponibles fora dels sistemes afectats (si es perd el servidor, es pot restaurar igualment).
• Hi ha un runbook de restauració amb passos concrets que qualsevol membre de lequip pot seguir sota pressió.
• Els backups cobreixen no només la base de dades, sinó també fitxers pujats per usuaris, configuració i qualsevol dada que no estigui al repositori.
• S'ha verificat que el backup i la restauració compleixen els temps definits a RTO i RPO.

Monitorització i alertes

• Hi ha un healthcheck automàtic que verifica la disponibilitat de laplicació almenys cada minut.
• Es monitoren les mètriques bàsiques: disponibilitat, taxa derrors i saturació de recursos.
• Els errors d'aplicació es capturen automàticament amb Sentry o equivalent, amb prou context per diagnosticar-los.
• Les alertes van lligades a accions: cadascuna té una resposta esperada i documentada.
• Hi ha almenys dos nivells d'alerta: urgent (notificació immediata) i informatiu (revisió en horari laboral).
• La relació senyal-soroll és suficient perquè l'equip confiï a les alertes i actuï quan salten.
• Els esdeveniments rellevants per a seguretat són visibles: errors repetits d'autenticació, accions administratives inusuals, canvis de privilegis i errors de còpia de seguretat.
• Els logs estan centralitzats i són consultables sense necessitat de connectar-se per SSH a cada servidor.
• Els primers minuts d'un incident estan estructurats: qui investiga, on es mira primer i com s'escala.

Dades, privadesa i obligacions legals

• El sistema pot identificar on viuen les dades de cada usuari (base de dades, fitxers, logs, backups, serveis de tercers).
• Hi ha un procés operatiu per esborrar les dades d'un usuari a petició, dins dels terminis que exigeix ​​el RGPD.
• L'exportació de dades d'usuari no requereix cap cirurgia manual sobre la base de dades.
• Els períodes de retenció estan definits per a dades de negoci, logs d'aplicació, logs d'accés i còpies de seguretat.
• Les dades de producció no es copien a entorns de desenvolupament o staging sense anonimitzar.
• Els tercers que processen dades d'usuaris (passarel·les de pagament, serveis de correu electrònic, analytics, proveïdors d'infraestructura) estan identificats i documentats.
• Hi ha una política de galetes implementada i verificada en tots els dominis públics.
• Els formularis que recullen dades personals informen l'usuari de com es tractaran aquestes dades.