Premesse
Nessuna organizzazione, oggi, gestisce i propri processi con un solo sistema isolato: anche il Software di Facility Management deve dialogare con altri sistemi aziendali: l’ERP, una soluzione di BI, un portale fornitori, un cruscotto direzionale che aggrega dati da più fonti. La domanda tecnica che chiude idealmente il capitolo dedicato alla sicurezza non è “il sistema può integrarsi con altri”, ma “come si espone un sottoinsieme controllato di dati verso l’esterno senza perdere il controllo su cosa viene condiviso, con chi, e per fare cosa”.
Perché un motore dedicato ad API esterne è diverso da “aprire l’API interna” a un sistema terzo?
L’errore più comune, quando un’organizzazione ha fretta di integrare un sistema esterno, è concedere l’accesso diretto alle stesse API interne usate dall’interfaccia principale dell’applicazione. È una scorciatoia rischiosa: quelle API sono progettate per l’uso interno, cambiano nel tempo seguendo l’evoluzione del prodotto, ed espongono spesso più dati di quanto un’integrazione esterna dovrebbe vedere. Un motore di pubblicazione dedicato, al contrario, tratta ciò che viene esposto verso l’esterno come un prodotto a sé, con una propria versione, una propria configurazione esplicita di quali campi sono visibili e quali no, indipendente dall’evoluzione interna dell’applicazione principale.
Tecnicamente, questo si traduce spesso in un runtime separato – un processo o una porta dedicata – che isola il traffico delle integrazioni esterne da quello degli utenti che lavorano sull’interfaccia principale, così che un picco di richieste da un sistema terzo mal configurato non comprometta le prestazioni dell’applicazione per gli utenti interni.
Come realizzare un compilatore di configurazione che trasforma una definizione dichiarativa in un’API pubblica?
Il processo tecnicamente più solido non pubblica direttamente ciò che un amministratore ha appena configurato, ma passa attraverso una fase di compilazione e validazione: la configurazione dichiarata – quali tabelle, quali campi, quali permessi per gruppo – viene verificata per coerenza e trasformata in uno snapshot immutabile, identificato da un hash univoco, che rappresenta esattamente lo stato che verrà esposto.
Questo snapshot può essere pubblicato, attivato o ritirato con un’azione esplicita, mantenendo uno storico completo di ogni versione mai pubblicata, con la possibilità tecnica di tornare a una versione precedente con un’unica operazione se una nuova pubblicazione introduce un problema imprevisto.
Questo approccio – configurazione dichiarativa, compilazione, snapshot immutabile, attivazione esplicita – è lo stesso principio usato nel software professionale per gestire il rilascio controllato di versioni, applicato qui alla pubblicazione di dati invece che di codice.
Quali controlli granulari per singolo campo dovrebbe offrire un motore di questo tipo?
La sicurezza di un’API pubblicata si gioca soprattutto nel dettaglio, campo per campo: quali colonne sono esposte in lettura, quali anche in scrittura, quali richiedono un mascheramento parziale del dato invece dell’esposizione completa – per esempio mostrando solo le ultime cifre di un codice sensibile – e quali permessi specifici per gruppo di utenti esterni si applicano a ciascun campo.
Un requisito tecnico particolarmente importante, coerente con quanto discusso nell’articolo precedente sul GDPR, è che i campi marcati come dati personali vengano esclusi automaticamente dall’esposizione di default, richiedendo un’autorizzazione esplicita e consapevole per includerli in una pubblicazione, invece che il contrario. È un’inversione dell’onere della prova tecnicamente semplice da implementare ma concettualmente importante: l’esposizione di un dato sensibile deve essere una scelta deliberata, mai un effetto collaterale di una configurazione generica.
Perché la documentazione dell’API dovrebbe essere generata automaticamente, e non scritta e mantenuta a mano separatamente?
Una documentazione API scritta a mano tende inevitabilmente a disallinearsi da ciò che l’API realmente espone, con il passare del tempo e delle modifiche di configurazione. Generare automaticamente la documentazione in un formato standard come OpenAPI, direttamente dalla configurazione compilata di cui parlavo sopra, garantisce che la documentazione sia sempre sincronizzata con la realtà, per costruzione, non per disciplina di manutenzione: ogni volta che la configurazione cambia, la documentazione generata riflette immediatamente il nuovo stato, senza il rischio – frequente con la documentazione scritta manualmente – che un endpoint documentato non corrisponda più a quello effettivamente disponibile, o viceversa.
Come si gestisce l’autenticazione e l’autorizzazione delle chiamate provenienti da sistemi esterni?
Un motore ben progettato non inventa un sistema di autenticazione parallelo per le integrazioni esterne, ma riusa lo stesso meccanismo di token già in uso per l’applicazione principale, assegnando a ogni sistema terzo integrato le proprie credenziali con permessi delimitati.
La Row-Level Security applicativa, di cui ho parlato nell’articolo dedicato alla sicurezza granulare, dovrebbe restare pienamente attiva anche sulle chiamate esterne: un sistema terzo autorizzato a vedere solo un sottoinsieme di edifici non dovrebbe poter aggirare questo confine semplicemente perché sta chiamando un’API diversa da quella usata dagli utenti interni.
A questo si affianca, come misura di sicurezza di base ma spesso trascurata, una configurazione CORS (Cross-Origin Resource Sharing) impostata in modalità restrittiva per default – fail-closed – che richiede un’autorizzazione esplicita per ogni dominio che può effettivamente interagire con l’API, invece di accettare richieste da qualunque origine per comodità di sviluppo dimenticata in produzione.
Che valore strategico ha, per il proprietario, poter esporre dati in autonomia senza commissionare uno sviluppo per ogni nuova integrazione?
È qui che si chiude il cerchio con il tema del lock-in affrontato all’inizio di questa serie: un proprietario che può configurare in autonomia quali dati esporre verso un nuovo sistema partner – un ERP aggiornato, un nuovo portale fornitori, un cruscotto direzionale commissionato a terzi – senza dover ogni volta commissionare uno sviluppo dedicato al fornitore del software di Facility Management, mantiene un controllo reale sulla propria roadmap di integrazione, invece di restare dipendente dai tempi e dalle priorità di un singolo fornitore per ogni nuova connessione.
Come cambia, per il responsabile IT, la gestione della superficie di rischio quando le integrazioni esterne sono governate in questo modo?
Il responsabile IT, che deve rispondere della sicurezza complessiva del perimetro aziendale, trae un beneficio diretto da un motore di pubblicazione che rende esplicita e verificabile ogni integrazione attiva – quali sistemi hanno accesso, a quali dati, con quali permessi – invece di dover ricostruire questa mappa a partire da configurazioni sparse o da accordi informali stipulati nel tempo da persone diverse.
Un audit trail dedicato per ogni chiamata, con identificativo di correlazione per ogni richiesta, come descritto nell’articolo precedente, completa questo quadro di controllo, rendendo ogni integrazione esterna un elemento gestito e monitorabile del sistema, non una zona grigia ai margini del perimetro di sicurezza aziendale.
Conclusioni
Un motore di pubblicazione API dedicato, con compilazione e versionamento immutabile, controlli granulari per singolo campo, documentazione sempre sincronizzata e autenticazione riusata dal sistema principale con permessi delimitati, permette a un’organizzazione di aprirsi verso il proprio ecosistema di sistemi partner senza perdere il controllo su cosa viene condiviso.
Con questo si chiude il capitolo dedicato a sicurezza, privacy e compliance: nei prossimi articoli guardiamo avanti, verso l’intelligenza artificiale applicata ai dati aziendali e l’osservabilità del sistema stesso.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui