Feltudstyr, TLS og VPN: hvilken grænse beskytter hvad

En enhed i marken åbner en forbindelse til en tjeneste, og designspørgsmålet kommer som et valg mellem VPN og TLS. Den ramme er forkert, fordi de to gør forskellige ting. TLS autentificerer applikationens endepunkt og beskytter samtalen; mens en VPN styrer tilgængeligheden og beskytter pakker mellem parter. Følg forbindelsen fra enheden og udad, og hvert lag har sit eget svar.

Hvis du ikke kan sige, hvor TLS afsluttes, kan du ikke sige, hvad applikationen faktisk stoler på.

Find ud af, hvor TLS faktisk afsluttes

Start ved enhedens applikation og følg forbindelsen til den proces, der fuldfører håndtrykket. Hvis en proxy afslutter TLS før mainframen, slutter den beskyttede vej ved proxyen. Det resterende hop har brug for sin egen dokumenterede beskyttelse.

At kalde det ende-til-ende på en antagelse er, hvordan en designgennemgang godkender et hul. Tegn afslutningspunktet og tillidsankeret på samme diagram.

TLS bærer anmodninger og svar i begge retninger, så en tovejsapplikation har ikke i sig selv brug for en VPN i stedet for TLS. Det omvendte er også sandt: en udrulning kan stadig have brug for en VPN til andre protokoller på samme enhed.

Beslut, hvad enheden skal autentificere

Konfigurer validering af serveridentitet og de tilsigtede tillidsrødder. Hvis hver enhed skal bevise sin egen identitet, vælg en understøttet klientautentificeringsmodel, og tilmeld en særskilt legitimation pr. enhed. Delte legitimationer gør én stjålet enhed til et problem for hele flåden.

Planlæg nøglebeskyttelse, fornyelse, tilbagekaldelse og genopretning før forsendelse. En enhed i marken, der ikke kan tilmeldes igen efter en mislykket fornyelse, bliver et servicebesøg, og den omkostning former designet mere end håndtrykket.

Brug et understøttet bibliotek og aktuelle retningslinjer. Moderne retningslinjer for TLS-udrulning forbyder forhandling af TLS 1.0 og 1.1, og en TLSv1-reference i et gammelt designnotat er ikke et krav.

Luk, når håndtrykket fejler

Et mislykket håndtryk eller identitetstjek må ikke stille falde tilbage til den oprindelige klartekstprotokol. Det tilbagefald er den sårbarhed, som TLS-arbejdet skulle lukke. Gør fejlen synlig for enhedens operatør og for tjenesten, og kræv den beskyttede kanal til følsomme handlinger. Lad derefter applikationsautorisationen afgøre, hvad en autentificeret enhed må gøre.

Definér forbindelsens levetid, indramning, timeouts og genforsøgsadfærd som en del af kontrakten. Kryptering gør ikke en gentagen kommando sikker, og et genforsøg efter en usikker tidligere handling kræver et svar på applikationsniveau.

Skriv tilbagefaldsreglen ned. “Den genopretter forbindelsen uden TLS, hvis håndtrykket fejler” er en designbeslutning, og den bør være eksplicit.

Giv kun VPN’en det arbejde, den kan udføre

En VPN kan begrænse tilgængeligheden og beskytte pakker til sin egen part. TLS beskytter applikationens forhold til det valgte endepunkt. Deres afslutningspunkter kan være forskellige, og ingen af dem sikrer endepunktets lagrede data eller administrative adgang.

Mål håndtryksomkostning, stabil meddelelsesudveksling og genopkobling på den faktiske enhed i stedet for at antage, at én mekanisme er hurtigere. Test derefter de fire tilfælde, der betyder noget: den tilsigtede udveksling, en forkert serveridentitet, en uautoriseret enhed og en genopkobling efter en usikker handling. Noter resultatet for hvert tilfælde, inklusive den fejl, enheden viser.