Sicurezza e dati
Due domande, con risposta prima che le facciate
Ogni azienda che valuta una piattaforma gestionale ha le stesse due preoccupazioni, e raramente sono quelle di cui parla il materiale commerciale: dove risiedono fisicamente i miei dati, e cosa succede il giorno in cui qualcosa va davvero male.
Dove stanno i vostri dati lo decidete voi
Un'installazione GTSuite è la stessa installazione ovunque giri.
- Sul vostro server, nella vostra sede o in un centro dati che già utilizzate, senza che nulla esca dalla vostra rete.
- Sul nostro servizio ospitato, se preferite non gestire affatto server e database.
- Spostata in seguito, in entrambe le direzioni, perché il software è lo stesso in un caso e nell'altro.
Entrambe le forme sono in uso oggi. Vale la pena chiarirlo subito, perché il luogo di residenza dei dati è spesso un obbligo di conformità o una clausola in un contratto con i vostri stessi clienti, e non dovrebbe essere dettato dal software che avete scelto.
I vostri dati aziendali vivono in un database relazionale standard con tabelle leggibili. I vostri strumenti li raggiungono, la vostra politica di salvataggio li copre, le vostre persone possono verificarli.
Chi vede cosa, fino al singolo bottone
Nella maggior parte dei gestionali il controllo degli accessi si ferma alla schermata: o l'utente ha la pagina o non ce l'ha. Le aziende vere hanno bisogno di distinzioni più fini. Due persone possono aver bisogno dello stesso elenco ordini davanti, mentre solo una delle due dovrebbe poter annullare un ordine, e all'altra metà delle colonne non serve.
In GTSuite i permessi fanno parte delle definizioni dell'applicazione, come tutto il resto. Si creano tutti i ruoli che l'organizzazione ha davvero, e a ciascuno si concedono le voci di menu che gli servono. Poi, dove la schermata intera è una misura troppo grossolana, si prende un singolo elemento, lo si dichiara oggetto controllato e lo si concede ai ruoli ammessi. Tre tipi di elemento si possono governare così:
- Un bottone o un comando, così la stessa pagina è di sola lettura per un ruolo e operativa per un altro.
- Una singola colonna di una tabella, così un elenco condiviso da più ruoli non deve mettere ogni cifra davanti a tutti.
- Una stampa, concessa ai ruoli che devono poterla eseguire.
Tutti e tre sono attivi in sistemi che girano oggi, e nessuno di essi ha richiesto una riga di codice: si censisce un oggetto come controllato e si concedono i ruoli.
Una distinzione che vale la pena fare: concedere oggetti adatta una schermata a un ruolo. Quando un'informazione non deve davvero arrivare a qualcuno, lo strumento giusto è il dato stesso, cioè dare a quel ruolo una pagina la cui interrogazione quel valore non lo restituisce affatto. Le due cose vengono spesso confuse in documenti come questo, e non sono la stessa cosa.
In ogni progetto esistono sempre due ruoli. Uno è l'amministratore, che per impostazione vede tutto. L'altro appartiene a chi costruisce l'applicazione, ed è quello che custodisce il lavoro in corso: una pagina concessa a quel ruolo è visibile a chi la sta sviluppando e a nessun altro.
Perché conta più di quanto sembri: significa che una pagina nuova si può costruire e collaudare sull'installazione viva, con i dati veri, mentre i vostri utenti continuano a lavorare senza mai vederla. Diventa loro il giorno in cui la concedete. Non serve un sistema di collaudo separato da tenere allineato, e non serve una serata di rilascio.
Salvataggi pensati per il giorno brutto
Quasi tutti i sistemi di salvataggio sono pensati contro il guasto dell'hardware. Quello è il caso facile. Il caso difficile è un attaccante che ottiene il controllo amministrativo di un server, perché la prima cosa che fa il ransomware moderno è distruggere i salvataggi prima di cifrare qualsiasi cosa.
GTSuite comprende un meccanismo di salvataggio cifrato fuori sede pensato esattamente contro questo. Si regge su un principio:
Il sistema che produce i salvataggi non è l'autorità che li custodisce.
In pratica, ogni notte i database vengono estratti, raccolti e cifrati, poi spediti a una seconda macchina in un altro luogo. La custodia di quello che arriva è affidata al sistema operativo della macchina ricevente, completamente al di fuori dell'applicazione. Un attaccante che prendesse il controllo del server mittente, applicazione compresa, non potrebbe comunque tornare indietro e distruggere lo storico che è già là.
Come regge
| Cosa potrebbe succedere | Cosa lo impedisce |
|---|---|
| Qualcuno ruba o copia gli archivi | Sono cifrati con una chiave pubblica. La chiave privata che potrebbe aprirli è tenuta fuori linea e non è mai stata su nessun server. |
| Un server viene compromesso del tutto e l'attaccante ne legge i salvataggi | Quel server sa cifrare ma non decifrare. Custodisce testo cifrato che non può aprire, compreso il proprio. |
| L'attaccante usa le credenziali di trasferimento per raggiungere l'altra macchina | Quelle credenziali appartengono a un'utenza dedicata senza accesso interattivo, confinata in un'unica cartella di ricezione e limitata per indirizzo di provenienza. Non c'è nessun comando da eseguire e nessun posto dove andare. |
| Un ransomware cancella le copie fuori sede | La cartella di ricezione accetta file nuovi ma rifiuta cancellazioni e rinomine, e ogni archivio è protetto singolarmente. A imporlo è il sistema operativo, non l'applicazione. |
| L'applicazione stessa viene manomessa e disattiva la propria protezione | Non può. Non ha mai avuto il privilegio necessario per modificare quegli attributi. |
Sono previste due configurazioni: unidirezionale, con spedizione verso una macchina di solo deposito che non deve nemmeno avere GTSuite, oppure reciproca, in cui due installazioni fanno da cassaforte l'una all'altra.
Detto chiaramente, come una pagina sulla sicurezza deve fare: questo protegge la copia a riposo altrove. Non nasconde i dati a un attaccante che controlla un server acceso, perché a quel punto i dati vivi sono già esposti e i salvataggi non aggiungono nulla. Chiunque sostenga il contrario vi sta vendendo qualcosa.
Un salvataggio mai ripristinato non è un salvataggio
La procedura di ripristino è documentata, la chiave privata è custodita in più di un luogo sotto la responsabilità del titolare, e un ripristino vero su un database di scorta va esercitato con regolarità invece che scoperto sotto pressione. Preferiamo dirvelo adesso piuttosto che farvi scoprire dopo che nessuno ci aveva mai provato.
Il quadro completo
La descrizione tecnica completa del meccanismo di salvataggio, compresi il modello delle minacce e la procedura operativa, fa parte della documentazione che si ottiene con un account. Confermate un indirizzo email e potrete leggerla, insieme a un sistema vero da usare e agli esercizi che mostrano come si costruiscono le applicazioni.