El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Ja saps què cal protegir (lliçó 01-01) i de què (lliçó 01-02). Queda la pregunta més important: amb quin criteri es prenen les decisions? Ningú no pot memoritzar la llista infinita de configuracions correctes, i cap llista no sobreviuria al següent canvi tecnològic. El que sí que sobreviu són els principis: un grapat de regles de disseny, algunes formulades fa més de cinquanta anys, que continuen explicant per què una arquitectura resisteix i una altra s'ensorra. En aquesta lliçó interioritzaràs aquests principis i els veuràs aplicats a decisions concretes de Nimbus Reservas: els permisos del compte amb què l'API parla amb PostgreSQL, les capes que envolten el bucket d'adjunts, qui pot desplegar a producció. Aquests principis són la columna vertebral de la resta del curs: quan al mòdul 5 discutim hardening o seguretat al núvol, estarem aplicant el d'aquí.

Contingut

Per què principis i no receptes
Mínim privilegi i necessitat de conèixer
Defensa en profunditat
Seguretat per defecte i seguretat des del disseny
Fallada segura (fail-safe / fail-secure)
Separació de funcions i rotació
Mediació completa
Economia del mecanisme i mínim mecanisme comú
Acceptabilitat psicològica
No confiar en la seguretat per obscuritat
Confiança zero (Zero Trust) i la fi del perímetre
Assumeix la bretxa
Taula resum i el compromís seguretat-usabilitat-cost

Per què principis i no receptes

La Marta, la CTO de Nimbus, rep cada setmana propostes contradictòries: un proveïdor li ven un tallafoc d'aplicació, un article diu que l'important és el MFA, un client exigeix un qüestionari de 80 preguntes. Sense un criteri propi, la seguretat es converteix en una llista de la compra.

Els principis que veuràs aquí procedeixen majoritàriament d'un article de 1975 de Saltzer i Schroeder sobre protecció de la informació en sistemes informàtics, ampliat després per la pràctica del sector. Han sobreviscut als mainframes, al client-servidor, al web i al núvol — i continuen explicant els incidents de 2026. Aquesta longevitat és la raó d'estudiar-los: una recomanació concreta caduca; un principi et permet generar la recomanació correcta per a una tecnologia que encara no existeix.

Una advertència abans de començar: els principis entren en conflicte entre si. L'economia del mecanisme demana simplicitat; la defensa en profunditat afegeix capes. La seguretat per defecte demana restringir; l'acceptabilitat psicològica demana no ofegar l'usuari. Aplicar-los bé no és obeir-los tots al màxim, sinó saber quin pesa més en cada decisió i poder explicar per què.

Mínim privilegi i necessitat de conèixer

2.1 Mínim privilegi

Tota entitat —persona, procés o servei— ha de tenir exactament els permisos que necessita per a la seva funció, ni un més, i només durant el temps que els necessita.

És el principi més rendible de tots, perquè limita el dany de qualsevol fallada, vingui d'un atac, d'un error o d'un bug. Si una credencial compromesa només pot llegir tres taules, l'atacant només llegeix tres taules.

Aplicat a Nimbus: el compte de base de dades de l'API.

L'Iván va arrencar el projecte connectant l'API amb el superusuari postgres, «per no barallar-se amb permisos». Funciona perfectament... fins que una injecció SQL o un bug converteixen aquesta comoditat en un desastre total: amb el superusuari, un atacant pot llegir qualsevol taula, esborrar-les totes, crear usuaris nous i en alguns escenaris executar ordres al sistema.

Així s'aplica mínim privilegi a PostgreSQL:

-- === 1. Un rol sense capacitat d inici de sessio que agrupa els permisos ===
CREATE ROLE nimbus_api_rol NOLOGIN;

-- === 2. Revocar el que PostgreSQL concedeix per defecte ===
-- Per defecte, qualsevol rol pot crear objectes a l esquema public.
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT USAGE ON SCHEMA public TO nimbus_api_rol;   -- veure l esquema, no crear-hi

-- === 3. Concedir NOMES el necessari, taula a taula i operacio a operacio ===
GRANT SELECT, INSERT, UPDATE ON reserves           TO nimbus_api_rol;
GRANT SELECT, INSERT, UPDATE ON clients_finals     TO nimbus_api_rol;
GRANT SELECT                  ON serveis           TO nimbus_api_rol;  -- cataleg: nomes lectura
GRANT SELECT, INSERT          ON auditoria_accessos TO nimbus_api_rol; -- s afegeix, NO es modifica
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public      TO nimbus_api_rol;  -- per als autoincrementals

-- === 4. Ni una sola taula amb DELETE ni DROP ===
--     Les baixes es fan amb esborrat logic (columna esborrat_el), no amb DELETE.

-- === 5. Dades especialment sensibles: res per defecte ===
REVOKE ALL ON nomines          FROM nimbus_api_rol;  -- l API no toca mai RH
REVOKE ALL ON claus_passarela  FROM nimbus_api_rol;

-- === 6. L usuari real de l aplicacio hereta del rol ===
CREATE USER nimbus_api WITH PASSWORD :'clau_generada';
GRANT nimbus_api_rol TO nimbus_api;

Explicació de les decisions clau:

Separar rol d'usuari (passos 1 i 6) permet rotar la contrasenya o crear un segon usuari (per exemple, per a un worker asíncron) sense tornar a escriure tots els GRANT.
El REVOKE del pas 2 és imprescindible. Molta gent concedeix permisos i dona per fet que la resta està tancat; a PostgreSQL, l'esquema public és permissiu per defecte. Mínim privilegi comença per treure, no per donar.
auditoria_accessos amb INSERT però sense UPDATE ni DELETE. Això sosté directament la traçabilitat i el no-repudi de 01-01: ni tan sols un atacant que s'apoderi de la credencial de l'API pot esborrar el seu propi rastre des d'allà.
Sense DELETE en cap taula. Un DELETE FROM reserves sense WHERE deixa de ser possible. L'esborrat lògic permet a més recuperar sense restaurar còpies.
REVOKE explícit sobre nomines. Encara que no s'hagués concedit, escriure-ho documenta la intenció i protegeix davant d'un GRANT ... ON ALL TABLES futur fet amb presses.

El mateix principi al núvol, amb la política de la màquina que executa l'API:

