Guida audit infrastruttura informatica per PMI

Un gestionale che rallenta a fine mese, un e-commerce che non regge una campagna, backup mai verificati o accessi amministrativi condivisi: sono problemi che spesso emergono quando il danno è già operativo. Questa guida audit infrastruttura informatica aiuta a leggere l'ambiente IT con un criterio concreto: capire dove sono i rischi, quali dipendenze esistono e quali interventi producono un effetto misurabile.

Per una PMI, un audit non è una certificazione da archiviare. È uno strumento decisionale. Serve a stabilire se server, rete, applicazioni, account e procedure sono adeguati alla continuità del business oppure se l'azienda sta lavorando con margini di sicurezza troppo ridotti.

Cosa deve rispondere un audit infrastrutturale

Un audit utile non parte da una lista generica di vulnerabilità. Parte dalle attività che l'azienda non può permettersi di interrompere: emissione ordini, fatturazione, magazzino, vendita online, assistenza clienti, accesso remoto del personale, integrazioni con fornitori o sistemi di pagamento.

L'obiettivo è rispondere a domande precise. Quali componenti sostengono questi processi? Chi può modificarle? Dove risiedono dati e backup? Quanto tempo serve per ripristinare un servizio critico? Quali aggiornamenti sono assenti? E, soprattutto, quale sarebbe l'impatto reale di un fermo di due ore o di due giorni?

Questo approccio evita due errori frequenti. Il primo è concentrarsi solo sulla sicurezza perimetrale, ignorando applicazioni obsolete, processi manuali e configurazioni fragili. Il secondo è produrre un report tecnicamente corretto ma inutilizzabile da chi deve decidere budget, priorità e responsabilità.

Guida audit infrastruttura informatica: definire perimetro e priorità

Il perimetro va definito prima delle verifiche. In un'azienda può includere server fisici, VPS, ambienti cloud, firewall, switch, VPN, postazioni, dispositivi mobili, domini, servizi email, database e applicazioni business. Se un gestionale comunica con un e-commerce, con un CRM o con un sistema di logistica, anche queste integrazioni rientrano nell'analisi.

Non tutti gli asset hanno lo stesso peso. Un server di test esposto accidentalmente su internet può essere un rischio alto; una postazione isolata e non usata da mesi può essere un problema minore, ma va comunque gestita. La priorità dipende dalla combinazione fra esposizione, criticità del dato, probabilità di incidente e capacità di ripristino.

È utile classificare i servizi in tre categorie: essenziali per l'operatività quotidiana, rilevanti ma temporaneamente sostituibili, accessori. Questa distinzione rende più chiara la sequenza degli interventi e impedisce che attività marginali sottraggano tempo alla protezione dei sistemi che generano ricavi o gestiscono dati sensibili.

Ricostruire l'inventario reale

Molte aziende possiedono un inventario parziale: un foglio con i computer acquistati, qualche credenziale in mano al fornitore, nessuna vista aggiornata dei servizi SaaS attivi. L'audit deve ricostruire la situazione effettiva, non quella teorica.

Per ogni componente è necessario identificare funzione, proprietario, posizione, sistema operativo o versione del servizio, esposizione in rete, livello di aggiornamento e dipendenze. Un'applicazione Laravel, Node.js o Magento non è solo codice: dipende da versioni di runtime, database, job schedulati, storage, SMTP, DNS, certificati e servizi esterni. Trascurare uno di questi elementi significa avere una mappa incompleta.

L'inventario deve includere anche gli account privilegiati. Capire chi possiede l'accesso root a un VPS, chi amministra il dominio, chi controlla il tenant Microsoft 365 o Google Workspace e chi può modificare il gateway di pagamento è una verifica essenziale. Le credenziali condivise rendono difficile attribuire le attività e complicano ogni intervento di emergenza.

Verificare architettura, sicurezza e continuità

Una volta definito il perimetro, l'audit analizza come i sistemi sono configurati e mantenuti. Non basta verificare che un servizio sia raggiungibile: occorre capire se è esposto solo quando necessario, se è aggiornato e se un guasto può propagarsi ad altri componenti.

Su ambienti server, per esempio, vanno esaminati il sistema operativo, le patch, le porte aperte, le regole firewall, la configurazione di Nginx, la segregazione dei servizi Docker, i certificati TLS, i log e la rotazione degli stessi. Un container non rende sicura un'applicazione per definizione. Se i segreti sono inseriti nell'immagine, le porte sono pubblicate senza motivo o i volumi non sono gestiti correttamente, il rischio resta concreto.

La sicurezza applicativa richiede una lettura specifica. Bisogna controllare dipendenze vulnerabili, gestione delle sessioni, autorizzazioni, validazione degli input, protezione delle API, policy sulle password e uso dell'autenticazione a più fattori. In molti casi il punto debole non è il server, ma un pannello amministrativo troppo esposto o un'integrazione sviluppata anni prima senza adeguate verifiche.

