Egy vállalati webalkalmazás átvitele a VPN mögé: átállási útmutató

Képzelje el a változást a felhasználó oldaláról. Valaki rákattint egy könyvjelzőre, a megszokott bejelentkező oldalt várja, és helyette kapcsolódási hibát kap, mert a hosztnév most már csak az alagúton belül válaszol. Az az egyetlen pillanat tartalmaz mindent, amit a migrációs tervnek jól kell csinálnia: a nevet, az útvonalat, a tanúsítványt, a fiókot és a mögötte lévő műveletet. Járja végig az alábbi lépéseket ebben a sorrendben, és az átállás megszűnik ugrásnak lenni.

Lépés 1: írja le, mit csinálnak ma a felhasználók

Kezdje a címsorban látható hosztnévvel, a porttal, az emberek által végrehajtott műveletekkel és a használt fiókokkal. Ha nem tudja megnevezni a három fő műveletet, nem áll készen a nyilvános belépő lezárására, mert az átvétel során nem fog felismerni egy hibásat.

Ezután döntse el, ki a privát közönség. A vállalati VPN-en lévő alkalmazottak kezdet, nem válasz. A szerződéses munkatársaknak, a támogató csapatnak és a pénzügyi csapatnak is szüksége lehet az alkalmazásra, és lehet, hogy nem mindannyian ugyanazon átjáró mögött ülnek.

Lépés 2: válassza el az alagutat a bejelentkezéstől

Amikor a felhasználó a VPN-en keresztül eléri az alkalmazást, a böngésző továbbra is TLS-kapcsolatot nyit az alkalmazás saját végpontjához. A tanúsítványnak meg kell felelnie ennek a névnek, és az alkalmazás továbbra is hitelesíti a fiókot. Az alagút semmit nem helyettesít e kettő közül.

Itt mennek csendben félre a migrációk. Valaki eldönti, hogy a privát címnek már nincs szüksége érvényes tanúsítványra, a felhasználók megtanulnak átkattintani egy figyelmeztetésen, és a szervezet egy nyilvános kitettséget cserélt egy biztonsági figyelmeztetések figyelmen kívül hagyására irányuló képzésre. Ha az alkalmazásnak valóban belső tanúsítványra van szüksége, adjon ki egyet a belső hatóságtól, és ossza el megfelelően a bizalmat. Ez ellenőrzött változás; egy figyelmeztető oldal nem az.

Tartsa az engedélyezést ott, ahol már van. A NIST zéró bizalom architektúra összefoglalója egyenesen kimondja: a hálózati hely nem indok érzékeny művelet megadására. Az alagúton belül lenni nem változtathat egy csak olvasható fiókot adminisztrátorrá.

Lépés 3: találja meg a nem alkalmazott hívókat

Nyissa meg az alkalmazás konfigurációját, és soroljon fel mindent, ami beszél vele: az identitásszolgáltató visszahívási URL-je, egy fizetési szolgáltató webhookja, ütemezett import, monitorozási próba, egy partner API-kliense. Mindegyik egy függőség gazdálkodóval, és mindegyik más-más pillanatban fog eltörni.

Döntsön támogatott útvonalról mindegyiknél, amelynek maradnia kell. Egy webhook-szolgáltató nem csatlakozhat az alkalmazotti VPN-hez, tehát vagy tegyen elérhetővé egy szűken korlátozott integrációs végpontot saját hitelesítéssel, vagy változtassa meg az integrációs modellt. Az egész alkalmazást nyilvánosan hagyni egyetlen visszahívás miatt választás, és általában a rossz.

Írjon le minden kivételt céllal, engedélyezett művelettel, hitelesítéssel és gazdálkodóval. Az integrációnak adott általános VPN-fiók az, ahogyan egy kivétel állandóvá válik. Tekintse át a listát a következő hozzáférési felülvizsgálaton, mert az integrációk túlélik az őket hozzáadó projekteket. A lejárati dátum nélküli kivétel állandó tervezési döntés, amelyet senki nem hozott meg.

Lépés 4: vezesse ki a nyilvános útvonalat, ne csak a DNS-rekordot

Járja végig a közzétételi láncot: DNS, terheléselosztó figyelők, fordított proxy szabályok, hoszt tűzfal és minden alternatív név, amely még a régi címre mutat. Ellenőrizze mindkét címcsaládot. A fő A rekord megváltoztatása szinte semmit nem bizonyít, ha egy régebbi CNAME vagy egy IPv6-figyelő még kiszolgálja az alkalmazást.

Ezzel párhuzamosan erősítse meg, hogy a privát név az alagúton belül feloldódik, és hogy a tanúsítvány lefedi a nevet, amelyet a felhasználók be fognak írni. Az a felhasználó, akinek numerikus címet kell beillesztenie, tünetet talált, nem megoldást.

Szűkítse a VPN közönségét az alkalmazás útvonalára. Az irodai hálózathoz való széles hozzáférés egy kitettségi döntést cserél egy nagyobbra, és az adminisztratív felületeknek saját engedélyezett forrásokra van szükségük, nem pedig a felhasználói szabály öröklésére.

Lépés 5: maga járja végig az átvételt

Csatlakozzon jóváhagyott felhasználóként, nyissa meg a könyvjelzőt, ellenőrizze a tanúsítványt, jelentkezzen be, és hajtson végre egy valódi műveletet. Ezután próbáljon ki egy fiókot, amelynek nem szabadna rendelkeznie ezzel a művelettel, és erősítse meg, hogy elutasítják. Utána próbálja meg a VPN-en kívüli eszközről, és erősítse meg, hogy az alkalmazás elérhetetlen.

Ismételje meg minden megtartott integrációra, és olvassa el a szolgáltató kézbesítési naplóját ahelyett, hogy feltételezné, hogy a saját teszteszköze 200-as válasza ugyanaz. Egy sikeres VPN-bejelentkezés egyik eredmény bizonyítéka sem.

Lépés 6: gyakorolja a rossz napot

Döntse el, mi történik alagútkimaradás esetén: a munka leáll, vagy egy másik jóváhagyott hozzáférési módszer veszi át. Bármit is választ, írja le, és tesztelje egyszer, mert a vészhelyzeti nyilvános újranyitást mint dokumentálatlan helyreállítási mechanizmust előbb-utóbb nyomás alatt álló valaki fogja végrehajtani.

Tartsa meg a helyreállítási hozzáférést az átjárót és az alkalmazást karbantartó adminisztrátoroknak, gazdálkodóval és eltávolítási dátummal. Rögzítse a változást és annak visszafordítási feltételeit ugyanott, hogy egy sikertelen migráció ne zárja ki azokat, akik javítanák.

Az átállás után a javítások, a fiókéletciklus, az alkalmazásengedélyezés és az auditálás továbbra is az Öné. Az alagút szűkítette a belépést; egyik feladatot sem vette át.