Välisseade, TLS ja VPN: milline piir mida kaitseb

Välisseade avab ühenduse teenusega ja projekteerimisküsimus tuleb valikuna VPN-i ja TLS-i vahel. See raamistik on vale, sest mõlemad teevad erinevat tööd. TLS autendib rakenduse lõpp-punkti ja kaitseb vestlust; samas kui VPN kontrollib kättesaadavust ja kaitseb pakette võrdsete vahel. Jälgige ühendust seadmest väljapoole ja igal kihil on oma vastus.

Kui te ei oska öelda, kus TLS lõpeb, ei oska te öelda, mida rakendus tegelikult usaldab.

Leidke, kus TLS tegelikult lõpeb

Alustage seadme rakendusest ja jälgige ühendust protsessini, mis lõpetab kätluse. Kui puhverserver lõpetab TLS-i enne suurarvutit, lõpeb kaitstud tee puhverserveri juures. Ülejäänud hüpe vajab oma dokumenteeritud kaitset.

Selle oletuse põhjal otsast-otsani nimetamine on viis, kuidas projekteerimise ülevaatus lünga heaks kiidab. Joonistage lõpp-punkt ja usalduse ankur samale skeemile.

TLS edastab päringuid ja vastuseid mõlemas suunas, seega kahesuunalisel rakendusel ei ole olemuslikult vaja VPN-i TLS-i asemel. Tõsi on ka vastupidine: juurutus võib sama seadme teiste protokollide jaoks endiselt VPN-i vajada.

Otsustage, mida peab seade autentima

Seadistage serveri identiteedi valideerimine ja kavandatud usaldusjuured. Kui iga seade peab tõestama oma identiteeti, valige toetatud kliendi autentimise mudel ja registreerige iga seadme jaoks eraldi volitus. Jagatud volitused muudavad ühe varastatud seadme kogu pargi probleemiks.

Planeerige võtmete kaitse, uuendamine, tühistamine ja taastamine enne tarnet. Põllul olev seade, mida ei saa ebaõnnestunud uuendamise järel uuesti registreerida, muutub kohapealseks visiidiks ja see kulu kujundab projekti rohkem kui kätlus.

Kasutage toetatud teeki ja kehtivaid juhiseid. Kaasaegsed TLS-i juurutamise juhised keelavad TLS 1.0 ja 1.1 läbirääkimise ning viide TLSv1-le vanas projekteerimismärkmes ei ole nõue.

Sulgege, kui kätlus ebaõnnestub

Ebaõnnestunud kätlus ega identiteedikontroll ei tohi vaikselt langeda tagasi algse avatud teksti protokolli. See tagasilangus on haavatavus, mille TLS-i töö pidi sulgema. Tehke ebaõnnestumine nähtavaks seadme operaatorile ja teenusele ning nõudke tundlike toimingute jaoks kaitstud kanalit. Seejärel laske rakenduse autoriseerimisel otsustada, mida autenditud seade tohib teha.

Määratlege ühenduse eluiga, raamimine, ajapiirid ja korduskatse käitumine lepingu osana. Krüpteerimine ei tee korduvat käsku turvaliseks ja ebakindla eelneva toimingu järel vajab korduskatse rakendustasandil vastust.

Kirjutage tagasilanguse reegel üles. „See ühendub uuesti ilma TLS-ita, kui kätlus ebaõnnestub“ on projekteerimisotsus ja see peaks olema sõnaselge.

Andke VPN-ile ainult see töö, mida see suudab teha

VPN saab piirata kättesaadavust ja kaitsta pakette oma võrdseni. TLS kaitseb rakenduse suhet valitud lõpp-punktiga. Nende lõpp-punktid võivad erineda ja kumbki ei kaitse lõpp-punkti salvestatud andmeid ega haldusjuurdepääsu.

Mõõtke kätluse kulu, püsivat sõnumivahetust ja taastumist tegelikul seadmel, selle asemel et eeldada, et üks mehhanism on kiirem. Seejärel testige nelja olulist juhtumit: kavandatud vahetus, vale serveri identiteet, volitamata seade ja taastamine ebakindla toimingu järel. Kirjutage iga juhtumi tulemus üles, sealhulgas viga, mida seade näitab.