Veldapparaat, TLS en VPN: welke grens beschermt wat

Een veldapparaat opent een verbinding met een dienst en de ontwerpvraag komt als een keuze tussen VPN en TLS. Die framing is onjuist, omdat beide verschillend werk doen. TLS authenticeert het applicatie-eindpunt en beschermt het gesprek; terwijl een VPN de bereikbaarheid beheert en pakketten tussen peers beschermt. Volg de verbinding vanaf het apparaat naar buiten en elke laag heeft zijn eigen antwoord.

Als u niet kunt zeggen waar TLS eindigt, kunt u niet zeggen waarop de applicatie werkelijk vertrouwt.

Ontdek waar TLS werkelijk eindigt

Begin bij de applicatie van het apparaat en volg de verbinding tot het proces dat de handshake voltooit. Als een proxy TLS beëindigt vóór het mainframe, eindigt het beschermde pad bij de proxy. De resterende sprong heeft zijn eigen gedocumenteerde bescherming nodig.

Dat end-to-end noemen op basis van een aanname is hoe een ontwerpbeoordeling een gat goedkeurt. Teken het eindpunt en het vertrouwensanker in hetzelfde diagram.

TLS transporteert verzoeken en antwoorden in beide richtingen, dus een bidirectionele applicatie heeft niet inherent een VPN nodig in plaats van TLS. Het omgekeerde is ook waar: een uitrol kan nog steeds een VPN nodig hebben voor andere protocollen op hetzelfde apparaat.

Bepaal wat het apparaat moet authenticeren

Configureer validatie van de serveridentiteit en de beoogde vertrouwenswortels. Als elk apparaat zijn eigen identiteit moet bewijzen, kies dan een ondersteund clientauthenticatiemodel en registreer per apparaat een afzonderlijke referentie. Gedeelde referenties maken van één gestolen apparaat een probleem voor de hele vloot.

Plan sleutelbescherming, vernieuwing, intrekking en herstel vóór verzending. Een apparaat in het veld dat na een mislukte vernieuwing niet opnieuw kan worden geregistreerd, wordt een bezoek ter plaatse, en die kosten vormen het ontwerp meer dan de handshake.

Gebruik een ondersteunde bibliotheek en actuele richtlijnen. Moderne richtlijnen voor TLS-implementatie verbieden het onderhandelen over TLS 1.0 en 1.1, en een verwijzing naar TLSv1 in een oude ontwerpnotitie is geen vereiste.

Sluit wanneer de handshake mislukt

Een mislukte handshake of identiteitscontrole mag niet stilzwijgend terugvallen op het oorspronkelijke platte-tekstprotocol. Die terugval is de kwetsbaarheid die het TLS-werk moest dichten. Maak het falen zichtbaar voor de operator van het apparaat en voor de dienst, en eis het beschermde kanaal voor gevoelige handelingen. Laat daarna de applicatieautorisatie beslissen wat een geauthenticeerd apparaat mag doen.

Definieer de levensduur van de verbinding, de framing, de time-outs en het gedrag bij herhaling als onderdeel van het contract. Versleuteling maakt een herhaald commando niet veilig, en een nieuwe poging na een onzekere eerdere handeling vereist een antwoord op applicatieniveau.

Schrijf de terugvalregel op. „Het maakt opnieuw verbinding zonder TLS als de handshake mislukt“ is een ontwerpbeslissing, en die zou expliciet moeten zijn.

Geef de VPN alleen het werk dat hij kan doen

Een VPN kan de bereikbaarheid beperken en pakketten tot zijn eigen peer beschermen. TLS beschermt de relatie van de applicatie met het gekozen eindpunt. Hun eindpunten kunnen verschillen, en geen van beide beveiligt de opgeslagen gegevens van het eindpunt of de administratieve toegang.

Meet de kosten van de handshake, stabiel berichtenverkeer en herverbinding op het werkelijke apparaat in plaats van aan te nemen dat het ene mechanisme sneller is. Test vervolgens de vier gevallen die ertoe doen: de bedoelde uitwisseling, een verkeerde serveridentiteit, een niet-geautoriseerd apparaat en een herverbinding na een onzekere handeling. Noteer het resultaat voor elk geval, inclusief de fout die het apparaat toont.