Azioni sul documento
3.4.
I ruoli e i permessi
Su di un livello
Ruoli e permessi regolano in pratica la possibilità di accesso dei diversi utenti ai contenuti e alle informazioni presenti nel sito, come accennato nel capitolo sul flusso di lavoro.
Vediamo ora un possibile esempio pratico di implementazione dei ruoli e quali possono essere, al di là della creazione e pubblicazione dei documenti, le funzionalità critiche di un CMS e come è possibile gestirle
I ruoli ed i permessi sono di solitamente contenuti in una ACL ( Access Control List ). Le ACL sono un modello di gestione della sicurezza che specifica chi può fare cosain un determinato sistema. Se una entità ha il permesso verso un determinato oggetto allora ha anche la possibilità di intervenire e modificare od eseguire tale oggetto.
È poi possibile ulteriormente espandere il modello Access-Control dal lato dei permessi in alcune importanti direzioni:
-
Ruoli
-
Acquisizioni
-
Proprietà
-
Ruoli locali
Stabilendo dei permessi per i ruoli e definendo il ruolo di un utente si impostano direttamente i parametri della sicurezza per le diverse famiglie di utenti suddivisi a seconda delle necessità degli amministratori.
Un ruolo va associato ad un utente del sistema. Vediamo ora di esemplificare quali possono essere.
MANAGER: ha la possibilità di effettuare tutte le azioni possibili per defoult., la sua funzione è quella di intervenire e gestire qualunque parte del sito, ha la supervisione sul funzionamento del CMS, può modificarne gli stati.
PROPRIETARIO: è forse il ruolo più importante per la sicurezza dei CMS. È l’ utente che ha creato un oggetto e che può in qualsiasi situazione modificarlo ed eseguirlo.
Dal punto di vista di possibili attacchi o danni al sistema è importante che un utente che accede ad un oggetto che aziona una modifica dello stato corrente possa determinare effettivamente questo cambiamento soltanto se sia l’ utente che il proprietario dell’ oggetto hanno il prerequisito Permesso.
Questa importante impostazione impedisce quelli che vengono chiamati attacchi server-side trojan, possibili quando un utente malicious ha la possibilità di creare sul server del codice eseguibile.
Fondamentalmente questo tipo di attacco presenta il seguente scenario:
-
Un utente malicious crea sul server del codice eseguibile che tenta di di effettuare un’ azione per la quale l’utente non ha i permessi (ad esempio cancellare un folder nella directory di root sul server).
-
L’ utente malicious induce qualcuno che abbia i permessi, ad esempio il proprietario del sito, a visitare la pagina con il codice maligno.
-
Se il codice ha come unica restrizione quella del permesso dell’utente autenticato in quel momento (in questo caso il manager) il codice va in esecuzione e l’attacco ha esito positivo.
È quindi molto importante che per evitare questo e altri tipi di attacco i permessi relativi a codice eseguibile siano gestiti dal sistema e dall’ amministratore in maniera consapevole, un buon compromesso può essere quello di considerare come restricted il codice editato via web e mai concedergli l’accesso al filesystem locale.
D’ altro canto codice creato ad hoc per i più svariati utilizzi deve potervi accedere e in ogni caso una volta pubblicato non ci sono più restrizioni, potenzialmente utenti del CMS potrebbero accedere a tutte le risorse del sistema disponibili con cui il CMS è interfacciato, ma nella maggior parte dei casi questa è più una risorsa che un problema dove i permessi sono impostati correttamente.
L’ UTENTE AUTENTICATO: è qualunque navigatore sia in possesso di una coppia valida username-password. Solitamente per defoult non ha permessi associati al proprio ruolo.
L’ UTENTE ANONIMO: è qualunque navigatore visiti le pagine pubblicate del sito. Conferire permessi a questa categoria di utenti significa conferirli a tutte le altre categorie (a meno di non negarle espressamente nella Access-Control-List).
