Rozdział 1

Bezpieczeństwo w systemie Windows 2000

Jeśli potrzebujesz natychmiastowego rozwiązania następującego problemu: [Author ID1: at Mon Jul 30 22:53:00 2001 ]zajrzyj na stronę:

Struktura Active Directory

Zintegrowane zarządzanie kontami zabezpieczeń (Security Account Management)

Korzystanie z przechodnich wzajemnych relacji zaufania

Przekazywanie administrowania

Korzystanie z Listy kontroli dostępu (Access Control List) przy precyzyjnym ustawianiu praw dostępu

Stosowanie protokołów zabezpieczeń

Korzystanie z interfejsu programu obsługi zabezpieczeń SSPI (Security Support Provider Interface)

Protokół uwierzytelniania Kerberos 5

Wykorzystywanie certyfikatów z kluczem publicznym (Public Key Certificates) do zapewnienia bezpieczeństwa w Internecie

Wprowadzanie wzajemnego dostępu pomiędzy przedsiębiorstwami (Interbusiness Access)

Rozwiązania na skalę całego przedsiębiorstwa

Zastosowanie danych uwierzytelniających (credentials) protokołu uwierzytelniania NTLM

Zastosowanie danych uwierzytelniających protokołu uwierzytelniania Kerberos

Zastosowanie pary kluczy prywatny-publiczny i certyfikatów

Zastosowanie protokołu Internet Protocol Security

Zastosowanie wirtualnych sieci prywatnych (Virtual Private Networks)

Zastosowanie narzędzi do konfigurowania zabezpieczeń

Przechodzenie z systemu Windows NT 4 doWindows 2000

W skrócie

Środki bezpieczeństwa w systemie Windows 2000 są elastyczne i mają duże możliwości rozbudowy — od małych przedsiębiorstw, aż do międzynarodowych korporacji, w których ścisłe bezpieczeństwo w sieciach rozległych (WAN) i połączeniach z Internetem jest sprawą priorytetową. Jednak nowe rozwiązania w systemie Windows 2000 w większości dotyczą przedsiębiorstw internetowych.

Bezpieczeństwo w dużych organizacjach osiąga się przez wykorzystywanie hierarchicznych usług katalogowych Windows 2000 Active Directory. Pozostałe zmiany polegają na ułatwionym korzystaniu z:

• łączenia w systemie Windows 2000,

• uwierzytelniania za pomocą internetowych certyfikatów z kluczem publicznym (Internet public key certificates),

• interaktywnego logowania się za pomocą kart elektronicznych.

System Windows 2000 łączy w sobie łatwość użytkowania, dobre narzędzia administracyjne i, zasługującą na zaufanie, infrastrukturę bezpieczeństwa, zarówno w przedsiębiorstwie, jak i w Internecie.

Active Directory w systemie Windows 2000

Usługi katalogowe Active Directory w systemie Windows 2000 służą do przechowywania założeń bezpieczeństwa domeny (Domain Security Policy) i informacji o kontach. Umożliwiają replikację i dostęp do danych o kontach dla wielu kontrolerów domeny (Domain Controllers — DCs) i ułatwiają zdalne administrowanie. Obsługują hierarchiczną przestrzeń nazw (namespace) kont użytkowników, grup i komputerów. W odróżnieniu od płaskiej przestrzeni nazw (flat namespace) kont domen w systemie Windows NT 4, konta mogą być pogrupowane w jednostki organizacyjne (Organizational Units — OUs).

Uwaga: W systemie Windows NT przestrzeń nazw domeny składa się z kont użytkowników (User), grup globalnych (Global group), grup lokalnych (Local group) i komputerów. W przestrzeni nazw Windows NT nie ma żadnej hierarchii — wszystko znajduje się na tym samym poziomie. Grupy globalne i grupy lokalne nie mogą być umieszczane jedna w drugiej, chociaż pierwsze z nich mogą zostać ulokowane wewnątrz drugiego typu grup. Grupa globalna nie może dziedziczyć praw ani uprawnień grupy globalnej wyższego poziomu, ponieważ taki poziom w tym przypadku nie istnieje. Jest to tzw. płaska przestrzeń nazw (flat namespace).

W systemie Windows 2000 mamy do czynienia z przeciwną sytuacją. Przestrzeń nazw (namespace) jest hierarchiczna. Jednostki organizacyjne (Organizational Units — OUs) mogą dziedziczyć założenia bezpieczeństwa (security policies) jednostek organizacyjnych (OUs) wyższego poziomu, a sukcesja ta może być blokowana lub wymuszana. Hierarchiczną przestrzeń nazw systemu Windows 2000 opisano w dalszej części niniejszego rozdziału. Jednostki organizacyjne (OUs) oraz obiekty założeń grupowych (Group Policy Objects — GPOs) omówiono szczegółowo w rozdziale 3.

Prawa administracyjne do tworzenia i zarządzania kontami grup lub użytkowników mogą być przekazane na poziom jednostek organizacyjnych (OUs). Z kolei prawa dostępu można przyznać poszczególnym właściwościom (properties) obiektów użytkownika, aby, np. pojedynczy użytkownik lub grupa, mieli prawo zmiany hasła bez możliwości [Author ID1: at Mon Jul 30 22:56:00 2001 ]modyfikowania innych informacji o koncie. Replikacja Active Directory pozwala na uaktualnianie kont w dowolnym kontrolerze domeny (DC), podczas gdy w systemie Windows NT 4 można było dokonać uaktualnienia tylko w podstawowym kontrolerze domeny (Primary Domain Controller — PDC). Wielokrotne repliki nadrzędne (multiple master replicas) Active Directory w innych kontrolerach domeny (DCs) są automatycznie uaktualniane i synchronizowane.

Uwaga: W domenach systemu Windows 2000 nie występują podstawowe kontrolery domeny (PDC) — wszystkie kontrolery domeny w systemie Windows 2000 są równe, chociaż jeden kontroler domeny (DC) w danej domenie bierze na siebie rolę emulatora podstawowego kontrolera domeny (PDC). W domenach mieszanych, w których występują podstawowe kontrolery domeny (PDC) systemu Windows NT, kontroler domeny systemu Windows 2000 może być odpowiednikiem zapasowego kontrolera domeny (Backup Domain Controller — BDC). Umożliwia to płynne przejście z systemu Windows NT 4 do Windows 2000.

W systemie Windows 2000 zastosowano nowy model domeny, wykorzystujący Active Directory do obsługi wielopoziomowego - [Author ID1: at Mon Jul 30 23:00:00 2001 ]-[Author ID1: at Mon Jul 30 23:00:00 2001 ]hierarchicznego drzewa domen (multilevel hierarchical tree of domains). Zarządzanie relacjami zaufania pomiędzy domenami zostało uproszczone dzięki zastosowaniu dwustronnych, przechodnich relacji zaufania (two-way transitive trusts) w całym drzewie domen. Natomiast dzięki drzewom domen i dwustronnym przechodnim relacjom zaufania protokołu Kerberos (Kerberos trusts) jest możliwa rozbudowa systemu Windows 2000. Sytuacja ta została omówiona w poniższym rozdziale 2.

Zagadnienia pokrewnezobacz na stronie

Korzystanie z przechodnich dwustronnych relacji zaufania (Transitive Two Way Trusts)

Możliwości rozbudowy systemu

Zabezpieczenia rozproszone i protokoły zabezpieczeń

Bezpieczeństwo systemu Windows obejmuje uwierzytelnianie w oparciu o standardowe internetowe protokoły zabezpieczeń. Kerberos 5, opisany w 4. rozdziale, jest protokołem domyślnym, chociaż Windows NT LAN Manager (NTLM) również jest obsługiwany dla zachowania zgodności z wcześniejszymi wersjami systemu Windows. Protokół Transport Layer Security (TLS), oparty na protokole Secure Sockets Layer 3 (SSL3/TLS), obsługuje uwierzytelnianie klientów poprzez przyporządkowanie danych uwierzytelniających (credentials) do istniejących kont systemu Windows NT, w formie certyfikatu z kluczem publicznym (public key certificate). Jednocześnie zapewnia on ulepszoną obsługę protokołów z kluczem publicznym (public key protocols) w systemie Windows 2000. Zabezpieczenia za pomocą klucza publicznego (public key security) oraz protokół SSL3/TLS omówiono w rozdziale 6. Do zarządzania informacjami o kontach (account information) oraz do kontroli dostępu (access control), stosuje się zwykłe narzędzia administracyjne. Korzysta się przy tym z uwierzytelniania za pomocą klucza tajnego (shared secret authentication) lub z zabezpieczeń z kluczem publicznym (public key security).

Oprócz haseł w systemie Windows 2000 istnieje możliwość wykorzystywania kart elektronicznych (smart cards) do logowania interaktywnego (interactive logon). Karty elektroniczne (smart cards), które, mimo że wyglądają jak zwykłe karty bankomatowe, zawierają tysiąc razy więcej informacji oraz służą do szyfrowania i bezpiecznego przechowywania kluczy prywatnych i certyfikatów, umożliwiając tym niezawodne uwierzytelnianie zabezpieczeń rozproszonych.

Wskazówka: Podstawowe wiadomości o kartach elektronicznych (smart cards), ich rodzajach, wyglądzie zewnętrznym oraz terminologię dotyczącą kart elektronicznych można znaleźć pod adresami www.gemplus.com/basics/what.htm i www.gemplus.com/basics/terms.htm.

Na poziomie sieci system Windows wykorzystuje Internet Protocol Security (IPSec) Protokół ten został omówiony w rozdziale 10., w którym opisano także protokoły tunelowania w wirtualnych [Author ID1: at Mon Aug 6 09:31:00 2001 ]Wirtualnych [Author ID1: at Mon Aug 6 09:31:00 2001 ]sieciach [Author ID1: at Mon Aug 6 09:31:00 2001 ]Sieciach [Author ID1: at Mon Aug 6 09:31:00 2001 ]prywatnych [Author ID1: at Mon Aug 6 09:31:00 2001 ]Prywatnych[Author ID1: at Mon Aug 6 09:31:00 2001 ] [Author ID1: at Mon Aug 6 09:31:00 2001 ](VPNs), np:

• protokół Point to Point Protocol (PPP),

• Point-to-Point Tunneling Protocol (PPTP),

• protokół tunelowania Layer 2 (Layer 2 Tunneling Protocol — L2TP).

W rozdziale 11. opisano W[Author ID1: at Mon Aug 6 09:31:00 2001 ]irtualne [Author ID1: at Wed Aug 1 21:08:00 2001 ]S[Author ID1: at Mon Aug 6 09:31:00 2001 ]ieci [Author ID1: at Wed Aug 1 21:08:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:31:00 2001 ] [Author ID1: at Mon Aug 6 09:31:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:31:00 2001 ] [Author ID1: at Mon Aug 6 09:31:00 2001 ]sieci wirtualne [Author ID1: at Wed Aug 1 21:08:00 2001 ](Virtual Private Networks — VPNs), wykorzystywane do zdalnego dostępu poprzez sieci rozległe (WANs), łącznie z Internetem. Protokoły będą omawiane w całej książce, a niniejszy rozdział wprowadzający zawiera jedynie wykaz najbardziej znaczących protokołów. Ich szczegółowe opisy zamieszczone są w dokumentach RFC (Request For Comment). Jeśli, np. będą potrzebne informacje o rozszerzeniach zabezpieczeń systemów nazw domen (Domain Name Systems Security Extensions — RFC 2535) lub na temat współdziałania zabezpieczeń i protokołu zarządzania kluczami (Security Association and Key Management Protocol — RFC 2408), to należy ich szukać pod adresami ftp://ftp..i. si..e. du/innotes/rfc2535..t. xt oraz ftp://ftp..i. si..e. du/innotes/rfc2408..t. xt.

Wskazówka: Lista dokumentów RFC znajduje się pod adresem http://ercole..d. i..u. nito..i. t/CIE/RFC/rfc-ind..h. tm

Zagadnienia pokrewne zobacz na stronie

Instalowanie protokołu z kluczem tajnym (Shared Secrets Protocol)

Stosowanie zabezpieczeń z kluczem publicznym systemu Windows 2000

Instalowanie stacji rejestrowania kart elektronicznych

Korzystanie z kart elektronicznych (smart cards)[Author ID1: at Wed Aug 1 23:56:00 2001 ]

Serwer certyfikatów [Author ID1: at Thu Aug 2 11:15:00 2001 ]Certyfikatów [Author ID1: at Thu Aug 2 11:15:00 2001 ]firmy [Author ID1: at Thu Aug 2 11:16:00 2001 ]Firmy [Author ID1: at Thu Aug 2 11:16:00 2001 ]Microsoft (Microsoft Certificate Server) pozwala organizacjom na wydawanie ich pracownikom i wspólnikom certyfikatów X.509 v. 3. Łączy się to z wprowadzeniem interfejsu aplikacji kryptograficznych (Cryptographic Application Program Interface — CryptoAPI) do zarządzania certyfikatami. Organizacje mogą stosować certyfikaty z kluczem publicznym (public key certificates) wydane przez komercyjną jednostkę certyfikującą (commercial CA), niezależną jednostkę certyfikującą (third-party CA) lub Serwer certyfikatów [Author ID1: at Thu Aug 2 11:16:00 2001 ]Certyfikatów[Author ID1: at Thu Aug 2 11:16:00 2001 ] [Author ID1: at Thu Aug 2 11:16:00 2001 ]firmy [Author ID1: at Thu Aug 2 11:16:00 2001 ]Firmy [Author ID1: at Thu Aug 2 11:16:00 2001 ]Microsoft (Microsoft Certificate Server). Administratorzy systemów określają, które z jednostek certyfikujących (CA) są godne zaufania w ich środowisku i które certyfikaty od danej chwili będą uznawane przy uwierzytelnianiu klientów i przy uzyskiwaniu dostępu do zasobów.

Wykorzystując certyfikaty z kluczem publicznym (public key certificates) i przydzielając je do istniejących kont użytkowników systemu Windows, można uwierzytelnić użytkowników zewnętrznych, którzy nie mają kont w systemie Windows 2000. Prawa dostępu - [Author ID1: at Mon Jul 30 23:09:00 2001 ]— [Author ID1: at Mon Jul 30 23:09:00 2001 ]ustanowione dla konta w systemie Windows - [Author ID1: at Mon Jul 30 23:09:00 2001 ]— [Author ID1: at Mon Jul 30 23:09:00 2001 ]określają, które z zasobów systemu mogą być używane przez użytkowników zewnętrznych. Uwierzytelnianie klientów (client authentication) za pomocą certyfikatu z kluczem publicznym (public key certificate) pozwala na uwierzytelnianie użytkowników zewnętrznych na podstawie certyfikatów wydanych przez zaufane jednostki certyfikujące.

Do zarządzania parami kluczy prywatny-publiczny i certyfikatami, wykorzystywanymi przy dostępie do zasobów internetowych, służą użytkownikom systemu Windows 2000 stosowne narzędzia i okna dialogowe. Skład danych uwierzytelniających zabezpieczenia osobiste, korzystając z bezpiecznego przechowywania na dysku, jest łatwo przenoszony za pomocą standardowego protokołu Personal Information Exchange (PIE). W systemie Windows 2000 wprowadzono obsługę czytników kart elektronicznych (smart card devices).

Zagadnienia pokrewne: zobacz na stronie:

Zakładanie jednostek certyfikujących (Certification Authority)

Instalowanie certyfikatów (CA Certificates)

Szyfrowanie (Encryption)

W systemie operacyjnym zaimplementowano kilka metod szyfrowania, aby wykorzystać podpisy elektroniczne do uzyskiwania uwierzytelnionych strumieni danych. Oprócz podpisanych formantów ActiveX (signed ActiveX controls) i klas Java dla Internet Explorera, w systemie Windows 2000 stosuje się podpisy elektroniczne do zapewnienia spójności wielu programów składowych. Programiści firmy mogą również tworzyć oprogramowanie z podpisem elektronicznym w celu jego dystrybucji i ochrony przed wirusami.

Dostawcy niezależni najczęściej umieszczają usługi dynamicznego uwierzytelniania haseł (dynamic password authentication services) na komputerach z systemem Windows 2000 Server oraz integrują hasła dynamiczne (dynamic passwords) z uwierzytelnianiem w domenie systemu Windows 2000. Interfejsy API (Application Programs Interfaces) i dokumentacja do obsługi tych programów znajduje się w Microsoft Platform Software Development Kit (SDK).

Zagadnienia pokrewne zobacz na stronie:

Szyfrowanie foldera lub pliku

Korzystanie z uwierzytelniania za pomocą klucza publicznego w programie Internet Explorer

Bezpieczeństwo protokołu IP

W świecie biznesu na szeroką skalę korzysta się z Internetu, intranetów, dostępu zdalnego, jak i tworzy się oddziały lokalne. Dane o znaczeniu strategicznym są nieustannie przesyłane przez sieć. Wyzwaniem dla administratorów i innych specjalistów od sieci komputerowych jest konieczne zapewnienie spójności, poufności i uwierzytelnienia danych, które muszą być zabezpieczone przed następującymi działaniami:

• modyfikacją po drodze,

• podsłuchiwaniem, podglądaniem lub kopiowaniem,

• dostępem osób nieuprawnionych.

Aby spełnić powyższe wymagania, w systemie operacyjnym Windows 2000 Server zaimplementowano protokół szyfrowania sieciowego IP Security Protocol (IPSec) w postaci opracowanej przez Internet Engineering Task Force (IETF). Protokół IPSec stosuje się poniżej warstwy transportowej, tak aby jego usługi zabezpieczeń były dziedziczone przez aplikacje w sposób niezauważalny. Do zapewnienia bezpieczeństwa sieci wykorzystującej protokół TCP/IP po obydwu stronach zapory ogniowej (firewall) przedsiębiorstwa IP Security wykorzystuje standardowe algorytmy szyfrowania i metodę wszechstronnego zarządzania zabezpieczeniami (comprehensive security management approach). Wynikiem tych działań jest w systemie Windows 2000 Server strategia zabezpieczania danych wzdłuż całej drogi ich przesyłania (end-to-end security strategy), chroniąca sieć zarówno przed atakami z zewnątrz, jak i od wewnątrz. Protokół IPSec omówiono szczegółowo w rozdziale 10.

