Więcej miejsc do posłuchania:
WERSJA TEKSTOWA
Cześć, witam Cię w moim odcinku podkastu, dzisiejszy temat poruszy, czy w Zero Trust Network Access jest potrzebny serwer Radius. Odpowiedź jest prosta – tak. Teraz zagłębie się w to dlaczego. Założenie koncepcji Zero Trust Network Access jest takie, że dajemy dostęp do zasobów naszej firmy tylko dla uprawnionych, zweryfikowanych użytkowników ze znanym kontekstem i wiemy z jakiego urządzenia się łączą. Jak to możemy osiągnąć jeżeli mamy pracownika w biurze, w sieci korporacyjnej i chcemy taką koncepcję Zero Trust Network Access zrealizować? Potrzebujemy serwer Radius. Dlatego, że chcemy mieć pewność kto łączy się do naszej sieci, niezależnie czy przewodowo czy bezprzewodowo i jaki poziom uprawnień powinniśmy do tego użytkownika przypisać.
W przypadku Radiusa mamy całą masę różnych możliwości jak go implementować, różnych producentów rozwiązań Radiusowych, mamy rozwiązania bezpłatne, rozwiązania dołączone do routerów. Cała gamą możliwości, należy je dobrać do tego co możesz zrealizować. Pierwsze pytanie czy masz na to fundusze – czy będzie to system płatny czy bezpłatny. Za chwilę opowiem jakie największe różnice widzę ze swojego doświadczenia. Następnie pytanie czy będziesz realizował na osobnym serwerze, czy w ramach zintegrowanej usługi na np. takim Mikrotiku czy na swoim innym routerze realizował taką funkcjonalność i jakie są zalety i wady tego podejścia.
Zacznijmy od tego płatny czy bezpłatny – oczywiście w zależności od tego czy dysponujesz funduszem. To jest najbardziej kluczowy czynnik. Jeżeli masz budżet to zdecydowanie lepiej iść w stronę jakiegoś płatnego rozwiązania bo ma kilka różnych zalet. Pierwsze najważniejsze kryterium to jest to, że masz wsparcie. Jeżeli będziesz miał problem, możesz się do kogoś zgłosić i poprosić o pomoc. Drugi najważniejszy element jest taki, że w urządzeniach komercyjnych – płatnych najczęściej masz klastrowanie serwerów Radius. Ponieważ taki serwer Radius jest krytycznym komponentem każdej takiej instalacji firmowej, w zasadzie każdej ponieważ jeśli zakładasz, że to będzie pełne wymuszanie dostępu i masz różnicowanie pomiędzy typami użytkowników to potrzebujesz tego systemu, żeby on działał cały czas. Gdy przestanie on działać to masz dwie opcje.
Pierwsza to nie wpuszczasz użytkowników do sieci, czyli nie mogą pracować. Druga – wpuszczasz z jednym uprawnieniem co też jest generalnie słabym rozwiązaniem bo najczęściej ta koncepcja sieciowa czyli np. adresacja, podzielenie pomiędzy dostępy np. telefony i użytkowników albo użytkowników wewnętrznych i zewnętrznych lub urządzenia po MAC Authentication – to są różne grupy użytkowników, których chcesz rozdzielić. Gdy przestaje Ci taki serwer Radius działać, to nie masz możliwości rozdzielenia tego. Założenie jest najczęściej takie, że ten system musi działać cały czas, jest krytyczny.
W przypadku rozwiązania darmowego, jest pewien rodzaj zapewnienia sobie takiej funkcjonalności – mianowicie możesz bez klastrowania bazować tylko na niezawodności środowiska wirtualnego. Jeżeli masz u siebie jakieś wirtualne środowisko zbudowane i jest ono w jakimś trybie HA to możesz założyć taki tryb, że Radius nie będzie klastrem tylko będzie pojedynczą maszyną a jeżeli będzie problem z jakimś elementem serwerowym to nasz serwer zostanie przeniesiony na inną maszynę fizyczną tak żeby swój wirtualny byt dalej podtrzymywał. W przypadku problemu z odtworzeniem to też jesteś w stanie w miarę szybko w mniejszym środowisku odtworzyć taki serwer Radius. To jest już kwestia wybalansowania – jeśli masz środki to lepiej to robić na zasadzie klastra. Jeżeli nie masz to możesz rozważyć system jako oparcie HA o system wirtualny.
Idąc dalej, implementacja pomiędzy dedykowanym serwerem Radius a serwerem zaimplementowanym np. na routerze. Plusy tego na routerze są takie, że nie musisz tworzyć dodatkowej infrastruktury. Co się jednak stanie jeśli padnie Ci ten jeden router? Nie masz niczego. Więc gdy Twoja struktura jest taka, że masz i tak tylko jeden router i wszystko jest od niego uzależnione, to nie jest problem. Zakładasz, że jak padnie to padnie wszystko i tak nie ma do niczego dostępu. W tym scenariuszu można rozważyć implementowanie systemu Radius na routerze. Widzę tu jeszcze jeden minus – masz bardzo ograniczone możliwości dostosowywania tego Radiusa do tego co byś chciał, żeby dla Ciebie robił. W przypadku bardzo prostego scenariusza na zasadzie wpuszczę, nie wpuszczę, myślę że implementacja Radiusa na routerze jest tutaj do rozważenia.
Jeżeli chcesz mieć to rozwiązanie bardziej skalowalne, czyli móc dostosowywać sobie do różnych zastosowań, pisać więcej serwisów, polityk, sprawdzać czy one działają, rozróżniać różne typy urządzeń to moim zdaniem lepiej jest postawić serwer zewnętrzny. Nawet jeśli ma to być Free Radius czyli Radius bezpłatny to tam będziesz mógł skonfigurować więcej serwisów. Będziesz mógł je rozdzielić. Masz dużo większą elastyczność tego, co robisz. Kolejna rzecz jest taka, że jeżeli rozdzielisz te systemy (czyli nie robisz wszystkiego na jednym routerze), to w przypadku kiedy będziesz chciał np. aktualizować dany komponent to nie musisz aktualizować wszystkiego naraz. Możesz zrobić aktualizację Radiusa nie aktualizując routera. Możesz zrobić aktualizację routera nie aktualizując Radiusa.
To są plusy, które na pewno warto rozważyć, jeżeli są te środowiska troszeczkę większe, jeżeli jest to bardzo małe środowisko, nie masz systemu serwerowego czyli jakiejś wirtualizacji. Masz tylko ten jeden router, jednego np. takiego Mikrotika to można robić wszystko na tym jednym i zakładać, że jak padnie to wszystko musisz odtworzyć, czyli lepiej sobie robić backup’y aby móc sobie łatwo ten router łatwo odtworzyć. Na zasadzie kupię albo najlepiej już mieć takie zapasowe urządzenie i je po prostu tylko przywrócić z tego backup’u.
Możesz też rozważyć kopiowanie tej konfiguracji. Tylko to jest oczywiście trochę uciążliwe. Czyli taki klaster ale manualny. Na zasadzie – skonfiguruję sobie pełną funkcjonalność na jednym routerze, zrobię backup i odtworzę też na drugim. Oczywiście na drugim routerze musisz tylko uwzględnić adresację bo ta część nie może się połączyć czy powtarzać pomiędzy routerami. Jeżeli jednak zrobisz jeszcze VRRP pomiędzy tymi dwoma routerami, czyli będzie jeden wirtualny adres IP, który będzie się tylko przełączać pomiędzy tymi dwoma routerami to wtedy jest to jakieś rozwiązanie, koncepcja która jest HA. Wymaga wprawdzie od Ciebie ręcznej synchronizacji – musisz za każdym razem robić backup, przywracać, zmieniać adresację i tego typu rzeczy. Jest to uciążliwe i sam bym tego manualnie nie robił.
Jeśli chciałbyś coś robić sam własnymi rękami to jest opcja, że taki skrypt możesz sobie wymyślić i napisać. Skrypt, który by synchronizował różne informacje pomiędzy tymi routerami. Np. informacje o użytkownikach bo jeżeli dodasz nowego użytkownika w zależności od tego czy masz domenę czy nie – zakładam, że coś zmieniasz na jednym Radiusie, to na drugim powinieneś mieć odtworzenie tej samej konfiguracji. Więc jeżeli miałbyś skrypt który np. cyklicznie robi kopię z jednego do drugiego i skonfigurowałbyś VRRP to taki scenariusz może zadziałać i on prawdopodobnie jest najlepszy z możliwych, które możesz zaimplementować jeżeli masz takie proste środowisko, nie masz żadnego systemu wirtualizacji i nie możesz tego sobie podzielić.
Więc ja widzę takie aspekty stosowania systemu Radius w koncepcji Zero Trust Network Access. To nadal jest kwestia oczywiście przy tym ZTNA, tak jak już pewnie słyszałeś jeśli oglądałeś moje poprzednie odcinki podkastu, automatyzacji. Gdy chcesz podwyższać poziom bezpieczeństwa to musisz automatyzować pewne rzeczy bo inaczej będzie Ci bardzo trudno to utrzymywać. W przypadku jak chcesz tą automatyzację robić sam, sam robić skrypty to pewnie, jest to jakieś rozwiązanie. Oczywiście jest ono bardzo dobre, jeżeli tylko Ty nad tym pracujesz, Ty rozumiesz co robisz i pamiętasz, masz dobrze udokumentowane te skrypty. Natomiast jeśli ma być to forma współpracy między wieloma osobami, to już manualne skrypty prawdopodobnie są bardzo trudne do utrzymania bo nadal wiedzę o tych skryptach będzie miała jedna osoba. Tu się tworzy problem operacyjny.
Gdy rozważasz rozwiązania komercyjne to tu jest dużo łatwiej w kontekście tego, że różne elementy, które są istotne dla firmowych zastosowań Radiusa są po prostu gotowe. Czyli masz np. budowę klastra systemów Radius. Za każdym razem jak zmieniasz na jednym serwerze Radius tą swoją konfiguracje, automatycznie replikuje się ona na wszystkie inne. Jeżeli jest z tym jakiś problem to masz wsparcie tego producenta, który może i powinien pomóc w tym zakresie – jeżeli dana funkcjonalność danego produktu nie działa. Więc to też jest duży plus. Gdy oprócz tego przy komercyjnych produktach również chciałbyś jakieś swoje skrypty pisać to jest taka możliwość. Większość a w zasadzie wszystkie systemy Radius, które teraz znam udostępniają jakąś formę dostępu – najczęściej po API i możesz sobie wtedy pewne rzeczy odczytywać, zapisywać, wysyłać, odbierać. Tu jest tylko taki minus, że oczywiście z wersji na wersję API może się nieco zmienić. To oznacza, że Twoje skrypty mogą przestać działać więc jesteś uzależniony od tego jak stabilne czy niezmienialne będzie API, które wywołujesz i z którego korzystasz.
To jest problem ogólnie znany i każdy się z nim mierzy jeżeli chce robić integracje pomiędzy systemami. Tutaj jest ciekawa rzecz do rozważenia bo jeżeli myślisz o tym, żeby API było bardziej stabilne to częściej jest tak, że albo trzeba wybierać produkty już w miarę dojrzałe albo rozważać produkty chmurowe. Z chmurowymi produktami jest tak, że mają one tą zaletę, że z założenia dużo więcej integracji jest wykonywanych przez jakieś API z dawnym systemem chmurowym. W związku z tym presja na producenta takiego rozwiązania jest taka, żeby nie zmieniać tego API bardzo często bo dodaje to pracy innym firmom, osobom, które z tego korzystają. W związku z tym najcześciej jest utrzymywany ten zakres funkcjonalny, który był niezmieniony. Jeśli chciałbyś coś innego uzyskać to wtedy nowe funkcje możesz ewentualnie wywoływać.
W systemie chmurowym jest jeszcze najczęściej tak, niezależnie od tego jaki to jest producent, założenie jest takie, że są ściśle określone scenariusze czyli use case. Jeżeli masz sytuację, która pasuje do danego use case to będziesz miał powtarzalny scenariusz, będziesz mógł integrować łatwiej inne systemy trzecie z takimi chmurowymi systemami i to jest jednocześnie też wada. Jeżeli masz większą firmę, masz dużo systemów już zaimplementowanych to może ten chmurowy system po prostu do Ciebie nie pasować. Pomijając te aspekty wątpliwości wysyłania danych do chmury gdzie one są przechowywane, jakie jest ich bezpieczeństwo, te różne typowe pytania rozwiązań chmurowych to jednak w zależności od tego o jakim scenariuszu rozmawiamy, jeśli jest to mniejsza firma to moim zdaniem tutaj warto szybciej rozważać rozwiązanie chmurowe, jeżeli firma jest większa to w zależności od tego w którym miejscu dojrzałości ta firma jest i czy zaczyna korzystać z systemów chmurowych.
Zauważ, że jeśli już korzystasz z jakiś krytycznych systemów, które dla Twojej firmy są zaimplementowane w chmurze to znaczy, że też już zaczynasz mieć takie pytania i dylematy jak tą chmurę podłączyć z tym co masz obecnie, jak to zabezpieczyć, jak to podłączyć razem z systemami, które używasz on-prem czyli u Ciebie w Data Center. Więc to są wszystko rzeczy, które trzeba wziąć pod uwagę. Nie ma tutaj jakiś super gotowych recept na wszystko, zwłaszcza w kontekście obecnej sytuacji, czyli większość zaimplementowanych w swojej serwerowni dlatego, że każdy ma najczęściej troszeczkę inaczej to zrobione. W związku z tym jest pytanie z tego miejsca, w którym jest jak może pójść do takiego rozwiązania Radiusowego czy on-premowego czy chmurowego to po prostu trzeba się chwile zastanowić, jaką ścieżkę najlepiej wybrać bo jak wspomniałem wcześniej to jeszcze tylko raz powtórzę – ten system Radiusowy będzie systemem krytycznym.
Wszelkie zmiany w tym systemie: implementacja, migracja będą bardzo problematyczne więc trzeba to dobrze przemyśleć jak do tego podejść i jak to zrealizować. Na dzisiaj to tyle, dziękuję Ci za uwagę i do usłyszenia już za tydzień.
