Premesse
Molti sistemi gestionali, quando parlano di sicurezza, si fermano al livello del modulo: l’utente X può accedere al modulo manutenzione, l’utente Y no. È una granularità limitata, che raramente rispecchia la realtà organizzativa reale di un’azienda con ruoli diversi, sedi diverse, informazioni che devono restare visibili solo a determinati gruppi anche all’interno dello stesso modulo. La sicurezza applicativa che un software di facility management dovrebbe offrire nel 2026 si gioca a un livello molto più fine: non solo quale modulo, ma quali righe di quella tabella, e persino quali singoli campi di quelle righe.
Cos’è, tecnicamente, la Row-Level Security, e perché deve essere risolta lato server e non semplicemente nascosta lato client?
La Row-Level Security è un meccanismo che filtra quali righe di una tabella un utente può vedere o modificare, in base al proprio ruolo, gruppo di appartenenza, o relazione con quel dato specifico – per esempio, un building manager che vede solo gli asset degli edifici di propria competenza, non l’intero patrimonio aziendale.
Un errore architetturale comune, e pericoloso, è implementare questo filtro solo nell’interfaccia utente, nascondendo semplicemente le righe non pertinenti nella visualizzazione: un utente sufficientemente esperto potrebbe comunque intercettare le richieste dirette all’API sottostante e ottenere dati che l’interfaccia gli nasconde, perché il server risponderebbe comunque con l’insieme completo dei dati.
La soluzione tecnicamente corretta risolve il filtro sempre lato server, ad ogni singola richiesta, indipendentemente da quale client la generi – l’interfaccia web, l’app mobile, una futura integrazione esterna – così che il vincolo di sicurezza non dipenda mai dalla buona fede o dalla correttezza del codice client, ma sia imposto in modo centralizzato dal motore che risponde alle query.
Come si estende questo principio al singolo campo, e perché è un requisito tecnico più complesso della sola sicurezza a livello di riga?
Filtrare le righe è già un requisito non banale; filtrare i singoli campi di una riga che l’utente può comunque vedere aggiunge un ulteriore livello di complessità tecnica. Pensiamo a un caso concreto: un tecnico esterno può aver bisogno di vedere l’anagrafica di un asset per intervenire su di esso, ma non dovrebbe necessariamente vedere il costo di acquisto o altre informazioni economiche riservate collegate a quello stesso record.
Un motore di permessi a livello di campo deve poter restituire la stessa riga con un sottoinsieme di colonne diverso a seconda di chi la sta interrogando, senza duplicare la logica di business per ogni possibile combinazione di ruolo e campo, il che richiede che questa regola viva anch’essa nei metadati configurabili di cui ho parlato negli articoli dedicati all’architettura no-code, applicata in modo trasversale da un unico motore di interpretazione.
Perché anche i parametri di filtro e ordinamento che viaggiano in una richiesta dovrebbero restare protetti, e come si ottiene tecnicamente?
Un dettaglio spesso trascurato riguarda cosa succede ai parametri con cui un utente filtra o ordina i propri dati – per esempio, i criteri di ricerca applicati su una griglia. Se questi parametri viaggiano in chiaro nell’indirizzo di una richiesta, chiunque osservi il traffico di rete, o semplicemente legga la barra degli indirizzi, può ricostruire quali criteri di ricerca un utente sta applicando, un’informazione che in alcuni contesti – per esempio ricerche su dati sensibili – non dovrebbe essere esposta nemmeno in questa forma indiretta.
Una soluzione tecnica solida cifra questi parametri prima che lascino il server, restituendo al client un token opaco da riportare tale e quale nella richiesta successiva, senza che il client debba mai conoscere o poter alterare il contenuto reale dei criteri applicati.
Come si evita che l’architettura no-code, descritta negli articoli precedenti, diventi essa stessa un rischio di sicurezza?
È una domanda legittima: se tabelle e permessi sono configurabili da amministratori interni invece che cablati nel codice da sviluppatori esperti, come si garantisce che questa flessibilità non introduca vulnerabilità? La risposta tecnica sta nella separazione netta tra il motore, scritto una volta con rigore ingegneristico e sottoposto a verifica approfondita, e la configurazione, che può variare liberamente senza mai bypassare i controlli di sicurezza incorporati nel motore stesso.
Concretamente, questo significa che qualunque configurazione di campo o di permesso, per quanto creativa, passa sempre attraverso lo stesso livello di generazione delle query parametriche sicure, mai attraverso una scorciatoia che concatena direttamente input configurato e istruzione SQL.
Che ruolo ha l’autenticazione a due fattori in un sistema che gestisce dati sensibili su edifici e persone?
Un sistema che tratta dati di dipendenti, fornitori, planimetrie di sicurezza e informazioni potenzialmente critiche per la continuità operativa di un’organizzazione dovrebbe offrire un’autenticazione a due fattori robusta e accessibile, non complicata al punto da scoraggiarne l’adozione.
Un approccio self-service, che permetta all’utente di attivare in autonomia un metodo basato su app di autenticazione temporanea (TOTP) o su un codice inviato via email, con codici di backup da conservare per i casi di dispositivo perso o non disponibile, bilancia sicurezza reale e usabilità quotidiana, un compromesso che un’imposizione troppo rigida rischierebbe di vanificare spingendo gli utenti verso scorciatoie non sicure.
Come si comporta un sistema ben progettato quando le richieste diventano numerose e concorrenti, senza compromettere la sicurezza per guadagnare velocità?
Un errore tecnico che ho visto commettere, sotto la pressione di ottimizzare le prestazioni, è eseguire operazioni potenzialmente lunghe – l’elaborazione di un file pesante, una query complessa – in modo bloccante all’interno di un endpoint che dovrebbe restare reattivo, con l’effetto di rallentare l’intera applicazione per tutti gli utenti connessi nello stesso momento in cui quell’operazione è in corso.
Un endpoint asincrono ben progettato delega le operazioni pesanti a un’esecuzione separata – un thread dedicato, una coda di elaborazione – restituendo il controllo immediatamente, senza mai bloccare il ciclo di gestione delle richieste su cui si appoggiano tutti gli altri utenti del sistema nello stesso momento. È un principio di progettazione che, se violato, si manifesta proprio nei momenti di maggior carico, quando la sicurezza dell’intero servizio – inteso come disponibilità, non solo come riservatezza – viene messa alla prova.
Che differenza percepiscono le quattro figure coinvolte, di fronte a questo livello di sicurezza granulare?
Il proprietario percepisce una riduzione del rischio reputazionale e legale legato a un’eventuale fuga di dati sensibili, sapendo che l’accesso è limitato per costruzione e non per convenzione. Il responsabile IT trova in questa granularità uno strumento per applicare policy aziendali complesse – diversi livelli di accesso per diversi ruoli – senza dover accettare compromessi grossolani.
Il building manager e il manutentore interno, pur senza percepire direttamente il meccanismo tecnico sottostante, ne beneficiano nella pratica: ciascuno vede esattamente ciò che gli serve per il proprio lavoro, senza essere sommerso da informazioni non pertinenti né esposto a dati che non dovrebbe vedere. La ditta esterna, infine, trova in questi meccanismi la garanzia tecnica che i confini del proprio accesso, definiti contrattualmente, siano realmente rispettati dal sistema, non solo dichiarati sulla carta.
Conclusioni
La sicurezza applicativa di un software di facility management si misura nella granularità dei suoi controlli – fino al singolo campo, non solo al singolo modulo – e nella disciplina con cui questi controlli vengono applicati sempre lato server, mai delegati alla buona fede del client. È un requisito tecnico che richiede rigore architetturale fin dalla progettazione, non un livello di protezione che si può aggiungere a posteriori senza ripensare la struttura del sistema.
Nel prossimo articolo entriamo nel merito di un tema strettamente collegato ma distinto: cosa significa davvero applicare il GDPR in modo reale, con enforcement effettivo e non solo formale.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui