Podkast 22T17 ZTNA – Zero Trust Network Access

WERSJA TEKSTOWA

Cześć, witam Cię w kolejnym odcinku mojego podkastu. Dzisiejszy temat to ZTNA, czyli Zero Trust Network Access.

Co to jest?

Jest to koncepcja, która została przedstawiona przez Gartnera i dotyczy przede wszystkim rozproszonych środowisk i takowej koncepcji bezpieczeństwa, która mówi, że dostęp do aplikacji będziemy udostępniać tylko określonym osobom i dla określonych konkretnych zasobów. Czyli jeśli nie mamy zdefiniowanej polityki dostępu, tzn, że taka osoba czy urządzenie nie dostanie dostępu do niczego. Dzięki temu mamy możliwość lepszego kontrolowania co z czym może się łączyć.

Jaka jest różnica pomiędzy tym nowym podejściem a tym co dzisiaj znamy?

Dziś tak naprawdę robimy podobne rzeczy, jeśli mówimy o takich implementacjach tzw. On-Premise, czyli w lokalizacji firmy, bazując na jakiejś infrastrukturze Firewall-i. Mówimy o tym, że dobrze, definiujemy do jakiej grupy dany system należy, definiujemy do jakiej grupy użytkownik należy a potem definiujemy politykę dostępu pomiędzy tymi dwoma grupami. Co jednak się stanie, jeżeli mamy bardziej rozproszone środowisko, czyli nasz ruch, który będziemy poddawać tym regułom, nie przechodzi centralnie przez naszego Firewalla lub klaster Firewall-i. Czyli mamy możliwość rozpraszania systemów w chmurze, w zasobach różnego typu i w różnych miejscach zlokalizowanych. Wtedy taka koncepcja centralnego filtrowania ruchu polityki centralnej w jednym miejscu się porostu zwyczajnie nie sprawdzi, bo ten ruch nie jest centralny.

Tu się pojawia problem jak tym zarządzić. Mamy oczywiście dzisiaj bardzo duże już doświadczenie w dostępie do różnych aplikacji w modelu SaaS, czyli np Microsoft Office 365, gdzie porostu się logujemy do danego systemu przez przeglądarkę. To podejście ma jednak tą dużą wadę, że wystawiamy taki system do styku z Internetem a większość systemów firmowych nie ma takiej potrzeby, czyli nie musi być dostępna publicznie dla wszystkich użytkowników Internetu, bo to oczywiście zwiększa skalę zagrożenia i potencjalnego ataku. Jeśli zostanie znaleziona jakaś podatność dla systemu X, a my ten system X wystawiamy do Internetu, to automatycznie jesteśmy dodatkowo narażeni. Jest oczywiście z tym związany dodatkowy problem, że najczęściej nie nadążamy z patchowaniem odpowiednich systemów. Czyli nawet jeśli mamy wiedzę, na temat tego, że jest już poprawka bezpieczeństwa dotycząca danego systemu, to jak mamy tych systemów wiele: dziesiątki, setki, to nawet zastosowanie tych patchy, tych poprawek jest problematyczne i zajmuje czas. Tym samym ten czas, który nam jest potrzebny do zpatchowania danego systemu, jest okresem, w którym jesteśmy narażeni na potencjalne ataki. W związku z tym, jest to potężny problem i m.in. Gartner sugeruje ukrywanie zasobów, które nie muszą być wystawione publicznie za VPN-em. Czyli mówimy teraz o takiej formie, że mamy często rozproszone systemy w różnych miejscach, nie musimy ich wystawiać publicznie do Internetu, ale musimy w jakiś sposób tych naszych użytkowników do tych systemów podłączyć. Tutaj ten model VPN-owy, czyli najpierw łączymy się VPNem do zdalnego środowiska a następnie za tym VPNem, koncentratorem, mamy dany system. Już nas dodatkowo zabezpiecza, czyli daje nam dodatkową warstwę bezpieczeństwa z puntu widzenia architektury i naszej infrastruktury.

W takich rozwiązaniach chmurowych nie ma możliwości fizycznego zastosowana Firewalla. Bazujemy na wirtualnych maszynach, co nie jest najczęściej problemem, bo przy dzisiejszych procesorach jest to zupełnie wystarczające. Jest tutaj natomiast wyzwanie dotyczące kierowania ruchem. Jeśli mamy tą rozproszoną strukturę, to musimy mieć jakieś narzędzie, które powie naszemu klientowi stacji końcowej, gdzie, za jakim VPN-em jest odpowiedni system. Tutaj właśnie te systemy z ZTNA dają taką możliwość. Automatyzują tą formę sterowania ruchem. Jeżeli słyszałeś coś kiedyś o takich sieciach SD-WAN to tu jest zbieżność tego tematu. W dużym skrócie SD-WAN mówi, że z danej lokalizacji, gdzie mamy urządzenie typu gateway SD-WAN-owy, możemy kierować ruchem do różnych lokalizacji, w zależności od różnych parametrów. SD-WAN zakłada, że mówimy o takim brzegowym urządzeniu per lokalizacja. Dobrze się to nadaje do sytuacji, gdzie mamy wielu użytkowników w jakiś zdalnych lokalizacjach bądź w lokalizacji centralnej i wchodzimy do systemów chmurowych. Natomiast jeśli mamy taką sytuację, że mamy pojedynczych użytkowników, rozproszonych np w domach, to tutaj SD-WAN się nie sprawdzi, ponieważ mamy pojedynczego użytkownika w dostępie typowym internetowym jednego łącza i nie mamy za bardzo jakiejś innej alternatywy w kontekście ISPs. W związku z tym podejście ZTNA czyli łączenia VPN-ów jest tutaj rozwiązaniem bardziej pasującym, dla takich użytkowników pracujących zdalnie czy hybrydowo, możemy stosować takie podejście, że VPN-y zapinamy do różnych terminatorów VPN-ów, do koncentratorów, a za nimi mamy zdefiniowane konkretne aplikacje. Śledzimy to, kto się łączy do jakiej aplikacji, jesteśmy w stanie nadać politykę bezpieczeństwa dostępu do takich aplikacji w zależności od tego, jaka jest nasza polityka w stosunku do typów użytkowników. Jesteśmy w stanie to kontrolować w takim środowisku bardziej rozproszonym.

W związku z tym wydaje się, że to podejście ZTNA to coś, co będzie się upowszechniało, będzie nas dotyczyło, jeśli będziemy iść w stronę rozbudowy naszych systemów wewnętrznych o różne rozwiązania chmurowe, zewnętrzne, kolokacje, inne miejsca niż nasza centralna serwerownia i jeden czy dwa centralne klastry Firewalli. Mam nadzieję, że to było dla Ciebie ciekawe, jeśli masz jakieś pytania w tym zakresie to oczywiście pisz w komentarzu. Dziękuję Ci za dziś i do usłyszenia już za tydzień 🙂