Come Configurare Permessi Granulari per File Sensibili
Nel mondo dell’amministrazione di sistema, c’è un errore ricorrente che fa rabbrividire qualsiasi esperto di sicurezza: risolvere un problema di permessi negati lanciando un disastroso chmod 777 o assegnando il controllo “Everyone” su Windows.
Questo approccio disintegra il Principio del Privilegio Minimo (PoLP). La gestione moderna dei file sensibili non si accontenta dei permessi base, ma richiede una granularità estrema. In questo articolo vedremo come configurare accessi chirurgici sui server Linux e Windows, garantendo che solo chi deve leggere, legga.
1. Oltre lo standard: Le Access Control List (ACL) su Linux
Il sistema tradizionale Linux basato su UGO (User, Group, Other) e sui comandi chmod e chown è solido, ma rigido. Cosa succede se hai un file di configurazione con permessi 640 (lettura/scrittura per il proprietario, lettura per il gruppo), ma vuoi permettere a un singolo utente esterno (es. uno stagista o un software di backup) di leggerlo, senza aggiungerlo al gruppo proprietario?
Qui entrano in gioco le ACL (Access Control List), che permettono di assegnare permessi specifici a utenti o gruppi aggiuntivi.
Utilizzo pratico di setfacl e getfacl
Per verificare se un file ha delle ACL configurate, si usa getfacl. Per impostarle, usiamo setfacl.
# Supponiamo di avere un file contenente API Key
touch /opt/secrets/api_keys.env
chmod 600 /opt/secrets/api_keys.env # Solo root può leggere/scrivere
# Diamo permessi di SOLA lettura all'utente "backup_user"
setfacl -m u:backup_user:r-- /opt/secrets/api_keys.env
# Verifichiamo i permessi
getfacl /opt/secrets/api_keys.env
L’output mostrerà chiaramente la regola granulare, e facendo un semplice ls -l vedrai un simbolo + accanto ai permessi tradizionali (es. -rw-------+), che indica la presenza di una ACL nascosta.
2. Il livello “Paranoia”: L’Immutabilità (chattr)
Anche con i permessi corretti, l’utente root può fare qualsiasi cosa, compreso cancellare per errore un file vitale (il classico rm -rf nella cartella sbagliata). Per i file veramente critici, Linux offre gli attributi del file system (ext4/XFS), che operano a un livello inferiore rispetto a chmod.
Usando il comando chattr possiamo applicare l’Immutabilità o la modalità Append-Only.
| Attributo | Comando | Effetto | Caso d’Uso Ideale |
| Immutable (+i) | chattr +i file.txt | Il file non può essere modificato, rinominato o cancellato, nemmeno da root. Per modificarlo, root deve prima rimuovere l’attributo con -i. | File di configurazione critici (es. /etc/passwd, file .htninja del tuo firewall). |
| Append Only (+a) | chattr +a auth.log | Il file può essere solo incrementato (si possono aggiungere righe alla fine), ma non si possono cancellare le righe esistenti o il file stesso. | File di Log. Un attaccante non potrà cancellare le proprie tracce dai log. |
3. Gestione Granulare su Windows Server (NTFS)
L’NTFS di Microsoft gestisce le ACL in modo nativo da decenni, ma la vera insidia in ambiente Windows è l’Ereditarietà (Inheritance). Di default, una cartella eredita tutti i permessi dalla cartella genitore.
Se crei una cartella C:\Dati\HR_Sensibili, questa erediterà i permessi di C:\Dati. Modificare i permessi senza rompere l’ereditarietà crea conflitti e falle di sicurezza.
Spezzare l’ereditarietà con ICACLS
Per blindare una cartella su Windows Server da riga di comando (PowerShell/CMD), la prassi corretta è:
- Rimuovere l’ereditarietà (copiando o rimuovendo i permessi precedenti).
- Assegnare esplicitamente i permessi solo agli utenti necessari.
# 1. Rimuove l'ereditarietà e rimuove i permessi ereditati (la cartella diventa inaccessibile a tutti)
icacls "C:\Dati\HR_Sensibili" /inheritance:r
# 2. Concede Controllo Completo (F) al gruppo "Domain Admins" e al sistema (SYSTEM)
icacls "C:\Dati\HR_Sensibili" /grant "SYSTEM:(OI)(CI)F"
icacls "C:\Dati\HR_Sensibili" /grant "Domain Admins:(OI)(CI)F"
# 3. Concede permessi di sola Lettura/Esecuzione (RX) al gruppo "HR_Users"
icacls "C:\Dati\HR_Sensibili" /grant "HR_Users:(OI)(CI)RX"
(Nota: I flag (OI) e (CI) assicurano che questi permessi si applichino anche a tutti i file e le sottocartelle future create all’interno).
La Regola d’Oro dei File Server
Non assegnare mai permessi NTFS ai singoli utenti (es. “Mario Rossi”). Assegnali sempre a Gruppi di Sicurezza (es. “Gruppo_HR_Lettura”). Quando l’utente cambia mansione o lascia l’azienda, ti basterà rimuoverlo dal gruppo invece di dover scansionare terabyte di file per rimuovere la sua utenza specifica.
Conclusioni: L’Audit Access
Configurare permessi granulari perfetti è inutile se non sai chi li sta usando. L’ultimo tassello della sicurezza dei file sensibili è l’Auditing.
- Su Linux, configura
auditdper monitorare chi legge o modifica file specifici (auditctl -w /etc/shadow -p wa -k shadow_changes). - Su Windows, abilita l’Object Access Auditing tramite Group Policy (GPO) per registrare nel visualizzatore eventi (Security Log) ogni volta che un utente accede, modifica o cancella un file all’interno di una cartella blindata.
Implementando ACL, attributi di immutabilità e auditing, si chiude la porta a errori accidentali, ransomware e accessi non autorizzati, trasformando un semplice file server in una cassaforte logica.
