Recuperare un file non richiede una VPN di rete completa

Una richiesta di accesso VPN spesso nasconde una cartella e un file dietro di sé. Concedere una rotta a tutta la rete dell'ufficio risponde alla richiesta e consegna molto più di quanto richieda il compito. Sostituire una condivisione montata con una pagina di caricamento può essere altrettanto sbagliato nella direzione opposta, perché cambia il modo in cui le persone lavorano. La decisione parte da cosa deve succedere al file.

Tre requisiti qui si somigliano e si comportano in modo molto diverso: copiare un PDF finito, modificare un documento sul posto ed eseguire un'applicazione su una directory condivisa.

Partite dalla modifica, non dalla cartella

Se il file è finito e serve solo leggerlo, basta un account di trasferimento. Se verrà modificato, la domanda diventa chi altro lo modifica e come si risolvono i conflitti, che è una questione di flusso di lavoro e non di rete. Se l'applicazione apre i documenti direttamente dalla directory, contano la latenza e il comportamento di blocco dello strato di archiviazione. Rispondere prima a questo evita una soluzione che si connette perfettamente e resta inutilizzabile.

La modifica condivisa introduce un problema che nessun trasferimento può risolvere. Un utente scarica un foglio di calcolo, lo modifica offline e lo carica dopo che qualcun altro ha cambiato l'originale, e la connessione cifrata non ha opinioni sulla sovrascrittura. Un accordo su sovrascrittura, conflitto o versionamento deve esistere prima del metodo di accesso.

SFTP è un protocollo di trasferimento, non una condivisione

SFTP sposta i file su un trasporto SSH cifrato, che è esattamente ciò di cui ha bisogno una copia e non ciò di cui ha bisogno un'unità montata. Non è FTP, e un prodotto che offre FTPS offre un protocollo diverso invece di SFTP. Montare una directory SFTP tramite uno strato di file system non garantisce il blocco, i permessi o il comportamento applicativo della condivisione originale. Verificate i requisiti dell'applicazione client prima di definirlo un sostituto diretto.

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

Questo è l'intero flusso di lavoro per un file finito: connettersi, mettere, prelevare. Un account solo trasferimento ha bisogno anche di un servizio SSH limitato, non solo del file system. Un chroot o ForceCommand internal-sftp limita ciò che la sessione può eseguire, e disattivare l'inoltro TCP e il tunneling chiude i percorsi che altrimenti trasformerebbero un account file in un punto di ingresso di rete. Limitare solo la directory visibile non dimostra nulla su ciò che l'account può raggiungere.

Se vi serve la condivisione, non pubblicatela

A volte la condivisione originale è davvero il requisito, e la risposta non è esporre SMB a client Internet arbitrari. L'indicazione di Microsoft è bloccare il traffico SMB diretto al confine, e per una buona ragione: il protocollo non è stato costruito per affrontare reti non affidabili. Esistono SMB su QUIC e progettazioni comparabili, con requisiti di piattaforma specifici a entrambe le estremità, e non sono un interruttore universale per un server Samba arbitrario. Se nessuno dei due si applica, il lavoro è fornire un percorso di accesso supportato invece di una porta inoltrata.

L'opzione basata sul browser è una terza risposta legittima quando il lavoro si presta. Porta con sé le proprie decisioni: account, link di condivisione, scadenza, versioni conservate e quale copia faccia fede. Un link che chiunque può aprire e uno spazio di lavoro che richiede l'accesso rappresentano politiche di accesso diverse, e nessuna delle due va scelta per caso.

Cosa verificare prima di consegnare l'accesso

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

Qualunque progetto scegliate, limitatelo ai dati e alle operazioni previsti. Il primo comando dovrebbe riuscire e il secondo essere rifiutato; se entrambi riescono, l'account è più ampio del compito. Poi rimuovete l'account e ripetete il primo, che ora dovrebbe fallire. Mantenete identificabile il proprietario dei file di origine, così che una domanda successiva sulla copia autorevole abbia risposta. Il risultato che vale la pena registrare è un flusso di lavoro di file utilizzabile e revocabile, non un'icona di connessione mancante.

Annotate quale protocollo richiede davvero l'applicazione dell'utente e quali tre test avete eseguito. Quelle due righe evitano gran parte del rifacimento.