La sicurezza non è qualcosa che aggiungiamo alla fine dello sviluppo. Fa parte del modo in cui progettiamo ogni sistema: da come gestiamo codice e credenziali a come vengono trattati i dati, configurati gli accessi e controllato ciò che arriva in produzione.
Non tutti i progetti presentano gli stessi rischi. Un sito informativo, un'automazione interna e un software che gestisce informazioni riservate richiedono livelli di attenzione differenti.
Per questo definiamo le misure tecniche in base all'architettura, ai dati coinvolti, alle integrazioni utilizzate e al contesto in cui il sistema dovrà operare.
Sicurezza proporzionata al progetto
Il nostro obiettivo non è aggiungere complessità, ma proteggere ogni lavoro in modo adeguato.
Prima di sviluppare analizziamo quali informazioni attraverseranno il sistema, dove verranno elaborate, quali servizi potranno accedervi e quali punti richiederanno maggiore attenzione.
Da questa analisi derivano le scelte tecniche: gestione degli accessi, separazione degli ambienti, protezione delle credenziali, validazione degli input, logging, backup e controlli prima del rilascio.
Più aumenta la criticità del sistema, più aumentano i controlli necessari.
Codice protetto e sviluppo controllato
Il codice viene mantenuto in repository privati e versionati, con accesso limitato alle persone coinvolte nel progetto.
Password, token, chiavi API e altre credenziali vengono mantenuti separati dal codice e gestiti attraverso strumenti dedicati.
Quando necessario, separiamo gli ambienti di sviluppo, test e produzione per verificare modifiche e nuove funzionalità prima che raggiungano il sistema utilizzato dagli utenti.
La cronologia delle modifiche mantiene inoltre il lavoro tracciabile nel tempo e permette di individuare più facilmente cosa è cambiato e intervenire in modo controllato quando necessario.
Accessi limitati a ciò che serve
Seguiamo un principio semplice: ogni persona dovrebbe poter accedere soltanto a ciò di cui ha realmente bisogno.
Limitiamo quindi autorizzazioni e privilegi non necessari ed evitiamo, quando possibile, la condivisione degli account.
Gli accessi ai servizi principali vengono protetti con autenticazione a più fattori quando disponibile e appropriata, e vengono rivisti quando cambiano persone, responsabilità o necessità operative.
Ridurre gli accessi superflui contribuisce a ridurre la superficie di rischio del sistema.
Trattiamo solo i dati necessari
Progettiamo i sistemi cercando di raccogliere, conservare e utilizzare soltanto le informazioni necessarie al loro funzionamento.
Per la trasmissione dei dati utilizziamo connessioni cifrate nei componenti e nei servizi che lo supportano e, per i dati memorizzati, valutiamo le funzionalità di cifratura a riposo disponibili e appropriate all'infrastruttura scelta.
Gli accessi vengono limitati in base alle effettive necessità operative. Quando il progetto lo richiede, definiamo inoltre quali informazioni debbano essere conservate, per quanto tempo e quali possano invece essere eliminate, anonimizzate o escluse completamente dal processo.
Lo stesso principio vale quando il sistema comunica con API, servizi cloud o altri componenti esterni: prima di integrare un servizio analizziamo quali dati debbano realmente raggiungerlo e cerchiamo di evitare trasferimenti non necessari.
La domanda non è soltanto “possiamo utilizzare questo dato?”, ma anche “serve davvero al sistema?”.
Dove vivono i tuoi dati
In un software moderno sapere dove si trova il database principale non basta necessariamente a capire dove vengono conservate, elaborate o trasmesse tutte le informazioni.
Durante il loro ciclo di vita, i dati possono attraversare storage, backup, repliche, code di elaborazione, sistemi di logging e monitoraggio, servizi di autenticazione, API, piattaforme di comunicazione e componenti AI.
Per questo, quando la localizzazione o il controllo delle informazioni rappresentano un requisito, consideriamo l'architettura nel suo insieme.
Prima vengono i requisiti. Poi le scelte tecniche.
Il cliente conosce il proprio processo, la natura delle informazioni trattate, le policy interne e gli eventuali vincoli contrattuali o normativi.
Il nostro compito è tradurre questi requisiti in architettura.
Provider, regioni, sistemi di archiviazione e modalità di elaborazione vengono quindi definiti considerando elementi come:
- natura e sensibilità dei dati;
- requisiti geografici;
- policy interne;
- vincoli contrattuali o normativi applicabili;
- necessità operative;
- disponibilità e continuità del servizio;
- prestazioni;
- costi e sostenibilità della soluzione nel tempo.
Quando un requisito richiede competenze legali o regolatorie specifiche, le decisioni tecniche vengono costruite attorno ai vincoli indicati dal cliente o dai professionisti competenti.
L'architettura implementa i requisiti. Non li inventa.
La regione del database è solo una parte
Se determinati dati devono rimanere in Italia, nell'Unione Europea o in un'altra area geografica, possiamo progettare il sistema attorno a questo vincolo.
Ma verificare soltanto la regione del database può non essere sufficiente.
Vanno considerati anche gli altri componenti che possono contenere, duplicare o ricevere informazioni:
- database;
- object storage;
- backup e repliche;
- logging e monitoraggio;
- servizi di autenticazione;
- API e integrazioni;
- servizi AI.
Ognuno può avere configurazioni, regioni, tempi di conservazione e condizioni differenti.
Per questo distinguiamo tra la localizzazione di un singolo componente e il percorso complessivo dei dati nel sistema.
Questo non implica che tutti i dati debbano necessariamente risiedere nello stesso ambiente. A seconda dei requisiti, database, documenti, storage, backup o altri componenti possono essere distribuiti tra infrastrutture differenti, mantenendo chiaramente definiti accessi, responsabilità e flussi tra le diverse parti del sistema.
Residenza e sovranità non sono sinonimi
Un dato può essere fisicamente conservato in Europa senza che questa informazione, da sola, descriva l'intero livello di controllo sull'infrastruttura.
Quando il progetto presenta requisiti di sovranità o particolare riservatezza possono diventare rilevanti anche altri elementi:
- chi gestisce il servizio;
- a quale giurisdizione è soggetto;
- chi controlla identità e accessi;
- come vengono gestite le chiavi di cifratura;
- quali componenti dipendono da fornitori terzi;
- quanto è possibile migrare dati e servizi verso un'altra infrastruttura.
La sovranità non viene quindi trattata come un'etichetta binaria.
È una valutazione più ampia che dipende dai requisiti e dall'architettura concreta del progetto.
Anche i servizi esterni fanno parte dell'architettura
Un sistema raramente opera completamente da solo.
Può dipendere da provider cloud, servizi di autenticazione, strumenti di monitoraggio, gateway di pagamento, piattaforme di comunicazione, API, servizi AI o altri fornitori tecnologici.
Quando uno di questi componenti può ricevere o trattare informazioni del progetto, entra nel perimetro dei dati.
Prima di adottarlo consideriamo, per quanto rilevante:
- quale funzione svolge;
- quali informazioni riceve;
- dove vengono elaborate;
- quali configurazioni offre;
- quali politiche di conservazione applica;
- da quali ulteriori servizi dipende.
Quando possibile e utile al progetto, limitiamo inoltre la quantità di informazioni trasmesse ai servizi esterni.
L'obiettivo non è costruire sistemi senza dipendenze a ogni costo.
È sapere quali dipendenze esistono e quale ruolo hanno nel trattamento delle informazioni.
Quando entra l'AI, compare un altro flusso di dati
Integrare un modello AI non significa necessariamente concedergli accesso all'intero archivio dell'organizzazione.
Il sistema può essere progettato per recuperare il contesto pertinente allo specifico compito e inviare al servizio AI soltanto ciò che serve all'elaborazione prevista, evitando accessi indiscriminati e trasferimenti non necessari.
Il principio, però, non si ferma al payload inviato al modello.
Prima di integrare un servizio AI consideriamo anche, in base ai requisiti del progetto:
- dove avviene l'elaborazione;
- quali politiche di conservazione si applicano;
- quali configurazioni relative ai dati sono disponibili;
- quali infrastrutture e provider partecipano al servizio;
- quali modalità di deployment sono possibili.
Le risposte non sono uguali per ogni modello.
Dipendono dal provider, dal prodotto utilizzato, dal contratto e dalla configurazione selezionata.
Per questo non descriviamo genericamente un modello come “privato” o “sicuro” senza considerare il modo in cui viene effettivamente utilizzato.
Non tutti i progetti richiedono lo stesso livello di controllo
Un sistema che utilizza informazioni pubbliche non richiede necessariamente le stesse misure di un software che elabora documentazione finanziaria, informazioni riservate, proprietà intellettuale o dati soggetti a specifici vincoli organizzativi o normativi.
A seconda del contesto possiamo quindi valutare livelli differenti di controllo.
Cloud regionale
Applicazione e dati vengono collocati in regioni geografiche selezionate tra quelle offerte dal provider.
È una soluzione adatta a molti progetti quando servizi utilizzati, configurazioni e requisiti sono compatibili.
La regione, tuttavia, viene verificata sui componenti rilevanti e non considerata automaticamente una proprietà dell'intero sistema.
Infrastruttura locale o nazionale
Quando determinate componenti devono rimanere in uno specifico Paese, possono essere utilizzate infrastrutture coerenti con questo requisito.
Anche in questo caso consideriamo gli altri servizi che potrebbero ricevere, elaborare o duplicare parte delle informazioni.
Servizi AI con requisiti di residenza o sovranità
Alcuni servizi AI offrono opzioni specifiche relative alla localizzazione dell'elaborazione, alla conservazione dei dati, all'isolamento dell'infrastruttura o al controllo operativo.
Le caratteristiche effettive cambiano da provider a provider e vengono quindi verificate sul servizio concreto, evitando di utilizzare l'etichetta “sovrano” come garanzia generica.
Self-hosting e infrastruttura dedicata
Applicazioni, servizi o modelli possono essere eseguiti su infrastrutture dedicate o controllate più direttamente.
Questo può aumentare il controllo sull'ambiente di esecuzione e ridurre alcune dipendenze esterne, ma trasferisce anche maggiori responsabilità operative a chi gestisce l'infrastruttura.
On-premise e ambienti isolati
Per esigenze particolarmente restrittive, e quando tecnicamente compatibile con il progetto, alcune componenti possono essere installate direttamente sull'infrastruttura dell'organizzazione.
È inoltre possibile progettare ambienti con comunicazioni esterne fortemente limitate o, in casi specifici, assenti.
Maggiore isolamento non significa automaticamente maggiore sicurezza.
Patch, monitoraggio, backup, continuità operativa, controllo degli accessi e competenze del team rimangono necessari indipendentemente dal luogo in cui gira il sistema.
Non esiste una classifica universale
Cloud pubblico, cloud regionale, infrastruttura dedicata, self-hosting e on-premise sono strumenti diversi.
Più isolamento può significare maggiore controllo, ma anche più manutenzione, maggiore complessità operativa e maggiori responsabilità.
I servizi gestiti possono invece offrire vantaggi significativi in termini di aggiornamenti, resilienza, scalabilità e gestione operativa.
Per questo non scegliamo un'architettura perché appare più sofisticata o più rassicurante sulla carta.
Valutiamo dati, processo, requisiti, dipendenze e rischio. Poi progettiamo il livello di controllo realmente necessario.
Un uso responsabile dell'intelligenza artificiale
La sicurezza di un sistema AI non dipende soltanto da dove viene eseguito il modello o da quali informazioni può elaborare. Dipende anche da ciò che il modello è autorizzato a fare.
Per questo l'AI viene inserita all'interno di un sistema composto da permessi, regole applicative, validazioni e controlli.
Non tutte le azioni devono avere lo stesso livello di autonomia.
Analizzare un documento, classificare informazioni o preparare una bozza e-mail può avere conseguenze molto diverse rispetto a modificare dati importanti, inviare una comunicazione, approvare una pratica o eseguire un'azione difficile da annullare.
Nei passaggi più rilevanti o irreversibili possiamo quindi introdurre verifiche aggiuntive, limiti operativi o una conferma umana prima dell'esecuzione.
Nei processi più delicati progettiamo inoltre il sistema affinché possa gestire informazioni mancanti, risultati incerti, errori ed eccezioni senza essere costretto a produrre una risposta o completare un'azione a ogni costo.
L'autonomia viene calibrata sul rischio del processo.
Utilizzare l'AI in modo responsabile significa quindi definirne il perimetro: quali informazioni può elaborare, quali strumenti può utilizzare, quali azioni può eseguire autonomamente e quali devono invece essere validate.
Il modello è un componente dell'architettura. Il controllo rimane nel sistema che gli costruiamo intorno.
Test, review e controlli prima del rilascio
Prima che una soluzione venga utilizzata realmente, verifichiamo le parti più importanti del sistema.
I controlli variano in base al progetto e possono comprendere test automatici, verifica delle integrazioni, validazione degli input, gestione degli errori, controllo dei permessi, configurazioni dell'ambiente e revisione del codice.
Per i sistemi più complessi possiamo affiancare al lavoro interno anche revisioni tecniche indipendenti.
L'obiettivo non è soltanto verificare che una funzionalità operi nelle condizioni previste, ma controllare anche come si comporta quando qualcosa non va come dovrebbe: input inattesi, integrazioni non disponibili, permessi insufficienti, dati incompleti o condizioni non previste.
Un sistema affidabile non deve soltanto saper funzionare. Deve anche saper fallire in modo controllato.
Logging, monitoraggio e backup
Quando il progetto lo richiede, implementiamo logging e monitoraggio per individuare errori, anomalie e comportamenti inattesi, cercando allo stesso tempo di non raccogliere informazioni non necessarie.
Per i sistemi che conservano dati importanti definiamo inoltre strategie di backup coerenti con l'infrastruttura utilizzata e con la criticità delle informazioni gestite.
La presenza di uno storage ridondato, di un NAS o di una replica non viene considerata automaticamente equivalente a una strategia di backup e ripristino. Il progetto deve tenere conto anche di cosa deve essere recuperabile e delle modalità di ripristino coerenti con la criticità del sistema.
Nei software custom più complessi, però, il lavoro non termina necessariamente con il rilascio.
Test e verifiche permettono di controllare il sistema prima della pubblicazione, ma alcuni aspetti emergono soltanto quando il software entra nel lavoro quotidiano: casi limite, eccezioni operative, comportamenti inattesi o passaggi che possono essere ulteriormente affinati.
Per questo, in base alla complessità del progetto, possiamo definire un periodo di monitoraggio e stabilizzazione in uso reale.
Osserviamo il comportamento del sistema, analizziamo ciò che emerge e raccogliamo il riscontro delle persone che lo utilizzano sul campo. Questo permette di intervenire sui punti che richiedono correzioni o affinamenti e di adattare ulteriormente la soluzione al processo reale per cui è stata costruita.
Prima, durante e dopo il rilascio
Prima dello sviluppo
Analizziamo il sistema, i dati coinvolti, le integrazioni e i punti che richiedono maggiore attenzione. Definiamo fin dall'inizio misure adeguate alla complessità e al rischio del progetto.
Durante lo sviluppo
Lavoriamo con repository privati, accessi controllati, credenziali separate dal codice e ambienti distinti quando necessari. Test e verifiche accompagnano progressivamente lo sviluppo.
Prima del rilascio
Controlliamo le parti critiche del sistema, le configurazioni dell'ambiente di produzione e il comportamento delle principali integrazioni prima dell'utilizzo reale.
Dopo il rilascio
Per i software più complessi possiamo prevedere un periodo di osservazione proporzionato al progetto. È il momento in cui il sistema incontra utenti, volumi, eccezioni e dinamiche del lavoro quotidiano che non sempre possono essere riprodotte completamente durante i test.
Monitoriamo ciò che accade, analizziamo eventuali anomalie e raccogliamo il feedback di chi utilizza concretamente la soluzione, intervenendo sui punti che emergono dall'uso reale.
Quando è previsto un servizio di manutenzione, il lavoro può proseguire nel tempo attraverso monitoraggio, aggiornamenti e interventi sulle nuove esigenze.
Cosa succede ai dati alla fine del progetto
Anche la conclusione di un progetto fa parte della gestione dei dati.
Quando una collaborazione termina o un sistema viene dismesso, definiamo in base all'architettura, ai servizi utilizzati e agli accordi del progetto cosa debba essere consegnato, mantenuto o rimosso.
Quando previsto, i dati possono essere esportati in un formato utilizzabile dal cliente e le copie operative sotto il nostro controllo possono essere eliminate una volta concluse le attività per cui erano necessarie.
Anche accessi, account tecnici, credenziali e autorizzazioni vengono considerati nella fase di chiusura, per evitare che rimangano attivi senza una reale necessità operativa.
La cancellazione, tuttavia, non significa necessariamente che ogni copia scompaia nello stesso istante. Alcune infrastrutture possono mantenere temporaneamente informazioni all'interno di backup automatici o sistemi di disaster recovery fino alla normale rotazione prevista dal servizio.
Per questo tempi e modalità effettive di eliminazione dipendono anche dall'architettura e dai provider coinvolti e vengono considerati in fase di progettazione quando rappresentano un requisito rilevante.
L'obiettivo è mantenere il controllo sui dati anche quando il sistema smette di essere utilizzato.
La sicurezza è un processo continuo
Nessun software può essere considerato immune da vulnerabilità.
Tecnologie, dipendenze, infrastrutture e modalità di attacco evolvono nel tempo.
Può cambiare anche il contesto in cui il software opera. Volumi, integrazioni, organizzazione dei team e requisiti possono rendere opportuno rivalutare scelte architetturali che erano adeguate in una fase precedente del progetto.
Anche un sistema progettato con attenzione può richiedere aggiornamenti, verifiche e interventi successivi.
Per questo preferiamo parlare di metodo, controlli e responsabilità invece di fare promesse assolute.
Il nostro lavoro consiste nel ridurre i rischi evitabili, limitare gli accessi, proteggere le informazioni e costruire sistemi che possano essere controllati, verificati e mantenuti nel tempo.
Meno dati inutili. Meno accessi superflui. Più controllo su ciò che conta.
È questo il principio con cui affrontiamo la sicurezza in ogni progetto.