Egy régi VPN fájlportál leváltása: tartsuk meg az ellenőrzéseket

A régi, kliens nélküli portálon volt egy törlésgomb, egy kedvenc csillag és egy e-mailbe illesztett megosztási útvonal. Ezek közül csak egy ellenőrzés. A portál leváltása azt jelenti, hogy eldöntjük, a távoli felhasználóknak mely műveletekre van még szükségük, és hol érvényesül mindegyik, nem pedig egy véletlenül működő oldal elrendezését másoljuk. Két cserealak fedi a legtöbb esetet, és ezek különböző pontokon hibáznak.

A gomb nem jogosultság

Kezdjük a műveletlistával: olvasás, feltöltés, átnevezés, törlés. Döntsük el, mely szerepkörök kapják meg mindegyiket, majd ezt a döntést a fájlszolgáltatásnál érvényesítsük, ne a felületen. A törlésvezérlő elrejtése egy új portálon érintetlenül hagyja a háttérjogosultságot, és bárki, akinek natív kliense és ugyanaz a fiókja van, továbbra is eltávolíthatja a fájlt.

A törlés külön döntést érdemel, mert ez az a művelet, amit a felhasználók megbánnak. Kérdezzük meg, honnan lehet valójában helyreállítani egy törölt elemet, és ne feltételezzük, hogy a válasz a laptop lomtára vagy a portál saját szemetese. Egy hálózati megosztás általában nem a helyi lomtáron keresztül irányítja a törléseket.

Windows-alapú megosztáson a Volume Shadow Copy biztosítja a pillanatképek gépezetét és a biztonsági mentő szoftver által használt összehangolást, de a jelenléte semmit nem mond arról, hogy ez a megosztás őriz-e visszaállítható verziókat. A fájlszolgáltatás tulajdonosának meg kell erősítenie a verziószabályzatot, és be kell mutatnia egy visszaállítást, mielőtt a portált nyugdíjazzák.

A változat: natív fájlügyfél az alagúton át

A leképezett meghajtó vagy egy SMB kliens megtartja a felhasználók által már ismert műveleteket, és a jogosultságokat minden kérésnél a fájlszerver érvényesíti. A számító identitás a fájlszolgáltatás identitása, így a hozzáférés túléli a VPN-termék cseréjét, amíg az alagút továbbra is szállítja a forgalmat, és a fiók továbbra is létezik.

Az ára az, hogy az ügyfélnek közvetlenül el kell érnie a szolgáltatást. A névfeloldás, a portok elérhetősége és a hitelesítési módszer mind a távoli hozzáférés tervezésének részévé válik, és egy portál, amely korábban a kapcsolatot proxizta, mindezt a követelményt elrejtette. A nem kezelt eszközökön lévő felhasználók a fájlkezelőjükbe csatolt megosztást is kapnak, ami szélesebb felület, mint egy böngészőfül. Számoljunk ezzel a támogatási teherrel a migráció előtt, mert már az első napon megérkezik, nem egy türelmi idő után.

A helyreállítás a legerősebb érv e forma mellett: az előző verziók és a visszaállítási jogosultságok a platform sajátjai, és a helpdesk ugyanazt az eljárást használhatja, mint a helyszínen.

B változat: proxy vagy alkalmazásátjáró

Az a portál, amely lekéri a fájlt és a böngészőbe streameli, kiveszi a fájlszolgáltatást a felhasználó hálózati útvonalából. Ez akkor hasznos, ha az eszköz nem tud csatlakozni az alagúthoz, vagy ha a szervezet minden kérést egyetlen szűk keresztmetszetnél akar naplózni. A kompromisszum az, hogy a proxy minden művelet résztvevőjévé válik, és a felhasználó identitását tovább kell vinnie a fájlszolgáltatásig, ahelyett hogy mindenhez a saját szolgáltatásfiókját használná.

A törlés és az átnevezés viselkedését meg kell valósítani, nem örökölni. Ha a proxy törlési műveletet kínál, az a művelet valamilyen identitással hívja a hátteret, és az auditnaplónak a felhasználót kell megneveznie, nem az átjárót. Ha a proxy nem tud átnevezni, mondjuk meg, mielőtt a felhasználók egy projekt közepén felfedezik.

A hivatkozások átírása az a pont, ahol ez a forma csendesen megváltoztatja a jelentést. Egy URL, amelyet a portál proxiz, nem ugyanaz az objektum, mint egy URL, amelyet a böngésző közvetlenül nyit meg, és az egyik másikká alakítása eltávolíthatja azt a hitelesítési kontextust, amely működőképessé tette.

Nevek, identitások és a köztük lévő hivatkozások

A jóváhagyott szervert és megosztási útvonalat osszuk ki, ne egy tartományböngésző listát. A böngészés olyan felderítő szolgáltatásoktól függ, amelyek nem biztos, hogy átjutnak az alagúton, és egy útvonal, amely azért működik, mert a felhasználó laptopja fel tud sorolni egy tartományt, a következő nem kezelt eszközön eltörik.

Az egyszeri bejelentkezést alkalmazásonként vizsgáljuk felül. A portálhoz kiadott tokent nem szabad újrajátszani egy olyan fájlszolgáltatásnak, amely soha nem érvényesítette, és az azonosítókat hordozó lekérdezési paramétereket nem szabad nyilvános hivatkozásba másolni csak azért, mert a régi könyvjelzőben megjelentek. Kezeljünk minden jóváhagyott alkalmazást a saját bizalmi határaként.

Válasszunk a követelménylista alapján

Egyik forma sem nyer egyértelműen. A működő alagúttal rendelkező, kezelt laptopokon dolgozó munkaerő többet kap a natív kliensből, mert a helyreállítás és a jogosultságok a platformból jönnek, nem egy újraimplementálásból. A vállalkozók és személyes eszközök vegyes sokasága indokolhatja a proxyt, feltéve, hogy az identitás csővezetéke valódi, és nem egy megosztott szolgáltatásfiók.

Írjuk le az összehasonlítást a négy művelet és a helyreállítási válasz mentén, majd csak akkor vonjuk ki a régi portált, ha az új úton már végrehajtottak egy visszaállítást. Ez a teszt gyakorolja a tervezés azon részeit, amelyeket egy sikeres bejelentkezés soha nem érint.