Portali i vjetër pa klient kishte një buton fshirjeje, një yll të preferuarave dhe një shteg ndarjeje të ngjitur në një email. Vetëm një prej tyre është kontroll. Zëvendësimi i portalit do të thotë të vendosësh cilat operacione u nevojiten ende përdoruesve në distancë dhe ku zbatohet secili, jo të riprodhosh planin e një faqeje që funksiononte rastësisht. Dy forma zëvendësimi mbulojnë shumicën e rasteve, dhe ato dështojnë në pika të ndryshme.

Një buton nuk është leje

Filloni me listën e operacioneve: lexim, ngarkim, riemërtim, fshirje. Vendosni cilat role marrin secilën, pastaj zbatoni atë vendim në shërbimin e skedarëve dhe jo në ndërfaqe. Fshehja e një kontrolli fshirjeje në një portal të re lë lejen e backend-it të paprekur, dhe kushdo me një klient vendas dhe të njëjtin llogari mund ta heqë skedarin.

Fshirja meriton një vendim të veçantë sepse është operacioni për të cilin përdoruesit pendohen. Pyetni se nga mund të rikuperohet vërtet një element i fshirë, dhe mos supozoni se përgjigjja është koshi i laptopit ose koshi i vetë portalit. Një ndarje rrjeti zakonisht nuk i drejton fshirjet përmes koshit lokal.

Në një ndarje të bazuar në Windows, Volume Shadow Copy ofron mekanizmin e fotografive dhe koordinimin që përdor softueri i rezervimit, por prania e tij nuk thotë asgjë nëse kjo ndarje ruan versione që mund t'i riktheni. Pronari i shërbimit të skedarëve duhet të konfirmojë politikën e versioneve dhe të demonstrojë një rikthim përpara se portali të tërhiqet.

Opsioni A: një klient skedarësh vendas përmes tunelit

Një disk i mapuar ose një klient SMB ruan operacionet që përdoruesit tashmë i njohin, dhe lejet zbatohen nga serveri i skedarëve në çdo kërkesë. Identiteti që ka rëndësi është identiteti i shërbimit të skedarëve, kështu që aksesi i mbijeton një ndryshimi të produktit VPN për sa kohë tuneli ende mban trafikun dhe llogaria ekziston ende.

Kostoja është se klienti duhet ta arrijë shërbimin drejtpërdrejt. Zgjidhja e emrave, arritshmëria e portave dhe metoda e autentikimit bëhen të gjitha pjesë e projektimit të aksesit në distancë, dhe një portal që më parë proxy-nte lidhjen fshihte secilën prej këtyre kërkesave. Përdoruesit në pajisje të pamenaxhuara marrin gjithashtu një ndarje të montuar në menaxherin e skedarëve, që është një sipërfaqe më e gjerë sesa një skedë shfletuesi. Parashikoni atë ngarkesë mbështetjeje përpara migrimit, sepse vjen ditën e parë dhe jo pas një periudhe tolerance.

Rikuperimi është argumenti më i fortë për këtë formë: versionet e mëparshme dhe lejet e rikthimit janë vendase në platformë, dhe ndihma teknike mund të përdorë të njëjtën procedurë që përdor në vend.

Opsioni B: një proxy ose portë aplikacionesh

Një portal që e merr skedarin dhe e transmeton në shfletues e mban shërbimin e skedarëve jashtë rrugës së rrjetit të përdoruesit. Kjo është e dobishme kur pajisja nuk mund t'i bashkohet tunelit ose kur organizata dëshiron që çdo kërkesë të regjistrohet në një pikë të vetme ngushtice. Shkëmbimi është se proxy-i bëhet pjesëmarrës në çdo operacion, dhe duhet ta çojë identitetin e përdoruesit deri te shërbimi i skedarëve në vend që të përdorë llogarinë e vet të shërbimit për gjithçka.

Sjellja e fshirjes dhe riemërtimit duhet implementuar, jo trashëguar. Nëse proxy-i ekspozon një veprim fshirjeje, ai veprim e thërret backend-in me një identitet të caktuar, dhe gjurma e auditimit duhet të emërojë përdoruesin dhe jo portën. Nëse proxy-i nuk mund të riemërtojë, thuajeni këtë përpara se përdoruesit ta zbulojnë në mes të një projekti.

Rishkrimi i lidhjeve është vendi ku kjo formë ndryshon në heshtje kuptimin. Një URL që portali e proxy-on nuk është i njëjti objekt si një URL që shfletuesi e hap drejtpërdrejt, dhe shndërrimi i njërës në tjetrën mund të heqë kontekstin e autentikimit që e bënte funksional.

Emrat, identitetet dhe lidhjet mes tyre

Shpërndani serverin dhe shtegun e ndarjes të miratuar, jo një listë shfletimi domeni. Shfletimi varet nga shërbime zbulimi që mund të mos e kalojnë tunelin, dhe një shteg që funksionon sepse laptopi i përdoruesit mund të numërojë një domen është një shteg që thyhet në pajisjen tjetër të pamenaxhuar.

Rishikoni identifikimin e vetëm aplikacion pas aplikacioni. Një token i lëshuar për portalin nuk duhet të riluhet drejt një shërbimi skedarësh që nuk e ka validuar kurrë, dhe parametrat e kërkesës që mbajnë identifikues nuk duhet të kopjohen në një lidhje publike vetëm sepse u shfaqën në faqeshënuesin e vjetër. Trajtoni çdo aplikacion të miratuar si kufirin e vet të besimit.

RequirementNative clientProxy portal
Permission enforcementFile service, per requestProxy identity, then file service
Restore pathPlatform versions and backupsProxy trash plus backend restore
Device requirementsTunnel and clientBrowser only
Audit identityFile server logsProxy logs, if it forwards the user

Zgjidhni sipas listës së kërkesave

Asnjë formë nuk fiton menjëherë. Një fuqi punëtore në laptopë të menaxhuar me një tunel funksional përfiton më shumë nga klienti vendas, sepse rikuperimi dhe lejet vijnë nga platforma dhe jo nga një riimplementim. Një popullsi e përzier kontraktorësh dhe pajisjesh personale mund të justifikojë proxy-in, me kusht që instalimi i identitetit të jetë i vërtetë dhe jo një llogari e përbashkët shërbimi.

Shkruani krahasimin kundrejt katër operacioneve dhe përgjigjes së rikuperimit, më pas tërhiqni portalin e vjetër vetëm pasi një rikthim të jetë kryer përmes rrugës së re. Ai test ushtron pjesët e projektimit që një hyrje e suksesshme nuk i prek kurrë.

Artikuj të ngjashëm