Scentralizuj dostęp partnerów przez VPN bez łączenia partnerów

Propozycja jest rozsądna: pięć tuneli partnerów rozproszonych po kilkunastu laptopach, pięć zestawów wersji klienta, pięć skryptów help desku i jeden inżynier, który wie, jak to wszystko do siebie pasuje. Przeniesienie ich do kontrolowanej warstwy dostępu porządkuje rozproszenie punktów końcowych. Jednocześnie tworzy nowy obiekt w architekturze — wspólną usługę dostępu, która teraz wymaga własnego modelu autoryzacji; a awaria, której wszyscy nie doceniają, to centralne urządzenie z włączonymi wszystkimi tunelami, które po cichu staje się siecią tranzytową między organizacjami, które nigdy nie zgodziły się być sąsiadami. To ryzyko jest decyzją projektową, a nie czymś, co sprzęt robi sam z siebie. Poniższa praca to sposób, w jaki zachowuję wygodę bez akceptowania przypadkowego efektu ubocznego.

Zacznij od umowy, którą każdy partner już podpisał

Przed jakąkolwiek konfiguracją potwierdź, że partner w ogóle dopuszcza wspólną bramę lub połączenie lokacji. Osobiste konto dostępu zdalnego, wymóg stanu urządzenia lub interaktywny przepływ MFA mogą nie dać się przenieść do bezobsługowego wspólnego tunelu, a łączenie pracowników za jedną skopiowaną tożsamością klienta to ten rodzaj skrótu, który przetrwa do audytu logów po stronie partnera. Dla każdego dozwolonego połączenia zapisz zakresy docelowe, prywatne domeny DNS, autoryzowane źródła wewnętrzne, właściciela uwierzytelniania i to, co ma się stać, gdy tunel zawiedzie. Poproś partnera o pisemne potwierdzenie wspólnego połączenia, wraz z zakresami źródłowymi, które zaakceptuje. Ustna zgoda zwykle zmienia znaczenie w tygodniu, w którym zmienia się ich zespół bezpieczeństwa.

Ten zapis jest rezultatem. Jeśli nie potrafisz go napisać dla jednego partnera, ten partner nie jest gotowy na centralizację.

Wyznaczaj trasy według kontekstu, nie tylko celu

Dwaj partnerzy w końcu użyją tego samego zakresu prywatnego, bo każda organizacja wybiera z tej samej przestrzeni RFC 1918. Jedna zwykła tablica routingu nie potrafi wybrać właściwego partnera tylko na podstawie adresu celu, więc nakładające się zakresy wymagają odrębnych kontekstów routingu lub innego uzgodnionego projektu. Model domeny przekazywania w RFC 4364 opisuje, dlaczego to rozdzielenie jest ważne, a wdrożenie nie musi uruchamiać MPLS, by wymagać tej samej właściwości od swojej platformy bramy.

Zadaj platformie wprost pytanie: czy dwóch partnerów może dzielić ten sam prefiks docelowy i nadal być rozróżnianych po tym, z jakiego kontekstu pracownika przyszła sesja? Jeśli odpowiedź brzmi nie, to ograniczenie kształtuje projekt bardziej niż jakakolwiek lista funkcji dostawcy.

Tam, gdzie odpowiedź brzmi tak, kontekst routingu staje się tym, co dokumentujesz i testujesz, bo jest niewidoczny w traceroute.

Zdecyduj, co wpisuje pracownik, a co loguje partner

Część pracy partnera pasuje do proxy aplikacji albo zdalnego obszaru roboczego otwieranego w kontekście tego partnera. Inna praca wymaga routowanego dostępu sieciowego z zatwierdzonego segmentu pracowników, a obie dają inne adresy źródłowe i inne ścieżki audytu po drugiej stronie. Wspólny tłumaczony adres źródłowy może spełnić listę dozwolonych, jednocześnie ukrywając, które urządzenie co zrobiło, więc zachowaj wiarygodne powiązanie pracownika z sesją i utrzymuj uwierzytelnianie aplikacji, zamiast traktować adres bramy jako tożsamość — co jest wygodne dokładnie do chwili, gdy partner zapyta, kto to zrobił.

Potem przejdź jedno realne zadanie ze strony pracownika: co klikają, o co są proszeni i co partner zobaczyłby, gdyby poprosił o wpis w logu. Jeśli tego przejścia nie da się powtórzyć, projekt nie jest skończony.

Wyraźnie odmów tranzytu między partnerami

Wspólny sprzęt nigdy nie powinien oznaczać wspólnego zaufania. Dodaj odmowę jako świadomą regułę z nazwanym właścicielem, a nie jako przypadek brakującej konfiguracji, i przetestuj ją w obu kierunkach żądaniem, które w innym razie by się powiodło. Test ma znaczenie, bo zezwolenie, którego po prostu nie ma, może przywrócić następny inżynier dodający trasę, by naprawić niepowiązaną skargę.

Zapisz odmowę w rekordzie partnera obok zezwoleń, żeby intencja przetrwała zmiany personelu.

Prowadź to jako wspólną usługę, a nie większy laptop

Odnawianie tuneli, rotacja poświadczeń, pojemność i wymiana bramy stają się teraz zmianami wspólnej usługi, co oznacza, że potrzebują harmonogramu i ścieżki komunikacji, których pojedyncze laptopy nigdy nie wymagały. Wygasający w sobotę certyfikat partnera to już nie awaria jednego użytkownika; to awaria wszystkich sesji tego partnera naraz.

Przyjmij warstwę tylko wtedy, gdy odrzucone żądanie między partnerami zawodzi dokładnie tak, jak zamierzono, a dozwolone żądanie pracownika dociera do właściwego celu z właściwego źródła. Usunięcie konfliktu laptopów przy zachowaniu nienaruszonej granicy każdego partnera to cały sens; projekt, w którym każdy prefiks zdalny jest osiągalny z każdego biurka, tylko przeniósł problem.

Prowadź małą tabelę: partner, kontekst, dozwolone zakresy i właściciel. To będzie pierwsza rzecz, o którą ktoś poprosi podczas incydentu.