Kampa aparato, TLS kaj VPN: kiu limo protektas kion

Kampa aparato malfermas konekton al servo, kaj la dezajna demando venas kiel elekto inter VPN kaj TLS. Tiu kadro estas malĝuŝta, ĉar la du faras malsamajn taskojn. TLS aŭtentigas la aplikaĵan finpunkton kaj protektas la konversacion; dum VPN regas atingeblon kaj protektas pakaĵojn inter samuloj. Sekvu la konekton de la aparato eksteren kaj ĉiu tavolo havas sian propran respondon.

Se vi ne povas diri, kie TLS finiĝas, vi ne povas diri, kion la aplikaĵo fakte fidas.

Trovu, kie TLS fakte finiĝas

Komencu ĉe la aparata aplikaĵo kaj sekvu la konekton ĝis la procezo, kiu finplenumas la manpremon. Se prokurilo finas TLS antaŭ la ĉefkomputilo, la protektita vojo finiĝas ĉe la prokurilo. La restanta salto bezonas sian propran dokumentitan protekton.

Nomi tion fin-al-fina per supozo estas kiel dezajna revizio aprobas breĉon. Desegnu la finpunkton kaj la fidoankron sur la sama diagramo.

TLS portas petojn kaj respondojn en ambaŭ direktoj, do dudirekta aplikaĵo ne nepre bezonas VPN anstataŭ TLS. La malo ankaŭ veras: starigo eble ankoraŭ bezonas VPN por aliaj protokoloj sur la sama aparato.

Decidu, kion la aparato devas aŭtentigi

Agordi validigon de servila identeco kaj la celitajn fidradikojn. Se ĉiu aparato devas pruvi sian propran identecon, elektu subtenatan modelon de klienta aŭtentigo kaj registru apartan legitimilon por ĉiu aparato. Kunhavataj legitimiloj transformas unu ŝtelitan aparaton en problemon por la tuta aro.

Planu ŝlosilprotekton, renovigon, revokon kaj restarigon antaŭ sendo. Aparato sur la kampo, kiu ne povas esti reregistrita post malsukcesa renovigo, fariĝas vojaĝo al la loko, kaj tiu kosto formas la dezajnon pli ol la manpremo.

Uzu subtenatan bibliotekon kaj aktualajn gvidliniojn. Modernaj gvidlinioj por TLS-starigo malpermesas intertrakti TLS 1.0 kaj 1.1, kaj referenco al TLSv1 en malnova dezajna noto ne estas postulo.

Fermu, kiam la manpremo malsukcesas

Malsukcesa manpremo aŭ identeckontrolo devas ne silente refali al la origina protokolo de klara teksto. Tiu refalo estas la vundebleco, kiun la laboro pri TLS devis fermi. Faru la malsukceson videbla por la aparata operatoro kaj por la servo, kaj postulu la protektitan kanalon por sentemaj operacioj. Poste lasu la aplikaĵan rajtigon decidi, kion aŭtentigita aparato rajtas fari.

Difinu la vivdaŭron de la konekto, enkadrigon, tempolimojn kaj konduton de reprovo kiel parton de la kontrakto. Ĉifrado ne faras ripetitan komandon sekura, kaj reprovo post necerta antaŭa operacio bezonas respondon je la aplikaĵa nivelo.

Skribu la refalan regulon. «Ĝi rekonektas sen TLS, se la manpremo malsukcesas» estas dezajna decido, kaj ĝi devus esti eksplicita.

Donu al VPN nur la taskon, kiun ĝi povas plenumi

VPN povas limigi atingeblon kaj protekti pakaĵojn al sia propra samulo. TLS protektas la rilaton de la aplikaĵo al la elektita finpunkto. Iliaj finpunktoj povas malsami, kaj neniu el ili sekurigas la konservitajn datumojn de la finpunkto aŭ la administran aliron.

Mezuru manpreman koston, stabilan mesaĝadon kaj rekonekton sur la reala aparato anstataŭ supozi, ke unu mekanismo estas pli rapida. Poste testu la kvar kazojn, kiuj gravas: la celitan interŝanĝon, malĝustan servilan identecon, neaŭtorizitan aparaton kaj rekonekton post necerta operacio. Notu la rezulton por ĉiu kazo, inkluzive de la eraro, kiun la aparato montras.