Trzymaj klucz podpisywania CA OpenVPN poza /etc/openvpn

Dwa katalogi, które w poradniku wyglądają podobnie, wykonują zupełnie różne zadania. Jeden zawiera urząd certyfikacji: jego klucz prywatny, licznik numerów seryjnych i rejestr wszystkiego, co podpisał. Drugi zawiera to, czego demon potrzebuje do uruchomienia i obsługi klientów. Umieszczenie obu na tym samym hoście pod tym samym kontem jest wygodne na jedno popołudnie i kosztowne przez resztę życia wdrożenia, ponieważ demon działa wtedy obok jedynego klucza, który może wytworzyć dowolną tożsamość.

Co zawiera obszar roboczy CA

Katalog PKI to stan wystawcy, a nie konfiguracja. Zawiera klucz prywatny i certyfikat CA, plik numeru seryjnego, indeks wydanych certyfikatów oraz materiał dla poszczególnych tożsamości wytworzony na ich podstawie.

Podpisanie żądania zmienia ten stan, dlatego obszar roboczy należy do konta kontrolowanego przez administratora na hoście, na którym usługa VPN nie działa. Każdy, kto może odczytać klucz prywatny CA, może wydać certyfikat, któremu serwer zaufa, więc ochrona klucza to cały model zaufania w jednym pliku. Skopiowanie go w drugie miejsce, aby zaoszczędzić krok, tworzy drugą rzecz do ochrony i drugą do zapomnienia. Każdy podpis zwiększa też numer seryjny i dodaje wpis do indeksu, dlatego obszar roboczy to jedna kopia stanu, a nie folder plików.

Publiczny certyfikat CA jest inny. Jest przeznaczony do rozpowszechniania i to jego klienci oraz serwery używają do wzajemnej weryfikacji.

Co demon czyta przy starcie

Działający serwer zużywa niewielki zestaw: własny certyfikat, własny klucz prywatny, certyfikat CA do weryfikacji partnerów oraz materiał kluczy wymagany przez wybrany tryb. Odczytuje te ścieżki przy starcie i ponownie przy przeładowaniu.

Własność trzeba oceniać względem jednostki, która faktycznie się uruchamia, a nie względem interaktywnej powłoki root. Zadeklarowany sandbox może uczynić część systemu plików tylko do odczytu lub niewidoczną, nawet gdy ręczny test jako root się powiedzie.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

Ten trzeci wiersz ludzie pomijają. Pyta on konto samego demona, czy może odczytać klucz, i to jedyna wersja pytania, która ma znaczenie po odebraniu uprawnień. Zerowy kod wyjścia jako root nic nie mówi o tym, co dzieje się po odebraniu.

Obie ścieżki awarii warto rozdzielić, zanim zmienisz jakiekolwiek uprawnienie. Awaria podpisywania wskazuje na katalog PKI, uprawnienie wyszukiwania w jego katalogach nadrzędnych i konto uruchamiające wystawcę. Awaria startu wskazuje na jednostkę, jej katalog roboczy i ścieżki wymienione w konfiguracji serwera. Udostępnienie całego drzewa wszystkim nie naprawia żadnej z nich i usuwa granicę, od której obie zależą.

Dlaczego kopiowanie klucza CA na serwer zawodzi później

Kopia zwykle zaczyna się jako ruch debugowania: ktoś chce odnowić klienta na hoście VPN, więc klucz CA trafia do /etc/openvpn i odnowienie działa. Natychmiastowe zadanie się udaje, a granica znika.

Potem serwer jest kopiowany zapasowo, a urząd podpisujący trafia do kopii. Migawka, pakiet pomocy technicznej lub kopia katalogu konfiguracji niesie teraz możliwość wydawania zaufanych tożsamości, dopóki CA jest ważny. Kto ma tę kopię, może wytworzyć certyfikat dla dowolnej nazwy akceptowanej przez serwer, w tym nazw, które nigdy nie zostały wydane. Jedynym zapisem tego wydania jest ten, który zdecydują się zachować.

Wyjście z tego stanu nie polega na usunięciu pliku. Trzeba zdecydować, czy klucz wyciekł, obrócić CA, jeśli tak, i rozdzielić zaufanie na każdego partnera. Osobny obszar roboczy pozwala uniknąć całej rozmowy.

Konta, katalogi, kopie zapasowe

Daj wystawcy własne konto i katalog domowy, trzymane z dala od hosta VPN, gdy to praktyczne. Daj demonowi inne konto, z dostępem do odczytu wdrożonego materiału i bez dostępu do zapisu do czegokolwiek, co wydaje certyfikaty. Wdrażaj, kopiując publiczne certyfikaty na zewnątrz i nigdy nie ściągając prywatnego stanu wystawcy do wewnątrz. Kopiuj zapasowo obie role osobno, ponieważ ich wrażliwość i historie odtwarzania się różnią.

Po unieważnieniu zaktualizuj plik CRL wskazany w konfiguracji serwera, a następnie przeładuj usługę, aby nowe połączenia go odczytały. Dokumentacja Easy-RSA omawia układ obszaru roboczego i przepływ podpisywania; reguły własności wokół niego pozostają decyzją o twoim hoście. Sprawdź, co załadowała usługa, za pomocą openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate zamiast zakładać, że przeładowanie to podchwyciło.

Test, który dowodzi rozdzielenia

Sprawdź przypadek negatywny, nie tylko działający. Podpisz certyfikat z konta wystawcy zgodnie z projektem, a następnie potwierdź, że to samo konto nie może uruchomić usługi ani odczytać klucza prywatnego serwera. Potem potwierdź, że konto demona nie może odczytać klucza prywatnego CA.

Te trzy kontrole zajmują kilka minut i przetrwają zmiany personelu, ponieważ są stwierdzeniami o uprawnieniach, a nie o nawyku. Zapisz wynik wraz ze ścieżkami i kontami, które obejmował, oraz datą wykonania. Następna osoba, która odziedziczy to wdrożenie, w przeciwnym razie ponownie wyprowadzi granicę z poradnika, który nigdy jej nie miał. Datowany zapis jest też tym, co sprawia, że następny przegląd zajmuje minuty, a nie popołudnie.