Ersätta en gammal VPN-filportal: behåll kontrollerna
En inbyggd filklient och en proxyportal upprätthåller behörigheter, återställning och identitet på olika ställen. Jämför dem på de fyra operationer användarna behöver.
Den gamla klientlösa portalen hade en raderingsknapp, en favoritstjärna och en delningssökväg inklistrad i ett mejl. Bara en av dessa är en kontroll. Att ersätta portalen innebär att avgöra vilka operationer fjärranvändarna fortfarande behöver och var var och en upprätthålls, inte att återskapa layouten för en sida som råkade fungera. Två ersättningsformer täcker de flesta fall, och de brister på olika punkter.
En knapp är inte en behörighet
Börja med operationslistan: läsa, ladda upp, byta namn, radera. Bestäm vilka roller som får var och en och upprätthåll sedan det beslutet i filtjänsten i stället för i gränssnittet. Att dölja en raderingskontroll i en ny portal lämnar backendbehörigheten intakt, och alla med en inbyggd klient och samma konto kan fortfarande ta bort filen.
Radering förtjänar ett eget beslut eftersom det är operationen användarna ångrar. Fråga var ett raderat objekt faktiskt kan återställas ifrån, och utgå inte från att svaret är laptopens papperskorg eller portalens egen papperskorg. En nätverksdelning dirigerar vanligtvis inte raderingar genom den lokala papperskorgen.
På en Windows-baserad delning tillhandahåller Volume Shadow Copy maskineriet för ögonblicksbilder och den samordning som säkerhetskopieringsprogramvaran använder, men dess närvaro säger ingenting om huruvida denna delning behåller versioner du kan återställa. Ägaren till filtjänsten måste bekräfta versionspolicyn och visa en återställning innan portalen avvecklas.
Alternativ A: en inbyggd filklient över tunneln
En mappad enhet eller en SMB-klient behåller de operationer användarna redan känner till, och behörigheterna upprätthålls av filservern vid varje begäran. Den identitet som spelar roll är filtjänstens identitet, så åtkomsten överlever ett byte av VPN-produkt så länge tunneln fortfarande bär trafiken och kontot fortfarande finns.
Kostnaden är att klienten måste nå tjänsten direkt. Namnuppslagning, portåtkomst och autentiseringsmetoden blir alla en del av designen för fjärråtkomst, och en portal som tidigare proxade anslutningen dolde vart och ett av dessa krav. Användare på ohanterade enheter får också en delning monterad i filhanteraren, vilket är en bredare yta än en webbläsarflik. Budgetera den supportbelastningen före migreringen, eftersom den kommer redan första dagen och inte efter en frist.
Återställning är det starkaste argumentet för denna form: tidigare versioner och återställningsbehörigheter är inbyggda i plattformen, och helpdesken kan använda samma procedur som den använder på plats.
Alternativ B: en proxy eller applikationsgateway
En portal som hämtar filen och strömmar den till webbläsaren håller filtjänsten utanför användarens nätverksväg. Det är användbart när enheten inte kan ansluta till tunneln eller när organisationen vill att varje begäran loggas på en enda flaskhals. Avvägningen är att proxyn blir deltagare i varje operation, och den måste föra användarens identitet vidare till filtjänsten i stället för att använda sitt eget tjänstekonto för allt.
Beteendet vid radering och namnbyte måste implementeras, inte ärvas. Om proxyn exponerar en raderingsåtgärd anropar den åtgärden backend med någon identitet, och granskningsspåret bör namnge användaren och inte gatewayen. Om proxyn inte kan byta namn, säg det innan användarna upptäcker det mitt i ett projekt.
Omskrivning av länkar är där denna form tyst ändrar betydelsen. En URL som portalen proxar är inte samma objekt som en URL som webbläsaren öppnar direkt, och att konvertera den ena till den andra kan ta bort autentiseringskontexten som gjorde den fungerande.
Namn, identiteter och länkarna däremellan
Distribuera den godkända servern och delningssökvägen, inte en lista för domänbläddring. Bläddring bygger på upptäcktstjänster som kanske inte korsar tunneln, och en sökväg som fungerar därför att användarens laptop kan räkna upp en domän är en sökväg som går sönder på nästa ohanterade enhet.
Granska enkel inloggning applikation för applikation. En token som utfärdats för portalen bör inte spelas upp mot en filtjänst som aldrig validerade den, och frågeparametrar som bär identifierare bör inte kopieras in i en offentlig länk bara för att de förekom i det gamla bokmärket. Behandla varje godkänd applikation som sin egen förtroendegräns.
| 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 |
Välj mot kravlistan
Ingen av formerna vinner direkt. En arbetsstyrka på hanterade laptops med en fungerande tunnel får mer ut av den inbyggda klienten, eftersom återställning och behörigheter kommer från plattformen och inte från en nyimplementering. En blandad population av entreprenörer och personliga enheter kan motivera proxyn, förutsatt att identitetsdragningen är verklig och inte ett delat tjänstekonto.
Skriv ner jämförelsen mot de fyra operationerna och svaret om återställning, och avveckla sedan den gamla portalen först efter att en återställning har utförts via den nya vägen. Det testet tränar de delar av designen som en lyckad inloggning aldrig rör.