Uwierzytelnianie wieloskładnikowe w modelu Zero Trust

Uwierzytelnianie wieloskładnikowe w koncepcji Zero Trust

W ostatnim czasie bardzo dużo mówi się o tzw. Architekturze Zero Trust opartej o krótkie sformułowanie „Nigdy nie ufaj. Zawsze sprawdzaj.”. Zaprojektowanie systemu umożliwiającego zrealizowanie założeń tej koncepcji zakłada wykorzystanie wielu składników, które wzajemnie będą się uzupełniać i dodawać kolejny element kontekstu, w ramach jakiego weryfikujemy osobę lub urządzenie, próbujące uzyskać dostęp do naszego zasobu, czy jest to aplikacja, dysk współdzielony czy po prostu dostęp do sieci organizacji.

O tyle, o ile różne scenariusze mogą zakładać inne, specyficzne ze względu na sposób uzyskiwania dostępu systemy zabezpieczające go, czy typ wspomnianego już zasobu do jakiego odwołuje się zapytanie, jest kilka elementów stale wpisujących się w każdy scenariusz. Jednym z tego typu rozwiązań Zero Trust, które wspierają administratorów w realizowaniu zadania weryfikacji tożsamości użytkownika przy próbie uzyskania dostępu, są systemy umożliwiające uwierzytelnianie wieloskładnikowe (ang. MFA – Multi-Factor Authentication).

Bezpieczeństwo IT

Co tak właściwie dają nam systemy MFA i czemu ich stosowanie powinno być swoistym „must have” w każdej organizacji? Odpowiedź na to pytanie może być bardzo rozbudowana. Producenci tego typu oprogramowania prześcigają się aktualnie w kwestii możliwości jakie stoją za właśnie ich systemem MFA. Każdy stara się przyciągnąć do siebie klientów za sprawą ilości natywnych integracji z aplikacjami, możliwością wykorzystania SSO czy nawet weryfikowaniem kondycji stacji końcowej przed potwierdzeniem tożsamości.

Krótko mówiąc, systemy te ewoluowały i z podstawowej roli, gdzie ich zadaniem było jedynie dodanie drugiego czynnika potwierdzającego, że osoba, która wpisała login i hasło to rzeczywiście ta osoba, poprzez podanie generycznego kodu z tokena czy hasła przesłanego na sms, pozwalają obecnie na znacznie więcej, co w konsekwencji rozszerza nasz kontekst na temat tej osoby i urządzenia, które w danym momencie wykorzystuje. Wszystko oczywiście zależy od możliwości danego rozwiązania jak i sposobu w jaki zostanie zaimplementowane.

Wykorzystanie SSL VPN

Próbując zatem odpowiedzieć na postawione pytanie zacznę od prozaicznej sytuacji z dostępem do sieci organizacji z wykorzystaniem SSL VPN. Scenariusz typowy, szczególnie od kiedy rozszalała pandemia i znakomita większość firm oraz organizacji została zmuszona do wprowadzenia modelu pracy zdalnej, nie zawsze umożliwiając swoim pracownikom wykorzystanie firmowego komputera w domu, często zmuszając do używania prywatnych urządzeń by połączyć się do sieci firmy przez SSL VPN, a następnie zdalnie uzyskać dostęp do swojej stacji roboczej w biurze.

Kiedy nagle trzeba było przesiąść się na taką formę pracy, wszyscy w biznesie myśleli głównie o tym by jak najszybciej stało się to możliwe, nie dbając o odpowiednie zabezpieczenie tego kanału połączenia, bo każdy dzień generował straty ze względu na niemożność wykonywania swoich obowiązków przez pracowników. Dostęp zdalny był realizowany poprzez połącznie się przez terminator sesji VPN do sieci firmy, najczęściej przy konieczności podania swojej nazwy użytkownika i hasła, po czym, jeśli te były prawidłowe, następowało zestawienie bezpiecznego tunelu pomiędzy komputerem pracownika, a terminatorem sesji VPN.

Proste i skuteczne, ale niosące ze sobą niebezpieczeństwo, że wykradzione poświadczenia mogą służyć komukolwiek innemu by podszyć się pod przysłowiowego Jana Kowalskiego i jako on wykonywać niepożądane akcje będąc prawidłowo uwierzytelnionym i posiadając autoryzowany dostęp do sieci organizacji.

Użytkownik końcowy

