Fältutrustning, TLS och VPN: vilken gräns skyddar vad

En fältutrustning öppnar en anslutning till en tjänst och designfrågan kommer som ett val mellan VPN och TLS. Den ramen är fel, eftersom de två gör olika jobb. TLS autentiserar applikationens slutpunkt och skyddar samtalet; medan en VPN styr nåbarheten och skyddar paket mellan parter. Följ anslutningen från enheten och utåt, och varje lager har sitt eget svar.

Om du inte kan säga var TLS slutar kan du inte säga vad applikationen faktiskt litar på.

Ta reda på var TLS faktiskt slutar

Börja vid enhetens applikation och följ anslutningen till den process som slutför handskakningen. Om en proxy avslutar TLS före stormaskinen slutar den skyddade vägen vid proxyn. Det återstående hoppet behöver sitt eget dokumenterade skydd.

Att kalla det hela vägen på en antagelse är hur en designgranskning godkänner en lucka. Rita slutpunkten och förtroendeankaret i samma diagram.

TLS bär förfrågningar och svar i båda riktningarna, så en tvåvägsapplikation behöver inte i sig en VPN i stället för TLS. Det omvända är också sant: en driftsättning kan fortfarande behöva en VPN för andra protokoll på samma enhet.

Bestäm vad enheten måste autentisera

Konfigurera validering av serveridentitet och de avsedda förtroenderötterna. Om varje enhet måste bevisa sin egen identitet, välj en stödd klientautentiseringsmodell och registrera ett eget certifikat per enhet. Delade autentiseringsuppgifter gör en enda stulen enhet till ett problem för hela flottan.

Planera nyckelskydd, förnyelse, återkallelse och återställning före leverans. En enhet i fält som inte kan registreras om efter en misslyckad förnyelse blir ett servicebesök, och den kostnaden formar designen mer än handskakningen.

Använd ett stött bibliotek och aktuella riktlinjer. Moderna riktlinjer för TLS-driftsättning förbjuder förhandling av TLS 1.0 och 1.1, och en TLSv1-referens i en gammal designanteckning är inte ett krav.

Stäng när handskakningen misslyckas

En misslyckad handskakning eller identitetskontroll får inte tyst falla tillbaka till det ursprungliga klartextprotokollet. Det fallet är den sårbarhet som TLS-arbetet skulle stänga. Gör felet synligt för enhetens operatör och för tjänsten, och kräv den skyddade kanalen för känsliga operationer. Låt sedan applikationens auktorisering avgöra vad en autentiserad enhet får göra.

Definiera anslutningens livslängd, inramning, tidsgränser och beteende vid nytt försök som en del av avtalet. Kryptering gör inte ett upprepat kommando säkert, och ett nytt försök efter en osäker tidigare operation kräver ett svar på applikationsnivå.

Skriv ner återfallsregeln. ”Den ansluter igen utan TLS om handskakningen misslyckas” är ett designbeslut, och det bör vara uttalat.

Ge VPN:en bara det jobb den kan göra

En VPN kan begränsa nåbarheten och skydda paket till sin egen part. TLS skyddar applikationens förhållande till den valda slutpunkten. Deras slutpunkter kan skilja sig, och ingen av dem säkrar slutpunktens lagrade data eller administrativa åtkomst.

Mät handskakningskostnad, jämn meddelandetrafik och återanslutning på den faktiska enheten i stället för att anta att en mekanism är snabbare. Testa sedan de fyra fall som betyder något: det avsedda utbytet, en felaktig serveridentitet, en obehörig enhet och en återanslutning efter en osäker operation. Notera resultatet för varje fall, inklusive felet enheten visar.