Questa applicazione self-hosted concede alle persone solo l’accesso di cui hanno bisogno? Una checklist per valutare l’RBAC
Usa questa checklist pratica per valutare ruoli, autorizzazioni, confini amministrativi, accesso API e processi del ciclo di vita degli utenti prima di spostare utenti e dati in un’applicazione self-hosted.
Perché la progettazione del controllo degli accessi va affrontata prima del deployment
Una migrazione può rendere un’applicazione tecnicamente disponibile, pur lasciando l’organizzazione con una soluzione poco adatta al modo in cui il lavoro è effettivamente suddiviso. Se finanza, vendite, operazioni, servizi ai clienti e collaboratori esterni necessitano di azioni diverse su record differenti, convalida questo modello prima di importare dati di produzione o invitare utenti.
Il controllo degli accessi basato sui ruoli (RBAC) si fonda sull’identificazione delle operazioni necessarie per specifiche mansioni, sull’assegnazione delle persone ai ruoli e sull’attribuzione dei privilegi a tali ruoli. La domanda importante per chi acquista non è quindi “Dichiara di avere l’RBAC?”, ma “Possiamo esprimere e gestire le decisioni di accesso di cui abbiamo bisogno in questa applicazione?”.
Considera il privilegio minimo come un criterio di progettazione: ogni persona dovrebbe ricevere solo i privilegi minimi necessari per il proprio lavoro. Persone con un livello di anzianità simile possono comunque richiedere accessi molto diversi perché le loro responsabilità differiscono. OWASP raccomanda inoltre un’autorizzazione con negazione predefinita, ossia che l’accesso sia esplicitamente consentito anziché dato per scontato.
- Valuta le autorizzazioni durante la selezione, non dopo che un rollout in produzione ha reso difficile revocare accessi troppo ampi.
- Non equiparare l’uso del termine “RBAC” da parte di un’applicazione a funzionalità avanzate. NIST distingue l’assegnazione di ruoli di base dalle gerarchie di ruoli opzionali e dalle funzionalità di separazione dei compiti.
- Rendi l’adeguatezza del modello di accesso una condizione per procedere con la migrazione, insieme a importazione dei dati, integrazioni, autenticazione e requisiti di backup.
Parti dai gruppi di utenti reali e dalle azioni che ogni gruppo deve svolgere
Inizia dal lavoro, non dai nomi dei ruoli predefiniti dell’applicazione. Intervista le persone responsabili di ciascun processo aziendale e registra il più piccolo insieme pratico di azioni che devono completare. Includi il lavoro ordinario, le eccezioni, le approvazioni, le esportazioni, l’eliminazione, l’amministrazione degli utenti e le modifiche di configurazione.
Evita etichette di ruolo che nascondono privilegi ampi. “Manager”, “editor” o “membro” non sono requisiti di autorizzazione. Un requisito utile indica un verbo, un oggetto e un ambito: per esempio, “creare record nello spazio di lavoro assegnato”, “visualizzare progetti di proprietà del cliente” o “esportare solo report aggregati”.
Includi requisiti negativi. Sono le azioni o i dati a cui un gruppo non deve poter accedere, che non deve poter modificare, divulgare o approvare. Spesso rivelano lacune che un elenco di azioni consentite non riesce a evidenziare.
- Elenca le categorie di utenti: dipendenti, responsabili di team, dirigenti, personale temporaneo, collaboratori esterni, clienti, partner, revisori e amministratori tecnici.
- Per ogni categoria, elenca le azioni: visualizzare, creare, modificare, commentare, assegnare, approvare, eliminare, esportare, condividere, configurare e amministrare.
- Definisci l’ambito di ogni azione: record propri, record assegnati, record del team, uno spazio di lavoro, un account cliente, tutti i record o nessun record.
- Identifica i campi sensibili e le azioni a elevato impatto separatamente dall’accesso ai contenuti ordinari.
Identifica il modello di accesso dell’applicazione: ruoli, gruppi, oggetti e confini
Chiedi al fornitore o alla documentazione del progetto di mostrare l’esatto modello di accesso della versione che intendi distribuire. Registra ciò che è documentato, ciò che può essere dimostrato in un’istanza di test e ciò che rimane incerto. Non colmare le lacune con supposizioni basate su un’altra applicazione o su un’etichetta di ruolo familiare.
Come minimo, stabilisci se le autorizzazioni sono assegnate tramite ruoli fissi, ruoli personalizzati, gruppi, concessioni dirette agli utenti o una combinazione di questi elementi. Quindi determina l’ambito in cui tali autorizzazioni si applicano: l’intera istanza, un’organizzazione, un team, uno spazio di lavoro, un progetto, una raccolta, un record o un campo.
Il confine di uno spazio di lavoro può essere utile solo se limita realmente l’accesso nel modo necessario. Verifica se le persone possono effettuare ricerche oltre i confini, seguire collegamenti ad altri oggetti, ricevere notifiche contenenti informazioni riservate, esportare dati oltre confine o ottenere accesso tramite appartenenze ereditate.
- Puoi creare un ruolo che corrisponda a ogni requisito senza assegnare privilegi non correlati?
- I ruoli sono globali o possono differire per spazio di lavoro, progetto, cliente o altro confine aziendale?
- Le autorizzazioni possono essere impostate a livello di oggetto o di campo dove il rischio lo richiede?
- Sono supportate gerarchie di ruoli e, in tal caso, i privilegi ereditati rimangono comprensibili e verificabili?
- Le concessioni dirette possono aggirare il normale modello di ruolo e come verranno individuate queste eccezioni durante la revisione?
- Cosa succede all’accesso quando un oggetto, uno spazio di lavoro o un utente viene spostato o copiato?
Verifica la separazione tra amministrazione e accesso ai dati aziendali sensibili
L’amministrazione operativa e l’accesso ai dati aziendali sono responsabilità diverse. Un team può aver bisogno di qualcuno che gestisca utenti, instradamento, backup o disponibilità dell’applicazione senza visualizzare abitualmente informazioni riservate su clienti, dipendenti o dati finanziari. Stabilisci se l’applicazione supporta questa distinzione, invece di presumere che un amministratore possa essere limitato in modo appropriato.
La separazione dei compiti riguarda la possibilità che una singola persona disponga di privilegi sufficienti per abusare di un sistema da sola. Può essere implementata tramite ruoli in conflitto assegnati preventivamente oppure tramite controlli che limitano un’azione in conflitto al momento dell’accesso. La necessità di uno dei due approcci dipende dal processo e dal rischio, ma la questione dovrebbe essere esplicita per le azioni a elevato impatto.
Mappa anche il confine infrastrutturale. Docker avverte che il controllo di un daemon Docker è altamente privilegiato e può fornire accesso root all’host. Allo stesso modo, le interfacce amministrative di supporto richiedono una revisione; Traefik rileva che un’API o una dashboard di produzione può esporre elementi di configurazione, inclusi dati sensibili, e dovrebbe essere protetta con autenticazione e autorizzazione.
- Un amministratore utenti può creare account e reimpostare gli accessi senza leggere i normali record aziendali?
- Un amministratore di contenuti o spazi di lavoro può gestire le appartenenze senza ricevere privilegi illimitati di esportazione o configurazione?
- Chi può modificare i ruoli, creare account privilegiati, alterare le impostazioni di autenticazione, accedere ai backup o gestire il deployment?
- Le azioni sensibili sono registrate in modo che l’organizzazione possa esaminarle?
- Per operazioni ad alto rischio, dovrebbero essere richieste due persone distinte per la richiesta e l’approvazione?
Verifica collaboratori esterni, appaltatori e utenti clienti
Gli utenti esterni rivelano spesso la differenza tra un ruolo generico di collaborazione e un modello sicuro di accesso per i clienti. Il loro accesso potrebbe richiedere una breve scadenza, un insieme limitato di progetti, nessuna visibilità della directory, nessun diritto di esportazione e nessuna possibilità di invitare altri. Verifica questi requisiti con le funzionalità effettive di condivisione e appartenenza dell’applicazione.
Non presumere che un’interfaccia limitata significhi dati limitati. Verifica a quali elementi l’account esterno può accedere tramite ricerca, URL diretti, notifiche, allegati, commenti, esportazioni e API. Testa un utente cliente rispetto a record rappresentativi di un altro cliente, non solo in un ambiente vuoto.
Se l’applicazione non può esprimere il confine richiesto, potrebbero essere più sicuri un’istanza separata, uno spazio di lavoro separato con controlli convalidati attentamente, un diverso processo di condivisione o un’applicazione diversa. La risposta corretta dipende dalla sensibilità dei dati e dalle conseguenze di un errore.
- L’accesso esterno può essere limitato a utenti nominativi e ambiti aziendali definiti?
- Gli inviti possono scadere e l’accesso può essere rimosso tempestivamente?
- Gli utenti esterni possono scoprire altri utenti, team, clienti o record?
- Possono scaricare, esportare, copiare o ricondividere informazioni?
- Possono creare utenti, invitare collaboratori o modificare le appartenenze?
- L’organizzazione può esaminare tutti gli account esterni attivi e i relativi accessi?
Valuta separatamente token API, account di servizio e integrazioni
Le autorizzazioni dell’interfaccia umana non dimostrano che le integrazioni siano sicure. Le API possono esporre funzioni amministrative o sensibili se l’autorizzazione a livello di endpoint manca o è troppo ampia. OWASP identifica specificamente l’autorizzazione compromessa a livello di funzione come un rischio quando endpoint amministrativi sono accessibili senza controlli adeguati.
Censisci ogni identità non umana: token API, credenziali di integrazione, utenti di automazione, account di servizio e webhook, ove applicabile. Per ciascuna, identifica proprietario, scopo, autorizzazioni, ambito, posizione di archiviazione, processo di rotazione e metodo di revoca. Un token non dovrebbe ereditare l’accesso onnipotente di un amministratore umano solo perché era comodo crearlo.
Testa le integrazioni usando gli stessi ambiti rappresentativi delle persone. Un’integrazione di reporting che necessita di dati aggregati non dovrebbe ricevere automaticamente la possibilità di modificare record o amministrare utenti. Mantieni distinte le credenziali di sviluppo, test e produzione quando il tuo modello operativo supporta tale separazione.
- L’applicazione supporta credenziali con ambito limitato oppure ogni token equivale di fatto all’accesso completo dell’account?
- I token possono essere attribuiti a un singolo proprietario o a uno scopo di servizio nominato?
- Le autorizzazioni possono essere limitate per azione, ambito della risorsa o scadenza?
- Un token può essere revocato senza disabilitare integrazioni non correlate?
- Le risposte API rispettano gli stessi confini previsti dell’interfaccia utente?
- Gli endpoint e le funzioni amministrative vengono testati esplicitamente, anziché dedotti dalle limitazioni dell’interfaccia?
Crea una matrice di test delle autorizzazioni con record rappresentativi e account non di produzione
Una matrice di test delle autorizzazioni trasforma i requisiti di accesso in evidenze. Crea utenti di test rappresentativi per ogni ruolo, incluso un account deliberatamente a basso privilegio e un account esterno. Crea record rappresentativi che coprano scenari ordinari, riservati, tra team, tra clienti, archiviati e di trasferimento della proprietà rilevanti per la tua organizzazione.
Per ogni ruolo e azione, indica il risultato atteso: consentito, negato o consentito solo entro un ambito nominato. Testa tutti i percorsi disponibili, inclusi interfaccia utente, collegamenti diretti, ricerca, esportazioni, azioni in blocco, client mobili se utilizzati, notifiche e API. Il testing dell’autorizzazione dovrebbe coprire sia i percorsi negati sia i percorsi utente conclusi con successo.
Ripeti i test quando cambiano ruoli, integrazioni, flussi di lavoro principali o funzionalità dell’applicazione. OWASP osserva che i problemi di autorizzazione sorgono spesso quando vengono aggiunte o modificate funzionalità senza rivalutare il comportamento dell’autorizzazione.
- Usa righe per i ruoli rappresentativi e colonne per le azioni e gli ambiti dei dati.
- Registra sia i risultati attesi sia quelli osservati, oltre a evidenze quali data del test, nome dell’account e riferimento del risultato.
- Testa, ove rilevante, azioni di lettura, creazione, modifica, eliminazione, condivisione, esportazione, invito, modifica del ruolo e configurazione.
- Includi tentativi di accesso ai dati di un altro team, cliente o spazio di lavoro.
- Aggiungi test di regressione per le regole di autorizzazione a più alto rischio quando il tuo team ne ha la capacità.
Pianifica i processi per ingresso, cambio ruolo e uscita
Anche un modello di ruoli ben progettato fallisce se account e appartenenze non vengono mantenuti aggiornati. Definisci come una persona ottiene l’accesso, come cambia l’accesso quando il ruolo o l’assegnazione a un cliente cambiano e come perde l’accesso quando terminano il rapporto di lavoro, un contratto o un progetto. Assegna un responsabile nominato per ogni passaggio e stabilisci una cadenza di revisione operativa adeguata al rischio.
Se l’applicazione supporta SCIM, il protocollo fornisce operazioni per le risorse Utente e Gruppo, incluse creazione, recupero, modifica ed eliminazione. Questo può supportare flussi di provisioning, ma non decide gli eventi che attivano il ciclo di vita, la progettazione dei ruoli, le regole di trasferimento della proprietà o la gestione delle eccezioni. Questi restano compiti dell’organizzazione.
Presta particolare attenzione alla proprietà. Prima di disabilitare un account, determina chi sarà proprietario dei record attivi, progetti, code, file, automazioni, report e credenziali di integrazione associati a quell’utente. Conferma che il trasferimento non ampli involontariamente l’accesso del destinatario.
- Ingresso: verifica l’identità, seleziona il ruolo approvato, imposta l’ambito corretto e registra il responsabile o manager che approva.
- Cambio ruolo: rimuovi gli accessi obsoleti prima di aggiungere o contestualmente all’aggiunta dei nuovi accessi; esamina le concessioni dirette e le appartenenze esterne.
- Uscita: disabilita o rimuovi l’accesso, revoca i token, trasferisci la proprietà ed esamina le risorse condivise.
- Fine del rapporto con un collaboratore esterno o un cliente: usa una revisione pianificata e conferma la rimozione, anziché fare affidamento su un’attività manuale da ricordare.
- Esamina periodicamente account privilegiati, esterni, inattivi e di eccezione.
Domande frequenti
Cosa dovrebbe includere una checklist RBAC per un’applicazione self-hosted?
Includi gruppi di utenti reali, azioni richieste e vietate, ambito dei dati, ruoli e gruppi, confini di spazi di lavoro o oggetti, separazione amministrativa, controlli sugli utenti esterni, autorizzazioni per API e account di servizio, una matrice di test delle autorizzazioni e processi per ingresso-cambio ruolo-uscita. Documenta ciò che è stato dimostrato rispetto a ciò che è solo presunto.
L’hosting gestito fornisce l’RBAC dell’applicazione?
L’infrastruttura gestita e l’autorizzazione dell’applicazione risolvono problemi diversi. Airbip gestisce l’infrastruttura cloud intorno ai deployment di applicazioni basate su Docker, inclusi instradamento, certificati TLS, gestione del ciclo di vita e backup configurabili. Il cliente deve comunque selezionare un’applicazione il cui modello di autorizzazioni sia adatto all’organizzazione, definire ruoli e ambiti di accesso e gestire adeguatamente la governance degli accessi.
Un ruolo chiamato amministratore è sempre troppo potente?
Non necessariamente, ma deve essere testato. Determina esattamente cosa l’amministratore può visualizzare, modificare, esportare e delegare e se l’amministrazione operativa può essere separata dall’accesso ai dati aziendali sensibili. Esamina anche l’amministrazione dell’infrastruttura di supporto, perché questi privilegi possono essere altamente sensibili.
Perché testare le autorizzazioni API se l’interfaccia utente sembra limitata?
Le limitazioni dell’interfaccia utente non dimostrano che gli endpoint API applichino le stesse regole di autorizzazione. Testa separatamente le funzioni API, in particolare funzioni amministrative, esportazioni e accesso tra ambiti diversi. Censisci e limita token e account di servizio in base al loro scopo specifico.
Quando un’applicazione self-hosted non è adatta al modello di accesso richiesto?
Scegli un’altra applicazione o un altro approccio di deployment quando i confini richiesti non possono essere espressi e verificati senza ampie eccezioni; quando gli utenti esterni non possono essere isolati in modo sufficientemente sicuro; quando le azioni sensibili richiedono una separazione che il sistema non può supportare; oppure quando il team non può gestire le necessarie revisioni degli accessi, i test e i processi del ciclo di vita. L’infrastruttura gestita non compensa un modello di autorizzazione a livello applicativo non adatto.
Fonti e approfondimenti
- Role Based Access Control FAQs — National Institute of Standards and Technology
- Authorization Cheat Sheet — OWASP Foundation
- Authorization Testing Automation Cheat Sheet — OWASP Foundation
- API5:2023 Broken Function Level Authorization — OWASP Foundation
- Separation of Duty glossary entry — National Institute of Standards and Technology
- SP 800-53 Rev. 5 controls download page — National Institute of Standards and Technology
- RFC 7644: System for Cross-domain Identity Management Protocol — IETF
- Docker Engine security — Docker
- Protect the Docker daemon socket — Docker
- API & Dashboard — Traefik Labs