Qualsiasi soluzione che non includa la crittografia sul lato client con le chiavi detenute dal proprietario non soddisferà il primo requisito dichiarato (protezione / sicurezza IP) - qualsiasi hack del lato server rivela dati non crittografati. Questo esclude i sistemi di sincronizzazione cloud come Dropbox che possiedono le chiavi.
Per evitare di ospitare le chiavi di crittografia importantissime sul server del sito Web, che a un certo punto è probabile che venga hackerato, ecco cosa farei:
- Server di backup interno sul sito del cliente: dispone di chiavi di crittografia e chiavi SSH per entrambi gli altri server
- Server che ospita il sito Web - potrebbe essere un host web
- Server o servizio di backup cloud
Passaggio 1: Server (1) estrae il backup da (2), quindi la maggior parte degli hack del server del sito Web non comprometterà i backup. La crittografia avviene a questo punto.
- Vorrei utilizzare rsnapshot su SSH utilizzando l'accesso basato su chiave, poiché questo ha requisiti minimi sull'host web e sul server di backup interno - a meno che non si disponga di un DB di grandi dimensioni per il backup, è molto efficiente nella larghezza di banda e memorizza più versioni del sito, e gestisce anche l'eliminazione di vecchi backup.
- La crittografia può essere eseguita da qualsiasi strumento da file a file come GPG, copiando l'albero rsnapshot in un altro albero - oppure è possibile utilizzare la duplicità per il passaggio 2, risparmiando spazio su disco.
- "Estrarre" dal server di backup è importante: se il server principale (2) dispone delle password / chiavi per il server di backup, gli hacker possono e talvolta eliminano i backup dopo aver violato il server principale (vedere di seguito). Gli hack davvero avanzati possono installare binari SSH trojan che potrebbero quindi compromettere il server di backup, ma è meno probabile per la maggior parte delle aziende.
Passaggio 2: il server (1) invia i backup crittografati a (3) in modo che sia presente un backup fuori sede. Se i backup sono stati crittografati nel passaggio 1, è possibile utilizzare semplicemente un mirror rsync dell'albero rsnapshot locale sul sistema remoto.
- Duplicity sarebbe una buona opzione per crittografare e eseguire il backup diretto dell'albero rsnapshot non crittografato sul server remoto. Le funzionalità di Duplicity sono un po 'diverse da rsnapshot, usando archivi tar crittografati con GPG, ma fornisce la crittografia di backup sull'host remoto e richiede solo SSH su quell'host (oppure può usare Amazon S3). Duplicity non supporta i collegamenti reali , quindi se è necessario (ad esempio per un backup completo del server), è meglio se uno script converte l'albero rsnapshot (che supporta i collegamenti fissi) in un file tar (forse solo i file che hanno> 1 hard link, che sarà piuttosto piccolo) in modo che la duplicità possa eseguire il backup del file tar.
- Poiché il server remoto è solo un host SSH, possibilmente con rsync, potrebbe essere un host web (ma di un diverso provider di hosting e in una diversa parte del paese) o un servizio cloud che fornisce rsync e / o SSH - vedi questa risposta sui backup rsync su cloud per la sua raccomandazione di bqbackup e rsync.net, sebbene non sia d'accordo con la configurazione di backup menzionata.
- Puoi utilizzare Amazon S3 come server remoto con duplicità, il che ti darebbe una disponibilità davvero buona anche se forse costerebbe di più per backup di grandi dimensioni.
- Altre opzioni per i backup crittografati remoti sono Boxbackup (non abbastanza maturo, alcune belle funzioni) e Tarsnap (servizio cloud commerciale basato su Amazon S3 con semplice interfaccia a riga di comando, buona deduplicazione e crittografia molto approfondita).
La sicurezza di tutti i vari host è importante, quindi dovrebbe essere regolata per soddisfare il profilo di sicurezza del client, ovvero analizzare le minacce, i rischi, i vettori di attacco, ecc. Ubuntu Server non è un brutto inizio in quanto ha frequenti aggiornamenti di sicurezza per 5 anni, ma è richiesta attenzione alla sicurezza su tutti i server.
Questa configurazione fornisce 2 backup indipendenti, uno dei quali può essere un servizio di archiviazione cloud ad alta disponibilità, funziona in modalità pull in modo che la maggior parte degli attacchi sul sito Web non possa distruggere i backup contemporaneamente e utilizza strumenti open source ben collaudati che non richiede molta amministrazione.
- I backup indipendenti sono fondamentali, perché gli hacker a volte eliminano tutti i backup contemporaneamente alla pirateria informatica del sito Web; nel caso più recente gli hacker hanno distrutto 4800 siti Web, inclusi i backup hackerando l'ambiente di hosting Web anziché i siti. Vedi anche questa risposta e questa .
- Il ripristino è molto semplice con rsnapshot: in ogni albero di snapshot è presente un file per ogni file di cui è stato eseguito il backup, quindi è sufficiente trovare i file con gli strumenti Linux e rsync o eseguirne lo script sul sito Web. Se il server di backup in loco non è disponibile per qualche motivo, utilizzare la duplicità per ripristinarli dal server di backup cloud oppure è possibile utilizzare strumenti standard come GPG, rdiff e tar per ripristinare i backup.
Poiché questa configurazione utilizza SSH e rsync standard, dovrebbe essere più semplice scegliere un fornitore adatto con le giuste garanzie di uptime, sicurezza elevata, ecc. Non è necessario bloccare un contratto lungo e se il servizio di backup ha un effetto catastrofico errore, hai ancora un backup locale e puoi passare a un altro servizio di backup abbastanza facilmente.