Salta el contingut

Conceptes de seguretat

Abans d'entrar en la gestió d'usuaris, privilegis i rols, cal tenir clars els conceptes sobre els quals es construeix tot el control d'accés d'un SGBD.

Model de seguretat: autenticació vs. autorització

La seguretat d'accés als SGBD s'estructura en dues capes ben diferenciades:

flowchart LR
    subgraph Autenticació
        A[Usuari / Aplicació] -->|Credencials| B{SGBD\nverifica identitat}
        B -->|Accés denegat| C[❌ Error de login]
        B -->|Identitat verificada| D[Sessió oberta]
    end
    subgraph Autorització
        D --> E{Comprova\nprivilegis}
        E -->|Permís concedit| F[✅ Operació executada]
        E -->|Permís denegat| G[❌ Accés no autoritzat]
    end

Autenticació

L'autenticació respon a la pregunta: qui ets? El SGBD verifica que l'usuari és qui diu ser mitjançant:

  • Contrasenya (el mecanisme més habitual)
  • Certificats SSL/TLS (autenticació de client per certificat)
  • Kerberos / LDAP / Active Directory (autenticació integrada corporativa)
  • Fitxers pg_hba.conf (PostgreSQL) o taules de privilegis d'host (MySQL)
  • Autenticació del sistema operatiu (peer auth a PostgreSQL, socket local)

Autorització

L'autorització respon a la pregunta: què pots fer? Un cop autenticat, el SGBD comprova quins objectes pot llegir, modificar o administrar l'usuari. Això es gestiona mitjançant:

  • Privilegis (GRANT / REVOKE)
  • Rols (agrupació de privilegis)
  • Vistes (restricció de visibilitat de dades)
  • Polítiques de seguretat a nivell de fila (Row-Level Security, RLS)

Models de control d'accés: DAC, MAC i RBAC

Un cop separades autenticació i autorització, cal triar com es decideixen els permisos dins la capa d'autorització. Hi ha tres grans models:

  • DAC (Discretionary Access Control — control d'accés discrecional): el propietari d'un objecte (taula, vista, esquema) decideix qui hi pot accedir i amb quins privilegis, i pot delegar aquesta decisió a altres usuaris. És el model per defecte de PostgreSQL, MySQL, SQL Server i Oracle: qui crea una taula en pot concedir l'accés amb GRANT. Avantatge: flexible i senzill. Inconvenient: el control queda dispers — cada propietari decideix pel seu compte, i és fàcil perdre'n la traça.

  • MAC (Mandatory Access Control — control d'accés obligatori): els permisos els fixa un administrador central mitjançant etiquetes de seguretat (per exemple, nivells de classificació "confidencial", "secret") i cap usuari, ni tan sols el propietari de l'objecte, els pot canviar. És habitual en entorns governamentals o militars amb requisits de seguretat molt estrictes (Oracle Label Security n'és un exemple). Avantatge: control centralitzat i auditable. Inconvenient: molt rígid i costós de mantenir per a la majoria d'aplicacions empresarials.

  • RBAC (Role-Based Access Control — control d'accés basat en rols): els privilegis no es concedeixen directament als usuaris, sinó a rols (perfils funcionals: comptable, suport_nivell1...), i els usuaris s'assignen als rols que els correspondrien segons la seva funció a l'organització. És el model que s'aprofundeix a la pàgina de Rols i el que farem servir a la pràctica del bloc. Avantatge: escala molt bé (afegir un empleat nou és assignar-lo a un rol existent, no repetir 20 GRANT) i simplifica les auditories. Inconvenient: cal dissenyar bé el catàleg de rols des del principi.

Model Qui decideix els permisos On s'aplica normalment Flexibilitat
DAC El propietari de l'objecte SGBD relacionals per defecte Alta
MAC Un administrador central (etiquetes) Entorns d'alta seguretat/governamentals Baixa
RBAC El disseny de rols de l'organització Aplicacions empresarials, ERP, SGBD moderns Mitjana-alta

Miniactivitat — AC0377/03/01 · Esquema de model de seguretat i comparativa DAC vs RBAC

  1. Dibuixa un esquema (a mà, Mermaid o qualsevol eina) que representi el flux complet autenticació → autorització d'una petició a un SGBD, situant-hi on entrarien DAC, MAC i RBAC dins la capa d'autorització.
  2. Compara DAC vs RBAC amb un exemple concret: una empresa amb 3 comptables i 15 comercials que necessiten accedir a la taula factures. Explica com es gestionaria l'accés amb DAC (GRANT directe a cada usuari) i com es gestionaria amb RBAC (rols rol_comptabilitat i rol_comercial). Quin dels dos escala millor quan s'incorporen 5 comercials nous?
  3. Raona per què MAC no seria un bon model per a l'exemple anterior, i en quin tipus d'organització sí que tindria sentit.

Temps estimat: 25 minuts.

Principi del mínim privilegi

Principi fonamental de seguretat

Cada usuari o aplicació ha de tenir únicament els privilegis estrictament necessaris per realitzar les seves funcions, i cap més.

Concedir privilegis excessius és una de les causes més comunes de brecxes de seguretat internes. Un empleat malintencionat o un compte compromès amb privilegis d'administrador pot destruir o filtrar tota la base de dades.

Els principis derivats d'aquest model són:

  1. Compte separat per aplicació: cada aplicació web, ETL o microservei ha de tenir el seu propi compte de base de dades, mai compartir credencials.
  2. Privilegis de lectura per defecte: si una aplicació només llegeix dades, no necessita INSERT, UPDATE ni DELETE.
  3. Cap accés directe a taules base des d'aplicacions externes: exposar vistes en lloc de taules.
  4. Revisió periòdica de privilegis: els comptes antics o inactius s'han de desactivar o eliminar.
  5. Separació de funcions (SoD): qui administra els servidors no hauria de ser qui administra les dades.

Normativa i estàndards de referència

La correcta gestió del control d'accés a bases de dades no és només bona pràctica tècnica: en molts casos és un requisit legal o contractual:

  • RGPD / GDPR (Reglament UE 2016/679): exigeix mesures tècniques i organitzatives per protegir dades personals, incloent control d'accés i registres d'auditoria.
  • ISO/IEC 27001: estàndard de gestió de la seguretat de la informació; inclou controls específics sobre accés a sistemes i bases de dades.
  • PCI-DSS: reglament de seguretat de pagaments amb targeta; exigeix accés mínim, auditoria i revisió de comptes privilegiats.
  • SOC 2 (Type II): auditoria de controls de seguretat per a proveïdors de serveis; inclou revisió de privilegis i logs d'accés.
  • LOPDGDD (Espanya): llei orgànica de protecció de dades; complementa el RGPD a nivell estatal.

Per als futurs professionals

En el món laboral real, l'administrador/a de bases de dades sovint ha de demostrar el compliment d'aquestes normatives davant d'auditors externs. Saber configurar i documentar el control d'accés és una habilitat molt valorada.

Eines que farem servir

Al llarg d'aquest bloc treballareu amb les eines de línia de comandes i gràfiques de cada SGBD:

SGBD CLI GUI recomanada
PostgreSQL psql pgAdmin 4, DBeaver
MySQL / MariaDB mysql MySQL Workbench, DBeaver
SQL Server sqlcmd, mssql-cli SQL Server Management Studio (SSMS), Azure Data Studio
Oracle sqlplus, sqlcl SQL Developer, DBeaver

Totes les pràctiques s'executen sobre contenidors Docker, de manera que no cal instal·lar res al sistema amfitrió més enllà de Docker Desktop.