Jak zabezpieczyć SSL VPN?

Pomimo coraz większej popularności rozwiązań typu Zero Trust Network Access w zakresie bezpiecznego dostępu zdalnego, klasyczne podejście wykorzystujące SSL VPN będzie jeszcze długo powszechnie stosowane. Niezależnie od przyjętej technologii oczywistym jest, że dostęp zdalny do zasobów wewnętrznych firmy musi być dobrze zabezpieczony. Zwykłe poświadczenia w postaci loginu i hasła statycznego nie są wystarczające, dlatego powszechnie stosuje się tzw. drugi faktor (2FA) w postaci dynamicznie zmieniającego się tokena dostarczanego SMSem lub za pomocą aplikacji mobilnej. Coraz częściej stosuje się dodatkowe zabezpieczenie – certyfikat klienta. Jeżeli certyfikat klienta jest poprawnie instalowany na docelowej stacji roboczej przez wewnętrzne służby IT lub za pomocą mechanizmów zarządzania typu GPO bez możliwości eksportu klucza prywatnego, to możemy być pewni, że dostęp zdalny będzie realizowany tylko z wykorzystaniem zatwierdzonych (autoryzowanych) urządzeń końcowych.

Stosowanie certyfikatu klienta przy dostępie SSL VPN

Stosowanie wymogu przedstawienia się użytkownika certyfikatem cyfrowym przy nawiązywaniu połączenia SSL VPN ma jeszcze jedną zaletę. W ten sposób chronimy naszą bramkę i docelowy serwer uwierzytelniający przed atakami typu brute force, gdyż weryfikacja certyfikatu odbywa się na początku procesu uwierzytelnienia, przed przekazaniem poświadczeń do serwera docelowego. Czyli w przypadku niepoprawnego certyfikatu lub jego braku nie dochodzi do weryfikacji poświadczeń. Warto tutaj dodatkowo wspomnieć, że dla dodatkowej ochrony materiału kryptograficznego przed wyciekiem zaleca się zastosowanie zewnętrznego nośnika typu karta mikroprocesorowa lub klucz U2F. W zależności od zastosowanego rozwiązania bramki SSL VPN warto rozważyć możliwość dodatkowej weryfikacji stanu urządzenia końcowego z przyjętą polityką np. co do wersji systemu operacyjnego, zastosowanych na nim innych mechanizmów zabezpieczeń, itp.

Sytuacja bardziej się komplikuje, jeżeli certyfikat klienta ma być zainstalowany na stacji niezarządzanej przez podmiot udostępniający zasoby przez SSL VPN. Wtedy najczęściej certyfikat jest przekazywany użytkownikowi razem z kluczem prywatnym. Pojawia się zatem ryzyko wycieku materiału kryptograficznego i możliwość przekazania go innemu użytkownikowi. Zdarza się też, że np. użytkownik A przekazuje swoją parę kluczy użytkownikowi B, bo temu akurat certyfikat wygasł lub został utracony, a na uzyskanie nowego certyfikatu w normlanym trybie akurat nie ma czasu. W celu zabezpieczenia się przed tego typu sytuacjami należy weryfikować zgodność nazwy użytkownika (loginu) z certyfikatem, a ściślej mówiąc z wartością wybranego atrybutu np. Common Name. Przy okazji warto zadbać, żeby generowane certyfikaty wśród wartości atrybutów zawierały nazwę użytkownika dokładnie taką jaka podawana jest podczas logowania się użytkownika.

Ivanti Connect Secure

Poniżej przedstawiono przykładową konfigurację stosowaną na rozwiązaniu Ivanti Connect Secure, wg której sprawdzana jest zgodność loginu z nazwą użytkownika zawartą w certyfikacie w atrybucie Common Name oraz przynależność użytkownika do odpowiedniej grupy w katalogu LDAP. Na tej podstawie w procesie autoryzacji przypisywane są danemu użytkownikowi odpowiednie zasoby.

Należy tutaj zaznaczyć, że wyżej wymieniona weryfikacja odbywa się na etapie autoryzacji, nie uwierzytelnienia. W związku z tym, w przypadku zastosowania przez użytkownika A certyfikatu od użytkownika B samo uwierzytelnienie powiedzie się, lecz nie zostaną udostępnione żadne zasoby.

Jeśli masz pytania dotyczące stosowania certyfikatu klienta przy dostępie SSL VPN - skontaktuj się z nami!