Principio del Privilegio Minimo, Spiegato

Il privilegio minimo sembra ovvio una volta che lo dici ad alta voce: dai a un account, a un processo o a un utente solo l'accesso di cui ha bisogno per fare il suo lavoro, niente di più. Il divario tra dirlo e far funzionare effettivamente i tuoi sistemi in questo modo è dove la maggior parte delle violazioni si trasforma da un incidente minore a un compromesso completo del dominio.

Cosa significa davvero

Il principio del privilegio minimo (PoLP) dice che ogni soggetto in un sistema — un utente, un account di servizio, un'applicazione, un container — dovrebbe operare con l'insieme minimo di permessi richiesti per completare la sua funzione. Non i permessi che sono convenienti. Non i permessi che qualcuno ha concesso tre anni fa e ha dimenticato di revocare. Il minimo.

Questo si applica a ogni livello: permessi del file system, ruoli del database, scope delle API, politiche IAM del cloud, regole del firewall, accesso sudo. Un processo di server web che legge file statici non ha bisogno dell'accesso in scrittura a /etc. Uno script di reporting che esegue solo query SELECT non ha bisogno di un ruolo di database con diritti DROP TABLE. Un tirocinante del marketing non ha bisogno dell'admin del dominio perché era più facile che capire il gruppo giusto.

Perché è più importante di quanto sembri

Quando un attaccante compromette un account o un processo, eredita tutto quello che quell'account può fare. Se il laptop di un dipendente phishing ha accesso solo alle condivisioni di file rilevanti per il suo team, il raggio di impatto di quel phishing è contenuto. Se lo stesso account ha diritti di admin del dominio perché l'IT lo ha impostato così una volta per la risoluzione dei problemi e non l'ha mai ripristinato, l'attaccante ora possiede la rete.

Questa è la logica dietro la maggior parte dei rapporti forensi post-violazione: l'accesso iniziale era di basso valore, ma il movimento laterale attraverso account con permessi eccessivi l'ha trasformato in ransomware in tutto l'ambiente. Il privilegio in eccesso non causa il compromesso iniziale, ma è quasi sempre quello che lo rende costoso.

Dove appare nella pratica

Cloud IAM. AWS, Azure e GCP hanno comportamenti permissivi di default se non stai attento — una politica IAM con "Action": "*" e "Resource": "*" passerà la convalida e funzionerà bene, finché una chiave di accesso trapelata non consegna a un attaccante il controllo completo dell'account. Limita le politiche ad azioni specifiche e ARN di risorse invece di usare i caratteri jolly.

Account di servizio. Questi sono spesso i peggiori colpevoli perché nessuno li esamina come esamina gli account umani. Una pipeline CI/CD che distribuisce a un bucket S3 non dovrebbe contenere credenziali che possono leggere ogni bucket nell'account.

Ruoli del database. Separa i ruoli di reporting di sola lettura dai ruoli dell'applicazione che hanno bisogno di INSERT/UPDATE, e separa quelli dal ruolo DBA che può alterare lo schema. PostgreSQL e MySQL supportano entrambi istruzioni GRANT granulari — usale invece di dare a ogni connessione dell'app l'equivalente di root.

Sudo e admin locale. L'elevazione just-in-time (richiedi accesso, ottienilo per una finestra limitata, perdilo automaticamente) batte i diritti di admin permanenti ogni volta. Strumenti come sudo con regole time-limited, o soluzioni PAM negli ambienti aziendali, esistono specificamente per questo.

La tensione con