La messa in sicurezza del server è solo il primo strato. I rischi specifici dell'ERP che fanno perdere davvero dati sono il controllo degli accessi, i privilegi del database, i log di audit e i backup non testati — ecco una checklist che funziona.
Un ERP in produzione è l'unico sistema che racchiude tutto — le tue finanze, le buste paga, il magazzino e i dati dei clienti in un solo database — quindi un fallimento della sicurezza non è un problema IT, è un problema di business. Mettere in sicurezza il server sotto di esso è necessario, ma è solo il primo strato, perché la maggior parte degli incidenti ERP reali non deriva da un server compromesso. Deriva da una persona che ha accesso a un modulo che non la riguarda, da un'applicazione che si connette al database con privilegi di amministratore, da un cambiamento che nessuno può rintracciare, o da un backup che si rivela irrecuperabile il giorno in cui serve. La checklist qui sotto copre gli strati specifici dell'ERP che la messa in sicurezza del server non raggiunge.
Un sito web compromesso può essere ripristinato da un backup e ricostruito in un giorno. Un ERP no, perché il valore sono i dati vivi accumulati — ogni fattura, ogni ciclo di buste paga, ogni movimento di magazzino — e perché chi lo usa quotidianamente non è un tecnico. Ne derivano tre conseguenze. Primo, i dati sono l'asset: la crittografia, il controllo degli accessi e i ripristini testati contano più di qualsiasi regola del firewall. Secondo, la minaccia è spesso interna: un dipendente con permessi più ampi di quelli richiesti dal suo ruolo, un collaboratore esterno mai disattivato, o un errore onesto in una schermata finanziaria che nessun log di audit sa spiegare. Terzo, il fermo si misura in ritardi di buste paga e spedizioni, non in visualizzazioni di pagina, quindi ogni controllo qui è scelto per mantenere il sistema in funzione, non solo per chiuderlo.
La maggior parte degli incidenti ERP si riduce a una frase: qualcuno aveva un accesso che non avrebbe dovuto avere. Risolvilo con ruoli basati sui veri mestieri, concedendo a ciascun ruolo solo il minimo necessario — un utente di magazzino legge le giacenze e scrive i movimenti, ma non vede mai le buste paga; un contabile vede il libro mastro ma non può modificare un periodo chiuso. Separa l'utente quotidiano dall'amministratore, richiedi l'autenticazione a due fattori per chiunque abbia privilegi amministrativi o finanziari, e controlla gli account inattivi ogni trimestre: un account senza accesso da 90 giorni va disattivato, e ogni partenza va disattivata lo stesso giorno, non a fine mese. Scrivi i ruoli, falle approvare dai responsabili di reparto e auditali rispetto alla realtà due volte l'anno — i permessi si allargano col tempo e non si restringono mai da soli.
L'applicazione ERP non deve mai connettersi al suo database come superuser o amministratore. Crea un utente del database con privilegi limitati esattamente agli schemi e alle tabelle che l'app richiede — niente eliminazione, niente gestione utenti — in modo che un difetto nell'applicazione non possa cancellare il libro mastro. Tieni ogni credenziale, chiave API e segreto del gateway di pagamento fuori dal repository di codice e fuori dalla directory di configurazione dell'ERP in chiaro: caricali dall'ambiente del server o da un gestore di segreti, e ruotali quando un dipendente con accesso se ne va. Critta il traffico tra l'applicazione e il database invece di fidarti della rete locale, e attiva la crittografia a riposo per il volume del database. Infine, tieni i dati di produzione fuori dagli ambienti di non-produzione: un server di staging con una copia dei veri record dei clienti è una fuga in attesa, quindi anonimizzali prima di copiarli ovunque.
Quando un numero è sbagliato a fine mese, la prima domanda è chi lo ha modificato e quando. Un log di audit che registra l'utente, la schermata, il record e la marca temporale — conservato dove nemmeno un amministratore può modificarlo, e mantenuto per almeno un anno — risponde a quella domanda in minuti invece che in giorni, ed è anche ciò che un regolatore chiede dopo un incidente. I backup vanno di pari passo, con una sola regola: un backup non è un backup finché non lo hai ripristinato. Esegui backup giornalieri automatici, conserva copie fuori dal server e fuori sede, attiva il recupero point-in-time per poter tornare all'ora prima di un import sbagliato, e fai un vero esercizio di ripristino ogni trimestre in un ambiente usa-e-getta. L'esercizio è l'unico test che conti, e le aziende che lo saltano sono quelle che scoprono che il backup stava fallendo silenziosamente proprio nel momento in cui serviva di più.
Non mettere l'interfaccia di amministrazione dell'ERP sull'internet pubblico. Limitala a una allowlist di IP o alla VPN aziendale, metti un web application firewall davanti, ed esponi solo ciò che personale e integrazioni servono davvero. Mantieni lo stack aggiornato a un ritmo fisso — il cuore dell'ERP, il database, il sistema operativo e ogni integrazione — e testa ogni aggiornamento in un ambiente di staging prima che tocchi la produzione, perché una patch ERP non testata può rompere un flusso di pagamento con la stessa facilità con cui chiude una falla. Poi nomina una sola persona responsabile: qualcuno che possieda la checklist, conduca l'esercizio di ripristino trimestrale, esamini le anomalie di audit e riferisca alla direzione. Il lavoro di sicurezza che è di tutti non è di nessuno, e su un ERP è così che i controlli si allentano in silenzio finché un audit — o un incidente — non li trova.
No, e confonderle è il motivo per cui restano delle lacune. La messa in sicurezza del server — chiavi SSH, firewall, aggiornamenti automatici, TLS — è la base ed è dove si inizia. Ma il rischio ERP riguarda soprattutto i dati: chi può raggiungere quali record, se la connessione al database è sovraprivilegiata, se i cambiamenti sono rintracciabili e se puoi davvero ripristinare. Un server messo in sicurezza che fa girare un ERP con ruoli aperti e un backup non testato è a un solo clic sbagliato da un problema di dati.
Un esercizio di ripristino completo almeno una volta al trimestre, in un ambiente usa-e-getta, poi un controllo che i dati ripristinati siano utilizzabili — apri il libro mastro, lancia un report, conferma che i totali combacino. I backup giornalieri automatici con copie fuori sede sono la base, e il recupero point-in-time permette di annullare un import sbagliato fino all'ora. L'esercizio trimestrale è la parte che la maggior parte dei team salta, ed è l'unica che dimostra che il resto funziona.
Il controllo degli accessi basato sui ruoli con il minimo privilegio. È l'unico controllo che restringe il raggio d'azione di ogni altro fallimento — una password trapelata, un import cliccato per sbaglio, un computer compromesso — perché l'attaccante o l'errore si scontra con un muro di permessi che non include buste paga né il libro mastro chiuso. È anche il meno costoso da correggere: basta una riunione con ogni responsabile di reparto e una revisione di ciò che ogni ruolo serve davvero.
ERP e sistemi aziendali costruiti con controllo degli accessi basato sui ruoli, log di audit e pratiche di deployment testate — prenota una sessione gratuita di analisi dei requisiti.
La guida complementare: quanto costa davvero un progetto ERP, cosa include il preventivo, e come trasformare un intervallo in un prezzo fisso.
La base a livello di server su cui si appoggia questa checklist — chiavi SSH, firewall, aggiornamenti automatici, TLS e backup giornalieri.
EGYmass si occupa di hosting, sicurezza e gestione continuativa - così tu puoi concentrarti sul tuo prodotto.
Consulenza gratuita