Na początek TGC

TGC to branżowa organizacja standaryzacyjna non profit, skupiająca dostawców IT, która od połowy 2004 r. pracuje nad schematem Trusted Network Connect. Jej projekt nie jest jednak jeszcze skończony i TGC wciąż poszukuje kompletnej architektury NAC.

Struktura Trusted Network Connect obejmuje sześć oddzielnych protokołów tworzących kompletny system, ale jedynie dwa z nich zostały w pełni zdefiniowane, co uniemożliwia pełne wdrożenie sieci NAC opartej na Trusted Network Connect. TGC obiecuje ukończenie pozostałych protokołów niebawem.

Trzeba jednak przyznać, że właśnie Trusted Net-work Connect to najlepszy punkt startowy do oceny architektury, ponieważ specyfikacja ta jest tworzona w otwartym, niezależnym od dostawców środowisku i może być użyta jako dobry punkt odniesienia, porządkujący sprawy terminologiczne (zob. tabela).

Każda proponowana strategia NAC może być porównywana z architekturą Trusted Network Connect, co nie oznacza jednak, że zawierają się w niej wszystkie pozostałe architektury. Wielu dostawców NAC dodaje własne mechanizmy, niespecyfikowane przez TGC, takie jak sterowanie osobistą zaporą ogniową czy ciągłe sprawdzanie bezpieczeństwa punktów końcowych. Obsługiwane są także przypadki niewymieniane w architekturze TGC, jak np. sposób zapewnienia kontroli dostępu, gdy system końcowy jest laptopem gościa bez wymaganego oprogramowania.

Architektura Trusted Network Connect rozdziela problem NAC na trzy jednostki: Access Requestor, Police Enforcement Point i Policy Decision Point (zob. rys).

Access Requestor jest zbiorem jednostek próbujących uzyskać dostęp do sieci - takich jak laptopy, desktopy - oraz oprogramowania i sterowników implementujących uwierzytelnianie i procesy oceny bezpieczeństwa punktów końcowych. TGC dzieli Access Requestor na trzy mniejsze elementy. Na samym dole jest Network Access Requestor, oprogramowanie używane przez klienta do połączeń z siecią, wydające żądanie dostępu i zapewniające uwierzytelnienie. Takie sieciowe żądania dostępu może obsługiwać np. klient 802.1X, nazywany "suplikantem", lub klient IPSec VPN.

Nad warstwą Network Access Requestor działają - na systemie klienckim i jako część dostępu - komponenty programowe odpowiedzialne za ocenę kondycji bezpieczeństwa systemu końcowego, o nazwie Integrity Measurement Collectors. Jeżeli reguły polityki są zdefiniowane w taki sposób, że każdy punkt końcowy musi mieć np. system antywirusowy, to dostawca rozwiązania antywirusowego musi zapewnić złącza programowe, które będą dostarczać informacje statusowe o jego oprogramowaniu.

TGC dzieli to zadanie na dwa elementy: Integrity Measurement Collectors i klienta Trusted Network Connect, który zbiera informacje z Integrity Measurement Collectors i pomaga spakować je w format właściwy dla oceny zgodności z regułami polityki.

Policy Enforcement Point jest dokładnie tym, co określa jego nazwa: punktem, w którym egzekwowane są reguły polityki. NAC w wydaniu TGC nie specyfikuje jakiego rodzaju mechanizmy egzekwowania reguł polityki są dostępne, pozostawiając to do decyzji dostawcy, chociaż dokumentacja architektoniczna opisuje, jak częścią egzekwowania reguł mogą stać się kwarantanna i systemy naprawcze.

Policy Decision Point także dzieli się na trzy części. Element na samym dole, odpowiedzialny za wymianę informacji z serwerem uwierzytelniania i komunikowanie decyzji uwierzytelnienia do Police Enforcement Point, to Network Access Authority. W typowej sieci będzie to prawdopodobnie tzw. serwer AAA (Authentication, Authorization, Accounting). Nad Network Access Authority sytuują się Integrity Measurement Verifiers. Są to odpowiedniki Integrity Measurement Collectors strony klienckiej. Odbierają raporty, które wysyłają kolektory Client Integrity Measurement i zapewniają zwrotnie informację weryfikacyjną dla Net-work Access Authority. Weryfikatory i kolektory są zestawem dopasowanym. Mogą one komunikować się między sobą przez tunel zapewniany przez wszystkie pozostałe elementy architektury NAC, używając dowolnych, własnych protokołów - według uznania dostawcy.

Interfejsem pomiędzy Integrity Measurement Verifiers a Network Access Authority w Policy Decision Point jest TNC Server.

Architekturę Trusted Network Connect zaprojektowano do pracy z istniejącymi systemami uwierzytelniania i autoryzacji 802.1X. Jeżeli Access Requestor nazwie się "suplikantem 802.1X", Policy Enforcement Point "przełącznikiem kompatybilnym z 802.1X" lub "punktem dostępowym", a Network Access Authority Policy Decision Point "serwerem RADIUS 802.1X", wtedy NAC Trusted Network Connect jest fragmentem oprogramowania umiejscowionym nad istniejącymi wdrożeniami 802.1X, uzupełniającym je oceną bezpieczeństwa punktów końcowych.

