Terenski uređaj, TLS i VPN: koja granica štiti šta
Terenskom uređaju treba autentificirani aplikacijski kanal, a ne samo mrežni pristup. Utvrdite gdje TLS završava i odlučite šta se dešava kad ne uspije.
Terenski uređaj otvara vezu prema servisu, a pitanje dizajna dolazi kao izbor između VPN-a i TLS-a. Taj okvir je pogrešan, jer njih dvoje rade različite poslove. TLS autentificira aplikacijsku krajnju točku i štiti razgovor; a VPN kontrolira dostupnost i štiti pakete između vršnjaka. Prođite vezu od uređaja prema van i svaki sloj ima svoj odgovor.
Ako ne možete reći gdje TLS završava, ne možete reći u šta aplikacija zapravo vjeruje.
Nađite gdje TLS zapravo završava
Počnite od aplikacije na uređaju i pratite vezu do procesa koji dovršava rukovanje. Ako proxy završava TLS prije mainframea, zaštićeni put završava na proxyju. Preostali skok treba vlastitu dokumentiranu zaštitu.
Nazvati to kraj-do-kraja po pretpostavci je način na koji pregled dizajna odobrava prazninu. Nacrtajte točku završetka i sidro povjerenja na istoj shemi.
TLS prenosi zahtjeve i odgovore u oba smjera, pa dvosmjerna aplikacija sama po sebi ne treba VPN umjesto TLS-a. Vrijedi i obrnuto: postavljanje može još trebati VPN za druge protokole na istom uređaju.
Odlučite šta uređaj mora autentificirati
Postavite provjeru identiteta poslužitelja i predviđene korijene povjerenja. Ako svaki uređaj mora dokazati vlastiti identitet, odaberite podržani model autentifikacije klijenta i registrirajte zasebne akreditacije za svaki uređaj. Dijeljene akreditacije pretvaraju jedan ukradeni uređaj u problem cijele flote.
Planirajte zaštitu ključeva, obnavljanje, opoziv i oporavak prije isporuke. Uređaj na terenu koji se ne može ponovno registrirati nakon neuspjelog obnavljanja postaje posjet na terenu, a taj trošak oblikuje dizajn više od rukovanja.
Koristite podržanu biblioteku i aktualne smjernice. Suvremene smjernice za postavljanje TLS-a zabranjuju pregovaranje TLS-a 1.0 i 1.1, a pozivanje na TLSv1 u staroj bilješci o dizajnu nije zahtjev.
Zatvorite se kad rukovanje ne uspije
Neuspjelo rukovanje ili provjera identiteta ne smiju tiho pasti natrag na izvorni protokol čistog teksta. Taj povratak je ranjivost koju je rad na TLS-u trebao zatvoriti. Učinite neuspjeh vidljivim operatoru uređaja i servisu te zahtijevajte zaštićeni kanal za osjetljive operacije. Zatim neka autorizacija aplikacije odluči šta autentificirani uređaj smije raditi.
Definirajte životni vijek veze, uokvirivanje, vremenske rokove i ponašanje pri ponovnom pokušaju kao dio ugovora. Enkripcija ne čini ponovljenu naredbu sigurnom, a ponovni pokušaj nakon neizvjesne prethodne operacije traži odgovor na razini aplikacije.
Zapišite pravilo povratka. “Ponovno se spaja bez TLS-a ako rukovanje ne uspije” je dizajnerska odluka i treba biti izričita.
Dajte VPN-u samo posao koji može obaviti
VPN može ograničiti dostupnost i zaštititi pakete do svog vršnjaka. TLS štiti odnos aplikacije s odabranom krajnjom točkom. Njihove točke završetka mogu se razlikovati i nijedna ne štiti pohranjene podatke krajnje točke ni administrativni pristup.
Mjerite trošak rukovanja, ustaljeno razmjenjivanje poruka i ponovno povezivanje na stvarnom uređaju umjesto da pretpostavljate da je jedan mehanizam brži. Zatim testirajte četiri slučaja koja su važna: predviđenu razmjenu, pogrešan identitet poslužitelja, neovlašteni uređaj i ponovno povezivanje nakon neizvjesne operacije. Zabilježite rezultat za svaki slučaj, uključujući grešku koju uređaj pokazuje.