Backup: esistere non basta

Il backup è uno dei punti in cui la distanza tra dichiarazioni e realtà è più evidente. Un audit serio verifica frequenza, conservazione, cifratura, separazione dall'ambiente principale e tempi di ripristino. Un backup nello stesso server che ospita l'applicazione protegge poco da ransomware, errore amministrativo o perdita dell'istanza.

La prova decisiva è il restore. Occorre ripristinare almeno un campione significativo in un ambiente controllato e misurare il risultato. Il database torna integro? Gli allegati sono disponibili? L'applicazione riparte con le corrette variabili d'ambiente? I dati ripristinati rispettano gli obiettivi di continuità concordati?

Qui entrano in gioco due parametri spesso ignorati: RPO e RTO. Il primo definisce quanta perdita di dati è accettabile, per esempio un'ora di ordini. Il secondo indica in quanto tempo un servizio deve tornare operativo. Non esistono valori corretti in assoluto: dipendono dal processo. Per un portale vetrina può essere accettabile un ripristino nel giorno lavorativo successivo; per un e-commerce attivo o un gestionale di magazzino, no.

Controllare le procedure, non solo la tecnologia

Un'infrastruttura può essere ben progettata e comunque vulnerabile se manca un processo minimo di gestione. L'audit deve verificare come vengono approvati gli accessi, come si gestiscono le uscite del personale, chi autorizza le modifiche in produzione, dove vengono registrati gli incidenti e come si pianificano gli aggiornamenti.

La documentazione non deve essere estesa per essere utile. Deve consentire a una persona competente di sapere cosa esiste, come intervenire e chi contattare. Se la conoscenza è concentrata in un unico consulente o dipendente, l'azienda ha una dipendenza operativa che merita una valutazione esplicita.

Per rendere la verifica ripetibile, le evidenze dovrebbero includere almeno questi elementi:

• inventario di asset, servizi, licenze e account amministrativi;
• diagramma delle dipendenze fra applicazioni, database e servizi esterni;
• configurazione di backup, risultato dei test di ripristino e obiettivi RPO/RTO;
• stato degli aggiornamenti e delle vulnerabilità con esposizione rilevante;
• registro degli accessi privilegiati, delle modifiche e degli incidenti principali.

Trasformare i rilievi in un piano attuabile

Il valore dell'audit si misura dopo la fase di analisi. Un elenco di cinquanta criticità senza contesto non aiuta una PMI. Serve invece una roadmap che distingua le azioni urgenti da quelle pianificabili, indichi il responsabile e riporti impatto, costo stimato, dipendenze e rischio residuo.

In genere, la priorità va a ciò che combina alta esposizione e alto impatto: account senza MFA, servizi amministrativi pubblici, backup non testati, sistemi fuori supporto, password condivise, vulnerabilità note su applicazioni esposte. Seguono gli interventi di consolidamento, come segmentazione di rete, centralizzazione dei log, revisione dei ruoli e aggiornamento delle procedure.

Non ogni criticità richiede una sostituzione completa. A volte è sufficiente correggere una configurazione, chiudere una porta, rimuovere un account inattivo o aggiornare una libreria. In altri casi, però, una piattaforma troppo datata o un'architettura cresciuta per stratificazioni richiede un progetto di evoluzione. Rimandarlo può costare meno nel trimestre corrente, ma aumenta il costo e il rischio dell'intervento futuro.

Quando ripetere l'audit

Un audit completo ha senso con cadenza annuale, ma non deve diventare l'unico momento di controllo. Va ripetuto anche dopo una migrazione, il lancio di un nuovo e-commerce, un'acquisizione, un incidente di sicurezza, l'ingresso di un nuovo provider o cambiamenti rilevanti nel modello di lavoro remoto.

Le verifiche periodiche più leggere possono concentrarsi su accessi, patch, backup, certificati in scadenza e servizi esposti. Questa disciplina è più sostenibile di un controllo straordinario svolto solo quando l'infrastruttura ha già dato segnali di cedimento.

Per aziende che vogliono un unico presidio su applicazioni, server e sicurezza, il punto non è accumulare strumenti ma mantenere responsabilità chiare. Noventra affronta gli audit partendo dalle dipendenze operative e traducendo i rilievi tecnici in interventi ordinati, verificabili e compatibili con le priorità aziendali.

Un buon audit lascia l'azienda con una mappa aggiornata, decisioni più semplici e un piano che può essere eseguito. Se il report non chiarisce cosa fare nella prossima settimana, nel prossimo trimestre e chi deve farlo, la verifica non ha ancora prodotto il suo risultato più utile.