Înlocuirea unui portal de fișiere VPN vechi: păstrați controalele

Vechiul portal fără client avea un buton de ștergere, o stea pentru favorite și o cale de partajare lipită într-un e-mail. Doar unul dintre acestea este un control. Înlocuirea portalului înseamnă să decizi ce operațiuni mai au nevoie utilizatorii la distanță și unde este aplicată fiecare, nu să reproduci aspectul unei pagini care funcționa din întâmplare. Două forme de înlocuire acoperă majoritatea cazurilor, și ele eșuează în puncte diferite.

Un buton nu este o permisiune

Începe cu lista de operațiuni: citire, încărcare, redenumire, ștergere. Decide ce roluri primește fiecare, apoi aplică acea decizie în serviciul de fișiere, nu în interfață. Ascunderea unui control de ștergere într-un portal nou lasă permisiunea de backend intactă, iar oricine are un client nativ și același cont poate încă să elimine fișierul.

Ștergerea merită o decizie separată pentru că este operațiunea de care utilizatorii se căiesc. Întreabă de unde poate fi recuperat cu adevărat un element șters și nu presupune că răspunsul este coșul laptopului sau coșul portalului însuși. O partajare de rețea de obicei nu direcționează ștergerile prin coșul local.

Pe o partajare bazată pe Windows, Volume Shadow Copy oferă mecanismul de instantanee și coordonarea pe care le folosește software-ul de backup, dar prezența sa nu spune nimic despre dacă această partajare păstrează versiuni pe care le poți restaura. Proprietarul serviciului de fișiere trebuie să confirme politica de versiuni și să demonstreze o restaurare înainte ca portalul să fie retras.

Opțiunea A: un client de fișiere nativ prin tunel

Un disc mapat sau un client SMB păstrează operațiunile pe care utilizatorii le știu deja, iar permisiunile sunt aplicate de serverul de fișiere la fiecare cerere. Identitatea care contează este identitatea serviciului de fișiere, așa că accesul supraviețuiește unei schimbări de produs VPN atât timp cât tunelul mai transportă traficul și contul încă există.

Costul este că clientul trebuie să ajungă direct la serviciu. Rezolvarea numelor, accesibilitatea porturilor și metoda de autentificare devin toate parte din proiectarea accesului la distanță, iar un portal care anterior făcea proxy pentru conexiune ascundea fiecare dintre aceste cerințe. Utilizatorii pe dispozitive negestionate primesc și o partajare montată în managerul lor de fișiere, ceea ce este o suprafață mai largă decât o filă de browser. Bugetează acea încărcare de suport înainte de migrare, pentru că sosește în prima zi și nu după o perioadă de grație.

Recuperarea este cel mai puternic argument pentru această formă: versiunile anterioare și permisiunile de restaurare sunt native platformei, iar echipa de suport poate folosi aceeași procedură pe care o folosește la fața locului.

Opțiunea B: un proxy sau un gateway de aplicații

Un portal care preia fișierul și îl transmite în flux către browser ține serviciul de fișiere în afara căii de rețea a utilizatorului. Acest lucru este util când dispozitivul nu se poate alătura tunelului sau când organizația vrea ca fiecare cerere să fie înregistrată într-un singur punct de îngustare. Compromisul este că proxy-ul devine participant la fiecare operațiune și trebuie să ducă identitatea utilizatorului până la serviciul de fișiere în loc să folosească propriul cont de serviciu pentru tot.

Comportamentul la ștergere și redenumire trebuie implementat, nu moștenit. Dacă proxy-ul expune o acțiune de ștergere, acea acțiune apelează backendul cu o anumită identitate, iar urma de audit ar trebui să numească utilizatorul, nu gateway-ul. Dacă proxy-ul nu poate redenumi, spune asta înainte ca utilizatorii să descopere la mijlocul unui proiect.

Rescrierea legăturilor este locul unde această formă schimbă în tăcere sensul. Un URL pe care portalul îl face proxy nu este același obiect ca un URL pe care browserul îl deschide direct, iar conversia unuia în celălalt poate elimina contextul de autentificare care îl făcea funcțional.

Nume, identități și legăturile dintre ele

Distribuie serverul și calea de partajare aprobate, nu o listă de navigare în domeniu. Navigarea depinde de servicii de descoperire care pot să nu treacă prin tunel, iar o cale care funcționează pentru că laptopul utilizatorului poate enumera un domeniu este o cale care se rupe pe următorul dispozitiv negestionat.

Revizuiește autentificarea unică aplicație cu aplicație. Un token emis pentru portal nu ar trebui rejucat către un serviciu de fișiere care nu l-a validat niciodată, iar parametrii de interogare care poartă identificatori nu ar trebui copiați într-o legătură publică doar pentru că au apărut în semnul de carte vechi. Tratează fiecare aplicație aprobată ca propria graniță de încredere.

Alege conform listei de cerințe

Nicio formă nu câștigă direct. O echipă pe laptopuri gestionate cu un tunel funcțional câștigă mai mult din clientul nativ, pentru că recuperarea și permisiunile vin de la platformă, nu dintr-o reimplementare. O populație mixtă de contractori și dispozitive personale poate justifica proxy-ul, cu condiția ca instalația de identitate să fie reală și nu un cont de serviciu partajat.

Notează comparația față de cele patru operațiuni și răspunsul despre recuperare, apoi retrage portalul vechi doar după ce o restaurare a fost executată prin noua cale. Acel test exersează părțile proiectării pe care o autentificare reușită nu le atinge niciodată.