Wstęp do Network Access Protection w Windows Server 2008 - cz. I

Autor: Kamil Skalski

Opublikowano: 22 stycznia 2008

Zawartość strony

	Wstęp
	Zrozumieć NAP
	Krótko o architekturze
	Instalacja NAP
	Określenie Urzędu Certyfikacji NAP
	Wybór certyfikatu połączeń
	Przeczytaj pozostałe części artykułu

Wstęp

Jednym z najbardziej pracochłonnych i trudnych problemów administratora jest zadbanie, by klienci łączący się z siecią prywatną nie stanowili zagrożenia. Wiele problemów i zagrożeń jest powodowanych poprzez działanie w sieci komputerów klienckich niespełniających norm bezpieczeństwa.

Komputer, którego system operacyjny nie jest zaktualizowany, nie posiada oprogramowania antywirusowego z aktualną bazą sygnatur lub posiada wyłączonego firewalla, może stać się przyczyną dużych kłopotów w całej sieci. W wielu organizacjach proces aktualizacji ochrony stacji roboczych użytkowników jest prowadzony ręcznie, bez użycia mechanizmów automatyzacji tych zadań. Nie mówiąc już o monitorowaniu stanu komputerów przyłączających się do sieci.

Równie często można spotkać sytuację, w której osoby pracujące zdalnie łączą się z różnymi niezaufanymi sieciami, a następnie łączą się z siecią macierzystą organizacji. Zdarza się również, że do sieci wewnętrznej muszą zostać podłączone komputery gości lub prywatne komputery pracowników, których stanu zabezpieczeń nie można stwierdzić.

Te wszystkie sytuacje stanowią zagrożenie dla zasobów przedsiębiorstw. Oczywiście można próbować ograniczyć takie zagrożenia, tworząc różne podsieci i ograniczać ich powiązania, lecz jest to pracochłonna, nie zawsze skuteczna metoda. Windows Server 2008 rozwiązuje te problemy, dostarczając mechanizm Network Access Protection, poniekąd znany już w Windows Server 2003 jako Network Access Quarantine.

Network Access Protection (NAP) należy rozumieć jako mechanizm zarówno kontroli stanu systemów, jak i w konfiguracji, pomagający administratorowi sieci zapewnić przestrzeganie założeń polityki zabezpieczeń dla komputerów klienckich.

Z wykorzystaniem NAP można stworzyć bezpieczne, zautomatyzowane środowisko, w którym każdy komputer na bieżąco podlega kontroli bezpieczeństwa. Największą zaletą NAP jest natychmiastowa reakcja na zmianę stanu zabezpieczeń. W odróżnieniu od mechanizmów firm trzecich, które w większości sprawdzają stan klienta tylko podczas uzyskiwania połączenia, NAP nie przestaje monitorować systemu.

Mówiąc o Network Access Protection w Windows Server 2008 należy zdać sobie sprawę z trzech podstawowych aspektów związanych z tym mechanizmem. Określenie stanu zdrowia odbywa się podczas połączenia się komputera z siecią.

Stan ten jest określany poprzez sprawdzenie zgodności ustawień zabezpieczeń z politykami określonymi przez administratora. Dodatkowo można określić działania, które zostaną podjęte w zależności od zdiagnozowanego stanu zdrowia. Przykładowo, komputery, które uzyskają certyfikat zdrowia, otrzymują pełny dostęp do zasobów sieci, a pozostałe są podłączane do sieci z ograniczeniami, które pozwalają tylko na poprawę ich stanu zdrowia (np. aktualizację definicji programu antywirusowego), ale zabronią dostępu do zasobów sieci.

Zgodność z politykami zdrowia jest ustalana na podstawie porównania aktualnego stanu zabezpieczeń z określonymi przez administratora wymogami. W przypadku niespełnienia wymogów zdrowia, można wdrożyć mechanizmy automatycznej naprawy, np. z użyciem Microsoft Systems Management Server 2003 lub System Center Configuration Manager 2007.

Ograniczony dostęp uzyskują komputery niespełniające wymogów. Może być on realizowany poprzez czasowe ograniczenie dostępu lub określenie zasobów, do jakich będzie miał dostęp komputer bez certyfikatu zdrowia. Dobrym rozwiązaniem jest wyodrębnienie w sieci „czyśćca” (strefy kwarantanny), w którym udostępnione będą zasoby konieczne do poprawy stanu zdrowia niebezpiecznych klientów. Można to zrealizować za pomocą serwerów korekcyjnych lub w mniej zaawansowanej konfiguracji poprzez udostępnienie zasobów zawierających aktualizacje, bazy sygnatur itp.

 Do początku strony

Zrozumieć NAP

Komponentami NAP odpowiadającymi za śledzenie zmian stanu zdrowia oraz sprawdzenie jej zgodności z politykami są System Health Agent (SHA) oraz System Health Validator (SHV). W systemach Windows Vista oraz Windows XP z Service Pack 3 znajduje się wbudowany komponent Windows Security Health Validator SHA, który odpowiedzialny jest za monitorowanie Centrum Zabezpieczeń i w ten sposób sprawdzający stan zdrowia komputerów.

