Zëvendësimi i një portali të vjetër skedarësh VPN: mbani kontrollet
Një klient skedarësh vendas dhe një portal proxy zbatojnë lejet, rikuperimin dhe identitetin në vende të ndryshme. Krahasoni ato në katër operacionet që u nevojiten përdoruesve.
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.
| Requirement | Native client | Proxy portal |
|---|---|---|
| Permission enforcement | File service, per request | Proxy identity, then file service |
| Restore path | Platform versions and backups | Proxy trash plus backend restore |
| Device requirements | Tunnel and client | Browser only |
| Audit identity | File server logs | Proxy 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ë.