Å erstatte en gammel VPN-filportal: behold kontrollene
En innebygd filklient og en proxyportal håndhever tillatelser, gjenoppretting og identitet på forskjellige steder. Sammenlign dem på de fire operasjonene brukerne trenger.
Den gamle klientløse portalen hadde en sletteknapp, en favorittstjerne og en delebanesti limt inn i en e-post. Bare én av disse er en kontroll. Å erstatte portalen betyr å avgjøre hvilke operasjoner eksterne brukere fortsatt trenger og hvor hver enkelt håndheves, ikke å gjenskape oppsettet til en side som tilfeldigvis fungerte. To erstatningsformer dekker de fleste tilfeller, og de svikter på forskjellige punkter.
En knapp er ikke en tillatelse
Start med operasjonslisten: lese, laste opp, gi nytt navn, slette. Avgjør hvilke roller som får hver av dem, og håndhev den avgjørelsen i filtjenesten i stedet for i grensesnittet. Å skjule en slettekontroll i en ny portal lar backend-tillatelsen være intakt, og alle med en innebygd klient og samme konto kan fortsatt fjerne filen.
Sletting fortjener en egen avgjørelse fordi det er operasjonen brukerne angrer på. Spør hvor et slettet element faktisk kan gjenopprettes fra, og ikke anta at svaret er laptoppens papirkurv eller portalens egen søppelbøtte. En nettverksdeling ruter vanligvis ikke slettinger gjennom den lokale papirkurven.
På en Windows-basert deling gir Volume Shadow Copy maskineriet for snapshots og koordineringen som sikkerhetskopiprogramvaren bruker, men tilstedeværelsen sier ingenting om hvorvidt denne delingen beholder versjoner du kan gjenopprette. Eieren av filtjenesten må bekrefte versjonspolicyen og demonstrere en gjenoppretting før portalen avvikles.
Alternativ A: en innebygd filklient over tunnelen
En tilordnet stasjon eller en SMB-klient beholder operasjonene brukerne allerede kjenner, og tillatelsene håndheves av filserveren ved hver forespørsel. Identiteten som betyr noe er filtjenestens identitet, så tilgangen overlever et bytte av VPN-produkt så lenge tunnelen fortsatt bærer trafikken og kontoen fortsatt finnes.
Kostnaden er at klienten må nå tjenesten direkte. Navneoppslag, porttilgjengelighet og autentiseringsmetoden blir alle en del av designet for ekstern tilgang, og en portal som tidligere proxiet tilkoblingen skjulte hvert av disse kravene. Brukere på ustyrte enheter får også en deling montert i filbehandleren sin, noe som er en bredere flate enn en nettleserfane. Budsjetter den støttebelastningen før migreringen, fordi den kommer den første dagen og ikke etter en frist.
Gjenoppretting er det sterkeste argumentet for denne formen: tidligere versjoner og gjenopprettingstillatelser er innebygd i plattformen, og brukerstøtten kan bruke samme prosedyre som på stedet.
Alternativ B: en proxy eller applikasjonsgateway
En portal som henter filen og strømmer den til nettleseren holder filtjenesten utenfor brukerens nettverksbane. Det er nyttig når enheten ikke kan bli med i tunnelen eller når organisasjonen vil at hver forespørsel skal logges på ett flaskehalspunkt. Avveiningen er at proxyen blir deltaker i hver operasjon, og den må bære brukerens identitet videre til filtjenesten i stedet for å bruke sin egen tjenestekonto til alt.
Sletting og nytt navn må implementeres, ikke arves. Hvis proxyen eksponerer en slettehandling, kaller den handlingen backend med en eller annen identitet, og revisjonssporet bør navngi brukeren og ikke gatewayen. Hvis proxyen ikke kan gi nytt navn, si det før brukerne oppdager det midt i et prosjekt.
Omskriving av lenker er der denne formen stille endrer betydning. En URL som portalen proxier er ikke det samme objektet som en URL nettleseren åpner direkte, og å konvertere den ene til den andre kan fjerne autentiseringskonteksten som gjorde den fungerende.
Navn, identiteter og lenkene mellom dem
Distribuer den godkjente serveren og delebanestien, ikke en domenenettleserliste. Nettlesing avhenger av oppdagelsestjenester som kanskje ikke krysser tunnelen, og en bane som fungerer fordi brukerens laptop kan ramse opp et domene, er en bane som brytes på neste ustyrte enhet.
Gå gjennom enkel pålogging applikasjon for applikasjon. Et token utstedt for portalen bør ikke spilles av til en filtjeneste som aldri validerte det, og spørringsparametere som bærer identifikatorer bør ikke kopieres inn i en offentlig lenke bare fordi de dukket opp i det gamle bokmerket. Behandle hver godkjent applikasjon som sin egen tillitsgrense.
| 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 |
Velg mot kravlisten
Ingen av formene vinner entydig. En arbeidsstyrke på styrte laptoper med en fungerende tunnel får mer ut av den innebygde klienten, fordi gjenoppretting og tillatelser kommer fra plattformen og ikke fra en reimplementering. En blandet populasjon av entreprenører og personlige enheter kan rettferdiggjøre proxyen, forutsatt at identitetsrøret er ekte og ikke en delt tjenestekonto.
Skriv ned sammenligningen mot de fire operasjonene og gjenopprettingssvaret, og avvikle den gamle portalen bare etter at én gjenoppretting er utført via den nye banen. Den testen trener delene av designet som en vellykket innlogging aldri berører.