Windows Server 2008 posiada podobny komponent: Windows Security Health Validator SHV. Za ograniczenie dostępu i wymuszenie zachowania zgodnego z polityką są Komponenty Wymuszające, wśród których można wyróżnić Enforcement Client (EC) oraz Enforcement Server (ES).

Komputery z systemami Windows XP z Service Pack 3, Windows Vista oraz Windows Server 2008 posiadają wsparcie dla NAP dla różnych rodzajów dostępu do sieci i komunikacji: ruch z użyciem IPSec, autentykacja IEEE 802.1x, połączenia zdalnego dostępu VPN oraz przydzielanie adresów za pośrednictwem DHCP.

W przypadku Windows Vista i Windows Server 2008 dostępna jest także współpraca NAP z Terminal Server Gateway. Wymienione wcześniej mechanizmy można wykorzystać do ograniczenia dostępu lub komunikacji dla komputerów, które nie uzyskały certyfikatu zdrowia. Istotnym faktem jest możliwość użycia wszystkich lub tylko wybranych mechanizmów, które dalej nazywane będą metodami wymuszenia. Określenie polityk odbywa się za pośrednictwem Network Policy Server (NPS), następcy Internet Authentication Service (IAS) w Windows Server 2003.

Przykładowe zastosowanie Mechanizmów NAP, w oparciu o wymuszenie IPSec przedstawia rysunek 1.

Rys. 1. Proces uzyskiwania certyfikatu zdrowia.

Proces uzyskiwania certyfikatu odbywa się w następujący sposób:

1. Komputer żąda dostępu do sieci, następnie przedstawia swój stan zdrowia wraz z prośbą o certyfikat;
2. HRA komunikuje się z Network Policy Server w celu sprawdzenia zgodności stanu zdrowia klienta z politykami;
3. W przypadku, gdy stan zdrowia nie jest zgodny z politykami NPS przesyła odpowiedź do HRA, że klient wymaga uaktualnienia;
4. HRA nie przydziela certyfikatu klientowi i pozostawiając go w strefie kwarantanny, odsyła by pobrał poprawki;
5. Klient komunikuje się z serwerem korygującym tzw. Remediation Server w celu pobrania poprawek;
6. Serwer korygujący (Remediation Server) przesyła potrzebne poprawki;
7. Komputer żąda dostępu oraz przedstawia swój stan zdrowia wraz z prośbą o certyfikat;
8. HRA komunikuje się z Network Policy Server w celu sprawdzenia zgodności stanu zdrowia klienta z politykami;
9. NPS potwierdza zgodność z politykami i zezwala na przyznanie certyfikatu zdrowia;
10. Komputer otrzymuje certyfikat zdrowia;
11. Następuje zezwolenie na dostęp do strefy chronionej.

 Do początku strony

Krótko o architekturze

Ponieważ o architekturze NAP można znaleźć wiele artykułów szczegółowo opisujących jej składniki, w tej części artykułu przedstawione zostaną najważniejsze założenia i komponenty potrzebne do zrozumienia działania tego mechanizmu.

Architekturę platformy NAP po stronie klienta można podzielić na pięć warstw (rysunek 2.):

• Warstwa klientów wymuszania ochrony dostępu do sieci (NAP EC);
• Warstwa agentów kondycji systemu (SHA);
• Agent NAP;
• Interfejs programistyczny NAP SHA API;
• Interfejs programistyczny NAP EC API.

Klienci NAP EC (Network Access Protection Enforcement Client) odpowiedzialni są za obsługę poszczególnych rodzajów komunikacji oraz sposoby uzyskiwania dostępu do sieci. Dla każdego z tych rodzajów może zostać użyty oddzielny NAP EC. Przykładowo, podczas wykorzystywania wymuszenia VPN i DHCP użyte będą dwa moduły NAP EC.

Agenci SHA (System Health Agent) odpowiedzialni są za sprawdzenie kondycji poszczególnych elementów systemu, np. sygnatur antywirusowych. Każdy z nich może być przypisany do serwera korygującego (Remediation Server).

Agent NAP monitoruje kondycję klienta NAP oraz uławia komunikację pomiędzy klientami wymuszenia, a agentami kondycji systemu i jest ponadto odpowiedzialny za:

• Odbieranie raportów kondycji od agentów kondycji systemu oraz ich przechowywanie;
• Dostarczanie bieżącej listy raportów kondycji;
• Przekazanie informacji o zmianach statusu dostępu klienta do sieci agentom kondycji systemu;
• Przekazywanie odpowiedzi SoHR z serwera do agentów kondycji systemu.

SHA API umożliwia:

• Rejestrację agentów systemu w Agencie NAP klienta;
• Sygnalizowanie kondycji klienta;
• Odpowiadanie na zadawane pytania o kondycję systemu;
• Przekazywanie przez agentów NAP instrukcji serwerów korygujących do SHA.

NAP EC API odpowiada za:

