TLS VPN kontra IPsec: az öt mező, amelyet érdemes átvizsgálni
Hasonlítsa össze a TLS VPN-t és az IPsec VPN-t kiadás, protokollverzió, csomagkészlet, partneridentitás és kitett hatókör szerint, valamint a ténylegesen beállított hibaeredmény szerint.
A TLS VPN-ek és az IPsec VPN-ek protokollcsalád szerinti rangsorolása olyan kérdésre válaszol, amelyet senki nem tett fel, és általában olyan konstrukcióra hivatkozik, amelyet mindkét család évekkel ezelőtt elhagyott. Amit egy bíráló valóban értékelni tud, az a tárgyalt védelem, a partneridentitás, az ügyfélmodell és a kitett szolgáltatás. Ez a négy dolog látható egy telepítésben, és egyik sem következik a termékcímkéből. Kérjen öt mezőt, és a beszélgetés konkrét lesz.
Öt mező, és a címke nem egy közülük
Az első mező a támogatott szoftverkiadás, mert a verzió nélküli protokollleírás brosúra. A második a tárgyalt protokollverzió, amely eldönti, milyen konstrukciók érhetők el egyáltalán. A harmadik a védelmi csomag, a negyedik a hitelesítési módszer mind a partner, mind a felhasználó számára, az ötödik pedig a hozzáférési hatókör, amelyet a termék a beléptetés után biztosít.
Az SSL VPN címke legalább három különböző terméket fed le: egy teljes hálózati klienst, egy alkalmazásproxy-t és egy örökölt böngészőalapú portált. Különböző szolgáltatásokat tesznek ki, és különbözőképpen hibáznak, így a címke nem helyettesítheti a hatókör mezőt.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
Mit változtat valójában a hitelesített titkosítás
A TLS 1.3 hitelesített titkosítást ír elő, ami eltávolítja a régebbi MAC-then-encrypt konstrukciót a protokollból, ahelyett hogy választhatóvá tenné. Az IPsec ESP ugyanilyen régóta rendelkezik hitelesített titkosítású csomagokkal, az AES-GCM a saját RFC-jében definiálva. Mindkét családban a garancia a tárgyalt csomagból származik, nem a család nevéből, ezért kezdődik a mezőlista verzióval. A bírálónak, aki nem tudja megnevezni a csomagot, nincs mit értékelnie.
Ezért félrevezető a történeti összehasonlítás. Egy régi TLS-verzióhoz CBC-csomaggal rögzített telepítés és egy TLS 1.3-at AEAD-csomaggal futtató telepítés nem azonos biztonsági helyzet, még ha mindkettő TLS VPN is. Ugyanez a hasadás létezik az IPsec oldalon egy modern ESP-csomag és egy örökölt kombináció között.
A tárgyalt értékeket olvassa, ne a szándékolt konfigurációt. Az alábbi parancsok megmutatják, miben állapodott meg valójában egy élő végpont és egy élő alagút.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas
Ha a végpont nem akar TLS 1.3-at tárgyalni, az megállapítás, nem preferencia. Ha az alagút olyan csomagot listáz, amelyre nem számított, a fontos konfiguráció a partnerek által választott, nem a sablonban lévő.
A partneridentitás külön kérdés
A hitelesített partner nélküli titkosítás megvédi a forgalmat a megfigyelőktől, és átadja annak, aki a kapcsolatra válaszolt. A partner hitelesítése azt kérdezi, milyen identitást várunk, milyen bizalmi anyag igazolja, és hogyan viselkedik az ügyfél, ha a válasz nem egyezik. A tanúsítványlánc, a rögzített kulcs és az előre megosztott titok három különböző válasz, három különböző üzemeltetési költséggel.
Utána tegye fel ugyanezeket a kérdéseket a felhasználóról vagy az eszközről. Az az átjáró, amely a gépet hitelesíti és bármely felhasználót beenged, vagy fordítva, sajátos helyzetben van, amelyet le kell írni, nem feltételezni. A beléptetés után alkalmazott erőforrás-jogosultságok ugyanahhoz a mezőhöz tartoznak, mert a hitelesítés nem engedélyezés.
A hosztnév- és tanúsítványellenőrzések megőrzése fontosabb, mint a bejelentkezési ablak ismerőssége. Az ellenőrzést figyelmen kívül hagyó ügyfél eltávolította az egyetlen lépést, amely megkülönbözteti az átjáróját egy meggyőző utánzattól.
A határ, amelyet a termék kitár
Az ügyfél nélküli portál kiválasztott alkalmazásműveleteket proxyz az átjárón keresztül, így a felhasználó felületet ér el, nem hálózatot. A teljes alagutas ügyfél azt szállítja, amit az útvonalai és szűrési szabályai kiválasztanak, ami sokkal nagyobb felület. A kettő protokollszilárdság szerinti összehasonlítása elvéti a különbséget abban, mit érhet el egy támadó rajtuk keresztül. Az egyik alkalmazásfelületet tár ki, a másik útvonalazott hálózatot, és a kettő különböző bírálatot igényel.
Kérdezze meg, melyik szolgáltatás van kitéve, mely műveletek engedélyezettek, és mire figyel maga az átjáró. Az az felügyeleti felület, amely a felhasználói portállal azonos címről érhető el, telepítési megállapítás, és semmilyen protokollválasztás nem kompenzálja.
Az alkalmazásonkénti hatókör tovább szűkíti a felületet, és megváltoztatja a hiba viselkedését is, amikor az alagút megszakad. Az a tervezés, amely teljes alagút elérését feltételezi, olyan módokon törik meg, amelyeket az alkalmazásonkénti tervezés nem ismer, és a támogatási teher követi.
Döntse el a hibaeredményt és az életciklust
Hogy mi történik, ha a hitelesítés vagy a védelem nem elérhető, szakpolitikai döntés, amely a bírálatba tartozik. A blokkolt eredmény és a be nem jelentett közvetlen visszaesés különböző következményekkel jár, és a különbség láthatatlan egy funkciólistában. Adja meg a szándékolt viselkedést az általa védett erőforrás mellett.
Foglalja bele az átjáró javítási és támogatási életciklusát, az engedélyezett külső funkcióit és az ügyfelek frissítési útvonalát. A helyes protokollválasztás nem tesz biztonságossá egy rosszul telepített szolgáltatást, és a legtöbb incidens abban a résben él, nem a csomagban.
Írja fel az öt mezőt, a hibapolitikát és az életciklus tulajdonosát egy oldalra. Az az oldal egy bírálat; a protokollcsaládok összehasonlítása vélemény.