Protezione dei dati e dei file in modo che non possano essere aperti da nessun'altra parte tranne il proprio server?

Perché credi che dovrebbe esserci un modo? Se un utente malintenzionato può hackerare il tuo server, può presumibilmente guardare i dati su quel server - da quel momento, potrebbero copiare i dati in chiaro in qualsiasi altro posto. Sappiamo che i dati devono essere chiari a quel punto, dal momento che il tuo server deve essere in grado di leggerlo, e devi essere in grado di accedere ai file (altrimenti è un po 'un buco nero). Potresti crittografare i file in modo tale che solo il tuo server specifico possa decrittografarli - potresti anche usare un modulo di sicurezza hardware per rendere l'esportazione delle chiavi più difficile - ma dato che devono essere decodificati per l'uso, un utente malintenzionato potrebbe semplicemente prendere una copia a quel punto.

Pensa che sia come un dipinto - puoi proteggere il dipinto in modo relativamente semplice, chiudendolo in una cassastrong, ma non appena lo vuoi mostrare, chiunque può entrare con una macchina fotografica e fare una copia. Per i dipinti, questo è meno di un problema: puoi facilmente sapere quando è stata fatta una copia. Per i dati digitali, non c'è alcuna differenza tra l'originale e la copia, quindi qualsiasi cosa tu possa fare con l'originale, puoi fare altrettanto bene con la copia.

Questo non è possibile. Pensaci: come viene acquistato il tuo server da uno stesso server? Potrebbe avere numeri seriali diversi in alcune parti, ma a parte questo, è lo stesso.

È possibile crittografare i dati con una chiave memorizzata solo su quel server. Ma se la chiave è memorizzata sul filesystem, un utente malintenzionato può copiarla!

Esistono dispositivi hardware che memorizzano in modo sicuro una chiave e non ne consentono l'esportazione. Solitamente sono chiamati moduli di sicurezza hardware . Se si cifrano tutti i dati con le chiavi memorizzate solo nell'HSM, i file possono essere decifrati solo da qualcuno che abbia accesso a tale HSM!

Ma nota: se un utente malintenzionato ha accesso al tuo server, nulla gli impedisce di decifrare tutti i file con HSM e copiare i file decrittografati.

Inoltre, ovviamente chiunque possa accedere a un file decrittografato può quindi copiare quel file senza restrizioni.

Quindi, per riassumere quello che puoi fare è acquistare un HSM, crittografare tutti i file con quell'HSM e archiviarli solo crittografati. Per impedire a qualcuno di rubare tutti i tuoi file, è necessario implementare gli avvisi quando si verificano troppe operazioni di crittografia. (Se in uso normale, un file al secondo viene decodificato, quando improvvisamente centinaia di file vengono decifrati, qualcosa non va). Tuttavia, un utente malintenzionato può rubare i file decodificati se ha accesso illimitato al server. Rende solo più difficile!

L'approccio migliore è il contrario: fai in modo che il server che memorizza i file sia non in grado di leggerli, crittografandoli con chiavi mantenute altrove.

Considera un sistema che comprende un laptop, una smartcard e il server. I tasti sono trattenuti sulla carta. Un utente richiede il documento dal server e riceve la copia crittografata. Il portatile lo passa alla smartcard per la decodifica e quindi lo visualizza sullo schermo.

Compromettere il server è inutile: non può leggere i documenti.

Compromettere il laptop ti fa decifrare qualsiasi documento mentre è compromesso, ma non tutti i documenti.

Compromettere la smartcard ti porterà tutti i documenti con i tasti pertinenti, ma questi dispositivi possono essere estremamente resistenti agli attacchi.

Lo stato dell'arte in dispositivi sicuri per l'utente finale per l'utente ordinario è l'iPhone, con i suoi componenti "TrustZone" che funzionano come un HSM. Probabilmente il prossimo dispositivo più pratico è un sistema Win10 che utilizza la crittografia del disco completo BitLocker con un HSM che memorizza le chiavi. Devi inserire la password all'avvio ed è ancora potenzialmente vulnerabile agli attacchi in tempo reale, ma se il sistema viene rubato mentre è spento il contenuto del disco non può essere letto senza la password.

C'è una specie di problema fondamentale in cui stai provando a fare: Dovrai decrittografare i dati. A questo punto è decifrato e può essere trapelato. Puoi utilizzare la crittografia a disco intero, anche combinarla con qualcosa come QubesOS per separare i processi. Ciò impedirà al software di rubare i dati, quindi il tuo problema principale è l'accesso fisico. Ma ci sarà sempre un momento in cui i dati non sono criptati e possono essere rubati.

Ogni implementazione generale di crypto ha questa proprietà e non può essere risolta facilmente.

Per essere diversi dalle altre risposte, ti indicherò un caso in cui ciò è possibile: chiavi private.

Ciò che rende le chiavi private un caso speciale è che A) le applicazioni sul server non devono mai accedere direttamente alla chiave, un dispositivo sicuro può tenere la chiave, eseguire qualsiasi elaborazione su di essa e restituire il risultato, e B) il i dati sono abbastanza piccoli (diciamo < 1 kb) che puoi dedicare grandi quantità di tempo CPU a nasconderli in memoria.

HSM : a volte le chiavi private sono archiviate su dispositivi hardware altamente sicuri progettati per questo scopo: HSM, smart card, TPM, Secure Enclave, ecc. L'idea è che il server non vedrà mai il privato perché quando deve firmare / crittografare qualcosa invia i dati all'HSM e recupera i dati firmati / crittografati.

Obfuscation in memory : se la chiave deve essere archiviata nel software sul server, non sei interamente affondata; applicazioni ben scritte possono decodificare il file chiave e quindi nascondere la chiave in memoria in modo che anche se un utente malintenzionato ottiene un dump della memoria dell'applicazione, è difficile (ma non impossibile) estrarre la chiave. I trucchi di offuscamento includono: dividere la chiave in 4 blocchi e distribuirli nello spazio di memoria dell'app, ottenere un numero casuale o una memoria inizializzata e utilizzarla come chiave per crittografare i blocchi. Questi trucchi richiedono: A) che le tue applicazioni siano scritte con questo in mente, e B) i dati da offuscare sono molto piccoli rispetto allo spazio di memoria dell'app (diciamo < 1 kb).

Dalla tua descrizione sembra che il tuo caso d'uso non sia applicabile perché le applicazioni hanno bisogno di accedere ai dati e i dati sono abbastanza grandi. Probabilmente stai sprecando il tuo tempo qui, invece dovresti impiegare il tuo tempo a proteggere il tuo server dalle vulnerabilità di login / di esecuzione del codice da remoto.