Egy terepi eszköz kapcsolatot nyit egy szolgáltatáshoz, és a tervezési kérdés VPN és TLS közötti választásként érkezik. Ez a keret téves, mert a kettő különböző munkát végez. A TLS hitelesíti az alkalmazás végpontját és védi a beszélgetést; míg a VPN szabályozza az elérhetőséget és védi a csomagokat a partnerek között. Kövesse a kapcsolatot az eszköztől kifelé, és minden rétegnek megvan a maga válasza.

Ha nem tudja megmondani, hol végződik a TLS, nem tudja megmondani, miben bízik valójában az alkalmazás.

Találja meg, hol végződik valójában a TLS

Kezdje az eszköz alkalmazásánál, és kövesse a kapcsolatot addig a folyamatig, amely befejezi a kézfogást. Ha egy proxy a mainframe előtt lezárja a TLS-t, a védett údvonal a proxynál ér véget. A fennmaradó ugrásnak saját dokumentált védelemre van szüksége.

Ezt feltételezés alapján végponttól végpontig nevezni az a mód, ahogy egy tervezési felülvizsgálat jóváhagy egy rést. Rajzolja ugyanarra a diagramra a végpontot és a bizalmi horgonyt.

A TLS mindkét irányban szállít kéréseket és válaszokat, ezért egy kétirányú alkalmazásnak önmagában nincs szüksége VPN-re a TLS helyett. Ez fordítva is igaz: egy telepítésnek továbbra is szüksége lehet VPN-re más protokollokhoz ugyanazon az eszközön.

Döntse el, mit kell az eszköznek hitelesítenie

Állítsa be a kiszolgáló identitásának ellenőrzését és a szándékolt bizalmi gyökereket. Ha minden eszköznek bizonyítania kell a saját identitását, válasszon támogatott ügyfél-hitelesítési modellt, és regisztráljon külön hitelesítő adatot eszközönként. A megosztott hitelesítő adatok egyetlen ellopott eszközt az egész flotta problémájává tesznek.

Tervezze meg a kulcsvédelmet, a megújítást, a visszavonást és a helyreállítást a szállítás előtt. Egy terepen lévő eszköz, amely sikertelen megújítás után nem regisztrálható újra, helyszíni kiszállássá válik, és ez a költség jobban formálja a tervezést, mint a kézfogás.

Használjon támogatott könyvtárat és aktuális útmutatást. Modern TLS-telepítési útmutatás megtiltja a TLS 1.0 és 1.1 egyeztetését, és egy TLSv1-hivatkozás egy régi tervezési feljegyzésben nem követelmény.

Zárjon, amikor a kézfogás meghiúsul

A sikertelen kézfogás vagy identitásellőrzés nem eshet csendesen vissza az eredeti nyílt szövegű protokollra. Ez a visszaesés az a sebezhetőség, amelyet a TLS-munkának be kellett zárnia. Tegye láthatóvá a hibát az eszköz kezelője és a szolgáltatás számára, és követelje meg a védett csatornát az érzékeny műveletekhez. Ezután hagyja, hogy az alkalmazás engedélyezése döntse el, mit tehet egy hitelesített eszköz.

Határozza meg a kapcsolat élettartamát, a keretezést, az időkorlátokat és az újrapróbálkozás viselkedését a szerződés részeként. A titkosítás nem teszi biztonságossá az ismételt parancsot, és egy bizonytalan korábbi művelet utáni újrapróbálkozás alkalmazásszintű választ igényel.

Írja le a visszaesési szabályt. „Újracsatlakozik TLS nélkül, ha a kézfogás meghiúsul“ tervezési döntés, és egyértelműnek kell lennie.

Csak azt a munkát adja a VPN-nek, amit el tud végezni

A VPN korlátozhatja az elérhetőséget és védheti a csomagokat a saját partneréig. A TLS védi az alkalmazás viszonyát a kiválasztott végponthoz. A végpontjaik különbözhetnek, és egyik sem biztosítja a végpont tárolt adatait vagy adminisztratív hozzáférését.

Mérje a kézfogás költségét, az állandó üzenetforgalmat és az újracsatlakozást a tényleges eszközön, ahelyett hogy feltételezné, hogy az egyik mechanizmus gyorsabb. Ezután tesztelje a négy fontos esetet: a szándékolt cserét, a hibás kiszolgáló-identitást, az engedélyezetlen eszközt és a bizonytalan művelet utáni újracsatlakozást. Jegyezze fel az eredményt minden esetben, beleértve az eszköz által mutatott hibát.

Kapcsolódó cikkek