Il Data Definition Language (DDL) è un sottoinsieme del linguaggio SQL (Structured Query Language) utilizzato per definire, modificare e gestire la struttura di un database. Mentre altri comandi SQL si occupano dei dati contenuti nelle tabelle, il DDL si occupa della “scatola” che li contiene: definisce lo schema, le tabelle, gli indici e i vincoli di integrità.
I comandi principali del DDL.
I verbi del DDL agiscono direttamente sul catalogo del database. Ecco i più importanti:
- CREATE: serve a creare nuovi oggetti nel database (tabelle, indici, viste o il database stesso).
- ALTER: permette di modificare la struttura di un oggetto esistente (per esempio, aggiungere o eliminare una colonna da una tabella).
- DROP: elimina definitivamente un oggetto e tutto il suo contenuto dal database.
- TRUNCATE: svuota completamente una tabella dai suoi dati, ma ne mantiene intatta la struttura (a differenza di DROP).
Differenza tra DDL e DML.
Per capire bene il DDL, è utile confrontarlo con il DML (Data Manipulation Language):
| Caratteristica | DDL (Definition) | DML (Manipulation) |
| Obiettivo | Definisce lo schema (la struttura) | Gestisce i dati (il contenuto) |
| Comandi | CREATE, ALTER, DROP, TRUNCATE, RENAME, COMMENT | SELECT, INSERT, UPDATE, DELETE |
| Effetto | Cambia la forma delle tabelle | Cambia le righe all’interno delle tabelle |
| Transazione | Spesso esegue un auto-commit (salvataggio immediato) | Può essere annullato con un rollback |
Un esempio pratico.
Se volessimo creare una tabella per gestire la sicurezza degli accessi, useremmo il DDL in questo modo:
SQL
CREATE TABLE AccessiSicurezza (
ID_Utente INT PRIMARY KEY,
Nome_Utente VARCHAR(50),
Data_Accesso DATE,
Livello_Autorizzazione INT
);
Il “giudizio” sistemico.
Nel contesto della sicurezza informatica e della compliance, il DDL è una fase critica. Definire correttamente i tipi di dati e i vincoli (come le Foreign Keys o i vincoli di Not Null) tramite DDL è la prima linea di difesa per garantire l’integrità del dato e prevenire vulnerabilità strutturali.
Passiamo ora dal piano teorico a quello operativo. In un database orientato alla sicurezza e alla compliance, il DDL non serve solo a creare spazio per i dati, ma a “blindare” il sistema. Ecco come si potrebbe strutturare una tabella utilizzando il DDL per garantire che i dati siano integri e protetti:
Esempio: Creazione di una Tabella di log degli accessi.
SQL
CREATE TABLE RegistroAccessi (
ID_Log INT PRIMARY KEY AUTO_INCREMENT,
ID_Utente INT NOT NULL,
Timestamp_Accesso DATETIME DEFAULT CURRENT_TIMESTAMP,
Indirizzo_IP VARCHAR(45) NOT NULL,
Esito_Accesso ENUM(‘Successo’, ‘Fallito’) DEFAULT ‘Successo’,
— Vincolo di integrità referenziale
FOREIGN KEY (ID_Utente) REFERENCES Utenti(ID_Utente)
);
Come il DDL implementa la sicurezza:
- Integrità dei Dati (NOT NULL): obbliga il sistema a registrare sempre l’ID dell’utente e l’IP. Se un tentativo di scrittura manca di questi dati, il database rifiuta l’operazione. Questo previene i “log vuoti” che rendono impossibili le indagini forensi.
- Referential Integrity (FOREIGN KEY): assicura che un log di accesso possa appartenere solo a un utente realmente esistente nella tabella Utenti. Impedisce che vengano creati log “orfani” o fittizi.
- Consistenza (ENUM): limitando l’esito a ‘Successo’ o ‘Fallito’, eviti che vengano inseriti valori ambigui che potrebbero confondere gli algoritmi di rilevamento delle intrusioni.
Modifiche strutturali con ALTER.
Se le normative sulla privacy (come il GDPR) dovessero cambiare, dovresti aggiornare la struttura senza cancellare i dati:
SQL
— Aggiunta di una colonna per la crittografia dell’IP
ALTER TABLE RegistroAccessi
ADD COLUMN IP_Criptato VARBINARY(256);
Il “filtro” della responsabilità.
In ambito professionale, chi ha il permesso di eseguire comandi DDL ha le “chiavi del castello”. Un errore in un comando DROP può cancellare l’intera storia di un’azienda. Per questo, nei sistemi sicuri, l’esecuzione di DDL è soggetta a rigorosi protocolli di autorizzazione.
Per vedere di gestire la sicurezza a livello di database, dobbiamo passare dal “cosa” al “chi”. In termini tecnici, questo significa gestire il Principio del Minimo Privilegio. Per evitare che un utente (o un malintenzionato che ne ha rubato le credenziali) possa usare il DDL per distruggere o alterare il database, si agisce sui permessi d’accesso tramite un altro sottoinsieme del linguaggio SQL: il DCL (Data Control Language). Ecco come si potrebbe strutturare la difesa di un database:
1. Separazione dei ruoli (RBAC).
Non tutti dovrebbero poter usare comandi come DROP o ALTER. Puoi creare dei ruoli specifici:
- Ruolo Security_Admin: può creare tabelle e gestire la struttura (DDL), ma non vede i dati sensibili.
- Ruolo Data_Analyst: può leggere i dati (SELECT), ma non può assolutamente modificare la struttura delle tabelle.
SQL
— Creazione di un ruolo che può solo leggere
CREATE ROLE ‘Analista_Sola_Lettura’;
GRANT SELECT ON NomeDatabase.* TO ‘Analista_Sola_Lettura’;
— Revoca esplicita dei permessi DDL (per sicurezza)
REVOKE DROP, ALTER, CREATE ON NomeDatabase.* FROM ‘Analista_Sola_Lettura’;
2. Protezione tramite Trigger di sistema.
In alcuni database avanzati (come SQL Server o Oracle), puoi creare dei Trigger DDL. Questi sono “guardiani” che si attivano ogni volta che qualcuno prova a modificare lo schema. Esempio: Se un amministratore prova a cancellare la tabella RegistroAccessi durante l’orario di ufficio, il trigger può bloccare l’operazione e inviare un avviso di sicurezza.
3. Log delle operazioni DDL (Audit Trail).
La sicurezza non è solo prevenzione, ma anche tracciabilità. È fondamentale che ogni comando DDL venga registrato in un file di log esterno, non modificabile dal database stesso. Questo permette di rispondere alla domanda: “Chi ha modificato la struttura del database alle 3 del mattino?”.
Sintesi: in un’ottica di sicurezza sistemica, il DDL è l’arma a doppio taglio:
- Come difesa: lo usi per creare vincoli, chiavi esterne e strutture rigide che impediscono l’inserimento di dati sporchi o pericolosi.
- Come minaccia: rappresenta il rischio di “cancellazione della memoria” del sistema.
La soluzione risiede nella norma: definire protocolli rigidi (DCL) che filtrino chi può agire sulla struttura.
Per chiudere il cerchio sulla sicurezza dei dati, possiamo vedere come un attacco di SQL Injection possa colpire proprio le debolezze di una struttura non adeguatamente protetta.
L’attacco via input.
Immagina un modulo di login che accetta un nome utente. Se il programmatore non ha “filtrato” l’input, un attaccante potrebbe inserire una stringa di codice SQL al posto del nome.
- Input malevolo: ‘ OR ‘1’=’1′; DROP TABLE Utenti; —
- Risultato: il database interpreta la prima parte come un accesso sempre valido (1=1 è sempre vero) e la seconda parte come un comando DDL (DROP TABLE). In un istante, l’intera base dati degli utenti viene cancellata.
La prevenzione sistemica.
Per evitare che il “potere” del DDL venga usato contro il sistema stesso, si applicano tre livelli di protezione:
- Validazione degli input: non accettare mai caratteri speciali (come ; o –) dove non dovrebbero esserci.
- Prepared Statements (Parametrizzazione): È la tecnica più efficace. Il database viene istruito a trattare l’input dell’utente solo come “testo” e mai come “comando”. Anche se l’utente scrive DROP TABLE, il sistema lo leggerà solo come un nome utente molto strano.
- Privilegi minimi (DCL): come dicevamo, l’utente web che interroga il database non deve mai avere i permessi per eseguire DROP, ALTER o CREATE. Anche se l’attacco riuscisse a passare, il database risponderebbe con “Permesso negato”.
La norma come difesa.
Questo esempio dimostra che la sicurezza non è un “prodotto” che si compra, ma una forma che si dà al sistema. La razionalità del programmatore deve prevedere l’irrazionalità (o la malizia) dell’utente.
“La tecnica è pericolosa non perché è potente, ma perché spesso è priva di limiti intrinseci.”
Nel database, i limiti intrinseci sono i vincoli DDL e i permessi DCL.