Két VPN-kapu egymás után: mit dönt valójában mindegyik

Két VPN láncolását általában többlettitkosításként adják el, ami a legkevésbé érdekes dolog, amit tesz. A valódi termék egy második engedélyezési döntés, amelyet más tulajdonos hoz más erőforráshalmazon. Ha mindkét szakasz ugyanazt a hitelesítő adatot fogadja el, és ugyanazokat a célokat éri el, a belső kapu díszítés extra késleltetéssel. Annak eldöntése, hogy a második döntés megéri-e az üzemeltetési költségét, azzal kezdődik, hogy megnevezzük, mit ellenőriz valójában az egyes kapu.

Egy alagút, majd egy második döntés

A külső kapu széles kérdésre válaszol: ez egy jóváhagyott munkavállalói eszköz-e, és elérheti-e az általános belső hálózatot. A belső kapu szűkebbre: rendelkezik-e ez az identitás a karbantartási jogosultsággal, és elérheti-e ezeket a konkrét felügyeleti végpontokat. Ezek különböző kérdések különböző tulajdonosokkal, és egyik sem jelenti a másikat. Egy mindkét szakaszon átvezető útvonal létezése nem felhatalmazás a második mögötti használatára. A távoli bejárat elérése azt bizonyítja, hogy egy útvonal működik, és semmi többet.

Az elv régi, és még mindig figyelmen kívül hagyják: a hálózati hely önmagában semmit nem érvel. A NIST nulla-bizalom architektúrájának összefoglalója világosan kimondja, elutasítva azt a hallgatólagos bizalmat, amely abból ered, honnan jött a kapcsolat, vagy ki birtokolja a hálózatot. Itt alkalmazva a belső bejárat elérése az erőforrásainak előfeltétele, soha nem a használatukra való engedély.

Írja le, mit ellenőriz az egyes kapu

Minden szakasznál rögzítse az általa ellenőrzött identitást, az engedélyezett célokat és azokat a feltételeket, amelyek mellett átugorható. A külső kapu jogszerűen engedélyezheti a szokásos belső szolgáltatásokat plusz a belső kapu figyelőjét, és semmi mást. A belső kapu szerepkövetelést írhat elő, és csak a változási rekordban megnevezett felügyeleti címeket engedélyezheti. A távoli végponton lévő alkalmazás megtartja a végső szót arról, milyen műveleteket végezhet ez a szerep, így a lánc kaput ad hozzá az alkalmazás engedélyezésének helyettesítése nélkül.

Két kihagyás csendesen megtöri a tervet. Ha a külső tartomány már közvetlenül eléri az összes érzékeny célt, a belső kapu opcionális, nem kötelező. Ha egy nyilvános figyelő vagy egy második privát útvonal ugyanazt a hozzáférést kínálja, a szándékolt útvonal egy lehetőség több közül. Rendeljen tulajdonost minden szabálykészlethez is, és szerződésük nevezze meg a cél-szolgáltatásokat, az engedélyezett forrásidentitásokat, a privát DNS-t, a címfordítást és azt, hogy ki válaszol, ha az átadás meghiúsul. A külső hálózaton megbízhatónak tartott cím soha nem helyettesítheti a belső tartomány engedélyezését.

A megtagadási eseteket tesztelje, ne a boldog utat

A két kapun átvezető sikeres kapcsolat nagyon keveset bizonyít, mert ez az az eset, amelyet mindenki tesztelt a bevezetés során. Az érdekes esetek azok, amikor az egyik szakasz átenged, a másik megtagad. Ezek közül három lefedi a kockázat nagy részét, és mindegyiknek van egy várható eredménye, amely ellenőrizhető, nem vitatható.

Jóváhagyott általános hozzáféréssel és hiányzó érzékeny szereppel a szokásos munkának folytatódnia kell, miközben az érzékeny cél megtagadásra kerül. Hagyja jóvá mindkét szakaszt, és az elérhető halmaz a változási rekordban megnevezett karbantartási végpontok legyen, semmi szélesebb. Ha a jogosultságot a munkamenet közepén visszavonják, a megállapodott munkamenet-szabályzatnak hatályba kell lépnie anélkül, hogy a nem kapcsolódó általános hozzáférést lebontaná. Hogy ez a visszavonás azonnal vagy a következő újrahitelesítéskor zárja-e le a meglévő munkamenetet, olyan szabályzati döntés, amelynek már a szerződésben kellene lennie. Aki az elfogadási eseteket írta, nem az a személy, akinek az incidens alatt értelmeznie kellene őket.

curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"

Számolja meg a hozzáadott függőségeket

Minden további szakasz hozzáad egy összetevőt, amely meghibásodhat, és egy útvonalat, amelynek megfelelően be kell ágyazódnia a külső alagútba. Részleges hiba esetén a külső útvonal fent marad, míg a belső elérhetetlen, így a felhasználó egy egészséges VPN-ikont lát egy soha nem válaszoló szolgáltatás mellett.

Ellenőrizze az útvonalakat és a blokkolási szabályokat hiba esetén, ne csak a normál esetben. A külső alagút által kényszerített alapértelmezett útvonal elfoghatja a belső kapu saját címét, ami a második szakaszt olyan kapcsolattá teszi, amely létrejön, majd megszakad. Rögzítse, minek kell blokkolva maradnia, miközben a belső alagút nincs, mert a körülötte lévő véletlen visszaesés rosszabb a tiszta kimaradásnál. Ugyanazt a vizsgálati formát használja mindkét ugrásnál, hogy mindegyiket mérjék, ne feltételezzék. Két csatlakozott állapotjelző sem beágyazódást, sem elkülönítést nem bizonyít.

Mit nem vehet meg Önnek a második kapu

Kérdezze meg, osztozik-e a két kapu egy hitelesítő adaton, egy tanúsító hatóságon vagy egy felügyeleti síkon. Ahol igen, ott a legfontosabb meghibásodási módjaikat is megosztják, és a második szakasz többe kerül, mint a függetlenség, amelyet látszólag hozzáad. A külön titkosítási munkamenetek nem hoznak létre külön adminisztratív ellenőrzéseket.

Tartsa meg a belső kaput, amíg olyan követelményt kényszerít ki, amelyet meg tud fogalmazni és tesztelni, például egy szerepet, amelyet a külső tartomány soha nem ellenőriz. Dobja el, amikor egyetlen feladata ugyanazon identitás újrahitelesítése ugyanazon célok felé. Mindkét esetben rögzítse a követelményt, a tulajdonost és a hiba viselkedését együtt, hogy a következő felülvizsgálat a követelményről vitatkozzon, ne a diagramról.