• Rejestrację klientów NAP EC w Agencie NAP klienta;
• Wysyłanie pytań o kondycję klienta;
• Przesyłanie instrukcji z serwerów korygujących do agentów NAP.

Uwaga: Zarówno agenci kondycji systemu, jaki i klienci wymuszania ochrony dostępu do sieci mogą być także dostarczani przez firmy trzecie.

Rys. 2. Architektura platformy NAP po stronie klienta.

Proces określenia stanu kondycji klienta rozpoczyna się od stworzenia raportu o kondycji (Statement of Health – SoH) przez agentów kondycji systemu, który jest przekazywany do Agenta NAP. Każda zmiana kondycji skutkuje stworzeniem nowego raportu SoH. Agent NAP ustala kondycję systemu poprzez analizę wszystkich raportów o kondycji poszczególnych elementów systemu.

Architekturę platformy NAP po stronie serwerów można podzielić na cztery podstawowe warstwy (patrz rys. 3.):

• Warstwa komponentów sprawdzania kondycji (SHV);
• Interfejs programistyczny API modułów sprawdzania kondycji (SHV API);
• Komponent administracyjny NAP;
• NPS (Network Protection Server).

SHV, czyli warstwa modułów sprawdzania kondycji (System Health Validator), w której każdy moduł sprawdzania kondycji zajmuje się innymi wymogami oraz może komunikować się z przypisanym serwerem NPS.

SHV, API umożliwia:

• Rejestrację modułów kondycji w komponencie administracyjnym NAP;
• Odbieranie raportów o kondycji z serwera;
• Przekazywanie informacji z serwerów korygujących do odpowiednich agentów NAP.

Komponent Administracyjny NAP odpowiada za komunikację pomiędzy serwerem NPS a modułami sprawdzania kondycji.

NPS odbiera komunikaty RADIUS Access-Request o kondycji poszczególnych komputerów i przekazuje je do komponentu administracyjnego NAP.

Rys. 3. Architektura platformy NAP po stronie serwerów.

Dokładny opis procesu komunikacji poszczególnych komponentów architektury platformy NAP można znaleźć w artykule „Komunikacja między klienckimi a serwerowymi komponentami platformy NAP" na stronie: https://www.microsoft.com/poland/technet/bazawiedzy/centrumrozwiazan/cr196_01.mspx

 Do początku strony

Instalacja NAP

Network Access Protection jest jedną z roli Windows Server 2008, a jej instalacja nie różni się znacząco do innych. Przed rozpoczęciem instalacji należy rozważyć zagadnienia związane z budowaniem środowiska NAP. Trzeba zastanowić się czy wszystkie zadania będzie wykonywał jeden serwer, czy istnieje już w środowisku Urząd Certyfikacji itp.

Do instalacji roli NAP oraz innych składników można użyć konsoli Server Manager oraz kreatora Add Roles Wizard (patrz rys. 4.).

Rys. 4. Instalacja NAP z wykorzystaniem Ad Roles Wizard.

Podczas instalacji roli istnieje możliwość wyboru trzech składników wykorzystywanych przez NAP (rys. 5.). Network Policy Server jest odpowiedzialny między innymi za sprawdzanie zgodności stanu zdrowia komputera z politykami NAP, Health Registration Authority, czyli podstawowa rola NAP oraz Host Credential Authorization Protocol umożliwia współpracę NAP z mechanizmem Network Access Control (sprzętowe rozwiązanie NAP firmy Cisco).

Rys. 5. Składniki instalacji.

 Do początku strony

Określenie Urzędu Certyfikacji NAP

Network Access Protection do wydawania certyfikatów zdrowia wykorzystuje Urząd Certyfikacji (patrz rys. 6.). Jeśli w środowisku nie istnieje jeszcze żaden CA można wykonać instalację tej roli, w innym przypadku konieczne jest zdefiniowanie CA. Można to także uczynić po instalacji w konsoli konfiguracyjnej.

Rys. 6. Określenie Urzędu Certyfikacji dla NAP.

Network Access Protection może pracować poza domeną. W tym kroku instalacji możliwe jest określenie, na jakich warunkach komputery kliencie mogą komunikować się z Health Registration Authority – czy muszą być uwierzytelnione w domenie (rys. 7.). Wykorzystanie opcji zezwalającej na dostęp anonimowy jest dobrym rozwiązaniem, gdy istnieje konieczność obsługi komputerów gości.

Rys. 7. Określenie wymogu autoryzacji do komunikacji z HRA.

 Do początku strony

Wybór certyfikatu połączeń

Ostatni etap konfiguracji NAP i jego składników podczas instalacji, to wybór rodzaju certyfikatu dla połączeń SSL oraz podjęcie decyzji, czy mają być używane przez HRA i HCAP do komunikacji z klientami (patrz rys. 8.).

Rys. 8.Wybór rodzaju połączeń do komunikacji HRA i HCAP z klientami.

 Do początku strony

Przeczytaj pozostałe części artykułu

• Wstęp do Network Access Protection w Windows Server 2008, cz. II
• Wstęp do Network Access Protection w Windows Server 2008, cz. III

Do początku strony