# Politica d acces a l emmagatzematge d objectes per al rol de l API
# Principi: nomes EL SEU prefix, nomes les accions que fa servir, nomes amb xifratge
Version: "2012-10-17"
Statement:
  - Sid: LlegirIEscriureNomesAdjuntsDelTenant
    Effect: Allow
    Action:
      - "s3:GetObject"
      - "s3:PutObject"
    Resource: "arn:aws:s3:::nimbus-adjuntos-prod/tenants/*"   # NO el bucket sencer
    Condition:
      StringEquals:
        "s3:x-amz-server-side-encryption": "aws:kms"          # obliga a xifrar en escriure

  - Sid: ProhibitEsborrarIProhibitTocarLesCopies
    Effect: Deny                                              # Deny guanya sempre a Allow
    Action:
      - "s3:DeleteObject"
      - "s3:PutBucketPolicy"
      - "s3:PutBucketAcl"
    Resource:
      - "arn:aws:s3:::nimbus-adjuntos-prod/*"
      - "arn:aws:s3:::nimbus-backups-prod/*"

Punts a destacar:

El recurs és /tenants/*, no *: l'API no pot tocar els prefixos de configuració interna del bucket.
La condició de xifratge converteix «recordar xifrar» en «és impossible escriure sense xifrar».
El bloc Deny inclou les accions que permetrien canviar les regles del joc (PutBucketPolicy, PutBucketAcl). Un atacant amb aquesta credencial no pot autoconcedir-se més permisos.
Les còpies de seguretat estan explícitament fora de l'abast de l'API. És la defensa estructural contra el ransomware: la càrrega de treball compromesa no arriba a la còpia que et salva.

2.2 Necessitat de conèixer (need to know)

És el mateix principi aplicat a la informació en comptes de a les operacions: no n'hi ha prou amb tenir el nivell d'autorització adequat; cal necessitar aquesta dada per a la tasca concreta.

El Rubén, a suport, té autorització general per consultar fitxes de clients finals. Però no necessita veure totes les fitxes de tots els clients de Nimbus sempre. Necessita veure la fitxa del client sobre el qual hi ha un tiquet obert.

Sense necessitat de conèixer	Amb necessitat de conèixer
El Rubén té accés permanent a tota la taula `clients_finals`	L'accés s'obre per al tenant del tiquet assignat i es registra
La consultoria externa té accés a tots els entorns	Accés només a l'entorn de l'incident, amb finestra temporal limitada
L'informe mensual de direcció inclou dades identificatives	L'informe es genera agregat, sense identificadors personals

A la pràctica s'implementa amb accés just-in-time (es concedeix en obrir el tiquet i expira en tancar-lo), emmascarament de camps i agregació. És també la base del principi de minimització de dades que exigeix la normativa de protecció de dades (06-03).

Defensa en profunditat

Cap control no és infal·lible. Col·loca diversos controls independents en sèrie, de manera que la fallada d'un no sigui la fallada del sistema.

La metàfora clàssica és el castell: fossat, muralla, pati, torre de l'homenatge. La metàfora més honesta és el formatge suís: cada capa té forats, però si les capes són independents, és improbable que els forats s'alineïn.

Aplicat a l'actiu més delicat de Nimbus —el bucket d'adjunts amb informes mèdics escanejats—:

flowchart TD
    ATK[Atacant extern] --> L1
    L1["CAPA 1 - PERIMETRE\nWAF i limitacio de peticions\nNomes HTTPS, TLS 1.2+"] --> L2
    L2["CAPA 2 - IDENTITAT\nAutenticacio de la sessio\nMFA per a comptes interns"] --> L3
    L3["CAPA 3 - AUTORITZACIO\nPermis + pertinenca al tenant\nverificada en cada peticio"] --> L4
    L4["CAPA 4 - XARXA\nEl bucket no es public\nAcces nomes des de la VPC"] --> L5
    L5["CAPA 5 - PERMISOS DEL RECURS\nPolitica de minim privilegi\nsense DeleteObject"] --> L6
    L6["CAPA 6 - DADA\nXifratge en repos amb KMS\nURLs signades i caduques"] --> L7
    L7["CAPA 7 - DETECCIO\nRegistre d accessos, alertes per\nvolum anomal de descarregues"] --> L8
    L8["CAPA 8 - RECUPERACIO\nVersionat i copies immutables\nen un altre compte"]

Com es llegeix aquest diagrama. Un atacant que aconsegueixi saltar-se una capa es troba amb la següent. I el més important: si aconsegueix exfiltrar dades igualment, les capes 7 i 8 continuen aportant valor — Nimbus s'assabenta de què es va endur i quan (traçabilitat), i no ha perdut la informació (recuperació).

La condició que fa que funcioni: independència. Deu capes que depenen totes del mateix directori d'identitat no són deu capes; són una. Quan dissenyis les teves capes, pregunta't: quina fallada única en tombaria diverses alhora? A Nimbus aquesta fallada única seria el compte d'administrador del proveïdor de núvol: qui el tingui anul·la les capes 4, 5, 6 i 8 de cop. D'aquí que aquest compte mereixi proteccions desproporcionades (MFA amb clau física, ús excepcional, alertes en cada ús).

Errors freqüents en aplicar defensa en profunditat:

Apilar capes del mateix tipus. Tres antivirus diferents no són defensa en profunditat; són redundància del mateix control.
Fer servir l'existència d'una capa per relaxar-ne una altra. «Com que tenim WAF, no cal validar l'entrada al codi.» El WAF és un filtre genèric i evadible; la validació al codi és la que coneix les regles de negoci.
Oblidar la capa de detecció. Moltes arquitectures tenen cinc capes de prevenció i cap de detecció. Si ningú no mira, la bretxa dura mesos.

Seguretat per defecte i seguretat des del disseny

Són dos principis germans que se solen citar junts (i que la normativa europea de protecció de dades recull de manera explícita).

4.1 Seguretat per defecte (secure by default)

La configuració de fàbrica ha de ser la més restrictiva raonable. Si l'usuari no toca res, ha de quedar protegit.

La configuració per defecte és la que acaba en producció en la majoria d'instal·lacions. Qualsevol valor per defecte insegur es converteix, estadísticament, en una vulnerabilitat massiva.

Decisió a Nimbus	Per defecte insegur	Per defecte segur
Nou usuari al tauler d'administració	Es crea amb rol `admin` i se li treuen permisos després	Es crea sense permisos; es concedeixen explícitament
Nou bucket creat per la Lucía	Hereta la configuració del compte	Plantilla d'infraestructura amb bloqueig públic i xifratge obligatori
Nou endpoint que afegeix l'Iván	Públic tret que s'afegeixi el decorador d'autenticació	Autenticació obligatòria tret d'excepció explícita en una llista blanca
Nou client que es dona d'alta	Tots els mòduls activats	Només el mòdul contractat
Registre de l'API	Nivell `DEBUG` amb cossos complets	Nivell `INFO` sense dades personals

El tercer cas mereix codi, perquè és el que evita les fuites de dades més ximples. Comparem:

# === PATRO INSEGUR PER DEFECTE ===
# L endpoint es public tret que algu recordi protegir-lo.
@router.get("/api/v1/facturas")
async def llistar_factures(db=Depends(get_db)):     # <-- van oblidar la dependencia d usuari
    return await db.fetch_all("SELECT * FROM factures")

# === PATRO SEGUR PER DEFECTE ===
# L autenticacio s aplica a TOT el router; oblidar-la es impossible.
router = APIRouter(dependencies=[Depends(exigir_usuari_autenticat)])

# I les rutes realment publiques es declaren una a una, de forma explicita i visible:
RUTES_PUBLIQUES = {"/api/v1/salud", "/api/v1/estado-servicio"}

@app.middleware("http")
async def exigir_autenticacio(peticio: Request, seguent):
    if peticio.url.path not in RUTES_PUBLIQUES:
        if not await sessio_valida(peticio):
            return JSONResponse({"detail": "No autenticat"}, status_code=401)
    return await seguent(peticio)

La diferència conceptual és enorme. En el primer patró, la seguretat depèn que cada desenvolupador recordi cada vegada. En el segon, la fallada per omissió resulta en denegació, i obrir alguna cosa requereix un acte deliberat i revisable (afegir una ruta a RUTES_PUBLIQUES apareix a la revisió del codi i crida l'atenció). Això és també fallada segura, que veurem a l'apartat 5.

4.2 Seguretat des del disseny (security by design)

La seguretat s'incorpora en concebre el sistema, no com una revisió final.

El cost de corregir una fallada creix de manera brutal segons en quina fase es detecta:

Moment en què es detecta	Cost relatiu de corregir	Exemple a Nimbus
En dissenyar	1	Decidir que cada taula porta `tenant_id` i que el filtre és obligatori
En programar	~5	Afegir la comprovació en un endpoint durant la revisió de codi
En proves	~15	Detectar a QA que tres endpoints no filtren per tenant
En producció	~50	Pedaç urgent, desplegament fora de finestra
Després d'un incident	~200+	Investigació forense, notificació, pèrdua de clients, reputació

Un exemple concret de decisió de disseny a Nimbus: en comptes de confiar que cada consulta afegeixi WHERE tenant_id = ..., s'activa seguretat a nivell de fila a PostgreSQL, de manera que l'aïllament entre clients el garanteix la base de dades:

-- L aillament multiclient deixa de dependre que ningu oblidi un WHERE
ALTER TABLE reserves ENABLE ROW LEVEL SECURITY;

CREATE POLICY aillament_per_tenant ON reserves
    USING (tenant_id = current_setting('app.tenant_actual')::int);

-- L API fixa la variable de sessio a l inici de cada peticio, despres d autenticar:
--   SET LOCAL app.tenant_actual = '42';
-- A partir d aqui, un "SELECT * FROM reserves" nomes veu les files del tenant 42.

Per què això és disseny i no pedaç: el desenvolupador ja no pot provocar una fuita entre clients oblidant una clàusula. La propietat de seguretat s'ha mogut a una capa on l'error és impossible, en comptes de vigilar-se en cadascun dels centenars de llocs on es podria cometre. Nota pràctica: SET LOCAL dins de la transacció és clau si es fa servir un pool de connexions, perquè el valor no es filtri a la petició següent.

Fallada segura (fail-safe / fail-secure)

Quan alguna cosa falla —i fallarà— el sistema ha de quedar en l'estat més segur possible. La decisió per defecte davant el dubte és denegar.

La formulació clàssica de Saltzer i Schroeder és fail-safe defaults: l'accés es basa en permís explícit, no en absència de prohibició.

Cal distingir dues variants que sovint es confonen:

Variant	Davant la fallada...	Prioritza	Exemple
Fail-secure	Es tanca / denega	Confidencialitat i integritat	Si el servei d'autorització no respon, l'API retorna 403
Fail-safe (seguretat física)	S'obre / allibera	Vida humana, disponibilitat	Les portes d'emergència es desbloquegen si hi ha incendi

En sistemes informàtics gairebé sempre volem fail-secure; en sistemes amb vides en joc, fail-safe. I de vegades cal triar conscientment.

El cas incòmode a Nimbus. El servei que valida els permisos deixa de respondre. Dues opcions:

# === OPCIO A: fail-open (PERILLOSA per defecte) ===
try:
    permes = await servei_permisos.comprovar(usuari, accio)
except TimeoutError:
    permes = True             # "per no trencar el servei"...
                              # ...un atacant que tombi el servei de permisos
                              # obte acces total. La fallada es la clau.

# === OPCIO B: fail-secure (CORRECTA en la majoria de casos) ===
try:
    permes = await servei_permisos.comprovar(usuari, accio)
except TimeoutError:
    logger.error("event=permisos_no_disponibles actor=%s accio=%s", usuari.id, accio)
    raise HTTPException(503, "Servei temporalment no disponible")
    # Es denega, s alerta i es degrada de forma visible.

L'opció A té una propietat devastadora: converteix un atac de denegació de servei en una escalada de privilegis. L'atacant ja no necessita robar credencials; n'hi ha prou que saturi el servei de permisos.

Ara bé, fail-secure aplicat sense criteri també fa mal. Si Nimbus decideix que qualsevol fallada interna impedeix reservar, un problema al servei d'enviament de correus deixaria les clíniques sense agenda. La resolució correcta és degradació graduada:

Component que falla	Decisió	Justificació
Servei de permisos	Denegar tot (fail-secure)	Sense autorització no es pot operar amb seguretat
Servei de correu transaccional	Continuar, encuar i avisar	El correu és accessori a l'operació principal
Passarel·la de pagament	Denegar l'operació de cobrament	No donar mai per bo un pagament no confirmat
Servei d'auditoria	Denegar en operacions sensibles	Sense registre no hi ha traçabilitat ni no-repudi

Aquest últim cas és discutible i serveix per practicar el raonament: si no es pot registrar una exportació massiva de dades personals, es permet fer-la a cegues? A Nimbus, la resposta acordada és no.

Separació de funcions i rotació

6.1 Separació de funcions (segregation of duties)

Cap persona no ha de controlar en solitari totes les fases d'un procés crític.

És un principi nascut en auditoria comptable i trasplantat a la informàtica amb excel·lents resultats. Protegeix alhora contra el frau deliberat i contra l'error individual.

Aplicat a Nimbus:

Procés crític	Sense separació (risc)	Amb separació
Desplegament a producció	L'Iván programa, aprova i desplega el seu propi codi	L'Iván programa; una altra persona aprova la PR; el desplegament l'executa el pipeline, no una persona
Pagament a proveïdors	La Sara crea el proveïdor i ordena el pagament	La Sara dona d'alta el proveïdor; l'ordre de pagament l'autoritza direcció
Gestió d'accessos	La Lucía s'autoconcedeix permisos d'administrador quan els necessita	La concessió requereix tiquet aprovat per la Marta i queda registrada
Revisió dels registres d'auditoria	La Lucía administra els sistemes i revisa els seus propis registres	Els registres van a un compte separat al qual la Lucía no té permís d'esborrat

I així es materialitza a la configuració del repositori, que és on viu de debò la separació de funcions en una empresa de programari:

# .github/branch-protection (representacio simplificada de la proteccio de branca)
branch: main
required_pull_request_reviews:
  required_approving_review_count: 1
  dismiss_stale_reviews: true          # un push nou invalida l aprovacio anterior
  require_code_owner_reviews: true     # els fitxers sensibles exigeixen revisor concret
required_status_checks:
  strict: true
  contexts:
    - "tests"
    - "analisi-estatica-seguretat"
    - "escaneig-dependencies"
enforce_admins: true                   # la regla aplica TAMBE als administradors
allow_force_pushes: false              # no es pot reescriure la historia
allow_deletions: false

Explicació de les línies que més importen:

enforce_admins: true és la que gairebé tothom deixa a false. Si la Marta i la Lucía poden saltar-se el procés, el procés no existeix: n'hi ha prou amb comprometre un d'aquests dos comptes.
dismiss_stale_reviews: true evita el truc d'aconseguir l'aprovació amb un canvi innocu i afegir després el codi real.
allow_force_pushes: false protegeix la integritat històrica del repositori: ningú no pot esborrar el rastre d'un canvi.

Límit pràctic en una pime. A Nimbus hi ha una sola administradora de sistemes. La separació estricta és impossible: la Lucía ha de poder fer la seva feina a les tres de la matinada. Quan la separació preventiva no és viable, se substitueix per controls compensatoris: registre inalterable de totes les seves accions en un compte on ella no pot escriure, alertes automàtiques a la Marta davant accions crítiques, i revisió periòdica per un tercer. És una resposta honesta i perfectament defensable davant d'un auditor.

6.2 Rotació

Complementa l'anterior: les persones canvien de lloc i les credencials caduquen.

Rotació de persones: que una altra persona passi per la funció revela irregularitats i elimina la dependència d'un individu (l'anomenat bus factor). Les vacances obligatòries són, històricament, un control antifrau.
Rotació de credencials: claus d'API, certificats i secrets amb vida limitada. Una credencial que caduca cada 90 dies acota la finestra d'utilitat d'una filtració. Millor encara: credencials efímeres emeses pel proveïdor d'identitat, vàlides durant minuts, que eliminen el secret de llarga vida completament.

Mediació completa

Cada accés a cada recurs s'ha de verificar, cada vegada. Sense excepcions, sense dreceres, sense memòries cau que sobrevisquin al canvi de permisos.

Aquest principi ataca un error molt concret: comprovar els permisos una vegada a l'inici i confiar després.

Exemples de mediació incompleta a Nimbus:

La SPA amaga el botó «Exporta clients» si l'usuari no té el permís... però l'endpoint no ho comprova. La interfície no és un control de seguretat: qualsevol pot cridar l'API directament.
El token de sessió del Rubén dura 8 hores. Se li revoquen els permisos a les 10:00, però el seu token continua sent vàlid i amb els permisos antics incrustats fins a les 18:00.
Es comprova l'autorització en llistar reserves, però no en descarregar l'adjunt d'una reserva concreta: l'URL del fitxer, si es coneix, funciona sense verificació.

Com s'implementa correctament el cas de l'adjunt:

@router.get("/api/v1/reservas/{reserva_id}/adjunto")
async def descarregar_adjunt(reserva_id: int, usuari=Depends(get_usuari_actual), db=Depends(get_db)):
    # MEDIACIO COMPLETA: es torna a verificar aqui, encara que ja es verifiques en llistar
    reserva = await db.fetch_one(
        "SELECT adjunt_clau FROM reserves WHERE id=:id AND tenant_id=:t",
        {"id": reserva_id, "t": usuari.tenant_id},
    )
    if reserva is None:
        raise HTTPException(404, "No trobada")

    # No s exposa mai l URL permanent de l objecte: se n genera una de signada i caduca
    url = generar_url_signada(
        clau=reserva["adjunt_clau"],
        caducitat_segons=120,            # dos minuts: suficient per descarregar
        nomes_lectura=True,
    )
    logger.info("event=descarrega_adjunt actor_id=%s recurs=reserva:%s", usuari.id, reserva_id)
    return {"url": url}

Les tres decisions defensables aquí: es reverifica la pertinença encara que «ja es va comprovar abans»; l'URL signada caduca en dos minuts, de manera que compartir-la per error té una finestra mínima; i l'accés queda registrat, amb la qual cosa la mediació és a més auditable.

La tensió d'aquest principi és evident: verificar sempre costa rendiment. Es resol amb memòries cau de molt curta durada i amb invalidació explícita en canviar permisos — mai eliminant la verificació.

Economia del mecanisme i mínim mecanisme comú

8.1 Economia del mecanisme (simplicitat)

El mecanisme de seguretat ha de ser el més petit i simple possible, perquè només el que és simple es pot verificar.

Un sistema de permisos amb 4 rols clars i auditables protegeix millor a la pràctica que un amb 60 permisos granulars que ningú no entén i que es concedeixen a l'engròs «perquè no sabem quin falta». La complexitat no és un inconvenient estètic: és l'amagatall de les fallades.

Senyals que Nimbus està violant aquest principi:

Ningú no sap explicar en una frase per què un usuari concret pot fer una acció concreta.
Hi ha tres mecanismes diferents d'autorització convivint (un al proxy, un altre al middleware, un altre dins de cada endpoint) i no està clar quin mana.
Per donar d'alta un empleat cal tocar set llocs i existeix un document de 20 pàgines que gairebé ningú no segueix.

Regla pràctica: si no pots dibuixar el teu model d'autorització en una pissarra en cinc minuts, no pots garantir que sigui correcte.

8.2 Mínim mecanisme comú

Minimitza els recursos i mecanismes compartits entre usuaris o entre sistemes diferents, perquè tot el que es comparteix és un canal potencial de fuita o de propagació.

Aplicat a Nimbus:

Compartit (risc)	Separat (millor)
Producció i preproducció al mateix compte de núvol i la mateixa VPC	Comptes separats; un compromís de preproducció no arriba a producció
Una única credencial utilitzada per l'API, els treballs batch i els scripts de la Lucía	Una credencial per identitat, amb permisos diferents i rastrejable
Dades reals copiades a l'entorn de proves	Dades anonimitzades o sintètiques en proves
La mateixa wifi per a empleats, convidats i les impressores	Xarxes separades; la de convidats sense accés a la interna

El cas de preproducció amb dades reals és especialment instructiu: els entorns de prova tenen menys controls, menys vigilància i més gent amb accés. Si contenen dades reals, has creat una còpia del teu actiu més sensible al teu entorn menys protegit — i, en termes de protecció de dades, un tractament difícil de justificar.

Acceptabilitat psicològica

Si un control és massa incòmode, la gent l'evita. Un control evitat no protegeix: a més, amaga l'exposició real.

Aquest principi, formulat ja el 1975, continua sent el més ignorat. La seguretat que no té en compte les persones produeix sistemàticament el contrari del que busca:

Control mal dissenyat	Comportament real que provoca	Alternativa acceptable
Canvi de contrasenya cada 30 dies amb 5 regles	`Nimbus2026!`, `Nimbus2026!!`, post-it sota el teclat	Contrasenyes llargues sense caducitat forçosa + MFA + gestor de contrasenyes corporatiu
Bloqueig de tots els serveis de transferència de fitxers	El Rubén fa servir el seu compte personal per enviar el CSV al client	Servei corporatiu còmode, amb caducitat i registre
Sol·licitud d'accés amb 3 aprovacions i 5 dies d'espera	Es comparteixen credencials entre companys «mentrestant»	Accés just-in-time d'autoservei, amb aprovació d'una persona i registre
MFA en cada acció, cada 10 minuts	Es busca com desactivar-lo; s'aproven notificacions sense llegir-les	MFA en iniciar sessió i en accions sensibles; sessions de durada raonable

La regla operativa: fes que el camí segur sigui el camí fàcil. Si el gestor de contrasenyes corporatiu és més còmode que el bloc de notes, es farà servir. Si el servei de transferència intern és més ràpid que WeTransfer, es farà servir. Dissenyar així requereix més feina per endavant, però és l'única manera que un control sobrevisqui al segon mes.

Avís de diagnòstic: si a Nimbus descobreixes que la gent es salta un control, la primera hipòtesi no ha de ser «són irresponsables», sinó «el control està mal dissenyat». Gairebé sempre ho està. Aquest enfocament connecta amb la lliçó de formació i sensibilització (06-05).

No confiar en la seguretat per obscuritat

La seguretat d'un sistema no ha de dependre que el seu disseny sigui secret. Ha de dependre que les seves claus ho siguin.

És el principi de Kerckhoffs, formulat al segle XIX per a la criptografia militar i vàlid per a qualsevol sistema: el disseny pot caure en mans de l'enemic sense que això comprometi la seguretat.

Què és obscuritat il·legítima (no protegeix):

Posar el tauler d'administració a /panel-secreto-nimbus-2024 i no exigir autenticació forta. Es troba amb un escaneig automatitzat de rutes.
Xifrar amb un algorisme propi «que ningú no coneix». Els algorismes casolans es trenquen gairebé sempre; els estàndards són públics precisament perquè han resistit dècades d'anàlisi.
Confiar que un identificador de reserva sigui llarg i difícil d'endevinar en comptes de comprovar l'autorització.
Amagar la versió del servidor a les capçaleres com a única mesura davant d'una vulnerabilitat coneguda sense pedaç.

Què sí que és legítim (i no és el mateix):

No publicar innecessàriament detalls interns. Reduir la informació que regales és útil com a capa addicional; simplement no pot ser la teva única capa.
Els secrets que estan dissenyats per ser secrets: claus criptogràfiques, contrasenyes, tokens. Aquí el secret no és obscuritat: és el mecanisme.
La diferència clau: un secret legítim es pot rotar si es filtra. Si la teva seguretat depèn que ningú no sàpiga la ruta del teu tauler, quan es filtri hauràs de redissenyar; si depèn d'una clau, la canvies.

Corol·lari pràctic per a Nimbus: quan la Marta avaluï una eina de seguretat, ha de desconfiar del proveïdor que es negui a explicar com funciona. «És propietari, no podem donar detalls» no és una resposta acceptable sobre un mecanisme criptogràfic.

Confiança zero (Zero Trust) i la fi del perímetre

11.1 Per què va morir el perímetre

El model clàssic dividia el món en dos: fora (perillós) i dins (de confiança). Un tallafoc a la frontera i llestos. A Nimbus, aquest model és senzillament inaplicable:

La meitat de la plantilla treballa des de casa. On és el «dins»?
Els servidors són en un proveïdor de núvol, no a l'oficina.
Una consultoria externa hi accedeix en remot amb privilegis elevats.
L'app mòbil dels usuaris finals es connecta des de qualsevol xarxa del món.
Les dades viuen en un bucket S3 i en serveis SaaS de tercers.

A més, el model de perímetre té una fallada estructural: un cop dins, no hi ha res més. Un atacant que compromet un portàtil es mou lateralment sense resistència — que és exactament el que fa el ransomware modern.

11.2 Els principis de Zero Trust

Mai no confiïs, verifica sempre. La ubicació a la xarxa no atorga privilegis.

flowchart TB
    subgraph PER["MODEL DE PERIMETRE (obsolet)"]
        direction LR
        FW[Tallafoc] --> INT["Xarxa interna\nTOT confia en TOT"]
    end
    subgraph ZT["MODEL ZERO TRUST"]
        direction LR
        U[Usuari o servei] --> V{"Verificacio en cada acces\nidentitat + dispositiu +\ncontext + permis minim"}
        V -->|permes, sessio curta| REC[Recurs concret]
        V -->|denegat| X[Bloqueig i registre]
    end

Zero Trust s'aguanta en tres idees que ja coneixes, combinades:

Verificació explícita en cada accés (mediació completa) fent servir tot el senyal disponible: qui ets, des de quin dispositiu, en quin estat està aquest dispositiu, a quina hora, des d'on.
Mínim privilegi amb accés just-in-time i sessions curtes.
Assumir la bretxa: microsegmentació, xifratge extrem a extrem i anàlisi contínua, de manera que un compromís quedi acotat.

Què significa concretament a Nimbus:

Abans (perímetre)	Amb Zero Trust
«Si ets a la VPN, pots arribar a la base de dades»	L'accés a la BD requereix identitat verificada, dispositiu gestionat i una finestra temporal aprovada
L'API confia en les peticions que venen de la xarxa interna	Els serveis s'autentiquen entre si amb mTLS o tokens de servei
El portàtil de la consultoria entra a la xarxa interna completa	Accés només al sistema concret de l'incident, amb gravació de sessió
Els contenidors de la mateixa VPC es parlen lliurement	Polítiques de xarxa que només permeten els fluxos declarats

Avís important: Zero Trust no és un producte que es compra. És una arquitectura i un recorregut de diversos anys. Per a Nimbus, començar és perfectament realista sense gran inversió: eliminar la confiança implícita per xarxa en l'accés a la base de dades, exigir MFA a tots els comptes administratius i acotar l'accés de la consultoria ja són tres passos de Zero Trust.

Assumeix la bretxa

Dissenya partint de la base que l'atacant ja és a dins. La pregunta no és «com ho impedeixo?», sinó «quant dany pot fer i en quant de temps me n'assabento?».

És un canvi de mentalitat més que un control. Canvia les preguntes que es fan a les reunions d'arquitectura:

Pregunta de mentalitat preventiva	Pregunta d'«assumeix la bretxa»
Com evito que entrin?	Si entren pel portàtil del Rubén, a què arriben des d'allà?
Està protegida la base de dades?	Si roben la còpia de la base de dades, les dades estan xifrades i amb quina clau?
Tenim còpies de seguretat?	Pot l'atacant que controla la infraestructura esborrar aquestes còpies?
Tenim registres?	En quant de temps detectaríem una exfiltració lenta i sostinguda?
És segur el nostre CI/CD?	Si comprometen un token de GitHub Actions, què pot desplegar i qui ho aprova?

Les tres conseqüències de disseny més importants:

Segmentació: que el compromís d'un component no doni accés al següent.
Còpies fora d'abast: còpies immutables o en un altre compte, de manera que les credencials de producció no les puguin destruir. És la diferència entre pagar un rescat i no pagar-lo.
Detecció i resposta: mètrica del temps de detecció. Una organització que detecta en hores pateix un incident; una que detecta en mesos pateix una catàstrofe.

Aquest enfocament es desenvolupa operativament al pla de resposta a incidents (04-05) i a les tècniques de monitoratge (05-02).

Taula resum i el compromís seguretat-usabilitat-cost

13.1 Els principis d'un cop d'ull

Principi	Què evita	Decisió concreta a Nimbus
Mínim privilegi	Que una fallada es converteixi en compromís total	El compte `nimbus_api` no té `DELETE` ni accés a `nomines`
Necessitat de conèixer	Exposició innecessària de dades	El Rubén veu la fitxa del tiquet obert, no tota la taula
Defensa en profunditat	Que una única fallada tombi el sistema	8 capes al voltant del bucket d'adjunts
Seguretat per defecte	Configuracions insegures que arriben a producció	Router amb autenticació obligatòria; rutes públiques en llista blanca
Seguretat des del disseny	Correccions cares i tardanes	Aïllament multiclient a la base de dades (RLS), no a cada consulta
Fallada segura	Que una fallada obri les portes	Si el servei de permisos no respon, es denega i s'alerta
Separació de funcions	Frau i errors sense control	`enforce_admins: true`; ningú no aprova el seu propi desplegament
Rotació	Credencials eternes i dependències personals	Claus amb caducitat; credencials efímeres
Mediació completa	Permisos comprovats «una vegada i ja»	Es reverifica la propietat en descarregar cada adjunt
Economia del mecanisme	Complexitat que amaga fallades	Quatre rols clars en comptes de seixanta permisos solts
Mínim mecanisme comú	Propagació entre entorns	Comptes de núvol separats; sense dades reals en proves
Acceptabilitat psicològica	Controls que s'eviten	Gestor de contrasenyes còmode en comptes de caducitat cada 30 dies
Res d'obscuritat	Seguretat que s'evapora en publicar-se el disseny	Res de criptografia pròpia; res de rutes «secretes» com a única defensa
Confiança zero	Moviment lateral després del primer compromís	Ser a la VPN no dona accés a la base de dades
Assumeix la bretxa	Ceguesa davant l'incident en curs	Còpies immutables en un altre compte; mesura del temps de detecció

13.2 Com es resol la tensió

Tots aquests principis costen diners, temps o comoditat. La manera professional de resoldre la tensió té quatre passos:

Classifica l'actiu. No tot mereix el mateix. Les notes mèdiques del bucket d'adjunts i el catàleg públic de serveis no requereixen les mateixes capes. Aplicar el màxim a tot esgota el pressupost i la paciència de l'equip, i acaba en un nivell mediocre uniforme.
Aplica el principi proporcionalment. Mínim privilegi rigorós en producció; una mica més flexible en un entorn de desenvolupament sense dades reals (i aquesta condició és la que ho fa acceptable).
Mesura la fricció, no la suposis. Si el MFA afegeix 6 segons dues vegades al dia, és assumible; si obliga el Rubén a autenticar-se 40 vegades en un matí, es convertirà en un problema i trobarà la manera de saltar-se'l.
Documenta el que acceptes i qui ho accepta. Si Nimbus decideix no separar funcions en administració de sistemes perquè només hi ha una persona, això s'escriu, s'explica el control compensatori i ho signa la direcció. Un risc acceptat i documentat és gestió; un risc acceptat en silenci és negligència.

Nota sobre implicacions legals: diversos d'aquests principis —seguretat des del disseny i per defecte, minimització de dades— apareixen com a obligacions expresses a la normativa europea de protecció de dades. La seva aplicació concreta al teu cas s'ha de validar amb el responsable de compliment o amb un professional de l'àmbit jurídic; el que aquí s'ofereix és formació tècnica, no assessorament legal.

Errors Comuns i Consells

Errors comuns:

Concedir permisos «temporalment» sense data de fi. L'accés temporal més durador del món és el que es concedeix un divendres per sortir del pas. Tota concessió excepcional ha de portar caducitat automàtica.
Confondre defensa en profunditat amb redundància. Capes del mateix tipus comparteixen els mateixos punts cecs.
Aplicar fail-open «perquè no es trenqui res». Converteix una caiguda en una escalada de privilegis. Si has d'obrir davant d'una fallada, que sigui una decisió conscient i documentada, no l'except que va quedar allà.
Creure que la interfície protegeix. Amagar un botó no protegeix l'endpoint. La seguretat s'aplica al servidor, sempre.
Prendre's la simplicitat com a excusa per no fer res. «Economia del mecanisme» no significa «no hi posem autorització»; significa que l'autorització que hi posis ha de ser comprensible.
Implantar Zero Trust com a compra de producte. Cap proveïdor no et ven Zero Trust; et ven una peça. L'arquitectura la dissenyes tu.
Oblidar l'acceptabilitat psicològica a les polítiques. Una política que l'equip no pot complir genera incompliment generalitzat, i amb ell la pèrdua de credibilitat de totes les altres.

Consells:

Davant de qualsevol decisió, recorre mentalment tres principis: és el mínim privilegi possible? què passa si això falla? hi ha més d'una capa? Cobreix la majoria dels casos.
Escriu els permisos com a codi (SQL, polítiques, fitxers de configuració) i desa'ls al repositori. El que es revisa en una PR es discuteix; el que es fa a mà en una consola, no.
Comença per revocar, no per concedir. La postura per defecte ha de ser el tancament.
Quan hagis de violar un principi per raons pràctiques, escriu-ho amb el seu control compensatori. Un principi incomplert i documentat és gestionable; un d'incomplert en silenci, no.

Exercicis

Exercici 1 — Diagnosticar quins principis es violen

La Marta troba aquesta situació en revisar la infraestructura de Nimbus. Identifica tots els principis que s'estan violant en cada punt i proposa la correcció:

L'API es connecta a PostgreSQL amb l'usuari postgres (superusuari), i la mateixa credencial la fan servir els treballs nocturns i els scripts manuals de la Lucía.
El tauler d'administració intern és a https://admin.nimbusreservas.example, sense restricció de xarxa ni MFA, però «ningú no coneix aquesta URL».
El middleware d'autorització té un bloc except Exception: return True per «evitar caigudes».
La política de contrasenyes obliga a canviar-la cada 30 dies amb majúscules, minúscules, números i símbols; el 60 % de l'equip fa servir variants numerades de la mateixa contrasenya.

Exercici 2 — Escriure permisos de mínim privilegi

Nimbus afegirà un servei nou, nimbus-informes, que genera cada nit un informe agregat d'ocupació per client. El servei:

Llegeix de les taules reserves i serveis.
Escriu el resultat a la taula informes_ocupacio.
Puja un PDF al prefix informes/ del bucket nimbus-adjuntos-prod.
No ha d'accedir a clients_finals, ni a nomines, ni esborrar res.

Escriu (a) els GRANT/REVOKE de PostgreSQL i (b) l'esquelet de la política d'accés al bucket. Justifica les decisions que no siguin òbvies.

Exercici 3 — Dissenyar capes de defensa en profunditat

Nimbus permetrà que els seus clients descarreguin un fitxer CSV amb totes les seves reserves de l'últim any. És una funcionalitat d'exportació massiva de dades personals. Dissenya almenys cinc capes independents de defensa al voltant d'aquesta funcionalitat, indicant per a cada capa quin principi la sustenta i quin atac o error concret mitiga.

Solucions

Solució 1

1. Superusuari compartit:

Viola mínim privilegi: l'API pot esborrar taules, crear usuaris i llegir-ho tot, quan només necessita operar sobre quatre taules.
Viola mínim mecanisme comú: una sola credencial per a tres identitats diferents (API, batch, humana).
Viola separació de funcions: si la Lucía fa servir la mateixa credencial que l'aplicació, les seves accions són indistingibles de les de l'API als registres — es perden traçabilitat i no-repudi.
Correcció: un rol per identitat (nimbus_api_rol, nimbus_batch_rol, compte nominal per a la Lucía), amb GRANT acotats com a l'apartat 2.1; cap servei amb superusuari; accés administratiu sota petició amb caducitat.

2. Tauler sense protecció real:

Viola no confiar en l'obscuritat: l'URL es descobreix per certificats públics, DNS i escaneig. És el primer que fa un bot.
Viola defensa en profunditat: hi ha una única barrera, i és fictícia.
Viola seguretat per defecte: un tauler administratiu hauria de néixer restringit.
Correcció: MFA obligatori, restricció a rangs de xarxa o accés només mitjançant identitat verificada, limitació d'intents, registre de tots els accessos i alerta davant accessos fora d'horari.

3. except Exception: return True:

Viola fallada segura de manera greu: converteix qualsevol error —inclòs un de provocable per un atacant— en autorització concedida.
Viola mediació completa: la verificació deixa d'existir quan més falta fa.
Correcció: capturar excepcions concretes, denegar l'accés, registrar l'error amb nivell ERROR i alertar. Si per una raó de negoci calgués degradar en obert, s'ha de limitar a operacions de només lectura no sensibles i estar documentat i aprovat per escrit.

4. Política de contrasenyes:

Viola acceptabilitat psicològica: la càrrega és tal que l'equip genera patrons predictibles, més febles que una contrasenya llarga estable.
Viola indirectament economia del mecanisme: la complexitat de la regla no aporta seguretat proporcional.
Correcció: contrasenyes llargues (frases de pas), sense caducitat forçosa tret d'indici de compromís, comprovació contra llistes de contrasenyes filtrades, gestor de contrasenyes corporatiu i MFA. La caducitat periòdica obligatòria està desaconsellada per les guies actuals precisament per aquest efecte.

Solució 2

(a) PostgreSQL:

CREATE ROLE nimbus_informes_rol NOLOGIN;

-- Veure l esquema, sense poder crear-hi objectes
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT USAGE ON SCHEMA public TO nimbus_informes_rol;

-- Lectura estricta del que necessita agregar
GRANT SELECT ON reserves TO nimbus_informes_rol;
GRANT SELECT ON serveis  TO nimbus_informes_rol;

-- Escriptura nomes a la seva taula de resultats; sense UPDATE ni DELETE:
-- cada execucio afegeix un informe nou, no reescriu els anteriors (integritat historica)
GRANT SELECT, INSERT ON informes_ocupacio TO nimbus_informes_rol;
GRANT USAGE ON SEQUENCE informes_ocupacio_id_seq TO nimbus_informes_rol;

-- Prohibicions explicites, encara que no s haguessin concedit: documenten la intencio
REVOKE ALL ON clients_finals     FROM nimbus_informes_rol;
REVOKE ALL ON nomines            FROM nimbus_informes_rol;
REVOKE ALL ON auditoria_accessos FROM nimbus_informes_rol;

CREATE USER nimbus_informes WITH PASSWORD :'clau_generada';
GRANT nimbus_informes_rol TO nimbus_informes;

Decisions no òbvies, justificades:

Sense UPDATE a informes_ocupacio: un informe generat no es modifica. Si cal corregir-lo, se'n genera un altre. Això preserva l'històric i facilita detectar manipulacions.
REVOKE explícits: protegeixen davant d'un futur GRANT ... ON ALL TABLES IN SCHEMA public fet amb presses, que d'altra manera donaria accés a dades personals a un servei que només ha d'agregar.
Millor encara, seguretat des del disseny: si l'informe és agregat, l'ideal és que ni tan sols llegeixi reserves directament, sinó una vista que exposi només les columnes necessàries (tenant_id, data_hora, servei_id) sense dades identificatives. Menys privilegi i menys superfície de fuita.

(b) Política del bucket:

Version: "2012-10-17"
Statement:
  - Sid: PujarNomesInformes
    Effect: Allow
    Action: "s3:PutObject"
    Resource: "arn:aws:s3:::nimbus-adjuntos-prod/informes/*"   # nomes el seu prefix
    Condition:
      StringEquals:
        "s3:x-amz-server-side-encryption": "aws:kms"

  - Sid: NiLlegirAdjuntsNiEsborrarRes
    Effect: Deny
    Action:
      - "s3:GetObject"        # no necessita llegir: nomes escriu
      - "s3:DeleteObject"
      - "s3:PutBucketPolicy"
      - "s3:PutBucketAcl"
    Resource: "arn:aws:s3:::nimbus-adjuntos-prod/*"

Nota: el Deny sobre s3:GetObject és deliberat i potser el punt més interessant de l'exercici. Un servei que només puja fitxers no necessita llegir la resta del bucket, on viuen els informes mèdics escanejats dels pacients. Si el servei es veu compromès, l'atacant no obté aquesta lectura.

Solució 3 — Capes per a l'exportació massiva de CSV:

#	Capa	Principi	Què mitiga
1	Permís específic `dades:exportar`, no inclòs al rol bàsic; només l'administrador del client el té	Mínim privilegi	Que qualsevol recepcionista descarregui tota la base de dades del negoci
2	Reverificació d'identitat (MFA) en el moment d'exportar, encara que la sessió ja estigui iniciada	Mediació completa, necessitat de conèixer	Ús d'una sessió robada o d'un equip desatès
3	Filtre obligatori per `tenant_id` aplicat a la base de dades mitjançant RLS, no a la consulta	Seguretat des del disseny	Que un oblit al codi exporti dades d'altres clients
4	Límit de rang (màxim 12 mesos), de mida i de freqüència (una exportació cada 24 h per client)	Fallada segura, disponibilitat	Exfiltració massiva repetida; esgotament de recursos
5	Generació asíncrona i lliurament per URL signada amb caducitat de 15 minuts, d'un sol ús, mai adjunta per correu	Mínim privilegi, defensa en profunditat	Reenviament accidental de l'enllaç; enllaços permanents indexables
6	Registre d'auditoria amb actor, tenant, files exportades, IP i hora, en emmagatzematge sense permís d'esborrat	Traçabilitat, no-repudi, separació de funcions	Negació posterior; incapacitat d'investigar un incident
7	Alerta automàtica a la Marta i correu a l'administrador del client davant cada exportació	Assumeix la bretxa	Exfiltració silenciosa mitjançant un compte compromès
8	Columnes mínimes al CSV (sense notes internes ni identificadors de pagament) i xifratge del fitxer en repòs	Necessitat de conèixer, mínim privilegi	Que la fuita d'un CSV exposi més del que és imprescindible

Les capes són independents: fallar el permís (1) no anul·la l'aïllament a base de dades (3), i encara que el fitxer es filtri, el contingut està minimitzat (8) i el fet queda registrat i alertat (6, 7). Nota addicional: una exportació de dades personals té implicacions de compliment —base legal, informació a l'interessat, registre de l'activitat— que s'han de validar amb el responsable de protecció de dades.

Conclusió

Has recorregut els quinze principis que sostenen totes les decisions tècniques de la resta del curs. Mínim privilegi i necessitat de conèixer limiten el dany de qualsevol fallada, i els has vist materialitzats en els GRANT del compte nimbus_api —sense DELETE, sense accés a nòmines, amb INSERT però no UPDATE sobre l'auditoria— i en una política de bucket que impedeix a la mateixa API esborrar objectes o reescriure les regles. Defensa en profunditat apila capes independents al voltant dels adjunts mèdics, incloent-hi les de detecció i recuperació que tantes arquitectures obliden. Seguretat per defecte i des del disseny desplacen la protecció de «que ningú no s'oblidi» a «que sigui impossible oblidar-se'n», com fa la seguretat a nivell de fila a PostgreSQL. Fallada segura t'ha ensenyat que un except mal posat converteix una caiguda en una escalada de privilegis.

Has vist també els principis que s'obliden més sovint i que surten més cars: la separació de funcions amb enforce_admins: true i els seus controls compensatoris quan en una pime només hi ha una administradora; la mediació completa que torna a verificar en cada descàrrega; l'economia del mecanisme, que t'obliga a poder dibuixar el teu model d'autorització en una pissarra; l'acceptabilitat psicològica, que explica per què la política de contrasenyes més estricta produeix les contrasenyes més febles; i el rebuig a la seguretat per obscuritat, amb la distinció entre un secret rotable i un disseny ocult. I has tancat amb les dues idees que defineixen la seguretat moderna: confiança zero —la ubicació a la xarxa no atorga privilegis— i assumeix la bretxa, que canvia la pregunta de «com ho impedeixo?» a «quant dany pot fer i en quant de temps me n'assabento?».

Ara saps què protegir, de què i amb quin criteri. Falta el més concret: saber exactament què té Nimbus. A la lliçó següent, Actius, Superfície d'Atac i Actors d'Amenaça (01-04), construirem l'inventari d'actius de l'empresa amb propietari, criticitat i classificació de la informació; en mesurarem la superfície d'atac en totes les seves dimensions; coneixerem els actors que podrien atacar-la i per què a una pime l'afecta sobretot l'atac automatitzat; i faràs els teus primers passos amb STRIDE sobre un diagrama de flux de dades real de Nimbus.

Principis de la Seguretat Informàtica