Czy iPad potrzebuje własnego certyfikatu klienta VPN?

Nowy iPad dołącza do zespołu, a najszybsza droga to wyeksportowanie istniejącego certyfikatu klienta i zainstalowanie go na tablecie. Działa to do chwili, gdy ktoś odejdzie, zgubi urządzenie albo poprosi o audyt, który wskaże, które urządzenie i kiedy się łączyło. Decyzja nie dotyczy pliku certyfikatu, lecz tożsamości: czy każde urządzenie można osobno autoryzować i odwołać. Koszt i nakład zarządzania rozstrzygają odpowiedź, a oba są mniejsze, niż się wydają.

Wspólny wystawca, odrębne tożsamości

Każde urządzenie może ufać temu samemu urzędowi certyfikacji i łączyć się z tą samą bramą, mając inną tożsamość klienta. Wystawca jest kotwicą zaufania, a tożsamość to para kluczy, której podmiot serwer mapuje na politykę. To właśnie mieszanie obu tych rzeczy sprawia, że wspólny certyfikat wydaje się nieszkodliwy. Pozostaje nieszkodliwy tylko do chwili, gdy ktoś musi wiedzieć, które urządzenie otworzyło sesję.

Współdzielenie wystawcy oszczędza pracę konfiguracyjną i niczego nie zmienia w odpowiedzialności za poszczególne urządzenia. Współdzielenie tożsamości spłaszcza każde urządzenie do jednej odwoływalnej jednostki: odwołanie jednego odwołuje wszystkie, a autoryzacja zamiennika autoryzuje każdą kiedykolwiek wykonaną kopię klucza. Ten kompromis warto zawrzeć wprost, zamiast kopiować plik dlatego, że w piątkowe popołudnie jest szybciej.

Kiedy drugi certyfikat kosztuje za dużo

Rejestracja na urządzenie kosztuje jeden krok: profil zarządzany, wniosek SCEP albo import prowadzony z jednorazowym hasłem. Wymaga też miejsca do śledzenia numerów seryjnych i dat ważności, czyli tego, o czym większość wdrożeń zapomina, dopóki pierwszy certyfikat nie wygaśnie. Oba koszty są jednorazowe i oba maleją, gdy proces rejestracji je automatyzuje.

Koszt jest realny w gospodarstwie domowym z dwoma tabletami i jednym użytkownikiem, gdzie wspólna tożsamość jest rozsądną decyzją udokumentowaną jednym zdaniem. Nie jest rozsądny w usłudze, w której dostęp trzeba odbierać per osoba lub per urządzenie, ponieważ historia odwołań to cały powód używania certyfikatów zamiast hasła. Oceń wdrożenie po tym, jak często urządzenia zmieniają właściciela, a nie po tym, ile urządzeń istnieje dziś.

Zarejestruj urządzenie, nie kopiuj klucza

Nowoczesne platformy trzymają klucze prywatne w chronionym magazynie, a niektóre z założenia oznaczają je jako nieeksportowalne. To ta właściwość sprawia, że kopiowanie jest od początku niemożliwe, i to również dlatego wyeksportowanego pakietu z laptopa nie można po prostu zaimportować na tablet w żaden obsługiwany sposób. Próba i tak daje profil, który instaluje się czysto i potem nigdy się nie uwierzytelnia.

Użyj metody rejestracji, którą wdrożenie już obsługuje: profilu tożsamości zarządzanej, usługi SCEP albo przepływu opartego na koncie, który wydaje nowy klucz na urządzeniu. Rozdawanie klucza prywatnego urzędu certyfikacji, by rozwiązać brak tożsamości, to inny błąd o znacznie większym zasięgu. Urząd wydaje poświadczenia i nigdy nie powinien podróżować do punktu końcowego.

Sprawdź odwołanie, zanim odpowiesz

Zanim wybierzesz opcję wspólną, opisz, jak wygląda odwołanie w najgorszym dniu. Jeśli odpowiedź to jedna czynność dotycząca kilku urządzeń, projekt już zdecydował przeciwko tobie.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Zbadaj materiał, który naprawdę masz: czy jest klucz prywatny, co mówi podmiot i czy numer seryjny można odwołać osobno. Plik certyfikatu bez swojego klucza nie może niczego uwierzytelnić, i dlatego niektóre skopiowane tożsamości zawodzą przy pierwszym połączeniu.

Usunięcie aplikacji z tabletu nie jest odwołaniem, a serwer nadal akceptuje tożsamość, dopóki ktoś jej nie wyłączy. Zapisz to zdanie w runbooku, zanim zostanie zarejestrowane pierwsze urządzenie.