The Cable Guy: NAP przez Internet

Autor: Joseph Davies

Opublikowano: 2 listopada 2009

Zawartość strony

	Przegląd wymuszania IPsec
	Odkrywanie HRA i serwery HRA dostępne z Internetu
	NAP przez Internet
	NAP przez Internet: przykład
	Podsumowanie

Network Access Protection (NAP) w Internecie jest naturalnym następcą wymuszania Internet Protocol Security (IPsec), które rozszerza mechanizm sprawdzania kondycji i bieżącej naprawy na komputery zarządzane, rozproszone w sieci Internet. NAP przez Internet zapewnia silniejszy, oparty na hoście model zabezpieczeń dla komputerów należących do domeny i połączonych z Internetem w dowolnym miejscu i czasie. Na przykład komputer przenośny łączący się z siecią Wi-Fi w kafejce internetowej może wykorzystać mechanizm NAP przez Internet do oceny i skorygowania kondycji systemu bez wiedzy ani interwencji użytkownika.

Zanim przejdziemy do szczegółów, przejrzyjmy niektóre podstawy i techniki wdrażania NAP i wymuszania IPsec.

Przegląd wymuszania IPsec

Wymuszanie IPsec jest rozszerzeniem scenariusza izolacji domeny, które wykorzystuje mechanizm sprawdzania kondycji NAP jako część procesu uwierzytelniania partnera IPsec. W scenariuszu tym konfigurujemy ustawienia zasad IPsec dla członków domeny, aby wymagali uwierzytelniania i zabezpieczania wszystkich przychodzących połączeń (szyfrowanie ruchu jest opcjonalne). Partnerzy IPsec mogą wykorzystać do uwierzytelniania protokół Kerberos albo certyfikaty cyfrowe. Członkowie domeny automatycznie uzyskują poświadczenia Kerberos, zaś certyfikaty mogą być automatycznie rozpowszechniane pomiędzy członków domeny przy użyciu opartego na systemie Windows urzędu certyfikacji (CA) oraz Zasad grupy.

W przypadku wymuszania IPsec w NAP poświadczeniem dla uwierzytelniania partnera IPsec jest certyfikat kondycji zawierający System Health Authentication Enhanced Key Usage (EKU). Zasada IPsec dla wymuszania IPsec żąda, aby wszystkie próby połączeń przychodzących używały certyfikatu kondycji w celu uwierzytelnienia. Gwarantuje to, że parter inicjujący komunikację nie tylko jest członkiem domeny, ale również jest zgodny z wymaganiami dotyczącymi kondycji systemu. W trybie pełnego wymuszania, jeśli klient NAP nie dysponuje certyfikatem kondycji, uwierzytelnianie partnera IPsec się nie powiedzie i niezgodny klient NAP nie będzie mógł nawiązać łączności ze zgodnym partnerem IPsec.

Gdy klient NAP ze skonfigurowanym wymuszaniem IPsec jest uruchamiany, kontaktuje się z Health Registration Authority (HRA). Jest to komputer, na którym uruchomiony jest system Windows Server 2008, Internet Information Services (IIS) oraz usługa roli HRA należąca do roli Network Policy and Access Services. HRA uzyskuje certyfikat X.509 z CA w imieniu klienta NAP, gdy serwer zasad kondycji NAP ustali, że klient jest zgodny z zasadami.

