Controllo degli accessi: autenticazione, autorizzazione e gestione delle risorse

Il controllo degli accessi è uno di quegli argomenti che sembrano ovvi finché non lo si osserva da vicino. È anche, anno dopo anno, la categoria numero uno della OWASP Top 10 (Broken Access Control), e di gran lunga la debolezza più comune che riscontriamo, sia nel settore in generale che nelle nostre stesse analisi. La buona notizia è che, una volta individuate le domande giuste, l’argomento diventa molto più semplice.

Che cos’è esattamente il controllo degli accessi?

Il controllo degli accessi determina chi può fare cosa, su quale risorsa. Quando un’applicazione riceve una richiesta, deve rispondere a tre domande, e tutte e tre contano.

1. Sappiamo chi è l’utente? (autenticazione)

Questa è la fase dell’identità: l’utente è davvero chi dichiara di essere? Password, MFA, SSO: tutti questi elementi rispondono a questa prima domanda.

2. L’utente è autorizzato a eseguire questa azione? (autorizzazione)

Sapere chi è l’utente non dice nulla su ciò che è autorizzato a fare. Un utente autenticato non è necessariamente un utente autorizzato a eliminare, modificare o amministrare.

3. Ha il diritto di accedere a questa risorsa specifica? (autorizzazione a livello di oggetto)

Questa è la domanda più spesso dimenticata. Avere il diritto di visualizzare “una” voce non significa avere il diritto di visualizzare “tutte” le voci. Quando questo controllo manca, si parla di IDOR (Insecure Direct Object Reference): basta modificare un identificatore nella richiesta per accedere ai dati di qualcun altro.

Da tenere a mente: dimenticare anche una sola di queste tre domande è sufficiente per creare una vulnerabilità. Le tre domande formano un insieme unico.

La domanda che spesso viene dimenticata: dove avviene il controllo?

Rispondere correttamente alle tre domande non basta. È necessario chiedersi anche dove vengono applicati questi controlli. Ed è esattamente qui che si fa la differenza tra una vera misura di sicurezza e una semplice convenzione dell’interfaccia.

Lato client

I controlli lato client vengono applicati dall’interfaccia: un pulsante “Elimina” nascosto, un’opzione disattivata, un menu che non compare. Questo è utile e perfettamente normale. È ciò che rende un’applicazione piacevole da usare e che allontana gli utenti da opzioni che verrebbero comunque rifiutate. Non è ciò che impedisce l’azione: quando il controllo degli accessi è implementato correttamente, il server rifiuta l’operazione indipendentemente da ciò che mostra l’interfaccia.

Questi controlli risiedono sul lato dell’utente, e chiunque manipoli direttamente le richieste può eluderli, poiché l’interfaccia è solo una delle porte per accedere ai dati.

Lato server

I controlli lato server vengono applicati dall’applicazione stessa, dove risiedono i dati. Non dipendono dall’interfaccia utilizzata e non possono essere elusi creando una richiesta manipolata.

Questo livello, e solo questo, è ciò che protegge realmente i dati sensibili: visualizzazione, modifica, eliminazione, rivelazione di una password, accesso agli allegati e così via.

Un controllo lato client è una convenzione di user experience, non una misura di sicurezza. La regola è semplice: qualsiasi permesso che protegge dati sensibili o un flusso critico deve essere applicato lato server. Un controllo lato client può accompagnarlo, ma non può mai sostituirlo.

Cosa significa questo in pratica per i suoi dati

Prendiamo l’esempio di Remote Desktop Manager (RDM), la nostra applicazione desktop per la gestione delle connessioni remote e delle credenziali. RDM offre un’esperienza ricca: permessi, ruoli, opzioni mostrate o nascoste in base all’utente. Ma dove vengono effettivamente applicati questi permessi? La risposta dipende interamente dall’architettura del workspace a cui si collega.

• Un workspace SQL Server (una connessione diretta al database). In questo caso, non c’è alcun application server tra RDM e il database. RDM comunica direttamente con SQL Server. I permessi esistono, ma vengono applicati dal client. In altre parole, risiedono tutti lato client. Il livello lato server, quello capace di resistere alla manipolazione diretta, semplicemente non è presente.
• Un workspace consigliato, basato su un application server. Si presenta in due varianti: Devolutions Server (DVLS), il workspace self-hosted che si distribuisce sulla propria infrastruttura, e Devolutions Cloud, il workspace completamente gestito e ospitato nel cloud. In entrambi i casi, RDM rimane il client, ma è il server a validare ogni accesso: chi è l’utente, cosa è autorizzato a fare e su quale risorsa specifica. Le tre domande trovano risposta dove conta davvero, lato server.

Non si tratta di buone intenzioni o di una configurazione accurata. È una questione di architettura. Senza un application server, non esiste un luogo fisico dove applicare i controlli lato server. Questo è il motivo principale per cui raccomandiamo di abbinare RDM a un Devolutions Password Manager: non per una preferenza di prodotto, ma perché è l’architettura a richiederlo.

In sintesi

• Un buon controllo degli accessi risponde a tre domande: chi (autenticazione), cosa (autorizzazione) e su quale risorsa (autorizzazione a livello di oggetto).
• Un controllo lato client migliora l’esperienza, ma non protegge nulla da solo, poiché può essere eluso.
• Solo un controllo lato server protegge realmente i dati sensibili.
• Perché questo livello lato server esista, è necessario un Devolutions Password Manager dietro RDM: Devolutions Server (DVLS) se si desidera l’opzione self-hosted, oppure Devolutions Cloud se si preferisce un servizio completamente gestito.

Se RDM si collega attualmente in modo diretto a un database SQL Server, vale la pena chiedersi: dove vengono effettivamente applicati i suoi controlli degli accessi? È l’architettura, non la configurazione, a fornire la risposta onesta. Può esplorare i workspace disponibili per scoprire quale si adatta al suo ambiente.

E il costo raramente è l’ostacolo che ci si aspetta: sia Devolutions Server che Devolutions Cloud offrono un’opzione gratuita per iniziare. Utilizzare Devolutions Server come backend richiede semplicemente una licenza Remote Desktop Manager Enterprise attiva, e poiché collegare RDM a un database SQL Server richiede già la stessa licenza Enterprise, con ogni probabilità dispone già di tutto il necessario per effettuare il passaggio. (Per accedere al workspace da un browser web, senza RDM, è necessaria una Client Access License separata.)