Staje się to oczywiste, jeżeli popatrzy się na protokoły Trusted Network Connect wybrane do pierwszej publikacji. Są to takie, które pozwalają kolektorom integrity-measurement, dostarczanym przez niezależnych dostawców, komunikować się z neutralnym klientem Trusted Network Connect na systemie klienckim. Także takie, które pozwalają Integrity Measurement Verifier, dostarczanym przez niezależnych dostawców, komunikować się z neutralnym serwerem TNC po stronie Policy Decision Point. Prototypowe implementacje Trusted Network Connect w znacznym stopniu opierają się na mechanizmach 802.1X - takich jak uwierzytelnianie i tunelowanie - aczkolwiek żaden z nich nie jest explicite wymieniony w dokumentacji architektury.

Skupienie się na 802.1X nie oznacza, że architektura Trusted Network Connect nie obsługuje innych rodzajów Policy Enforcement Point, takich jak zapory ogniowe, koncentratory VPN czy przełączniki. Oznacza jednak, że - próbując przejść od architektury do implementacji na podstawie dokumentów Trusted Network Connect - szybko można natknąć się na brakujące elementy układanki, co najmniej na etapie architektury. Ważne detale, takie jak komunikacja klienta i serwera Trusted Network Connect z Network Access Requestor i Network Access Authority nie są jeszcze opracowane, co oznacza, że nawet wtedy gdy architektura zostanie ukończona tak jak planowano, to nie będzie kompletna.

Chociaż architektura Trusted Network Connect jest uporządkowanym sposobem myślenia o NAC, to jako wciąż niepełna, nie może być użyta w implementacji.

Microsoft: Network Access Protection

Najbardziej znacząca różnica pomiędzy architekturą Microsoftu Network Access Protection a TGC Trusted Network Connect wynika z faktu, że Microsoft nie jest producentem przełączników ani routerów. Dlatego też metody egzekwowania reguł są różne i skupiają się raczej na DHCP niż 802.1X.

Tak jak Trusted Network Connect, strona kliencka Microsoftu dzieli się na trzy części. Na samej górze są agenty - System Health Agents, wykonujące zadania podobne do Integrity Measurement Collectors. Agenty odpowiadają za generowanie "Statements of Health, które mogą być używane do oceny bezpieczeństwa punktu końcowego.

System Health Agents są łączone z pozostałą częścią architektury przez Network Access Protection Agent - analogia klienta Trusted Network Connect TGC. Poniżej Network Access Protection Agent znajdują się Enforcement Clients - odpowiedniki Network Access Requestor TGC.

Elementy w rodzaju Enforcement Clients to zazwyczaj suplikanty 802.1X lub klienty VPN w innych architekturach, natomiast w środowisku Microsoftu obejmują także klienta DHCP. Dokumentacja architektoniczna Microsoftu definiuje klientów dla DHCP, PPP/L2TP (Point-To-Point Protocol/Layer 2 Tunneling Protocol) oraz dostęp sieciowy IPSec. Jednak ważniejsze jest to, że jako trzeci poziom klienta Network Access Protection Microsoft zdefiniował odpowiednie API.

Tworząc API, które pozwala opisać, jak te trzy elementy klienta będą się nawzajem uzupełniać, Microsoft wyeliminował nadmierne ryzyko zmienności w całym obszarze Network Access Control.

Rolę Policy Enforcement Point w architekturze Microsoftu przejęły Enforcement Servers. Ponieważ Microsoft nie produkuje przełączników czy routerów, jego projektanci początkowo przestawiali wizje egzekwowania kontroli dostępu raczej jako usługę niż punktowy typ kontroli, które firmy takie jak Cisco mogą uważać za naturalne podejście.

Microsoft ma udostępnić Enforcement Server wraz z systemami operacyjnymi Vista i Longhorn - jako część zbioru własnych serwerów VPN opartych na RRAS (Routing and Remote Access Service), operujących zarówno na poziomie PPP/L2TP, jak i IPSec. Z dokumentów udostępnionych przez Microsoft wynika, że firma traktuje Network Access Protection przede wszystkim jako narzędzie zapewniające użytkownikowi:

• pełny dostęp

• brak dostępu

• dostęp ograniczony do pewnego rodzaju sieci naprawczej lub kwarantanny.

Brak solidnego miejsca dla uwierzytelniania w architekturze Microsoftu pokazuje, że została ona zaprojektowana przede wszystkim do wspomagania istniejącego środowiska zarządzania desktopami i laptopami w domenach Microsoftu w zakresie kontroli zgodności z regułami bezpieczeństwa punktów końcowych, a nie jako czysty mechanizm kontroli dostępu.

Zapleczem Policy Decision Point w wydaniu Microsoftu jest Network Policy Server oparty na RADIUS, który ma zastąpić starszy Internet Authentication Server. Network Policy Server będzie dostarczany z nowymi wersjami Windows. Zawiera on funkcjonalność porównywalną z TCG Network Access Authority, obejmującą uwierzytelnianie i zarządzanie regułami polityki. Microsoft tworzy oddzielny Network Access Protection Administration Server - obsługujący te same funkcje co komponent TCG TNC Server - łącząc serwer uwierzytelniania ze złączami programowymi rozwiązań weryfikujących, pochodzących od dostawców niezależnych. Nad Administration Server, używając zdefiniowanego przez Microsoft API, funkcjonują System Health Verifiers, odpowiedniki TCG Integrity Measurement Verifiers, które odbierają Statements of Health z System Health Agents na kliencie i zapewniają zwrotne odpowiedzi do Administration Server.