Ho una situazione pratica qui, la mia azienda è un FTP provider di server per alcuni clienti. I clienti condividono i propri file sul nostro server FTP e finora non hanno avuto problemi con la gestione degli accessi e le politiche sulla privacy.

Di recente, i nostri clienti desiderano crittografare i propri file per un motivo: “ Non vogliono che lamministratore del server FTP abbia accesso ai loro file “.

Inoltre, la nostra azienda vuole migliorare il nostro metodo di autenticazione FTP con la firma digitale.So che possiamo implementare la crittografia PGP per linvio di file al server FTP, ma il problema è che quando i file crittografati ricevono, verranno decrittografati dal server con la sua chiave privata e quindi lamministratore ha pieno accesso a quei file.

Con limplementazione dellinfrastruttura a chiave pubblica, ogni client deve avere una smart card per accedere al server FTP con firma digitale. Ma non lo è possibile per i nostri clienti crittografare i propri file in base alla chiave pubblica del destinatario. Perché potrebbe esserci una situazione in cui ci sono diversi destinatari di file e si dovrebbe crittografare un singolo file utilizzando dozzine di chiavi pubbliche che impiegano uneternità!

Quindi, la mia domanda è: “ Esiste una soluzione per crittografare i file sul server FTP che può essere implementata in questa situazione? ” Qualsiasi aiuto sarebbe molto apprezzato.

Commenti

  • Non è la risposta alla tua domanda, ma non dovresti usare affatto FTP perché la password FTP viene trasmessa in chiaro. Come dice theterribletrivium in una risposta, utilizzare un protocollo di trasferimento crittografato. Sarebbe qualcosa come SCP, FTPS o SFTP.
  • BobBrown e Steffan Ullrich sono entrambi morti di testa. Steffen risponde alla tua vera domanda, ma Bob fa un buon punto. Cioè, i client devono essere responsabili della crittografia. Archiviatori come 7-zip rendono banale creare archivi crittografati, compressi o meno. Questo potrebbe anche essere scritto tramite Python o forse PHP come parte della routine di caricamento del client ‘. Per quanto riguarda il punto ‘ di BobBrown – se i tuoi clienti lo considerano sensibile, non dovrebbero certamente usare FTP. Unalternativa crittografata è una precisa necessità in questa situazione.
  • @BobBrown Sì, come ho detto, stiamo sviluppando funzionalità abilitate per PK per il nostro servizio di accesso. Quindi, non cè trasmissione di password, abbiamo una firma digitale per lautenticazione.
  • I tuoi clienti dovrebbero effettivamente crittografarla da soli, e usando ad esempio SSH invece di FTP anche ‘ una cattiva idea. Tuttavia, potresti dare unocchiata al concetto di servizi a conoscenza zero: en.wikipedia.org/wiki/Zero_knowledge
  • Se capisco correttamente la domanda A23149577 ‘, la domanda è: esiste un software server FTP (sia FTPS che SFTP) in grado di crittografare il flusso di dati in entrata su disco e decrittografarlo il flusso di dati in uscita dal disco allutente in modo che gli utenti locali del sistema che esegue il software del server FTP non abbiano accesso ai dati del cliente ‘ sul disco. Questa è una domanda legittima a cui non si risponde attribuendo la responsabilità della crittografia dei dati al cliente o riprogettando il flusso di lavoro di A23149577 ‘. I vantaggi di una risposta positiva a questa domanda sono la facilitazione dellautomazione della gestione

Answer

Recentemente, i nostri clienti vogliono crittografare i loro file per un motivo: “Non vogliono” che lamministratore del server FTP abbia accesso ai loro file “.

Con questo requisito la crittografia non dovrebbe essere eseguita sul lato server . Altrimenti un amministratore potrebbe semplicemente prendere il contenuto prima che venga crittografato. E ovviamente anche la gestione delle password / chiavi dovrebbe essere accessibile solo al client.

Questo lascia solo la crittografia sul lato client. Ci sono diverse soluzioni per questo, come archivi protetti da password ecc. Oppure, si potrebbe usare PGP e aiutare i client impostando un server di chiavi PGP privato per rendere più facile lo scambio di chiavi pubbliche. Le chiavi stesse dovrebbero ovviamente essere generate dal client stesso e la chiave privata dovrebbe essere conservata inlato client.

Commenti

  • Grazie per la risposta, sono consapevole che la crittografia dovrebbe essere eseguita sul lato client e la compressione protetta da password è il situazione più semplice qui. Volevo trovare soluzioni più automatiche che non usassero la crittografia simmetrica e lo scambio di chiavi via e-mail, ad esempio.
  • I client possono anche utilizzare la crittografia asimmetrica collaudata come PGP. In questo caso hanno solo bisogno di ottenere la chiave pubblica dal peer per condividere un file.Per facilitare la condivisione delle chiavi pubbliche potresti configurare un server delle chiavi, ma la generazione e la pubblicazione delle chiavi sul server deve essere eseguita nuovamente dal client per mantenere la chiave privata sicura.
  • Credo che questa soluzione sia la migliore, perché in questo modello non siamo più preoccupati per lo scambio di chiavi simmetriche tra i client. Grazie per la tua risposta
  • ‘ ho aggiunto lidea alla risposta.

Risposta

Il mio suggerimento è che i tuoi clienti gestiscano le proprie password di crittografia o certificati. Alcuni client FTP consentono luso della crittografia, ad esempio: http://www.coreftp.com/docs/web1/FTP_Encryption.htm . Voglio assicurarmi però che tu stia effettivamente utilizzando un qualche tipo di crittografia per il transito dei loro dati. Non ne parli e poiché vanilla FTP non usa la crittografia per impostazione predefinita, voglio essere sicuro che anche quella parte sia coperta .

Commenti

  • In realtà il nostro attuale server FTP utilizza una connessione SSH ed è ‘ quasi sicuro, ma, come ho già detto, stiamo passando allautenticazione tramite firma digitale e infrastruttura a chiave pubblica che ci aiuta a rendere più sicuro il nostro sistema di accesso. Forse dobbiamo implementare una sorta di SFTP personalizzato per la nostra situazione.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *