Database server aziendale:
chi ha le chiavi dei tuoi dati?

Il problema: tutti hanno accesso, nessuno ha la governance

Il database server è il caveau dell'azienda: contiene fatture, anagrafiche clienti, dati dei dipendenti, contabilità. Eppure, nella maggior parte delle PMI italiane, è il sistema meno controllato.

Il meccanismo è sempre lo stesso. La software house del gestionale chiede la password di amministratore — «altrimenti non funziona». L'azienda acconsente perché non ha le competenze per valutare se è vero. Poi arriva la software house delle paghe, quella del CRM, il consulente chiamato per un'emergenza. Ognuno installa i propri strumenti, crea i propri backup, schedula i propri job. Nessuno documenta. Nessuno coordina.

Il risultato è un server amministrato di fatto da 3-5 soggetti diversi, ognuno con privilegi di amministratore, senza che nessuno abbia il quadro completo.

Perché «ci serve sa» è quasi sempre falso

Un gestionale ben progettato ha bisogno di permessi specifici sul proprio database: un db_owner sul suo DB e, al massimo, qualche permesso puntuale come BACKUP DATABASE o VIEW SERVER STATE.

Non ha mai bisogno di sysadmina livello di istanza. Chi lo chiede lo fa per pigrizia di sviluppo, perché non sa quali permessi servono effettivamente, o perché vuole poter fare troubleshooting diretto in produzione. Nessuna di queste è una ragione accettabile dal punto di vista della sicurezza.

I rischi concreti per l'azienda

Quando più fornitori hanno accesso sysadmin allo stesso server, le conseguenze sono gravi:

• Ogni fornitore vede i dati di tutti gli altri— la software house del gestionale può leggere i dati delle paghe, e viceversa. Nessuna segregazione.
• Nessun audit trail affidabile — se tutti usano lo stesso account sa, non sapete chi ha fatto cosa. In caso di incidente, è impossibile ricostruire la catena degli eventi.
• Credenziali sparse ovunque— password in file di configurazione, in chiaro o con cifratura debole, su macchine di tecnici esterni che non controllate.
• Strumenti di backup sovrapposti— ogni fornitore lascia il suo: Maintenance Plans, script di terze parti, agent proprietari. Alla fine nessuno sa quale backup è valido in caso di disastro.
• Superficie di attacco espansa— ogni tool installato è codice che gira con privilegi elevati. Ogni tool non aggiornato è una vulnerabilità. Ogni tool abbandonato è una vulnerabilità che nessuno corregge.

La responsabilità è della direzione, non della software house

Questo è il punto che molti titolari non vedono. Il GDPR è chiarissimo: il titolare del trattamento è l'azienda. La software house è un responsabile esterno del trattamento che agisce sotto le istruzioni dell'azienda. Se le istruzioni non esistono e ognuno fa come vuole, in caso di ispezione del Garante o di data breach la responsabilità è dell'azienda.

La software house, nel proprio contratto, ha scritto che «il cliente è responsabile dell'infrastruttura». L'azienda pensava che «ci pensa la software house». Nessuno ci pensava.

Con la Direttiva NIS2 si aggiunge l'obbligo di gestione del rischio nella catena di fornitura: sapere e controllare cosa fanno i fornitori sui sistemi aziendali non è più una best practice, è un obbligo di legge per i soggetti rientranti nel perimetro.

La soluzione: un referente unico con delega della direzione

Il primo passo non è tecnico, è organizzativo. La direzione deve nominare un referente unico per l'infrastruttura database — interno o esterno — e comunicare a tutti i fornitori che ogni intervento sul server passa da quel referente.

• 1Audit degli accessi— mappare chi ha accesso al server, con quali privilegi e per quale motivo. Spesso si scoprono account dimenticati, service account con password che non scadono mai, strumenti abbandonati ancora attivi.
• 2Principio del minimo privilegio — sostituire gli account sysadmin con permessi granulari. Ogni applicativo accede solo al proprio database, con i permessi strettamente necessari.
• 3Un sistema di backup unico e documentato— eliminare gli strumenti sovrapposti, implementare una strategia di backup e disaster recovery con retention chiare, test di ripristino periodici e documentazione.
• 4Governance dei fornitori— ogni software house che interviene sul server opera sotto la supervisione del referente, con credenziali dedicate, tracciate e revocabili.

Un partner certificato per riprendere il controllo

AtWorkStudio opera da Piacenza dal 2000. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, con qualificazione ACN per i servizi cloud. Siamo membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.

Ci poniamo come intermediari tra l'azienda e le software house: gestiamo il database server, assegniamo i permessi corretti, implementiamo un sistema di backup unico e documentato, e garantiamo che ogni intervento sia tracciato e conforme. La direzione ha un unico referente che risponde della sicurezza dei dati.