Wspólne CA, osobne drzwi: jedna usługa na plik dopuszczenia

Certyfikat, który waliduje się wobec wspólnego organu, przeszedł test zaufania, a nie test członkostwa. Te dwie decyzje są często łączone, ponieważ obie zachodzą w momencie połączenia, a połączenie pozostaje niewidoczne, dopóki do usługi nie zostanie dopuszczony ktoś, kto nie powinien tam być. Rozwiązaniem nie jest drugi organ; to druga decyzja, podejmowana dla każdej usługi i zapisywana tam, gdzie demon ją czyta. Trzymaj oba osobno, a większość zamieszania w tej dziedzinie znika.

Zaufany łańcuch nie mówi nic o członkostwie w usłudze

Dwie usługi mogą akceptować tę samą hierarchię wystawcy i mimo to mieć różne populacje. Jeden laptop należy do pierwszej i nie może dotrzeć do drugiej, podczas gdy inni klienci tej samej hierarchii naprawdę tam należą. Usunięcie organu z tej usługi zablokowałoby wszystkich, którzy używają jej legalnie, więc praca polega na dopuszczeniu, a nie na zaufaniu.

Pomaga wyobrazić sobie dwa zamki na jednych drzwiach. Certyfikat otwiera zamek zewnętrzny, a decyzja dla usługi otwiera wewnętrzny; żaden nie zastępuje drugiego. Usługa mająca tylko zamek zewnętrzny w ogóle nie egzekwuje członkostwa, jedynie uwierzytelnia. Zapisz obie decyzje, zanim cokolwiek zmienisz, ponieważ polityki, która istnieje tylko w postaci działającego połączenia, nie da się zaudytować. To, co następuje, dotyczy zamka wewnętrznego.

Zamień opcjonalne nadpisania w bramę dopuszczenia

Katalog konfiguracji klienta jest zwykle udogodnieniem: pliki w nim nadpisują ustawienia klientów, których dotyczą, a klient bez pliku po prostu działa z wartościami domyślnymi serwera. Jedna dyrektywa zamienia to udogodnienie w bramę, tak że brakujący plik oznacza odrzucenie połączenia.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Wydanie społecznościowe OpenVPN 2.6 ccd-exclusive dokumentuje na swojej stronie podręcznika dokładnie ten warunek, a wyszukiwanie nazwanego pliku zależy od efektywnej tożsamości klienta. Inne kompilacje i serwery zarządzane przez produkty mogą się różnić, więc potwierdź zainstalowaną wersję, zanim zaufasz tej samej semantyce gdzie indziej.

Traktuj powyższą ścieżkę jako przykład i sprawdź faktycznie wdrożony układ, zamiast tworzyć katalog wymyślony przez poradnik. Zostaw istniejące kontrole certyfikatów, kontrole tożsamości serwera i uwierzytelnianie konta dokładnie takie, jakie były, ponieważ fragment dodaje warunek i niczego nie usuwa. Przygotuj zmianę przed produkcją, ponieważ odmowa podniesiona w niewłaściwym miejscu wygląda jak awaria certyfikatu i kieruje dochodzenie do organu. Następnie potwierdź, że wpis w logu dla odrzuconego klienta wymienia brakujący plik konfiguracji, a nie łańcuch.

Jeden katalog na usługę, a nie jedna wspólna lista

Członkostwo należy do usługi, która je egzekwuje, więc każda usługa trzyma własny katalog i własne pliki. Wskazanie dwóch usług na jedną listę sprawia, że dzielą członkostwo niezależnie od tego, czy ktoś tego chciał, czy nie, a wynikająca z tego zmiana jest trudna do prześledzenia do decyzji. Wspólny organ może pozostać wspólny; pliki dopuszczenia nie mogą. Trzymanie ich osobno oznacza też, że błąd w jednej usłudze nie może po cichu rozszerzyć innej.

Wpis DEFAULT to przypadek, który wprowadza ludzi w błąd. Zapewnia ustawienia zapasowe, gdy nazwany plik nie zostanie znaleziony, ale nie jest to nazwany plik wymagany przez bramę, więc nie może sam dopuścić klienta. Przetestuj klienta, który nie ma żadnego wpisu, i potwierdź odmowę; jeśli ten klient zostanie dopuszczony, stosowane jest ustawienie zapasowe i ccd-exclusive nie obowiązuje w tej instancji.

Efektywna tożsamość decyduje, który plik jest czytany

Wyszukiwanie używa tożsamości, którą klient faktycznie się uwierzytelnił, zwykle nazwy powszechnej certyfikatu. Gdy serwer weryfikuje też nazwę użytkownika i hasło i mapuje tę nazwę na nazwę powszechną, plik musi zamiast tego odpowiadać uwierzytelnionej nazwie użytkownika. Rozbieżność pozostawia katalog pełen wiarygodnych nazw plików, które nigdy nie są wybierane.

Czytanie to druga połowa. Demon zwykle zrzeka się uprawnień po starcie, więc zredukowane konto potrzebuje dostępu do odczytu katalogu i każdego wpisu w nim. Klienci nie mogą móc tworzyć własnego wpisu przez żadną ścieżkę z prawem zapisu, ponieważ samoobsługowe dopuszczenie całkowicie niweczy mechanizm. Sprawdź uprawnienia montowania i udostępniania, a nie tylko tryb pliku, ponieważ katalog, który wygląda na zamknięty dla jednego konta, może być otwarty dla innego. Następnie potwierdź, którego konta naprawdę używa działający proces, a nie którego konta dotyczy plik unit. Oba są takie same tylko wtedy, gdy nic innego ich nie zmieniło.

Obserwuj odmowę, dopuszczenie i odwołanie osobno

Wypróbuj tożsamość należącą do usługi i potwierdź, że się łączy. Wypróbuj ważny certyfikat bez wpisu i potwierdź, że jest odrzucany. Wypróbuj tożsamość dopuszczoną do drugiej usługi i potwierdź, że nie jest tu dopuszczona. Zanotuj instancję usługi i efektywną tożsamość obok każdego wyniku, ponieważ wyniku bez tego kontekstu nikt inny nie odtworzy.

Wycofanie to osobna operacja od unieważnienia. Edycja pliku dopuszczenia usuwa uprawnienie do jednej usługi, podczas gdy tożsamość pozostaje ważna wszędzie indziej, natomiast przejęty klucz wymaga reakcji unieważnienia w organizacji. Zdecyduj z góry, co dzieje się z już ustanowionymi sesjami, ponieważ ani edycja katalogu, ani lista unieważnień nie kończy ich same z siebie.

Dopuszczenie to także tylko pierwsza brama. Dołączenie do usługi nie mówi nic o podsieciach, bazach danych ani interfejsach zarządzania za nią, a tę politykę zasobów trzeba napisać i przetestować osobno.