Aby móc uzyskiwać certyfikaty dla zgodnych klientów NAP, musimy skonfigurować na serwerach HRA lokalizację urzędów certyfikacji NAP w intranecie. Aby klienci NAP mogli zlokalizować serwery HRA w intranecie, możemy albo skonfigurować je przy użyciu grupy zaufanych serwerów – listy adresów URL serwerów HRA w intranecie – albo poprzez odkrywanie HRA (patrz ramka „Odkrywanie HRA i serwery HRA dostępne z Internetu").

Po uruchomieniu klienta NAP lokalizuje on HRA w intranecie, wysyła swój status kondycji i – o ile jest zgodny –uzyskuje certyfikat kondycji. Następnie, gdy klient NAP inicjuje komunikację z innymi punktami w intranecie, podejmuje próbę negocjacji zabezpieczeń IPsec dla tego ruchu, używając poświadczeń certyfikatu kondycji. Jeśli negocjacja się nie powiedzie, klient NAP łączy się bez zabezpieczeń IPsec. Jeśli stan kondycji lub stan sieci dla zgodnego klienta NAP ulegnie zmianie, wykonuje on dodatkowe sprawdzenie stanu kondycji z serwerem HRA, i jeśli jest zgodny, uzyskuje nowy certyfikat. Jeśli wystąpią warunki kondycji systemu, które muszą być skorygowane, klient będzie musiał jej poprawić, zanim uzyska certyfikat kondycji.

 Do początku strony

Odkrywanie HRA i serwery HRA dostępne z Internetu

Klient NAP może również wykorzystać odkrywanie HRA w celu automatycznego zlokalizowania serwerów HRA w sieci. Zamiast skonfigurowanej listy adresów URL w grupie zaufanych serwerów włączenie odkrywania HRA na kliencie NAP powoduje, że próbuje on zlokalizować HRA poprzez wysłanie kwerendy DNS z zapytaniem o rekordy SRV _hra._tcp.site_name._sites.domain_name. Na przykład, jeśli podstawową domeną klienta NAP jest contoso.com, używa on domyślnej lokacji Active Directory i ma włączone odkrywanie HRA, wyśle zapytanie o rekordy SRV dla _hra._tcp.default-first-site-name._sites.contoso.com. Rekord SRV dla HRA zawiera w pełni kwalifikowaną nazwę domenową serwera HRA. Rekordy SRV dla HRA w DNS muszą zostać ręcznie skonfigurowane w odpowiednich strefach.

W przypadku korzystania z NAP przez Internet należy skonfigurować odrębne rekordy SRV dla intranetu (dla serwerów HRA dostępnych z wnętrza sieci firmowej) oraz rekordy SRV zawierające FQDN serwerów HRA dostępnych w sieci Internet. Klienci NAP wysyłają te zapytania o tę samą nazwę i typ rekordu, ale otrzymują w odpowiedzi różne FQDN, zależnie od własnej lokalizacji.

W celu włączenia odkrywania HRA dla klientów NAP, którzy odbierają swoją konfigurację za pośrednictwem zasad grupy, należy ustawić wartość rejestru HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\ NetworkAccessProtection\ClientConfig\Enroll\HcsGroups\ EnableDiscovery (typu DWORD) równą 1.

Więcej informacji można znaleźć w artykule „Configure HRA Automatic Discovery”.

 Do początku strony

NAP przez Internet

Gdy komputer kliencki NAP skonfigurowany dla wymuszania IPsec opuszcza intranet i łączy się bezpośrednio z Internetem, klient NAP nadal próbuje zlokalizować serwer HRA. Ponieważ „podróżujący” komputer podłączony do Internetu nie może już skontaktować się z intranetowym serwerem HRA i wykonać weryfikacji kondycji systemu, nie może też określić, czy spełnia warunki narzucane przez systemowe zasady kondycji ani wykonać ich korekty w razie potrzeby. Z upływem czasu klient NAP wędrujący przez Internet może znaleźć się w stanie, w którym brakować mu będzie aktualizacji systemu operacyjnego lub aplikacji, albo też użytkownik, zależnie od jego poziomu uprawnień, może wykonać takie zmiany konfiguracji, które narażą komputer na ryzyko, na przykład wyłączając wbudowaną zaporę.

Gdy niezgodny komputer powraca do intranetu, musi najpierw uzdrowić stan swojego systemu, zanim będzie mógł uzyskać certyfikat kondycji i komunikować się z siecią. W czasie, gdy niezgodny komputer jest poprawiany, istnieje ryzyko przeniesienia przez niego infekcji na inne komputery intranetu, które nie są chronione przez IPsec.

Poprzez umieszczenie serwerów HRA w Internecie i skonfigurowaniu klientów NAP, tak aby mogły je zlokalizować, klienci podłączeni do Internetu mogą na bieżąco sprawdzać swój stan kondycji, tak jakby były połączone z intranetem. Jakkolwiek certyfikat kondycji nie jest wykorzystywany do realizacji uwierzytelniania partnerów IPsec, klient NAP nadal weryfikuje stan kondycji. Jeśli włączone jest automatyczne naprawianie, klient NAP będzie samoczynnie próbował skorygować swój stan, aby ograniczyć ryzyko zagrażające komputerowi połączonemu z Internetem. Samoczynna naprawa utrzymuje komputer w stanie zgodności z organizacyjnymi zasadami kondycji bez konieczności interwencji użytkownika. Komputer mobilny ponownie przyłączany do sieci intranetowej stwarza znacznie mniejsze zagrożenie, jeśli cały czas ma zapewnioną zgodność z zasadami.

Naprawa kondycji systemu ograniczona jest w tym wypadku do funkcjonalności zapewnianej przez systemowych agentów kondycji (SHA) i może wymagać rozmieszczenia dodatkowych serwerów naprawczych dostępnych z sieci Internet.

Warto zauważyć, że domyślnie klienci NAP próbują wykonać uwierzytelnianie Kerberos przy łączeniu się z serwerem HRA dostępnym w Internecie. Ponieważ jednak kontroler domeny nie jest w tym wypadku osiągalny, uwierzytelnienie to się nie powiedzie. Dlatego konieczne jest wykonanie następującego polecenia na serwerach HRA dostępnych w Internecie, aby klienci NAP posłużyli się uwierzytelnianiem NTLM:

%windir%\system32\inetsrv\appcmd.exe set config -section:

system.webServer/security/authentication/windowsAuthentication

/-providers.[value='Negotiate']

Informacje rejestrowane przez serwery zasad kondycji NAP można wykorzystać do określenia ogólnego stanu zgodności klientów NAP podłączonych do Internetu.

Jeżeli serwery HRA dostępne w Internecie są odrębne od serwerów intranetowych, można skonfigurować osobne zasady wymagań kondycji dla klientów NAP połączonych przez Internet. Na przykład można wskazać oddzielny zestaw zasad, podając jako warunek adres IP serwera HRA. Zasady stosowane w intranecie będą używały wszystkich dostępnych agentów SHA, takich jak Windows Security Health Agent (WSHA), Forefront SHA czy System Center Configuration Manager (SCCM) SHA. Zestaw zasad stosowany w Internecie będzie używał tylko WSHA.

 Do początku strony

NAP przez Internet: przykład

Rysunek 1 ukazuje uproszczony schemat wdrożenia NAP przez Internet przez firmę Contoso Corporation.

Rysunek 1: Wdrażanie NAP przez Internet.

Rysunek 1 Wdrażanie NAP przez Internet

W tym przykładzie dostępne z Internetu serwery HRA są fizycznie połączone zarówno z Internetem, jak i intranetem, dzięki czemu mogą uzyskać dostęp do urzędów certyfikacji NAP CA oraz serwerów zasad kondycji NAP. W celu ochrony serwerów HRA ustawienia zapory zezwalają tylko na ruch kierowany do i od portu TCP 443, co odpowiada ruchowi SSL over HTTP.

Załóżmy, że intranetowe serwery HRA mają nazwy hra1.corp.contoso.com oraz hra2.corp.contoso.com. Dostępne z Internetu serwery HRA używają nazw int_hra1.contoso.com oraz int_hra2.contoso.com. Oczywiście intranetowe serwery DNS nie mogą rozwiązać nazw int_hra1.contoso.com ani int_hra2.contoso.com, zaś serwery DNS obsługujące Internet nie rozwiązują nazw hra1.corp.contoso.com ani hra2.corp.contoso.com.

Przy tej konfiguracji administrator sieci Contoso utworzy grupę zaufanych serwerów zawierającą następującą listę adresów URL:

• https://hra1.corp.contoso.com/domainhra/hcsrvext.dll
• https://hra2.corp.contoso.com/domainhra/hcsrvext.dll
• https://int_hra1.contoso.com/domainhra/hcsrvext.dll
• https://int_hra2.contoso.com/domainhra/hcsrvext.dll

Klienci NAP najpierw próbują połączyć się z intranetowymi serwerami HRA, a dopiero potem z serwerami dostępnymi z Internetu.

Klient NAP zlokalizowany w intranecie skontaktuje się z serwerem HRA1 lub HRA2. Klient NAP w Internecie najpierw spróbuje rozwiązać nazwy hra1.corp.contoso.com oraz hra2.corp.contoso.com. Te dwie próby szybko się zakończą błędem DNS Name Not Found. Następnie klient NAP z powodzeniem rozwiąże nazwę int_hra1.contoso.com albo int_hra2.contoso.com, po czym połączy się odpowiednio z serwerem INT_HRA1 lub INT_HRA2.

 Do początku strony

Podsumowanie

Po wdrożeniu scenariusza wymuszania IPsec w sieci intranet rozszerzenie weryfikacji stanu kondycji i naprawy dla klientów NAP połączonych z Internet jest stosunkowo łatwe, wymagając kilku dodatkowych serwerów jako dostępnych z Internetu serwerów HRA (albo dodatkowych ról na już istniejących serwerach internetowych). Co więcej, zależnie od tego, jak klienci NAP lokalizują serwery HRA, konieczne może być opublikowanie rekordów dla tych serwerów na internetowych serwerach DNS i uzupełnienie grupy zaufanych serwerów. Można też utworzyć dodatkowy zestaw zasad kondycji określający testy sprawdzania systemu oraz działanie samoczynnej naprawy dla klientów NAP połączonych przez Internet.

O autorze

Joseph Davies jest głównym autorem technicznym w zespole dokumentacji sieciowej w firmie Microsoft. Jest autorem lub współautorem licznych książek opublikowanych przez Microsoft Press, w tym Windows Server 2008 Networking and Network Access Protection (NAP) (wydanie polskie: Ochrona dostępu do sieci (NAP) w Windows Server 2008, APN Promise 2008), Understanding IPv6, Second Edition oraz Windows Server 2008 TCP/IP Protocols and Services (wydanie polskie: Protokoły i usługi TCP/IP w Windows Server 2008, APN Promise 2008).

Do początku strony