Niektórzy administratorzy starej szkoły wciąż debatują na temat bezpiecznych sieci wewnętrznych, ale eksperci poszli o krok dalej: architektury o zerowym zaufaniu oferują niezawodną, ale złożoną strategię ochrony sieci przed wszystkimi zagrożeniami – wewnętrznymi i zewnętrznymi.
W trzecim roku pandemii stało się jasne, że ten sam wirus, który spowodował wiele osobistych tragedii, równocześnie przyczynił się do rozwoju wielu firm, zwłaszcza z sektora IT. Do tej kategorii
zdecydowanie należą dostawcy rozwiązań VPN: praca z domu stała się bardziej regułą niż wyjątkiem, zapotrzebowanie na rozwiązania VPN zaś znacznie wzrosło. Mało kto spodziewał się, że obciążenie bram VPN tak bardzo wzrośnie niemal z dnia na dzień. Producenci sieci chętnie pomagali swoim klientom, którzy kupowali coraz mocniejsze systemy, np. dla OpenVPN (Rysunek 1).
Ale czy VPN faktycznie rozwiązują problem z bezpieczeństwem sieci? Zdania ekspertów są podzielone. Organizacje korzystające z VPN-ów wychodzą z następującego założenia: istnieje różnica między siecią wewnętrzną a zewnętrzną i bezpiecznie jest traktować klientów wewnętrznych inaczej niż klientów zewnętrznych. VPN-y są regularnie używane, ponieważ administratorzy w ogóle nie chcą, aby niektóre usługi były dostępne z Internetu. W wielu firmach VPN-y stanowią część architektury bezpieczeństwa, która rozwijała się organicznie przez wiele lat. Ponieważ wymagania bezpieczeństwa stale rosły w ciągu ostatnich dwóch dekad, firmy inwestowały coraz więcej pieniędzy w sieci prywatne i odcinały coraz więcej usług od świata zewnętrznego.
Jednak odcięcie użytkowników zewnętrznych rozwiązuje tylko część problemu. Klasyczny podział na niebezpieczną sieć zewnętrzną i bezpieczną sieć wewnętrzną opiera się na kilku założeniach. Przede wszystkim zakłada, że można mieć racjonalnie oczekiwania dotyczące zachowania użytkownika w oparciu na lokalizację. Ta błędna narracja skłania do przekonania, że pracownicy firmy nie mogą mieć złych zamiarów, w przeciwieństwie do złowrogich hakerów, którzy włamują się wyłącznie z zewnątrz. Innym błędnym założeniem jest to, że na podstawie lokalizacji możemy bezpiecznie wnioskować o tym, kim jest klient i jakie uprawnienia powinien mieć. Każdy, kto wejdzie do sieci wewnętrznej, jest automatycznie uznawany za godnego zaufania i ma rozszerzone przywileje, w tym dostęp do komponentów infrastruktury, które pozostają zamknięte dla klientów zewnętrznych.
Dzisiejsza wiedza na temat bezpieczeństwa informacji pokazuje, że takie opinie oparte są na wątpliwych podstawach. Klienty w sieci wewnętrznej również stanowią zagrożenie dla bezpieczeństwa. Ryzyko może pochodzić od użytkownika, który otworzy załącznik zainfekowany złośliwym oprogramowaniem, niezadowolonego lub byłego pracownika, który nadal ma jakąś formę dostępu do sieci wewnętrznej. Innym problemem jest ciągła obecność gości przychodzących i wychodzących z zaawansowanymi urządzeniami mobilnymi, które stale korzystają z sieci.
Zero zaufania to zestaw zasad opracowanych w celu ustanowienia reguł mających na celu wyeliminowanie stronniczości związanych z lokalizacją w sieci. W modelu z zerowym zaufaniem każdy użytkownik jest uważany za niewiarygodnego, dopóki nie udowodni, że jest inaczej. Reguły zerowego zaufania kodyfikują również inne najlepsze praktyki w zakresie bezpieczeństwa sieci, tworząc najnowocześniejsze środowisko korygujące wiele nieaktualnych założeń, które narażają sieci na ryzyko.
Długa historia
Termin „zero zaufania” pochodzi z rozprawy doktorskiej Stephena Paula Marsha z Uniwersytetu Stirling w Szkocji [1]. Praca Marsha opierała się na pojęciu „zaufania” jako czegoś, co można zdefiniować matematycznie – nie ma związku z moralnością czy w ogóle złożonością interakcji międzyludzkich. W okolicach 2003 r. międzynarodowa grupa zwana Jericho Forum zaczęła organizować spotkania, aby zbadać problem, który zdefiniowano jako „zniesienie granic” (de-perimeterisation). Jerycho Forum podniosło świadomość potrzeby nowego podejścia do bezpieczeństwa sieci, z naciskiem na wyeliminowanie archaicznej idei sieci wewnętrznej jako bezpiecznej i chronionej przestrzeni. Tak zwana „przykazania” Forum Jerycho [2] były prekursorem wielu zasad obecnie związanych z zerowym zaufaniem.
Oczywiście minęło trochę czasu, zanim rzeczywistość dogoniła teoretyków. Warto pamiętać, że pierwsze sieci lokalne, jakie znamy dzisiaj, były izolowane i zazwyczaj nie używały nawet protokołów, z których korzysta się dziś w Internecie; popularne były np. protokoły IPX/SPX. Kiedy w latach 90. XX w. pojawił się trend, by łączyć sieci lokalne z Internetem, koncepcja sieci LAN jako „bezpiecznej” przestrzeni była już mocno zakorzeniona, a wysiłki mające na celu powstrzymanie intruzów przed uzyskaniem dostępu koncentrowały się na urządzeniu będącym bramą. W szczególności duże firmy miały trudności z porzuceniem strategii bezpieczeństwa, które lepiej lub gorzej sprawdzały się w latach 90. XX wieku.
W 2009 roku firma Google częściowo wdrożyła model bezpieczeństwa BeyondCorp, który jest obecnie uważany za wczesną implementację architektury zerowego zaufania. W międzyczasie naukowcy i eksperci ds. bezpieczeństwa nadal opracowywali i badali zasady zerowego zaufania, a komponenty, które obecnie stanowią elementy składowe zerowego zaufania, takie jak szyfrowanie i zarządzanie tożsamością, ewoluowały równolegle.
Pierwsze dokumenty rządowe określające politykę zerowego zaufania pojawiły się kilka lat temu, wraz z dokumentem SP 800-207 „Architektura zerowego zaufania”[3] opublikowanym przez amerykański National Institute of Standards and Technology (NIST)[3] w 2018 r. i „Architektury sieciowe” opublikowanym przez [4] brytyjski National Cyber Security Center (NCSC) w 2019 r.
W 2022 r. podział świata na „dobry” (wewnętrzny) i „zły” (zewnętrzny) staje się coraz bardziej nieistotny, a model zerowego zaufania szybko zyskuje na popularności jako lepsze podejście.
Założenia
Istnieje kilka sformułowań zasad zerowego zaufania, z których wszystkie mają podobne cele. NIST SP 800-207 definiuje te zasady w następujący sposób:
1. Wszystkie źródła danych i usługi obliczeniowe są uważane za zasoby.
2. Cała komunikacja jest zabezpieczona – niezależnie od lokalizacji sieci.
3. Dostęp do poszczególnych zasobów przedsiębiorstwa jest przyznawany na podstawie sesji.
4. Dostęp do zasobów jest określany przez zasady dynamiczne — w tym obserwowalny stan tożsamości klienta, aplikacji/usługi oraz żądanego zasobu — i może obejmować inne atrybuty behawioralne i środowiskowe.
5. Organizacja monitoruje i mierzy integralność oraz stan bezpieczeństwa wszystkich posiadanych i powiązanych zasobów.
6. Wszelkie uwierzytelnianie i autoryzacja zasobów są dynamiczne i ściśle wymuszane, zanim udzielone zostanie pozwolenie na dostęp.
7. Organizacja gromadzi jak najwięcej informacji o aktualnym stanie zasobów, infrastruktury sieciowej i komunikacji oraz wykorzystuje je do poprawy stanu bezpieczeństwa.
Cała idea polega na tym, że organizacja projektuje architekturę zerowego zaufania opartą na tych zasadach, a następnie wdraża ją, by zbudować sieć zerowego zaufania. Zasady zapewniają, że żadne ważne szczegóły nie zostaną pozostawione przypadkowi. Bliższe zbadanie tych zasad ujawnia, że wiele elementów zerowego zaufania już działa w nowoczesnych sieciach, np. rejestrowanie, monitorowanie, zarządzanie dostępem czy bezpieczna komunikacja. Model zerowego zaufania tworzy nadrzędną strukturę i zapewnia systematyczne stosowanie zasad.
W przypadku zerowego zaufania usługa zawsze zakłada, że klient ma złowrogie intencje, dopóki nie udowodni, że jest inaczej, na przykład logując się przy użyciu unikalnych poświadczeń. Ale nawet logowanie nie skutkuje nieograniczonym zaufaniem; wyrafinowana strategia autoryzacji jest integralnym elementem środowiska zerowego zaufania. Klient musi mieć wyraźną autoryzację do określonego zadania, aby móc je wykonać.
Innym kluczowym czynnikiem zerowego zaufania jest to, że wszystkie połączenia muszą być szyfrowane. Oczywiście pojawia się pytanie, jaki rodzaj szyfrowania i jakie narzędzia szyfrujące wybrać – na te pytania najlepiej odpowiedzieć na etapie projektowania. Można by zapytać, czy coś takiego jak VPN jest w ogóle konieczne, skoro szyfrowanie i tak jest używane w sieci lokalnej, a zasady zerowego zaufania eliminują pojęcie sieci wewnętrznej. Czy nie byłoby możliwe uzyskanie dostępu do każdego zasobu z dowolnego miejsca na Ziemi za pomocą SSH? Takie sformułowanie wskazuje jednak niepełne zrozumienie zasad zerowego zaufania.
Na przykład serwery pocztowe Google nie są bezpośrednio dostępne z sieci przez SSH. Nie dzieje się tak jednak dlatego, że Google zrezygnowało z zasad zerowego zaufania. Chodzi raczej o to, że administracyjny dostęp do infrastruktury jest zwykle zarezerwowany dla niewielkiej, dość statycznej grupy osób. Po prostu nie ma powodu, aby przeciętny użytkownik usług Google miał dostęp do serwerów Google przez SSH. Z drugiej strony do wielu centralnych usług Google – tych przeznaczonych do powszechnego użytku – można uzyskać dostęp bez specjalnego połączenia, takiego jak VPN. Model zerowego zaufania nie wyklucza korzystania z VPN do specjalnych celów, a jedynie neguje założenie, że klient z dostępem VPN powinien mieć specjalne prawa.
Zanim jednak administratorzy będą mogli wyłączyć VPN w istniejącym środowisku lub ograniczyć jego użycie, potrzeba dużo pracy, ponieważ zerowego zaufania nie można osiągnąć poprzez zainstalowanie określonego programu. Chodzi bardziej o stworzenie strategii, która w najlepszy możliwy sposób zintegruje wszystkie niezbędne komponenty środowiska.
Użytkownicy i prawa dostępu
Jak widać z przedstawionych wyżej zasad, system zerowego zaufania jest w dużym stopniu zależny od potrzeby scentralizowanego organu do przypisywania szczegółowych praw określonym użytkownikom. W przypadku każdej infrastruktury o zerowym zaufaniu scentralizowany system zarządzania użytkownikami i uprawnieniami jest absolutnie niezbędny. Na rynku ugruntowały się dwa systemy do scentralizowanego zarządzania użytkownikami: LDAP i Active Directory (AD). Szczególnie w korporacyjnych środowiskach IT często można znaleźć dość aktualną instancję AD Microsoftu (Rysunek 2), a przy odrobinie szczęścia włączona jest kompatybilność z LDAP. Obecnie większość oprogramowania do zarządzania oferuje obsługę co najmniej jednej z tych metod dostępu.
Jeśli gotowy katalog użytkowników nie jest dostępny i chcemy go utworzyć dla środowiska Linux, mamy kilka możliwości. Jedną z opcji jest LDAP w klasycznej implementacji OpenLDAP. OpenLDAP jest dostępny dla Suse Linux Enterprise Server, Ubuntu i kilku innych dystrybucji. Natomiast Red Hat poszedł własną drogą i udostępnia infrastrukturę Red Hat Identification Management. Opiera się ona na FreeIPA, konkurencyjnej implementacji OpenLDAP z kilkoma dodatkowymi funkcjami. Na przykład FreeIPA jest dostarczany ze zintegrowanym zarządzaniem kluczami (SSH i SSL), systemami i użytkownikami gotowymi do użycia tuż po instalacji oraz różnymi narzędziami działającymi w wierszu poleceń.
Role
Bez względu na to, którą opcję wybierzemy, ważniejsza od nazw użytkowników i haseł jest strategia roli i autoryzacji, którą mapujemy na centralny katalog użytkowników. W tym miejscu sprawy się nieco komplikują. Istnieją bowiem różne opinie na temat mapowania uprawnień w LDAP i innych narzędziach do zarządzania tożsamością.
Jedna z często używanych metod opiera się na grupach LDAP. Pod względem logiki wygląda to tak, że mapujemy uprawnienia dostępu do zasobu jako członkostwo w grupie. Innymi słowy, dostęp do usługi mają tylko użytkownicy należący do odpowiedniej grupy LDAP. Takie grupowe przypisanie nie zapewnia jednak dużego poziomu szczegółowości, dlatego opracowano różne obejścia tego problemu. Często istnieją różne grupy LDAP dla użytkowników i administratorów usług. Problem w tym, że usługa, która jest następnie połączona z LDAP, również musi być w stanie ocenić te grupy. Są też i inne problemy. Przykładowo LDAP sam w sobie również obsługuje role i dodatkowe poziomy hierarchii.
Złożoność związana z przypisywaniem uprawnień podczas wdrażania modeli zerowego zaufania jest jednym z powodów, dla których fundamentalne znaczenie ma wcześniejsze rozplanowanie całego procesu. Zanim administratorzy systemów w ogóle pomyślą o wdrożeniu OpenLDAP lub FreeIPA, muszą mieć dający się zaimplementować projekt definiujący użytkowników i ich role w oparciu na macierz RASCI [5], która z wyprzedzeniem odwzorowuje jak najwięcej nieprzewidzianych sytuacji.
Jak to zwykle bywa, po wdrożeniu strategii trudno jest wprowadzić głębsze zmiany i musimy się liczyć z oporem użytkowników. Z drugiej strony, jeśli już z góry wiadomo, jakie uprawnienia są wymagane do dostępu do poszczególnych usług, łatwiej jest zaimplementować centralny katalog użytkowników w sposób zgodny z projektem.
Znajdowanie oprogramowania
Z punktu widzenia administratora systemu szczególnie problematyczne jest to, że zerowe zaufanie nie zostało jeszcze wdrożone jako ustalony standard techniczny, lecz jedynie jako wiele częściowo sprzecznych strategii. Opisana wcześniej definicja podana w standardzie SP 800-207 ma charakter informacyjny, ale jest trochę niejasna. Jeśli chcemy, aby nasze oprogramowanie spełniało wymagania zerowego zaufania, nie możemy liczyć na gotowy skrypt, który nas poprowadzi.
Usługi i składniki sieciowe mogą się znacznie różnić pod względem obsługi zerowego zaufania. W większości przypadków usługi centralne, takie jak istniejące oprogramowanie do pracy grupowej lub serwery pocztowe, zapewniają niezbędną elastyczność. Standardowe rozwiązania, takie jak Dovecot lub Postfix, mogą na przykład obsłużyć połączenie z LDAP za pomocą wielu opcji umożliwiających precyzyjną konfigurację, co ułatwia wdrożenie poczty elektronicznej obsługującej zerowe zaufanie.
Sytuacja nieco się komplikuje, jeśli używamy zamkniętych narzędzi, które w ogóle nie łączą się z LDAP lub nie implementują istotnych funkcji, takich jak uwierzytelnianie wieloskładnikowe. W takim przypadku musimy w jakiś sposób obejść ten problem. Na przykład Libpam domyślnie oferuje uwierzytelnianie dwuskładnikowe i zawiera moduły umożliwiające integrację z Google Authenticatorem i korzystanie z haseł jednorazowych. W ten sposób można nawet dodatkowo zabezpieczyć logowanie przez SSH w systemach zdalnych, znacznie utrudniając atak, w sytuacji kiedy klucz SSH został przechwycony. Warto jednak zwrócić uwagę na wydajność, ponieważ w przeszłości integracja Authenticatora z PAM-em miała na nią negatywny wpływ.
Istnieje kilka projektów stworzonych z myślą o wspieraniu administratora we wdrażaniu strategii zerowego zaufania. Jednym z najbardziej znanych jest Teleport (Rysunek 3), który jest rozbudowanym zamiennikiem OpenLDAP obiecującym „uwierzytelnianie ze świadomością tożsamości”. W tle Teleport opiera się na ustalonych standardach, takich jak X.509 czy OpenID, i udostępnia je użytkownikowi, jednocześnie działając jako klient klasycznych usług, takich jak SSH.
W praktyce Teleport pełni funkcję serwera pośredniczącego, co znacznie ułatwia migrację do poziomu zerowego zaufania. Takie podejście ma ogromne zalety, zwłaszcza jeśli korzystamy ze starszego bądź zamkniętego oprogramowania, dla którego usługi takie jak Teleport to w tym wypadku jedyne praktyczne rozwiązanie. Każdy, kto kiedykolwiek próbował ponownie zainstalować starsze oprogramowanie, wie, jak bardzo może to być kłopotliwe już kilka lat po utworzeniu programu.
To nie przypadek, że Teleport umieszcza banki na szczycie listy grup klientów o wysokim znaczeniu. Banki często wykorzystują starsze oprogramowanie, o którego integracji z nowoczesną architekturą bezpieczeństwa trudno byłoby pomyśleć bez serwera pośredniczącego lub jakiejś formy warstwy kompatybilności.
Urządzenia mobilne
Smartfony i tablety już dawno zmieniły się w dość wydajne komputery, które można wykorzystać do wygodnego wykonywania prostych codziennych zadań. Specjalne zasady mają już zastosowanie do urządzeń mobilnych niezależnie od zerowego zaufania. Podobnie jak w przypadku laptopów, ryzyko utraty jest wysokie, co oznacza, że szyfrowanie danych na urządzeniu musi mieć wysoki priorytet. Jeśli urządzenia mobilne są utrzymywane pod parasolem zerowego zaufania, firma ma żywotny interes w utrzymaniu kontroli nad urządzeniem przez cały czas, nawet jeśli zostało skradzione lub zgubione. W takim przypadku powinna istnieć możliwość zdalnego wyczyszczenia urządzenia lub uniemożliwienia dalszego użytkowania za pomocą blokady aktywacyjnej.
W środowiskach opartych na standardzie zerowego zaufania urządzenia mobilne często odgrywają znaczącą rolę. Ponieważ uwierzytelnianie w środowisku o zerowym zaufaniu musi być zabezpieczone wieloma czynnikami, urządzenie mobilne może działać jako token bezpieczeństwa oparty na usłudze takiej jak Google Authenticator. Oczywiście oznacza to, że środki bezpieczeństwa, którym przyglądaliśmy się do tej pory, muszą być przestrzegane jeszcze bardziej rygorystycznie (np. mechanizmy odblokowywania). Jeśli urządzenie można łatwo odblokować, zainstalowany na nim Google Authenticator jako drugi czynnik staje się bezużyteczny. Dlatego konieczna jest bezpieczna i odpowiednia konfiguracja odblokowania.
Choć rola urządzeń mobilnych w środowiskach o zerowym zaufaniu jest kluczowa, nie ma prawie żadnych sensownych opcji centralnego zarządzania urządzeniami za pomocą narzędzi standardowo dostarczanych z Linuksem. Przynajmniej na poziomie oprogramowania nie ma nic, co mogłoby choćby zacząć konkurować z centralnymi narzędziami od Google’a (Rysunek 4) czy Apple’a (Rysunek 5), które oferują takie funkcje, jak możliwość zdalnego wyczyszczenia utraconego smartfona. Jeśli wydajemy telefony komórkowe pracownikom, musimy wziąć pod uwagę bezpieczeństwo smartfonów, i to jeszcze na etapie planowania. W praktyce trudno więc uniknąć skorzystania z usług dwóch głównych producentów, które pomogą w realizacji strategii zerowego zaufania.
Budować samemu czy kupować?
Na jednym poziomie zero zaufania to metodologia – sposób na zorganizowanie sieci. Teoretycznie można samemu zbudować implementację zerowego zaufania, korzystając z komponentów dostępnych w środowisku linuksowym. Można też skorzystać z usług firm specjalizujących się we wdrożeniach tego typu architektury. BeyondCorp Google’a ma już kilkanaście lat, nie jest to więc jakaś zupełnie nowa, jeszcze nieprzetestowana technologia.
Każdy, kto chce szybko i kompleksowo wprowadzić zerowe zaufanie, może skorzystać z usług Google. Ale jest oczywiście pewien haczyk: jeśli zamówimy w Google usługi codziennego użytku, takie jak poczta elektroniczna lub aplikacje biurowe, nasze dane nieuchronnie trafią do chmury Google. Jednak chmura ta jest doskonale przygotowana na zerowe zaufanie, ponieważ obsługuje połączenie z Active Directory i innymi mechanizmami uwierzytelniania oraz pozwala w spójny sposób zarządzać uprawnieniami w całym uniwersum Google.
Inni dostawcy usług również pomagają w migracji do modelu zerowego zaufania. Ich oferta obejmuje zarówno usługi doradcze, jak i gotowe pakiety chmurowe. Z europejskiego punktu widzenia we wszystkich kontaktach z dostawcami mającymi siedzibę w USA należy pamiętać, że nie da się pogodzić amerykańskiej ustawy CLOUD i RODO. Firma europejska nie może przejść na zerowe zaufanie z dnia na dzień – wymagane jest długoterminowe planowanie, by zapewnić zgodność z wymogami RODO.
Niezbędna innowacja
Jak najszybsze przejście na zerowe zaufanie nie jest złym pomysłem. Przeciążone bramy VPN i zbiór starych reguł zapory sieciowej, których nikt już nie rozumie (bo zostały utworzonych przez pracowników, którzy odeszli z firmy wiele lat temu), nie są w stanie sprostać dzisiejszym zagrożeniom. Lepiej podjąć radykalne kroki, niż kurczowo trzymać się zabezpieczeń z lat 90. XX wieku.
