ZTNA

ZTNA (Zero Trust Network Access) to sposób zdalnego dostępu, w którym użytkownik po sprawdzeniu tożsamości i stanu urządzenia dostaje połączenie z jedną konkretną aplikacją, a nie z całą siecią. Jest praktycznym wdrożeniem modelu Zero Trust: NIST opisuje go jako odejście od obrony opartej na statycznym obwodzie sieci na rzecz ochrony użytkowników, zasobów i danych ^[1]. Nikt nie dostaje zaufania tylko dlatego, że łączy się z określonej sieci, a uwierzytelnienie i autoryzacja odbywają się, zanim powstanie sesja z zasobem ^[1]. Nazwa pochodzi z raportu rynkowego analityka Gartnera Steve'a Rileya z 2019 roku ^[2].

Jak działa

Klasyczny VPN najpierw wpuszcza do sieci, a potem użytkownik szuka w niej usług. ZTNA odwraca kolejność: najpierw uwierzytelnienie, potem połączenie z konkretną aplikacją ^[2]. Keeper Security ujmuje różnicę tak, że VPN po zestawieniu połączenia daje dostęp do całej sieci, a ZTNA egzekwuje kontrolę dostępu na podstawie tożsamości użytkownika i kontekstu ^[4].

Architektura NIST SP 800-207 dzieli mechanizm na silnik polityk, który podejmuje decyzję, i punkt egzekwowania polityki (PEP), który otwiera, monitoruje i zamyka połączenie między podmiotem a zasobem ^[1]. W najczęstszym modelu na urządzeniu działa agent, a przed zasobem stoi bramka; zasób rozmawia tylko z bramką, która pełni rolę pośrednika ^[1]. Połączenie jest zrywane po zakończeniu pracy albo gdy administrator polityk wykryje zdarzenie bezpieczeństwa, na przykład wygaśnięcie sesji lub nieudane ponowne uwierzytelnienie ^[1].

RYS. 1Dostęp do panelu przez ZTNA

Zasady, na których opiera się ten przepływ, NIST zapisuje wprost. Dostęp do każdego zasobu jest przyznawany na jedną sesję, z najmniejszymi potrzebnymi uprawnieniami, a uwierzytelnienie do jednego zasobu nie daje automatycznie dostępu do innego ^[1]. Decyzja zależy od dynamicznej polityki, która bierze pod uwagę tożsamość klienta, aplikację i stan urządzenia, na przykład zainstalowane wersje oprogramowania, lokalizację i porę żądania ^[1]. To bezpośrednie zastosowanie zasady najmniejszych uprawnień.

ZTNA a VPN

Kapitan Hack opisuje ZTNA jako odejście od tradycyjnego podejścia opartego na obwodzie sieci VPN w stronę modelu skoncentrowanego na tożsamości ^[3]. Ten sam tekst przytacza wzrost liczby zgłaszanych podatności VPN o 32 procent w 2023 roku i o kolejne 35 procent w pierwszej połowie 2024 roku ^[3]. NIST zaznacza jednak, że część ryzyk, na przykład zablokowanie ruchu do punktu egzekwowania polityki, dotyczy także klasycznych VPN i nie jest cechą wyłącznie architektury zero trust ^[1].

W WordPressie

Strona WordPress ma zwykle kilka powierzchni, które nie muszą być publiczne: katalog /wp-admin/, ekran logowania, panel bazy danych w rodzaju phpMyAdmin, środowisko testowe (staging). Dokumentacja WordPressa zaleca już dziś drugą warstwę ochrony przed panelem, na przykład hasło po stronie serwera, i przypomina, że sieć po obu stronach połączenia, serwerowej i klienckiej, powinna być zaufana ^[6]. ZTNA rozwija tę myśl: zamiast drugiego hasła panel stoi za bramką, która sprawdza tożsamość użytkownika u dostawcy tożsamości, zanim przepuści pierwsze żądanie.

Przykładem usługi tego typu jest Cloudflare Access. Dokumentacja opisuje ją jako warstwę uwierzytelniania między użytkownikiem a serwerem źródłowym; każda aplikacja jest domyślnie zablokowana, a dostęp dostaje tylko ten, kto spełnia regułę zezwalającą ^[5]. Reguły można przypiąć do ścieżek z symbolem wieloznacznym, więc chronić sam panel, a nie całą witrynę ^[5]. W połączeniu z tunelem serwer źródłowy pozostaje ukryty; dokumentacja ostrzega, że opublikowanie tunelu bez aplikacji Access udostępnia aplikację każdemu w internecie ^[5].

Na zwykłym hostingu ZTNA dla całej strony jest rzadko potrzebne. Sensowne zastosowania to:

• panel /wp-admin/ i wp-login.php dostępne tylko dla zespołu, co ogranicza ataki siłowe (brute-force) na formularz logowania;
• phpMyAdmin i panele hostingu zamknięte przed publicznym internetem;
• kopia robocza strony widoczna tylko dla klienta i wykonawcy.

Ścieżki, z których korzystają odwiedzający i integracje, na przykład admin-ajax.php albo REST API, trzeba wyłączyć spod bramki albo przetestować, bo zablokowanie ich psuje front strony.

Zagrożenia i ograniczenia

ZTNA przenosi ciężar bezpieczeństwa na tożsamość. Jeśli atakujący przejmie konto u dostawcy tożsamości, na przykład przez phishing AiTM, bramka go przepuści. Dlatego wdrożenie ZTNA zakłada silne uwierzytelnianie wieloskładnikowe (MFA) i porządek w zarządzaniu tożsamością i dostępem. NIST zwraca uwagę, że komponenty decyzyjne mogą być usługą chmurową, a dostawca hostingu może je przypadkiem wyłączyć, co odcina użytkowników od zasobów ^[1].

ZTNA nie zastępuje też ochrony samej aplikacji. Podatna wtyczka, dostępna przez publiczną część strony, pozostaje podatna; tu potrzebne są aktualizacje i WAF.

Jak wdrażać

1. Spisać zasoby, które nie muszą być publiczne, i ustalić, kto ich potrzebuje.
2. Podłączyć bramkę do jednego źródła tożsamości z MFA.
3. Zacząć od reguły „domyślnie zabroń” i dopisywać konkretne osoby lub grupy ^[5].
4. Dopiero po włączeniu bramki usunąć publiczny dostęp do zasobu, na przykład regułą zapory sieciowej (firewall) wpuszczającą tylko ruch z tunelu.
5. Przeglądać dziennik dostępu i odbierać uprawnienia osobom, które odeszły.

Historia

Model zerowego zaufania zaproponował w 2010 roku John Kindervag z Forrestera ^[2]. Równolegle Google rozwijał od 2009 roku program BeyondCorp, uruchomiony po atakach znanych jako Operation Aurora ^[2]. Termin ZTNA wprowadził w 2019 roku Steve Riley z Gartnera; Kapitan Hack przytacza jego późniejszą uwagę, że trafniejsza byłaby nazwa Zero Trust Application Access, bo sieć jest w tym modelu sprawą drugorzędną ^[2]. NIST opublikował publikację SP 800-207 o architekturze zero trust w sierpniu 2020 roku ^[1].