Zanim zastąpisz IPsec przez Shadowsocks, wypisz brakujące zadania

Trzy usługi, jeden tunel: aplikacja webowa, baza danych i udział plików. Ktoś proponuje zamienić IPsec na Shadowsocks, bo łatwiej go utrzymać. Następująca debata o szyfrowaniu mija się z sednem, bo tunel wykonuje kilka zadań naraz i tylko jedno z nich dotyczy szyfrów. Wypisz te zadania, zanim zaczniesz porównywać produkty. Lista jest krótka i każdy punkt może unieważnić zmianę.

Zacznij od tego, jak ruch jest przechwytywany

Protokół ma dwie połowy. Lokalny komponent przyjmuje połączenie, szyfruje strumień zaczynający się adresem docelowym i wysyła go do zdalnego komponentu. Zdalna połowa otwiera połączenie do tego celu i przekazuje bajty. UDP zachowuje ten sam kształt z datagramami. To przekazywanie dla strumieni, które przechwytuje, i nic nie mówi o strumieniach, których nie przechwytuje. Aplikacja, która jawnie mówi proxy, jest łatwa; wszystko inne potrzebuje adaptera lub reguł routingu, żeby w ogóle zostać przechwycone.

Udokumentuj sposób przechwytywania dla każdej aplikacji, zanim porównasz cokolwiek innego. Ruch nieprzechwycony wychodzi zwykłą drogą i nikt tego nie zauważa, dopóki jakaś usługa nie zacznie zachowywać się inaczej poza biurem.

Nazwij każdy cel i każdy protokół

Zdalna połowa musi docierać do każdej wewnętrznej usługi. Działająca sesja szyfrowana do tego hosta nie dodaje trasy z niego do bazy danych i nie powoduje rozwiązywania wewnętrznych nazw na kliencie. Wypisz adresy, porty i protokoły, zamiast pisać, że LAN jest uwzględniony.

Dodaj przypadki, które psują uporządkowane projekty: wewnętrzny DNS, aplikacje ignorujące ustawienia proxy i każdy strumień, który musi być zainicjowany z serwera w stronę klienta. Każdy z nich wymaga wyraźnego ustalenia, a nie założenia.

Szyfrowanie to nie autoryzacja

Udokumentowane metody AEAD w Shadowsocks zapewniają szyfrowanie z uwierzytelnianiem, więc odrzucanie całej rodziny jako niebezpiecznej jest błędem. Równie błędne jest pozwolenie, by ten fakt odpowiadał na pytanie o dostęp. Ktoś musi zdecydować, kto dociera do której usługi, jak odbiera się dostęp, gdy człowiek odchodzi, gdzie przechowuje się sekrety i który komponent egzekwuje granicę. Jeden wspólny sekret daje każdemu posiadaczowi ten sam zasięg, a odejście jednej osoby staje się rotacją dla wszystkich.

Przyłóż obecną konfigurację IPsec do tej samej miary. Jej etykieta nie dowodzi, że reguły są poprawne, a porównanie wypolerowanej wersji jednego projektu z mglistą wersją drugiego niczego nie rozstrzyga.

Wypisz kontrole, które istnieją dziś po obu stronach, a potem oceń, z jakimi lukami możesz żyć.

Policz pracę eksploatacyjną

Każda zamiana potrzebuje właściciela pakietów klienta, aktualizacji serwera, rotacji poświadczeń i obsługi awarii. Zauważ, co robi każda aplikacja, gdy tunel jest niedostępny: zawodzi, ponawia przez ścieżkę lokalną albo czeka. To zachowanie wynika z wdrożenia, a nie z nazwy protokołu.

Dla jednej aplikacji webowej wąskie proxy może wystarczyć. Dla dostępu do całej sieci z uprawnieniami na osobę dodatkowe części zwykle kosztują więcej niż zastąpiony tunel.

Decyzja nie dotyczy tego, który produkt brzmi bezpieczniej. Dotyczy tego, który projekt kończy wymienione zadania z kontrolami, które zespół naprawdę utrzyma.