Realizacja dostępu opartego na tożsamości z Cisco pxGrid

W tym poście omówię koncepcję sieci opartej na tożsamości i jej komponentów w oparciu o produkty Cisco Systems. Następnie rzucę trochę światła na to, jak wygląda proces z perspektywy każdego węzła funkcjonalnego ekosystemu, w którym Cisco pxGrid jest jednym z podstawowych używanych protokołów.

Dlaczego potrzebujemy dostępu opartego na tożsamości?

Znaczenie podejścia do tożsamości użytkownika w sieciach korporacyjnych opisaliśmy kilka lat temu w artykule Is user identity important. Od tego czasu opracowano kilka nowych koncepcji i produktów różnych dostawców. W portfolio Cisco Systems znajdziemy kompleksowe podejście, które nabiera dojrzałości i widzimy, że wiele firm podąża obecnie w tym modelu.

We wspomnianej koncepcji, wykorzystując Cisco Identity Services Engine (ISE), serce rozwiązania tożsamości, urządzenia Cisco LAN/WLAN, a także produkty zabezpieczające, takie jak firewalle lub urządzenia zabezpieczające pocztę e-mail, współpracują ze sobą, aby zapewnić widoczność sieci end-to-end i być bardziej skuteczne w walce z cyberzagrożeniami.

Tożsamość użytkowników, rozliczanie zdarzeń uwierzytelniających i widoczność ruchu pomagają osiągnąć automatyzację poza granicami sieci, ujednolicenie zasad dostępu i bezpieczeństwa, a także łatwiejszą administrację.

Koncepcja Cisco Digital Network Architecture (DNA) — nazwa Cisco określająca kompleksowe podejście do sieci korporacyjnych — nie dotyczy tylko tożsamości, jednakże tożsamość jest jednym z kluczowych aspektów uzyskania kontrolowanego, zautomatyzowanego i zabezpieczonego środowiska sieciowego. Tożsamość w tym kontekście sprawia, że ​​sieć jest bardziej świadoma użytkowników, a nie prefiksów IP, co z kolei pomaga w konstruowaniu uniwersalnych polityk bezpieczeństwa, lepiej się skaluje, szczególnie w dużych organizacjach z wieloma lokalizacjami i zapewnia szczegółową kontrolę dostępu i rozliczanie użytkowników.

Cisco pxGrid

Jednym z kluczowych terminów stojących za kompleksową tożsamością jest Cisco pxGrid, protokół będący obecnie standardem zatwierdzonym przez IETF, opisany w RFC 8600 i opublikowany w czerwcu 2019 r. pxGrid oznacza Platform Exchange Grid i umożliwia międzyplatformową wymianę informacji w w odniesieniu do konkretnego kontekstu danych. Architektura pxGrid opiera się na podejściu Publish-Subscription, w którym Konsumenci danych subskrybują dany Temat, a Dostawca publikuje informacje na ten temat, które z kolei Broker dystrybuuje do wszystkich subskrybowanych konsumentów.

Informacje, które można udostępniać za pomocą danych pxGrid, mogą być wykorzystywane przez systemy monitorowania i wykrywania bezpieczeństwa, platformy zasad sieciowych, IAM lub inne produkty infrastruktury IT, które mogą korzystać z tych danych. Jednym z typów danych w naszym przypadku jest mapowanie tożsamości użytkownika na adres IP, które konsumenci pobierają dzięki komunikacji pxGrid.

Ekosystem pxGrid i schemat komunikacji

Na poniższym schemacie przedstawiono przepływ komunikacji w płaszczyźnie sterującej, która jest używana do propagowania informacji o użytkowniku pobranych i przeanalizowanych przez ISE podczas procesu uwierzytelniania 802.1x.

Informacje są przekazywane z ISE do Firepower Management Center, które jest centralną konsolą zarządzania dla zapór Internet Edge i Data Center. Z kolei informacje o użytkowniku zawierające nazwę użytkownika i aktualny adres IP są przekazywane do urządzeń Firepower (lub ASA z usługami FirePOWER). Na podstawie podanych informacji o mapowaniu użytkownika na adres IP zapory ogniowe mogą egzekwować reguły bezpieczeństwa w oparciu o nazwę użytkownika lub tożsamość grupy AD, a nie adres IP.

Jak wygląda proces?

Użytkownik uwierzytelnia się jako pierwszy. Nie ma znaczenia, czy typ uwierzytelniania jest przewodowy czy bezprzewodowy. W naszym przypadku natywny suplikant systemu Windows 10 jest używany do uwierzytelniania za pośrednictwem przełącznika Ethernet obsługującego standard 802.1x.

Na panelu dzienników na żywo ISE możemy teraz zobaczyć, że użytkownik jest uwierzytelniony i autoryzowany.

Czasami przy rozwiązywaniu problemów pomocne jest sprawdzenie informacji na poziomie przełącznika. Tutaj Catalyst 2960X działa jako NAD (Network Access Device), dlatego może być również częścią procesu diagnostycznego. Informacje na temat switchport odzwierciedlają to, co mamy w dziennikach na żywo ISE (port, mac, IP, nazwa użytkownika i inne).

W tle protokół pxGrid służy do raportowania informacji o zdarzeniu do Konsumenta, którym jest Firepower Management Center (FMC).

Zatem to, co właśnie osiągnęliśmy, to kompleksowy proces AAA, który prowadzi do udostępnienia informacji o nazwie użytkownika na adres IP Konsumentowi pxGrid (FMC). Aby móc skorzystać z tego rodzaju danych, powinniśmy mieć w naszej sieci jakieś urządzenie Firepower, które będzie w stanie wymusić pewne reguły oparte na tożsamości dla tego konkretnego użytkownika lub jego grupy AD. W moim przypadku testowym reguła dla Użytkownika 1 jest trywialna, po prostu blokuje ruch ICMP do wersji 8.8.8.8, jednak pokazuje zastosowanie informacji o tożsamości w Polityce kontroli dostępu Firepower (ACP).

Mówiąc o kompleksowym portfolio produktów, należy wspomnieć o kolejnym typie dostępu, jakim jest zdalny dostęp VPN. Użytkownik korzystający z klienta Cisco Anyconnect Secure Mobility powinien podlegać tym samym zasadom bezpieczeństwa, niezależnie od tego, gdzie się znajduje. W kolejnym artykule pokazuję konfigurację zdalnego dostępu VPN przy użyciu uwierzytelniania wieloskładnikowego Anyconnect i Duo Security, które zostanie zintegrowane z powyższym ekosystemem. Informacje o tożsamości pochodzące ze zdarzenia połączenia dostępu zdalnego VPN będą dostępne również dla zestawu reguł Firepower ACP.

Stay connected!