Wirtualne sieci [Author ID1: at Mon Aug 6 09:44:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:44:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:44:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:44:00 2001 ]

Wirtualne sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ](Virtual Private Networks — VPN) pozwalają użytkownikowi na tworzenie tuneli w Internecie lub w innej sieci publicznej, przy zachowaniu takiego samego stopnia bezpieczeństwa, jaki zostałby osiągnięty w sieci prywatnej. Z punktu widzenia użytkownika, wirtualne [Author ID1: at Mon Aug 6 09:33:00 2001 ]Wirtualne [Author ID1: at Mon Aug 6 09:33:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ](VPN) wyglądają jak połączenie z serwerem korporacyjnym typu point-to-point. W wirtualnych sieciach prywatnych klienci mobilni (roaming clients) lub zdalni (remote clients) muszą mieć możliwość podłączenia się do zasobów oraz bezpiecznego uwierzytelnienia. Adres prywatny użytkownika, jego nazwa i hasło, muszą być poufne, a dane — zaszyfrowane. Dla klienta i serwera klucze szyfrowania (encryption keys) powinny zostać wygenerowane, [Author ID1: at Mon Jul 30 23:14:00 2001 ]odświeżane, a obsługiwane protokoły — powszechnie spotykane w sieciach publicznych.

Ostrzeżenie! Każde bezpieczeństwo nie jest dane raz na zawsze, zatem klucze szyfrowania nie stanowią tutaj wyjątku. Dlatego też mają okres ważności (expiry time) i należy je periodycznie odświeżać. Podczas aktualizowania klucza powinny być stosowane środki bezpieczeństwa, takie jak alternatywne ścieżki danych (alternate data paths). Jeżeli nieuprawniony użytkownik podejrzy odświeżanie klucza, wówczas zagraża to bezpieczeństwu przeprowadzanej operacji.

Obecnie system Windows 2000 obsługuje rozwiązania wirtualnych [Author ID1: at Mon Aug 6 09:33:00 2001 ]Wirtualnych [Author ID1: at Mon Aug 6 09:33:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]prywatnych[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ]Prywatnych[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ](VPN) opartych na protokole PPTP i na niedawno opracowanym protokole L2TP. Protokół IPSec również obsługuje wirtualne [Author ID1: at Mon Aug 6 09:33:00 2001 ]Wirtualne [Author ID1: at Mon Aug 6 09:33:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ](VPN), ale często nie spełnia wszystkich wymagań. Wirtualne sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:33:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:33:00 2001 ] [Author ID1: at Mon Aug 6 09:33:00 2001 ](VPN) opisane zostały w rozdziale 11.

Narzędzia do konfigurowania i analizowania zabezpieczeń

Do konfigurowania i analizy ustawień zabezpieczeń w systemie Windows 2000 służą:

• szablony [Author ID1: at Mon Jul 30 23:16:00 2001 ]Szablony [Author ID1: at Mon Jul 30 23:16:00 2001 ]zabezpieczeń [Author ID1: at Mon Jul 30 23:16:00 2001 ]Zabezpieczeń [Author ID1: at Mon Jul 30 23:16:00 2001 ](Security Templates),

• [Author ID1: at Mon Aug 6 09:33:00 2001 ]przystawki — konfigurowani[Author ID1: at Mon Jul 30 23:16:00 2001 ]e [Author ID1: at Mon Jul 30 23:16:00 2001 ]Konfigurowanie [Author ID1: at Mon Jul 30 23:16:00 2001 ]i analiza [Author ID1: at Mon Jul 30 23:16:00 2001 ]Analiza [Author ID1: at Mon Jul 30 23:16:00 2001 ]zabezpieczeń [Author ID1: at Mon Jul 30 23:16:00 2001 ]Zabezpieczeń [Author ID1: at Mon Jul 30 23:16:00 2001 ](Security Configuration and Analysis snap-ins),

• program narzędziowy secedit, uruchamiany z wiersza poleceń.

Narzędzia te korzystają z szeregu standardowych szablonów, które można załadować, łączyć i edytować w celu skonfigurowania zabezpieczeń lokalnych. Pozwalają one na analizowanie ustawień zabezpieczeń poprzez porównanie ich z domyślnymi i eksportowanie, wykonanych na zamówienie, szablonów zabezpieczeń, które będą zastosowane w innych komputerach sieci. Ponadto umożliwiają konfigurowanie zabezpieczeń na poziomie komputera lokalnego lub wnoszenie poprawek do szablonów zależnych od rodzaju komputera, które potem mogą być wykorzystywane w każdym z komputerów tego rodzaju (stacja robocza, serwer członkowski, itd.), występujących w danej sieci.

Chociaż system Windows NT 4 zawiera liczne narzędzia graficzne, które mogły być wykorzystywane pojedynczo do konfigurowania różnych warunków bezpieczeństwa, to nie są one scentralizowane — może zajść konieczność uruchomienia trzech lub czterech aplikacji, aby skonfigurować zabezpieczenia dla jednego komputera. Konfiguracja zabezpieczeń może być skomplikowana, a dodatkowo — biorąc pod uwagę zabezpieczenia rozproszone (distributed securities), wprowadzone w systemie Windows 2000 — stopień komplikacji stale rośnie.

Narzędzia do konfigurowania zabezpieczeń zostały zaprojektowane, aby zaspokoić potrzebę centralnego konfigurowania zabezpieczeń i umożliwić analizowanie bezpieczeństwa w całym przedsiębiorstwie.

Bezpośrednie rozwiązania

Struktura Active Directory

Zabezpieczenia systemu Windows 2000 wykorzystują Active Directory jako składnicę (repository) informacji o kontach. Dzięki Active Directory nastąpiła znaczna poprawa wydajności (performance) i możliwości rozbudowy (scalability) w stosunku do implementacji w systemie Windows NT, w której korzysta się z Rejestru. Active Directory oferuje bogato wyposażone środowisko administracyjne.

W systemie Windows NT 4 konta domeny tworzą płaską przestrzeń nazw (flat namespace), bez wewnętrznego uporządkowania. Jednak w systemie Windows 2000 konta użytkowników, grup i komputerów mogą być połączone w kontenery katalogowe (directory containers) określane jako jednostki organizacyjne (Organizational Units — OUs). Domena może zawierać dowolną liczbę jednostek organizacyjnych (OUs) tworzących przestrzeń nazw w postaci drzewa (tree-structured namespace). Przedsiębiorstwa mogą odpowiednio organizować przestrzeń nazw informacji o kontach (namespace for account information) w taki sposób, aby zostały przedstawione oddziały i organizacja całej firmy. Konta użytkowników, jak również jednostki organizacyjne (OUs) są obiektami katalogowymi, którym łatwo zmienić nazwę wewnątrz drzewa domen (domain tree), w zależności od zmian zachodzących w przedsiębiorstwie.

Ze względu na swą hierarchiczną strukturę, przestrzeń nazw domen (domain namespace) systemu Windows 2000 z reguły przedstawiana jest w postaci trójkąta, co zostało zobrazowane na rysunku 1.1.

Wielodomenowy model (multiple domain model) Windows 2000 ma również strukturę hierarchiczną, w przeciwieństwie do modelu z domeną główną (master domain model) systemu Windows NT, w którym występuje tylko hierarchia dwupoziomowa. Model całkowitego zaufania (complete trust model) jest łatwiejszy do zaimplementowania w Windows 2000 dzięki stosowaniu przechodniej, obustronnej relacji zaufania protokołu Kerberos (transitive two-way Kerberos trusts), którą opisano w dalszej części niniejszego rozdziału. Na rysunku 1.2 przedstawiono typową strukturę wielodomenową (multiple domain structure) systemu Windows 2000.

