Terénní zařízení, TLS a VPN: která hranice co chrání

Terénní zařízení otevírá spojení ke službě a otázka designu přichází jako volba mezi VPN a TLS. Toto rámování je chybné, protože obě dělají různé věci. TLS autentizuje aplikační koncový bod a chrání konverzaci; zatímco VPN řídí dosažitelnost a chrání pakety mezi protějšky. Projděte spojení od zařízení směrem ven a každá vrstva má svou odpověď.

Pokud nedokážete říct, kde TLS končí, nedokážete říct, čemu aplikace ve skutečnosti důvěřuje.

Najděte, kde TLS skutečně končí

Začněte u aplikace v zařízení a sledujte spojení k procesu, který dokončuje handshake. Pokud proxy ukončuje TLS před mainfremem, chráněná cesta končí na proxy. Zbývající skok potřebuje vlastní zdokumentovanou ochranu.

Nazvat to end-to-end na základě předpokladu je způsob, jakým revize designu schválí mezeru. Nakreslete bod ukončení a kotvu důvěry do stejného diagramu.

TLS přenáší požadavky i odpovědi oběma směry, takže obousměrná aplikace nutně nepotřebuje VPN místo TLS. Platí to i opačně: nasazení může stále potřebovat VPN pro jiné protokoly na stejném zařízení.

Rozhodněte, co musí zařízení autentizovat

Nastavte ověřování identity serveru a zamýšlené kořeny důvěry. Pokud každé zařízení musí prokázat vlastní identitu, zvolte podporovaný model autentizace klienta a zaregistrujte samostatné přihlašovací údaje pro každé zařízení. Sdílené údaje promění jedno ukradené zařízení v problém celé flotily.

Naplánujte ochranu klíčů, obnovu, odvolání a zotavení před dodáním. Zařízení v terénu, které nelze po neúspěšné obnově znovu zaregistrovat, se změní ve výjezd a tato cena formuje design více než handshake.

Použijte podporovanou knihovnu a aktuální doporučení. Moderní doporučení pro nasazení TLS zakazují vyjednávání TLS 1.0 a 1.1 a odkaz na TLSv1 ve staré poznámce k designu není požadavek.

Zavřete se, když handshake selže

Neúspěšný handshake nebo kontrola identity nesmí tiše spadnout zpět na původní protokol s čistým textem. Tento návrat je zranitelnost, kterou měla práce na TLS uzavřít. Udělejte selhání viditelné pro operátora zařízení i pro službu a pro citlivé operace vyžadujte chráněný kanál. Potom nechte autorizaci aplikace rozhodnout, co smí autentizované zařízení dělat.

Definujte životnost spojení, rámování, časové limity a chování při opakování jako součást smlouvy. Šifrování nedělá opakovaný příkaz bezpečným a opakování po nejisté předchozí operaci potřebuje odpověď na úrovni aplikace.

Zapište pravidlo návratu. „Znovu se připojí bez TLS, pokud handshake selže“ je rozhodnutí o designu a mělo by být výslovné.

Dejte VPN jen tu práci, kterou zvládne

VPN může omezit dosažitelnost a chránit pakety ke svému protějšku. TLS chrání vztah aplikace k vybranému koncovému bodu. Jejich body ukončení se mohou lišit a ani jeden nezabezpečuje uložená data koncového bodu ani administrativní přístup.

Měřte cenu handshake, ustáleného zasílání zpráv a opětovného připojení na skutečném zařízení, místo abyste předpokládali, že jeden mechanismus je rychlejší. Potom otestujte čtyři případy, které mají význam: zamýšlenou výměnu, špatnou identitu serveru, neoprávněné zařízení a opětovné připojení po nejisté operaci. Zaznamenejte výsledek pro každý případ, včetně chyby, kterou zařízení zobrazí.