Sostituire un vecchio portale file VPN: mantenere i controlli

Il vecchio portale senza client aveva un pulsante di eliminazione, una stella per i preferiti e un percorso di condivisione incollato in un messaggio di posta. Solo uno di questi è un controllo. Sostituire il portale significa decidere quali operazioni servono ancora agli utenti remoti e dove ciascuna viene applicata, non riprodurre il layout di una pagina che funzionava per caso. Due forme di sostituzione coprono la maggior parte dei casi e falliscono in punti diversi.

Un pulsante non è un permesso

Parti dall'elenco delle operazioni: lettura, caricamento, rinomina, eliminazione. Decidi quali ruoli ottengono ciascuna, poi applica quella decisione nel servizio file anziché nell'interfaccia. Nascondere un controllo di eliminazione in un nuovo portale lascia intatto il permesso di backend, e chiunque abbia un client nativo e lo stesso account può ancora rimuovere il file.

L'eliminazione merita una decisione separata perché è l'operazione che gli utenti rimpiangono. Chiedi da dove si può davvero recuperare un elemento eliminato, e non dare per scontato che la risposta sia il cestino del laptop o il cestino del portale stesso. Una condivisione di rete di solito non instrada le eliminazioni attraverso il cestino locale.

Su una condivisione basata su Windows, Volume Shadow Copy fornisce il meccanismo delle copie istantanee e il coordinamento che usa il software di backup, ma la sua presenza non dice nulla sul fatto che questa condivisione conservi versioni ripristinabili. Il proprietario del servizio file deve confermare la politica delle versioni e dimostrare un ripristino prima che il portale venga ritirato.

Opzione A: un client file nativo sul tunnel

Un'unità mappata o un client SMB mantiene le operazioni che gli utenti già conoscono, e i permessi sono applicati dal server file a ogni richiesta. L'identità che conta è quella del servizio file, quindi l'accesso sopravvive a un cambio di prodotto VPN finché il tunnel trasporta ancora il traffico e l'account esiste ancora.

Il costo è che il client deve raggiungere il servizio direttamente. Risoluzione dei nomi, raggiungibilità delle porte e metodo di autenticazione diventano tutti parte del progetto di accesso remoto, e un portale che prima faceva da proxy della connessione nascondeva ognuno di questi requisiti. Gli utenti su dispositivi non gestiti hanno anche una condivisione montata nel file manager, che è una superficie più ampia di una scheda del browser. Metti in budget quel carico di supporto prima della migrazione, perché arriva il primo giorno e non dopo un periodo di tolleranza.

Il ripristino è l'argomento più forte per questa forma: le versioni precedenti e i permessi di ripristino sono nativi nella piattaforma, e l'help desk può usare la stessa procedura che usa in sede.

Opzione B: un proxy o gateway applicativo

Un portale che preleva il file e lo trasmette al browser tiene il servizio file fuori dal percorso di rete dell'utente. È utile quando il dispositivo non può entrare nel tunnel o quando l'organizzazione vuole che ogni richiesta sia registrata in un unico punto di strozzatura. Il compromesso è che il proxy diventa partecipe di ogni operazione e deve portare l'identità dell'utente fino al servizio file invece di usare il proprio account di servizio per tutto.

Il comportamento di eliminazione e rinomina va implementato, non ereditato. Se il proxy espone un'azione di eliminazione, quell'azione chiama il backend con una certa identità, e la traccia di controllo dovrebbe indicare l'utente e non il gateway. Se il proxy non può rinominare, dillo prima che gli utenti lo scoprano a metà di un progetto.

La riscrittura dei link è il punto in cui questa forma cambia silenziosamente significato. Un URL che il portale fa da proxy non è lo stesso oggetto di un URL che il browser apre direttamente, e convertire l'uno nell'altro può togliere il contesto di autenticazione che lo rendeva funzionante.

Nomi, identità e i link in mezzo

Distribuisci il server e il percorso di condivisione approvati, non un elenco di esplorazione del dominio. L'esplorazione dipende da servizi di individuazione che potrebbero non attraversare il tunnel, e un percorso che funziona perché il laptop dell'utente riesce a enumerare un dominio è un percorso che si rompe sul prossimo dispositivo non gestito.

Esamina l'accesso singolo applicazione per applicazione. Un token emesso per il portale non dovrebbe essere ripetuto verso un servizio file che non lo ha mai convalidato, e i parametri di query che portano identificatori non dovrebbero essere copiati in un link pubblico solo perché comparivano nel vecchio segnalibro. Tratta ogni applicazione approvata come un proprio confine di fiducia.

Scegli in base all'elenco dei requisiti

Nessuna delle due forme vince del tutto. Una forza lavoro su laptop gestiti con un tunnel funzionante ottiene di più dal client nativo, perché ripristino e permessi vengono dalla piattaforma e non da una reimplementazione. Una popolazione mista di collaboratori esterni e dispositivi personali può giustificare il proxy, purché l'impianto di identità sia reale e non un account di servizio condiviso.

Scrivi il confronto rispetto alle quattro operazioni e alla risposta sul ripristino, poi ritira il vecchio portale solo dopo che un ripristino è stato eseguito attraverso il nuovo percorso. Quel test esercita le parti del progetto che un accesso riuscito non tocca mai.