[Author ID2: at Mon Aug 13 11:29:00 2001 ]OU — Jednostka organizacyjna[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Users — Użytkownicy[Author ID2: at Mon Aug 13 11:28:00 2001 ]

[Author ID2: at Mon Aug 13 11:28:00 2001 ]

Rysunek 1.1.[Author ID2: at Mon Aug 13 11:38:00 2001 ] Hierarchiczna przestrzeń nazw domen (domain name space) systemu Windows 2000

Domain A (Root) [Author ID2: at Mon Aug 13 11:30:00 2001 ]- [Author ID1: at Tue Jul 31 00:53:00 2001 ]— [Author ID1: at Tue Jul 31 00:53:00 2001 ][Author ID2: at Mon Aug 13 11:30:00 2001 ]Domena A (Główna)[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Domain B (Child) [Author ID2: at Mon Aug 13 11:30:00 2001 ]- [Author ID1: at Tue Jul 31 00:53:00 2001 ]—[Author ID1: at Tue Jul 31 00:53:00 2001 ][Author ID2: at Mon Aug 13 11:30:00 2001 ] [Author ID1: at Tue Jul 31 00:53:00 2001 ][Author ID2: at Mon Aug 13 11:30:00 2001 ]Domena B (Potomna)[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Domain C (Child) [Author ID2: at Mon Aug 13 11:30:00 2001 ]- [Author ID1: at Tue Jul 31 00:53:00 2001 ]— [Author ID1: at Tue Jul 31 00:53:00 2001 ][Author ID2: at Mon Aug 13 11:30:00 2001 ]Domena C (Potomna)[Author ID2: at Mon Aug 13 11:30:00 2001 ]
[Author ID2: at Mon Aug 13 11:30:00 2001 ]

Rysunek 1.2.[Author ID2: at Mon Aug 13 11:38:00 2001 ] Model wielodomenowy

[Author ID2: at Mon Aug 13 11:31:00 2001 ]

Zintegrowane zarządzanie kontami zabezpieczeń (Security Account Management)

Model zabezpieczeń systemu Windows 2000 stanowi ujednoliconą i spójną implementację kontroli dostępu do wszystkich zasobów domeny na podstawie członkostwa w grupie. Części składowe zabezpieczeń systemu Windows 2000 „mają zaufanie” do zapisanych w katalogu informacji dotyczących bezpieczeństwa, np. [Author ID1: at Mon Jul 30 23:19:00 2001 ]usługa uwierzytelniania systemu Windows 2000 zapisuje informacje o hasłach zaszyfrowanych w bezpiecznej części obiektów użytkownika katalogu (directory user objects). System operacyjny ufa, że informacje o założeniach bezpieczeństwa są przechowywane bezpiecznie i ograniczenia dotyczące kont lub członkostwa w grupie nie będą zmienione przez osoby nieuprawnione. Ponadto informacje o założeniach bezpieczeństwa dla kompleksowego zarządzania domeną są przechowywane w Active Directory.

Zapisywanie informacji o kontach zabezpieczeń w Active Directory oznacza, że użytkownicy i grupy są przedstawiani jako obiekty w katalogu. Prawo odczytu i zapisu do obiektów w katalogu może być przyznane obiektowi jako całości lub jego pojedynczej właściwości. Administratorzy kontrolują dokładnie, kto może aktualizować informacje o użytkowniku albo grupie. Prawa dostępu opisano szczegółowo w dalszej części rozdziału. Rozdział 3. zawiera dokładny opis stosowania konsoli MMC, założeń grupowych (Group Policy MMC) do tworzenia i modyfikowania obiektów założeń grupowych (GPO).

Active Directory przechowuje informacje o zasadach bezpieczeństwa domeny (domain security policy information), takich jak ograniczenia dotyczące haseł, które obowiązują w całej domenie, oraz systemowe uprawnienia dostępu (system access privileges). W systemie Windows 2000 zaimplementowano obiektowy model bezpieczeństwa (object-based security model) i kontrolę dostępu do wszystkich obiektów Active Directory. Każdy z tych obiektów ma unikatowy deskryptor bezpieczeństwa (security descriptor), określający uprawnienia dostępu konieczne do odczytania czy modyfikacji ich właściwości. Active Directory korzysta z personifikacji (impersonation) i weryfikacji dostępu do Windows 2000, aby określić, czy klient Active Directory może odczytać lub modyfikować dany obiekt. Oznacza to, że żądania klienta LDAP (Lightweight Directory Access Protocol) skierowane do katalogu wymagają od systemu operacyjnego przejęcia kontroli dostępu, zamiast pozostawiania możliwości podejmowania decyzji, dotyczących kontroli dostępu w sferze usług katalogowych Active Directory.

Połączenie zarządzania kontami zabezpieczeń (security account management) z usługami katalogowymi Active Directory ma kilka zalet:

• active [Author ID0: at Thu Nov 30 00:00:00 1899 ]Active [Author ID1: at Mon Jul 30 23:21:00 2001 ]Directory przy lepszej wydajności obsługuje większą liczbę obiektów użytkownika (ponad milion) niż w przypadku Rejestru. Rozmiar pojedynczej domeny nie jest już ograniczony wydajnością składnicy kont zabezpieczeń (security account repository). Drzewo połączonych domen może obsłużyć duże, złożone struktury organizacji,

• administrowanie informacjami o kontach rozszerzono za pomocą zaawansowanych narzędzi graficznych wykorzystywanych do zarządzania Active Directory, jak również poprzez obsługę języków skryptowych dzięki usługom katalogowym OL EDS. (Object Linking and Embedding Directory Services). Często spotykane zadania mogą być wykonywane automatycznie za pomocą skryptów wsadowych (batch scripts),

• usługi replikacji katalogów (directory replication services) obsługują wiele kopii informacji o kontach, które można aktualizować w dowolnej kopii i w dowolnym kontrolerze domeny (DC). LDAP oraz obsługa synchronizacji katalogów dostarczają mechanizmów do łączenia katalogów w systemie Windows z innymi katalogami w przedsiębiorstwie.

Wykorzystywanie obustronnych przechodnich relacji zaufania (transitive two-way trusts)

Relacje zaufania pomiędzy domenami w hierarchicznym drzewie domen (hierarchical domain tree) Windows 2000 pozwala użytkownikowi, który ma konto zdefiniowane w jednej domenie, na uwierzytelnienie — poprzez serwery — zasobów (resource servers) w innej domenie.

W systemie Windows NT i wersjach wcześniejszych międzydomenowe relacje zaufania (interdomain trust relationships) były ustanawiane za pomocą jednostronnych relacji zaufania pomiędzy kontami (one way trusted domain accounts) w różnych domenach. Zarządzanie relacjami zaufania pomiędzy domenami kont (account domains) a domenami zasobów (resource domains) w dużej sieci jest zadaniem złożonym. Aby zapewnić zgodność z domenami NT 4 i umożliwić, w razie konieczności, ustanowienie jednostronnych relacji zaufania pomiędzy domenami systemu Windows 2000, Active Directory obsługuje bez zastrzeżeń relacje zaufania na wzór systemu Windows NT 4.

Jednakże Active Directory również obsługuje obustronne przechodnie relacje zaufania (two-way transitive trusts) — relacje zaufania protokołu Kerberos — pomiędzy domenami, które są częścią drzewa domen (domain tree) systemu Windows 2000. W przypadku przechodniej relacji zaufania (transitive trust), tzn. jeśli domena A znajduje się w relacji zaufania z domeną B i domena B znajduje się w relacji zaufania z domeną C, wówczas domena A znajduje się w relacji zaufania z domeną C.

Na rysunku 1.3 przedstawiono model relacji pełnego zaufania pomiędzy domenami (full-trust domain model) w systemie Windows 2000 w porównaniu z tym samym modelem istniejącym w systemie Windows NT 4. W systemie Windows NT 4 wymagane jest ustanowienie i utrzymywanie dwunastu relacji zaufania (trusts), podczas gdy w systemie Windows 2000 konieczne są tylko trzy.

Każda z domen przez domniemanie znajduje się w relacji zaufania z innymi domenami drzewa. Jeśli w przypadku określonej domeny nie jest potrzebna obustronna relacja zaufania (two-way trusts), można wprost zdefiniować konta znajdujące się w relacji jednostronnej relacji zaufania (one-way trust accounts). Utworzenie domeny potomnej (child domain) automatycznie ustanawia relację zaufania protokołu Kerberos (Kerberos trust) z domeną macierzystą.

[Author ID2: at Mon Aug 13 11:31:00 2001 ]Windows 2000 Full Trust Model — Model relacji pełnego zaufania w systemie Windows 2000[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Wind[Author ID2: at Mon Aug 13 11:30:00 2001 ]ows NT Full Trust Model — Model relacji pełnego zaufania w systemie Windows NT[Author ID2: at Mon Aug 13 11:30:00 2001 ][Author ID1: at Thu Aug 2 11:18:00 2001 ]

[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Rysunek 1.3.[Author ID2: at Mon Aug 13 11:38:00 2001 ] Porównanie modeli relacji zaufania

Na potrzeby poniższej procedury przyjęto, że w domenie znajduje się jeden kontroler domeny (DC), który zostanie głównym (root) oraz przynajmniej jeden serwer członkowski (member server).

Aby awansować serwer członkowski (member server) na kontrolera domeny potomnej (child domain DC) należy:

1. Wybrać w serwerze członkowskim (member server) opcję Start/[Author ID1: at Tue Jul 31 14:35:00 2001 ]\[Author ID1: at Tue Jul 31 14:35:00 2001 ]Run i wpisać dcpromo.

2. Po uzyskaniu pozwolenia wybrać opcję Domena potomna (child [Author ID1: at Mon Jul 30 23:23:00 2001 ]Child [Author ID1: at Mon Jul 30 23:23:00 2001 ]domain).

3. Podać nazwę domeny macierzystej (parent domain) oraz nazwę i hasło konta administratora w tej domenie.

Ostrzeżenie! Ważne jest, aby odróżniać domenę główną (root domain) od domeny macierzystej (parent domain). Przykładowo na rysunku 1.2 domena A jest domeną główną (root domain) i jednocześnie domeną macierzystą domeny B. Jednakże domeną macierzystą (parent domain) domeny C jest domena B, a nie domena główna (root domain).

Przekazywanie administrowania

Prawa do administrowania mogą być przekazane, aby ograniczyć administrowanie zabezpieczeniami (security administration) do określonych podzbiorów domeny całej organizacji. Pełnomocnikom przyznaje się prawa do zarządzania niewielkimi zbiorami użytkowników lub grup w obszarze ich odpowiedzialności, ale nie daje im się uprawnień do zarządzania kontami w innych częściach danej organizacji.

Przekazywanie odpowiedzialności za tworzenie nowych użytkowników lub grup jest definiowane na poziomie jednostki organizacyjnej (OU) lub tam, gdzie są tworzone konta. Administratorzy grup pojedynczej jednostki organizacyjnej (OU) niekoniecznie maja uprawnienia do tworzenia i zarządzania kontami w innych jednostkach organizacyjnych (OUs) domeny. Ustawienia założeń dla całej domeny (domain-wide policy settings) i prawa dostępu ustanowione na wyższych poziomach drzewa katalogów (directory tree) mają zastosowanie w całym drzewie katalogów, ponieważ zachodzi dziedziczenie praw dostępu.

Poniżej przedstawiono trzy sposoby przekazania zakresu obowiązków administratora:

• przekaż uprawnienia do zmiany właściwości któregokolwiek z kontenerów, np. założenia[Author ID1: at Tue Jul 31 14:42:00 2001 ] [Author ID1: at Tue Jul 31 14:42:00 2001 ]Założenia[Author ID1: at Tue Jul 31 14:42:00 2001 ] [Author ID1: at Tue Jul 31 14:42:00 2001 ]lokalne[Author ID1: at Thu Aug 2 11:18:00 2001 ] [Author ID1: at Thu Aug 2 11:18:00 2001 ]Lokalne[Author ID1: at Thu Aug 2 11:18:00 2001 ] [Author ID1: at Thu Aug 2 11:18:00 2001 ](Local Policies) samego obiektu domeny,

• przekaż uprawnienia do tworzenia i usuwania obiektów potomnych (child objects) podanego typu w danej jednostce organizacyjnej (OU), takiego jak: użytkownicy[Author ID1: at Mon Jul 30 23:25:00 2001 ] [Author ID1: at Mon Jul 30 23:25:00 2001 ]Użytkownicy[Author ID1: at Mon Jul 30 23:25:00 2001 ] [Author ID1: at Mon Jul 30 23:25:00 2001 ](users[Author ID1: at Mon Jul 30 23:25:00 2001 ]Users[Author ID1: at Mon Jul 30 23:25:00 2001 ]), grupy[Author ID1: at Mon Jul 30 23:25:00 2001 ] [Author ID1: at Mon Jul 30 23:25:00 2001 ]Grupy[Author ID1: at Mon Jul 30 23:25:00 2001 ] [Author ID1: at Mon Jul 30 23:25:00 2001 ](groups[Author ID1: at Mon Jul 30 23:25:00 2001 ]Groups[Author ID1: at Mon Jul 30 23:25:00 2001 ]) czy drukarki[Author ID1: at Mon Jul 30 23:25:00 2001 ] [Author ID1: at Mon Jul 30 23:25:00 2001 ]Drukarki[Author ID1: at Mon Jul 30 23:25:00 2001 ] [Author ID1: at Mon Jul 30 23:25:00 2001 ](printers[Author ID1: at Mon Jul 30 23:25:00 2001 ]Printers[Author ID1: at Mon Jul 30 23:25:00 2001 ]),

• przekaż uprawnienia do aktualizowania podanych właściwości obiektów potomnych (child objects) podanego typu w danej jednostce organizacyjnej (OU), np. prawo do ustanawiania haseł dla obiektów użytkowników.

Interfejs użytkownika [Author ID0: at Thu Nov 30 00:00:00 1899 ]Użytkownika [Author ID1: at Mon Aug 6 09:35:00 2001 ]— administrowanie [Author ID0: at Thu Nov 30 00:00:00 1899 ]Administrowanie [Author ID1: at Mon Aug 6 09:35:00 2001 ]usługami katalogowymi (Directory Service Administration user interface) pozwala na podgląd informacji o przekazanych uprawnieniach zdefiniowanych dla kontenerów (containers). Administrator może przekazać nowe uprawnienia, wybierając, komu mają zostać przekazane i które uprawnienia są konieczne do przekazania.

Uwaga: W rozdziale 3. znajduje się szczegółowy opis, w jaki sposób należy korzystać z interfejsu [Author ID0: at Thu Nov 30 00:00:00 1899 ]Interfejsu[Author ID1: at Mon Aug 6 09:35:00 2001 ] [Author ID1: at Mon Aug 6 09:35:00 2001 ]użytkownika [Author ID1: at Mon Aug 6 09:35:00 2001 ]Użytkownika [Author ID1: at Mon Aug 6 09:35:00 2001 ]— administrowanie [Author ID1: at Mon Aug 6 09:35:00 2001 ]Administrowanie [Author ID1: at Mon Aug 6 09:35:00 2001 ]usługami katalogowymi (Directory Service Administration user interface) w celu podglądu i wprowadzania poprawek do informacji o przekazywaniu uprawnień w danym kontenerze.

Dzięki połączeniu składnicy kont zabezpieczeń (security account repository) z Active Directory uzyskuje się poprawę wydajności systemu, płynność w jego administrowaniu i możliwość rozbudowy, w przypadku wielkich organizacji. Przedsiębiorstwa internetowe (Internet-based enterprise) mogą wykorzystywać drzewa domen (domain trees) i hierarchiczne jednostki organizacyjne (OUs) do organizowania kont z określonymi prawami dostępu do ich systemu komputerowego dla wspólników, częstych klientów lub dostawców.

Zastosowanie Listy kontroli [Author ID1: at Mon Aug 6 09:45:00 2001 ]Kontroli [Author ID1: at Mon Aug 6 09:45:00 2001 ]dostępu [Author ID1: at Mon Aug 6 09:45:00 2001 ]Dostępu [Author ID1: at Mon Aug 6 09:45:00 2001 ](Access Control List) do precyzyjnego ustalania praw dostępu

W wielkich organizacjach zazwyczaj wymaga się, aby pewna liczba osób lub grup miały przyznane prawa do zabezpieczania i zarządzania infrastrukturą kont sieciowych (network account infrastructure). Muszą one mieć możliwość nadawania praw dostępu dla podanych operacji, [Author ID1: at Mon Jul 30 23:28:00 2001 ]takich jak usuwanie haseł użytkowników lub blokowanie kont (disabling accounts) [Author ID1: at Mon Jul 30 23:28:00 2001 ]podanym grupom lub osobom, bez jednoczesnego nadania uprawnień, np., do tworzenia nowych kont lub zmiany innych właściwości kont użytkowników.

Architektura zabezpieczeń obiektów Active Directory wykorzystuje deskryptory bezpieczeństwa (security descriptors) systemu Windows 2000 do kontroli dostępu do obiektów. Każdy z obiektów w katalogu ma unikatowy deskryptor bezpieczeństwa (security descriptor). Lista kontroli [Author ID1: at Mon Aug 6 09:35:00 2001 ]Kontroli [Author ID1: at Mon Aug 6 09:35:00 2001 ]dostępu [Author ID1: at Mon Aug 6 09:35:00 2001 ]Dostępu [Author ID1: at Mon Aug 6 09:35:00 2001 ](Access Control List [Author ID1: at Tue Jul 31 00:50:00 2001 ]-[Author ID1: at Tue Jul 31 00:50:00 2001 ]— [Author ID1: at Tue Jul 31 00:50:00 2001 ]ACL), będąca częścią deskryptora bezpieczeństwa (security descriptor), zawiera pozycje, które nadają bądź odbierają osobom czy grupom określone prawa dostępu. Prawa dostępu można nadawać lub odbierać w różnym zakresie dla danego obiektu. Można je zdefiniować, tak aby:

• miały zastosowanie do obiektu jako całości, w wyniku czego będą odnosiły się do wszystkich właściwości obiektu,

• miały zastosowanie do grup właściwości określonych przez zestawy właściwości w obiekcie,

• miały zastosowanie do pojedynczych właściwości obiektu.

Domyślnym prawem dostępu (access permission) twórcy obiektu jest prawo do odczytu — [Author ID1: at Mon Jul 30 23:29:00 2001 ]-[Author ID1: at Mon Jul 30 23:29:00 2001 ]zapisu (read-write access) do wszystkich właściwości danego obiektu. Nadawanie lub odmowa praw dostępu do zestawu właściwości (property set) obiektu jest dogodnym sposobem definiowania uprawnień dla grup właściwości pokrewnych. Grupa właściwości jest określona przez atrybut — zestaw atrybutów (property set attribute) danej właściwości w schemacie (schema). Zmieniając schemat (schema), można przystosować relację zestawów właściwości (property set relationship) do własnych potrzeb.

Na zakończenie jeszcze jedna, ważna informacja. Najbardziej szczegółowe jest definiowanie praw dostępu do pojedynczej właściwości. Określanie tego rodzaju dostępu jest osiągalne dla wszystkich obiektów w Active Directory.

Obiekty w katalogu typu kontener (container objects) również obsługują precyzyjne prawa dostępu poprzez zdefiniowanie, kto ma uprawnienia do tworzenia obiektów potomnych oraz które rodzaje obiektów potomnych mogą powstać. Np. kontrola dostępu, zdefiniowana dla jednostki organizacyjnej (OU), może określać, komu zezwala się na tworzenie obiektów użytkownika (kont) w tym kontenerze. Inna pozycja kontroli dostępu dla tej jednostki organizacyjnej (OU) może definiować, kto ma prawo tworzyć obiekty drukarek.

Edytor listy [Author ID1: at Sun Aug 5 19:36:00 2001 ]Listy [Author ID1: at Sun Aug 5 19:36:00 2001 ]kontroli [Author ID1: at Sun Aug 5 19:36:00 2001 ]Kontroli [Author ID1: at Sun Aug 5 19:36:00 2001 ]dostępu[Author ID1: at Sun Aug 5 19:36:00 2001 ] [Author ID1: at Sun Aug 5 19:36:00 2001 ]Dostępu[Author ID1: at Sun Aug 5 19:36:00 2001 ] [Author ID1: at Sun Aug 5 19:36:00 2001 ](Access Control List Editor) jest wykorzystywany do podglądu lub zmiany uprawnień dotyczących bezpieczeństwa obiektu i stanowi interfejs do definiowania praw dostępu do obiektów Active Directory za pomocą zestawu właściwości (property set) lub pojedynczych właściwości. Edytor ACL pozwala również na określenie dziedziczonych praw dostępu w obiekcie typu kontener — innymi słowy — prawami dostępu, które spływają do wszystkich podobiektów w danej części drzewa katalogu.

Rozwiązania pokrewne [Author ID1: at Mon Jul 30 23:30:00 2001 ]zobacz na stronie:

Korzystanie z Edytora listy kontroli dostępu (Access Control List Editor)

Zastosowanie protokołów [Author ID1: at Mon Aug 6 09:45:00 2001 ]Protokołów [Author ID1: at Mon Aug 6 09:45:00 2001 ]zabezpieczeń [Author ID1: at Mon Aug 6 09:45:00 2001 ]Zabezpieczeń [Author ID1: at Mon Aug 6 09:45:00 2001 ](security [Author ID1: at Mon Aug 6 09:45:00 2001 ]Security [Author ID1: at Mon Aug 6 09:45:00 2001 ]protocols[Author ID1: at Mon Aug 6 09:45:00 2001 ]Protoc[Author ID1: at Mon Aug 6 09:45:00 2001 ]ols[Author ID1: at Mon Aug 6 09:45:00 2001 ])

System Windows 2000 obsługuje wiele sieciowych protokołów zabezpieczeń, ponieważ każdy z nich zapewnia zgodność z istniejącymi klientami, efektywniejsze mechanizmy zabezpieczeń lub współdziałanie różnorodnych sieci, takich jak Internet. Łatwiejszym rozwiązaniem byłoby posiadanie jednego protokołu zabezpieczeń (security protocol), zaspokajającego wszystkie potrzeby, ale konfiguracje sieci w małych firmach i u wielkich usługodawców internetowych nie mają jednakowych wymagań dotyczących bezpieczeństwa. Kupującemu (customer) potrzebna jest możliwość wyboru integrowania nowych technologii zabezpieczeń, np. haseł dynamicznych (dynamic passwords) czy kryptografii klucza publicznego, z ich własnym środowiskiem komputerowym.

W obecnie wykorzystywanych sieciach przedsiębiorstw znajduje się wiele protokołów uwierzytelniania (authentication protocols), a architektura systemu Windows 2000 nie narzuca ograniczeń w tym zakresie. Stosując uniwersalne interfejsy API Win32 (general-purpose Win32 security APIs), system operacyjny izoluje obsługiwane aplikacje od szczegółów różnych dostępnych protokołów zabezpieczeń (security protocols). Interfejsy aplikacji wyższego poziomu, które są elementem mechanizmu uwierzytelniania zdalnego wywołania procedury (Authenticated Remote Procedure Call) i modelu obiektowego składników rozproszonych (Distributed Component Object Model — DCOM), dzięki odpowiednim parametrom, pozwalają na pomijanie nieistotnych szczegółów przy korzystaniu z usług zabezpieczeń (security services). Ci, którzy znają interfejs sterownika transportu (Transport Driver Interface — TDI) i specyfikację NDIS (Network Driver Interface Specification) systemu Windows NT, docenią dużą elastyczność, uzyskaną poprzez odizolowanie aplikacji i usług od szczegółów protokołu zabezpieczeń.

Infrastruktura bezpieczeństwa systemu Windows 2000 obsługuje kilka pierwotnych protokołów zabezpieczeń (security protocols):

1. Windows NT LAN Manager (NTLM) — stosowany w systemie Windows NT 4 i wcześniejszych wersjach Windows NT. NTLM będzie nadal obsługiwany i stosowany, w przypadku wcześniejszych wersji Windows NT, w celu uwierzytelniania sieciowego, dostępu do plików zdalnych (remote file access) i uwierzytelnionych połączeń RPC.

2. Kerberos 5 — zastąpił NTLM w roli pierwotnego protokołu zabezpieczeń dostępu do zasobów w obrębie domeny lub pomiędzy domenami Windows 2000. Protokół uwierzytelniania Kerberos jest standardowym protokołem, którego zalety wykorzystano do uwierzytelniania w sieci Windows. Do korzyści wynikających z zastosowania protokołu Kerberos należy wzajemna autoryzacja klienta i serwera, zmniejszenie obciążenia serwera podczas ustanawiania połączenia oraz obsługa przekazywania uwierzytelniania (delegation of authorization) od klienta do serwera, poprzez zastosowanie procedur pośredniczących (proxy mechanizm).

3. Rozproszone uwierzytelnianie [Author ID1: at Mon Aug 6 09:36:00 2001 ]Uwierzytelnianie [Author ID1: at Mon Aug 6 09:36:00 2001 ]za [Author ID1: at Mon Aug 6 09:36:00 2001 ]Za [Author ID1: at Mon Aug 6 09:36:00 2001 ]pomocą [Author ID1: at Mon Aug 6 09:36:00 2001 ]Pomocą [Author ID1: at Mon Aug 6 09:36:00 2001 ]haseł [Author ID1: at Mon Aug 6 09:36:00 2001 ]Haseł [Author ID1: at Mon Aug 6 09:36:00 2001 ](Distributed Password Authentication — DPA) — protokół uwierzytelniania z kluczem tajnym (shared secret protocol) stosowany jest przez niektóre z wielkich serwisów internetowych (Internet membership organizations), takich jak Microsoft Network (MSN) czy CompuServe. Wchodzi on w skład usług Microsoft Commercial Internet System (MCIS) i jest specjalnie zaprojektowany w taki sposób, by użytkownicy mogli stosować identyczne hasło (Internet membership password) do łączenia się do dowolnej liczby witryn, które są częścią tego samego serwisu internetowego (membership organization). Internetowe serwery tematyczne (Internet content servers) stosują usługę uwierzytelniania MCIS jako wewnętrzną (back-end) usługę internetową i użytkownicy mogą łączyć się z wieloma witrynami bez konieczności wielokrotnego wprowadzania hasła.

Rozwiązania pokrewne Zobacz na stronie:

Zapewnienie możliwości rozbudowy

• Protokoły korzystające z klucza publicznego — zapewniają poufność i niezawodność w Internecie. Protokół Secure Socket Layer jest faktycznym standardem dla połączeń pomiędzy przeglądarkami internetowymi (Internet browser) a internetowymi serwerami informacyjnymi (Internet information servers). Protokół TLS (Transport Layer Security) jest standardowym protokołem IETF stworzonym na podstawie SSL3. Protokoły te korzystają z certyfikatów klucza publicznego do uwierzytelniania klientów oraz z serwerów i zależą infrastruktury klucza publicznego (public key infrastructure) do stosowania w szerokim zakresie. Zabezpieczenia systemu Windows 2000 mają rozszerzoną obsługę protokołów klucza publicznego, co zostało opisane w dalszej części niniejszego rozdziału.

[Author ID1: at Wed Aug 1 23:56:00 2001 ]

Rada: Wdrażanie protokołów zabezpieczeń (security protocols) zostało dokładnie opisane w rozdziale 4. Zastosowanie założeń bezpieczeństwa klucza publicznego (public key security policy) opisano w rozdziale 6.

Bezpieczeństwo w przedsiębiorstwie zależy od elastyczności w korzystaniu z odpowiednich mechanizmów zabezpieczeń w poszczególnych sytuacjach. Przetwarzanie danych w przedsiębiorstwie będzie nadal zależało od szerokiego zakresu usług sieciowych, świadczonych przez pliki zdalne (remote files) i serwery wydruku (print servers), aplikacje ekonomiczne (business applications) i serwery danych (data servers) oraz hurtownie danych i środowisko przetwarzania transakcji. Obsługa wielu sieciowych protokołów zabezpieczeń umożliwia systemowi Windows 2000 świadczenie różnorodnych usług sieciowych, jak również technologii internetowych.

Zastosowanie interfejsu [Author ID1: at Mon Aug 6 09:45:00 2001 ]Interfejsu [Author ID1: at Mon Aug 6 09:45:00 2001 ]usługodawcy [Author ID1: at Mon Aug 6 09:45:00 2001 ]Usługodawcy [Author ID1: at Mon Aug 6 09:45:00 2001 ]zabezpieczeń [Author ID1: at Mon Aug 6 09:45:00 2001 ]Zabezpieczeń [Author ID1: at Mon Aug 6 09:45:00 2001 ](Security Support Provider Interface)

Interfejs usługodawcy [Author ID1: at Mon Aug 6 09:36:00 2001 ]Usługodawcy [Author ID1: at Mon Aug 6 09:36:00 2001 ]zabezpieczeń[Author ID1: at Mon Aug 6 09:36:00 2001 ] [Author ID1: at Mon Aug 6 09:36:00 2001 ]Zabezpieczeń[Author ID1: at Mon Aug 6 09:36:00 2001 ] [Author ID1: at Mon Aug 6 09:36:00 2001 ](Security Support Provider Interface — SSPI) jest interfejsem API platformy Win32 wykorzystywanym przez wiele aplikacji i usług systemowych, takich jak Internet Explorer (IE) czy Internet Information Server (IIE). Jego zadaniem jest oddzielenie protokołów poziomu aplikacji od, służących do uwierzytelniania sieciowego, protokołów zabezpieczeń. Usługodawcy zabezpieczeń (security providers) do uwierzytelniania użytkownika wykorzystują różnorodne dane uwierzytelniające (credentials) — klucze tajne (shared secret keys) albo certyfikaty klucza publicznego. Protokoły zabezpieczeń (security protocols) współdziałają z różnymi usługami uwierzytelniania (authentication services) i składami informacji o kontach (account information stores).

Usługodawca zabezpieczeń NTLM wykorzystuje do uwierzytelniania klientów (client authentication) i informacji dotyczących autoryzacji usługę uwierzytelniania MSV1_0 i usługę NetLogon w kontrolerze domeny (DC).

Usługodawca zabezpieczeń (security provider) Kerberos łączy się z centrum [Author ID1: at Mon Aug 6 09:36:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:36:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:36:00 2001 ]Dystrybucj[Author ID1: at Mon Aug 6 09:36:00 2001 ]i [Author ID1: at Mon Aug 6 09:36:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:36:00 2001 ] [Author ID1: at Mon Aug 6 09:36:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:36:00 2001 ] [Author ID1: at Mon Aug 6 09:36:00 2001 ](Key Distribution Center — KDC), które działa w trybie online oraz ze składem kont Active Directory (Active Directory account store), aby otrzymać bilet sesji.

Protokół DPA (Distributed Password Authentication) korzysta z usług zabezpieczeń MCIS do uwierzytelniania członków (memebership authentication) i dostępu do właściwych dla serwera informacji.

Usługi kanałów bezpiecznych (secure [Author ID1: at Wed Aug 1 22:04:00 2001 ]secure [Author ID1: at Wed Aug 1 22:04:00 2001 ]channel services) oparte są na certyfikatach klucza publicznego (public key certificates) wydanych przez jednostki certyfikujące godne zaufania (trusted CA) i nie wymagają serwera uwierzytelniania, pracującego w trybie online (online authentication server).

Interfejs SSPI komunikuje się z interfejsem API platformy Win32 opartym na interfejsie Generic Security Service Application Program Interface (GSS — API). Aplikacje i usługi systemu Windows 2000 stosują SSPI do oddzielenia protokołów poziomu aplikacji (application level protocols) od szczegółów protokołów zabezpieczeń sieciowych (network security protocols). System Windows 2000 obsługuje interfejs SSPI, aby ograniczyć wielkość programów poziomu aplikacji, koniecznych do obsługi wielu protokołów uwierzytelniania (authentication protocols). Protokół SSPI obsługuje wiele mechanizmów uwierzytelniania, opartych na protokołach z kluczem wspólnym (shared secret key) lub protokołach z kluczem publicznym. Aplikacje stosujące zintegrowane zabezpieczenia systemu Windows 2000 korzystają z modułowości interfejsu SSPI, wywołując katalog procedur SSPI (SSPI routines directory) lub korzystając z protokołów wyższego poziomu zarządzania połączeniami sieciowymi (higher-level network connection management protocols) dostarczonych przez uwierzytelnione RPC lub DCOM. [Author ID2: at Mon Aug 13 11:41:00 2001 ]

Interfejs GSS — API jest zdefiniowany w dokumencie RFC 1508, dostępnym pod adresem ftp://ftp..i. si..e. du/innotes/rfc1508..t. xt.

Na rysunku 1.4 przedstawiono architekturę umożliwiającą obsługę wielu protokołów zabezpieczeń (security protocols) zaimplementowaną w Windows 2000, która korzysta z interfejsu SSPI.

[Author ID2: at Mon Aug 13 11:41:00 2001 ]Remote File — Plik zdalny[Author ID0: at Thu Nov 30 00:00:00 1899 ]

DCOM Application — Aplikacje DCOM[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Secure RPC — Bezpieczne RPC[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Directory enabled apps using ADSI — Aplikacje Active Directory korzystające z interfejsów ADSI[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Mail, Chat, News — Po[Author ID2: at Mon Aug 13 11:39:00 2001 ]czta, chat, grupy dyskusyjne[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Membership Services — Usługi członkowskie[Author ID2: at Mon Aug 13 11:39:00 2001 ]

Rysunek 1.4.[Author ID2: at Mon Aug 13 11:39:00 2001 ] Architektura wielokrotnego uwierzytelniania firmy Microsoft (Microsoft's Multiple Authentication Architecture)

Rozwiązania pokrewnezobacz na stronie:

Zastosowanie interfejsu usługodawcy zabezpieczeń (Security Support Provider Interface)

Zastosowanie protokołu uwierzytelniania Kerberos 5

Protokół uwierzytelniania Kerberos 5 został zdefiniowany w dokumencie The Kerberos Network Authentication Service 5, którego autorami są J. Kohl i C. Neumann (Internet RFC 1510). Jest on dostępny pod adresem ftp://ftp..i. si..e. du/innotes/rfc1510..t. xt. Protokół ten został zweryfikowany w praktyce i stał się standardowym protokołem zabezpieczeń. Implementacja protokołu Kerberos w systemie Windows 2000 bazuje na definicji protokołu Kerberos zawartej w dokumencie RFC 1510.

Protokół określa interakcje pomiędzy klientem a usługą uwierzytelniania sieciowego (network authentication service) znaną jako centrum dystrybucji klucza (Key Distribution Center — KDC). W systemie Windows 2000 centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ](KDC) jest usługą uwierzytelniania w każdym z kontrolerów domeny (DC). Określenia domena (domain) systemu Windows 2000 i obszar (realm) protokołu Kerberos są synonimami. Wersję runtime klienta protokołu Kerberos (Kerberos client runtime) zaimplementowano w systemie Windows 2000 w postaci usługodawców bezpieczeństwa systemu Windows 2000 (Windows 2000 security provider), opartych na interfejsie SSPI. Pierwsze uwierzytelnienie za pomocą protokołu Kerberos jest elementem architektury usługi logowania WinLogon do uwierzytelniania użytkownika metodą jednokrotnego logowania (Single-Sign-On — SSO). Serwer protokołu Kerberos (Centrum Dystrybucji Kluczy — KDC), zintegrowany z istniejącymi usługami bezpieczeństwa systemu Windows i pracującymi w kontrolerze domeny (DC), wykorzystuje Active Directory jako bazę danych kont użytkowników (którzy są tzw. security principals) lub grup.

Protokół uwierzytelniania Kerberos zwiększa wydajność uwierzytelniania serwerów (server authentication) podczas pierwszego ustalania połączenia. Do uwierzytelnienia klienta serwer aplikacji (application server) nie musi łączyć się z kontrolerem domeny (DC). Serwer aplikacji (application serwer) radzi sobie lepiej przy obsługiwaniu żądań połączenia od wielu klientów.

Protokół Kerberos pozwala na delegowanie uwierzytelniania (delegation of authentication) w przypadku wielowarstwowej architektury aplikacji typu klient — [Author ID1: at Tue Jul 31 00:54:00 2001 ]-[Author ID1: at Tue Jul 31 00:54:00 2001 ]serwer (multitier client-server application architectures). Kiedy klient łączy się z serwerem, wówczas staje się on personifikacją klienta w tym systemie. Jeśli serwer ma połączyć się poprzez sieć z innym serwerem wewnętrznym (back-end server), aby transakcję klienta doprowadzić do końca, to protokół Kerberos pozwala na przekazanie uwierzytelnienia (delegation of authentication) do pierwszego serwera, w celu połączenia się z innym serwerem w imieniu klienta. Delegowanie umożliwia, by ten drugi serwer również był personifikacją klienta (impersonate the client).

Za pomocą protokołu Kerberos ustanowione zostają przechodnie relacje zaufania (transitive trust relationships) uwierzytelniania międzydomenowego (interdomain authentication). Użytkownicy mogą być autoryzowani w domenach w dowolnym miejscu drzewa domen (domain tree), ponieważ usługi uwierzytelniania (KDC) w każdej z domen ufają biletom (tickets) wydanym przez inne centra [Author ID1: at Mon Aug 6 09:37:00 2001 ]Centra [Author ID1: at Mon Aug 6 09:37:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ](KDC) w tym drzewie domen (domain tree). Przechodnie relacje zaufania (transitive trust) upraszcza zarządzanie domenami w wielkich sieciach z wieloma domenami.

Bilety protokołu Kerberos (Kerberos tickets)

Protokół Kerberos jest protokołem uwierzytelniania z kluczem tajnym (shared secret authentication protocol), ponieważ zarówno użytkownik, jak i centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ](KDC) znają hasło użytkownika lub, w przypadku centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ](KDC), hasło zaszyfrowane za pomocą algorytmu jednokierunkowego (one-way encrypted password). Protokół definiuje wymianę komunikatów pomiędzy klientami, centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ](KDC) i serwerami w celu uzyskania biletów protokołu Kerberos (Kerberos tickets). Kiedy użytkownik rozpoczyna logowanie do systemu Windows, usługodawca bezpieczeństwa protokołu Kerberos (Kerberos Security Support Provider — SSP) otrzymuje początkowy bilet protokołu Kerberos lub (Ticket Granting Ticket — TGT), uzyskany na podstawie zaszyfrowanego skrótu (encrypted hash) hasła użytkownika. W systemie Windows 2000 TGT jest przechowywany w pamięci podręcznej biletów (ticket cache) stacji roboczej, związanej z kontekstem logowania użytkownika (logon context).

Kiedy program — [Author ID1: at Tue Jul 31 00:54:00 2001 ]-[Author ID1: at Tue Jul 31 00:54:00 2001 ]klient próbuje uzyskać dostęp do usługi sieciowej, odpowiednia procedura protokołu Kerberos (Kerberos runtime) sprawdza, czy w pamięci podręcznej biletów (ticket cache) znajduje się ważny bilet sesji (session ticket) do serwera. Jeśli bilet nie znajduje się tam, TGT wysyłany jest do centrum dystrybucji kluczy (KDC) jako żądanie biletu sesji (session ticket), który pozwala na uzyskanie dostępu do serwera.

Bilet sesji (session ticket) jest dodawany do pamięci podręcznej biletów (ticket cache) i może być użyty powtórnie dla przyszłych połączeń z tym samym serwerem, dopóki nie straci ważności. Czas ważności biletu (ticket expiration period) jest określony w założeniach bezpieczeństwa domeny (domain security policy) i zazwyczaj wynosi około ośmiu godzin. Jeśli bilet sesji (session ticket) utraci ważność w trakcie sesji, Kerberos SSP zwraca odpowiedni numer błędu, który pozwala klientowi i serwerowi na odnowienie biletu, wygenerowanie nowego klucza sesji (session key) i kontynuowanie połączenia.

Na rysunku 1.5 przedstawiono relację pomiędzy klientem, centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:37:00 2001 ] [Author ID1: at Mon Aug 6 09:37:00 2001 ](KDC) i serwerem aplikacji (application server), która wykorzystuje protokół uwierzytelniania Kerberos.

W przypadku zdalnego dostępu do usługi, bilet sesji (session ticket) protokołu Kerberos jest przedstawiany usłudze zdalnej w trakcie przesyłania komunikatu o połączeniu początkowym (initial connection message). Części biletu sesji (session ticket) są zaszyfrowane za pomocą klucza tajnego (secret key) dzielonego pomiędzy usługę i centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:37:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:37:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ](KDC). Wtedy serwer może dokonać uwierzytelnienia klienta poprzez weryfikację biletu sesji (session ticket) bez odwoływania się do usługi uwierzytelniania, ponieważ procedury protokołu Kerberos (Kerberos runtime) w serwerze mają zapisaną kopię klucza tajnego (secret key) serwera. Inicjalizacja połączenia sesji (session connection setup) jest po stronie serwera o wiele szybsza niż w przypadku autoryzacji za pomocą protokołu NTLM. W protokole NTLM serwer uzyskałby dane uwierzytelniające (credentials) użytkownika, a następnie musiałby ponownie uwierzytelniać użytkownika poprzez centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ](KDC).

Initial Client Authentication to KDC — Początkowe uwierzytelnianie klienta do centrum dystrybucji kluczy (KDC)[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Request Session Ticket from KDC for Target Server — Żądanie biletu sesji z centrum dystrybucji kluczy (KDC) dla serwera docelowego[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Present Session Ticket at Connection Setup — Aktualny bilet sesji podczas usta[Author ID2: at Mon Aug 13 11:45:00 2001 ]nawiania połączenia[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Verifies Session Ticket Issued by KDC — Weryfikacja biletu sesji wydanego przez centrum dystrybucji kluczy (KDC)[Author ID2: at Mon Aug 13 11:45:00 2001 ]

Application Server (Target) — Serwer aplikacji (docelowy)[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Key Distribution Center (KDC) — Centrum dystrybucji kluczy[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Window[Author ID2: at Mon Aug 13 11:45:00 2001 ]s Directory Server — Serwer katalogowy Systemu Windows[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Windows Domain Controller — Kontroler domeny systemu Windows[Author ID2: at Mon Aug 13 11:45:00 2001 ][Author ID1: at Thu Aug 2 11:21:00 2001 ][Author ID2: at Mon Aug 13 11:45:00 2001 ]

[Author ID2: at Mon Aug 13 11:45:00 2001 ]

Rysunek 1.5.[Author ID2: at Mon Aug 13 11:44:00 2001 ] Protokół uwierzytelniania Kerberos[Author ID1: at Thu Aug 2 11:21:00 2001 ]

Bilet sesji (session ticket) protokołu Kerberos zawiera unikatowy klucz sesji (session key) utworzony przez centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ](KDC), aby zastosować go do symetrycznego szyfrowania (symmetric encryption) informacji uwierzytelniających (authentication information) i danych przesyłanych pomiędzy klientem a serwerem. W modelu protokołu Kerberos centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ](KDC) jest niezależną, godną zaufania jednostką, pracującą w trybie online (online trusted third party), która generuje klucz sesji (session key). W ten sposób, w przypadku rozproszonych usług użytkowych (distributed application services), uwierzytelnianie w trybie online za pomocą protokołu Kerberos jest bardzo wydajne.

Integracja protokołu Kerberos z architekturą zabezpieczeń systemu Windows 2000

Protokół Kerberos jest w pełni zintegrowany z architekturą zabezpieczeń systemu Windows 2000 do uwierzytelniania i kontroli dostępu. Usługa logowania systemu Windows (WinLogon) zapewnia wstępne logowanie do domeny systemu Windows za pomocą usługodawcy zabezpieczeń (security provider) protokołu Kerberos, który uzyskuje wstępny bilet (ticket) tego protokołu. Inne składniki systemu operacyjnego, takie jak usługa przeadresowywania (redirector) lub stacja robocza (workstation), wykorzystują interfejs SSPI usługodawcy zabezpieczeń (security provider) protokołu Kerberos, aby otrzymać bilet sesji (session ticket) do połączenia się z serwerem SMB (Server Message Block Server) w celu uzyskania dostępu do plików zdalnych.

Protokół Kerberos 5 definiuje pole zaszyfrowane w biletach sesji (session ticket), które zawiera dane o autoryzacji (authorization data). Pole to jest używane przez aplikacje. System Windows 2000 korzysta z danych o autoryzacji zawartych w biletach (tickets) protokołów Kerberos do przekazywania identyfikatorów zabezpieczeń systemu Windows (Windows Security IDs) przedstawiających użytkowników i członkostwo w grupach. Usługodawca zabezpieczeń (security provider) protokołu Kerberos po stronie serwera wykorzystuje dane o autoryzacji w celu utworzenia bezpiecznego znacznika dostępu (security access token) systemu Windows przedstawiającego użytkownika tego systemu. Serwer pełni rolę modelu zabezpieczeń (security model) systemu Windows personifikowania (impersonating) klienta, stosując znacznik dostępu (access token), przedstawiający klienta przed próbą uzyskania dostępu do zasobów lokalnych chronionych za pomocą list [Author ID1: at Mon Aug 6 09:38:00 2001 ]List [Author ID1: at Mon Aug 6 09:38:00 2001 ]kontroli [Author ID1: at Mon Aug 6 09:38:00 2001 ]Kontroli [Author ID1: at Mon Aug 6 09:38:00 2001 ]dostępu[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ]Dostępu[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ](ACLs). Delegowanie uwierzytelniania (delegation of authentication) jest obsługiwane przez protokół Kerberos 5 za pomocą znaczników (flags): pośrednictwo (proxy) i przesyłanie dalej (forwarding), znajdujących się w biletach sesji (session ticket). W systemie Windows 2000 delegowanie pozwala serwerom na uzyskanie innych biletów sesji (session ticket) do łączenia z serwerami zdalnymi w imieniu klienta.

Współdziałanie różnych implementacji protokołu Kerberos

Protokół Kerberos został zaimplementowany dla różnych systemów i jest stosowany jako jedyna usługa uwierzytelniania w sieciach rozproszonych. Współdziałanie różnych implementacji protokołu Kerberos sprawia, że jeden wspólny protokół pozwala na korzystanie z jednej (być może zreplikowanej) bazy danych kont (account database) do uwierzytelniania użytkowników wszystkich systemów komputerowych przedsiębiorstwa. Współdziałanie różnych implementacji protokołu Kerberos uzyskano dzięki następującym elementom:

• wspólnemu protokołowi uwierzytelniania do identyfikowania w sieci użytkownika lub usługi za pomocą nazwy głównej (principal name),

• zdolności do definiowania relacji zaufania (trust relationships) pomiędzy obszarami (realms) protokołu Kerberos i do generowania żądań odesłania biletu (ticket referral requests) pomiędzy obszarami (realms),

• implementacjom spełniającym wymagania umożliwiające współdziałanie (interoperability requirements), zapisane w dokumencie RFC 1510, które dotyczą szyfrowania, algorytmów obliczania sumy kontrolnej, wzajemnego uwierzytelniania i innych opcji biletów (ticket),

• obsłudze formatów znaczników zabezpieczeń (security token formats) protokołu Kerberos 5 do ustanawiania kontekstu (context establishment) oraz wysyłania i odbierania poszczególnych komunikatów (per message exchange), zgodnie z definicją opracowaną przez grupę roboczą IETF Common Authentication Technology.

Nazwa główna (principal name) w bilecie (ticket) protokołu Kerberos jest stosowana do uwierzytelniania tożsamości użytkownika, ale system lokalny może posłużyć się dodatkowymi informacjami o autoryzacji do kontroli dostępu. Uwierzytelnianie na podstawie tożsamości (identity based authentication) zapewnia wysoki stopień współdziałania (interoperability) systemów, które obsługują protokół Kerberos 5, ale nie obsługują autoryzacji użytkowników. [Author ID1: at Mon Jul 30 23:49:00 2001 ]Protokół Kerberos zapewnia przesyłanie danych o autoryzacji, ale zawartość tego pola jest uważana za specyficzną dla usługi użytkowej (application service).

Implementacja protokołu Kerberos dokonana przez Microsoft spełnia warunki współdziałania (interoperability) wystarczające do uwierzytelniania na podstawie tożsamości (identity based authentication). Ponadto Microsoft łączy dane do autoryzacji (authorization data) w jedną całość z członkami grup (group memberships) systemu Windows 2000 w biletach (tickets) protokołu Kerberos, aby przekazać informacje dotyczące kontroli dostępu (access control information) do usług systemu Windows 2000. Typowe przedstawienie danych autoryzacji (authorization data) znajduje się w identyfikatorze zabezpieczeń (Security IDs) systemu Windows.

Usługi systemu Windows 2000 mają swoje konta usług (service accounts) zdefiniowane w Active Directory, które określają klucz tajny (shared secret key) wykorzystywany przez centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ](KDC) do odszyfrowywania biletów sesji (session tickets). Klienci próbujący połączyć się z usługami systemu Windows 2000 otrzymują bilety sesji (session tickets) do serwera docelowego z centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:38:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:38:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:38:00 2001 ] [Author ID1: at Mon Aug 6 09:38:00 2001 ](KDC) w domenie, w której zdefiniowano konto danej usługi. Usługodawca zabezpieczeń (security provider) protokołu Kerberos obsługujący usługę systemu Windows 2000 liczy, że odnajdzie dane autoryzacji (Authorization Data) w biletach sesji (session tickets) wykorzystywanych do tworzenia bezpiecznego znacznika dostępu (security access token). Usługa systemu Windows 2000 imituje kontekst bezpieczeństwa (security context) klienta na podstawie danych autoryzacji (authorization data) umieszczonych w bilecie sesji (session ticket).

Klienci, którzy otrzymali wstępne bilety TGT z centrów dystrybucji kluczy (KDC) systemów innych niż Windows 2000, stosują mechanizm odsyłania (referral mechanism) protokołu Kerberos, aby żądać biletu sesji (session ticket) z centrum [Author ID1: at Mon Aug 6 09:39:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:39:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:39:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:39:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ](KDC) domeny usługi Windows 2000. Bilet uzyskany za pomocą mechanizmu odsyłania (referral ticket) jest tworzony przez międzyobszarowe relacje zaufania (interrealm trust relationships) pomiędzy centrami dystrybucji kluczy (KDCs). Ponieważ żądania biletu, pochodzące od usługi uwierzytelniania protokołu Kerberos z systemu innego niż Windows 2000, na ogół nie zawierają danych autoryzacji (authorization data), to usługodawca zabezpieczeń (security provider) protokołu Kerberos w systemie Windows 2000 próbuje zastosować nazwę główną (principal name) umieszczoną w bilecie i utworzyć bezpieczny znacznik dostępu (security access token) dla wyznaczonego konta użytkownika lub użyć zdefiniowanego do tego celu konta domyślnego.

Rozszerzenia protokołu Kerberos do uwierzytelniania za pomocą klucza publicznego

W systemie Windows 2000 zaimplementowano również rozszerzenia protokołu Kerberos, aby było możliwe, oprócz uwierzytelniania za pomocą kluczy tajnych (shared secret keys), uwierzytelnianie na podstawie pary kluczy prywatny-publiczny. Takie uwierzytelnianie za pomocą klucza publicznego pozwala klientom wysyłać żądania wstępnego biletu TGT, przy użyciu klucza prywatnego, podczas gdy centrum [Author ID1: at Mon Aug 6 09:39:00 2001 ]Centrum [Author ID1: at Mon Aug 6 09:39:00 2001 ]dystrybucji [Author ID1: at Mon Aug 6 09:39:00 2001 ]Dystrybucji [Author ID1: at Mon Aug 6 09:39:00 2001 ]kluczy[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ]Kluczy[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ](KDC) weryfikuje żądanie, korzystając z klucza publicznego, uzyskanego z certyfikatu X.509, a zapisanego w obiekcie Użytkownik w Active Directory. Certyfikat użytkownika może być wydany przez niezależną jednostkę certyfikującą (third-party CA), taką jak Digital ID VeriSign lub przez Microsoft Certificate Server systemu Windows 2000. Po wstępnym uwierzytelnieniu klucza prywatnego do połączenia się z usługami sieciowymi, w celu uzyskania biletów sesji (session tickets) stosowana jest standardowa wersja protokołu Kerberos.

Wskazówka: Ci, którzy chcą więcej wiedzieć na temat X.509, mogą znaleźć informacje w Internecie. Poszukiwania radziłbym rozpocząć od raportu grupy IETF Public Key Infrastructure X.509 (PKIX), który znajduje się pod adresem www.i. etf..o. rg/html..c. harters/pkix-charter.html.

Rozszerzenia protokołu Kerberos dotyczące uwierzytelniania za pomocą klucza publicznego stanowią podstawy użycia kart elektronicznych (smart card) do uwierzytelniania sieciowego. System Windows 2000 pozwala użytkownikom na logowanie się do stacji roboczych, korzystając z kart elektronicznych (smart card). W przyszłości pojawi się wiele możliwości uzyskiwania certyfikatów dla użytkowników, w zależności od ich przynależności organizacyjnej lub wykonywanych zadań. System Windows 2000 zawiera serwer [Author ID1: at Wed Aug 1 22:08:00 2001 ]Serwer [Author ID1: at Wed Aug 1 22:08:00 2001 ]certyfikatów[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ]Certyfikatów[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ](Certificate Server), przeznaczony dla instytucji, które chcą wydawać swoim użytkownikom certyfikaty z kluczem publicznym bez konieczności korzystania z usług komercyjnych jednostek certyfikujących (commercial CA). Polityka wydawania certyfikatów jest jasna — certyfikaty są wydawane użytkownikom uwierzytelnionym za pomocą ważnych danych uwierzytelniających konta domeny (valid domain account credentials). W następnym rozdziale przedstawiono, w jaki sposób certyfikaty te mogą być wykorzystane do uzyskania dostępu do zasobów Windows 2000 przez intranet lub Internet.

Rozwiązane pokrewne [Author ID1: at Mon Jul 30 23:53:00 2001 ]Zobacz na stronie:

Zastosowanie centrum dystrybucji kluczy

Uwierzytelnianie logowanie

Analiza biletów protokołu Kerberos

Stosowanie Zabezpieczeń z kluczem publicznym w systemie Windows 2000

Zastosowanie certyfikatów z kluczem publicznym do zapewnienia bezpieczeństwa w Internecie

Kryptografia klucz publicznego (public key cryptography) umożliwia bezpieczne komunikowanie się w przedsiębiorstwie i przez Internet. Techniki zabezpieczania komunikowania się przez Internet firmy Microsoft obejmują serwer [Author ID1: at Wed Aug 1 22:09:00 2001 ]Serwer [Author ID1: at Wed Aug 1 22:09:00 2001 ]certyfikatów[Author ID1: at Sun Aug 5 19:38:00 2001 ] [Author ID1: at Sun Aug 5 19:38:00 2001 ]Certyfikatów[Author ID1: at Sun Aug 5 19:38:00 2001 ] [Author ID1: at Sun Aug 5 19:38:00 2001 ](Certificate Server), czyli usługodawcę zabezpieczeń kanału bezpiecznego (secure channel security provider), będącego implementacją protokołów SSL/TLS i Secure Electronic Transaction (SET) oraz zabezpieczające transakcje dokonywane za pomocą kart kredytowych i elementy interfejsu CryptoAPI do zarządzania i administrowania certyfikatami.

Wskazówka: Omówienie protokołu SET można znaleźć pod adresem www..m. astercard..c. om/shoponline/set/. Do bardziej szczegółowych opisów prowadzą łącza (links) na stronę http://trienadecet..m. kn..c. o..u. k/help/system/set/info. Szczegóły na temat interfejsu CryptoAPI można znaleźć pod adresem www.microsoft.com/security/tech/cryptoapi/.

Na rysunku 1.6 przedstawiono elementy infrastruktury klucza publicznego Microsoftu.

Infrastruktura zabezpieczeń internetowych firmy Microsoft jest oparta na standardach zabezpieczeń z kluczem publicznym (public key security), obejmujących algorytm szyfrowania RSA (Rivest Shamir Adleman), format certyfikatów X.509 i standardy kryptografii z kluczem publicznym (Public Key Cryptography Standards — PKCS).

[Author ID2: at Mon Aug 13 11:47:00 2001 ]Applications — Programy użytkowe[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Smartcard interfaces — Interfejsy kart elektronicznych[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Authenticode — Usługa znakowania plików Authenticode[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Network APIs — Sieci[Author ID2: at Mon Aug 13 11:46:00 2001 ]owe interfejsy API[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Message Standards (PKCS) — Standardy komunikatów (PKCS)[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Certificate Management Services — Usługi zarządzania certyfikatami[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Crypto Services — Usługi kryptograficzne[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Secure channel — Kanał bezpieczny[Author ID0: at Thu Nov 30 00:00:00 1899 ]

File I/O — Wejście-Wyjście pliku[Author ID0: at Thu Nov 30 00:00:00 1899 ]

RSA Base CSP — Usługodawca kryptograficzny korzystający z algorytmu RSA[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Hardware CSP — Sprzętowy usługodawca kryptograficzny[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Device driver — Sterownik urządzenia[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Reader — Czytnik[Author ID2: at Mon Aug 13 11:46:00 2001 ][Author ID1: at Wed Aug 1 23:56:00 2001 ][Author ID2: at Mon Aug 13 11:46:00 2001 ]

Rysunek 1.6.[Author ID2: at Mon Aug 13 11:47:00 2001 ] Infrastruktura zabezpieczeń z kluczem publicznym firmy Microsoft

Wskazówka: Szczegółowa analiza algorytmów szyfrowania RSA znajduje się na stronach www..r. sasecurity..c. om/rsalabs/faq/2-1-4..h. tlm oraz www..r. sasecurity..c. om/rsalabs/faq/2-1-5..h. tlm. Informacje na temat PKCS dostępne są pod adresem www..r. sasecurity..c. om/rsalabs/pkcs/. Szczególną uwagę należy zwrócić na PKCS #7 i PKCS #10. Strona laboratoriów RSA Security (www..r. sasecurity..c. om) powinna stać się ulubioną przez każdego specjalistę od bezpieczeństwa.

W systemie Windows NT 4 znalazły się pierwsze elementy pozwalające na korzystanie z zabezpieczeń za pomocą klucza publicznego (public key security), w skład których wchodzą:

• interfejs CryptoAPI, wspomagający programistę w zakresie generowania i wymiany kluczy, podpisów elektronicznych oraz szyfrowania danych, za pomocą architektury usługodawcy (provider) do obsługi instalowalnych usługodawców kryptograficznych (Cryptographic Service Providers),

• obsługa certyfikatów X.509 i standardów PKCS przez interfejs CryptoAPI,

• kanał bezpieczny (secure channel), który jest implementacją SSL2 lub SSL3 z obsługą części klienta (client side support) oraz techniki PCT 1 (Private Communications Technology) protokołów zabezpieczeń z kluczem publicznym (public key security protocols),

• usługa znakowania plików Authenticode, stosująca podpisy elektroniczne do weryfikowania spójności oprogramowania pobranych poprzez Internet i identyfikowania tego, kto udostępnił oprogramowanie.

Infrastruktura zabezpieczeń internetowych firmy Microsoft utworzona na bazie wymienionych powyżej elementów zawiera także dodatkowe funkcje obsługujące zabezpieczenia z kluczem publicznym (public key security) dla systemów Windows, z systemem Windows 2000 włącznie. Internet Explorer oraz IIS korzystają z wielu elementów zabezpieczeń internetowych. Nowe elementy infrastruktury zabezpieczeń internetowych Microsoftu dotyczące rozproszonych usług zabezpieczeń (Distributed Security Services) systemu Windows 2000 obejmują:

• uwierzytelnianie klienta (client authentication) za pomocą SSL3, opartego na certyfikatach z kluczem publicznym (public key certificates),

• serwer [Author ID1: at Wed Aug 1 22:09:00 2001 ]Serwer [Author ID1: at Wed Aug 1 22:09:00 2001 ]certyfikatów[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ]Certyfikatów[Author ID1: at Mon Aug 6 09:39:00 2001 ] [Author ID1: at Mon Aug 6 09:39:00 2001 ](Certificate Server), wydający certyfikaty dla kont domen w systemie Windows 2000.

Zabezpieczenia systemu Windows 2000 wykorzystują internetowe standardy zabezpieczeń z kluczem publicznym (public key security) z elementami wbudowanymi w system operacyjny.

Uwierzytelnianie klientów za pomocą protokołu SSL3

Secure Socket Layer i Transport Layer Security są protokołami zabezpieczeń, w których zastosowano klucz publiczny, wykorzystywanymi przez usługodawcę zabezpieczeń (security provider) i kanał bezpieczny (secure channel). Przeglądarki i serwery internetowe korzystają z wyżej wymienionych protokołów zabezpieczeń do wzajemnego uwierzytelniania, zapewnienia spójności komunikatów (message integrity) oraz poufności (confidentiality). Internet Explorer (klient) dokonuje uwierzytelnienia serwera internetowego, wówczas gdy certyfikat serwera jest przedstawiony jako część procedury ustanawiania kanału bezpiecznego SSL/TLS. Program — [Author ID1: at Mon Jul 30 23:59:00 2001 ]-[Author ID1: at Mon Jul 30 23:59:00 2001 ]klient przyjmuje certyfikat serwera, weryfikując podpisy kryptograficzne (cryptographic signatures) umieszczone w certyfikacie i w każdym z certyfikatów wydanych przez pośrednie jednostki certyfikujące (intermediate CA) jednej ze znanych lub skonfigurowanych głównych jednostek certyfikujących (root CAs).

Protokoły SSL3 i TLS również obsługują uwierzytelnianie klienta (client authentication). Uwierzytelnianie klienta za pomocą certyfikatów z kluczem publicznym jest częścią ustanawiania sesji z kanałem bezpiecznym (secure channel session establishment).

Na rysunku 1.7 przedstawiono przesyłanie komunikatów potwierdzenia transmisji (handshake messages) pomiędzy klientem i serwerem w celu ustanowienia połączenia bezpiecznego (secure connection establishment).

Uwierzytelnianie klienta przez serwer jest tym samym procesem, co uwierzytelnianie serwera (server authentication). Serwer weryfikuje podpisy kryptograficzne (cryptographic signatures) umieszczone w certyfikacie klienta i w każdym z pośrednich certyfikatów wydanych przez jednostki certyfikujące (CA) u znanej lub znajdującej się z danym serwerem w relacji zaufania głównej jednostki certyfikującej (root CA). Jednakże, skoro tożsamość klienta została potwierdzona poprzez zweryfikowanie certyfikatu (uwierzytelnienie klienta), serwer aplikacji (application server) żąda ustanowienia kontekstu bezpieczeństwa (security context) ze zdefiniowanymi dla tego klienta odpowiednimi prawami dostępu. Informacje dotyczące kontroli dostępu określają, które z zasobów danego serwera są dostępne dla danego klienta. W architekturze zabezpieczeń (security architecture) systemu Windows 2000 członkostwo grupy oraz uprawnienia podane w znaczniku dostępu bezpiecznego (security access token) określają zakres kontroli dostępu (access control).

[Author ID2: at Mon Aug 13 11:51:00 2001 ]Applicatio[Author ID2: at Mon Aug 13 11:51:00 2001 ]n Data — Dane aplikacji[Author ID2: at Mon Aug 13 11:51:00 2001 ]

*Oznacza komunikaty opcjonalne lub zależne od sytuacji, które nie są wysyłane za każdym razem.[Author ID2: at Mon Aug 13 11:51:00 2001 ][Author ID1: at Wed Aug 1 23:56:00 2001 ][Author ID2: at Mon Aug 13 11:51:00 2001 ]

[Author ID2: at Mon Aug 13 11:51:00 2001 ]

[Author ID2: at Mon Aug 13 11:51:00 2001 ]

Rysunek 1.7.[Author ID2: at Mon Aug 13 11:49:00 2001 ] Potwierdzanie transmisji (handshake) w protokole Secure Socket Layer 3

W trakcie uwierzytelniania klienta z użyciem klucza publicznego (public key client authentication) zachodzi odwzorowanie informacji zawartych w certyfikacie klienta na dane dotyczące lokalnej kontroli dostępu (local access control information). Dane te precyzują, jakie upoważnienie posiada klient, aby mieć dostęp do zasobów serwera. Wstępna obsługa uwierzytelniania klienta przez Microsoft IIS jest osiągalna poprzez zarządzanie bazą danych autoryzacji (authorization database), aby przyporządkować dane podmiotu certyfikowanego (certificate subject) lub emitenta certyfikatu do istniejących kont systemu Windows 2000. Baza danych autoryzacji (authorization database) może być prosta lub skomplikowana, w zależności od wymagań aplikacji.

System Windows 2000 obsługuje uwierzytelnianie klienta (client authentication) za pomocą usługi zabezpieczeń (security service), korzystającej z Active Directory lub IIS podczas przyporządkowywania informacji zawartych w certyfikacie do istniejących kont systemu Windows. Przyporządkowywania dokonuje się za pomocą szukania nazwy podmiotu certyfikowanego (certificate subject name) w katalogu systemu Windows albo szukając właściwości katalogu, które pozwalają na zidentyfikowania certyfikatu klienta.

Obsługa uwierzytelniania klienta w systemie Windows 2000 łączy certyfikaty mające klucz publiczny (public key certificates) z architekturą zabezpieczeń (security architecture) systemu Windows 2000. Do definiowania praw dostępu związanych z certyfikatami z kluczem publicznym (public key certificates) nie jest potrzebna oddzielna baza danych. Informacje dotyczące kontroli dostępu są obsługiwane (maintained) przez członków grup (group membership) zapisanych w katalogu systemu Windows. Ogólnodostępne narzędzia administracyjne usług katalogowych (Directory Service) są wykorzystywane do przyznawania praw dostępu poprzez dodawanie użytkowników do grup. [Author ID2: at Mon Aug 13 11:54:00 2001 ]

Uwierzytelnianie klientów zewnętrznych

Obsługa uwierzytelniania za pomocą certyfikatów z kluczem publicznym (public key certificate authentication) w systemie Windows 2000 pozwala aplikacjom — [Author ID1: at Tue Jul 31 00:01:00 2001 ]-[Author ID1: at Tue Jul 31 00:01:00 2001 ]klientom (client applications) na łączenie się z usługami bezpiecznymi (secure services) w imieniu użytkowników, którzy nie mają konta w domenie Windows 2000. Użytkownicy, którzy zostali uwierzytelnieni na podstawie certyfikatu z kluczem publicznym (public key certificate), wydanego przez zaufaną jednostkę certyfikującą (trusted CA), mogą mieć przyznane prawo dostępu do zasobów systemu Windows 2000. Narzędzia administracyjne Directory Service pozwalają administratorowi lub jednostce upoważnionej podłączyć co najmniej jednego użytkownika zewnętrznego do istniejącego konta systemu Windows 2000, aby kontrolować dostęp. Pole certyfikatu X.50 v. 3 Nazwa podmiotu (subject [Author ID1: at Tue Jul 31 00:02:00 2001 ]Subject [Author ID1: at Tue Jul 31 00:02:00 2001 ]name) służy do identyfikowania użytkownika zewnętrznego związanego z danym kontem.

Przedsiębiorstwa mogą bezpiecznie dzielić informacje z wybranymi osobami z innych organizacji bez konieczności tworzenia osobnego konta w systemie Windows 2000 dla każdej z osób. Przyporządkowanie nieróżnowartościowe (many-to-one) certyfikatów do obiektów — [Author ID1: at Tue Jul 31 00:03:00 2001 ]-[Author ID1: at Tue Jul 31 00:03:00 2001 ]użytkowników systemu Windows 2000 zapewnia uwierzytelnianie na podstawie certyfikatów z kluczem publicznym i wspólnych uprawnień do kontroli dostępu (common access control permissions). Uwierzytelnianie klientów zewnętrznych nadal wymaga od administratora systemu skonfigurowania jednostki certyfikującej (CA), wydającej certyfikaty użytkownikom zewnętrznym jako godnej zaufania (trusted CA). Zapobiega to uwierzytelnieniu osoby posiadającej certyfikat wydany przez nieznaną jednostkę certyfikującą. W rozdziale 6. znajduje się dokładny opis wprowadzania zabezpieczeń korzystających z klucza publicznego.

Sewer certyfikatów firmy Microsoft

Serwer certyfikatów [Author ID1: at Sun Aug 5 19:39:00 2001 ]Certyfikatów [Author ID1: at Sun Aug 5 19:39:00 2001 ]Microsoftu (Certificate Server) świadczy usługi wydawania i zarządzania certyfikatami dla aplikacji stosujących kryptografię klucza publicznego (public key cryptography). Usługi serwera [Author ID1: at Mon Aug 6 09:40:00 2001 ]Serwera [Author ID1: at Mon Aug 6 09:40:00 2001 ]certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ]Certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ](Certificate Server) można adaptować dla potrzeb różnych organizacji.

Serwer certyfikatów[Author ID1: at Sun Aug 5 19:39:00 2001 ] [Author ID1: at Sun Aug 5 19:39:00 2001 ]C[Author ID1: at Mon Aug 6 09:40:00 2001 ]ertyfikatów[Author ID1: at Sun Aug 5 19:39:00 2001 ] [Author ID1: at Sun Aug 5 19:39:00 2001 ](Certificate Server) odbiera żądania nowych certyfikatów poprzez mechanizmy transportowe (transports), takie jak zdalne wywołania procedur (RPC), HTTP czy poczta elektroniczna. Każde żądanie jest sprawdzane, czy zgadza się z założeniami niestandardowymi (custom policies) lub założeniami właściwymi dla danej lokacji (site-specific policies). Następnie serwer [Author ID1: at Wed Aug 1 22:11:00 2001 ]S[Author ID1: at Mon Aug 6 09:40:00 2001 ]erwer [Author ID1: at Wed Aug 1 22:11:00 2001 ]certyfikatów[Author ID1: at Sun Aug 5 19:39:00 2001 ] [Author ID1: at Sun Aug 5 19:39:00 2001 ]C[Author ID1: at Mon Aug 6 09:40:00 2001 ]ertyfikatów[Author ID1: at Sun Aug 5 19:39:00 2001 ] [Author ID1: at Sun Aug 5 19:39:00 2001 ]ustawia przed wydaniem certyfikatu jego opcjonalne właściwości, po czym go wydaje. Ponadto pozwala administratorom na dodawanie elementów do listy unieważniania certyfikatów (Certificate Revocation List — CRL) i regularne publikowanie listy CRL. Interfejsy programowalne (programmable interfaces), które zawiera serwer [Author ID1: at Wed Aug 1 22:11:00 2001 ]S[Author ID1: at Mon Aug 6 09:40:00 2001 ]erwer [Author ID1: at Wed Aug 1 22:11:00 2001 ]certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ]Certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ]są używane przez programistów do tworzenia programów obsługi dodatkowych transportów (transports), założeń (policies), właściwości certyfikatu i formatów.

Moduł założeń serwera [Author ID1: at Sun Aug 5 19:39:00 2001 ]S[Author ID1: at Mon Aug 6 09:40:00 2001 ]erwera [Author ID1: at Sun Aug 5 19:39:00 2001 ]certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ]Certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ](Certificate Server) stosuje uwierzytelnianie sieciowe (network authentication) żądań certyfikatów do ich wydawania użytkownikom, którzy mają konta w domenie Windows 2000 może być dostosowany do potrzeb organizacji wydającej certyfikat. Serwer [Author ID1: at Sun Aug 5 19:40:00 2001 ]S[Author ID1: at Mon Aug 6 09:40:00 2001 ]erwer [Author ID1: at Sun Aug 5 19:40:00 2001 ]certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ]Certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ](Certificate Server) tworzy certyfikat w standardowym formacie X.509. Certyfikaty w tym formacie są powszechnie używane do uwierzytelniania serwerów i klientów związanych z łącznością bezpieczną (secure communications) za pomocą protokołu TLS albo SSL.

W intranecie lub Internecie serwery [Author ID1: at Tue Jul 31 00:05:00 2001 ]typu Microsoft IIS mogą dokonać uwierzytelniania klientów dla łączności bezpiecznej (secure communications) za pomocą certyfikatów wydanych przez serwer [Author ID1: at Tue Jul 31 00:05:00 2001 ]S[Author ID1: at Mon Aug 6 09:40:00 2001 ]erwer [Author ID1: at Tue Jul 31 00:05:00 2001 ]certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ]Certyfikatów[Author ID1: at Mon Aug 6 09:40:00 2001 ] [Author ID1: at Mon Aug 6 09:40:00 2001 ](Certificate Server). Serwer ten może również wytworzyć certyfikaty serwera (server certificates) wykorzystywane przez IIS i inne serwery Sieci (Web servers), aby dokonać uwierzytelnienia serwera i upewnić klientów (przeglądarki), że komunikują się z jednostką, z którą miały zamiar połączyć się. Rozdział 7. zawiera dokładny opis zarządzania usługą certyfikowania (Certificate Service), zarządzania certyfikatami i przygotowania żądań certyfikatów.

Interfejs CryptoAPI

W systemie Windows NT 4 wprowadzono do interfejsu CryptoAPI systemową obsługę kryptografii (low-level cryptography support) i modułowych usługodawców usług kryptograficznych (modular Cryptographic Service Providers). System Windows 2000 korzysta z wprowadzenia do interfejsu CryptoAPI zarządzania certyfikatami (CryptoAPI Certificate Management) w celu obsługi zabezpieczeń wykorzystujących klucz publiczny (public key security).

Wśród nowych cech interfejsu CryptoAPI są m.in.:

• obsługa certyfikatów w standardzie X.509 v.3 oraz list unieważniania certyfikatów (CRLs) w standardzie X.509 v.2 poprzez wspólne funkcje kodowania — [Author ID1: at Tue Jul 31 00:07:00 2001 ]-[Author ID1: at Tue Jul 31 00:07:00 2001 ]dekodowania, analizę syntaktyczną (parsing) certyfikatów oraz weryfikację,

• obsługa żądań certyfikatów PKCS #10 i PKCS #7 dla danych podpisanych (signed data) i danych opakowanych (enveloped data),

• zdolność do dodawania i odzyskiwania certyfikatów oraz list unieważniania certyfikatów (CRLs) ze składów certyfikatów (certificate stores), lokalizacji certyfikatów według atrybutów i przydzielania kluczy prywatnych,

• obsługa weryfikowania podpisu cyfrowego (digital signature) i szyfrowania danych za pomocą funkcji wyższego poziomu dostępnych dla aplikacji użytkowych napisanych w HTML-u, Javie, Visual Basic-u (Scripting Edition — VBScript) i C/C++.

Właściwości interfejsu CryptoAPI wykorzystywane są przez składniki systemu Windows 2000, np.Software Publisher Trust Provider w celu weryfikacji za pomocą Authenticode. Inne programy użytkowe i usługi systemowe korzystają z CryptoAPI , [Author ID0: at Thu Nov 30 00:00:00 1899 ]2, aby zapewnić powszechnie dostępny zestaw funkcji, umożliwiający stosowanie techniki zabezpieczeń z zastosowaniem klucza publicznego.

Implementowanie dostępu między przedsiębiorstwami

Wiele przedsiębiorstw kontaktuje się z kupującymi i współpracownikami poprzez Internet. Dealerzy, dostawcy, dystrybutorzy i każdy, kto jest związany z przedsiębiorstwem może połączyć się do intranetu danego przedsiębiorstwa i mieć dostęp do ważnych informacji firmowych. Pracownicy w większym stopniu wykorzystują dostęp lokalny do sieci publicznych, aby połączyć się ze zdalnymi źródłami informacji o przedsiębiorstwie. Bezpieczeństwo systemu Windows 2000 zostało zaprojektowane w ten sposób, by nadążać za zmieniającymi się potrzebami przetwarzania rozproszonego poprzez Internet. Rozproszenie przetwarzania danych pomiędzy przedsiębiorstwa (interbusiness distributed computing) nie jest ograniczone do jednej architektury systemu i technologia zabezpieczeń (security technology) nie powinna ograniczać firm do stosowania tylko jednej z metod dostępu do danych. Ponieważ technologie zabezpieczania zmieniają się szybko, pojawia się wiele takich metod. W systemie Windows 2000 połączono obsługę protokołów zabezpieczeń (security protocols) i modele użytkowników odpowiadające potrzebom oprogramowania użytkowego lub potrzebom przedsiębiorstwa. Co ważniejsze system Windows 2000 umożliwia zmianę obecnych zabezpieczeń przedsiębiorstwa i daje możliwości pełnego wykorzystania internetowych zabezpieczeń z kluczem publicznym, gdy infrastruktura umocni się.

Jednym ze sposobów współpracy pomiędzy przedsiębiorstwami (interbusiness access) jest stworzenie kont użytkowników, które pozwolą wspólnikom (business partners) na dostęp do korporacyjnych usług informatycznych (corporate information services). Połączenie zabezpieczeń w systemie Windows 2000 z Active Directory upraszcza zarządzanie tymi specjalnymi kontami. Jednostki organizacyjne (OUs) katalogu mogą służyć do pogrupowania pokrewnych kont według wspólników, dostawców lub innych relacji biznesowych, a administrowanie tymi kontami może być przekazane osobom z organizacji zarządzającej kooperacją między wspólnikami. Wykorzystując wirtualne [Author ID1: at Wed Aug 1 22:13:00 2001 ]Wirtualne [Author ID1: at Wed Aug 1 22:13:00 2001 ]siei [Author ID1: at Mon Aug 6 09:40:00 2001 ]Siei [Author ID1: at Mon Aug 6 09:40:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ]Pry[Author ID1: at Mon Aug 6 09:41:00 2001 ]watne[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ](Virtual Private Networks) do szyfrowania ruchu w sieciach publicznych, wspólnicy (business partners) mogą skorzystać z usług zdalnego dostępu (remote access services), aby dotrzeć do informacji korporacyjnych (corporate information) w taki sam sposób, jak wszyscy pracownicy zdalni (remote employee). Dostęp do baz danych lub składnic informacji (information repositories) może być kontrolowany za pomocą narzędzi kontroli dostępu systemu Windows 2000.

Kolejnym narzędziem służącym do ustanowienia wzajemnych relacji pomiędzy przedsiębiorstwami (cross-business relationships) są relacje zaufania domeny (domain trust relationships). Active Directory zapewnia elastyczność zarządzania drzewem domen hierarchicznych (tree of hierarchical domains). Za pomocą zintegrowania konwencji nazewniczej domen w systemie Windows 2000 z konwencją nazewniczą DNS wyznaczanie tras w sieci złożonej (Internet routing) pomiędzy dwoma domenami jest łatwe do skonfigurowania. W ten sposób relacje zaufania domen (domain trusts) mogą być wykorzystane do skonfigurowania aplikacji klient [Author ID3: at Mon Jul 16 12:59:00 2001 ]-[Author ID3: at Mon Jul 16 12:59:00 2001 ]- [Author ID3: at Mon Jul 16 12:59:00 2001 ]serwer, tak aby zapewnić poufność i integralność. Cechy te są konieczne do komunikowania się poprzez Internet. Aby uzyskać dostęp do zasobów udostępnionych (shared resources) w domenach zdalnych (remote domains), użytkownik może stosować uwierzytelnianie za pomocą protokołu Kerberos lub protokołów uwierzytelniania z kluczem publicznym.

Organizacje mogą wykorzystać infrastrukturę zabezpieczeń internetowych Microsoftu (Microsoft Internet security infrastructure) do rozwiązywania problemów bezpieczeństwa w Internecie, wydając certyfikaty z kluczem publicznym (public key certificates) tym partnerom, którym potrzebny jest dostęp do określonych zasobów informatycznych (information resources). Certyfikaty mogą być wykorzystywane do identyfikowania i uwierzytelniania użytkowników. Certyfikaty z kluczem publicznym (public key certificates) oraz infrastruktura niezbędna do wydawania certyfikatów i weryfikowania unieważniania certyfikatów (certificate revocation) stanowią skuteczną metodę obsługi kontaktów pomiędzy przedsiębiorstwami (business-to-business relationships) poprzez Internet. System Windows 2000 obsługuje certyfikaty w standardzie X.509 v.3 wydane przez dowolny system certyfikowania. Administratorzy systemu Windows 2000 określają, które jednostki certyfikujące (CA) są godne zaufania (trusted) oraz mogą przydzielać użytkownikom zewnętrznym, uwierzytelnionym za pomocą certyfikatów z kluczem publicznym (public key certificates), konta użytkownika systemu Windows 2000, by w ten sposób ustanowić dla nich prawa dostępu.

Rozwiązania na skalę całego przedsiębiorstwa

System Windows 2000 zarządza danymi uwierzytelniającymi użytkownika dotyczącymi bezpieczeństwa sieciowego (network security credentials) w sposób niezauważalny dla użytkownika po każdym zalogowaniu się do sieci. Użytkownik nie musi interesować się, czy połączenie z serwerem sieciowym (network server) korzysta z protokołu NTLM, Kerberos lub z protokołów zabezpieczeń opartych na kluczu publicznym. Zalogowany do systemu ma dostęp do wielu usług sieciowych.

Wewnątrz przedsiębiorstwa dostęp do zasobów jest określany za pomocą praw przyznanych kontom użytkowników lub członkostwa w grupie. W przypadku połączeń poprzez Internet użytkownik uzyskuje dostęp na podstawie identyfikacji potwierdzonej za pomocą podpisu cyfrowego z kluczem prywatnym (private key signature) i odpowiadającego mu certyfikatu z kluczem publicznym (public key certificate). Wszystkie protokoły zabezpieczeń polegają na pewnych formach danych uwierzytelniających użytkownika (user credentials), a przedstawianych serwerowi po ustanowieniu połączenia. System Windows 2000 zarządza tymi danymi uwierzytelniającymi (user credentials) i automatycznie wykorzystuje ich zestaw, odpowiedni dla stosowanego protokołu zabezpieczeń (security protocol).

Active Desktop w systemie Windows 2000 obsługuje wiele danych uwierzytelniających dotyczących bezpieczeństwa (security credentials), jako część zabezpieczona danych konta użytkownika. Dane te (credentials) służą usługom uwierzytelniania w przedsiębiorstwie (enterprise authentication services), które do uwierzytelniania użytkownika w trybie online wykorzystują kontroler domeny. Zaawansowane serwery aplikacji mogą obsługiwać uwierzytelnianie zinter[Author ID1: at Tue Jul 31 00:13:00 2001 ]growane z systemem Windows 2000, wykorzystując do uwierzytelniania sieciowego [Author ID1: at Mon Aug 6 09:41:00 2001 ]Sieciowego [Author ID1: at Mon Aug 6 09:41:00 2001 ]interfejs [Author ID1: at Mon Aug 6 09:41:00 2001 ]Interfejs [Author ID1: at Mon Aug 6 09:41:00 2001 ]usługodawcy [Author ID1: at Mon Aug 6 09:41:00 2001 ]Usługodawcy [Author ID1: at Mon Aug 6 09:41:00 2001 ]zabezpieczeń[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ]Zabezpieczeń[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ](Security Service Provider Interface).

Zastosowanie danych uwierzytelniających protokołu NTLM

Klienci w systemie Windows 2000 wykorzystują protokół uwierzytelniania (authentication protocol) NTLM do łączenia się z serwerami, w których pracują wcześniejsze wersje systemu Windows NT. Uwierzytelnianie za pomocą protokołu NTLM stosuje się, np. do połączenia z udostępnionymi na serwerze Windows NT plikami zdalnymi (remote file share) lub do połączenia klienta Windows NT 4 z plikami udostępnionymi w systemie Windows 2000. Dane uwierzytelniające protokołu NTLM (NTLM credentials) zawierają nazwę domeny, nazwę użytkownika oraz zaszyfrowane hasło, wprowadzone w trakcie pierwszego logowania.

Usługi zabezpieczeń (security services) kontrolera domeny (DC) posługują się bezpieczną kopią danych uwierzytelniających użytkownika protokołu NTLM w Active Directory, aby użyć ich do uwierzytelnienia za pomocą protokołu zabezpieczeń NTLM. Klienci systemu Windows 2000 wykorzystują dane uwierzytelniające (credentials) protokołu NTLM wprowadzone w trakcie logowanie się po stronie klienta, podczas łączenia się klienta z serwerem Windows NT, stosując uwierzytelnianie za pomocą protokołu zabezpieczeń NTLM. Dla zachowania zgodności, obsługa danych uwierzytelniających protokołu NTLM przez zabezpieczenia systemu Windows 2000 jest taka sama, jak w przypadku systemu Windows NT 4.

Zastosowanie danych uwierzytelniających w przypadku stosowania protokołu Kerberos

Uwierzytelnianie za pomocą protokołu zabezpieczeń Kerberos jest głównym sposobem uwierzytelniania dla domen systemu Windows 2000. Dane uwierzytelniające protokołu Kerberos składają się z nazwy domeny, nazwy użytkownika (nazwy te mogą być podane w formie stosowanej w Internecie, np. [e-mail]) i hasła zaszyfrowanego w sposób właściwy dla protokołu Kerberos (Kerberos — style encrypted password). Podczas logowania użytkownika do systemu, Windows 2000 otrzymuje przynajmniej jeden bilet (ticket) protokołu Kerberos, aby połączyć się z usługami sieciowymi. Bilety (tickets) protokołu zabezpieczeń Kerberos przedstawiają sieciowe dane uwierzytelniające (network credentials) przy uwierzytelnianiu na podstawie tego protokołu.

System Windows 2000 automatycznie zarządza pamięcią podręczną biletów protokołu Kerberos (Kerberos ticket cache) dla połączeń ze wszystkimi usługami sieciowymi. Bilety (tickets) mają swoje okresy ważności (expiration time) i od czasu do czasu muszą być uaktualniane. Usługodawca zabezpieczeń Kerberos i związane z nim usługi użytkowe (application services) załatwiają sprawę unieważniania i wznawiania biletów. Większość usług, takich jak usługa przeadresowywania (redirector) w systemie plików, automatycznie aktualizuje bilety sesji (session tickets). Regularne wznawianie biletów (ticket renewal) stanowi dodatkowe zabezpieczenie sesji dzięki okresowej zmianie klucza sesji.

Zastosowanie par kluczy prywatny-publiczny i certyfikatów z parą kluczy prywatny-publiczny

Internetowe dane uwierzytelniające w postaci par kluczy prywatny-publiczny i certyfikatów z parą kluczy prywatny-publiczny są zarządzane przez użytkownika. Active Directory służy do publikowania użytkownikom certyfikatów z kluczem publicznym. Natomiast do ich znajdowania używa się standardowych protokołów dostępu do katalogu (standard directory access protocols). Klucze prywatne (private keys) i certyfikaty wydane użytkownikom (end users) przechowywane są w miejscach bezpiecznych, w systemie lokalnym lub na karcie elektronicznej (smart card). Miejsca te są znane jako magazyny chronione (Protected Store), a ich ochronę zapewniają internetowe technologie zabezpieczeń.

Implementację magazynu chronionego (Protected Store) oparto na architekturze interfejsu CryptoAPI dla systemu Windows NT. Interfejs CryptoAPI zawiera funkcje do zarządzania kluczami i pozostałe, z zakresu kryptografii do tworzenia magazynów chronionych za pomocą certyfikatów znajdujących się w magazynie certyfikatów (Certificate Store). Protokoły zabezpieczeń, oparte na kluczu publicznym (public key-based security protocols) w wersji zaimplementowanej w systemie Windows 2000, wykorzystują klucze i certyfikaty dostępne w magazynie chronionym (Protected Store) i magazynie certyfikatów (Certificate Store), jako dane uwierzytelniające użytkownika dla uzyskania dostępu do serwerów internetowych. W wielu przypadkach określone przez użytkownika właściwości certyfikatów znajdujących się w magazynie certyfikatów (Certificate Store) pozwalają protokołom zabezpieczeń na automatyczne dokonanie wyboru oraz użycie poprawnego certyfikatu i klucza podpisu cyfrowego (signature key). Postępy w zakresie internetowych protokołów zabezpieczeń, np. SSL3/TLS pozwalają serwerowi na żądanie od klienta określonych danych uwierzytelniających (credentials), które są automatycznie pobierane z magazynu certyfikatów (Certificate Store), o ile są dostępne.

Informacje z magazynu chronionego (Protected Store) i magazynu certyfikatów (Certificate Store) są dostępne dla użytkowników mobilnych (roaming users), ponieważ są oni zabezpieczeni jako część profilu użytkownika. Kiedy użytkownik po raz pierwszy loguje się do komputera — [Author ID1: at Tue Jul 31 00:16:00 2001 ]-[Author ID1: at Tue Jul 31 00:16:00 2001 ]klienta systemu Windows, dane z jego profilu są kopiowane do tego komputera. Jeśli użytkownik otrzyma w trakcie tej sesji nowe klucze i certyfikaty, to przy wylogowywaniu się następuje aktualizacja profilu użytkownika w serwerze centralnym.

Zmiana protokołu uwierzytelniania NTLM na protokół Kerberos

Przejście z uwierzytelniania za pomocą protokołu NTLM, wykorzystywanego w systemie Windows NT 4 i poprzednich wersjach Windows NT, na uwierzytelnianie domen za pomocą protokołu Kerberos (Kerberos Domain Authentication) jest bardzo płynne. System Windows 2000 obsługuje połączenia klienta lub serwera, wykorzystując dowolny z tych protokołów. Negocjacje dotyczące bezpieczeństwa, prowadzone przez warstwę (layer) SSPI albo protokół aplikacji (application protocol), stanowią jeszcze jeden sposób wyboru najodpowiedniejszego protokołu zabezpieczeń. Przejście od usług w przedsiębiorstwie (enterprise-based services), wykorzystujących uwierzytelnianie za pomocą protokołu Kerberos, na usługi internetowe (Internet-based services), wykorzystujące uwierzytelnianie za pomocą klucza publicznego jest całkowicie niezauważalne dla użytkownika. Obsługiwanie przez system Windows 2000 wielu danych uwierzytelniających użytkownika (user credentials) pozwala na stosowanie techniki uwierzytelniania za pomocą klucza tajnego (secret key) dla usług użytkowych przedsiębiorstwa (enterprise application services) oraz techniki zabezpieczeń za pomocą klucza publicznego przy łączeniu się z serwerami internetowymi (Internet-based servers). Większość protokołów użytkowych (application protocol), takich jak LDAP, HTTP/HTTPS czy RPC daje możliwości uwierzytelniania i jest zaprojektowana również po to, by obsługiwać wiele usług uwierzytelniania oraz dokonać wyboru pomiędzy tymi usługami podczas ustanawiania połączenia (connection establishment).

Zamiast polegać na jednej technologii uwierzytelniania i jednym protokole uwierzytelniania, system Windows 2000, stosuje wiele protokołów w zależności od wymagań stawianych przez programy użytkowe i użytkowników co do bezpiecznego przetwarzania danych w sieci.

Zastosowanie protokołu IPSec (Internet Protocol Security)

Aby zapewnić bezpieczeństwo transmisji za pomocą protokołu TCP/IP po obu stronach „zapory ogniowej” (firewall) danego przedsiębiorstwa, protokół IPSec (Microsoft Windows IP Security) wykorzystuje standardowe algorytmy szyfrowania i wszechstronne podejście do zarządzania bezpieczeństwem. Ponieważ protokół IPSec jest zainstalowany poniżej warstwy transportowej, zaoszczędzono w ten sposób menedżerom sieci (network managers) i dostawcom oprogramowania (software vendors) kłopotów i nakładów poniesionych na próby zainstalowania i koordynowania zabezpieczeń dla każdego programu użytkowego pojedynczo. Instalując system Windows 2000 Server, menedżerowie sieci zapewniają wysoki stopień ochrony w całej sieci za pomocą programów użytkowych, automatycznie dziedzicząc zabezpieczenia systemu Windows 2000 Server. Obsługa szyfrowania przez protokół Windows IP Security obejmuje również wirtualne [Author ID1: at Mon Aug 6 09:41:00 2001 ]Wirtualne [Author ID1: at Mon Aug 6 09:41:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ](Virtual Private Networks [Author ID1: at Tue Jul 31 00:55:00 2001 ]— [Author ID1: at Tue Jul 31 00:55:00 2001 ]VPN).

Integracja protokołu IPSec z systemem Windows 2000 Server daje administratorom i menedżerom sieci następujące korzyści:

• protokół IPSec jest otwartym standardowym rozwiązaniem alternatywnym do własnych technik szyfrowania protokołu IP;

• protokół IPSec znajduje się poniżej warstwy transportowej, co czyni go przezroczystym dla aplikacji i użytkowników i oznacza, że nie ma potrzeby zmiany aplikacji sieciowych w komputerze użytkownika (user's desktop), kiedy protokół IPSec jest zaimplementowany w „zaporze ogniowej” (firewall) lub ruterze;

• solidne usługi uwierzytelniania zapobiegają przechwyceniu danych przez osoby postronne;

• usługi poufności zapobiegają nieuwierzytelnionemu dostępowi do najważniejszych danych przesyłanych pomiędzy komunikującymi się stronami;

• nagłówki uwierzytelniające protokołu IP (IP authentication headers) i zmienność skrótu (hash message authentication code) gwarantują integralność danych podczas transmisji;

• dynamiczna zmiana klucza (dynamic rekeying) w trakcie komunikacji pomaga zabezpieczyć się przed atakami;

• protokół IP Security zabezpiecza połączenie pomiędzy użytkownikami sieci prywatnych (private network users) w danej domenie lub pomiędzy dowolnymi domenami w przedsiębiorstwie, pozostającymi w relacjach zaufania;

• aby zapewnić właściwy poziom bezpieczeństwa, administratorzy sieci wykorzystują założenia bezpieczeństwa (security policies) i filtry, biorąc po uwagę użytkowników, grupy robocze lub inne kryteria. Zarządzanie scentralizowane ogranicza koszty ogólne administrowania;

• elastyczność protokołu IP Security pozwala na stosowanie założeń (policies) w skali całego przedsiębiorstwa lub do pojedynczej stacji roboczej.

Są to dobre wiadomości dla menedżerów sieci i innych specjalistów w dziedzinie sieci komputerowych, do których obowiązków należy ochronna informacji. Gwałtowny rozwój intranetów i postępująca integracja sieci korporacyjnych z Internetem spowodowały jeszcze większe potrzeby w zakresie zapewnienia bezpieczeństwa. Chociaż klasyczne podejście do zapewnienia bezpieczeństwa polega na ochronie danych przed dostępem z zewnątrz, protokół IP [Author ID0: at Thu Nov 30 00:00:00 1899 ]Sec zapewnia również ochronę przed nieautoryzowanym dostępem od wewnątrz.

Ustalając profile zabezpieczeń (security profiles), czy to dla kluczowych grup roboczych (key workgroups), czy też dla całej sieci, szyfrowanie, którego dokonuje się za pomocą protokołu IP Security, może zapewnić menedżerom sieci spokój ducha, którego źródłem jest zabezpieczenie komunikacji w przedsiębiorstwie.[Author ID1: at Tue Jul 31 14:54:00 2001 ] ([Author ID1: at Tue Jul 31 14:54:00 2001 ]W rozdziale 10. opisano szczegółowo instalowanie protokołu IP Security)[Author ID1: at Tue Jul 31 14:54:00 2001 ].

Zastosowanie wirtualnych [Author ID1: at Mon Aug 6 09:46:00 2001 ]Wirtualnych [Author ID1: at Mon Aug 6 09:46:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:46:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:46:00 2001 ]prywatnych [Author ID1: at Mon Aug 6 09:46:00 2001 ]Prywatnych [Author ID1: at Mon Aug 6 09:46:00 2001 ](Virtual Private Networks)

Zastosowanie wirtualnych [Author ID1: at Mon Aug 6 09:41:00 2001 ]Wirtualnych [Author ID1: at Mon Aug 6 09:41:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]prywatnych[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ]Prywatnych[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ](Virtual Private Networks [Author ID1: at Tue Jul 31 00:52:00 2001 ]-[Author ID1: at Tue Jul 31 00:52:00 2001 ]— [Author ID1: at Tue Jul 31 00:52:00 2001 ]VPN) opartych na technologiach internetowych — inaczej mówiąc, połączenia internetowe gwarantowane poprzez usługodawców internetowych (Internet service [Author ID1: at Tue Jul 31 00:52:00 2001 ]Service [Author ID1: at Tue Jul 31 00:52:00 2001 ]providers[Author ID1: at Tue Jul 31 00:52:00 2001 ]Providers [Author ID1: at Tue Jul 31 00:52:00 2001 ]-[Author ID1: at Tue Jul 31 00:52:00 2001 ]— [Author ID1: at Tue Jul 31 00:52:00 2001 ]ISPs) lub przez IIS, a dodatkowo jeszcze pewna liczba komputerów-serwerów VPN — stanowią oszczędny i dający się łatwo rozbudować sposób zaspokojenia potrzeb organizacji w zakresie połączeń zdalnych (remote networking).

Zwykle, kiedy wprowadza się zdalny dostęp do sieci (remote networking), zachodzi potrzeba ustanowienia kontroli dostępu do zasobów i danych w przedsiębiorstwie. Wirtualne sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:42:00 2001 ] [Author ID1: at Mon Aug 6 09:42:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:42:00 2001 ] [Author ID1: at Mon Aug 6 09:42:00 2001 ](VPN) muszą zezwolić klientom mobilnym (roaming clients) i klientom zdalnym (remote clients) na połączenie z zasobami sieci LAN oraz pozwolić na wzajemne połączenie pomiędzy zdalnymi biurami, aby mogły współdzielić zasoby i informacje. Dodatkowo należy zapewnić bezpieczeństwo informacji przesyłanych przez Internet lub intranet korporacji.

Z wymienionych powyżej względów wirtualne [Author ID1: at Mon Aug 6 09:41:00 2001 ]Wirtualne [Author ID1: at Mon Aug 6 09:41:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:41:00 2001 ]prywatne[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ]Prywatne[Author ID1: at Mon Aug 6 09:41:00 2001 ] [Author ID1: at Mon Aug 6 09:41:00 2001 ]muszą spełniać następujące warunki:

• Tożsamość użytkownika musi zostać zweryfikowana, a dostęp za pomocą wirtualnych [Author ID1: at Mon Aug 6 09:42:00 2001 ]Wirtualnych [Author ID1: at Mon Aug 6 09:42:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:42:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:42:00 2001 ]prywatnych [Author ID1: at Mon Aug 6 09:42:00 2001 ]Prywatnych [Author ID1: at Mon Aug 6 09:42:00 2001 ](VPN) musi być ograniczony tylko do użytkowników autoryzowanych. Muszą zostać wygenerowane rekordy sprawozdań i inspekcji (audit and accounting records) po to, by można było zobaczyć, kto i kiedy miał dostęp do informacji.

• Klientowi musi zostać przydzielony adres w sieci prywatnej, a adres ten musi być poufny.

• Dane przesyłane przez sieci publiczne muszą być przedstawione w takiej postaci, by nie mogły zostać odczytane przez osoby nieuwierzytelnione. Generowanie i odświeżanie kluczy szyfrowania musi zapewnić bezpieczne szyfrowanie zarówno dla klienta, jak i serwera.

• Muszą być obsługiwane protokoły powszechnie używane w sieciach publicznych.

W wirtualnych sieciach prywatnych do przesyłania danych z sieci prywatnych przez sieci publiczne stosuje się tunelowanie (tunneling). Dane, które mają być przesłane, znane pod nazwą „ładunek użyteczny” (payload), zawarte są w ramkach (frames) lub pakietach (packets) protokołu. Protokół tworzący tunele (tunneling protocol) obudowuje (encapsulates) ramkę w dodatkowy nagłówek (header), zawierający dane dotyczące wyboru trasy (routing information), tak aby zawarte w nim „dane użyteczne” (payload) mogły być przesłany przez sieć pośrednią (intermediate network). Następnie, dla przygotowanych w ten sposób pakietów, wyznacza się trasę w sieci pośredniej (internetwork) pomiędzy węzłami tunelu (tunneling endpoints). Ścieżka logiczna, którą przesyłane są te pakiety nosi nazwę tunelu. Skoro tylko pakiety dotrą do punktu przeznaczenia w tranzytowej sieci pośredniej (transit internetwork), ramki zawarte w nich zostaną oddzielone (unencapsulated) i przesłane dalej do ich ostatecznego miejsca przeznaczenia.

Protokoły tunelowania (tunneling protocols) mogą być protokołami warstwy 2.[Author ID1: at Tue Jul 31 14:55:00 2001 ] (Layer 2) lub warstwy 3.[Author ID1: at Tue Jul 31 14:55:00 2001 ] (Layer 3). Wybór warstwy odpowiada modelowi odniesienia OSI (Open Systems Interconnection Reference Model), w którym warstwa 2.[Author ID1: at Tue Jul 31 14:55:00 2001 ] jest warstwą łącza danych (data link layer), a warstwa 3.[Author ID1: at Tue Jul 31 14:55:00 2001 ] jest warstwą sieciową (network layer). Protokoły PPTP i L2TP są protokołami warstwy 2.[Author ID1: at Tue Jul 31 14:55:00 2001 ], a protokół IPSec jest protokołem warstwy 3.

System Windows 2000 obsługuje zarówno protokół PPTP, jak i protokół L2TP. Protokoły te zapewniają uwierzytelnianie użytkowników (user authentication), szyfrowanie danych (data encryption), obsługę kart znaczników (token card), dynamiczne przyporządkowywanie adresów (dynamic address assignment), kompresję danych (data compression), zarządzanie kluczami szyfrowania (encryption key management) i obsługę wielu protokołów. W protokole IPSec zaimplementowano szyfrowanie danych dla protokołu L2TP w wersji firmy Microsoft, ale sam w sobie nie stanowi kompletnego rozwiązania, ponieważ jak do tej pory nie zapewnia dynamicznego przydzielania adresów (dynamic address assignment), ani obsługi wielu protokołów. W rozdziale 11. opisano krok po kroku sposób implementowania wirtualnych [Author ID1: at Mon Aug 6 09:42:00 2001 ]Wirtualnych [Author ID1: at Mon Aug 6 09:42:00 2001 ]sieci [Author ID1: at Mon Aug 6 09:42:00 2001 ]Sieci [Author ID1: at Mon Aug 6 09:42:00 2001 ]prywatnych[Author ID1: at Mon Aug 6 09:42:00 2001 ] [Author ID1: at Mon Aug 6 09:42:00 2001 ]Prywatnych[Author ID1: at Mon Aug 6 09:42:00 2001 ] [Author ID1: at Mon Aug 6 09:42:00 2001 ](VPNs).

Zastosowanie narzędzi do konfigurowania zabezpieczeń

Narzędzia GUI do konfigurowania i analizowania zabezpieczeń — przystawki (snap-ins),[Author ID1: at Tue Jul 31 00:56:00 2001 ] Szablon zabezpieczeń [Author ID1: at Wed Aug 1 22:16:00 2001 ]Zabezpieczeń [Author ID1: at Wed Aug 1 22:16:00 2001 ](Security Template) oraz Konfigurowanie i analizowanie [Author ID1: at Wed Aug 1 22:16:00 2001 ]Analizowanie [Author ID1: at Wed Aug 1 22:16:00 2001 ]zabezpieczeń [Author ID1: at Wed Aug 1 22:16:00 2001 ]Zabezpieczeń [Author ID1: at Wed Aug 1 22:16:00 2001 ](Security Configuration and Analysis) — zapewniają scentralizowane i łatwe administrowanie zabezpieczeniami systemu Windows 2000. Pozwalają one obniżenie kosztów poprzez określenie jednego punktu, w którym są widoczne zabezpieczenia systemu i z którego można dokonać analizy systemu zabezpieczeń oraz, w razie potrzeby, poprawić je. Za pomocą wyżej wymienionych narzędzi można:

• konfigurować zabezpieczenia dla co najmniej jednego komputera z systemem Windows 2000;

• przeanalizować zabezpieczenia co najmniej jednego komputera z systemem Windows 2000;

• wykonać te zadania korzystając z jednolitych narzędzi wchodzących w skład systemu Windows.

Narzędzia do konfigurowania i analizowania zabezpieczeń pozwalają na konfigurowanie na poziomie makro (configuration at a macro level). Innymi słowy umożliwiają zdefiniowanie wielu ustawień konfiguracyjnych i zaimplementowanie ich jako drugoplanowe (in the background). Zadania konfigurowania mogą być łączone w sieci i zautomatyzowane. Nie wymagają już wielokrotnego naciskania tych samych klawiszy ani odwiedzania wielu różnych aplikacji w celu skonfigurowania grupy komputerów.

Narzędzia do konfigurowania zabezpieczeń nie są przeznaczone, aby zastąpić nimi narzędzia systemowe, które mają wpływ na system zabezpieczeń takich jak Menedżer użytkowników[Author ID1: at Wed Aug 1 22:16:00 2001 ] [Author ID1: at Wed Aug 1 22:16:00 2001 ]Użytkowników[Author ID1: at Wed Aug 1 22:16:00 2001 ] [Author ID1: at Wed Aug 1 22:16:00 2001 ](User Manager), Menedżer serwerów[Author ID1: at Wed Aug 1 22:16:00 2001 ] [Author ID1: at Wed Aug 1 22:16:00 2001 ]Serwerów[Author ID1: at Wed Aug 1 22:16:00 2001 ] [Author ID1: at Wed Aug 1 22:16:00 2001 ](Server Manager), Edytor listy [Author ID1: at Wed Aug 1 22:16:00 2001 ]Listy [Author ID1: at Wed Aug 1 22:16:00 2001 ]ACL (ACL Editor) i tak dalej. Stanowią raczej ich dopełnienie, definiując moduł programowy tzw. silnik (engine), który może interpretować standardowe pliki konfiguracyjne i wykonać konieczne operacje automatycznie na drugim planie (in the background). Administratorzy mogą nadal używać istniejących narzędzi, lub ich nowszych wersji, do zmiany pojedynczych ustawień zabezpieczeń, kiedy tylko zachodzi potrzeba.

Inaczej niż w przypadku innych systemów operacyjnych, bezpieczeństwo jest cechą charakterystyczną systemu Windows 2000 jako całości. Prawie każdy ze składników systemu jest odpowiedzialny za jakiś aspekt bezpieczeństwa. Dlatego udzielenie odpowiedzi na pytania typu „Czy mój komputer jest bezpieczny?” oraz „Czy moja sieć jest bezpieczna?” jest bardzo trudne. Zwykle administrator systemu, podejmując próbę odpowiedzi na te pytania, musi zbadać wiele różnych składników systemu i użyć wielu narzędzi. Narzędzia do konfigurowania zabezpieczeń zaprojektowano jako środek pomocniczy przy udzielaniu odpowiedzi na pytania związane z bezpieczeństwem systemu, czy to ogólne, jak przytoczone powyżej, czy też bardzo szczegółowe. Narzędzia te, w celu zapewnienia administrowania zabezpieczeniami i możliwości uzyskania danych o zabezpieczeniach, pozwalają na skonfigurowanie i analizę poniższych elementów:

• Założenia kont [Author ID1: at Wed Aug 1 22:16:00 2001 ]K[Author ID1: at Mon Aug 6 09:42:00 2001 ]ont [Author ID1: at Wed Aug 1 22:16:00 2001 ](Account policies[Author ID1: at Wed Aug 1 22:17:00 2001 ]P[Author ID1: at Mon Aug 6 09:42:00 2001 ]olicies[Author ID1: at Wed Aug 1 22:17:00 2001 ]) — ustal założenia dostępu (access policy), włącznie z założeniami haseł domen lub lokalnymi (domain or local password policies), założenia ochrony przed niepożądanym odczytem dla domeny lub lokalne (domain or local lockout policy) oraz założenia protokołu Kerberos dla domeny.

• Założenia lokalne [Author ID1: at Mon Aug 6 09:42:00 2001 ]Lokalne [Author ID1: at Mon Aug 6 09:42:00 2001 ](Local policies[Author ID1: at Mon Aug 6 09:42:00 2001 ]Policies[Author ID1: at Mon Aug 6 09:42:00 2001 ]) — skonfiguruj lokalne założenia inspekcji (local audit policy), przypisanie praw użytkownika (user rights assignment) i różne opcje zabezpieczeń, takie jak kontrolowanie dyskietek (floppy disk), CD-ROM-ów i tak dalej.

• Grupy z ograniczeniami (Restricted groups) — przypisz członkostwo w grupie dla grup wbudowanych (built-in groups), takich jak Administrators, Server Operators, Backup Operators, Power Users itd., jak również innych grup specjalnych skonfigurowanych przez administratora. Nie powinno to być używane jako powszechnie stosowane narzędzie do zarządzania członkostwem, ale wyłącznie do kontrolowania grup, którym przypisano specjalne właściwości (sensitive capabilities).

• Usługi systemowe [Author ID1: at Mon Aug 6 09:42:00 2001 ]Systemowe [Author ID1: at Mon Aug 6 09:42:00 2001 ](System services[Author ID1: at Mon Aug 6 09:42:00 2001 ]Services[Author ID1: at Mon Aug 6 09:42:00 2001 ]) — skonfiguruj zabezpieczenia dla różnych usług zainstalowanych w systemie, włącznie z sieciowymi usługami transportowymi (transport services) takimi jak TCP/IP, NetBIOS, współdzieleniem plików CIFS (Common Internet File System),drukowaniem itd. Można je skonfigurować jako opcje (startup options) — uruchamiane automatycznie, ręcznie lub zablokowane — lub można również ustanowić kontrolę dostępu do tych usług: zagwarantować lub odmówić dostępu w celu uruchomienia (start), zatrzymania (stop), [Author ID1: at Tue Jul 31 00:27:00 2001 ]przerwania (pause) czy wydawania poleceń sterujących.

Wskazówka. Więcej informacji na temat CIFS można znaleźć dzięki odnośnikom (links), znajdującym się pod adresem www.cifs.com.

• Współdzielenie plików lub folderów (File or folder sharing) — skonfiguruj ustawienia systemu plików NTFS (Windows NT File System) oraz usługę przeadresowywania (Redirector service). Obejmują one opcje wyłączania dostępu anonimowego (anonymous access), uaktywniania podpisów i zabezpieczeń pakietów przy uzyskiwaniu dostępu do różnych udostępnionych plików sieciowych (network file shares). Przyszłe wersje będą zawierały inne ustawienia dotyczące usług takich jak IIS.

• Rejestr systemowy (System Registry) — ustaw zabezpieczenia kluczy Rejestru.

• Magazyn systemowy (System store) — ustaw zabezpieczenia woluminów i drzew katalogów lokalnego systemu plików.

• Zabezpieczenia Active Directory (Directory security[Author ID1: at Mon Aug 6 09:43:00 2001 ]Security[Author ID1: at Mon Aug 6 09:43:00 2001 ]) — zarządzanie zabezpieczeniami obiektów znajdujących się w Active Directory.

• Wstępnie zdefiniowane konfiguracje (Predefined configurations) — wykorzystaj te konfiguracje w postaci, w jakiej zostały dostarczone, lub wykorzystaj je jako punkt wyjścia do tworzenia własnych konfiguracji. Możliwości takie daje przystawka (snap-in) Szablon zabezpieczeń [Author ID1: at Sun Aug 5 19:42:00 2001 ]Zabezpieczeń [Author ID1: at Sun Aug 5 19:42:00 2001 ](Security Template).

Ponieważ narzędzia do konfigurowania zabezpieczeń służą do ograniczania kosztów związanych z administrowaniem zabezpieczeniami sieci, ważne jest, by były łatwe do nauczenia się i do stosowania. Nie zawierają złożonych opcji, tylko prosty, jednolity interfejs graficzny (GUI) do definiowania konfiguracji, zapisywania ich do pliku i oglądania danych do analizowania bezpieczeństwa zapisanych w bazie danych analizy zabezpieczeń (security analysis database). Interfejs ten ma znormalizowany wygląd konsoli MMC.

Nie ma tu nadmiernie rozbudowanej grafiki ani statystyki, są tylko informacje podane w postaci tabel z widocznymi wskazówkami sygnalizującymi problemy związane z zabezpieczeniami. Dodatkowo program narzędziowy wywoływany z wiersza poleceń o nazwie Secedit.exe pozwala administratorom na uruchomienie konfiguracji i analizy jako część skryptu. Administratorzy mogą korzystać z interfejsu GUI lub z wiersza poleceń, by zastosować którąś z zapisanych konfiguracji i przeanalizować ją w celu dopasowania jej do istniejących zasad administrowania. Mogą również do zdefiniowania konfiguracji i przeglądania danych analitycznych skorzystać z interfejsu GUI. W rozdziale 12. znajdują się szczegółowe informacje o narzędziach do konfigurowania i analizy zabezpieczeń systemu Windows 2000 oraz opis korzystania z nich.

Zmiana systemu z Windows NT 4 na Windows 2000

Przechodzenie ze środowiska Windows NT 4 na domeny systemu Windows 2000 jest proste, ponieważ istnieje zgodność z wcześniejszymi wersjami protokołów zabezpieczeń i protokołami replikacji kont występującymi w systemie Windows NT 4. Zmiana taka jest łatwa [Author ID1: at Tue Jul 31 00:29:00 2001 ]do wykonania, ponieważ system Windows 2000 ma następujące właściwości:

• Kontroler domeny (DC) systemu Windows 2000 może wystąpić w roli zapasowego kontrolera domeny (BDC) systemu Windows NT 4 i nastąpi replikacja kont domeny z istniejącego głównego kontrolera domeny (PDC) systemu Windows NT 4.

• Stacje robocze z systemem Windows NT 4 mogą wysyłać do kontrolera domeny (DC) systemu Windows, który spełnia rolę zapasowego kontrolera domeny (BDC) systemu Windows NT 4, żądania uwierzytelniania przez sieć, korzystając z protokołu uwierzytelniania NTLM.

• Kontrolery domen (DCs) systemu Windows 2000 mogą ustanawiać relacje zaufania z domenami systemu Windows NT 4 i obsługiwać uwierzytelnienie przekazujące (pass-through authentication) pomiędzy domenami. Oznacza to, że systemy zabezpieczeń domen w przedsiębiorstwie nie muszą w tym samym czasie zostać zaktualizowane do systemu zabezpieczeń systemu Windows 2000.

Kontrolery domen (DC) systemu Windows NT 4 mogą być zastępowane przez kontrolery domen (DCs) systemu Windows 2000 stopniowo. Narzędzia systemu Windows NT 4 do zarządzania kontami wykorzystywane są w głównym kontrolerze domeny (PDC) tak długo, jak długo ten kontroler pracuje pod kontrolą systemu Windows NT 4. Ostatecznie wszystkie kontrolery domeny (DCs) mogą być zaktualizowane, by mogły wykorzystywać Active Directory do zarządzania kontami i replikację kont pomiędzy kontrolerami domen (multimaster account replication).

Obsługa wielu protokołów uwierzytelniania przez system Windows 2000 oznacza, że użytkownicy mogą mieć dostęp do usług systemu Windows 2000 z dowolnego miejsca w mieszanym środowisku po jednokrotnym zalogowaniu się do domeny. Ponieważ system Windows 2000 nadal obsługuje uwierzytelnianie za pomocą protokołu NTLM, klienty [Author ID1: at Tue Jul 31 00:31:00 2001 ]klienci [Author ID1: at Tue Jul 31 00:31:00 2001 ]Windows NT 4, które [Author ID1: at Tue Jul 31 00:31:00 2001 ]którzy [Author ID1: at Tue Jul 31 00:31:00 2001 ]nie korzystają z protokołu uwierzytelniania Kerberos, mogą nadal łączyć się z serwerami aplikacji systemu Windows 2000.

Właściwości te pozwalają organizacjom na elastyczne planowanie i wdrażanie strategii przechodzenia na system Windows 2000 w miarę rosnących potrzeb.

33 Część I ♦ Podstawy obsługi systemu WhizBang (Nagłówek strony)

40 T:\Paweł\r-01.03.doc[Author ID2: at Mon Aug 13 11:48:00 2001 ]C:\Helion\Windows_2000_Security\zwrot\Poprawione\r-01.03.doc[Author ID1: at Mon Aug 6 09:44:00 2001 ][Author ID2: at Mon Aug 13 11:27:00 2001 ]C:\Helion\Windows_2000_Security\zwrot\3 po kor. językowej\r-01.03.doc[Author ID1: at Sun Aug 5 19:34:00 2001 ]

---