Trasferimento sicuro dei dati dal fornitore di servizi al client

Dal punto di vista della sicurezza, le tue opzioni NON sono equivalenti. Se questo è importante o meno dipende dal contesto.

I primi due metodi sono, approssimativamente, equivalenti in termini di sicurezza: in entrambi i casi si utilizza la crittografia dei dati in transito e si basa sulla complessità della password di accesso per proteggere i dati. La sfida per la sicurezza che stai per ottenere è più o meno la seguente: protezione dagli attacchi MitM e password cracking. In entrambi i casi, dovrai configurarlo attentamente e correttamente per prevenire MitM e in entrambi i casi avrai bisogno di un canale sicuro separato per lo scambio di chiavi (nel tuo caso, la password).

Potresti renderlo più strong usando coppie di chiavi pubbliche / private per l'autenticazione. Un altro problema è che, poiché i dati non sono crittografati sul server (a riposo), qualsiasi difetto nel software o nella configurazione del server potrebbe consentire l'accesso ai dati a un utente malintenzionato.

Il terzo metodo è diverso. Sebbene tu abbia ancora bisogno di un canale sicuro separato per scambiare le password, non stai facendo affidamento sulla riservatezza della connessione di crittografia. Ciò significa che l'intera configurazione è più resiliente poiché la rottura di un livello di protezione (ad esempio, il tuo server di posta) non concederà a un utente malintenzionato l'accesso ai dati.

Detto questo, potresti migliorare molto il progetto. Ad esempio, l'utilizzo di un server SFTP per ospitare un file PGP crittografato renderà tutto più sicuro e più pratico. Se sei disposto a fidarti delle tue chiavi su qualche macchina nella tua rete interna, l'intera operazione può essere automatizzata.

Per quanto riguarda i file temporanei, solo se sono veramente validi nel tuo caso d'uso, allora il tuo requisito è abbastanza severo da non provare a implementarlo tu stesso ma assumere un professionista. In generale, i file temporanei sono sicuri quanto gli altri file sulla tua macchina: se la tua macchina è abbastanza sicura, lo sono anche i tuoi file. E se hai un file temporaneo, non crittografato, caricato su un server da qualche parte, quel file sarà sicuro quanto la copia "reale" che intendi lasciare lì (cioè non molto).

Come sapresti già che non esiste una sicurezza assoluta, ma il mio approccio sarebbe così:

1. Cifra i dati usando una password complessa (TrueCrypt AES-256 et. al.)
2. SCP di SFTP i dati nella nuova posizione.
3. Decifra e verifica i dati nella nuova posizione.
4. Proteggi elimina i dati nella vecchia posizione.

La creazione di file temporanei non riduce la sicurezza, ma l'opzione B ha un vettore di attacco aggiuntivo nell'applicazione web stessa e utilizzerei OpenSSH su qualsiasi altra applicazione Web ogni giorno.

Opzione A: C deve essere in grado di accedere a SSH su rete Ps (dovrebbe essere fornito ip statico su entrambi i lati per creare le necessarie regole del firewall), e C dovrebbe usare SSH-Keys, quindi questa sarebbe un'opzione. P può restringere / chroot C accessi a sftp e una certa directory.

Opzione B: Basic / Digest-Auth + SSL per accedere a questo file dovrebbe andare bene, ma il login / password-transfer non dovrebbe essere fatto via internet. Inoltre P si rilascia un client-cert protetto da password a C per l'autenticazione. se C è dietro un IP statico, usa un firewall per proteggere quel servizio.

Opzione C: solo se A / B non è un'opzione. in questo caso puoi anche criptare e caricare su rapidshare et al:)

comunque, il file dovrebbe essere cancellato dopo il trasferimento riuscito.

which of these transfer methods is preferable and why:

quello che è più facile da configurare e mantenere.

il trasferimento sicuro dovrebbe essere fornito in tutti e 3 i casi, ma se P ha implementato l'accesso SSH con VPN e non desidera fornire l'accesso C VPN, allora HTTPS potrebbe essere una soluzione migliore.

se ti interessa la creazione di file temporanei o attacchi in memoria puoi chiedere a P di configurare un server dedicato per il trasferimento dei file.

Oppure, come suggerito da Fahad Yussuf, crittografare i dati prima di posizionarli su un server con connessione Internet; ciò impedirebbe qualsiasi problema con i file temporanei ed è una buona soluzione. la crittografia può essere programmata, ma la decrittografia richiede un essere umano coinvolto, tranne quando si esegue una sorta di demone sul ricevitore che funziona con gpg / gpg-agent, ma questo sarebbe un po 'troppo trascurato?