Nie bez powodu mówi się, że najsłabszym ogniwem w łańcuchu zwanym bezpieczeństwem jest człowiek. Niezabezpieczona, prywatna stacja końcowa, może być nosicielem malware’u, który pozwala przechwytywać atakującemu między innymi znaki wpisywane na klawiaturze lub wręcz mieć podgląd do wszystkiego co ten wykonuje na swojej stacji. Przechwycenie danych logowania do organizacji wraz z adresem serwera, do którego użytkownik odwołuje się by zestawić sesję SSL VPN ze swoją organizacją będzie dla tego typu złego aktora dziecinną igraszką.

Pojedynczy skompromitowany użytkownik może w efekcie być źródłem poważnego wycieku danych, skutkującym co najmniej szkodami wizerunkowymi dla organizacji, nie wspominając o tym, że ten kanał może posłużyć do dystrybucji w sieci firmowej złośliwego oprogramowania ransomware, a to tylko dlatego, że Jan Kowalski w chwili połączenia z siecią firmową tak naprawdę nie był naszym zaufanym pracownikiem Janem Kowalskim, a jedynie znał jego login i hasło przez co w naszych oczach to był Jan Kowalski.

MFA w modelu Zero Trust

Wracając do systemów MFA i powodów zastosowania ich w organizacji. Ponownie skupię się na sytuacji z Janem Kowalskim i jego wykradzionych poświadczeniach. Ponownie atakujący chce dostać się z ich pomocą do sieci organizacji. Tym razem jednak potrzebuje jeszcze jednego elementu, a mianowicie kodu generowanego przez aplikację na telefonie komórkowym prawdziwego Jana Kowalskiego. W tym scenariuszu atakujący nie dostanie się do sieci organizacji jako Jan Kowalski, ponieważ kody są generyczne i zmieniają się co jakiś czas, a dodatkowo z poziomu aplikacji i telefonu może być wykrywany jeszcze jeden czynnik – biometryka, czyli odcisk palca lub skan twarzy, dobitnie potwierdzający, czy loguje się Jan Kowalski czy też ktoś obcy.

W tym scenariuszu mamy zatem trzy czynniki, które potwierdzają nam czy osoba logująca się do sieci organizacji za pomocą SSL VPN to Jan Kowalski. Po pierwsze login i hasło. Po drugie generyczny kod z aplikacji w telefonie Jana Kowalskiego. Po trzecie weryfikacja danych biometrycznych przez telefon Jana Kowalskiego. Tym sposobem dostajemy większą pewność na temat tego, kto i czy to rzeczywiście nasz pracownik loguje się do sieci firmowej za pomocą SSL VPN.

Podobna weryfikacja może oczywiście zaistnieć w przypadku dostępu do aplikacji, danych w zasobach współdzielonych czy nawet stacji roboczej. W tym miejscu płynnie przejdę do konkretnego modelu Zero Trust, które chciałbym przybliżyć jako jedno z wiodących w moim odczuciu dostępnych na rynku, a mowa o Thales SafeNet Trusted Access.

Thales SafeNet Trusted Access

W podejściu Zero Trust wykorzystywane jest również narzędzie Thales SafeNet Trusted Access, który jest dostarczany w formie usługi chmurowej co sprawia, że jego implementacja w organizacji jest wyjątkowo krótka, a do tego elastyczna i skalowalna, co pozwala z łatwością dostosować poziom świadczenia usługi do rosnących z czasem potrzeb organizacji, bez konieczności inwestowania dodatkowych funduszy we własne zasoby serwerowe.

Platforma obsługuje uwierzytelnianie w systemach operacyjnych Windows, MacOS, iOS i Android, a także VPN i usług w chmurze. Jest to znakomite rozwiązanie, które pozwala zabezpieczyć dostęp do coraz większej ilości usług przenoszonych przez organizacje do chmury. Jako przykład można przywołać chociażby najpopularniejszą obecnie usługę chmurową wykorzystywaną w biznesie jaką jest Office 365. Thales STA bez trudu jest w stanie zintegrować się z naszym chmurowym serwerem exchange i dodać kolejną warstwę ochrony dla dostępu naszych użytkowników do ich poczty firmowej.

Ostatnią, lecz nie najmniej ważną funkcją o jakiej chciałbym wspomnieć jest możliwość monitorowania ryzyka przez centralny dashboard Thales STA. W logach jesteśmy w stanie zobaczyć każdą próbę logowania do naszych systemów, zarówno te udane jak i zakończone niepowodzeniem. Możemy przeanalizować, kiedy dochodziło do nieuprawnionego logowania, jakie zasoby były celem, jakie polityki zablokowały dostęp i dlaczego. Wszystko to dostępne w postaci przejrzystych wykresów obrazujących te dane w czasie.