Urządzenie terenowe, TLS i VPN: która granica co chroni

Urządzenie terenowe otwiera połączenie z usługą, a pytanie projektowe przychodzi jako wybór między VPN a TLS. Ta rama jest błędna, bo oba robią różne rzeczy. TLS uwierzytelnia punkt końcowy aplikacji i chroni rozmowę; natomiast VPN kontroluje osiągalność i chroni pakiety między partnerami. Przejdź połączenie od urządzenia na zewnątrz, a każda warstwa ma własną odpowiedź.

Jeśli nie potrafisz powiedzieć, gdzie kończy się TLS, nie potrafisz powiedzieć, czemu aplikacja naprawdę ufa.

Znajdź, gdzie TLS naprawdę się kończy

Zacznij od aplikacji urządzenia i przejdź połączenie do procesu, który kończy uzgadnianie. Jeśli proxy kończy TLS przed mainframe’em, chroniona ścieżka kończy się na proxy. Pozostały skok potrzebuje własnej udokumentowanej ochrony.

Nazwanie tego end-to-end na podstawie założenia to sposób, w jaki przegląd projektu zatwierdza lukę. Narysuj punkt zakończenia i kotwicę zaufania na tym samym schemacie.

TLS przenosi żądania i odpowiedzi w obu kierunkach, więc aplikacja dwukierunkowa nie potrzebuje z natury VPN zamiast TLS. Jest też odwrotnie: wdrożenie może nadal potrzebować VPN dla innych protokołów na tym samym urządzeniu.

Zdecyduj, co urządzenie musi uwierzytelnić

Skonfiguruj walidację tożsamości serwera i zamierzone korzenie zaufania. Jeśli każde urządzenie musi udowodnić własną tożsamość, wybierz obsługiwany model uwierzytelniania klienta i zarejestruj oddzielne poświadczenie dla każdego urządzenia. Wspólne poświadczenia zamieniają jedno skradzione urządzenie w problem całej floty.

Zaplanuj ochronę kluczy, odnawianie, unieważnianie i odzyskiwanie przed wysyłką. Urządzenie w terenie, którego nie można ponownie zarejestrować po nieudanym odnowieniu, staje się wizytą w terenie, a ten koszt kształtuje projekt bardziej niż uzgadnianie.

Używaj obsługiwanej biblioteki i aktualnych wytycznych. Nowoczesne wytyczne wdrażania TLS zabraniają negocjowania TLS 1.0 i 1.1, a odniesienie do TLSv1 w starej nocie projektowej nie jest wymaganiem.

Zamknij, gdy uzgadnianie zawiedzie

Nieudane uzgadnianie lub nieudana kontrola tożsamości nie może po cichu wracać do pierwotnego protokołu tekstu jawnego. Ten powrót to luka, którą praca nad TLS miała zamknąć. Uczyń awarię widoczną dla operatora urządzenia i dla usługi oraz wymagaj chronionego kanału dla operacji wrażliwych. Potem pozwól autoryzacji aplikacji zdecydować, co może robić uwierzytelnione urządzenie.

Zdefiniuj czas życia połączenia, ramkowanie, limity czasu i zachowanie przy ponowieniu jako część umowy. Szyfrowanie nie czyni powtarzanego polecenia bezpiecznym, a ponowienie po niepewnej wcześniejszej operacji wymaga odpowiedzi na poziomie aplikacji.

Zapisz regułę powrotu. „Ponownie łączy się bez TLS, jeśli uzgadnianie zawiedzie” to decyzja projektowa i powinna być jawna.

Daj VPN tylko tę pracę, którą może wykonać

VPN może ograniczyć osiągalność i chronić pakiety do własnego partnera. TLS chroni relację aplikacji z wybranym punktem końcowym. Ich punkty zakończenia mogą się różnić i żaden nie zabezpiecza przechowywanych danych punktu końcowego ani dostępu administracyjnego.

Mierz koszt uzgadniania, stałą wymianę komunikatów i ponowne połączenie na rzeczywistym urządzeniu, zamiast zakładać, że jeden mechanizm jest szybszy. Następnie przetestuj cztery przypadki, które mają znaczenie: zamierzoną wymianę, błędną tożsamość serwera, nieupoważnione urządzenie i ponowne połączenie po niepewnej operacji. Zapisz wynik każdego przypadku, w tym błąd, który pokazuje urządzenie.