← Torna alla Base di conoscenza← Domanda precedenteDomanda successiva →
ProgrammazioneArchitetto SQL

Quali sono i modi per proteggere i dati da modifiche accidentali o dannose tramite diritti e ruoli in SQL? Quali sono le differenze tra i livelli di accesso e come implementare correttamente una politica di sicurezza multistrato?

Supera i colloqui con l'assistente IA Hintsage

Risposta.

Il server SQL supporta un sistema di autorizzazioni multistrato tramite ruoli, diritti utente (GRANT/REVOKE) e schemi (schemas). Principi chiave:

  • Assegnare un ruolo = insieme di autorizzazioni che l'utente riceverà successivamente.
  • Dare solo diritti minimi, solo quelli necessari (principio del minimo privilegio).
  • Separare i diritti a livello di database, tabelle, viste, procedure separatamente.
  • Per operazioni particolarmente importanti – utilizzare solo attraverso procedure memorizzate o viste, non accesso diretto alle tabelle.

Esempio di creazione di ruoli e assegnazione di diritti:

-- Creiamo un ruolo per analisti
CREATE ROLE Analyst;
-- Diamo solo SELECT alle tabelle necessarie
GRANT SELECT ON Sales TO Analyst;
-- Neghiamo la modifica dei dati
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Assegniamo il ruolo all'utente
GRANT Analyst TO user_ivan;

Spesso si distinguono ruoli per lettura (read-only), modifica, amministrazione e operazioni specifiche.

Domanda trabocchetto.

Trappola: "Un utente con accesso solo alla vista (VIEW) può modificare la tabella di base attraverso di essa? Fai un esempio."

Risposta: Sì, se la VIEW non contiene aggregazione/raggruppamento e non è solo in lettura (WITH CHECK OPTION) – è possibile eseguire INSERT/UPDATE/DELETE sulla VIEW e le modifiche colpiranno la tabella di base, se le autorizzazioni lo consentono.

-- Vista che filtra le colonne superflue
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Se consentito, l'utente apporterà modifiche in questo modo:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- Questo influenzerà Sales.total per id=42

Soluzione: utilizzare solo VIEW in sola lettura o negare diritti di modifica dei dati attraverso le viste.

Esempi di errori reali dovuti alla mancanza di conoscenza delle sottigliezze dell'argomento.

Storia

Progetto: Portale HR, dati personali dei dipendenti.

Errore: Gli operatori avevano accesso alla tabella di base attraverso VIEW senza limitazioni per UPDATE – hanno accidentalmente modificato gli stipendi l'uno dell'altro, anche se inizialmente VIEW era pensato "solo per report".

Storia

Progetto: Contabilità, integrazioni esterne.

Errore: Abbiamo dato al sistema esterno diritti INSERT e SELECT su tutta la DB invece di solo INSERT nelle tabelle necessarie. Risultato: vulnerabilità alla lettura dell'intero DB e possibile violazione della legislazione GDPR.

Storia

Progetto: Piattaforma SaaS, report multitenant.

Errore: Tutti i clienti lavoravano in uno schema con diritti comuni: per errore vedevano e potevano modificare i dati degli altri. Soluzione – suddivisione in schemi, ruoli separati e vincoli propri a livello di Sicurezza Row Level (RLS).