Dlaczego klucze serwera i dane uwierzytelniające użytkownika wymagają osobnych właścicieli

Klucz dowodzący, że twoja brama jest sobą, i poświadczenie mówiące, że dana osoba może dołączyć, są oba sekretami i tu podobieństwo się kończy. Jeden identyfikuje usługę wobec każdego klienta; drugi identyfikuje jednego użytkownika wobec tej usługi. Mieszanie ich oszczędza jeden krok przy konfiguracji i kosztuje popołudnie podczas incydentu, ponieważ odzyskiwanie każdego z nich to nie ta sama operacja. Rozdzielenie jest nudne w konfiguracji i pamiętne, gdy się je pominie.

Dwa sekrety, dwóch różnych właścicieli

Brama przechowuje klucz prywatny lub certyfikat, którego jedynym zadaniem jest udowodnienie jej tożsamości podczas uzgadniania połączenia. Klienci potrzebują pasującego materiału publicznego, aby go zweryfikować, i nigdy nie potrzebują połowy prywatnej. Ta asymetria umożliwia uwierzytelnianie serwera bez dawania każdemu użytkownikowi zdolności podszywania się pod serwer.

Materiał użytkownika idzie w przeciwnym kierunku. Prywatny klucz klienta, certyfikat klienta lub hasło dowodzą, że właśnie tej osobie lub temu urządzeniu przyznano dostęp. Oczekuje się, że będzie rozprowadzany, kopiowany między urządzeniami i ostatecznie odwołany.

WireGuard czyni rozdzielenie oczywistym, ponieważ każdy uczestnik ma parę kluczy: prywatny klucz serwera pozostaje na serwerze, a plik konfiguracyjny, który dajesz użytkownikowi, zawiera jego własny klucz prywatny oraz klucz publiczny serwera. Profil zawierający prywatny klucz serwera nie jest skrótem, to kompromitacja czekająca na udostępnienie pliku.

Trzy pytania, które decydują o rozdzieleniu

Zapytaj, kto musi móc przeczytać sekret, co ujawnienie pozwoliłoby zrobić atakującemu i czy naprawą jest jedno odwołanie, czy przebudowa usługi.

Jeśli użytkownik może go przeczytać i dowodzi on tożsamości bramy, odpowiedź na drugie pytanie brzmi, że atakujący może podszyć się pod twój serwer wobec każdego klienta — to najgorszy wynik, ponieważ klienci są zaprojektowani tak, by ufać tej tożsamości. Jeśli dowodzi tylko jednego użytkownika, ujawnienie daje temu użytkownikowi dostęp do jednego peera, a odwołanie jest rutynową operacją. Jeśli jest to klucz urzędu certyfikacji, ujawnienie jest gorsze od obu, ponieważ atakujący może tworzyć tożsamości, którym ufa każdy punkt końcowy.

Te trzy odpowiedzi dają regułę przechowywania: klucz CA żyje offline lub w sejfie, klucz bramy żyje na bramie, a klucze użytkowników żyją u użytkowników. Każdy układ, który dla wygody umieszcza wszystkie trzy w jednym katalogu, zamienił decyzję w wypadek.

Czego klient naprawdę potrzebuje

Klient potrzebuje publicznego certyfikatu lub publicznego klucza peera, materiału CA lub odcisku palca, któremu powinien zaufać, własnego klucza prywatnego i szczegółów punktu końcowego. Ta lista nie zawiera niczego, co należy do prywatnej tożsamości bramy.

Dokumentacja jest miejscem, w którym to przecieka. Poradnik, który mówi skopiuj katalog serwera i usuń to, czego nie potrzebujesz, już nauczył złego modelu, ponieważ plik pozostający po kroku usuwania rzadko jest przez kogokolwiek sprawdzany.

Odwołaj jednego użytkownika bez dotykania bramy

Ponieważ tożsamości użytkowników są wydawane osobno, można je osobno wycofać. Wdrożenie oparte na certyfikatach odwołuje certyfikat klienta i publikuje zaktualizowaną listę odwołań; wdrożenie WireGuard usuwa wpis peera z konfiguracji serwera. Żadna z tych operacji nie zmienia własnego klucza bramy.

Zachowaj rejestr wydań, inaczej nie będziesz wiedzieć, którą tożsamość wycofać. Arkusz kalkulacyjny wystarczy, pod warunkiem że wymienia osobę, urządzenie, numer seryjny lub klucz publiczny i datę, oraz pod warunkiem że ktoś się nim opiekuje po odejściu osoby, która go zbudowała.

Poniższe polecenia sprawdzają certyfikat klienta, a następnie odwołują go przez urząd w stylu OpenSSL, co jest przepływem, który opakowuje easy-rsa:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Opublikuj nową listę tam, gdzie klienci ją sprawdzają, inaczej odwołanie jest notatką w pliku, która nic nie zmienia. Jeśli twoja brama akceptuje certyfikaty klientów bez sprawdzania listy odwołań, powiedz to wprost, zamiast sugerować, że odwoływanie działa.

Trzymaj kopie zapasowe tak samo oddzielnie jak sekrety

Archiwum do odbudowy zgodnie z prawem zawiera klucz bramy i materiał CA, ponieważ bez nich przywracanie nie może odtworzyć usługi. Pakiet instalacyjny klienta nie może, i obu nie wolno przechowywać razem. Oznacz każde archiwum według tego, kto może je trzymać, a nie według daty utworzenia. To właśnie tę etykietę czyta zmęczony administrator o drugiej w nocy.

To rozróżnienie określa też, kto może pobrać każde z nich. Administrowanie bramą, wydawanie tożsamości użytkowników i czytanie kopii zapasowych to trzy różne uprawnienia, a osoba, która potrzebuje jednego, nie potrzebuje automatycznie pozostałych. Zapisz te uprawnienia, a następnie sprawdź je wobec tego, co faktycznie pozwala twoje przechowywanie, ponieważ dziedziczenie katalogów po cichu daje więcej, niż zakłada polityka.