Warto też zasygnalizować obecność innego rozwiązania autorstwa Cisco - urządzenia NAC Appliance (dawnej Cisco Clean Access). Jest to w zasadzie odrębna platforma (możliwa do zintegrowania z "pełnowartościowym" Cisco NAC), której użycie zwalnia z konieczności wprowadzania rewolucji w infrastrukturze (wymiany sprzętu itp.). Jest to więc rozwiązanie przeznaczone dla tych, którzy chcą mieć "prawie" NAC.

Microsoft - Network Access Protection

Dostarczycielem drugiej z wiodących koncepcji jest Microsoft. W jego wydaniu NAC został ochrzczony nazwą NAP (Network Access Protection). Nazwa inna, a chodzi o to samo. No prawie. Podejście do technologii NAC ze strony Microsoft to przede wszystkim odnajdywanie klientów, którzy nie spełniają wymagań bezpieczeństwa.

Z racji tego, że gigant z Redmond nie produkuje (jak dotąd) urządzeń sieciowych, podejście to jest czysto software'owe. Mówiło się o nim bardzo dużo, zanim jeszcze można je było zobaczyć "w akcji". Pierwszym systemem operacyjnym, w którym zaimplementowano rozwiązanie NAP, jest Microsoft Vista, a to też nie w 100%. Dopiero Longhorn przyniesie pełne wydanie NAP. Nie znaczy to, że posiadacze systemów starszych zostaną na lodzie. Zarówno w Windows XP SP2, jak i Windows 2003 Server są dostępne pewne jego elementy. Jak na razie jednak pełne wsparcie dla funkcjonalności NAP w Windows XP SP2 znajduje się w fazie beta.

Pod względem architektury NAP współgra z określoną przez IETF koncepcją. Przełom sierpnia i września 2006 r. przyniósł nowe rewelacje - Microsoft podjął współpracę z Cisco, mającą na celu sprawienie, że zarówno Microsoft NAP, jak i Cisco NAC będą ze sobą ściśle współpracować. Podobnie jak Cisco także i Microsoft "gromadzi" partnerów, którzy deklarują kompatybilność z NAP (http://www.microsoft.com/windowsserver2003/partners/nappartners.mspx ). Lista jest imponująca. Jak zatem wygląda koncepcja Microsoftu? Po stronie klienta znajdziemy standardowo trzy elementy.

Pierwszym jest System Health Agent (SHA), który odpowiada za zbieranie oraz przekazywanie informacji o "stanie zdrowia" klienta, czyli np. o tym czy zainstalowane jest odpowiednie oprogramowanie antywirusowe, czy firewall jest włączony itp. Pełni on więc rolę weryfikatora stanu.

Drugim składnikiem jest NAP Enforcement Client (NEC), który pełni rolę oprogramowania łączącego klienta z infrastrukturą. W ramach NEC udostępniane są następujące komponenty: suplikant 802.1x, klient VPN obsługujący standardy PPTP, L2TP oraz IPSEC czy klient DHCP.

Wreszcie trzecim ze składników jest agent NAP, który działa jako pośrednik pomiędzy SHA i NEC i koordynuje ich działanie. Wszystkie te elementy spina API, które jest dostępne dla innych producentów, którzy chcieliby wykorzystać NAP do badania "zdrowia" poszczególnych elementów systemu. W roli punktów kontroli dostępu występują tutaj głównie serwery VPN oraz coś, co jest charakterystyczne dla NAP - kompatybilne serwery DHCP. Jest tak z racji tego, że jak już wspomnieliśmy wcześniej Microsoft nie produkuje odpowiednich urządzeń sieciowych - alians z Cisco wydaje się w tej sytuacji niezłym posunięciem.

Wreszcie po stronie centrum weryfikacji znajdziemy trzy komponenty. W pierwszym rzędzie stoi tutaj następca popularnego serwera RADIUS (IAS - Internet Authentication Services) - Network Policy Server (NPS). Rola tej aplikacji to przede wszystkim uwierzytelnianie i zarządzanie polityką bezpieczeństwa. Zanim jednak NPS podejmie decyzję, musi uzyskać odpowiednie informacje. Tych dostarczają weryfikatory stanu nazywane przez Microsoft System Health Validators. Dodatkowo, aby NPS mógł zrozumieć dane spływające z weryfikatorów potrzebuje tłumacza i pośrednika - komponentu NAP Administration Server.

Pozostaje już tylko podjąć odpowiednią decyzję i przekazać ją do punktu kontroli dostępu. Ten albo zezwala klientowi na pełny dostęp, albo przenosi go do strefy ograniczonego zaufania, gdzie może zostać przeprowadzony proces "uzdrawiania". Nie są to jednak wszystkie elementy, które mogą zaistnieć w centrum weryfikacji. Pozostałe nie są jednak kluczowe dla zrozumienia samej koncepcji NAP. Przykładem może być serwer Active Directory, z którego jako bazy obiektów korzysta NPS.

Ciekawym pomysłem jest umieszczenie w ramach centrum serwera PKI, generującego certyfikaty zdrowia (Health Certificate Server). Jego rolą jest wystawienie certyfikatu dla klienta, który przeszedł poprawnie weryfikację. Dotyczy to połączeń realizowanych w oparciu o IPSec, a certyfikaty wykorzystywane są do zestawiania tuneli. Zamiast więc za każdym razem prosić użytkownika o uwierzytelnienie, można użyć certyfikatów, co znacząco ułatwia cały proces.

TCG - Trusted Network Connect

Ostatnim z głównych nurtów rozumienia technologii NAC, na które rzucimy nieco światła, jest podejście reprezentowane przez organizację TCG noszące nazwę Trusted Network Connect (TNC). To najbardziej otwarta z koncepcji NAC, mająca całkiem duże grono zwolenników - wśród nich m.in. Juniper, który na TNC oparł swoje rozwiązanie UAC (Unified Access Control). TNC nie zajmuje się produktami. Określa sposoby bezpiecznej komunikacji pomiędzy komponentami pochodzącymi od wielu dostawców. W lutym 2007 r. podczas konferencji RSA w San Francisco TCG zaprezentowała nowe specyfikacje architektury. Jak ona wygląda?

Znowu zacznijmy od strony klienta. TCG podobnie jak pozostałe koncepcje wyróżnia trzy elementy: Network Access Requestor (NAR) - łącznik sieciowy, Integrity Measurement Collector (IMC) - kolektor stanu oraz TNC Client (TNCC) - pośrednik klienta. Funkcję NAR może pełnić oprogramowanie zapewniające dostęp do sieci, np. klient VPN czy też suplikant 802.1x. IMC z kolei to nie tyle jeden komponent, co grupa komponentów, które służą zbieraniu informacji o stanie klienta, np. zainstalowanym oprogramowaniu AV czy też uruchomionych procesach. Tych komponentów może być tak wiele, jak wiele elementów musi zostać sprawdzonych w systemie. Pozostaje jeszcze TNCC. Zadaniem tego elementu jest usystematyzowanie informacji zebranych przez IMC i przekazanie ich w odpowiedniej (zrozumiałej) postaci do NAR. W nowej specyfikacji TNCC wspiera Javę, co ułatwia implementację w środowiskach heterogenicznych. TNCC jest bardzo często niewidoczny dla końcowego użytkownika, ponieważ dzięki otwartym specyfikacjom zostaje wchłonięty przez oprogramowanie konkretnego dostawcy.