Więcej miejsc do posłuchania:
WERSJA TEKSTOWA
Witam Cię w dzisiejszym odcinku mojego podkastu, temat to ZTNA i IF-MAP oraz Firewall. Chodzi o to, że IF-MAP jest to protokół, który potrafi przekazywać informacje o sesjach użytkowników. Jakie to ma znaczenie z koncepcją ZTNA? ZTNA w kontekście lokalnego dostępu korporacyjnego zakłada, że wiemy o użytkowniku kto to jest, wiemy z jakiej stacji się łączy i do jakich aplikacji ma mieć dostęp. Czyli potrzebujemy również serwer Radius. Wiadomo ale oprócz tego najczęściej potrzebujemy też komunikacji pomiędzy serwerem Radius a Firewallem.
Chodzi o to żeby wysyłać tą informację o użytkowniku nie tylko do przełącznika Access Pointa ale również do Firewalla. Dzięki temu mamy możliwość najczęściej zaimplementowania polityk aplikacyjnych w dostępie korporacyjnym co znacznie nawet rozszerza poziom możliwości i nasze bezpieczeństwo w sieci. Czyli jesteśmy bardziej konkretnie przypisać dostęp do konkretnych aplikacji – to co w ZTNA jest sednem. Czyli ograniczenie ilości dostępu do poszczególnych systemów ale jak tą informacje przekazać?
No więc możemy użyć takiego protokołu, który się nazywa IF-MAP. Potrafi on wymienić informacje pomiędzy systemem Radiusowym – jaki to jest użytkownik, jaką ma mieć przypisaną rolę – i innymi systemami. Systemami NAC, systemami VPN, systemami webowymi, dowolnym systemem gdzie mamy informacje o użytkowniku i możemy tą informację przesłać. Dzięki temu mamy możliwość skonstruowania takiego konceptu, który nam umożliwia wymuszanie pewnych reguł na Firewallu a jednocześnie wiązanie tej informacji o użytkowniku i VPNowym i NACowym.
W bardziej rozbudowanych scenariuszach są klienci, którzy używają tego typu podejścia do wewnętrznych VPNów. Czyli jeżeli ktoś wewnątrz ma krytyczne systemy, które chce udostępniać tylko konkretnej grupie użytkowników i nie ufa jakby całej pozostałej części infrastruktury to ma możliwość spięcia wewnętrznego VPNa tylko konkretnie dla tych użytkowników. Jest to jedna z możliwości, natomiast chcielibyśmy żeby to spinanie VPN było nie zauważalne dla danego użytkownika. Czyli żeby on na przykład i logowanie do sieci 802.1x i spinanie VPNa mógł zrealizować automatycznie.
Co więcej jeżeli mamy możliwości czy mamy taką potrzebę to możemy również do innych systemów używać tej informacji o sesji. Czyli raz uwierzytelniony użytkownik może być uwierzytelniany czy od razu traktowany jako znany użytkownik w różnych innych systemach. Co do zasady podejście jest świetne i bardzo dobrze się sprawdza. Jest jeszcze jeden element, który w praktyce mogę od razu podpowiedzieć, że się świetnie sprawdza. Jeżeli to są duże sieci i mamy tych użytkowników na tysiące i mamy bardzo skomplikowane jeszcze wieloregułowe zasady bezpieczeństwa, to wyniesienie enforcement’u czyli zasady użycia na Firewall, jest elementem bardzo pożądanym nie tylko ze względu na wymuszanie aplikacyjne ale również ze względu na skalowanie.
Jeżeli popatrzysz sobie na to ile reguł możesz zastosować na takim przełączniku czy na Access Poincie czy też na kontrolerze bezprzewodowym. Lub na to ile możesz takich reguł zastosować w VPNie vs to ile możesz zastosować takich reguł na Firewallu, to to jest element który ewidentnie się skaluje bardzo dobrze i chciałem powiedzieć, że ja znam konkretne przypadki i projekty gdzie to podejście było jedynym możliwym do zrealizowania. Ponieważ jeżeli popatrzysz sobie na to, że chciałbyś mieć na przykład tych ról 20, 30, 100, obojętnie i dla każdej z tych ról masz inny zestaw reguł ACL, czyli masz bardzo dużą multiplikację ilości wpisów na końcu.
Czyli każdy użytkownik, który się łączy z innym profilem i ma inne zestawy reguł musi mieć odpowiednią nową listę swoich wpisów w ACL’ce wpisane. Powoduje to, że każdy użytkownik w zależności od skomplikowania idei, będzie tych wpisów generował kilkanaście, kilkadziesiąt. To teraz jeżeli masz na tysiące użytkowników, którzy się łączą, to efekt jest tego taki, że po prostu osiągasz często limit danej platformy i przeniesienie tej funkcjonalności na Firewalla jest bardzo pożądane. Skaluje się i ma dużo większe możliwości.
Może jeszcze warto powiedzieć jak jest realizowane to przypisanie na Firewall. Czyli załóżmy, że łączysz się tym VPNem, masz uwierzytelnienie użytkownika, jest serwer IF-MAPowy do którego najpierw jest wysyłana ta informacja systemu VPN, że użytkownik o takim adresie IP, to jest taki Jan Kowalski i mamy jakieś dodatkowe atrybuty, na zasadzie jaka rola ma być przypisana. Ta informacja jest wysyłana do Firewalla. Firewall ma skonfigurowane dynamiczne grupy bezpieczeństwa, które mają już konkretne reguły sformułowane.
Chodzi o to, żeby tego użytkownika, który się właśnie zalogował przez VPN i podłączył do sieci, żeby go dodać do dynamicznej grupy na Firewall. W ten sposób jesteśmy w stanie zaaplikować dany schemat bezpieczeństwa dla danej roli, dla tego konkretnego użytkownika. Jeżeli chodzi o systemy NAC działa to bardzo podobnie. Czyli użytkownik loguje się do sieci przewodowej lub bezprzewodowej, ma przypisaną jakąś rolę, jakiś atrybut przez Radiusa. Ta informacja jest wysyłana ze strony serwera Radiusowego, do serwera IF-MAPowego a ten serwer synchronizuje sesję z Firewallem i na tej podstawie jest przypisywany użytkownik do dynamicznej grupy na Firewall.
Możesz oczywiście pewne reguły podstawowe zaimplementować na punkcie dostępowym, kontrolerze bezprzewodowym albo na przełączniku ale jeżeli chodzi o bardziej zaawansowane reguły albo większą ich ilość to możesz zaimplementować na Firewallu. Tutaj już to jak to wybierzesz zależy od ciebie. Plusy są takie, że jeżeli na przełączniku albo na punkcie dostępowym zastosujesz pewną regułę, to ona już działa na tym pierwszym poziomie. Czyli jeżeli chciałbyś na przykład ograniczyć, że ten użytkownik może się łączyć tylko do internetu a z innymi użytkownikami w danej sieci WLAN albo w danej sieci bezprzewodowej nie może, to tą regułę powinieneś zastosować na urządzeniu dostępowym.
Natomiast jeżeli już chciałbyś stosować reguły dotyczące na przykład systemów docelowych, aplikacyjnych, do których ma ten użytkownik mieć dostęp i te systemy zawsze stoją za Firewallem, to tu nie ma problemu. Najlepiej te wszystkie reguły implementować na Firewallu bo ten jeden punkt albo jeden klaster, najczęściej Firewalli jest najlepszym miejscem do tego, żeby wymuszać naszą politykę bezpieczeństwa i mieć jasność co gdzie stosujemy. Czyli jeżeli bardzo proste reguły na brzegu sieci stosujemy, że na zasadzie: tylko do internetu albo do naszych wewnętrznych systemów Data Center może się łączyć dany użytkownik, to wiemy, że tylko te reguły są stosowane na brzegu a wszystkie pozostałe są na Firewalu.
Jeżeli jest jakiś problem, ktoś nie może się do czegoś połączyć, to na tym Firewallu możemy sobie to łatwo sprawdzać. Co więcej możemy na bieżąco albo w logach historycznie sprawdzać czy dany użytkownik został przypisany do tej grupy dynamicznej, czy nie. Czy do właściwej grupy dynamicznej czy do innej jest nam łatwo wtedy tym zarządzać i ewentualnie rozwiązywać potencjalne problemy. Jeśli widzimy, że jakieś zgłoszenia są i trzeba sprawdzać co, gdzie nie zadziałało, to cały ten proces, tych wielu komponentów (jak widzisz jest tu kilka poszczególnych etapów), łatwo jest prześledzić, mając informacje o tym co, gdzie się wydarzyło.
Sam serwer IF-MAPowy jest relatywnie prostym rozwiązaniem, więc tutaj nie ma jakiegoś dużego skomplikowania tego rozwiązania, tam jest po prostu tylko tablica sesji użytkowników oraz wpisywanie i zdejmowanie tych informacji. Jest to w zasadzie tyle, więc trzymanie tego całego schematu prostego też jest bardzo pozytywne dlatego, że łatwiej jest trableshooting robić czyli rozwiązywać problemy. Na dzisiaj to tyle, jeżeli masz jakieś pytania co do tego tematu to oczywiście zapraszam – pisz w komentarzu. Jeżeli nie to dziękuję za uwagę i do usłyszenia już za tydzień.
