Moim rodzicom, Robertowi i Isie, którym powinienem zadedykować książkę już dawno temu.
O Autorze Po raz pierwszy zetknąłem się z komputerem w wieku 11 lat. Od tamtej pory nieustannie mi towarzyszy. Swą karierę zawodową rozpocząłem jako inżynier elektronik, projektując centrale telefoniczne i systemy bankowe. Pracowałem nad systemami zabezpieczeń, które mają duże znaczenie w bankowości. Zajmowałem się kształceniem korespondencyjnym, a następnie zostałem wykładowcą uniwersyteckim. Posiadam ponadtrzydziestoletnie doświadczenie w pracy w przemyśle, handlu i edukacji. W roku 1969 zostałem jednym z pierwszych programistów mikroprocesorów (tempus fugit), a wkrótce także specjalistą od sieci komputerowych. Dzięki swej pracy zdobyłem certyfikaty Microsoftu: Microsoft Certified Database Administrator, Systems Engineer plus Internet oraz Trainer. Ponadto przez 15 lat byłem redaktorem czasopisma technicznego i napisałem więcej artykułów i skryptów akademickich niż chciałbym się do tego przyznać.Obecnie prowadzę własną firmę consultingową, ku uciesze mamy, która jest dumna, że w końcu mam prawdziwą pracę. Wiele lat temu ożeniłem się z uroczą irlandzką dziewczyną, a to, że mnie wybrała mnie, wciąż jest źródłem mojego zdumienia i radości. Wprost niewiarygodne, że w ciągu 25-iu lat nie uskarżała się i cierpliwie wspierała przy wszystkich 12-u książkach. Razem mamy dwoje wspaniałych dzieci. Są już dorosłe i wiedzie im się dużo lepiej, niż kiedykolwiek będzie powodziło się ich staremu ojcu. Niniejsza książka jest dwunastą w moim dorobku pisarskim — sądzę, że po prostu nie lubię zbytnio drzew.
Podziękowania Pisanie książki jest wysiłkiem zespołowym, dlatego czasami wydaje mi się, że autor ma najłatwiejsze zadanie. Niniejsza publikacjawiele zawdzięcza wybitnym pracownikom wydawnictwa The Coriolis Group. Stephanie Wall, redaktor prowadzący, uwierzyła w moje zdolności pisarskie i prowadziła przez trudne początki tworzenia. William McManus, redaktor ds. praw autorskich (copy editor), nie tylko poprawił mój angielski, ale także zauważył wszystkie nieścisłości, które przeoczyłem. Nade wszystko Dan Young, redaktor wydania (project editor), służył wsparciem, radami i wskazówkami, zachęcał, był wzorem profesjonalizmu oraz emanował humorem i optymizmem. Specjalne podziękowania kieruję do Laury Wellander, specjalisty ds. koordynacji (production coordinator); Jody Winkler, wykonawcy projektu okładki (cover designer); April Nielsena, odpowiedzialnego za skład (layout designer) i Tracy Schofield, specjalisty ds. sprzedaży (marketing specialist), którzy wspólnie, pracując „za kulisami” procesu twórczego, przyczynili się do powstania tej książki. Osobiście wiele zawdzięczam Johnowi Greenowi, redaktorowi naukowemu (technical editor), który wspierał mnie, doradzał i pomógł wyjaśnić niektóre z bardziej tajemniczych akronimów. Niewielu jest ludzi tak aspołecznych, jak autor w trakcie pracy nad książką. Nie osiągnąłbym niczego bez wsparcia mojej wspaniałej (pod każdym względem) żony Anne, syna Drew i córki Bryony. Muszę tu również wspomnieć dwa koty o imionach: Bryony, Bonnie i Clydzie, które pomogły mi w trakcie pracy nad rozdziałem 4.
Przedmowa Osiąganie odpowiedniego poziomu bezpieczeństwa sieci porównywalne jest z próbą utrzymywania równowagi na linie, po której akrobata przechodzi, jak po dwunastopasmowej autostradzie. Będąc administratorem, nie można nadać praw ani uprawnień, dopóki nie zdobędzie się pewności, że są one bezwzględnie konieczne. Użytkownicy muszą mieć dostęp do zasobów, wystarczający im do wykonywania pracy. Jednak zawsze będą chcieli więcej, niż jest to rzeczywiście konieczne. Kierownicy wyższego szczebla domagają się większych zabezpieczeń, ale pod warunkiem, że nie będzie to nic kosztowało i nie będzie ich dotyczyć. Poza tym widoczne są ciągłe zmiany. To, co było bezpieczne wczoraj, nie jest bezpieczne dzisiaj i stanowi otwarte drzwi dla technologii jutra.
Posługując się analogią, można powiedzieć, że najniebezpieczniejszą rzeczą w cyrku jest siatka zabezpieczająca. Jeśli myślisz, że jesteś bezpieczny, a w siatce jest dziura, wówczas niebezpieczeństwo jest większe niż w sytuacji, gdy wcale nie ma siatki, a na arenę zostaną wypuszczone tygrysy. Czy można zaufać akrobatce na trapezie, która podaje pomocną dłoń? Oczywiście, że tak, aranżer programu ręczył za nią. Ale czy można zaufać aranżerowi programu? Obłęd nie jest warunkiem zasadniczym, jeśli ma się aspiracje, by zostać specjalistą w dziedzinie bezpieczeństwa. Okaże się to dość szybko. W książce tej omówiono bezpieczeństwo sieciowe w sieciach Microsoft Windows 2000, chociaż wiele zasad bezpieczeństwa jest niezależnych od systemu. Publikacja ta ma charakter techniczny, odnosi się do technicznej strony bezpieczeństwa, ale zawsze należy pamiętać, że na bezpieczeństwo w równym stopniu ma wpływ czynnik ludzki. Gdyby zabezpieczenia nie były inteligentnie zaprojektowane, zawsze znaleźliby się użytkownicy, którzy zostawią bez nadzoru komputery, do których są zalogowani, zapisują hasła i przyklejający je na monitorach lub gubią portfele, zawierające karty elektroniczne (smart cards) i kody PIN. Zadaniem specjalisty od bezpieczeństwa sieciowego jest znalezienie równowagi pomiędzy bezpieczeństwem a użytecznością, ustalenie takich kryteriów bezpieczeństwa, które zostaną przyjęte przez wszystkich użytkowników jako możliwe do wprowadzenia i rozsądne. Im bardziej surowe i uciążliwe są wymagania bezpieczeństwa, tym bardziej prawdopodobnym jest, że użytkownicy będą poszukiwać sposobów ich obejścia.
Bezpieczeństwo w systemie Windows 2000 Bezpieczeństwo w systemie Windows 2000 jest oparte na zasadach bezpieczeństwa występujących w systemie Windows NT 4. Tak jak w przypadku NT 4 jedno zalogowanie się do domeny Windows umożliwia użytkownikowi dostęp do dowolnego zasobu w sieci korporacyjnej. System zawiera łatwe w użyciu narzędzia administracyjne do zarządzania kontami i ustalania założeń bezpieczeństwa (security policy). Model domenowy jest elastyczny i pozwala na konfigurowanie sieci w szerokim zakresie; od pojedynczej domeny w jednym miejscu do struktury z wieloma nadrzędnymi domenami kont (multimaster domains), rozmieszczonymi na całym świecie. System Windows 2000 stanowi również podstawę zintegrowanego bezpieczeństwa aplikacji z rodziny BackOffice, włącznie z Microsoft Exchangiem, SQL Serverem, SNA Serverem i Microsoft System Management Serverem. Model bezpieczeństwa systemu Windows 2000 umożliwia organizacjom bezpieczną współpracę z partnerami, dostawcami i klientami za pomocą technologii internetowych, wykorzystujących relacje zaufania (trust relationships). W systemie Windows 2000 zmieniono definicję relacji bezpieczeństwa, ułatwiając ich wykorzystywanie i ustawianie w stosunku do systemu Windows NT 4. Technologie zabezpieczeń rozwijają się szybko. Certyfikaty z kluczem publicznym (public key certificates) i hasła dynamiczne (dynamic passwords) pomagają zaspokoić potrzeby bezpieczeństwa w przedsiębiorstwie. Zdalny dostęp przez sieci publiczne i komunikowanie się pomiędzy przedsiębiorstwami (business-to-business communication) poprzez Internet są siłą
napędową ewolucji technologii zabezpieczeń. Tam, gdzie używanie haseł było wątpliwym zabezpieczeniem, zastąpiono je kartami elektronicznymi (smart cards), a biometria (biometrics) — wykorzystywanie unikatowych cech człowieka, takich jak linie papilarne czy identyfikacji na podstawie badania tęczówki oka zamiast kodu PIN — stanowi mocną podstawę bezpieczeństwa kont, połączoną z łatwością stosowania. Należy zauważyć, że napisano „mocną”, a nie „nienaruszalną”. Nie ma systemów nienaruszalnych!
Dla kogo jest przeznaczona niniejsza książka? Książka ta jest przeznaczona dla osób zajmujących się zawodowo sieciami komputerowymi, możliwie z doświadczeniem z zakresu Windows NT 4, NetWare’a lub Uniksa, które administrują lub mają zamiar zająć się administrowaniem sieciami Windows 2000, a zwłaszcza bezpieczeństwem systemu Windows 2000. Może być również przydatna pracownikom działów pomocy technicznej oraz konsultantom i projektantom zajmującym się rozwojem i ustanawianiem bezpieczeństwa w sieci. Układ książki jest czytelny przede wszystkim dla tych, którzy chcą poznać fakty, wykonać zamieszczone przykłady i szybko rozwiązywać problemy. Jest wiele wspaniałych książek na temat Windows NT, a może jeszcze więcej na temat sieci komputerowych. Nie mam zamiaru odtwarzać informacji zawartych w tych publikacjach. Przyjąłem, że czytelnik wie, jak działają relacje zaufania w systemie NT 4, zetknął się z Menedżerem Użytkowników Domeny (User Manager for Domains), Menedżerem Serwera (Server Manager), Edytorem Założeń Systemowych (System Policy Editor) oraz Podglądem Zdarzeń (Event Viewer), a także zna w praktyce protokół TCP/IP i ograniczenia standardu 10BaseT.
Nowości w systemie zabezpieczeń Windows 2000 Bezpieczeństwo Windows 2000 lub, według określenia firmy Microsoft, Zabezpieczenia rozproszone zawiera wiele nowych elementów, upraszczających administrowanie domeną, poprawiających wydajność i łączących techniki zabezpieczeń internetowych oparte o szyfrowanie z wykorzystaniem klucza publicznego. Elementy te opisane są szczegółowo w niniejszej książce, a jest ich zbyt wiele, by wyliczyć je w przedmowie. Jednakże jest kilka szczególnie ważnych. Firma Microsoft określa je jako „punkty główne” (highlights): •
integracja z Windows 2000 Active Directory zapewnia elastyczne zarządzanie kontami w dużych domenach, z precyzyjną kontrolą dostępu (fine-grain access control) i delegowaniem administrowania,
•
protokół uwierzytelniania Kerberos 5 — standard bezpieczeństwa w Internecie — jest domyślnym protokołem uwierzytelniania w sieci i stanowi podstawę zgodności procedur uwierzytelniania (authentication interoperability),
•
uwierzytelnianie z zastosowaniem certyfikatów z kluczem publicznym (public key certificates), kanały bezpieczne (secure channels), korzystające z protokołu szyfrowania Secure Socket Layer 3(SSL 3) oraz interfejsu aplikacji kryptograficznych CryptoAPI dostarczających standardowych protokołów, zapewniających integralność i poufność danych w sieciach publicznych.
Powyższe elementy oraz wiele innych zostały szczegółowo omówione w niniejszej książce.
Układ książki Rozdział pierwszy przybliża hasła i akronimy, spotykane przy wdrażaniu zabezpieczeń w systemie Windows 2000 oraz zawiera ogólny opis tematów, omówionych szczegółowo w dalszych rozdziałach. Rozdział ten pozwala na zaznajomienie się z pojęciami i podjęcie decyzji, która z kolejnych części książki jest szczególnie interesujący dla czytelnika. Niniejsza książka traktuje o rozwiązywaniu problemów. Rozdział 1. dostarcza wiedzy na temat tego, czego szukać i gdzie to znaleźć. W rozdziale 2. opisano usługi katalogowe Active Directory określające strukturę sieci Windows 2000 i umożliwiające wprowadzanie systemowych, wielopoziomowych stref bezpieczeństwa kontrolowanych dokładniej niż było to możliwe w poprzednich wersjach systemu MS Windows. Rozdział ten podaje, w jaki sposób usługi Active Directory mogą być przystosowane do własnych potrzeb, jak skonfigurować Ustawienia Kontroli Dostępu (Access Control Settings) oraz przedstawia przystawki Konsoli Zarządzania Firmy Microsoft (Microsoft Management Console — MMC snap-ins), które są wykorzystywane do administrowania wszystkimi elementami systemu Windows 2000, łącznie z założeniami bezpieczeństwa. W rozdziale 3. opisano założenia grupowe oraz sposoby, jak ustawienia zawarte w Obiektach Założeń Grupowych (Group Policy Objects — GPOs) mogą być zastosowane do obiektów Active Directory, np. siedzib (sites), domen (domains) i jednostek organizacyjnych (Organizational Units — OUs). Rozdział ten zawiera omówienie dziedziczenia założeń (policy inheritance), w jaki sposób założenia obowiązujące na poziomie domeny (domain level policies) mogą być wymuszane lub blokowane na niższych poziomach struktury Active Directory oraz w jaki sposób odpowiednie ustawienie uprawnień członków grup zabezpieczeń (security group filtering) umożliwia delegowanie administrowania określonymi jednostkami organizacyjnymi (OUs), zachowując ważność założeń dla całej domeny. W rozdziale 4. omówiono protokoły bezpieczeństwa systemu Windows 2000 (Windows 2000 Security Protocols) i ich zastosowanie. W szczególności przedstawiono Kerberos 5, domyślny protokół uwierzytelniania w systemie Windows 2000. Rozdział ten zawiera omówienie obustronnego uwierzytelniania za pomocą protokołów z kluczem tajnym (shared secret protocol) i kluczy wspólnych (shared keys) oraz klucze sesji (session keys), ośrodki dystrybucji kluczy (key
distribution centers), bilety (tickets) uwierzytelniające systemu Kerberos, usługę generowania biletu uwierzytelniającego (ticket granting service), jak i uwierzytelnianie wzajemne pomiędzy domenami (cross-domain authentication). Zasady i ich stosowanie w praktyce opisane w tym rozdziale są głównymi pojęciami dotyczącymi bezpieczeństwa w systemie Windows 2000. W rozdziale 5. został naszkicowany problem nieautoryzowanego dostępu do istotnych danych i opisano jego rozwiązanie w systemie Windows 2000, tzn. System Szyfrowania Plików (Encrypting File System — EFS). System EFS zazwyczaj nie jest widoczny dla użytkownika, który ma dostęp do swoich plików i może je edytować w normalny sposób, podczas gdy pliki pozostają niedostępne dla innych użytkowników. Występują tu pewne problemy, dlatego również omówiono wykorzystywanie agentów odzyskiwania (recovery agents) plików zaszyfrowanych. Zagadnienia poruszane w rozdziałach 6. i 7. łączą się ze sobą. Używanie kluczy publicznych (public keys), kluczy prywatnych (private keys) i certyfikatów bezpieczeństwa (security cerificates) daje wysoki stopień zabezpieczeń w trakcie przesyłania istotnych danych w tak wrogim środowisku, jakim jest Internet. W rozdziale 6. omówiono infrastrukturę klucza publicznego (public key infrastrukture — PKI), wykorzystanie protokołu SSL 3 do ustanowienia bezpieczeństwa witryn internetowych oraz stosowanie podpisów elektronicznych (digital signatures) i szyfrowania (encryption) do ochrony ważnych listów elektronicznych. Rozdział 7. zawiera opis jednostek certyfikujących (certificate authorities — CAs), włącznie z usługami certyfikacji firmy Microsoft (Microsoft Certificate Services) oraz niezależnych jednostek certyfikujących (third party CAs), takich jak VeriSign i Thawte. W rozdziale tym zaprezentowano, jak zainstalować jednostkę certyfikującą (CA) i listę certyfikatów unieważnionych (certificate revocation list — CRL) oraz jak otrzymać certyfikat. W rozdziałach 8. i 9. omówiono rozwiązywanie problemów uwierzytelniania użytkowników (user authentication) w sytuacjach, gdy ochrona za pomocą hasła nie jest najlepszym rozwiązaniem. Rozdział 8. zawiera opis przyporządkowywania certyfikatów (certificate mapping). W ten sposób wprowadzane jest w życie zabezpieczanie logowania za pomocą certyfikatów (certificate-based security for logons) we wrogim środowisku Internetu. W rozdziale tym przedstawiono sposób uwierzytelniania logowania się przez partnerów i firmy zależne, które nie mają indywidualnych kont w danej domenie. Karty elektroniczne (smart cards), omówione w rozdziale 9., szybko stają się najlepszym sposobem uwierzytelniania, szczególnie w wielkich organizacjach, w których nie dawano sobie rady z zabezpieczeniem za pomocą haseł. Dane kluczowe są najmniej bezpieczne w trakcie przesyłania ich poprzez sieć. Podczas gdy przeglądarki (browsers) mogą wykorzystywać szyfrowanie SSL 3, konieczne jest, by aplikacje również były zabezpieczane przez mechanizmy SSL 3. Protokół Internet Protocol Security (IPSec), omówiony w rozdziale 10., jest niewidocznym dla użytkownika sposobem zabezpieczenia ruchu w sieci przed osobami postronnymi i niepożądanymi działaniami użytkowników tej sieci. Podczas przesyłania przez sieci zewnętrzne tak, jak Internet, tunelowanie (tunneling) poprzez Wirtualne Sieci Prywatne (Virtual Private Networks — VPNs), omówione w rozdziale 11., jest niekosztownym rozwiązaniem problemów bezpieczeństwa. Rozdział 12. zawiera opis narzędzi do konfigurowania bezpieczeństwa lokalnego za pomocą Szablonów Bezpieczeństwa (Security Templates), do modyfikacji parametrów bezpieczeństwa, tworzenia nowych szablonów i analizy ustawień zabezpieczeń. Na zakończenie, w dodatku A, zamieszczono słowniczek wyjaśniający określenia techniczne pojawiające się w niniejszej książce, a obszerny indeks pozwala czytelnikowi szybko znaleźć określone pojęcia i zagadnienia, ułatwiając korzystanie z publikacji.
W jaki sposób korzystać z niniejszej książki Niniejsza książka może być czytana kolejno; od początku do końca, co pozwoli nauczyć się podstawowych zagadnień bezpieczeństwa w systemie Windows 2000. Jednak można również pomijać niektóre zagadnienia, szukać przykładów i procedur, które mogą być pomocne w rozwiązywaniu problemów napotkanych w rzeczywistości. Książka ta jest środkiem zaradczym. Proszę korzystać z niej w sposób najlepiej odpowiadający potrzebom i doświadczeniu czytelnika. Komentarze i konstruktywna krytyka będą mile widziane. Proszę przesyłać je na adres
[email protected], zamieszczając tytuł książki w temacie wiadomości.
Rozdział 1
Bezpieczeństwo w systemie Windows 2000 Jeśli potrzebujesz natychmiastowego rozwiązania następującego problemu: 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 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-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 Sieciach Prywatnych (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 Wirtualne Sieci Prywatne (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) Serwer Certyfikatów Firmy 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 Firmy 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 — ustanowione dla konta w systemie Windows — 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 Prywatne Wirtualne Sieci Prywatne (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 Sieci Prywatne (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, 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 Sieci Prywatnych (VPN) opartych na protokole PPTP i na niedawno opracowanym protokole L2TP. Protokół IPSec również obsługuje Wirtualne Sieci Prywatne (VPN), ale często nie spełnia wszystkich wymagań. Wirtualne Sieci Prywatne (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 Zabezpieczeń (Security Templates),
•
przystawki — Konfigurowanie i Analiza Zabezpieczeń (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.
Rysunek 1.1. Hierarchiczna przestrzeń nazw domen (domain name space) systemu Windows 2000
Rysunek 1.2. Model wielodomenowy
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. 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 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 twoway 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ą.
Rysunek 1.3. 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\Run i wpisać dcpromo.
2.
Po uzyskaniu pozwolenia wybrać opcję Domena potomna (Child 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 Lokalne (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 (Users), Grupy (Groups) czy Drukarki (Printers),
•
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 — Administrowanie 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 Użytkownika — Administrowanie 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 Dostępu (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, takich jak usuwanie haseł użytkowników lub blokowanie kont (disabling accounts) 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 Dostępu (Access Control List — 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-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 Kontroli Dostępu (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 zobacz na stronie: Korzystanie z Edytora listy kontroli dostępu (Access Control List Editor)
Zastosowanie Protokołów Zabezpieczeń (Security Protocols) 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 Za Pomocą Haseł (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.
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 Usługodawcy Zabezpieczeń (Security Support Provider Interface) Interfejs Usługodawcy Zabezpieczeń (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 Dystrybucji Kluczy (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 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. 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.
Rysunek 1.4. 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 Dystrybucji Kluczy (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 (SingleSign-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-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 Dystrybucji Kluczy (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 Dystrybucji Kluczy (KDC) znają hasło użytkownika lub, w przypadku Centrum Dystrybucji Kluczy (KDC), hasło zaszyfrowane za pomocą algorytmu jednokierunkowego (one-way encrypted password). Protokół definiuje wymianę komunikatów pomiędzy klientami, Centrum Dystrybucji Kluczy (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-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 Dystrybucji Kluczy (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 Dystrybucji Kluczy (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 Dystrybucji Kluczy (KDC).
Rysunek 1.5. Protokół uwierzytelniania Kerberos Bilet sesji (session ticket) protokołu Kerberos zawiera unikatowy klucz sesji (session key) utworzony przez Centrum Dystrybucji Kluczy (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 Dystrybucji Kluczy (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 Kontroli Dostępu (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. 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 Dystrybucji Kluczy (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 Dystrybucji Kluczy (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 Dystrybucji Kluczy (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 Dystrybucji Kluczy (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 Certyfikatów (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 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 Certyfikatów (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).
Rysunek 1.6. 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/21-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 Certyfikatów (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-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).
Rysunek 1.7. 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.
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-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 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-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 Microsoftu (Certificate Server) świadczy usługi wydawania i zarządzania certyfikatami dla aplikacji stosujących kryptografię klucza publicznego (public key cryptography). Usługi Serwera Certyfikatów (Certificate Server) można adaptować dla potrzeb różnych organizacji. Serwer Certyfikatów (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 Certyfikatów 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 Certyfikatów 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 Certyfikatów (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 Certyfikatów (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 typu Microsoft IIS mogą dokonać uwierzytelniania klientów dla łączności bezpiecznej (secure communications) za pomocą certyfikatów wydanych przez Serwer Certyfikatów (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-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 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 Siei Prywatne (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-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-tobusiness 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 zintegrowane z systemem Windows 2000, wykorzystując do uwierzytelniania Sieciowego Interfejs Usługodawcy Zabezpieczeń (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.
[email protected]) 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 prywatnypubliczny 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-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 Sieci Prywatne (Virtual Private Networks — 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ół IPSec 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. W rozdziale 10. opisano szczegółowo instalowanie protokołu IP Security.
Zastosowanie Wirtualnych Sieci Prywatnych (Virtual Private Networks) Zastosowanie Wirtualnych Sieci Prywatnych (Virtual Private Networks — VPN) opartych na technologiach internetowych — inaczej mówiąc, połączenia internetowe gwarantowane poprzez usługodawców internetowych (Internet Service Providers — 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 Prywatne (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 Sieci Prywatne muszą spełniać następujące warunki: •
Tożsamość użytkownika musi zostać zweryfikowana, a dostęp za pomocą Wirtualnych Sieci Prywatnych (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 (Layer 2) lub warstwy 3 (Layer 3). Wybór warstwy odpowiada modelowi odniesienia OSI (Open Systems
Interconnection Reference Model), w którym warstwa 2 jest warstwą łącza danych (data link layer), a warstwa 3 jest warstwą sieciową (network layer). Protokoły PPTP i L2TP są protokołami warstwy 2, 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 Sieci Prywatnych (VPNs).
Zastosowanie narzędzi do konfigurowania zabezpieczeń Narzędzia GUI do konfigurowania i analizowania zabezpieczeń — przystawki (snap-ins) Szablon Zabezpieczeń (Security Template) oraz Konfigurowanie i Analizowanie Zabezpieczeń (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 (User
Manager), Menedżer Serwerów (Server Manager), Edytor Listy 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 (Account Policies) — 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 (Local Policies) — 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 (System Services) — 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), 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) — 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ń (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 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 (passthrough 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, klienci Windows NT 4, którzy 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.
Rozdział 2 Jeśli potrzebne jest natychmiastowe rozwiązanie zobacz na stronie: Obsługa standardów otwartych (open standards) Obsługa standardowych formatów nazw Zastosowanie interfejsów API Zastosowanie programu Windows Scripting Host Możliwości rozbudowy Zastosowanie zabezpieczeń rozproszonych Zastosowanie rozszerzeń edytora założeń grupowych (Group Policy editor) dotyczących ustawień zabezpieczeń Analiza domyślnych ustawień kontroli dostępu Analiza członkostwa w grupach domyślnych Przełączanie pomiędzy kontekstami użytkownika Synchronizowanie komputerów po aktualizacji systemu z domyślnymi ustawieniami zabezpieczeń Zastosowanie przystawki (snap-in) Szablony zabezpieczeń (security templates) Edytor listy kontroli dostępu (Access Control List)
W skrócie Active Directory w systemie Windows 2000 Na ogół sieci komputerowe w wielkich przedsiębiorstwach składają się z zespołu serwerów wewnętrznych przeznaczonych dla użytkowników, serwerów dla najważniejszych danych, dla intranetu, ze strefą zastrzeżoną i otwartą oraz z publicznej witryny internetowej. Administratorzy muszą mieć możliwość obserwowania całej sieci z jednego miejsca, ustawiania ograniczeń, aby zabezpieczyć się przed nieautoryzowanym dostępem do danych kluczowych oraz wykonywania replikacji danych, tak aby dostęp do nich był kontrolowany. Ten dostęp do danych potrzebny jest użytkownikom, nawet jeśli nie są pewni, w którym katalogu czy wręcz serwerze dane są zapisane. Zarządzający firmą ponownie chcą mieć pewność, że usługi katalogowe, w granicach sieci i systemu operacyjnego, będą działały, a ich zakres będzie się rozszerzał wraz z rozwojem sieci. Usługi katalogowe Active Directory firmy Microsoft spełniają te wymagania, a dodatkowo umożliwiają stosowanie zabezpieczeń rozproszonych i replikację pomiędzy wszystkimi kontrolerami domeny (multimaster replication). Protokoły i formaty obiektów (object formats) obsługiwane przez Active Directory są miarą otwartości (openness) usług katalogowych, tzn. miarą stopnia dostępności katalogów dla tych klientów, dla których nie zostały one wprost przeznaczone. Jednakże pożądany stopień otwartości (openness) stwarza dla administratora problemy. Jeśli sieć jest otwarta dla wielu klas użytkowników — użytkowników z firm współpracujących oraz tych, którzy nie mają w domenie kont ani haseł — wówczas bezpieczeństwo może zostać zakwestionowane. Sieć można rozbudowywać i w miarę rozwoju firmy tworzyć domeny potomne (child domains), ale kontekst bezpieczeństwa (security context) ochraniający najważniejsze dane musi pozostać w określonych granicach. Administrowanie będzie delegowane — pojedyncza osoba nie będzie w stanie administrować siecią przedsiębiorstwa działającego na skalę światową — ale zakres uprawnień administratorów lokalnych nie powinien obejmować dostępu do najważniejszych danych, znajdujących się poza strefą przez nich administrowaną. Ponadto należy pamiętać, że administratorzy lokalni nie powinni mieć uprawnień do nadawania prawa dostępu do takich informacji tym użytkownikom, którzy nie są administratorami. Wymogi dotyczące zabezpieczeń rozproszonych (distributed security), potrzeba ustanowienia stref i granic bezpieczeństwa (security zones and boundaries) oraz istota sieci międzynarodowych, łączących wiele domen i organizacji, są uwzględnione przez usługi katalogowe Active Directory systemu Windows 2000.
Przestrzeń nazw (namespace) Active Directory Active Directory jest połączeniem internetowego rozumienia przestrzeni nazw (namespace) z usługami katalogowymi systemu operacyjnego. Dlatego nie jest zaskoczeniem fakt, że — dla administrowania Active Directory — systemem lokalizującym (locator) jest system nazw domen (Domain Name System — DNS). Jednak nie jest to ten system, który administratorzy od dawna znają i wykorzystują. W systemie Windows NT, poprzez połączenie DNS z usługą WINS (Windows Internet Naming Service), rozwiązano wiele problemów występujących w starej, statycznej wersji DNS. W systemie Windows 2000 nastąpiła całkowita integracja, dzięki czemu dynamiczny DNS (Dynamic DNS — DDNS) umożliwia klientom, mającym dynamicznie przydzielone adresy, bezpośrednie rejestrowanie się na serwerze DNS i bieżące aktualizowanie tabeli DNS, bez korzystania z WINS. Protokół LDAP (Lighweight Directory Access Protocol) jest głównym protokołem używanym w Active Directory. Protokół ten może przekraczać granice systemu operacyjnego, łącząc różne przestrzenie nazw (namespaces). Dzięki jego zastosowaniu możliwe jest zarządzanie katalogami programów użytkowych, jak i katalogami z innych sieciowych systemów operacyjnych, co pozwala na obniżenie kosztów ogólnych administrowania i kosztów związanych z utrzymywaniem wielu przestrzeni nazw oraz można traktować je jako jeden katalog uniwersalny. Usługi katalogowe Active Directory nie są zgodne ze standardem X.500 i zamiast niego wykorzystują protokół LDAP jako protokół dostępu (access protocol), jak i realizują model informacyjny standardu X.500 (X.500 information model), nie dbając o dodatkowe elementy tego standardu. Dzięki ich stosowaniu, uzyskuje się wysoki poziom współdziałania (interoperability), konieczny do administrowania niejednorodnymi sieciami. Tradycyjnie usługi katalogowe są narzędziami do organizowania, zarządzania i lokalizowania w systemie komputerowym obiektów, takich jak: drukarki, dokumenty, adresy poczty elektronicznej, bazy danych, użytkowników, składników rozproszonych i innych zasobów. Jednak, gdy sieć staje się coraz większa i bardziej skomplikowana, usługi katalogowe muszą zapewnić zestaw zaawansowanych usług do zarządzania (management services). Active Directory stworzono, by sprostać wymaganiom dotyczącym unifikacji i uporządkowania zmiennych hierarchii serwerów i przestrzeni nazw.
Active Directory jako usługodawca Oprócz podstawowych zadań dotyczących administrowania, usługi katalogowe Active Directory zaspokajają wymagania odnoszące się do: nazw, kwerend (queries), administrowania, rejestrowania oraz rozpoznawania nazw (resolution). Na rysunku 2.1 w skrócie przedstawiono wszystkie funkcje systemu.
Rysunek 2.1. Active Directory jako usługodawca W celu rozszerzenia zakresu usług na wiele przestrzeni nazw (namespaces) Active Directory, zastosowano zintegrowany zestaw protokołów i interfejsów API, aby rozszerzyć zakres usług na wiele przestrzeni nazw (namespaces) oraz zbierać i przedstawiać informacje o katalogach, zasobach różnych systemów operacyjnych i w miejscach oddalonych. Dostępnych jest wiele obiektów COM (Component Object Model), a dzięki programowi Windows Scripting Host (WSH) administrator ma wydajny, łatwy w użyciu interfejs do uruchamiania skryptów obiektowych (object-oriented scripts). Struktura Active Directory umożliwia dopasowanie jej do wielkości firmy od najmniejszych, aż do korporacji międzynarodowych i administracji państwowej.
Bezpieczeństwo Active Directory Jak opisano w rozdziale 1., struktura Active Directory składa się z jednostek organizacyjnych (Organizational Units — OUs), w których umieszczane są obiekty, takie jak: użytkownicy, grupy, zasoby, itd. Ustawienia zabezpieczeń zdefiniowane są wewnątrz Obiektów Założeń Grupowych (Group Policy Objects — GPOs). Konfiguracje dla grup użytkowników i komputerów w obiektach założeń grupowych (GPOs) tworzone są za pomocą przystawki (snap-in) Edytor Założeń Grupowych (Group Policy editor) konsoli MMC (Microsoft Management Console). Z kolei obiekty GPOs są związane z wybranymi obiektami Active Directory, takimi jak: lokacje
(sites), domeny i jednostki organizacyjne (OUs). Założenia Grupowe (Group Policies) omówiono szczegółowo z rozdziale 3. Rozszerzenie Ustawienia Zabezpieczeń (Security Settings Extension) Edytora Założeń Grupowych (Group Policy editor) można użyć do określenia konfiguracji zabezpieczeń dla grup użytkowników lub grup komputerów w obiektach GPOs. Konfiguracja ta jest następnie egzekwowana jako część założeń grupowych. Rozszerzenie Ustawienia Zabezpieczeń (Security Settings Extension) stanowi dopełnienie istniejących narzędzi zabezpieczających system, takich jak: Edytor Listy Kontroli Dostępu (Access Control List Editor), Menedżer Użytkowników Lokalnych (Local User Manager) oraz Menedżer Serwera (Server Manager). Rozszerzenie Ustawienia Zabezpieczeń (Security Settings Extension) określa procedurę tzw. aparat (engine), który może interpretować standardową konfigurację zabezpieczeń i wykonać konieczne operacje jako zadania drugoplanowe. W razie potrzeby można korzystać z istniejących narzędzi do zmiany poszczególnych ustawień.
Lista Kontroli Dostępu (Access Control List) W zakończeniu niniejszego rozdziału opisano Listę Kontroli Dostępu (Access Control List). Domyślne ustawienia kontroli dostępu stanowią znaczną część zabezpieczeń systemu Windows 2000 i dlatego ważna jest znajomość tych ustawień oraz sposób ich modyfikacji. Przejście do system Windows 2000 z systemu Windows NT, w którym nie stosuje się domyślnych ustawień Windows 2000, może mieć wpływ na bezpieczeństwo systemu Windows 2000. Listy kontroli dostępu mogą być modyfikowane za pomocą wielu narzędzi — poleceń, takich jak: Secedit, przystawka (snap-in) Szablony Zabezpieczeń (Security Templates) konsoli MMC oraz Edytor ACL (ACL Editor). Chociaż lista kontroli dostępu nie jest związana wyłącznie z Active Directory (także serwery członkowskie i stacje robocze mają listy ACL), to ma wpływ na założenia domeny i założenia grupowe (Domain and Group Policy). Dlatego zostanie ona omówiona w niniejszym rozdziale.
Bezpośrednie rozwiązania
Spełnianie standardów otwartych (open standards) Dzięki Active Directory wygląd sieci został ujednolicony, co znacznie ogranicza liczbę katalogów i przestrzeni nazw (namespaces), z którymi muszą zmagać się administratorzy i użytkownicy. Ma to wpływ na wszystkie sfery administrowania katalogami, włączając w to bezpieczeństwo. Usługi Active Directory zostały specjalnie zaprojektowane, aby scalić inne katalogi i zarządzać nimi, niezależnie od ich fizycznej lokalizacji czy systemów operacyjnych, w których zostały utworzone, oraz narzucić granice bezpieczeństwa i dziedziczenia. Aby to osiągnąć, Active Directory korzysta w szerokim zakresie z istniejących standardów i protokołów, łącznie ze standardowymi formatami nazw i zawiera interfejsy API, ułatwiające komunikowanie się z tymi katalogami. Active Directory korzysta z usługi DNS (Domain Name Service) jako usługi lokalizującej i może wymieniać dane z dowolnym programem użytkowym lub katalogiem, który stosuje protokół LDAP.
Usługa DNS Usługa DNS jest usługą lokalizującą (locator service), stosowaną w Internecie i w większości intranetów, dzięki czemu jest najczęściej wykorzystywaną usługą katalogową na świecie. Usługa lokalizacyjna (locator service) tłumaczy nazwę, np. www.mojafirma.com na adres TCP/IP. W Active Directory nazwy domen systemu Windows 2000 są nazwami DNS — mojafirma.com może być zarówno domeną DNS (obszarem adresowania) oraz domeną Windows 2000. W ten sposób
[email protected] jest zarówno internetowym adresem poczty elektronicznej, jak i nazwą użytkownika w domenie mojafirma.com. Domeny systemu Windows 2000 mogą być zlokalizowane w Internecie i intranecie w taki sam sposób, w jaki inne zasoby są umieszczane w Internecie za pomocą DNS. W systemie Windows 2000 zastosowano dynamiczną usługę DNS (DDNS). Rozwiązany został jeden z głównych problemów związanych z usługą DDNS — główny serwer DDNS jest podatny na uszkodzenia (point of failure). Ponieważ wszystkie kontrolery domeny w systemie Windows 2000 są równe, to wszystkie są serwerami DDNS, co, w razie awarii, umożliwia pracę bez zakłóceń (fail-over protection). Nazwa DNS dla domeny systemu Windows 2000 jest definiowana w sytuacji, gdy instaluje się pierwszy kontroler domeny (DC) lub — dokładniej — gdy zostaje uruchomiony program dcpromo, który awansuje serwer Windows 2000 na pozycję pierwszego kontrolera domeny (DC) w nowej domenie.
Protokół LDAP Active Directory korzysta również z innego standardu stosowanego w Internecie — protokołu LDAP (Internet Proposed Standard RFC 2251), który stworzono jako prostszą alternatywę dla protokołu X.500. Służy on do uzyskania dostępu do usług katalogowych. Firma Microsoft aktywnie uczestniczy w pracach nad rozwijaniem standardów LDAP. W Active Directory zastosowano protokół LDAP w wersji 2 i 3.
Rozpoznawanie standardowych formatów nazw Formaty nazw (name formats) stosowane przez usługi katalogowe mają wpływ zarówno na użytkowników, jak i na programy użytkowe. Jeśli użytkownik lub program użytkowy ma coś znaleźć lub użyć czegoś, to musi on znać nazwę lub niektóre właściwości obiektu, który ma być zlokalizowany. Istnieje kilka powszechnie używanych konwencji nazewniczych w katalogach, które są formalnymi lub faktycznymi standardami. Wiele z nich można stosować w Active Directory. Pozwala to użytkownikom i programom użytkowym, przy korzystaniu z Active Directory, na posługiwanie się formatem nazw, który znają najlepiej. Np.w Active Directory można stosować następujące formaty nazw: •
RFC 822 — są to nazwy w postaci mojanazwa@mojadomena, które są znane większości użytkownikom Internetu jako adresy poczty elektronicznej, np.
[email protected]. Wszyscy użytkownicy w Active Directory mogą stosować przyjazne nazwy zgodne ze standardem RFC 822. Nazwa taka może być używana jako adres poczty elektronicznej lub jako nazwa użytkownika przy logowaniu się do systemu,
•
adresy URL protokołu LDAP i nazwy zgodne ze standardem X.500 — Active Directory obsługuje dostęp za pomocą protokołu LDAP dowolnego klienta, korzystającego z tego protokołu. Nazwy w przypadku protokołu LDAP są mniej intuicyjne niż w przypadku nazw internetowych, ale skomplikowana konwencja nazewnicza zwykle jest ukryta w programie użytkowym. W nazwach tych stosuje się nadawanie nazw na podstawie atrybutów (attributed naming), zgodnie ze standardem X.500. Adres URL w przypadku protokołu LDAP określa serwer, na którym uruchomiono usługi Active Directory oraz nazwę na podstawie atrybutów (attributed name), np. LDAP://myserver.mycompany.com/ CN=i.mclean, OU=Sys, OU=Product, OU=Division, DC=mycompany, DC=com
Zgodność ze standardami otwartymi (open standards), korzystanie z usługi DNS oraz obiektów GPO umożliwiły wprowadzenie w Active Directory modelu zabezpieczeń dziedziczenia założeń grupowych: prawa, uprawnienia, założenia kont, itd. (zob. rysunek 2.2).
Rysunek 2.2. Model połączeń i zabezpieczeń Active Directory
Zastosowanie interfejsów API Active Directory oferuje potężne, elastyczne i łatwe w obsłudze interfejsy API. Dostępność bogatego zestawu interfejsów API dla usług katalogowych zachęca do tworzenia narzędzi, korzystających z usług katalogowych. Np. administrator może napisać skrypt dodający do systemu 100 nowych użytkowników i ustanawiający ich członkami wybranych grup zabezpieczonych (security groups). Zazwyczaj interfejsy usług Active Directory (Active Directory Service Interfaces — ADSI) wykorzystuje się za pomocą języków skryptowych (scripting languages), m.in. Microsoft Visual Basic, chociaż można również używać C/C++. Active Directory zawiera trzy główne zestawy interfejsów API: •
ADSI — zestaw interfejsów COM do manipulowania wieloma usługami katalogowymi i wysyłania do nich zapytań (querying),
•
MAPI — interfejs przesyłania informacji (Messaging API) architektury WOSA (Windows Open Services Architecture),
•
LDAP C API (RFC 1823) — informacyjny dokument RFC, który jest faktycznym standardem przy pisaniu aplikacji protokołu LDAP w języku C.
Interfejsy usług Active Directory (ADSI) Interfejsy ADSI zostały opracowane po to, by ułatwić pisanie programów użytkowych, korzystających z usług katalogowych, które mają dostęp do Active Directory i innych katalogów obsługujących protokół LDAP. Interfejsy ADSI są zbiorem mogących się rozszerzyć interfejsów API, stosowanych przy pisaniu programów użytkowych, które pozwalają na uzyskanie dostępu i zarządzanie Active Directory, dowolnym katalogiem opartym na protokole LDAP i innymi usługami katalogowymi w sieci, łącznie z sieciowymi usługami katalogowymi (Network Directory Services-NDS) firmy Novell. Interfejsy ADSI są częścią interfejsu ODSI (Open Directory Services Interface) architektury Windows Open Services Architecture (WOSA) do manipulacji usługami katalogowymi i wysyłania do nich zapytań.. Obiekty ADSI są dostępne dla Windows NT, NetWare Novell-a, Active Directory, jak również dla pozostałych usług katalogowych, korzystających z protokołu LDAP. Interfejsy ADSI pozwalają na uniezależnienie usług katalogowych od usługodawców sieciowych, dzięki czemu możliwe stało się otrzymanie jednego zestawu interfejsów usług katalogowych do zarządzania zasobami sieciowymi. Efektem jest prostsze tworzenie aplikacji rozproszonych i administrowanie systemami rozproszonymi. Programiści i administratorzy wykorzystują te interfejsy do sporządzania wykazu zasobów usługi katalogowej i zarządzania tymi zasobami, niezależnie od rodzaju sieci, w której one znajdują się. W ten sposób interfejsy ADSI ułatwiają wykonywanie najczęściej spotykanych zadań administracyjnych, np. dodawanie nowych użytkowników, nadawanie uprawnień i inne zadania związane z bezpieczeństwem i zarządzaniem zasobami w rozproszonych systemach komputerowych. Interfejsy ADSI przedstawiają katalog jako zbiór obiektów COM. Na obiektach tych można wykonywać różne działania za pomocą obiektowych języków programowania, takich jak: Visual Basic czy C++. Ponieważ obiekty ADSI są dostępne dla wielu popularnych usług katalogowych, interfejsy ADSI używane są do tworzenia programów użytkowych, które będą pracowały z wieloma katalogami. Wykaz obiektów COM i ich właściwości można odnaleźć w następujący sposób: 1.
Z menu Start\Programy\Narzędzia administracyjne (Start\Programs\Administrative tools) wybierz opcję Usługi Składowe (Component Services).
2.
Rozszerz gałąź Usługi Składowe (Component Services) w sposób pokazany na rysunku 2.3 i wybierz kontener COM + Programy Użytkowe (COM + Applications).
3.
Kliknij prawym klawiszem myszki dowolny w obiekt w prawej części okna i z menu wybierz opcję Właściwości (Properties). Pojawi się okno przedstawiające właściwości obiektu COM (rysunek 2.4).
4.
Wybierz dowolną zakładkę, aby zobaczyć lub dokonać edycji odpowiedniej właściwości.
Rysunek 2.3. Przystawka (snap-in) Usługi Składowe (Component Services) konsoli MMC
Rysunek 2.4. Karta Właściwości (Properties) obiektu IIS Narzędzia (COM IIS Utilities)
Interfejs API usługi przesyłania komunikatów (Windows Messaging API) Active Directory zapewniają obsługę interfejsu MAPI (Messaging API) po to, aby stare programy użytkowe MAPI nadal współpracowały z Active Directory. Zachęca to do korzystania z ADSI przy pisaniu aplikacji korzystających z usług katalogowych.
Interfejs API LDAP C Z interfejsu API LDAP C korzystają programiści piszący programy użytkowe pracujące z wieloma różnymi rodzajami klientów. Istniejące programy użytkowe LDAP będą konkurować z usługami
Active Directory, ale pozostaną niezmienione lub zostaną zmodyfikowanetylko w niewielkim stopniu, za wyjątkiem rozszerzenia zestawu funkcji programów użytkowych do obsługi specjalnych typów obiektów Active Directory. Programiści piszący aplikacje LDAP są zachęcani do przechodzenia na interfejs ADSI, który obsługuje każdą z usług katalogowych, korzystającą z protokołu LDAP. Innymi słowy, aby opracować własne procedury, a coraz więcej administratorów musi to robić, zwłaszcza biorąc pod uwagę bezpieczeństwo, należy poznać i pokochać ADSI.
Zastosowanie programu Windows Scripting Host Nawet ci, którzy nigdy nie napisali żadnej procedury obiektowej ani skryptu, korzystającego z obiektów COM, na pewno będą je uruchamiać. Program Windows Scripting Host (WSH) w systemie Windows 2000 jest interfejsem służącym do uruchamiania skryptów Visual Basic Scripting Edition (VBSript) lub JavaScript. Program ten działa jako sterownik aparatu skryptowego Active X (Active X scripting engines) i może być stosowany w skryptach interaktywnych i nieinteraktywnych. Istnieją dwie wersje WSH: •
wersja okienkowa, wscript.exe — ma swoją kartę Właściwości (Properties sheet),
•
wersja pracująca w trybie znakowym, cscript.exe, — w wierszu poleceń podaje się dla niej odpowiednie parametry (switches).
W wierszu poleceń można uruchomić obydwie wersje programu WSH. Skrypt można również uruchomić, klikając odpowiednią ikonę na pulpicie.
Uruchamianie skryptów za pomocą programu WSH w wersji dla wiersza poleceń Aby uruchomić skrypty za pomocą programu WSH w wersji dla wiersza poleceń (cscript.exe), należy wpisać następujące polecenie: cscript [nazwa skryptu] [parametry hosta] [parametry skryptu]
Nazwa skryptu (script name) oznacza pełną nazwę pliku skryptowego, włącznie z rozszerzeniem oraz niezbędnymi informacjami o ścieżce dostępu. Parametry hosta (host parameters) są to parametry podawane w wierszu poleceń, które uaktywniają lub wyłączają różne opcje programu WSH, a parametry skryptu (script parameters) — to przekazywane do skryptu parametry podawane w wierszu poleceń. Parametry skryptu są zawsze poprzedzone pojedynczym znakiem ukośnika (/). Parametry hosta zawsze poprzedzają dwa ukośniki. Parametry te są opcjonalne. Jednak nie można podać parametrów skryptu bez podania skryptu. Jeśli nie zostanie podana nazwa skryptu ani żaden parametr skryptu, cscript.exe wyświetli informację o prawidłowej składni i listę parametrów programu Windows Scripting Host. Oto lista parametrów hosta wykorzystywanych przez program cscript: •
//B — oznacza tryb wsadowy (batch mode), w którym nie są wyświetlane komunikaty o alarmach, błędach skryptów ani oknach dialogowych,
•
//D — włącza aktywne usuwanie błędów (active debugging),
•
//E:engine — informuje, że do wykonania skryptu użyty będzie aparat (engine),
//H:Cscript lub //H:Wscript — ustanawia domyślny program uruchamiający skrypty (cscript.exe lub wscript.exe). Jeśli nie zostanie wybrany żaden z programów, domyślnym programem uruchamiającym skrypt jest wscript.exe, •
//I — oznacza wybór trybu interaktywnego. Wyświetlane są komunikaty o alarmach, błędach skryptów oraz monity (input prompts). Jest to tryb domyślny, przeciwny trybowi ustawianemu za pomocą parametru //B,
•
//Job:xxxx — powoduje wykonanie zadania Windows Scripting (WS job),
•
//Logo — oznacza, że podczas działania wyświetlany będzie banner. Jest to tryb domyślny, odwrotne znaczenie ma //Nologo.
•
//S — bieżące parametry podane w wierszu poleceń zostaną zapisane dla aktualnego użytkownika,
•
//T:nn — podaje maksymalny czas pracy skryptu w sekundach. Górna granica to 32 767 sekund. Domyślnie nie ma ograniczenia czasu,
•
//X — powoduje wykonanie skryptu w trybie usuwania błędów,
•
//U — oznacza, że bezpośrednie operacje wejście-wyjście z konsoli będą wykorzystywać znaki w standardzie Unicode.
•
//? — spowoduje wyświetlenie informacji, w jaki sposób korzystać z tego polecenia. Ten sam efekt można uzyskać, wpisując polecenie cscript.exe bez żadnych parametrów.
Uruchamianie skryptów za pomocą okienkowej wersji hosta skryptów
Skrypty można również uruchamiać za pomocą programu okienkowej wersji hosta skryptów wscript.exe w następujący sposób: 1.
W wierszu poleceń lub oknie dialogowym Uruchom (Run) wpisz wscript.exe.
2.
Ustaw wybrane przez siebie właściwości hosta skryptów (script host), a potem naciśnij przycisk OK. Stosując ten sposób do wyboru są tylko dwie opcje — zatrzymanie skryptu po określonej liczbie sekund lub wyświetlanie logo.
3.
W oknie Eksploratora Windows (Windows Explorer) lub Mój komputer (My Computer) kliknij dwukrotnie plik skryptu, który ma zostać uruchomiony.
Strona Właściwości programu wscript.exe pozwala na ustawienia globalnych właściwości dla wszystkich skryptów uruchamianych przez wscript.exe na komputerze lokalnym. Można również ustawić właściwości dla pojedynczych skryptów klikając prawym klawiszem myszki plik skryptu w oknie Eksplorator Windows (Windows Explorer) lub Mój komputer (My Computer), wybierając opcję Właściwości (Properties) a następnie wybierając zakładkę Skrypt (Script). Na rysunku 2.5 przedstawiono zakładkę Skrypt pliku metaback.vbs, który jest zapisany w folderze Inetpub/issamples/sdk/admin. Ten sam efekt da uruchomienie programu wscript.exe za pomocą okna dialogowego Uruchom. Do tworzenia prostych skryptów logowania, np. skryptów używających Active Directory do zarządzania usługami katalogowymi, administratorzy mogą również korzystać z funkcji pomocnika WSH (WSH helper functions).
Rysunek 2.5. Strona Plik Skryptowy Właściwości Jednak programowanie obiektowe (OOP) i języki skryptowe wykraczają poza zakres niniejszej książki. Istnieje wiele doskonałych publikacji na ten temat. Administrator zabezpieczeń powinien wiedzieć o istnieniu takich narzędzi, które mogą stanowić dodatkową broń w arsenale środków, służących poprawieniu bezpieczeństwa systemu. Więcej szczegółów na temat programu Windows Scripting Host można znaleźć na stronie www.microsoft.com/isapi. Klikając odpowiednie łącza, znajdujące się na tej stronie, można pobrać próbne skrypty WSH.
Możliwości rozbudowy Przedsiębiorstwa różnią się między sobą wielkością, więc ich usługi katalogowe, aby być wartościowymi, muszą odpowiadać potrzebom zarówno małych, jak i wielkich firm. Dlatego
właśnie usługi katalogowe Active Directory zostały zaprojektowane w taki sposób, by pracowały równie wydajnie na pojedynczym komputerze oraz w wielkim przedsiębiorstwie. Usługi katalogowe Active Directory mogą obsłużyć ponad milion użytkowników w pojedynczej domenie. Liczba użytkowników może być jeszcze większa jeśli utworzy się drzewo domen, strukturę z wieloma drzewami domen lub las domen (forest). Za pomocą usług katalogowych Active Directory można tworzyć małe domeny, które są łatwe w administrowaniu. Pozwala to organizacjom, a tym samym sieciom, z których korzystają, na osiągnięcie wielkich rozmiarów. Administrowanie systemami komputerowymi w wielkich przedsiębiorstwach nie różni się niczym od administrowania systemami w małych firmach — potrzebnych jest tylko więcej administratorów. Active Directory tworzą jedną kopię składu katalogu (directory store) dla każdej domeny. Kopia składu katalogu zawiera obiekty odnoszące się tylko do danej domeny. Domeny pokrewne można połączyć w strukturę drzewa, a każda domena w drzewie domen ma swoją kopię składu katalogu ze swoimi obiektami. Ma również możliwości znajdowania innych kopii w drzewie składu katalogu (tree of the directory store).
Zastosowanie drzew domen i lasów domen Najważniejszym elementem Active Directory, który stanowi o dużych możliwościach rozbudowy systemu, jest struktura o nazwie drzewo domen (domain tree). W odróżnieniu od usług katalogowych, w których występuje pojedyncze drzewo i konieczny jest złożony proces podziału „od góry do dołu” (top-down partitioning), w Active Directory tworzenie dużych drzew domen metodą „od dołu do góry” (bottom-up method) jest proste i intuicyjne. W Active Directory pojedyncza domena jest kompletną częścią katalogu. Jeśli konieczna jest złożona struktura organizacyjna lub zapisanie dużej liczby obiektów, można wiele domen połączyć w drzewo. Wiele drzew może utworzyć las (forest). Na rysunku 2.6 przedstawiono drzewo domen, składające się z jedenastu połączonych ze sobą domen. Jest to model pełnego zaufania (full trust model) uzyskany za pomocą dziesięciu relacji zaufania (trusts). Równoważny model w systemie Windows NT 4 wymagałby ustanowienia 110 relacji zaufania.
Rysunek 2.6. Drzewo domen Usługi katalogowe Active Directory są potężnymi i intuicyjnymi narzędziami administracyjnymi. W przypadku wielkich przedsiębiorstw obiekty można uporządkować hierarchicznie. Graficzny interfejs użytkownika (GUI) zawiera konsolę, w której zastosowano metodę „przeciągnij i upuść” (drag-and-drop control console), umożliwiającą podejście obiektowe do administrowania.
Zastosowanie przystawki (snap-in) Domeny Active Directory i relacje zaufania (Active Directory Domains and Trusts ) Domenami administruje się za pomocą przystawki Domeny Active Directory i Relacje Zaufania (Active Directory Domains and Trusts). Dodatkowe domeny są identyfikowane za pomocą
przyrostków UPN (User Principal Name suffixes). Domyślnym przyrostkiem UPN jest nazwa drzewa, która jest nazwą UPN pierwszej domeny w danym drzewie. Aby użyć przystawkę (snap-in) Domeny Active Directory iRrelacja Zaufania, należy: 1.
Wybrać menu Start\Programy\Narzędzia administracyjne (Start\Programs\Administrative tools) i pozycję Domeny Active Directory i Relacje Zaufania (Active Directory Domains and Trusts).
2.
Kliknąć prawym klawiszem myszki ikonę Domeny Active Directory i Relacje Zaufania umieszczoną najwyżej w lewej części okna i z menu wybrać Właściwości. Pojawi się okno dialogowe podobne do przedstawionego na rysunku 2.7. Umożliwia ono podanie alternatywnego przyrostka UPN dla domeny lub drzewa domen.
Rysunek 2.7. Okno dialogowe domeny Active Directory i Relacje Zaufania (Active Directory Domains and Trusts Properties) przyrostki UPN (UPN Suffixes)
Rysunek 2.8. Okno dialogowe Domena Właściwości (Domain Properties) 3.
Zamknąć okno dialogowe i kliknąć prawym klawiszem myszki nazwę twojej domeny lub nazwę domeny głównej (root domain). Jeśli istnieje drzewo domen, kliknąć opcję Właściwości (Properties). Powinno pojawić się okno dialogowe, takie jak na rysunku 2.8.
Uwaga: Domena przedstawiona na rysunku 2.8 została przetworzona na tryb Native, który oznacza, że w tym drzewie domen mogą być wyłącznie kontrolerzy domeny z systemem Windows 2000. Gdyby domena była w trybie Mixed, pojawiłby się aktywny przycisk umożliwiający jednokierunkową konwersję na tryb Native.
4.
Wybrać zakładkę Relacje Zaufania (Trusts). Możesz ustanowić relacje zaufania z innymi domenami, podając nazwy tych domen oraz hasło administratora. Naciśnąć przycisk Anuluj
(Cancel), aby powrócić do przystawki (snap-in) Domeny Active Directory i Relacje Zaufania (Active Directory Domains and Trusts).
Wskazówka: Jeśli instalujesz kontroler domeny jako domenę potomną (child domain) domeny głównej (root domain), nie musisz ustanawiać żadnych relacji zaufania. Instalacja domeny potomnej (child domain) automatycznie ustawia obustronne relacje zaufania lub relacje zaufania usługi Kerberos (Kerberos trust) pomiędzy tymi domenami.
Rozwiązania pokrewne zobacz na stronie: Zastosowanie przechodnich dwustronnych relacji zaufania 5.
Kliknąć domenę główną (root domain) prawym klawiszem myszki i wybrać opcję Zarządzaj (Manage). Uruchomiona zostanie przystawka (snap-in) Active Directory Użytkownicy i Komputery (Active Directory Users and Computers).
6.
Kliknąć prawym klawiszem myszki nazwę domeny. Możesz teraz np. dodać nową jednostkę organizacyjną (OU), jak przedstawiono to na rysunku 2.9.
Wszystko co można wykonać za pomocą interfejsu GUI, powinno się robić programowo lub w postaci skryptu. Active Directory zapewnia pełną automatyzację dodawania, zmian, przenoszenia, kopiowania i innych funkcji administracyjnych przez umiejętne posługiwanie się skryptami Visual Basica czy Javy.
Rysunek 2.9. Dodawanie jednostki organizacyjnej (OU)
Zastosowanie hierarchii kontenerów do modelowania organizacji Cecha hierarchii kontenerów (container hierarchy) Active Directory, pozwalająca na umieszczanie jednej jednostki organizacyjnej (OU) wewnątrz innej lub wewnątrz domen, daje w wyniku hierarchiczną przestrzeń nazw (hierarchical namespace), która może być zastosowana przez administratorów do odwzorowania struktury organizacji i przekazania uprawnień kontrolnych administratora. Zastosowanie hierarchii kontenerów (container hierarchy) z modelem bardziej precyzyjnego administrowania (finer-grained administrative model) rozwiązuje wiele problemów. Chociaż domeny mogą być duże, znalezienie w nich któregokolwiek elementu powinno być łatwe. Wszystko, co znajduje się w drzewie domen (domain tree), pojawia się w katalogu globalnym (global catalog). Istnieje usługa umożliwiająca użytkownikom proste odnalezienie dowolnego obiektu, niezależnie od tego, w której części drzewa lub lasu (forest) domen ten obiekt ten znajduje się.
Uzyskanie bardziej precyzyjnego administrowania Drzewa domen Active Directory oferują większą elastyczność administrowania aniżeli ma to miejsce w odniesieniu do struktury organizacji z pojedynczym drzewem. Chociaż Active Directory może zawierać domeny o strukturze pojedynczego drzewa (single-tree domains), to — ze względów bezpieczeństwa — lepiej jest utworzyć drzewo domen, z których każda ma własne bezpieczne granice (security boundaries). Hierarchia domen pozwala na bardziej precyzyjną kontrolę administracyjną, bez stwarzania zagrożeń ich bezpieczeństwu. Uprawnienia mogą być przekazywane w dół drzewa z użytkownikami, którym nadaje się uprawnienia (jak również nadając uprawnienia innym) na podstawie jednostek organizacyjnych (OU). Takie drzewo domen można przystosować do zmian struktury organizacji przez przycinanie gałęzi, przeszczepianie i scalanie. Każda z domen w drzewie ma kopię usługi katalogowej (directory service), zawierającą wszystkie obiekty dla tej domeny i metadane (metadata) drzewa domen, takie jak: schemat (schema), wykaz wszystkich domen w drzewie, lokalizacja serwerów katalogów globalnych (global catalog servers), itd. Ponieważ pojedynczy skład katalogu (directory store)nie musi zawierać wszystkich obiektów wszystkich domen można budować duże drzewa bez obniżania wydajności systemu. Usługi katalogowe Active Directory umożliwiają zdecentralizowane administrowanie bez narażania zabezpieczeń. Ponieważ każda z domen jest granicą zabezpieczeń (security boundary), tych granic może być wiele. W ten sposób, np. administratorzy domeny mojadomena.com nie są automatycznie administratorami domeny twojadomena.com. Hierarchia kontenerów (container hierarchy) jest ważna, ponieważ administrator domeny ma władzę nad każdym obiektem i usługą w tej domenie. Usługi katalogowe Active Directory nadają użytkownikom uprawnienia na podstawie specjalnych funkcji, które wykonują w określonym zakresie działania. Zakresem działania administratora (administrative scope) może być cała domena, poddrzewo jednostki organizacyjnej w danej domenie lub pojedyncza jednostka organizacyjna (OU). Wskazówka: Dokładna kontrola administracyjna (fine-grained administration) polega na edycji ACL i stosowaniu założeń grupowych (Group Policy). Można, np. mieć jednostkę organizacyjną o nazwie „sales" oraz adminstratora tej jednostki administracyjnej, który może nadawać prawa i uprawnienia użytkownikom tej domeny. Jednakże można ustawić takie warunki zabezpieczeń na poziomie domeny (domain level security conditions), który nie może być zmieniony przez administratora domeny „sales" i wymusić dziedziczenia tych warunków przez wszystkie jednostki organizacyjne w danej domenie. Np. administrator domeny „sales" może być w stanie nadać uprawnienia do korzystania z pliku lub foldera, ale nie może nadać użytkownikom prawa do logowania się lokalnie w kontrolerach domen. Administrator domeny „sales" nie posiada uprawnień administracyjnych w żadnej innej jednostce organizacyjnej.
Rozwiązania pokrewne zobacz na stronie: Zastosowanie edytora listy kontroli dostępu (Access Control List editor) Dostęp do założeń grupowych domeny lub jednostki organizacyjnej Ustanawianie dziedziczenia i zastępowanie zasad (override)
Korzystając z usług katalogowych Active Directory, można tworzyć rozbudowane struktury użytkowników. Potencjalnie każdy użytkownik może mieć dostęp do wszystkich informacji zapisanych w katalogu, ale granice zabezpieczeń pozostają wyraźne. Granice te (security boundaries) mogą być również dużo mniejsze niż domena, np. podczas tworzenia konta użytkownika, przypisuje się je do określonej domeny, ale można je także umieścić w jednostce organizacyjnej. Uprawnienie do tworzenia użytkowników w danej jednostce organizacyjnej (OU) może być przekazane komuś, kto mógłby tworzyć użytkowników lub inne obiekty katalogowe tylko w jednym miejscu, a prawa te obowiązują tylko w danej jednostce organizacyjnej. Dodatkowo można tworzyć hierarchie jednostek organizacyjnych. W Active Directory wprowadzono specjalne uprawnienia, każde z nich może być przekazane i każdemu można ograniczyć zakres stosowania.
Rozszerzanie usług katalogowych za pomocą schematu otwartego (extensible schema) Aby administratorzy mogli tworzyć własne typy obiektów katalogowych (directory object types), do Active Directory można wprowadzić nowe elementy za pomocą mechanizmu schematów (schema mechanism). Użytkownik, który chce opublikować w katalogu jakiekolwiek ważne dane, może utworzyć typ obiektu i opublikować go, np. hurtownik może utworzyć obiekt typu magazyn, aby umieścić go w jego katalogu, razem z informacjami właściwymi dla swojej działalności. Można też definiować nowe klasy obiektów i dodawać nowe obiekty. Szeroki zakres klas jest zdefiniowany przez same usługi katalogowe, np. w Active Directory są: standardowe obiekty dla klas domena (domain), jednostka organizacyjna, użytkownik (user), grupa (group), komputer (machine), wolumin (volume) i kolejka wydruku (printQueue), jak również zestaw obiektów punkt połączenia (connection point) wykorzystywanych przez Winsock, RPC i usługi modelu obiektowego składników rozproszonych (Distributed Component Object Model — DCOM), służące do publikowania informacji o powiązaniach (binding information).
Zastosowanie zabezpieczeń rozproszonych Razem z Active Directory w systemie Windows 2000 Server wprowadzono model zabezpieczeń rozproszonych (distributed security model), oparty na protokole uwierzytelniania Kerberos. Uwierzytelnianie za pomocą protokołu Kerberos jest stosowane do zabezpieczeń rozproszonych w granicach drzewa domen, a stosowane zabezpieczenia za pomocą klucza publicznego i prywatnego są zgodne z modelem obsługi ACL, jaki występuje w systemie operacyjnym Windows
2000. Active Directory jest składem (store) dla systemu zabezpieczeń (security system), łącznie z kontami użytkowników, grupami i domenami. Zastępuje bazę danych kont rejestru (registry account database) i jest elementem zaufanym w granicach lokalnej jednostki certyfikującej (Local Security Authority — LSA). Uwierzytelnienie metodą pojedynczego logowania (single sign-on) do drzewa domen Windows 2000 pozwala użytkownikom na dostęp do wszystkich zasobów znajdujących się w dowolnym miejscu sieci przedsiębiorstwa. Narzędzia administracyjne do zarządzania założeniami bezpieczeństwa (security policy) i kontami obniżają koszty wdrażania systemu Windows 2000, który daje również podstawy zintegrowanych zabezpieczeń programów z rodziny BackOffice, zawierającej Exchange, SQL Server, SNA Server oraz Systems Management Server. Protokół uwierzytelniania Kerberos 5 został rozszerzony, aby — oprócz uwierzytelniania na podstawie hasła i wspólnego uwierzytelniania (shared secret authentication) — można było dokonywać uwierzytelniania na podstawie klucza publicznego. Rozwiązania pokrewne zobacz na stronie: Ustanawianie połączenia za pomocą protokołu z kluczem tajnym (shared secret protocol) Uwierzytelnianie logowania Zastosowanie zabezpieczeń z kluczem publicznym systemu Windows 2000 Usługi katalogowe Active Directory do nadawania prawa dostępu do zasobów podmiotom, np. użytkownikom, które nie mają danych uwierzytelniających protokołu Kerberos, wykorzystują również certyfikaty z kluczem publicznym w standardzie X.509v3. Do tego rodzaju użytkowników należy zazwyczaj ktoś spoza firmy, komu potrzebny jest dostęp do zasobów firmowych, np. zakład produkcyjny może mieć poddostawców, którym potrzebny jest dostęp do specyfikacji, planów, itp. Active Directory pozwalają na przypisanie certyfikatu X.509v3 wydanego przez zaufaną jednostkę certyfikującą do grup zabezpieczonych (security groups) systemu Windows 2000. Tak więc użytkownikom spoza systemu Windows 2000, którzy mają certyfikat, można nadać prawo dostępu do zasobów w ten sam sposób, jak użytkownikom uwierzytelnionym za pomocą protokołu Kerberos.
Zastosowanie rozszerzenia ustawienia zabezpieczeń (security settings) edytora założeń grupowych (Group Policy editor) Jak już wcześniej wspomniano, rozszerzenie Ustawienia Zabezpieczeń (Security Settings) Edytora Założeń Grupowych (Group Policy Editor) można stosować do definiowania konfiguracji zabezpieczeń w granicach danego obiektu GPO (Group Policy Object). Założenia grupowe (Group
Policy) opisano szczegółowo w rozdziale 3., ale w tym miejscu omówione zostaną udogodnienia, które zapewnia interfejs GUI. Poniższe procedury przedstawiają tworzenie konsoli przygotowywanych według potrzeb administratora poprzez dodawanie przystawek (snap-in) konsoli MMC, sprawdzenie, czy uaktywniono rozszerzenie Założenia Grupowe — Ustawienia zabezpieczeń (Group Policy Security Settings) i zapisanie konsoli, w celu jej wykorzystania w przyszłości. 1.
Z menu Start wybierz Uruchom (Run) i wpisz polecenie mmc.
2.
Kliknij menu rozwijalne Konsola (Console).
3.
Kliknij Dodaj/Usuń przystawkę (Add/Remove snap-in). Pojawi się okno dialogowe Dodaj/Usuń przystawkę (Add/Remove snap-in).
4.
Kliknij Dodaj (Add). Pojawi się okno dialogowe Dodawaj samodzielną przystawkę (Add standalone snap-in).
5.
Z listy Dostępne samodzielne przystawki (Available standalone snap-in) wybierz Active Directory Użytkownicy i Komputery (Active Directory Users and Computers). Kliknij Dodaj.
6.
Wybierz Active Directory Lokacje i Usługi (Active Directory Sites and Services). Kliknij Dodaj (Add).
7.
Wybierz Założenia Grupowe (Group Policy). Kliknij Dodaj (Add).
8.
Pojawi się nowe okno. Upewnij się, czy dla przystawki Założenia Grupowe (Group Policy) wybrano opcję Komputer Lokalny (Local Computer), a następnie naciśnij przycisk Zakończ (Finish).
9.
Naciśnij Zamknij (Close).
10. Wybierz zakładkę Rozszerzenia (Extensions). Upewnij się, czy zaznaczono pole wyboru Dodaj wszystkie (Add all) dla każdej z przystawek dodanych do konsoli MMC (są wybrane domyślnie). W szczególności upewnij się, czy uaktywniono rozszerzenie Założenia grupowe — Ustawienie zabezpieczeń, jak przedstawiono na rysunku 2.10. 11. Naciśnij OK. 12. Wybierz Konsola\Zapisz (Console\Save). W celu wykorzystania konsoli w dalszej części niniejszego rozdziału i zapewnienia zgodności z opisem w rozdziale 3., zapisz konsolę pod nazwą GroupAD. Konsola powinna wyglądać podobnie jak na rysunku 2.11. Zauważ, że Założenia Grupowe (Group Policy) pojawiają się jako Założenia Komputera Lokalnego (Local Computer Policy), ponieważ dla przystawki (snap-in) Założenia Grupowe (Group Policy) w punkcie 8. wybrano opcję Komputer Lokalny.
Wskazówka: Domyślnie nowa konsola zapisana jest w folderze Narzędzia administracyjne (Administrative tools). Prostym sposobem uruchomienia tej konsoli jest wybór opcji menu Start\Programy\Narzędzia administracyjne (Start\Programs\Administrative Tools).
Rysunek 2.10. Upewnij się, że wybrano Założenia Grupowe Ustawienia Zabezpieczeń (Group Policy Security Settings)
Rysunek 2.11. Rozszerzenie Ustawienia Zabezpieczeń (Security Settings) przystawki Założenia Grupowe (Policy Settings snap-in) 13. Zbadaj wszystkie zabezpieczenia rozszerzając gałęzie Założenia Komputera Lokalnego (Local Computer Policy), Konfiguracja Komputera (Computer Configuration), Ustawienia Systemu Windows (Windows Settings) i Ustawienia Zabezpieczeń (Security Settings) jak przedstawiono to na rysunku 2.12. Można skonfigurować i przeanalizować następujące pozycje: •
Założenia Kont (Account Policies) — zawiera ustawienia zabezpieczeń dotyczące założeń haseł, zasad blokady kont (account lockout policies) i protokołu Kerberos,
•
Założenia Lokalne (Local Policies) — zawiera ustawienia zabezpieczeń dotyczące inspekcji (auditing), nadawania praw użytkownikom oraz opcje zabezpieczeń. Założenia Lokalne umożliwiają określenie, kto ma dostęp do danego komputera lokalnie lub poprzez sieć oraz w jaki sposób dokonuje się inspekcji zdarzeń lokalnych,
•
Założenia Klucza Publicznego (Public Key Policies) — wyszczególnia Agenty Odzyskiwania Danych Zaszyfrowanych (Encrypted Data Recovery Agents),
•
Założenia Zabezpieczeń Protokołu IP (IP Security Policies) na komputerze lokalnym — zawiera reguły Serwera (Żądaj zabezpieczeń) (Request security), właściwości Serwera
Bezpiecznego (Secure Server) Zabezpieczenia wymagane (Require security) oraz właściwości Klienta (Tylko odpowiada) (Respond only).
Rysunek 2.12. Ustawienia zabezpieczeń Założeń Komputera Lokalnego (Local Computer Policy), Konfiguracja Komputera (Computer Configuration)
Rysunek 2.13. Ustawienia zabezpieczeń Założeń Komputera Lokalnego (Local Computer Policy), Konfiguracja Użytkownika (User Configuration) 14. Rozszerz gałąź Konfiguracja Użytkownika (User Configuration), Ustawienia Systemu Windows (Windows Settings) i Szablony Administracyjne (Administrative Templates) jak przedstawiono to na rysunku 2.13. Ponadto prześledź dostępne udogodnienia. W tym miejscu można, np. skonfigurować menu Start użytkownika, Pasek Zadań (Taskbar), Pulpit (Tesktop) i Panel Sterowania (Control Panel). Elementy te nie zostaną tu opisane szczegółowo; ściślej mówiąc, nie należą one do zabezpieczeń, ponieważ zabezpieczenia użytkownika ustawia się na poziomie jednostki organizacyjnej (OU), a nie na poziomie domeny. Dlatego kontener Ustawienia Zabezpieczeń (Security Settings container) jest pusty. Zauważ, że, klikając prawym klawiszem myszki dowolną pozycję w lewej części okna, można wywołać Pomoc kontekstową (Context-sensitive help). 15. Zamknij konsolę. Nie zapisuj ustawień.
Analiza domyślnych ustawień kontroli dostępu Znaczna część zabezpieczeń systemu Windows 2000 jest definiowanych za pomocą domyślnych uprawnień dostępu wpisanych do ACL podczas instalacji lub, w przypadku kontrolerów domen, kiedy uruchamiany jest program dcpromo. Na stacji roboczej z systemem Windows 2000 Professional lub serwerze członkowskim Windows 2000 uprawnienia te są nadawane trzem grupom: Administratorom (Administrators), Zaawansowanym użytkownikom (Power Users) i Użytkownikom (Users). Na kontrolerach domen takimi grupami są: tak, jak poprzednio Administratorzy (Administrators) oraz Obsługujący serwer (Server Operators) i Użytkownicy zatwierdzeni (Authenticated Users). Grupa Użytkownicy zatwierdzeni (Authenticated Users) zawiera grupy: Account Operators i Print Operators oraz każdego użytkownika korzystającego z dostępu zdalnego do kontrolera domeny. Członkom grupy Użytkownicy zatwierdzeni (Authenticated Users) na kontrolerze domeny (DC) nadaje się te same uprawnienia kontroli dostępu, co członkom grupy Użytkownik (Users) na stacji roboczej lub serwerze członkowskim. Domyślne ustawienia zabezpieczeń stosuje się na początku instalacji w trybie graficznym (GUI — mode setup) podczas nowej instalacji systemu Windows 2000 lub w trakcie aktualizacji Windows 9x. Aktualizacja systemu Windows NT 4 nie powoduje zmiany ustawień zabezpieczeń. Ustawienia zabezpieczeń systemu plików mogą być stosowane tylko wtedy, gdy system Windows 2000 jest instalowany na partycji NTFS. Ponieważ zabezpieczenia dla składników opcjonalnych, takich jak Internet Information Server, wybranych w trakcie instalacji w trybie graficznym (GUI — mode setup) ustala się na początku instalowania w trybie graficznym (GUI — mode setup), to nie ma wyraźnie zdefiniowanych ustawień zabezpieczeń. Jeśli zabezpieczenia składników opcjonalnych są inne niż odziedziczone domyślnie, to składniki te są same odpowiedzialne za ustawienia swoich zabezpieczeń.
Ustawienia domyślne dla grupy użytkowników (Users) Domyślne ustawienia zabezpieczeń zaprojektowano po to, by powstrzymać użytkowników (członków grupy Users) przed potencjalnymi zagrożeniami integralności systemu operacyjnego i zainstalowanych aplikacji. Użytkownicy nie mogą zmieniać ustawień Rejestru, dotyczących całego komputera, plików systemowych ani plików programów. Nie mogą instalować programów, które mogłyby być uruchamiane przez innych użytkowników, aby uniknąć w ten sposób ukrytych niebezpieczeństw. Użytkownicy nie mają dostępu do prywatnych danych innych użytkowników. Teoretycznie, użytkownicy powinni umieć uruchamiać programy użytkowe, które wcześniej zostały zainstalowane przez członków grupy administratorzy, zaawansowani użytkownicy lub przez nich samych. W praktyce, powszechni użytkownicy nie będą w stanie uruchomić wielu starszych wersji programów użytkowych, ponieważ, tworząc tamte wersje programów, nie
uwzględniono zagadnień związanych z bezpieczeństwem. Możliwość uruchamiania takich programów powinni mieć członkowie grupy Power Users. Użytkownicy mogą uruchamiać programy użytkowe zgodne ze specyfikacją Windows 2000 Application Specification, którą można znaleźć pod adresem http://msdn.microsoft.com/winlogo/win2000.asp. Programy użytkowe, spełniające te wymagania, znajdują się w katalogu Windows 2000 Application Catalog (http://www.microsoft.com/windows/compatible). www.microsoft.com/windows/compatible). Microsoft Office 2000 i wersja programu Internet Explorer, która jest częścią Windows 2000 będą pracowały poprawnie w kontekście użytkownika (user context). Użytkownicy (członkowie grupy Users) nie mogą instalować programów użytkowych w wersji na komputer (per-machine), ponieważ nie mogą dokonywać zapisów do lokalizacji ogólnosystemowych (system wide locations). Jednak użytkownik może zainstalować program użytkowy w wersji dla użytkownika (per-user), pod warunkiem że instalator tego programu daje taką możliwość. Taki program użytkowy musiałby być zainstalowany w katalogu profilu użytkownika i mógłby modyfikować tylko ustawienia w kluczu Rejestru HKEY_CURRENT_USER oraz pozycje menu Start użytkownika. W ten sposób tylko użytkownik, który zainstalował dany program użytkowy, może go uruchomić. Jest to jedyny sposób na dopuszczenie do instalowania programów przez użytkowników, których wiarygodność nie została potwierdzona.
Ustawienia domyślne dla członków grupy Power Users Domyślne ustawienia zabezpieczeń systemu Windows 2000 dla zaawansowanych użytkowników (członków grupy Power Users) zapewniają zgodność wsteczną (backward compatibility) z domyślnymi ustawieniami zabezpieczeń dla użytkowników systemu Windows NT 4. W najlepszej sytuacji członkowie grupy Power Users powinni być w stanie wykonać dowolne zadanie niezwiązane z administrowaniem, czyli powinni zainstalować i odinstalować w wersji na komputer (per-machine) takie aplikacje, które nie rozmieszczają usług systemowych (system services). W rzeczywistości członkowie grupy Power Users nie mogą zainstalować starszych wersji programów użytkowych, które próbują w trakcie instalowania zamienić pliki systemowe. Członkowie grupy Power Users mogą dostosować zasoby systemowe (system wide resources), np. zegar systemowy, ustawienia ekranu, udziały (shares), konfigurację zasilania, drukarki, itp. do własnych potrzeb. Użytkownicy z grupy Power Users nie mają dostępu do danych innych użytkowników zapisanych na partycji NTFS. Ściślej mówiąc, członkowie grupy Power Users mogą: •
tworzyć użytkowników lokalnych i grupy lokalne,
•
modyfikować użytkowników i grupy, które stworzyli,
•
tworzyć i usuwać współużytkowane pliki nieadministracyjne,
•
tworzyć, zarządzać, usuwać i udostępniać drukarki lokalne,
•
zmieniać czas systemowy,
•
uruchamiać i zatrzymywać usługi, które nie są uruchamiane automatycznie.
Członkowie grupy Power Users mają następujące prawa dostępu: •
prawo modyfikowania (modify) — do katalogu Program Files,
•
prawo modyfikowania (modify) — do wielu lokalizacji znajdujących się w zakresie gałęzi Rejestru HKEY_LOCAL_MACHINES\Software,
•
prawo zapisu (write) — do większości katalogów systemowych, włącznie z %systemroot% i %systemroot%\system32.
Te uprawnienia pozwalają użytkownikom z grupy Power Users na instalowanie w trybie na komputer (per-machine) takich programów, które nie modyfikują plików systemowych Windows oraz umożliwiają uruchamianie starszych wersji aplikacji, które zapisują dane konkretnego użytkownika (per-user data) w lokalizacjach trybu na komputer (per-machine).
Grupy specjalne na kontrolerach domen Użytkownicy zatwierdzeni (członkowie grupy Authenticated User) na kontrolerze domeny mają takie same ograniczone uprawnienia domyślne, jak użytkownicy (członkowie grupy Users) w przypadku stacji roboczej czy serwera. Członkowie grupy Server Operators na kontrolerze domeny mają wszystkie prawa i uprawnienia dotyczące użytkowników zaawansowanych (członków grupy Power Users) na stacji roboczej lub serwerze. Jednak członkowie tej grupy mogą również zamieniać pliki systemowe Windows i z tego względu muszą to być użytkownicy całkowicie zaufani.
Ustawienia domyślne dla grupy administratorzy (Administrators) Standardowe ustawienia zabezpieczeń systemu Windows 2000 nie ograniczają dostępu administracyjnego do Rejestru ani do obiektów systemu plików. Członkowie grupy Administrators
mogą wykonywać wszystkie funkcje udostępnione przez system operacyjny, np.nadać samym sobie każde prawo, którego nie mają domyślnie. Oprócz praw i uprawnień nadanych członkom grupy Power Users, członkowie grupy Administrators mogą domyślnie wykonywać następujące zadania: •
instalacja systemu operacyjnego,
•
instalacja lub konfiguracja sterowników urządzeń,
Uwaga: Członkowie grupy Power Users mogą instalować sterowniki drukowania.
•
instalacja usług systemowych,
•
instalacja pakietów service pack, hotfix i aktualizacja systemu Windows,
•
aktualizacja systemu operacyjnego,
•
naprawa systemu operacyjnego,
•
instalacja aplikacji modyfikujących pliki systemowe systemu Windows,
•
konfiguracja zasad haseł (password policy),
•
konfiguracja zasad inspekcji (audit policy),
•
zarządzanie dziennikami zabezpieczeń (security logs),
•
tworzenie udziałów administracyjnych (administrative shares),
•
tworzenie kont administracyjnych,
•
modyfikowanie grup i kont utworzonych przez innych użytkowników,
•
zdalny dostęp do Rejestru,
•
uruchamianie lub zatrzymywanie każdej usługi,
•
konfigurowanie usługi,
•
zwiększanie zasobów dyskowych dostępnych dla użytkowników (quotas),
•
podnoszenie priorytetu wykonania,
•
zdalne zamykanie systemu,
•
przejmowanie prawa własności obiektów,
•
nadawanie praw użytkownikom,
•
pomijanie blokady komputera zablokowanego,
•
formatowanie dysku twardego,
•
modyfikowanie zmiennych środowiskowych obowiązujących w całym systemie,
•
dostęp do prywatnych danych innych użytkowników,
•
wykonywanie kopii zapasowych i odtwarzanie plików.
Wskazówka: Domyślne ustawienia zabezpieczeń systemu Windows 2000 można znaleźć w następujących miejscach:
Stacje robocze
%systemroot%\inf\defltwk.inf
Serwery członkowskie
%systemroot%\inf\defltsv.inf
Kontrolery domen
%systemroot%\inf\defltdc.inf
Analiza członkostwa w grupach domyślnych W systemie Windows NT 4 grupa Everyone używana była jako połączenie wszystkich list dostępu ACL systemu plików, list ACL Rejestru i praw użytkowników. Jeśli administratorowi potrzebna była dokładniejsza kontrola dostępu, musiał zmodyfikować domyślne ACL w ten sposób, by usunąć grupę Everyone, a dodać grupy, w których mógł kontrolować członkostwo. W systemie Windows 2000 zastosowano inne podejście. Grupy, takie jak Everyone i Użytkownicy zatwierdzeni, w których członkostwo jest automatycznie konfigurowane przez system operacyjny, zazwyczaj nie są używane do nadawania uprawnień. Zamiast tego korzysta się tylko z tych grup, w których członkostwo może być kontrolowane przez administratora — głównie są to grupy: Użytkownicy (Users), Użytkownicy zaawansowani (Power Users), Server Operators i Administratorzy (Administrators).
Uwaga: Istnieje kilka wyjątków, np. grupa Everyone używana jest do nadawania prawa do odczytu (read access) niektórych obiektów systemu plików i Rejestru w celu zachowania zgodności wstecznej (backward-compatibility) z niektórymi programami użytkowymi, które wymagają prawa do anonimowego odczytu (anonymous read access). Również korzysta się z grupy Interactive w ACL Service, do których dostęp zależy od tego, w jaki sposób jest się zalogowanym do systemu, a nie jako kto.
W tabeli 2.1. przedstawiono użytkowników, którzy domyślnie są członkami tych grup Domyślnie w przypadku komputerów z nową instalacją systemu Windows 2000 Professional lub Windows 2000 Server albo po aktualizacji systemu z wersji Windows 9x grupa Użytkowników zatwierdzonych (Authenticated Users) jest dodawana do grupy Użytkowników (Users). Grupa Użytkowników interaktywnych (Interactive Users) dodawana jest do grupy użytkowników Zaawansowanych (Power Users) tylko w systemie Windows 2000 Professional. Członkostwo w
grupach Użytkowników zatwierdzonych i Użytkowników interaktywnych (Interactive Users) jest kontrolowane automatycznie przez system operacyjny. Grupa Użytkowników zatwierdzonych jest taka sama, jak grupa Everyone, oprócz tego, że nie zawiera ona użytkowników anonimowych (anonymous users). W związku z tym domyślnie mają zastosowanie następujące zasady: •
każdy użytkownik — nie administrator, uzyskując dostęp do systemu Windows 2000 Server staje się automatycznie zwykłym użytkownikiem, członkiem grupy Users,
•
każdy użytkownik — nie administrator, uzyskując poprzez sieć dostęp do systemu Windows 2000 Professional staje się zwykłym użytkownikiem, członkiem grupy Users,
•
każdy użytkownik — nie administrator, uzyskując lokalnie dostęp do systemu Windows 2000 Professional staje się automatycznie członkiem grupy Power Users.
Tabela 2.1. Grupy używane do nadawania uprawnień Grupa lokalna Administrators
Domyślne członkostwo — stacja robocza Administrator
Domyślne członkostwo — serwer Administrator
Server Operators Power Users
Interactive Users
Users
Authenticated Users
Authenticated Users
Taka sytuacja zapewnia zgodność wsteczną (backward compatibility) systemu Windows 2000 Professional w zakresie ustawień kontroli dostępu. Ponieważ członkowie grupy Power Users systemu Windows 2000 mają te same uprawnienia dotyczące systemu plików i Rejestru, co członkowie grupy Users systemu Windows NT 4, to członkowie grupy Interactive Users w systemie Windows 2000 Professional powinni być w stanie uruchomić każdą aplikację, którą mogą uruchomić członkowie grupy Users w systemie Windows NT 4. Jednak zabezpieczenie stacji roboczej z systemem Windows 2000 jest obecnie zadaniem znacznie prostszym niż w przypadku wcześniejszych wersji systemu Windows NT. Zamiast modyfikacji wielu ACL systemu plików i Rejestru, po prostu usuwa się grupę Interactive Users z grupy Power Users. Po tej operacji użytkownicy — nie administratorzy po zalogowaniu się zostają członkami grupy Users, która automatycznie podlega surowym zasadom kontroli dostępu (access control policy). Domyślnie nikt nie jest członkiem grupy Power Users w systemie Windows 2000 Server po nowej instalacji lub aktualizacji systemu Windows 9x. W ten sposób użytkownicy lub konta usług (service accounts) logujący się do systemu Windows 2000 Server automatycznie znajdują się w środowisku bezpiecznym (secure environment) zwykłych członków grupy Users. Jeśli wymagana jest zgodność wsteczna z systemem Windows NT 4, to administrator musi podjąć specjalne działania i umieścić takie konta w mniej zabezpieczonej grupie Power Users. Na zakończenie, kiedy serwer członkowski (member server) lub stacja robocza są dołączane do domeny, grupy domen administratorów (domain Administrators) i domen użytkowników (domain Users) dodawane są odpowiednio do grup lokalnych Administrators i Users.
Przełączanie pomiędzy kontekstami użytkowników Administratorzy systemów powinni unikać logowania się na konto administratora przy wykonywaniu zadań niezwiązanych z administrowaniem systemem. Chroni to system przed wykonaniem jakiegoś programu, napisanego w złych zamiarach, w uprzywilejowanym kontekście zabezpieczeń (security contex). Najczęściej spotykanymi przypadkiem tego rodzaju jest pobieranie i uruchamianie programów z Internetu. Aby zachęcić administratorów do pracy w mniej uprzywilejowanym kontekście (least privileged context), system Windows 2000 zawiera poręczne narzędzie, które pozwala administratorom zalogować się jako użytkownik z grupy User lub Power User, a następnie uruchomić zaufane programy administracyjne w kontekście administracyjnym, bez konieczności wylogowania i ponownego zalogowywania się. Narzędzie to nazywa się runas.exe. Np., aby uruchomić okno poleceń w kontekście danego administratora, należy wprowadzić w oknie Uruchom (Run) następujące polecenie: RUNAS /user:administrator@yourdoamin cmd
Programy uruchamiane za pomocą tego okna poleceń odziedziczą znacznik dostępu (access token) tego okna. Program runas.exe jest również zintegrowany z powłoką (shell) systemu Windows 2000 (Eksplorator Windows — Windows Explorer), tak więc programy i skróty (shortcuts) do programów mogą być uruchamiane za pomocą interfejsu użytkownika w różnych kontekstach użytkowników (user’s context). Aby użyć programu runas.exe z poziomu powłoki (shell), należy wybrać program wykonywalny (executable) oraz nacisnąć Shift i prawy klawisz myszki.
Synchronizacja komputerów po aktualizacji systemu z domyślnymi ustawieniami zabezpieczeń Ponieważ zabezpieczenia komputerów po aktualizacji z systemu Windows NT nie są modyfikowane w trakcie instalowania systemu Windows 2000, domyślne ustawienia zabezpieczeń muszą być zmienione przez administratora po zakończeniu procesu instalacji. W przypadku stacji roboczych należy z katalogu %systemroot%\security\templates wpisać następujące polecenie:
Secedit /configure /cfg basicwk.inf /db basicwk.sdb /log basicwk.log /verbose
Dla serwerów domyślne ustawienia zabezpieczeń zdefiniowano w pliku basicsv.inf. Ponownie z katalogu %systemroot%\security\templates należy wprowadzić następujące polecenie: Secedit /configure /cfg basicsv.inf /db basicsv.sdb /log basicsv.log /verbose
Podstawowe pliki konfiguracyjne zmienią wszystkie domyślne ustawienia zabezpieczeń oprócz praw użytkownika (User Rights) i członkostwa w grupach Users i Power Users. Tak więc może wystąpić potrzeba dołączenia grupy Interactive Users do grupy Power Users po zastosowaniu szablonu podstawowego (basic templates). Uzyskanie domyślnych ACL systemu plików jest możliwe tylko dla systemu NTFS.
Zastosowanie przystawki (snap-in) Szablony Zabezpieczeń (Security Templates) Przystawkę (snap-in) Szablony Zabezpieczeń (Security Templates) można zastosować do poprawienia Szablonów Zabezpieczeń (Security Templates) dla grup użytkowników, grup komputerów oraz specjalnych ról komputera (computer roles). Narzędzie to można także wykorzystać do tworzenia nowych szablonów (templates), użyć do modyfikacji ustawień ACL, dodając i usuwając prawa i uprawnienia użytkowników i grup (user and group rights and permission) zarówno dla kont wbudowanych, jak i dla utworzonych. Aby zademonstrować zastosowanie takiego narzędzia w grupie „autorzy”(authors), która aktualnie ma jednego członka „i.mclean”, nadane zostanie prawo do zalogowania się lokalnie. W celu wypróbowania tej procedury samemu, należy wybrać na komputerze lub utworzyć zwykłą grupę użytkowników. Mniej oczywistym przykładem zastosowania przystawki Szablony Zabezpieczeń (Security Templates) jest zmiana praw dla członków grupy Power Users lub definiowanie domyślnych ustawień zabezpieczeń dla katalogu głównego (root directory) poprzez utworzenie odpowiednio plików defltwk.inf i defltsv.inf: 1.
Wybierz pozycję menu Start\Uruchom i wpisz polecenie mmc.
2.
Kliknij pozycję menu MMC Konsola (Console).
3.
Wybierz opcję menu Dodaj/Usuń przystawkę (Add/Remove snap-in).
4.
Naciśnij Dodaj (Add). Pojawi się okno dialogowe Dodaj samodzielną przystawkę (Add standalone snap-in).
5.
W polu listy (list box) Dostępne samodzielne przystawki (Available standalone snap-ins) wybierz Szablony Zabezpieczeń (Security Templates).
6.
Naciśnij Dodaj (Add), naciśnij Zamknij (Close) a potem naciśnij OK.
7.
Pojawi się przystawka Szablony Zabezpieczeń (Security Templates). Rozszerz przystawkę jak przedstawiono na rysunku 2.14.
8.
Kliknij prawym klawiszem myszki pozycję Logowanie Lokalne (Log on Locally). Wybierz opcję Bezpieczeństwo (Security).
9.
Wybierz opcję Definiuj te ustawienia zasad w szablonie (Define these policy settings in the template). Naciśnij Dodaj (Add).
10. Na rysunku 2.15 przedstawiono dodawanie grupy „autorzy” (authors). Można wybrać dowolną grupę zwykłych użytkowników tego komputera. 11. W każdym z okien dialogowych naciśnij OK. Zamknij konsolę bez zapisywania ustawień. 12. System zażąda zapisania poprawionego szablonu w katalogu %systemroot%\security\templates\dcsecurity.inf. Naciśnij OK.
Rysunek 2.14. Rozszerzenie przystawki (snap-in) Szablony Zabezpieczeń (Security Templates)
Rysunek 2.15. Zastosowanie ustawień szablonu do danej grupy
OSTRZEŻENIE! Ważnym jest, aby zrozumieć, co w rzeczywistości zostało zrobione. Zmieniono domyślne ustawienia szablonu, które po zastosowaniu pozwolą członkom grupy „autorzy" na logowanie się lokalnie do systemu, o ile założenia ustanowione na wyższym poziomie nie odbiorą tego prawa. W przypadku kontrolera domeny (DC) mogłyby to być założenia domeny (domain policy). W rozdziale 3. przedstawiono administrowanie założeniami domeny (domain policy). Narzędzie Szablony Zabezpieczeń (Security Templates) opisano szczegółowo w rozdziale 12.
Zdefiniowane wstępnie Szablony zabezpieczeń (security templates) Jak już wspomniano przy omawianiu przystawki Szablony Zabezpieczeń (Security Templates) dla najczęściej spotykanych zadań administracyjnych zdefiniowano zestaw szablonów zabezpieczeń. Można je stosować w takiej postaci, jak są lub modyfikować odpowiednio do wymagań dotyczących bezpieczeństwa systemu. Oto zestaw zdefiniowanych wstępnie szablonów zabezpieczeń: •
domyślny — stacja robocza (basicwk.inf),
•
domyślny — serwer (basicsv.inf),
•
domyślny — controler domeny (basicdc.inf),
•
zgodny — stacja robocza lub serwer (compatws.inf),
•
bezpieczny — stacja robocza lub serwer (securews.inf),
•
wysoki stopień bezpieczeństwa (highly secure) — stacja robocza lub serwer (hisecws.inf),
•
specjalizowany kontroler domeny (dedicadc.inf),
•
bezpieczny — kontroler domeny (securedc.inf),
•
wysoki stopień bezpieczeństwa (highly secure) — kontroler domeny (hisecdc.inf).
Domyślnie szablony te zapisane są w katalogu \%systemroot%\security\templates.
Poziomy zabezpieczeń Wymienione powyżej szablony zostały zaprojektowane, aby spełnić kilka grup wymagań w zakresie bezpieczeństwa: •
podstawowe (basic) (basic*.inf) — podstawowe dane konfiguracyjne dotyczą domyślnych ustawień zabezpieczeń dla wszystkich obszarów zabezpieczeń (security area), oprócz odnoszących się do praw użytkownika, które nie są modyfikowane w szablonach podstawowych, ponieważ programy instalacyjne aplikacji zazwyczaj modyfikują prawa użytkowników, aby umożliwić prawidłowe wykorzystanie takiej aplikacji,
•
zgodne (compatible) (compat*.inf) — jak opisano wcześniej zabezpieczenia systemu Windows 2000 są konfigurowane domyślnie w ten sposób, aby członkowie grupy lokalnej Users mieli doskonałe ustawienia zabezpieczeń, a członkowie grupy lokalnej Power Users mieli ustawienia zabezpieczeń zgodne wstecz z użytkownikami systemu Windows NT 4. Taka domyślna konfiguracja umożliwia pisanie aplikacji dla standardowej definicji środowiska
zabezpieczeń Windows, podczas gdy istniejące aplikacje nadal mogą działać poprawnie przy niższym poziomie zabezpieczeń grupy Power Users. Ustawienia dla grupy Power Users mogą być zbyt niepewne dla niektórych środowisk, w których lepiej byłoby, aby domyślnie użytkownicy byli członkami wyłącznie grupy Users. Dla takich środowisk przeznaczone są szablony zgodne (compatible templates), które, obniżając poziom zabezpieczeń określonych plików, folderów i kluczy Rejestru (do których najczęściej aplikacje mają dostęp), pozwalają większości aplikacji pracować poprawnie. Dodatkowo, ponieważ administrator, stosując szablon zgodny (compatible template), zapewne nie chce, aby użytkownicy byli członkami grupy Power Users, wszyscy członkowie tej grupy zostają usunięci, •
bezpieczne (secure) (secure*.inf) — szablony bezpieczne (secure templates) wprowadzają zalecane ustawienia zabezpieczeń dla wszystkich obszarów zabezpieczeń, oprócz plików, folderów i kluczy Rejestru. Ustawienia dla tych elementów nie są modyfikowane, ponieważ system plików i uprawnienia Rejestru są konfigurowane jako bezpieczne domyślnie,
•
wysoki stopień zabezpieczeń (highly secure) (hisec*.inf) — szablony wysokiego stopnia zabezpieczeń określają ustawienia zabezpieczeń systemu Windows 2000 dla komunikacji przez sieć. Obszary zabezpieczeń są ustawione w ten sposób, aby wymagały maksymalnej ochrony dla transmisji przez sieć i protokołów sieciowych stosowanych pomiędzy komputerami z systemem Windows 2000. W wyniku tego komputery, w których użyto szablonu wysokiego stopnia zabezpieczeń, mogą komunikować się tylko z innymi komputerami pracujacymi pod kontrolą systemu Windows 2000,
•
specjalizowane kontrolery domen (dedicated domain controllers) (dedica*.info) — kontrolery domen z zainstalowanym systemem Windows 2000 w przypadku zastosowania ustawień domyślnych nie są idealnie bezpieczni. Umożliwia to administratorowi uruchamiać na kontrolerach domen istniejące aplikacje, korzystające z serwerów, w taki sam sposób, jak we wcześniejszych wersjach Windows. Jeśli nie uruchamia się aplikacji korzystających z serwera na kontrolerze domeny (co jest zalecane przez Microsoft), domyślne uprawnienia systemu plików i Rejestru dla grupy lokalnej Users mogą być zdefiniowane w ten sam idealny sposób jak w przypadku stacji roboczych lub autonomicznych serwerów z systemem Windows 2000. Korzystając z tego szablonu wprowadza się dla użytkowników lokalnych kontrolera domeny Windows 2000 takie, idealne ustawienia zabezpieczeń.
Zastosowanie Edytora Listy Kontroli Dostępu (Access Control List editor) Zakładka Bezpieczeństwo (Security) edytora ACL obiektu założeń grupowych (GPO) znajduje się w oknie Właściwości (Properties) tego obiektu. Aby uruchomić Edytor ACL (ACL Editor) w przystawce (snap-in) MMC Założenia Grup (MMC Group Policy) kliknij prawym klawiszem myszki gałąź główną (root node) obiektu GPO, wybierz z menu pozycję Właściwości (Properties), a następnie wybierz zakładkę Bezpieczeństwo (Security). Strona ta służy do nadawania uprawnień do wybranego obiektu założeń grupowych (GPO). Za pomocą tych uprawnień, określonym grupom nadaje się prawo dostępu lub odmawia prawa dostępu do danego obiektu GPO. Procedura jest następująca:
1.
Z menu Start wybierz pozycję Uruchom (Run) i wpisz polecenie mmc.
2.
Wybierz pozycję menu MMC Konsola (MMC Console).
3.
Wybierz pozycję Dodaj/Usuń przystawkę (Add/Remove snap-in). Pojawi się okno dialogowe Dodaj/Usuń przystawkę (Add/Remove snap-in).
4.
Naciśnij Dodaj (Add). Pojawi się okno dialogowe Dodaj samodzielną przystawkę (Add standalone snap-in).
5.
W polu listy Dostępne samodzielne przystawki (Available standalone snap-in’s) wybierz Założenia Grupowe (Group Policy), a następnie naciśnij Dodaj (Add).
6.
Naciśnij Przeglądaj (Browse) i wybierz kontener Kontroler Domeny (Domain Controller), jak przedstawiono na rysunku 2.16. Naciśnij OK.
7.
Kliknij Domyślne Założenia Kontrolera Domeny (Default Domain Controllers Policy) prawym klawiszem myszki. Z menu wybierz Właściwości (Properties).
8.
Wybierz zakładkę Bezpieczeństwo (Security). Teraz masz dostęp do Edytora ACL (ACL Editor); zob. rysunek 2.17. Zauważ, że tytuł okna dialogowego nie podaje, że korzysta się z edytora ACL. Zamiast tego określa, co jest aktualnie edytowane.
Rysunek 2.16. Wybór kontenera Kontroler Domeny (Domain Controller)
Rysunek 2.17. Edytor Listy Kontroli Dostępu (Access Control List Editor) 9.
Zwróć uwagę na dostępne opcje. Naciśnij przycisk Zaawansowane (Advanced) i obejrzyj opcje zaawansowane. Na razie nic nie zmieniaj.
10. W każdym oknie dialogowym naciśnij OK. W oknie Wybierz obiekt założeń grupowych (Select Group Policy Object) naciśnij przycisk Zakończ (Finish). Zamknij okno dialogowe Dodaj samodzielną przystawkę (Add standalone snap-in), naciśnij OK. i wyjdź z przystawki. Jeśli chcesz, zapisz konsolę. Członkowie grupy Domain Administrators mogą również użyć edytora ACL (ACL Editor) do określenia, która grupa administratorów może modyfikować założenia (policies) w obiektach GPOs. Administratorzy sieci mogą zdefiniować grupy administratorów, np.Accounting Administrators, a następnie nadać im prawo odczytu-zapisu wybranych obiektów GPOs, przekazując w ten sposób kontrolę nad założeniami obiektów GPOs (GPO policies). Nadanie prawa odczytu-zapisu do obiektu GPO pozwala administratorom na kontrolę wszystkich elementów danego obiektu GPO.
Rozdział 3 Rozwiązania natychmiastowena stronie: Łączenie zasad grupowych (Group Policy) ze strukturą Active Directory Konfigurowanie przystawki Zarządzanie zasadami grupowymi (Group Policy Management) Tworzenie obiektu zasad grupowych (Group Policy Object) Edycja obiektu zasad grupowych Nadawanie użytkownikowi prawa do logowania się lokalnie (log -on locally) na kontrolerze domeny Zarządzanie zasadami grupowymi Dodawanie lub przeglądanie obiektu zasad grupowych Ustanawianie dziedziczenia i zastępowania (override) zasad grupowych Wyłączanie części obiektu zasad grupowych (GPO) Dołączanie obiektu zasad grupowych (GPO) do wielu lokacji (sites), domen i jednostek organizacyjnych (OUs) Administrowanie zasadami korzystającymi z Rejestru (registry-based policies) Przygotowywanie skryptów Ustawianie odpowiednich uprawnień dla poszczególnych członków grup zabezpieczeń (security group filtering) Dopasowanie zasad (policies) do danego komputera za pomocą przetwarzania sprzężenia zwrotnego (loopback processing) Konfigurowanie zasad inspekcji (audit policy)
W skrócie Możliwości zasad grupowych (Group Policy) i korzyści z ich stosowania Zasady grupowe w systemie Windows 2000 służą do określania ustawień poszczególnych użytkowników i komputerów, członków odpowiednich grup. W rozdziale 2. opisano krótko przystawkę (snap-in) konsoli MMC (Microsoft Management Console) Edytor Zasad Grupowych (Group Policy Editor), służącą do tworzenia konfiguracji właściwych dla danego komputera lub ustanawiania zasad grupowych (Group Policy) dla poszczególnych grup użytkowników i komputerów. Zasady grupowe (Group Policy) są zawarte w obiektach zasad grupowych (Group Policy Objects — GPOs). Obiekty te kontrolują zasady grupowe (Group Policies) dotyczące obiektów Active Directory, takich jak lokacje (sites), domeny czy jednostki organizacyjne (OUs), z którymi są związane. Za pomocą Edytora Zasad Grupowych (Group Policy Editor) można określić ustawienia dla następujących elementów: •
Zasady Oprogramowania (Software Policies) — w ich skład wchodzą ustawienia Rejestru dotyczących zasad grupowych (Group Policy) dla składników systemu Windows 2000 i aplikacji,
•
Skrypty (Scripts) — obejmują uruchamianie i zamykanie systemu oraz logowanie i wylogowywanie,
•
Opcje Zarządzania Oprogramowaniem (Software Management Options) — określają, które aplikacje są dostępne dla użytkowników. Dotyczy to zarówno aplikacji opublikowanych, (published applications) jak również takich, które są przypisane konkretnym komputerom,
•
Dokumenty i Ustawienia Użytkownika (User Documents and Settings) — stosowane do instalowania plików na komputerach, które są dostępne na danym komputerze lub tylko dla konkretnych użytkowników oraz służą do określenia folderów specjalnych, takich jak Moje dokumenty (My documents),
•
Ustawienia Zabezpieczeń (Security Settings) — stosowane są do określania środowiska pracy użytkownika lub grupy. System wyegzekwuje (enforce) zasady zdefiniowane za pomocą tych ustawień.
Stosowanie zasad grupowych (Group Policy) daje następujące korzyści: •
integracja z usługami Active Directory i korzystanie z narzędzi (facilities) systemowych Active Directory,
•
możliwość scentralizowanego lub zdecentralizowanego zarządzania opcjami zasad (policy options),
•
elastyczność oraz możliwości i stosowania wielu różnych scenariuszy implementacji zarówno dla małych przedsiębiorstw, jak i wielkich firm,
•
proste, zintegrowane narzędzia do zarządzania zasadami,
•
Edytor Zasad Grupowych (Group Policy Editor), przystawkę (snap-in) konsoli MMC, która jest rozszerzeniem innych narzędzi administracyjnych Active Directory, takich jak przystawki Menedżer Active Directory (Active Directory Manager), Menedżer Active Directory Lokacje i Usługi (Active Directory Site and Services Manager) oraz Zarządzanie Komputerem (Computer Management),
•
możliwość przekazania przez administratora kontroli nad GPO.
Można zróżnicować zasady grupowe, ustalając odpowiednio członkostwo w grupach zabezpieczeń i nadając odpowiednie uprawnienia na liście kontroli dostępu (Access Control List — ACL). Edytor Listy Kontroli Dostępu (ACL Editor) został krótko opisany w rozdziale 2., natomiast w niniejszym rozdziale edytor ten będzie omówiony dokładniej. Nadanie uprawnień ACL umożliwia szybkie przetwarzanie GPO i pozwala na zastosowanie zasad grupowych (Group Policy) do grup zabezpieczeń (security groups). Stosując listy kontroli dostępu i grupy zabezpieczeń, można modyfikować zakres GPO.
Zasady grupowe (Group Policy) a usługi Active Directory Zasady systemowe (system policies) są ustawieniami zapisanymi w Rejestrze, które określają zachowanie różnych składników systemu komputerowego. W systemie Windows NT 4 ustawienia dotyczące użytkowników i komputerów, dokonane za pomocą Edytora Zasad Systemowych (System Policy Editor), zapisane są w bazie danych Rejestru systemu Windows NT. Za pomocą Edytora Zasad Systemowych (System Policy Editor) można utworzyć zasady systemowe (System Policy) do kontrolowania środowiska pracy użytkownika i jego działań oraz narzucenia konfiguracji systemu. W systemie Windows 2000 wprowadzono Edytor Zasad Grupowych (Group Policy Editor), narzędzie, które rozszerza zakres funkcjonalny Edytora Zasad Systemowych (System Policy Editor) i daje większe możliwości konfigurowania ustawień dla poszczególnych elementów w grupach użytkowników i komputerów. Zasady grupowe określają różne składniki środowiska użytkownika, którymi mają zarządzać administratorzy systemu. Są to ustawienia dotyczące oprogramowania (Software Settings), opcje instalowania aplikacji, skryptów, ustawień dotyczących użytkowników, opcje dokumentów i ustawienia zabezpieczeń. Po określeniu ustawień zasad grupowych są one zapisywane w GPO, który z kolei jest związany z wybranym obiektem Active Directory (lokacja, domena lub jednostka administracyjna). Domyślnie zasady grupowe stosuje się do wszystkich komputerów i użytkowników w wybranym
kontenerze Active Directory. Jednak można filtrować (filter) zasady grupowe (Group Policy) oparte na członkostwie użytkowników lub komputerów w grupach zabezpieczeń systemu Windows 2000. Do filtrowania (filter) wpływów (effects) zasad grupowych (Group Policy) korzysta się ze standardowego Edytora Listy Kontroli Dostępu (ACL Editor). Można również za pomocą uprawnień znajdujących się na liście kontroli dostępu przekazać (delegować) korzystanie z Edytora Zasad Grupowych (Group Policy Editor). Na rysunku 3.1 przedstawiono relację pomiędzy zasadami grupowymi (Group Policy) a usługami Active Directory
Rysunek 3.1. Zasady grupowe (Group Policy) zastosowane do lokacji (sites), domen i jednostek organizacyjnych (OUs) Rozpatrując sytuację z rysunku 3.1, należy wziąć pod uwagę kilka czynników: •
lokacje (sites) są zdefiniowane przez adresy podsieci (subnet addresses) i mogą przekraczać granice domeny, chociaż zaleca się, by nie wykraczały poza nie
•
obiekty zasad grupowych (GPOs) są konfigurowane dla konkretnej domeny,
•
z jedną lokacją (site), domeną lub jednostką organizacyjną (OU) może być związanych wiele obiektów zasad grupowych,
•
wiele lokacji (sites), domen lub jednostek organizacyjnych może korzystać z jednego obiektu (GPO),
•
dowolna lokacja (site), domena lub jednostka organizacyjna może być związana z dowolnym obiektem zasad (GPO), nawet jeśli przekracza granicę domeny, chociaż przetwarzanie może być bardzo wolne,
•
wpływ obiektów (GPOs) może być filtrowany (filter) za pomocą ustawień na liście kontroli dostępu i przydzielania członków do grup zabezpieczeń.
Ustawienia dotyczące komputerów i użytkowników Podstawę przestrzeni nazw Edytora Zasad Grupowych (Group Policy Editor) stanowią dwie gałęzie macierzyste Ustawienia Komputera (Computer Settings) i Ustawienia Użytkownika (User Settings). Są to foldery nadrzędne używane przy konfigurowaniu specyficznych środowisk pracy komputera i wprowadzaniu zasad grupowych dla komputerów i użytkowników danej sieci. Ustawienia Komputera (Computer Settings) zawierają zasady określające działanie systemu operacyjnego, wygląd pulpitu, przypisane aplikacje, opcje instalowania plików, ustawienia zabezpieczeń oraz skrypty do uruchamiania i zamykania systemu. Zasady grupowe dotyczące komputera zaczynają działać w chwili inicjalizacji systemu operacyjnego. Ustawienia Użytkownika (User Settings) zawierają informacje dotyczące określonego użytkownika, takie jak działanie systemu operacyjnego, ustawienia pulpitu, ustawienia aplikacji, aplikacje przypisane i opublikowane, opcje instalowania plików, ustawienia zabezpieczeń i skrypty logowania i wylogowywania użytkownika. Zasady grupowe dotyczące użytkowników zaczynają działać w chwili, gdy dany użytkownik loguje się na komputerze. Można podać zasady grupowe (Group Policy), które będą dotyczyły wszystkich użytkowników określonego komputerów. Jest to przydatne w takich systemach komputerowych, np. szkolnych, w których należy skonfigurować komputer w określony sposób, ograniczając odpowiednio dostęp do zasobów, niezależnie od tego, który użytkownik loguje się do danego komputera (podobnie jak w przypadku profilów obowiązkowych w systemie Windows NT 4). Aby skonfigurować ustawienia użytkownika dla konkretnego komputera, należy skorzystać z gałęzi Zasady Oprogramowania (Software Policies) foldera Ustawienia Komputera.
Zarządzanie oprogramowaniem Do instalowania, przypisywania, publikowania, aktualizacji, naprawiania i usuwania oprogramowania dla grup użytkowników i komputerów można stosować gałąź Ustawienia Oprogramowania (Software Settings) Edytora Zasad Grupowych (Group Policy Editor). Aplikacje są przypisane do grup użytkowników, aby użytkownicy, korzystający z danej aplikacji, mieli ją automatycznie na swoich pulpitach. Przypisując daną aplikację do grupy użytkowników, w rzeczywistości ogłasza się ją (advertising) na pulpitach wszystkich użytkowników z tej grupy. Oznacza to, że skrót (shortcut) do aplikacji pojawi się w menu Start, a w Rejestrze znajdą się
informacje o lokalizacji pakietu aplikacji oraz lokalizacji plików źródłowych instalacji. Aplikacja zostanie zainstalowana, kiedy użytkownik uaktywni ją po raz pierwszy. Podane pliki są umieszczane na pulpicie albo w trakcie uruchamiania komputera, jeśli zostały określone w Ustawieniach Komputera (Computer Settings), albo gdy użytkownik zaloguje się na komputerze, jeśli zostały określone w Ustawieniach Użytkownika (User Settings). Pliki podane w Ustawieniach Komputera są dostępne dla wszystkich użytkowników danego komputera. Pliki podane w Ustawieniach Użytkownika są dostępne tylko dla konkretnego użytkownika, niezależnie na którym komputerze się zaloguje. Można również opublikować (publish) aplikację dla grupy użytkowników. Jeśli aplikacja zostanie opublikowana, na pulpitach użytkowników nie pojawią się skróty do tej aplikacji i nie będzie żadnych wpisów do Rejestru lokalnego. W celu zainstalowania aplikacji opublikowanej (published application) użytkownicy mogą wykorzystać narzędzie Dodaj/Usuń programy (Add/Remove programs), które zawiera listę aplikacji opublikowanych, dostępnych dla tych użytkowników.
Wskazówka: Ogłaszanie aplikacji (advertising applications) spotkało się z różnymi opiniami, ponieważ jest sprzeczne z przyjętą zasadą popierania dostosowywania środowiska pracy użytkownika do jego potrzeb. Z tego względu publikowanie aplikacji (publishing applications) może być uważane za lepsze rozwiązanie, ale wymaga nadania użytkownikom prawa dostępu do narzędzia Dodaj/Usuń programy (Add/Remove programs). Podjęcie decyzji przez administratora będzie częściowo zależne od doświadczenia użytkowników administrowanego przez niego systemu.
Zarządzanie oprogramowaniem pozwala administratorowi nadawać użytkownikom prawo dostępu do zasobów, które są im niezbędne do pracy i jednocześnie ograniczyć dostęp do najważniejszych aplikacji (np. do Eksploratora Windows) tylko dla wybranych grup.
Ustawienia Zabezpieczeń Rozszerzenie Ustawienia Zabezpieczeń (Security Settings), o którym wspomniano w rozdziale 2., jest używane do konfigurowania zabezpieczeń komputerów w granicach danego obiektu zasad grupowych (GPO). Konfiguracja taka jest zwarta w tym konkretnym obiekcie i jest częścią egzekwowania zasad grupowych. Rozszerzenie Ustawienia Zabezpieczeń interpretuje standardową konfigurację zabezpieczeń i wykonuje na drugim planie wszystkie konieczne operacje. W razie potrzeby można zmienić poszczególne ustawienia.
Skrypty Rozszerzenie Skrypty (Scripts) pozwala na podanie informacji, które skrypty mają pracować przy uruchamianiu lub zamykaniu komputera lub podczas logowania i wylogowywania się użytkowników. Nazwy skryptów i ich wiersze poleceń, w postaci kluczy i wartości Rejestru, zapisane są w pliku registry.pol.
Rozwiązania natychmiastowe Łączenie zasad grupowych (Group Policy) ze strukturą Active Directory Projektując strukturę Active Directory, należy brać pod uwagę sposób implementacji zasad grupowych (Group Policy) w danym systemie komputerowym. Sposób działania zasad grupowych zależy od zdefiniowanej struktury. Uwzględnienie zasad grupowych podczas projektowania Active Directory upraszcza implementację i administrowanie zasadami grupowymi. Zasady grupowe są stosowane dla obiektów (GPOs), które z kolei są związane z określonymi kontenerami Active Directory. Zasady grupowe (Group Policy) są przetwarzane hierarchicznie w następującej kolejności: lokacja (site) — domena — jednostka organizacyjna (OU). Kontener Active Directory, znajdujący się najbliżej danego komputera lub użytkownika, zastępuje zasady grupowe (Group Policy) ustanowione w nadrzędnym kontenerze Active Directory, o ile zasady te nie są ustanowione jako obowiązkowe za pomocą parametru Nie zastępuj (No override), co zostanie wyjaśnione w dalszej części niniejszego rozdziału. Domyślnie ustawienia zasad grupowych kumulują się i są dziedziczone z kontenerów macierzystych Active Directory — jest to działanie domyślne. Poza tym istnieją mechanizmy pozwalające na wyegzekwowanie zasad grupowych lub zablokowanie ich dla użytkowników i komputerów w lokacjach (sites), domenach lub jednostkach organizacyjnych (OUs). Natomiast, w celu osiągnięcia największej wydajności i ułatwienia pracy, stosowanie tych mechanizmów
powinno być ograniczone do minimum. Aby mieć dodatkową kontrolę do filtrowania skutków działania obiektów zasad grupowych (GPOs), można zastosować członkostwo komputerów lub użytkowników w grupach zabezpieczeń. Osiąga się to przez zmianę ACL obiektu zasad greupowych (GPO) tak, by dany obiekt miał wpływ tylko na członków określonej grupy zabezpieczeń. Stosowanie możliwości, które dają zasady grupowe (Group Policy) w różnych kombinacjach, pozwala na zaspokojenie różnorodnych potrzeb i dowodzi elastyczności zasad grupowych (Group Policy). W poniższych przykładach opisano, o czym trzeba pamiętać przy planowaniu zasad grupowych. Ostrzeżenie! Stosuj najprostszą kombinację możliwości, Które pozwolą utworzyc zasady grupowe (Group Policy) i rozważnie zaplanuj ich stosowanie. W przeciwnym razie zasady grupowe (Group Policy) będą trudne do zrozumienia i administrowania.
Konfigurowanie przystawki (snap-in) Zarządzanie Zasadami Grupowymi (Group Policy Management) Zasady grupowe są związane z usługami Active Directory i przystawka (snap-in) Zasady grupowe jest rozszerzeniem narzędzi do zarządzania Active Directory, korzystających z mechanizmu rozszerzania przystawki konsoli MMC. Przystawki (snap-ins) Active Directory ustalają zakres zarządzania zasadami grupowymi (Group Policy). Najczęściej spotykanym sposobem uzyskania dostępu do zasad grupowych jest użycie przystawki (snap-in) Active Directory Użytkownicy i Komputery (Active Directory Users and Computers), która służy do ustalenia zakresu zarządzania domenami i jednostkami organizacyjnymi. Do ustawienia zasięgu zarządzania dla lokacji (site) można użyć przystawki (snap-in) Active Directory Lokacje i Usługi (Active Directory Sites and Services). Obie przystawki usługi Active Directory znajdują się w menu Narzędzia administracyjne (Administration tools), ale dla wygody można utworzyć jedną wspólną konsolę niestandardową, zawierającą przystawki Active Directory Użytkownicy i Komputery, Active Directory Lokacje i Usługi oraz Zasady grupowe (Group Policy). Jeśli konsola została już utworzona zgodnie z opisem zamieszczonym w rozdziale 2., wystarczy ją po prostu załadować. W przeciwnym razie można ją utworzyć zgodnie z poniższym opisem.
Konfigurowanie konsoli niestandardowej
Aby skonfigurować konsolę niestandardową, należy wykonać następujące czynności: 1.
Z menu Start wybrać pozycję Uruchom (Run) i wpisać polecenie mmc.
2.
Wybrać pozycję Konsola|Dodaj/Usuń przystawkę (Console\Add/Remove snap-in). Pojawi się okno dialogowe Dodaj/Usuń przystawkę (Add/Remove snap-in).
3.
Nacisnąć Dodaj (Add). Pojawi się okno dialogowe Dodawanie przystawki autonomicznej (Add standalone snap-in).
4.
Z listy Dostępne przystawki autonomiczne (Available standalone snap-ins) wybrać Active Directory Użytkownicy i Komputery (Active Directory Users and Computers). Nacisnąć Dodaj (Add).
5.
Wybrać przystawkę Active Directory Lokacje i Usługi (Active Directory Sites and Services) i nacisnąć przycisk Dodaj (Add).
6.
Wybrać przystawkę Zasady Grupowe (Group Policy) i nacisnąć przycisk Dodaj (Add).
7.
Na żądanie systemu należy upewnić się, że przystawka Zasady Grupowe (Group Policy) ma wybraną opcję Komputer Lokalny (Local Computer), a następnie nacisnąć przycisk Dodaj (Add).
8.
Nacisnąć przycisk Zamknij (Zlose).
9.
Wybrać zakładkę Rozszerzenia (Extensions). Upewnić się, że dla każdego rozszerzenia podstawowego, dodanego do konsoli MMC, zaznaczono pole wyboru Dodaj wszystkie rozszerzenia (Add all extensions). Nacisnąć przycisk OK.
10. Wybrać pozycję menu Konsola\Zapisz (Console\Save) i zapisać konsolę. Aby zachować zgodność z opisem tworzenia konsoli z rozdziału 2. i móc korzystać z tej konsoli w dalszej części niniejszego rozdziału, trzeba zapisać konsolę jako GroupAD. Konsola ta powinna wyglądać podobnie do tej, zamieszczonej na rysunku 3.2.
Wskazówka: Domyślnie nowa konsola zapisywana jest w folderze Narzędzia administracyjne (Administrative tools). Za pomocą menu Start\Programy\Narzędzia administracyjne (Start\Programs\Administrative tools) można łatwo uzyskać dostęp do danej konsoli.
Rysunek 3.2. Konsola Zasady Grupowe i Active Directory (Group Policy and Active Directory)
Dostęp do zasad grupowych domeny lub jednostki organizacyjnej W tej części rozdziału korzysta się z konsoli Zasady Grupowe i Active Directory (Group Policy and Active Directory) utworzonej w poprzedniej części i zapisanej pod nazwą GroupAG. Można również użyć przystawki Active Directory Użytkownicy i Komputery (Active Directory Users and Computers), która jest dostępna w menu Narzędzia administracyjne (Administrative tools). Aby uzyskać dostęp do zasad grupowych (Group Policy) domeny lub jednostki organizacyjnej (OU), należy postępować zgodnie z poniższym opisem: 1.
Otworzyć konsolę GroupAD: Z menu Start|Programy|Narzędzia administracyjne (Start\Programs\Administrative tools) wybrać pozycję GroupAD.
2.
Rozwinąć drzewo, klikając znak + przy pozycji Active Directory Użytkownicy i Komputery (Active Directory Users and Computers).
3.
Rozwinąć domenę główną (root domain).
4.
Kliknąć domenę lub jednostkę organizacyjną (OU) prawym przyciskiem myszki i z menu wybrać pozycję Właściwości (Properties).
5.
W oknie dialogowym Właściwości (Properties) wybrać zakładkę Zasady Grupowe (Group Policy). Pojawi się strona Zasady Grupowe Właściwości (Group Policy Properties) (rysunek 3.3), która służy do zarządzania obiektami zasad grupowych (GPOs) związanymi z wybranym kontenerem. Strona ta umożliwia dodawanie, usuwanie, wyłączanie, wybór opcji Nie zastępuj (No override) i zmianę kolejności skojarzonych obiektów (GPO). Umożliwia również edycję obiektów zasad grupy (GPOs). Strona Zasady Grupowe Właściwości jest szeroko stosowana do zarządzania zasadami grupowymi, a więc do ustanawiania zabezpieczeń jednostek organizacyjnych i domen. Strona ta będzie kilkakrotnie przywoływana w niniejszym rozdziale.
Rysunek 3.3. Strona Zasady Grupowe Właściwości (Group Policy Properties) służąca do zarządzania obiektami zasad grupowych (GPOs)
Uwaga: Kontenery Komputery (Computers) oraz Użytkownicy (Users) nie są jednostkami organizacyjnymi (OUs) i nie stosuje się do nich bezpośrednio zasad grupowych (Group Policy). Dla użytkowników i komputerów z tych kontenerów stosuje się zasady (policies) z obiektów zasad grupy (GPOs), które dotyczą tylko obiektów domen i lokacji (sites). Kontener kontrolera domeny (na rysunku 3.3 jest to coriolis.com) jest jednostką organizacyjną (OU) i zasady grupowe mogą być stosowane do niego bezpośrednio. Komputery, użytkownicy i grupy mogą być umieszczane w jednostkach organizacyjnych specjalnie w tym celu utworzonych i wówczas zasady grupowe mogą być stosowane do tych jednostek organizacyjnych.
Tworzenie obiektu zasad grupowych (Group Policy Object) Zasady grupowe zawarte są w Obiektach Zasad Grupowych (Group Policy Object — GPOs), które z kolei są związane z wybranymi obiektami Active Directory, takimi jak lokacje (sites), domeny lub jednostki organizacyjne (OUs). Poniżej opisano tworzenie obiektu zasad grupy (GPO) dla poddomeny lub jednostki organizacyjnej (OU) w domenie głównej (root domain). Aby utworzyć obiekt zasad grupy (GPO), należy: 1.
Otworzyć konsolę MMC GroupAD w sposób opisany powyżej.
2.
Rozwinąć przystawkę Active Directory Użytkownicy i Komputery (Active Directory Users and Computers), a następnie rozwinąć domenę główną (root domain).
3.
Kontynuować rozwijanie drzewa, dopóki nie zostanie odnaleziona jednostka organizacyjna (OU) lub domena, dla której chceym utworzyć zasady grupowe (Group Policy).
4.
Kliknąć ten obiekt, a następnie z menu wybrać pozycję Właściwości (Properties).
5.
Na stronie Właściwości (Properties) wybrać zakładkę Zasady Grupowe (Group Policy). Tak, jak w poprzedniej procedurze, należy przejść do strony Zasady Grupowe Właściwości (Group Policy Properties) wybranego obiektu Active Directory.
6.
Nacisnąć przycisk Nowy (New).
7.
Wpisać nazwę obiektu zasad grupy (GPO). Powinno pojawić się okno dialogowe Zasady Grupowe Właściwości (Group Policy Properties), które przedstawiono na rysunku 3.4. Nacisnąć przycisk Zamknij (Close).
8.
Dodać kilka obiektów zasad grupowych (GPOs), aby otrzymać listę takich obiektów. Konsekwencje, jakie pociąga za sobą określona kolejność obiektów na liście, są omówione w dalszej części niniejszego rozdziału.
9.
Teraz można zredagować utworzony właśnie obiekt zasad grupowych (GPO). Naciśnięcie przycisku Edytuj (Edit) uruchomi przystawkę (snap-in) Zasady Grupowe (Group Policy) dla danego obiektu zasad grupy (jego opis znajduje się w następnym akapicie). Funkcje zasad grupowych pochodzą z rozszerzeń przystawki (snap-in extensions). Domyślnie wszystkie rozszerzenia są aktywne. Można ograniczyć rozszerzenia, które są umieszczane w każdej przystawce (snap-in), za pomocą gałęzi System\Zasady Grupowe (System\Group Policy) w folderze Szablony Administracyjne (Administrative Templates). Korzystając z zakładki Wyjaśnianie (Explain), można dowiedzieć się więcej na temat stosowania tych zasad (policies).
10. Jeśli posiada się więcej obiektów zasad grupowych (GPOs), skojarzonych z danym folderem Active Directory, należy sprawdzić ich kolejność. Obiekt zasad grupy, który jest najwyżej na liście, ma najwyższy priorytet, ponieważ jest przetwarzany jako ostatni. Dany obiekt zasad grupy ma swoje miejsce w hierarchii obiektów i — do uzyskania oraz modyfikacji informacji ogólnych o tym obiekcie — można skorzystać z jego menu kontekstowego. Informacjami tymi są ustawienia poufnych list kontroli dostępu (Discretionary Access Control List — DACL) oraz inne lokacje (sites), domeny lub jednostki organizacyjne, z którymi połączony jest dany obiekt zasad grupowych (GPO). Obiekt ten może być bardziej precyzyjny, jeśli użytkownicy lub komputery będą członkami grupy zabezpieczeń (security group), w wyniku czego moża otrzymać odpowiednie ustawienia na listach kontroli dostępu (ACL). Sytuacja ta została opisana w dalszej części niniejszego rozdziału, w punkcie „Filtrowanie ustawień w grupach zabezpieczeń”. 11. Teraz można wypróbować możliwości edycji obiektu zasad grup (GPO) według sposobu opisanego poniżej lub zamknąć przystawkę MMC.
Rysunek 3.4. Dodawanie obiektu zasad grupowych (Group Policy Object)
Edycja obiektu zasad grupowych Przed dokonaniem edycji obiektu zasad grupowych (GPO) należy upewnić się, czy nie jest on związany z innymi obiektami w drzewie domen, na które zmiany mogłyby mieć niepożądany wpływ. Kolejna procedura opisuje, w jaki sposób edytować dany obiekt zasad grupowych i zmienić ustawienia hasła w gałęzi Założenia Komputera (Computer Policies): 1.
Jeśli nie jest to kontynuacja poprzedniej procedury, należy powtórzyć opisane powyżej czynności 1 – 5, a następnie nacisnąć przycisk Edycja (Edit).
2.
Rozwinąć gałąź Konfiguracja Komputera (Computer Configuration).
3.
Rozwinąć gałąź Konfiguracja Użytkownika (User Configuration). Ekran powinien wyglądać, jak na rysunku 3.5.
4.
W gałęzi Konfiguracja Komputera rozwinąć gałąź Ustawienia Systemu Windows (Windows Settings).
5.
Rozwinąć gałąź Ustawienia Zabezpieczeń (Security Settings), a następnie rozwinąć Zasady Kont (Account Policies). Wybrać Zasady Haseł (Password Policy).
6.
Prawym klawiszem myszki kliknąć opcję Maksymalny okres ważności hasła (Maximum password age), a następnie kliknąć Zabezpieczenia (Security).
7.
Zaznaczyć pole wyboru Definiuj następujące ustawienia zasad (Define this policy setting).
8.
Ustawić parametr Maksymalny okres ważności hasła (Maximum password age), jak przedstawiono na rysunku 3.6.
9.
Naciśnąć OK.
10. Aby przyjąć sugerowane ustawienia Minimalny okres ważności hasła (Minimum password age), należy nacisnąć OK i zamknąć Edytor Zasad Grupowych (Group Policy Editor). Zamknąć konsolę GroupAD.
Rysunek 3.5. Edytor Założeń Grupowych (Group Policy Editor)
Rysunek 3.6. Zastosowanie Edytora Zasad Grupowych (Group Policy Editor) do ustanawiania zasad hasła (Password Policy)
Nadawanie użytkownikowi prawa do logowania się lokalnie (log on locally) na kontrolerze domeny W rozdziale 2. przystawka (snap-in) MMC Szablony Zabezpieczeń (Security Templates) używana była do tworzenia szablonu dla grupy „autorzy” (authors), który zawiera prawo Logowanie lokalne (Log on locally). Jednakże — w większości zasad zabezpieczeń (security policies) — jest to raczej prawo komputerów niż użytkowników. Szablon ma zastosowanie do obiektu lub obiektów zasad grupy (GPOs) kontrolujących zasady (policies) jednostki organizacyjnej (OU), w której ta grupa jest umieszczona. W przypadku kontrolera domeny (DC) sprawa wygląda jednak trochę inaczej. Prawo Logowanie lokalne musi mieć zastosowanie do obiektu zasad grupy (GPO) Domyślni Kontrolerrzy Domeny (Default Domain Controllers), który jest obiektem zasad grupy najwyższego poziomu (highest level GPO) w danej domenie. Prawo to można nadać zwykłemu użytkownikowi lub grupie z dowolnej części domeny. Oczywiście nadawanie zwykłemu użytkownikowi lub grupie użytkowników prawa Logowanie lokalne w kontrolerze domeny nie jest dobrą zasadą. Zwykle tacy użytkownicy zostaliby dodani do grupy, takiej jak obsługujący serwer (server operators), po czym przestaliby być zwykłymi użytkownikami. Jednakże do wypróbowania takich procedur na pojedynczym komputerze trzeba mieć możliwość logowania się jako zwykły użytkownik, aby testy były wykonywane w odpowiednim kontekście. Jeśli w danej domenie nie ma zwykłych użytkowników, należy utworzyć takie konto przed rozpoczęciem kolejnej procedury. Jednocześnie nie ma znaczenia, w jakiej jednostce organizacyjnej (OU) znajdzie się to konto. Kolejno należy: 1.
Uruchomić konsolę GroupAG i przejść do strony Zasady Grupowe Właściwości (Group Policy Properties) obiektu Kontrolerzy Domeny (Domain Controllers).
2.
Zaznaczyć obiekt zasad grupy (GPO) Zasady Domyślnych Kontrolerów Domeny (Default Domain Controllers Policy) i naciśnąć przycisk Edycja (edit).
3.
Rozwinąć gałęzie Konfiguracja Komputera (Computer Configuration), Ustawienia Systemu Windows (Windows Settings), Ustawienia Zabezpieczeń (Security Settings) i następnie Zasady Lokalne (Local Policies).
4.
Kliknąć Przypisywanie Praw Użytkownika (User Rights Assignment).
5.
Kliknąć dwukrotnie Logowanie Lokalne (Log on Locally).
6.
W razie potrzeby trzeba zaznaczyć pole wyboru Definiuj następujące ustawienia zasad (Define these policy settings).
7.
Nacisnąć Dodaj (Add), Przeglądaj (Browse) i wybrać użytkownika.
8.
Nacisnąć Dodaj (Add). Powinno pojawić się okno podobne do przedstawionego na rysunku 3.7.
9.
Naciskć OK, aby zamknąć każde okno dialogowe. Następnie zamknąć przystawkę (snapin) Zasady Grupowe (Group Policy).
10. Nacisnąć OK, aby zamknąć stronę Zasady Grupowe Właściwości (Group Policy Properties). 11. Na konsoli GroupAD rozwinąć gałąź Zasady Komputera Lokalnego (Local Computer Policy) i powtórz czynności 3 – 9. Dzięki temu użytkownik uzyska prawo do logowania lokalnego, oprócz domyślnych praw kontrolera domeny.
Rysunek 3.7. Dodawanie użytkownikowi prawa Logowanie Lokalne (Log on Locally)
Zarządzanie zasadami grupowymi Do zarządzania zasadami grupowymi (Group Policy) konieczny jest dostęp do menu kontekstowego (context menu) lokacji (site), domeny lub jednostki organizacyjnej (OU). Można to zrobić za pomocą strony Zasady Grupowe Ełaściwości (Group Policy Properties). Większość funkcji dostępnych na tej stronie zostanie opisanych szczegółowo w dalszej części niniejszego rozdział, ale stosowne będzie zamieszczenie tu skrótu. Na stronie Zasady Grupowe Właściwości przedstawiono wszystkie obiekty zasad grupowych (GPOs), które zostały skojarzone lub połączone (linked) z bieżącą lokacją (site), domeną lub jednostką organizacyjną (OU). Łącza (links) są obiektami i jako takie mają menu kontekstowe (context menu), które pojawi się po kliknięciu obiektu prawym klawiszem myszki. Kliknięcie prawym klawiszem na białym miejscu spowoduje wyświetlenie menu kontekstowego (context menu) do tworzenia nowego łącza (link), dodawania łącza lub odświeżania listy. Lista jest uporządkowana w ten sposób, że obiekt zasad grupowych (GPO) o najwyższym priorytecie znajduje się najwyżej. Uporządkowanie obiektów zasad grupowych (GPOs) można zmienić wybierając Obiekt Zasad Grupy, a następnie naciskając przyciski Góra (Op) lub Dół (Down). W celu skojarzenia (połączenia) nowego obiektu, naciśnij przycisk Dodaj (Add). Aby edytować obiekt zasad grupy (GPO), znajdujący się na liście, wybierz goi naciśnij przycisk Edytuj (Edit) lub kliknij ten obiekt dwukrotnie. W ten sposób zostanie uruchomiona przystawka (snap-in) Zasady Grupowe, za pomocą której można modyfikować dany obiekt zasad grupowych. Edytowanie obiektu zasad grupy opisano w poprzednim akapicie. Aby trwale usunąć z listy obiekt zasad grupowych (GPO), zaznacz go i naciśnij przycisk Usuń (Delete). Wybierz opcję Usuń trwale łącze i obiekt zasad grupy (Remove the link and delete the Group Policy Object permanently), a następnie naciśnij przycisk OK. Przy usuwaniu obiektu należy zachować ostrożność, ponieważ dany obiekt zasad grupy (GPO) może być skojarzony z inną lokacją (site), domeną lub jednostką organizacyjną (OU). Jeśli chcesz jedynie usunąć obiekt zasad grupy z listy dla zaznaczonego obiektu, wybierz opcję Usuń łącze z listy (Remove the link from the list). Chcąc określić, jakie inne lokacje (sites), domeny lub jednostki administracyjne są skojarzone z danym obiektem zasad grupy (GPO), kliknij opcję Właściwości (Properties), wybierz zakładkę Łącza (Links), a następnie naciśnij przycisk Znajdź (Find now). Można również wyłączyć część obiektu zasad grupy (GPO) Użytkownik (User) lub Komputer (Computer). Opcje wyłączania podanych części znajdują się w zakładce Ogólne (General) okna Obiekt Zasad Grupy Właściwości (GPO Properties). Zaznaczenie pola wyboru Zablokuj dziedziczenie zasad (Blok policy inheritance) anuluje ustawienia wszystkich obiektów zasad grupy (GPOs) znajdujących się wyżej w hierarchii obiektów. Jednakże nie są blokowane żadne obiekty zasad grupowych (GPOs), które mają ustawioną opcję Nie zastępuj (No override) — one zawsze są stosowane. Opcję Nie zastępuj (No override) można ustawić, klikając dwukrotnie wybrany obiekt zasad grupy (GPO) znajdujący się w kolumnie Nie zastępuj (No override) lub klikając dwukrotnie dany obiekt zasad grupy (GPO) i wybierając opcję Nie zastępuj (No override).
Dodawanie lub przeglądanie obiektu zasad grupowych Poprzednio, aby dodać nowy obiekt zasad grupowych (GPO), trzeba było nacisnąć przycisk Nowy (New), dlatego mogło pojawić się pytanie, do czego służy przycisk Dodaj (Add). Po naciśnięciu przycisku Dodaj pojawi się okno dialogowe Dodawanie łącza obiektu zasad grup (Add a Group Policy Object Link), które przedstawia obiekty zasad grupowych (GPOs) aktualnie skojarzone z domenami, jednostkami organizacyjnymi (OUs) i lokacjami (sites) lub wszystkie obiekty zasad grupowych (GPOs), bez względu na ich aktualne skojarzenia (łącza). To okno dialogowe, przedstawione na rysunku 3.8, może służyć do dodawania i przeglądania obiektów zasad grupy (GPOs) i często jest nazywane oknem dialogowym Dodawanie/Przeglądanie (Add/Browse).
Rysunek 3.8. Okno dialogowe Dodawanie Łącza Obiektu Zasad Grupy (Add a Group Policy Object Link) Okno to ma kilka funkcji:
•
w zakładce Domeny\Jednostki organizacyjne (Domains\OUs) przedstawione są jednostki organizacyjne niższego rzędu (sub-OUs) i obiekty zasad grupowych (GPOs) wybranej domeny lub jednostki organizacyjnej (OU). Aby poruszać się w hierarchii, należy kliknąć dwukrotnie jednostkę organizacyjną niższego rzędu (sub-OU) lub skorzystać z opcji Zobacz (Look) pola rozwijalnego (drop-down box),
•
aby dodać obiekt zasad grupy (GPO) do wybranej aktualnie domeny lub jednostki organizacyjnej (OU), należy kliknąć dwukrotnie obiekt zasad grupy lub zaznaczyć go i nacisnąć przycisk OK,
•
aby utworzyć nowy obiekt zasad grupy (GPO), należy wybrać zakładkę Wszystkie (All) i kliknąć prawym klawiszem myszki w wolnym miejscu lub użyć przycisku z paska narzędzi Tworzenie nowego Obiektu Zasad Grupy (Create new GPO). Przycisk ten jest aktywny tylko w zakładce Wszystkie (All). Do utworzenia nowego obiektu zasad grupowych i połączenia go z konkretną lokacją (site), domeną lub jednostką organizacyjną (OU) służy przycisk Nowy (New) na stronie Zasady Grupowe Właściwości (Group Policy Property),
•
wszystkie obiekty zasad grupowych (GPOs) skojarzonych z wybraną lokacją (site) wyświetlono na stronie zakładki Lokacje (Sites). Lista rozwijalna służy do wybrania innej lokacji (site). Nie ma hierarchii lokacji,
•
zakładka Wszystkie (All) przedstawia listę wszystkich obiektów zasad grupy (GPOs) zapisanych w wybranej domenie. Jest ona przydatna, gdy trzeba wybrać obiekt zasad grupowych (GPO) na podstawie jego nazwy, a nie na podstawie jego miejsca w drzewie domeny. Jest to także jedyne miejsce, w którym można utworzyć obiekt zasad grupowych, który nie ma połączenia z lokacją (site), domeną czy jednostką organizacyjną (OU). Aby to zrobić, kliknij prawym klawiszem myszki w wolnym miejscu i wybierz opcję Nowy (New). Nadaj nazwę nowemu obiektowi zasad grupowych i naciśnij Enter. Następnie naciśnij Anuluj (Cancel) — nie naciskaj OK. Naciśnięcie przycisku OK. łączy nowy obiekt zasad grupy (GPO) z aktualną lokacją (site), domeną lub jednostką administracyjną. Naciśnięcie przycisku Anuluj (Cancel) tworzy niepołączony obiekt zasad grupowych.
Wskazówka: Kliknięcie prawym klawiszem myszki w wolnym miejscu, aby uzyskać dostęp do odpowiedniego menu kontekstowego (incontext menu), jest metodą prawie powszechnie stosowaną w konsolach MMC. Jest ona zwykle szybsza i prostsza niż poszukiwanie na pasku narzędzi przycisku, który może nie istnieć.
Ustanawianie dziedziczenia i zastępowania (override) zasad grupowych
W rozdziałach 1. i 2. krótko omówiono dziedziczenie i wyjaśniono, że jednostka organizacyjna (OU) może dziedziczyć właściwości jednostki organizacyjnej znajdującej się wyżej w strukturze drzewa — lub, dokładniej, obiektów zasad grupowych (GPOs), skojarzonych z daną jednostką organizacyjną. Jednak takie dziedziczenie pomiędzy jednostkami organizacyjnymi (OUs) może być zablokowane. Są również dostępne narzędzia dla administratora, które służą do wymuszania dziedziczenia wybranych zasad (policies). Funkcje Zablokuj dziedziczenie zasad (Block policy inheritance) i Nie zastępuj (No override) pozwalają uzyskać kontrolę nad domyślnymi regułami dziedziczenia.Aby wypróbować te funkcje, najpierw utwórz w swojej domenie dwie jednostki organizacyjne: nadrzędną (parent) jednostkę organizacyjną pod nazwą Nadrzędna (Parent) i podrzędną w stosunku do tej jednostki organizacyjnej, pod nazwą Podrzędna (Child). Tworzenie jednostek organizacyjnych zostało opisane w rozdziale 2. Można również skorzystać z istniejących w danej domenie jednostek organizacyjnych, znajdujących się w relacji Nadrzędna/Podrzędna. Rozwiązania pokrewne zobacz na stronie Możliwości rozbudowy W poniższym ćwiczeniu utworzone zostaną dwa obiekty zasad grupowych (GPOs) dołączone do nadrzędnej jednostki organizacyjnej o nazwie Nadrzędna (Parent), które zawierają Zasady Użytkownika (User Policies). Jeden zostanie nazwany Obowiązkowy (Mandatory), drugi — Domyślny (Default). Dzięki funkcji Nie zastępuj (No override), zasady z obiektu Obowiązkowy (Mandatory) zastąpią zasady w obiekcie Domyślny . W następnej części rozdziału, dzięki funkcji Zablokuj dziedziczenie zasad (Block policy inheritance), jednostka organizacyjna Podrzędna (Child) nie odziedziczy właściwości jednostki Nadrzędnej. 1.
Po utworzeniu w twojej domenie jednostek organizacyjnych Nadrzędna (Parent) i Podrzędna (Child), dodaj konto zwykłego użytkownika do jednostki organizacyjnej Podrzędna i nadaj temu użytkownikowi prawo Logowanie Lokalne (Log on Locally) w sposób opisany wcześniej.
2.
Przejdź do strony Zasady Grupowe Właściwości (Group Policy Properties) jednostki organizacyjnej Nadrzędna (Parent), jak opisano to wcześniej w niniejszym rozdziale (zob. rysunek 3.3).
3.
Utwórz nowy obiekt zasad grupowych (GPO) o nazwie Obowiązkowy (Mandatory).
4.
Utwórz nowy obiekt o nazwie Domyślny (Default).
Wskazówka: Utworzenie obiektów zasad grupowych (GPOs) w takiej kolejności powoduje, że obiekt zasad grupowych (GPO) Obowiązkowy (Mandatory) jest pierwszy na liście. Jeśli tak nie jest — użyj przycisku Do góry (Up). Nie jest to bezwzględnie konieczne, obiekty zasad grupowych (GPOs), które są narzucane, zawsze mają pierwszeństwo przed tymi, które nie są narzucane.
5.
Wybierz opcję Nie zastępuj (No override) obiektu zasad grupy (GPO) Obowiązkowy (Mandatory), klikając tę kolumnę dwukrotnie. Strona Właściwości (Properties) powinna wyglądać tak, jak na rysunku 3.9.
6.
Edytuj obiekt zasad grupowych (GPO) Obowiązkowy. Rozwiń gałęzie Konfiguracja Użytkownika (User Configuration), Szablony Administracyjnej (Administrative Templates) i System. Kliknij Logowanie/Wylogowywanie (Log on/Log off).
7.
W prawej części okna kliknij dwukrotnie zasadę (policy) WyłączMmenedżera Zadań (Disable Task Manager) i wybierz opcję Włączony (Enabled).
8.
Naciśnij OK. Zwróć uwagę, że ustawiona jest opcja Włączony . Ekran powinien wyglądać podobnie do zamieszczonego na rysunku 3.10.
Rysunek 3.9. Ustawienie Nie zastępuj (No override)
Rysunek 3.10. Menedżer Zadań (Task Manager) wyłączony w obiekcie zasad grupowych (GPO) Obowiązkowy (Mandatory) 9.
Zamknij okno Zasady Grupowe (Group Policy). Powinno pojawić się okno Nadrzędne Właściwości (Parent Properties), podobne do przedstawionego na rysunku 3.9.
10. Edytuj obiekt zasad grupowych (GPO) Domyślny (Default). 11. Rozwiń gałąź Konfiguracja Użytkownika\Szablony Administracyjne\Pulpit (User Configuration\Administrative templates\Desktop). 12. Kliknij gałąź Active Desktop, kliknij dwukrotnie Wyłącz Active Desktop (Disable Active Desktop) i wybierz Włączony (Enabled). 13. Naciśnij OK. Zwróć uwagę, że ustawiona jest opcja Włączony (Enabled). 14. Zamknij przystawkę Zasady Grupowe. 15. Aby zamknąć stronę Nadrzędny Właściwości (Parent Properties) naciśnij OK. Zamknij konsolę.
16. Zaloguj się do jednostki organizacyjnej (OU) Podrzędna (Child), korzystając z utworzonego wcześniej konta użytkownika. Zwróć uwagę, że nie możesz uruchomić Menedżera Zadań (Task Manager), jak i włączyć funkcji Active Desktop. Potwierdź to, klikając prawym klawiszem myszki na pulpicie i wybierając opcję Właściwości (Properties). Zaloguj się z powrotem jako Administrator. Postępując zgodnie z powyższą procedurą, można zagwarantować, że ustawienia zasad danego obiektu zasad grupowych (GPO) kontenera Active Directory wyższego poziomu są narzucane kontenerom niższego poziomu. Z funkcji tej należy korzystać wyłącznie wtedy, gdy wymagają tego okoliczności. Nadużywanie funkcji Nie zastępuj (No override) może komplikować zasady rozwiązywania problemów.
Wskazówka: Użycie funkcji Nie zastępuj (no override) jest jedyną metodą delegowania administrowania bez narażania bezpieczeństwa systemu. Jeśli w obiektach zasad grupowych (GPOs) dołączonych do lokacji (sites), domen lub jednostek organizacyjnych wyższego poziomu ustawiono zasady (policies) uwzględniające zabezpieczenia (security sensitive) i włączono opcję Nie zastępuj (No override), wówczas można bezpiecznie przekazać kontrolowanie jednostek organizacyjnych niższego poziomu, nadając odpowiednim osobom uprawnienia prawo odczytu i zapisu (read-write). Administratorzy pomocniczy do obiektów zasad grupowych (GPOs) będą oczywiście mieli tylko uprawnienie odczytu (read). Np. do obiektów zasad grupowych domyślne zasady domeny (default domain policy), które mogą określać dla całej domeny zasady dotyczące logowania, prawo dostępu, ustawienia protokołów zabezpieczeń i zasady inspekcji (audit policy), powinni mieć wyłącznie administratorzy sieci (członkowie grupy domain administrators), którzy powinni zagwarantować, że zasady, obowiązujące w całej domenie i ustanowione w danym obiekcie zasad grupy, nie zostaną zastąpione na niższych poziomach.
Blokowanie dziedziczenia zasad Teraz zostanie użyta funkcja Zablokuj dziedziczenie zasad (Block policy inheritance) po to, by obiekt zasad grupowych (GPO) Podrzędny (Child) nie dziedziczył zasad obiektu Nadrzędny (Parent). Po zablokowaniu dziedziczenia, użytkowników danej jednostki organizacyjnej (OU) będą dotyczyć tylko narzucone (funkcja no override) zasady Zasady Użytkownika (User Policies). Jest to łatwiejsze niż unieważnienie poszczególnych zasad obiektu zasad grupy (GPO) dla danej jednostki organizacyjnej (OU). 1.
Przejdź do strony Zasady Grupowe Właściwości (Group Policy Properties) jednostki organizacyjnej Podrzędna (Child).
2.
Zaznacz pole wyboru Zablokuj Dziedziczenie Zasad, jak przedstawiono to na rysunku 3.11.
Rysunek 3.11. Blokowanie dziedziczenia zasad (policies) Aby sprawdzić, że dziedziczone ustawienia są teraz zablokowane, należy zalogować się, korzystając z konta zwykłego użytkownika, które zostało utworzone w jednostce organizacyjnej (OU) Podrzędna . Zwróć uwagę, że zakładka Web znajduje się teraz na stronie Ustawienia Ekranu Właściwości (Display Setting Properties), ale Menedżer Zadań (Task Manager) jest nadal wyłączony, ponieważ ta zasada (policy) ma ustawioną opcję Nie zastępuj (No override). Jak pokazano poprzednio, można nie dopuścić, by ustawienia zasad grupowych (Group Policy) nadrzędnych kontenerów Active Directory oddziaływały na użytkowników i komputery w kontenerach niższego poziomu. Tak samo, jak w przypadku funkcji Nie zastępuj, blokowanie dziedziczenia powinno być stosowane tylko wtedy, kiedy bezwzględnie wymaga tego sytuacja, ponieważ w pozostałych okolicznościach może to komplikować zasady rozwiązywania problemów.
Wyłączanie części obiektu zasad grupy (GPO) Ponieważ obiekty zasad grupy (GPOs) Domyślny (Default) i Obowiązkowy (Mandatory) dotyczyły wyłącznie konfiguracji użytkownika (User Configuration), część obiektu zasad grupy (GPO) Konfiguracja Komputera (Computer Configuration) może być wyłączona. Skraca to czas uruchamiania systemu, ponieważ nie jest konieczne sprawdzanie obiektów zasad grupowych (GPOs) danego komputera pod kątem istnienia zasad (policies). Aby wyłączyć część obiektu zasad grupowych (GPO) Konfiguracja Komputera, należy: 1.
Upewnić się, czy zostało dokonane zalogowanie na konto administratora.
2.
Przejśćdo strony Zasady Grupowe Właściwości (Group Policy Property) jednostki administracyjnej o nazwie Nadrzędna (Parent).
3.
Wybrać obiekt zasad grupy (GPO) Obowiązkowy (Mandatory) i nacisnąć przycisk Właściwości (Properties).
4.
Zaznaczyć pole wyboru Wyłącz ustawienia konfiguracji komputera (Disable computer configuration settings). W oknie dialogowym Potwierdź Wyłączenie (Confirm Disable) naciśnij Tak (Yes). Okno dialogowe dla obiektu zasad grupy (GPO) Obowiązkowy Właściwości powinno wyglądać podobnie do przedstawionego na rysunku 3.12. Naciśnij OK.
5.
Wykonać powyższe czynności dla obiektu zasad grupowych (GPO) Domyślne (Default).
Uwaga: Można nie usuwać części obiektu zasad grupy (GPO) Konfiguracja komputera (computer configuration). Konfigurując ustawienia dotyczące użytkownika dla poszczególnych komputerów, można zastąpić zasady właściwe dla użytkowników (user-specific policies) zasadami właściwymi dla komputera (computer-specific policies). Jest to przydatne do skonfigurowania specjalnego pulpitu bez konieczności liczenia się z użytkownikami, którzy logują się na danym komputerze. Aby skonfigurować ustawienia użytkownika dla danego komputera, uruchom konsolę Edytor Zasad Grupowych (Group Policy Editor) i przejdź do gałęzi Ustawienia Komputera\Zasady Oprogramowania (Computer Settings\Software policies).
Rysunek 3.12. Wyłączanie ustawień Konfiguracja Komputera (Computer Configuration) danego obiektu zasad grupowych (GPO)
Dołączanie obiektu zasad grupowych (GPO) do wielu lokacji (sites), domen i jednostek organizacyjnych (OUs) Za pomocą dziedziczenia można zagwarantować, że jednostka organizacyjna (OU) zawsze będzie miała ten sam zestaw zasad (policies), co inna. Jednakże czasami jednostki organizacyjne mogą znajdować się w różnych gałęziach drzewa domeny i dołączenie ich do tego samego obiektu zasad grupowych (GPO) jest właściwym sposobem, gwarantującym, że zawsze dzielą te same zasady
(policies). Również zasady grupowe (Group Policy) nie są dziedziczone poza granicami domeny, a czasami zachodzi potrzeba dołączenia dwóch jednostek organizacyjnych z różnych domen, dwóch lokacji lub domen do jednego obiektu zasad grupy (zob. rysunek 3.1). Należy zwrócić uwagę, że połączenia (links) przekraczające granice mogą znacznie spowolnić przetwarzanie. Poniższa procedura podaje sposób dołączenia jednego obiektu zasad grupy (GPO) do dwóch jednostek organizacyjnych (OUs). Ta sama procedura może służyć do dołączania dwóch lub więcej lokacji (sites) lub domen lub do innej kombinacji lokacji (sites), domen i jednostek organizacyjnych. 1.
Na tym samym poziomie, na którym znajduje się jednostka organizacyjna Podrzędna (Child), utwórz jednostkę organizacyjną pod nazwą Second_child. Do tej jednostki organizacyjnej dodaj użytkownika i nadaj mu prawo Logowanie Lokalne (Log on Locally).
2.
Otwórz stronę Zasady Grupowe Właściwości (Group Policy Properties) jednostki organizacyjnej Second_Child.
3.
Utwórz nowy obiekt zasad grupy (GPO) pod nazwą Child_Link.
4.
Zaznacz obiekt zasad grupy (GPO) Child-Link i naciśnij przycisk Edytuj (Edit).
5.
Rozwiń gałąź Konfiguracja Użytkownika\Szablony Administracyjne\Panel Sterowania (User Configuration\Administrative Templates\Control Panel), a potem naciśnij Wyświetl (Display).
6.
Uaktywnij zasadę (policy) Wyłącz Aplet Ekran w Panelu Sterowania (Disable Display in Control Panel). Ekran powinien wyglądać podobnie do przedstawionego na rysunku 3.13.
7.
Zamknij przystawkę (snap-in) Zasady Grupowe (Group Policy).
8.
Aby zamknąć stronę Second_Child Właściwości (Second_Shild Properties) naciśnij OK.
9.
Otwórz stronę Zasady Grupowe Właściwości (Group Policy Properties) jednostki organizacyjnej (OU) Podrzędna (Child).
10. Naciśnij przycisk Dodaj (Add) lub kliknij prawym klawiszem myszki w wolnym miejscu ekranu przedstawiającego łącza (links) obiektu zasad grupowych (GPO) i z menu wybierz opcję Dodaj (Add). 11. Naciśnij strzałkę w dół w polu Szukaj w (Look in), wybierz jednostkę organizacyjną Nadrzędna (Parent) i kliknij dwukrotnie jednostkę organizacyjną Second_Child. 12. Wybierz obiekt zasad grupy (GPO) Child_Link. 13. Naciśnij OK. Strona Child Właściwości (Child Properties) powinna wyglądać podobnie do umieszczonej na rysunku 3.14. 14. Teraz jeden obiekt zasad grupy (GPO) jest dołączony do dwóch jednostek organizacyjnych (OUs). Zmiany dokonane w obiekcie zasad grupy (GPO) w jednej z jednostek organizacyjnych uwzględniane są w obydwu jednostkach organizacyjnych. Sprawdź to, zmieniając kilka zasad (policies) w obiekcie zasad grupy Child_Link i logując się (korzystając z kont zwykłych użytkowników utworzonych w jednostkach organizacyjnych Child i Second_Child).
Rysunek 3.13. Ustawianie zasad dla obiektu zasad grupowych (GPO) Child_Link
Rysunek 3.14. Udostępniony obiekt zasad grupy (GPO) dodany do jednostki organizacyjnej (OU) Oprócz dołączania jednego obiektu zasad grupy do kilku obiektów Active Directory można również przypisać kilka obiektów zasad grupy (GPOs) do konkretnego kontenera Active Directory. Jednak liczba przypisanych obiektów zasad grupy może wpłynąć na czas przetwarzania procedury logowania. W trakcie logowania przetwarzany jest każdy obiekt zasad grupy (GPO) — do którego użytkownik lub komputer mają prawo dostępu Zastosuj zasady grupy (Apply group policy) — skojarzony z kontenerem, tak więc im większa liczba skojarzonych obiektów zasad grupy (GPOs), tym dłużej trwa przetwarzanie. Jedynym sposobem zmniejszenia liczby obiektów zasad grupy dotyczących użytkowników jest zastosowanie grup zabezpieczeń do filtrowania (filtering) obiektów zasad grupowych . Stosując zasady grupowe z wielu obiektów zasad grupowych (GPOs) do danego kontenera Active Directory i korzystając z filtrowania zasad grupowych (Group Policy filtering) — co ukrywa pewne zasady (policies) przed niektórymi użytkownikami — poprawia się znacznie wydajność, ponieważ przetwarzanych jest mniej obiektów zasad grupy (GPOs). Filtrowanie (filtering) omówiono dokładniej w dalszej części niniejszego rozdziału.
Administrowanie zasadami korzystającymi z Rejestru (Registry-based policies) Interfejs użytkownika zasad korzystających z Rejestru (Registry-based policies) jest kontrolowany za pomocą plików Szablony Administracyjne (Administrative Templates) ADM. Pliki te opisują interfejs użytkownika, który jest wyświetlany w gałęzi Szablony Administracyjne (Administrative Templates) przystawki (snap-in) Zasady Grupowe (Group Policy). Chociaż pliki te mają format zgodny z plikami ADM, używanymi przez Edytor Zasad Systemowych (System Policy Editor), poledit.exe, systemu Windows NT 4, szablony pochodzące z poprzednich wersji systemu Windows nie powinny być importowane do systemu Windows 2000, ponieważ nie będą pracowały poprawnie i mogą uszkodzić Rejestr. Zanim omówione zostaną praktyczne aspekty administrowania zabezpieczeniami systemu Windows 2000 za pomocą Rejestru, opisany będzie sposób, w jaki te informacje są zapisywane. Szablon Zasad Grupowych (folder Group Policy Template — GPT), zawiera kilka podfolderów: •
Adm — zawiera pliki ADM szablonu zasad grupy (GPT),
•
Skrypty (Scripts) — zawiera wszystkie skrypty i pliki związane z nimi szablonu zasad grupy (GPT),
•
Użytkownik (User) — zawiera plik registry.pol, w którym zapisane są ustawienia Rejestru dotyczące użytkowników. Kiedy użytkownik loguje się na komputerze, plik ten jest ładowany i stosowany do klucza Rejestru HKEY_CURRENT_USER. Folder Użytkownik (User) zawiera podfolder Apps, w którym zapisane są pliki Anonse (Advertisements), z których korzysta Instalator Systemu Windows (Windows Installer) oraz podfolder Pliki (Files), w którym zapisane są pliki do zainstalowania.
•
Komputer (Machine) — zawiera plik registry.pol, w którym zapisane są ustawienia Rejestru, które mają dotyczyć komputerów. Podczas inicjalizacji komputera, plik ten jest ładowany i stosowany do klucza Rejestru HKEY_LOCAL_MACHINE. Folder Komputer zawiera podfolder Apps i podfolder Pliki, w tym przypadku dla aplikacji anonsowanych dla komputera (per-computer). Zawiera także podfolder, który zawiera plik Edytora Zabezpieczeń (Security Editor) GPTTmpl.inf.
Foldery Użytkownik i Komputer są tworzone w trakcie instalowania systemu. Inne foldery tworzone są w razie potrzeby, kiedy ustalone zostaną zasady (policy). Plik registry.pol zawiera niestandardowe ustawienia Rejestru. W systemie Windows 2000 są pliki tekstowe, podczas gdy w systemie Windows NT 4 były to pliki binarne. W folderze Szablon Zasad Grupy (Group Policy Templates) tworzone są dwa pliki registry.pol — jeden, dotyczący ustawień komputera (computer settings) i zapisany w podfolderze Komputer oraz drugi, zapisany w podfolderze Użytkownik. Pliki registry.pol są tworzone lub poprawiane w następujący sposób:
1.
Kiedy uruchamiany jest Edytor Zasad Grupowych, tworzone jest tymczasowe drzewo Rejestru, składające się z dwóch gałęzi: Użytkownik (User) i Komputer (Machine).
2.
Podczas przechodzenia przez gałąź Zasady Oprogramowania (Software Policies) Edytora Zasad Grupowych, wyświetlane są pliki ADM i gałęzie rozszerzeń przystawek (snap-in extension nodes). Pliki ADM z gałęzi Edytor Zasad Grupowych (Group Policy Editor) są ładowane dynamicznie,gdy wybrana jest konkretna gałąź, a wówczas plik ADM jest umieszczany w buforze.
3.
Kiedy w prawej części okna konsoli MMC wybrana zostanie pewna zasada (policy), tymczasowy Rejestr jest badany, aby określić, czy wybranej zasadzie (policy) przypisano już wartości Rejestru. Jeśli tak jest, to wartości te są wyświetlane w oknie dialogowym Zasada.
4.
Jeśli wybranej zasadzie nie przypisano wartości Rejestru, korzysta się z domyślnych wartości z pliku ADM lub ze skojarzonego rozszerzenia przystawki MMC (MMC snap-in extension).
5.
Po zmodyfikowaniu zasad podane wartości Rejestru wpisywane są do odpowiednich części Rejestru tymczasowego.
6.
Po zamknięciu Edytora Zasad Grupowych (Group Policy Editor) gałęzie Rejestru tymczasowego są eksportowane do plików registry.pol w odpowiednich folderach Szablon Zasad Grupowych (Group Policy Template).
7.
Przy następnym uruchamianiu Edytora Zasad Grupowych (Group Policy Editor) dla tego samego obiektu zasad grupowych (GPO), informacje Rejestru z odpowiednich plików registry.pol są importowane do Rejestru tymczasowego.
Uwaga: Jeśli dwóch administratorów na różnych kontrolerach domeny (DC) uruchomiłoby Edytor Zasad Grupowych (Group Policy Editor) dla tego samego obiektu zasad grupowych (GPO), każdy z nich mógłby modyfikować zasady (policies), które mogłyby być zastępowane przez poprawki drugiego administratora. W takim przypadku skuteczne byłyby modyfikacje zapisane jako ostanie. Jedynym sposobem uniknięcia takiej sytuacji jest ścisłe ograniczenie liczby administratorów domeny. Liczba użytkowników, którym nadaje się prawo zapisu (write) dla każdego obiektu zasad grupowych (GPO), nie powinna przekraczać niezbędnego minimum.
Dodawanie szablonów administracyjnych Chociaż ważne jest, aby wiedzieć, jak zlokalizować pliki registry.pol i co one zawierają, to w rzeczywistości do administrowania Rejestrem używa się szablonów administracyjnych (Administrative templates), tzn. plików ADM, znanych również jako Szablony zasad (Policy templates). Plik ADM zawiera hierarchiczną strukturę kategorii i podkategorii, które określają, w jaki sposób zorganizowane są opcje interfejsu użytkownika Zasady Grupowe (Group Policy). Aby dodać szablon administracyjny (Administrative template), należy:
1.
Uruchomić przystawkę Zasady Grupowe. Można skorzystać z utworzonej wcześniej konsoli GroupAD lub po prostu dodaj przystawkę Zasady Grupowe (Group Policy) do autonomicznej konsoli MMC.
2.
Rozwinąć gałąź Konfiguracja Użytkownika (User Configuration) lub Konfiguracja Komputera (Computer Configuration). Plik ADM określa, w której lokalizacji zasada jest wyświetlana, nie ma więc znaczenia, która z lokalizacji zostanie wybrana.
3.
Rozwinąć gałąź Szablony Administracyjne (Administrative Templates).
4.
Kliknac prawym klawiszem myszki gałąź Szablony Administracyjne (Administrative Templates) i z menu wybrać opcję Dodaj/Usuń szablony (Add/Remove templates). Pojawi się lista szablonów danej jednostki administracyjnej, które są aktualnie czynne.
5.
Nacisnąć przycisk Dodaj (Add). Pojawi się lista plików ADM dostępnych w katalogu %systemroot%\inf komputera, w którym Zasady Grupowe (Group Policy) są uruchomione. Można wybrać pliki ADM z innego komputera, ale najpierw trzeba upewnić się, że komputer ten pracuje pod kontrolą systemu Windows 2000. Raz wybrany plik ADM zostanie skopiowany do obiektu zasad grupy (GPO).
Poprawianie zasad korzystających z Rejestru (Registry-based policies) za pomocą szablonów administracyjnych Teraz do zmiany zasad (policies) jednostki administracyjnej Nadrzędna (Parent) zostanie użyty szablon administracyjny (administrative template) i sprawdzimy, że będzie dziedziczyć je jednostka administracyjna Podrzędna (Child). Aby wykonać procedurę opisaną poniżej, należy zakończyć procedurę ustanawiania dziedziczenia (opisaną wcześniej w niniejszym rozdziale) lub użyć jednostki organizacyjnej (OU), podrzędnej jednostki organizacyjnej i dołączonych do nich obiektów zasad grupy (GPOs), zdefiniowanych w podobny sposób w kontrolerze domeny. 1.
Otwórz stronę Zasady Grupowe Właściwości (Group Policy Properties) jednostki organizacyjnej Nadrzędna (Parent) lub dowolnej jednostki organizacyjnej, wybranej z danego komputera.
2.
Edytuj obiekt zasad grupowych (GPO) Obowiązkowy (Mandatory) lub wybierz własny.
3.
Rozwiń gałąź Konfiguracja Użytkownika\Szablony Administracyjne (User Configuration\Administrative Templates) i wybierz pozycję Menu, Start i Pasek zadań (Menu, Start and Taskbar).
4.
Kliknij dwukrotnie pozycję Usuń menu Uruchom z menu Start (Remove Run menu from Start Menu). Pojawi się okno dialogowe Właściwości tej zasady (policy), jak przedstawiono na rysunku 3.15.
5.
Wybierz Włączony (Enabled).
Wskazówka: Zwróć uwagę na przyciski Następna zasada (Next policy) i Poprzednia zasada (Previous policy). Można je użyć do poruszania przez listę zasad bez zamykania i powtórnego otwierania okna dialogowego Właściwości (Properties).
6.
W oknie dialogowym naciśnij przycisk OK. Zwróć uwagę na zmianę stanu w kolumnie ustawień. Zmiana jest natychmiastowa. Jeśli jesteś w środowisku zreplikowanego kontrolera domeny, działanie to uaktywnia replikację.
7.
Zaloguj się do jednostki organizacyjnej Podrzędna (Child), korzystając z utworzonego wcześniej konta użytkownika. Zwróć uwagę, że na skutek dziedziczenia z jednostki administracyjnej Nadrzędna (Parent), usunięte zostało menu Uruchom (Run).
Rysunek 3.15. Okno dialogowe do poprawiania szablonu administracyjnego
Obsługa klientów Windows NT i 9x Edytor Zasad Grupowych (Group Policy Editor) systemu Windows 2000 nie umożliwia obsługi klientów Windows NT 4 ani komputerów pracujących pod kontrolą systemów Windows 95 i Windows 98. Obsługa klientów Windows NT 4 jest zapewniona przez obsługiwanie szablonów administracyjnych (administrative templates), takich jak w systemie Windows NT i stosowanie plików Edytora Zasad Systemowych (System Policy Editor) systemu Windows NT 4, poledit.exe. Podczas instalowania systemu Windows 2000 Server można zainstalować dodatkowe składniki, tzw. Dodatkowe narzędzia administracyjne systemu Windows 2000 (Windows 2000 optional administrative tools). Pakiet ten zawiera wszystkie informacje konieczne do zainstalowania dodatkowych programów do administrowania i jest częścią systemu Windows 2000 Server. Klienci pracujący pod kontrolą systemów Windows 95 lub Windows 98 muszą korzystać z Edytora Zasad Systemowych (System Policy Editor) systemu Windows NT 4, poledit.exe. Zarówno w przypadku stacji roboczych Windows NT, jak i komputerów pracujących pod kontrolą systemu Windows 95 oraz Windows 98, utworzone w ten sposób pliki z rozszerzeniem pol muszą zostać skopiowane do udziału Netlogon domeny (...\system32\repl\import\scripts).
Przygotowywanie skryptów Skrypty są to pliki wsadowe (BAT), pliki poleceń (CMD) lub pliki wykonywalne (EXE) uruchamiane, gdy komputer jest włączany i zamykany, albo gdy użytkownik loguje się lub wylogowuje na dowolnej stacji roboczej w sieci. W systemie Windows 2000 obsługiwane są: Windows Scripting Host (WSH), Visual Basic Scripting Edition (VBScript) i JavaScript (JScript), nadal także obsługiwane są skrypty poleceń i pliki wykonywalne systemu MS-DOS. Skrypty mogą być używane do ustanawiania kryteriów bezpieczeństwa dla wszystkich rodzajów klientów podłączonych do systemu Windows 2000 Server. Można także za ich pomocą ustawiać zmienne środowiskowe (environment variables) i połączeń stałych do udziałów sieciowych (network shares). Kolejna procedura służy do dodawania skryptu logowania metaback.js i uruchomienia go przy logowaniu. Skrypt ten wykonuje kopię zapasową metabazy (metabase) i jest częścią zestawu Software Development Kit (SDK). Inne skrypty można pobrać, korzystając z witryny Microsoftu www.microsoft.com i znajdujących się tam łączy (links): 1.
Otwórz stronę Zasady Grupowe Właściwości (Group Policy Properties) domeny głównej (root domain).
2.
Edytuj obiekt zasad grupowych o nazwie Domyślne Zasady Domeny (Default Domain Policy).
3.
Rozwiń gałąź Konfiguracja Użytkownika\Ustawienia Systemu Windows (User Configuration\Windows Settings) i wybierz pozycje Skrypty (Scripts) (Log on/Log off).
4.
W prawej części okna kliknij dwukrotnie pozycje Logowanie (Logon).
5.
Na stronie Logowanie Właściwości (Logon Properties) — rysunek 3.16— przedstawiona jest lista skryptów uruchamianych przy logowaniu się użytkowników, których dotyczą. Jest to lista uporządkowana; skrypt znajdujący się na pierwszym miejscu jest również uruchamiany jako pierwszy. Kolejność skryptów można zmienić za pomocą przycisków Góra (Up) i Dół (Down). Strona prawdopodobnie okaże się pusta, o ile wcześniej nie dodano żadnych skryptów.
6.
Uruchom program Eksplorator Windows (Windows Explorer) i znajdź plik ..\inetpub\iissamples\sdk\admin\metaback.js. Skopiuj plik, a potem zamknij Eksploratora.
Rysunek 3.16. Strona Logowanie Właściwości (Logon Properties) 7.
Na stronie Logowanie Właściwości naciśnij przycisk Pokaż Pliki (Show Files) i wklej skrypt metaback.js do okna Logowanie (Logon). Zamknij okno Logowanie (Logon).
8.
Naciśnij przycisk Dodaj, znajdujący się na stronie Logowanie Właściwości.
9.
Naciśnij przycisk Przeglądaj (Browse). Kliknij dwukrotnie plik metaback.js.
10. Nie trzeba podawać żadnych parametrów skryptu, więc naciśnij OK. Kolejny raz naciśnij przycisk OK, aby zamknąć stronę Logowanie Właściwości (Logon Properties). 11. Wyloguj się i zaloguj ponownie jako administrator. Skrypt powinien zostać uruchomiony w trakcie logowania.
Wskazówka: Jeśli zalogujesz się jako zwykły użytkownik, skrypt nie zostanie uruchomiony, ale zamiast tego pojawi się w oknie ze wskazaniem, gdzie wystąpił błąd. Jest to prawidłowe działanie. Zwykły użytkownik nie ma wystarczających uprawnień do wykonywania kopii zapasowej metabazy (metabase). Także, jak zaznaczono poprzednio, zwykły użytkownik nie powinien logować się na kontrolerze domeny. Jeśli jest stacja robocza-klient, zaloguj się jako zwykły użytkownik na tej stacji roboczej. W tym przypadku nie będzie w ogóle dostępu do skryptu metaback.js, ponieważ jest on uruchamiany tylko w sytuacji logowania się na kontrolerze domeny.
Przygotowywanie skryptów wylogowywania (log off script) lub skryptów do uruchamiania-zamykania komputera (startup-shutdown scripts) Przedstawioną właśnie procedurę można także zastosować do przygotowywania skryptów uruchamianych podczas wylogowywania się użytkownika lub w trakcie uruchamiania czy też zamykania komputera. Domyślnie skrypty zasad grupowych (Group Policy), uruchamiane w oknie poleceń (pliki z rozszerzeniem bat lub cmd), działają jako ukryte (hidden). Starsze skrypty, zdefiniowane w obiekcie użytkownika, domyślnie są widoczne podczas przetwarzania, chociaż za pomocą zasad grupowych można je ukryć.
Ustawianie odpowiednich uprawnień dla poszczególnych członków grup zabezpieczeń (security group filtering)
Korzystając z grup zabezpieczeń systemu Windows 2000 oraz za pomocą Edytora Listy Kontroli Dostępu (ACL Editor), który służy do filtrowania wpływu obiektu zasad grupowych (GPO) na członków grup, można dokładnie ustalić, na które komputery i których użytkowników oddziałuje konkretny obiekt zasad grupowych. Zgodnie z opisem zamieszczonym w rozdziale 2. Edytor Listy Kontroli Dostępu (ACL Editor) można uruchomić wybierając stronę Właściwości (Properties) obiektu zasad grupowych i zakładkę Bezpieczeństwo (Security). Edytor listy kontroli dostępu (ACL Editor) może być również użyty do określenia, którzy użytkownicy mogą modyfikować obiekt zasad grupy. Administratorzy mogą określić, które grupy użytkowników i komputerów mają uprawnienia Stosowanie Zasad Grupy (Apply Group Policy — AGP) i Wpis Kontroli Dostępu (Access Control Entry — ACE) do danego obiektu zasad grupowych (GPO). Grupy, które mają uprawnienia do Stosowanie Zasad Grupy (Apply Group Polic) i odczytu (read access) danego obiektu zasad grupy, otrzymują zasady grupowe (Group Policies) w nim zawarte. Domyślnie członkowie grupy zatwierdzeni użytkownicy (authenticated users) mają uprawnienia Stosowanie Zasad Grupy (Apply Group Policy) i do odczytu listy kontroli dostępu (read ACL). Oznacza to, że użytkownicy z tej grupy nie mogą modyfikować informacji zawartych w obiekcie zasad grupowych (GPO). Jeśli w tym obiekcie zostaną umieszczone istotne dane, których nie powinni odczytać użytkownicy, na których dany obiekt zasad grupy ma wpływ, to można zmienić domyślne uprawnienia dotyczące listy kontroli dostępu (ACL) i nadać uprawnienia do odczytu tylko tym użytkownikom, którym jest to niezbędne. Domyślnie administratorzy domeny mają uprawnienia pełnej kontroli (full control), ale nie maja uprawniania Stosowanie Zasad Grupy (Apply Group Policy) dotyczącego list kontroli dostępu. Oznacza to, że domyślnie zasady danego obiektu zasad grupowych (GPO) nie mają zastosowania w odniesieniu do administratorów domeny, ale mogą oni modyfikować obiekty zasad grupowych (GPOs). Administratorzy sieci (członkowie grupy domain administrators) mogą również użyć Edytora Listy Kontroli Dostępu (ACL Editor) do określenia grup administracyjnych, których członkowie mogą modyfikować zasady (policies) w obiektach zasad grupowych (GPOs). Administrator sieci może zdefiniować grupy administratorów, np. administratorów publikowania (publishing administrators), z prawami określonymi w jednostce administracyjnej Wydawcy (Publishers) i nadać im prawo odczytu – zapisu (read – write access) do wybranych obiektów zasad grupy (GPO). Pozwala to administratorowi sieci na przekazanie kontroli nad zasadami tych obiektów zasad grupy (GPOs). Nadanie prawa odczytu – zapisu, dotyczącego obiektu zasad grupy, pozwala administratorom na kontrolowanie wszystkich jego elementów. Edytor Listy Kontroli Dostępu (ACL Editor) można uruchomić także za pomocą menedżera przystawki Lokacje i Usługi Active Directory (Active Directory Sites and Services) konsoli MMC, klikając prawym klawiszem myszki obiekt lokacji (site object) i włączając opcję Właściwości (Properties), a następnie wybierając zakładkę Bezpieczeństwo (Security). Przed rozpoczęciem kolejnej procedury należy utworzyć w jednostce administracyjnej Nadrzędna (Parent) Globalną Grupę Zabezpieczeń (Global Security Group) pod nazwą Zarządzanie (Management). Można oczywiście użyć dowolnej grupy z dowolnej jednostki organizacyjnej i odpowiednio dostosować poniższą procedurę: 1.
Otwórz stronę Zasady Grupowe Właściwości (Group Policy Properties) jednostki organizacyjnej o nazwie Nadrzędna (Parent) lub innej jednostki organizacyjnej, wybranej na danym komputerze.
2.
Kliknij prawym klawiszem myszki obiekt zasad grupowych (GPO) o nazwie Obowiązkowy (Mandatory) lub inny wybrany przez siebie obiekt zasad grupowych (GPO). Kliknij opcję Właściwości, a następnie wybierz zakładkę Bezpieczeństwo.
Uwaga: Chociaż nie jest to częścią niniejszej procedury, w tym miejscu można zbadać opcje Zaawansowane, naciskając przycisk Zaawansowane (Advanced). Należy zwrócić uwagę, że można za ich pomocą zastosować uprawnienia dotyczące obiektu zasad grupy (GPO), skonfigurowane dla dowolnej grupy, dla obiektów podrzędnych i wielu innych obiektów wybranych z listy rozwijalnej Zastosuj do (Apply onto), która pojawi się po naciśnięciu przycisku Widok/Edycja (View/Edit). Powinno się również zwrócić uwagę, że można skonfigurować inspekcję (auditing) dla dowolnej grupy „lun" użytkownika oraz inspekcję korzystania z uprawnień dla danego obiektu zasad grupy (GPO).
3.
Naciśnij przycisk Dodaj (Add).
4.
Wybierz z listy grupę Zarządzanie (Management) lub inną grupę, którą używasz.
5.
Naciśnij Dodaj (Add), a następnie naciśnij OK.
6.
Zaznacz grupę Zarządzanie (Management) lub tą, którą używasz i zobacz uprawnienia. Domyślnie tylko uprawnienie odczytu (read) ACE jest ustanowione jako Zezwalaj (allow). Oznacza to, że do członków grupy Zarządzanie (Management) nie stosuje się tego obiektu zasad grupy (GPO), chyba że są członkami innej grupy, która ma nadane uprawnienie Stosowanie Zasad Grupy (Apply Group Policy). Jednak grupa Zarządzanie (Management) domyślnie jest członkiem grupy Zatwierdzeni Użytkownicy (Authenicated Users), która ma nadane uprawnienie Stosowanie zasad grupy. Teraz do wszystkich członków grupy Zatwierdzeni Użytkownicy (Authenicated Users) stosuje się dany obiekt zasad grupowych (GPO), bez względu na to, że dodano do listy grupę Zarządzanie.
7.
Oprócz uprawnienia Stosowanie Zasad Grupy (Apply Group Policy) dla grupy Zarządzanie (Management) zaznacz pole wyboru Zezwalaj (Allow) i wyczyść to pole wyboru dla grupy Zatwierdzeni Użytkownicy (Authenicated Users). Dany obiekt zasad grupy (GPO) jest skonfigurowany tak, by dotyczył tylko członków grupy Zarządzanie (Management). Na rysunku 3.17 przedstawiono zrzuty ekranów dla tych operacji. Zamknij konsolę naciskając dwukrotnie OK.
OTRZEŻENIE! Przy korzystaniu z opcji Odmów (Deny) należy zachować szczególną ostrożność. Dla każdej grupy wybór tej opcji ma pierwszeństwo, nawet jeśli użytkownik lub komputer, dzięki członkostwu w innej grupie, ma ustawione Zezwalaj (Allow).
Wskazówka: Te same opcje można zastosować w przypadku skryptów logowania przygotowanych zgodnie z poprzednią procedurą. Można skrypt skonfigurować w ten sposób,
by był uruchamiany tylko dla członków konkretnej grupy lub dla wszystkich, za wyjątkiem członków określonej grupy.
Filtrowanie grup zabezpieczeń (security group filtering) ma dwie funkcje. Pierwszą jest zmiana grupy, na którą oddziałuje dany obiekt zasad grupy (GPO). Druga — to przekazanie modyfikowania zawartości obiektu zasad grupowych poprzez nadanie uprawnienia Pełnej Kontroli (Full Control) ograniczonej grupie administratorów. Działanie to jest zalecane, ponieważ zmniejsza szansę na równoczesne dokonywanie zmian przez kilku administratorów. Należy zwrócić uwagę, że najwyższy stopień bezpieczeństwa ustawień zasad (policy settings security) osiągnięto za pomocą filtrowania grup zabezpieczeń (security group filtering). Domyślnie ustawienia listy kontroli dostępu (ACL) zasad grupowych (Group Policy) aktualizują daną zasadę (policy) tylko wtedy, gdy ustawienia są nowe lub zmienione. Filtrowanie grup zabezpieczeń (security group filtering) gwarantuje, że wybrane ustawienia stosowane są przy każdym logowaniu do Active Directory. Jednak wybór tej opcji anuluje optymalizację wydajności osiągniętą przez pomijanie stosowania ustawień zasad (policy settings), gdy nie zostały zmienione.
Rysunek 3.17. Ustawienia dla grup Administrowanie (Management) i Zatwierdzeni Użytkownicy (Authenticated Users)
Dopasowanie zasad (policies) do danego komputera za pomocą przetwarzania sprzężenia zwrotnego (loopback processing) Czasami zachodzi potrzeba zastosowania dla użytkowników zasad grupowych (Group Policy) na podstawie lokalizacji obiektu komputera w strukturze Active Directory, zamiast na podstawie lokalizacji obiektu użytkownika. Innymi słowy, wszyscy użytkownicy logujący się na określonym komputerze podlegają takim samym ograniczeniom zasad (policies). Funkcja zasad grupowych (Group Policy) Sprzężenie zwrotne (Loopback) daje administratorowi możliwość stosowania zasad grupowych dostosowanych do komputera (computer-based Group Policy). Funkcję tę najlepiej zilustruje przykład. W domenie przedstawionej na rysunku 3.18 do członków grupy Obroty (Sales) z jednostki administracyjnej Nadrzędna (Parent), podczas logowania się do ich stacji roboczych stosuje się obiekty zasad grupowych Obowiązkowy (Mandatory) i Domyślny (Default). Jednak, jeśli członek grupy Obroty (Sales) loguje się na komputerze, który jest członkiem jednostki administracyjnej Komputery o ograniczonym dostępie (Restricted Computers), to wtedy stosowane są zasady (policies) z obiektu zasad grupy (GPO) Sprzężenie zwrotne (Loopback). Ten obiekt zasad grupy nie musi nazywać się Loopback — nazwa ta została wybrana dla przejrzystości. Poniżej opisano dwa sposoby zastosowania zasad grupowych Sprzężenie zwrotne (Loopback): •
Tryb scalania (Merge mode) — w trakcie logowania lista obiektów zasad grupowych (GPOs) danego użytkownika jest tworzona w sposób zwykły, a następnie lista obiektów zasad grupowych (GPOs) komputera jest dodawana na końcu listy obiektów zasad grupowych (GPOs) użytkownika. Powoduje to, że obiekty zasad grupowych tego komputera mają wyższy priorytet niż obiekty zasad grupowych danego użytkownika. W przykładzie przedstawionym na rysunku 3.18 do członka grupy Zarządzanie (Management) logującego się na komputerze z jednostki organizacyjnej Komputery o ograniczonym dostępie (Restricted Computers)stosowałyby się zasady obiektu zasad grupowych (GPO) Domyślne (Default), po czym następowałyby zasady (policies) obiektu Obowiązkowy (Mandatory), a następnie zasady (policies) obiektu Sprzężenie zwrotne. Należy zwrócić uwagę, że kolejność, w jakiej stosowane są zasady (policies) jest odwrotna do ich priorytetu.
•
Tryb zamiany (Replace Mode) — w trybie tym lista obiektu zasad grupowych (GPO) użytkownika jest pomijana. W przedstawionym przykładzie stosowane będą tylko zasady zawarte w obiekcie zasad grupy Sprzężenie zwrotne (Loopback).
Rysunek 3.18. Zasady określonego komputera kontrolowane za pomocą funkcji sprzężenia zwrotnego (Loopback) Następna procedura wymaga, by — oprócz kontrolera domeny — w sieci znajdowała się stacja robocza. Na potrzeby tej procedury utworzono jednostkę administracyjną pod nazwą Komputery o ograniczonym dostępie (Restricted Computers), do której dodano komputer WORKSTATION10. W jednostce administracyjnej (OU) Nadrzędna (Parent) utworzono grupę Obroty (Sales), która ma nadane prawo Logowanie lokalne (Log on Locally) na kontrolerze domeny. Do grupy Obroty dodano konto użytkownika. Jeśli używasz innych nazw komputera, jednostki organizacyjnej (OU) i grupy, a prawdopodobnie tak jest, należy nimi odpowiednio zastąpić nazwy podane w poniższej procedurze. 1.
Otworzyć stronę Zasady Grupowe Właściwości (Group Policy Properties) jednostki organizacyjnej Komputery o ograniczonym dostępie (Restricted Computers).
2.
Utworzyć obiekt zasad grupy (GPO) pod nazwą Sprzężenie zwrotne (Loopback). Zaznaczyć ten obiekt zasad grupy i nacisnąć przycisk Edytuj (Edit).
3.
Rozwinąć gałąź Konfiguracja Komputera\Szablony Administracyjne\System (Computer Configuration\Administrative Templates\System), a następnie kliknąć Zasady Grupowe.
4.
W prawej części okna kliknąć dwukrotnie pozycję Tryb przetwarzania sprzężenia zwrotnego zasad grupy użytkownika (User Group Policy loopback processing mode).
5.
Załączyć zasady (policies) i upewnić się, że w rozwijalnej liście dialogowej Tryb (Mode) wybrano pozycję Zamień (Replace). Ekran powinien wyglądać podobnie do tego z rysunku 3.19.
6.
Nacisnąć OK i sprawdzić, czy zasada (policy) została załączona.
7.
Rozwinąć gałąź Konfiguracja Użytkownika\Szablony Administracyjne (User Configuration\Administrative Templates) i wybrać Menu, Start i Pasek zadań (Menu, Start and Taskbar).
8.
Kliknąć dwukrotnie pozycję Usuń folder użytkownika z menu Start (Remove user’s folder from Start Menu) i załączyć zasadę, wybierając opcję Włączona (Enabled) i naciskając przycisk Zastosuj (Apply).
9.
Aby przejść do następnej zasady (policy) — Wyłącz i usuń łącza do witryny Windows Update (Disable and remove links to Windows update) — naciśnąć przycisk Następna zasada (Next policy).
10. Użyć przycisku Następna zasada (Next policy), aby przechodzić do kolejnych zasad na stronie, uaktywniając te, które przedstawiono na rysunku 3.20. W celu upewnienia się, jakie jest działanie danej zasady, należy wybrać zakładkę Wyjaśnij (Explain). Po przejściu przez wszystkie zasady nacisnąć OK.
Rysunek 3.19. Załączenie zasady sprzężenia zwrotnego (Loopback)
Rysunek 3.20. Zasady (policies) użytkownika Menu, Start i Pasek zadań (Menu, Start and Taskbar) obiektu zasad grupy pod nazwą Sprzężenie zwrotne (Loopback)
Uwaga: Zakładka Wyjaśnij (Explain) pojawi się po dwukrotnym kliknięciu zasady i będzie widoczna podczas przechodzenia do kolejnych zasad za pomocą przycisku Następna zasada (Next policy). Na rysunku 3.20 nie przedstawiono zakładki Wyjaśnij (Explain) ani przycisku Następna zasada (Next policy). Rysunek ten zamieszczono po to, aby pokazać, jakie zasady użytkownika (user policies) należy ustawić.
11. Wybrać pozycję Pulpit (Desktop) i uaktywnić zasady (policies) na tej stronie, jak przedstawiono to na rysunku 3.21. Kliknąć OK.
12. Rozwinąć gałąź Panel Sterowania (Control Panel). Wybrać pozycję Dodaj/Usuń programy (Add/Remove programs) i załączyć zasadę Ukryj stronę Dodaj/Usuń składniki systemu Windows (Hide Add/Remove Windows Components Page). Nacisnąć OK. 13. Wybrać pozycję Ekran (Display) i załączyć zasadę Nie zezwalaj użytkownikowi na uruchamianie panelu sterowania ekranu (Prohibit user from running display control panel). Nacisnąć OK. 14. Zamknąć przystawkę (snap-in) Zasady Grupowe (Group Policy) oraz konsolę. Teraz żadnego z użytkowników zalogowanych na komputerach w jednostce organizacyjnej (OU) Komputerów o ograniczonym dostępie (restricted computers) nie dotyczą zasady, które normalnie byłyby wobec nich stosowane, ale dotyczą ich zasady użytkownika (user policies), ustanowione w obiekcie zasad grupy pod nazwą Sprzężenie zwrotne. Aby to przetestować, zaloguj się na stacji roboczej WORKSTATION10 jako użytkownik z grupy Obroty (Sales), a następnie zaloguj się na kontrolerze domeny jako ten sam użytkownik. Jednak nie jest to porównywanie podobieństw, ponieważ kontrolerzy domen mają swój własny zestaw Zasad Komputera (Computer Policies). Lepiej jest zalogować się jako dany użytkownik na innej stacji roboczej, która nie znajduje się w jednostce organizacyjnej Komputery o ograniczonym dostępie lub usunąć stację roboczą WORKSTATION10 z tej jednostki organizacyjnej, przenieść ją do innej, której nie dotyczą ograniczenia sprzężenia zwrotnego (loopback restrictions) i zalogować się znów jako ten sam użytkownik.
Rysunek 3.21. Zasady Użytkownika (User Policies) dotyczące Pulpitu (Desktop) obiektu zasad grupy Sprzężenie zwrotne (Loopback)
Konfigurowanie zasad inspekcji (audit policies) Administratorzy regularnie przeprowadzają inspekcję zdarzeń, sprawdzając bezpieczeństwo sieci. W szczególności dokonuje się inspekcji następujących zdarzeń: •
nieudane próby zalogowania, aby określić, czy ktoś korzystał z kont, z których nie ma prawa korzystać,
•
udane i nieudane próby dostępu do najważniejszych plików i folderów,
•
wykorzystanie uprawnień i zmiany zasad (policies), jeśli delegowano administrowanie.
Można też archiwizować dziennik zabezpieczeń (security log), by śledzić trendy. Wszystko to jest znane administratorom systemu Windows NT 4. Wymagania dotyczące inspekcji nie uległy znaczącym zmianom wraz z pojawieniem się systemu Windows 2000. Ukazało się więcej zdarzeń podlegających inspekcji, ale podstawowe zasady są identyczne, choć inny jest interfejs ustanawiania zasad inspekcji (audit policy), które — jak prawie wszystko w systemie Windows 2000 — ustawia się za pomocą przystawki (snap-in) konsoli MMC. Aby skonfigurować zasady inspekcji (audit policy) na kontrolerze domeny, należy: 1.
Przejśćdo strony Właściwości Zasad Grupowych (Group Policy Properties) jednostki organizacyjnej (OU) Kontrolerzy Domeny (Domain Controllers).
2.
Edytować obiekt zasad grupy (GPO) Domyślne zasady kontrolerów domeny (Default Domain Controllers Policy).
3.
Rozwinąć gałęzie Konfiguracja Komputera (Computer Configuration), Ustawienia Systemu Windows (Windows Settings), Ustawienia Zabezpieczeń (Security Settings), Zasady Lokalne (Local Policies), a następnie wybrać pozycję Zasady Inspekcji (Audit Policy).
4.
Kliknąć dwukrotnie dowolną zasadę, aby ją uaktywnić tak, jak przedstawiono na rysunku 3.22.
5.
Nacisnąć OK i wyjść ze strony zasad grupowych (Group Policy). Nacisnąć OK i zamknąć konsolę.
Tak, jak w przypadku systemu Windows NT 4, inspekcja dostępu do obiektów jest ustanawiana dla określonych plików i folderów za pomocą Eksploratora Windows (Windows Explorer), przy założeniu, że systemem plików jest NTFS. Prawo do zarządzania inspekcją (auditing) i dziennikiem zabezpieczeń (security log) jest nadane poprzez zasadę Przypisywanie Praw Użytkownika (User Rights Assignment), która jest częścią tego samego rozszerzenia konsoli MMC (MMC expansion), co Zasady inspekcji (Audit Policy); domyślnie tylko administratorzy mają to prawo. Gdzie indziej można znaleźć bardziej tajemnicze opcje zasad inspekcji (auditing policy options), np.w Opcjach Zabezpieczeń (Security Options), w tym samym rozszerzeniu konsoli MMC (MMC expansion) może być ustawiona opcja Monitoruj dostęp do globalnych obiektów systemu (Audit the access of global system objects). Należy zawsze pamiętać, że stosunkowo łatwo jest zaplanować i skonfigurować zasady inspekcji (audit policy). Znalezienie czasu na sprawdzenie dziennika zabezpieczeń (security log) jest trudniejsze.
Rysunek 3.22. Ustanawianie zasad inspekcji (Audit Policy)
Rozdział 4
Protokoły zabezpieczeń Rozwiązania natychmiastowezobacz na stronie Konfigurowanie protokołów z kluczami tajnymi (shared secrets protocol) Zastosowanie Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) Podstawowe wiadomości o podprotokołach (subprotocols) protokołu Kerberos Analiza biletów protokołu Kerberos (Kerberos tickets) Delegowanie uwierzytelniania Konfigurowanie zasad domeny protokołu Kerberos (Kerberos domain policy) Zastosowanie interfejsu usługodawcy obsługi zabezpieczeń (Security Support Provider Interface)
W skrócie Protokoły Protokoły są zasadniczą częścią każdego systemu zabezpieczeń, a podstawowe wiadomości o protokołach zastosowanych w systemie Windows 2000 są koniecznym elementem wyposażenia administratora. Jednak protokołów nie konfiguruje się od razu, jak np. Active Directory czy zasady grupowe (Group Policy). Przed przystąpieniem do konfigurowania protokołu, konieczna jest znajomość zasad ich działania oraz skutków, jakie pociągają za sobą wprowadzane zmiany. Niniejszy rozdział zawiera więcej teorii niż którykolwiek z pozostałych w tej książce i jednocześnie mniej gotowych rozwiązań i opisów czynności. Nie jest to bynajmniej złe — pokaźna wiedza o protokołach zabezpieczeń jest konieczna. Zabezpieczenia warstwy transportowej (transport layer security) oparte na protokole Secure Sockets Layer 3 (SSL 3/TLS) opisano w rozdziale 6., przy okazji omawiania certyfikatów z kluczem publicznym (public key certificates). Zabezpieczenia protokołu IP (IP security) na poziomie sieci omówiono w rozdziale 10. Pozostaje NT LAN Manager (NTLM) i protokół Kerberos 5. Protokołu NTLM używa się, aby zapewnić zgodność wsteczną (backward compatibility) z poprzednimi wersjami sieciowych systemów operacyjnych Microsoftu (Microsoft Network Operating Systems — NOS), takimi jak Windows NT 4 i LAN Manager. Tak więc większa część niniejszego rozdziału poświęcona jest protokołowi Kerberos. Rozwiązania pokrewne zobacz na stronie Ustanawianie zabezpieczeń sieci WWW (World Wide Web Security)
Porównanie protokołów NTLM i Kerberos Usługodawca zabezpieczeń NTLM w celu uwierzytelniania korzysta z procedury wyzwanieodpowiedź (challenge-response). Usługodawca zabezpieczeń (security provider) zna hasło danego użytkownika lub, ściślej mówiąc, wyciąg uzyskany za pomocą funkcji skrótu MD4 (MD4 hash of the password). Za pomocą funkcji skrótu MD4 (MD4 hash) szyfruje losowo wygenerowany blok danych i odsyła go do klienta (wyzwanie — challenge). Następnie klient rozszyfrowuje blok danych i przesyła z powrotem do serwera. Jeśli klient również zna prawidłowe hasło, dane zostaną rozszyfrowane poprawnie i serwer zarejestruje danego klienta jako uwierzytelnionego. Z kolei usługodawca zabezpieczeń (security provider) generuje niepowtarzalny znacznik dostępu (access token), który jest przesyłany do klienta, aby korzystał z niego w przyszłości. Kolejne
uwierzytelnienia klienta dokonywane są na podstawie tego znacznika (token) i usługodawca zabezpieczeń (security provider) NTLM nie musi powtarzać procedury uwierzytelniania wyzwanie-odpowiedź (challenge-response).
Wskazówka: MD2, MD4 i MD5 są algorytmami wyznaczania funkcji skrótu wiadomości (message digest) opracowanych dla potrzeb aplikacji tworzących podpisy cyfrowe, w których duży blok wiadomości (message) musi zostać „skompresowany” w sposób bezpieczny, zanim zostanie podpisany za pomocą klucza prywatnego. Opis i kody źródłowe wymienionych powyżej trzech algorytmów można znaleźć w dokumentach Requests For Comment (RFC) od 1319 do 1321. Więcej informacji dostępnych jest na stronie internetowej RSA Laboratory www.rsasecurity.com/rsalabs/, a szczególnie pod adresem Frequently Asked Questions (FAQ) www.rsasecurity.com/rsalabs/faq/3-6-6.html.
Protokół Kerberos korzysta z idei biletów pośrednich (proxy tickets). Weźmy pod uwagę, np. proces A, który wywołuje aplikację B. Następnie aplikacja B staje się personifikacją procesu A (impersonates A), tzn. aplikacja B w ustalony sposób działa jak A. Jednak jeśli B, działając jako A, wywoła inną aplikację (C), to domyślnie aplikacja C będzie personifikacją B (impersonate B), a nie A, ponieważ uprawnienia dotyczące zabezpieczeń (security privileges) procesu A nie zostaną delegowane do aplikacji C. Prawdziwe delegowanie (delegation) — takie, jakie zapewnia protokół Kerberos — oznacza, że jeśli aplikacja B, która jest działającym wątkiem (thread) A, wywoła inną aplikację — C — to aplikacja C może być personifikacją A (impersonate A). Aplikacja B posiada bilet pośredni (proxy ticket) aplikacji A, który umożliwia personifikację A (impersonate A) nawet, jeśli wywołuje inne aplikacje. Komputery pracujące pod kontrolą systemów Windows 3.11, Windows 95, Windows 98 lub Windows NT 4 będą korzystały z protokołu NTLM przy uwierzytelnianiu sieciowym (network authentication) w domenach Windows 2000. Komputery pracujące pod kontrolą systemu Windows 2000 będą korzystały z protokołu NTLM w przypadku uwierzytelniania przez serwery systemu Windows NT 4 i przy dostępie do zasobów znajdujących się w domenach systemu Windows NT 4. Ale w systemie Windows 2000 głównym protokołem jest Kerberos. Korzyści z zastosowania protokołu Kerberos do uwierzytelniania są następujące: •
uwierzytelnianie wzajemne (mutual authentication) — protokół NTLM pozwala serwerowi na weryfikowanie tożsamości klientów, ale nie umożliwia klientom sprawdzania tożsamości serwera ani nie daje serwerowi możliwości zweryfikowania tożsamości innego serwera. Protokół Kerberos gwarantuje, że obydwie strony połączenia sieciowego wiedzą, że druga strona połączenia jest tym, za co się podaje,
•
szybsze połączenia — w przypadku uwierzytelniania za pomocą protokołu NTLM serwer aplikacji, aby uwierzytelnić każdego klienta, musi dołączyć się do kontrolera domeny (DC). W przypadku uwierzytelniania za pomocą protokołu Kerberos, serwer nie musi odwoływać się do kontrolera domeny (DC), ale zamiast tego może uwierzytelnić klienta, sprawdzając jego dane uwierzytelniające (credentials). Klienci uzyskują dane uwierzytelniające (credentials) dla danego serwera tylko raz, a potem korzystają z nich ponownie w trakcie logowania sieciowego (network logon session),
•
prostsze zarządzanie relacjami zaufania (trust management) — jedną z głównych korzyści uwierzytelniania wzajemnego (mutual authentication) w przypadku protokołu Kerberos jest to, że relacje zaufania pomiędzy domenami systemu Windows 2000 domyślnie są obustronne (two-way) i przechodnie (transitive). Jeśli sieć zawiera kilka drzew, to dane uwierzytelniające — wydane przez domenę w dowolnym drzewie — są uznawane w całym drzewie,
Uwaga: Przechodnia relacja zaufania (transitive trust) oznacza, że jeśli A ufa B i B ufa C, to A ufa C. Relacje zaufania ustanawiane za pomocą protokołu Kerberos są przechodnie, a relacje ustanawiane za pomocą protokołu NTLM — nie.
•
uwierzytelnianie delegowane (delegated authentication) — zarówno protokół NTLM, jak i protokół Kerberos dostarczają informacji potrzebnych usłudze do personifikowania (impersonate) swojego klienta lokalnie, ale niektóre aplikacje rozproszone zostały zaprojektowane tak, że usługa zewnętrzna (front-end service) musi personifikować (impersonate) klientów (clients), łącząc się z usługami wewnętrznymi (back-end services) na innym komputerze. Protokół Kerberos zawiera mechanizm pośredniczący (proxy mechanism), który pozwala usłudze na personifikowanie klienta, kiedy ten łączy się z innymi usługami. Protokół NTLM takiego mechanizmu nie zawiera,
•
współdziałanie (interoperability) — implementacja protokołu Kerberos w wersji firmy Microsoft jest oparta na specyfikacji przedstawionej grupie roboczej Internet Engineering Task Force (IETF). W wyniku tego implementacja protokołu Kerberos w systemie Windows 2000 stanowi podstawę współdziałania z innymi sieciami (szczególnie z sieciami zgodnymi z e standardem POSIX), w których do uwierzytelniania stosuje się protokół Kerberos.
Protokół uwierzytelniania Kerberos umożliwia wzajemne uwierzytelnianie (mutual authentication) pomiędzy klientem a serwerem oraz pomiędzy dwoma serwerami, zanim pomiędzy nimi zostanie ustanowione połączenie sieciowe. Protokół przyjmuje, że początkowe transakcje (transactions) pomiędzy klientami a serwerami mają miejsce w otwartej sieci, w której większość komputerów nie jest zabezpieczonych i „napastnicy” mogą monitorować oraz dowolnie modyfikować pakiety tak, jak w Internecie. Protokół Kerberos gwarantuje, że nadawca wie, kim jest odbiorca i odwrotnie oraz gwarantuje, że nikt z zewnątrz nie będzie mógł się podawać za żadną ze stron.
Rozwiązania natychmiastowe Konfigurowanie protokołów z kluczem tajnym (shared secrets protocol) W protokole Kerberos zastosowano uwierzytelnianie wymagające kluczy tajnych (shared secrets). Jeśli tylko dwoje ludzi zna klucz tajny (secret), wówczas każdy z nich może zweryfikować tożsamość drugiej strony przez uzyskanie potwierdzenia, że osoba ta zna ten sam klucz tajny (secret). Załóżmy, że np. Bonnie często wysyła wiadomości do Clyde’a, który musi mieć pewność, że wiadomość od Bonnie jest autentyczna, zanim zacznie działać zgodnie z otrzymanymi informacjami. Bonnie i Clyde jako rozwiązanie tego problemu wybrali hasło, które nie będzie udostępniane nikomu innemu. Jeśli z wiadomości od Bonnie będzie wynikało, że nadawca zna to hasło, Clyde będzie wiedział, że nadawcą jest Bonnie. W jaki sposób Bonnie pokaże, że zna to hasło? Mogłaby zamieścić w zakończeniu swojej wiadomości coś na wzór bloku podpisu (signature block). Jest to sposób prosty i wydajny, ale będzie bezpieczny tylko wtedy, gdy Bonnie i Clyde będą pewni, że nikt inny nie czyta ich poczty. Niestety, wiadomości są przesyłane przez sieć, z której korzysta Szeryf, posiadający analizator sieci (network analyzer). Tak więc Bonnie, jedynie podając hasło,nie może udowodnić, że je zna, tylko musi wykazać się jego znajomością bez przesyłania przez sieć. W protokole Kerberos rozwiązano ten problem za pomocą kryptografii z kluczem tajnym (secret key cryptography). Zamiast współdzielenia hasła, partnerzy komunikacji współdzielą klucz (cryptographic key) i stosują go do weryfikowania tożsamości drugiej strony. Klucz wspólny (shared key) musi być symetryczny (symmetric). Innymi słowy, ten sam klucz służy do szyfrowania i odszyfrowywania. Jedna ze stron udowadnia znajomość klucza poprzez zaszyfrowanie części danych, a druga — rozszyfrowując te dane. Uwierzytelnianie za pomocą klucza tajnego (secret key authentication) rozpoczyna się, gdy jedna ze stron przedstawi wartość uwierzytelniającą (authenticator) w postaci części danych zaszyfrowanych za pomocą klucza tajnego. Zestaw danych do tworzenia wartości uwierzytelniającej (authenticator) za każdym razem musi być inny, w przeciwnym razie stara wartość uwierzytelniająca mógłaby być wykorzystana ponownie przez kogoś, komu udałoby się podsłuchać wymianę danych. Po otrzymaniu wartości uwierzytelniającej (authenticator) odbiorca odszyfrowuje ją. Jeśli odszyfrowanie przebiegło pomyślnie, to odbiorca wie, że osoba przedstawiająca tę wartość zna właściwy klucz. Tylko dwoje ludzi ma właściwy klucz; odbiorca jest jedną z nich, więc osoba przedstawiająca wartość uwierzytelniającą musi być tą drugą.
Ostrzeżenie! Przyjęto, że dwie i tylko dwie osoby posiadają klucz tajny (secret key). Jeśli byłby on znany osobie trzeciej — przestałby być tajnym.
Jeśli dane są pobierane z zaufanego źródła, odbiorca musi upewnić się, czy źródło jest tym, czym rzekomo jest oraz czy informacje nie zostały po drodze sfałszowane. Nie jest to mało znaczący problem, ale parametry są ustalone i można znaleźć właściwe rozwiązanie. Należy wrócić uwagę, że w kontekście bezpieczeństwa nie ma rozwiązań doskonałych. W przypadku komunikacji dwukierunkowej, kiedy wymagane jest uwierzytelnianie wzajemne (mutual authentication), pojawiają się nowe problemy, zwłaszcza gdy dochodzi do współdzielenia kluczy tajnych (secret keys) i konieczne jest zastosowanie nowych narzędzi do rozwiązania tych problemów. Odbiorca, aby zapewnić uwierzytelnianie wzajemne, może wziąć część danych z pierwotnej wartości uwierzytelniającej (authenticator), zaszyfrować je, tworząc nową wartość uwierzytelniającą, którą wysyła do nadawcy, który z kolei może odszyfrować wartość uwierzytelniającą odbiorcy i porównać z oryginałem. Jeśli zgadzają się, nadawca będzie wiedział, że odbiorca był w stanie odszyfrować oryginał, a więc ma właściwy klucz. Załóżmy, np.że Bonnie i Clyde zadecydowali, iż do weryfikowania tożsamości drugiej strony, przed przesłaniem jakichkolwiek informacji, będą korzystać z klucza tajnego (shared secret key). Uzgodnili w ten sposób następujący protokół: 1.
Bonnie wysyła do Clyde’a komunikat zawierający jej imię zapisane otwartym tekstem oraz wartość uwierzytelniającą (authenticator) zaszyfrowaną za pomocą klucza tajnego (secret key) współdzielonego z Clydem. W tym protokole wartość uwierzytelniająca (authenticator) jest strukturą danych zawierającą dwa pola. Jedno pole zawiera informacje o Bonnie — np. nazwisko (Parker). Drugie pole zawiera aktualny czas wskazywany na stacji roboczej Bonnie.
2.
Clyde otrzymuje wiadomość i za pomocą klucza współdzielonego z Bonnie odszyfrowuje wartość uwierzytelniającą (authenticator) i odczytuje pole zawierające czas ze stacji roboczej Bonnie.
3.
Załóżmy, że oboje używają usługi sieciowej, która synchronizuje zegary w ich komputerach. Tak więc Clyde może porównać czas odczytany z wartości uwierzytelniającej (authenticator) z czasem wskazywanym przez zegar w jego komputerze. Jeśli różnica przekracza ustaloną granicę, Clyde odrzuca wartość uwierzytelniającą.
4.
Jeśli czas ten mieści się w dopuszczalnym zakresie, to wartość uwierzytelniająca (authenticator) prawdopodobnie pochodzi od Bonnie, ale Clyde nadal nie ma na to dowodu. Szeryf mógł obserwować ruch w sieci i teraz powtórzył wcześniejszą próbę ustanowienia połączenia przez Bonnie. Jednak jeśli Clyde zapisał czasy uzyskane z wartości uwierzytelniających (authenticators) przesłanych przez Bonnie, wtedy może udaremnić próby powtarzania wcześniejszych wiadomości, odrzucając każdą wiadomość, której czas jest taki sam lub wcześniejszy niż czas ostatniej wartości uwierzytelniającej.
Wskazówka: W poprzednim akapicie opisano atak metodą powtórzenia (replay attack). Jest to określenie warte zapamiętania, ponieważ osoby zajmujące się zabezpieczeniami poświęcają takim atakom wiele uwagi.
5.
Clyde używa klucza współdzielonego z Bonnie do zaszyfrowania czasu uzyskanego z komunikatu przesłanego przez Bonnie i wysyła go do niej z powrotem. Należy zwrócić uwagę, że Clyde nie odsyła wszystkich informacji zawartych w wartości uwierzytelniającej (authenticator), ale tylko czas. Gdyby odesłał wszystko, Bonnie nie miałaby sposobu, aby dowiedzieć się, czy ktoś udający Clyde’a po prostu nie skopiował wartości uwierzytelniającej (authenticator) z oryginalnego komunikatu Bonnie i nie wysłał do niej w niezmienionej postaci. Clyde wybrał czas, ponieważ jest to jedyna niepowtarzalna w komunikacie część informacji, którą przesłała Bonnie.
6.
Bonnie otrzymuje odpowiedź od Clyde’a, odszyfrowuje ją i porównuje wynik z czasem zamieszczonym w wartości uwierzytelniającej (authenticator), którą wysłała. Jeśli czas zgadza się, Bonnie może być pewna, że jej wartość uwierzytelniająca dotarła do kogoś, kto zna klucz tajny (secret key), konieczny do odszyfrowania tej wartości i oczytania czasu. Klucz tajny Bonnie współdzieli tylko z Clyde’m., więc to on odebrał jej komunikat i odpowiedział. Zarówno nadawca, jak i odbiorca mogą mieć zaufanie co do danego połączenia. Na rysunku 4.1 przedstawiono proces wzajemnego uwierzytelniania.
Rysunek 4.1. Uwierzytelnianie wzajemne
Zastosowanie Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) Poprzednia procedura ma pewien mankament — nie wyjaśnia jak ani skąd Bonnie i Clyde uzyskali klucz tajny (secret key), z którego korzystają podczas sesji. Dla jasności na potrzeby poprzedniej procedury przyjęto, że Bonnie i Clyde są ludźmi, którzy mogliby się spotkać i
uzgodnić współdzielony klucz tajny (shared secret). W rzeczywistości Bonnie może być programem-klientem pracującym na stacji roboczej, a Clyde — usługą uruchomioną na serwerze sieciowym. Następnym problemem jest to, że klient, Bonnie, komunikuje się z wieloma serwerami, więc potrzebne są klucze dla każdego z nich, a Clyde komunikuje się z wieloma klientami i również konieczne są klucze dla każdej sesji. Jeśli klient ma mieć klucz do każdej usługi, a każda usługa ma mieć klucz dla każdego klienta, to dystrybucja kluczy może szybko skomplikować się i stanowić znaczące zagrożenie. Uwaga: W niniejszym rozdziale i w innych fragmentach książki, w których używa się przykładu Bonnie i Clyde’a, określa się ich jako „ona” i „on”. Jak podano w poprzednim fragmencie Bonnie i Clyde mogą być programami lub usługi, ale analogia nadal jest ważna. Używanie określeń „ona” i „on” nie musi oznaczać, że Bonnie i Clyde są ludźmi.
Protokół Kerberos rozwiązuje ten problem, określając trzy jednostki: klienta, serwer i zaufaną jednostkę niezależną, która jest pośrednikiem pomiędzy nimi. Ten zaufany pośrednik nosi nazwę Centrum Dystrybucji Kluczy (Key Distribution Center — KDC).
Wskazówka: Obecnie zwiększa się zapotrzebowanie na niezależne firmy dostarczające klucze tajne (key pads) i zarządzające nimi, które działają jako zaufani pośrednicy. Jeśli jesteś przedsiębiorczy i bierzesz pod uwagę możliwość działalności komercyjnej, warto to przemyśleć.
Usługa Centrum Dystrybucji Kluczy (KDC) jest uruchomiona na serwerze, który jest fizycznie zabezpieczony i obsługuje bazę danych o kontach (account information) wszystkich obiektów typu security principal w swoim obszarze (realm), który jest w protokole Kerberos odpowiednikiem domeny systemu Windows 2000. Razem z informacjami o każdym z obiektów typu security principal, Centrum Dystrybucji Kluczy (KDC) przechowuje również klucz szyfru (cryptographic key), znany tylko obiektowi typu security principal i Centrum Dystrybucji Kluczy (KDC). Klucz ten jest używany przy wymianie informacji pomiędzy obiektem zabezpieczeń głównych (security principal) i centrum oraz jest określany jako klucz długoterminowy (long term key). Zazwyczaj uzyskuje się go na podstawie hasła logowania obiektu typu security principal.
Wskazówka: Zamknij serwer Centrum Dystrybucji Kluczy (KDC) w zabezpieczonym pokoju i nie dołączaj klawiatury ani monitora (VDU). Administruj tym serwerem ze stacji roboczej-klienta z zainstalowanym odpowiednim oprogramowaniem. Dokonuj inspekcji każdego dostępu lub próby dostępu do serwera. Jeśli twoje Centrum Dystrybucji Kluczy (KDC) nie jest bezpieczne, to nic innego nie jest bezpieczne.
Klient, który chce skomunikować się z serwerem, wysyła żądanie do Centrum Dystrybucji Kluczy (KDC), które przydziela obu stronom unikatowy, krótkoterminowy (short term) klucz sesji (session key), służący wzajemnemu uwierzytelnianiu. Kopia klucza sesji serwera jest
zaszyfrowana w kluczu długoterminowym (long term) serwera. Kopia klucza sesji klienta jest zaszyfrowana w kluczu długoterminowym klienta. Teoretycznie Centrum Dystrybucji Kluczy (KDC) mogłoby wysyłać klucz sesji (session key) bezpośrednio do każdego obiektu typu security principal, którego to dotyczy, ale w praktyce taka procedura byłaby skrajnie niewydajna. Wymagałaby od serwera zachowywania w pamięci swojego klucza sesji podczas oczekiwania na wywołanie przez klienta. Ponadto serwer musiałby pamiętać klucze dla wszystkich klientów, którzy mogliby żądać obsługi. Zarządzanie kluczami (key management) zajęłoby niewspółmiernie dużą część zasobów serwera i nie dałoby możliwości rozbudowy. Protokół Kerberos rozwiązuje ten problem za pomocą biletów sesji (session tickets).
Zastosowanie biletów sesji (session tickets) Centrum Dystrybucji Kluczy (KDC) odpowiada na żądanie klienta, wysyłając do niego kopię klucza sesji (session key) serwera i klucza sesji (session key) klienta, jak przedstawiono na rysunku 4.2. Kopia klucza sesji klienta jest zaszyfrowana za pomocą klucza, który centrum dystrybucji współdzieli z klientem. Kopia klucza sesji serwera jest umieszczona razem z informacjami o kliencie w strukturze danych o nazwie bilet sesji (session ticket), a cała struktura jest zaszyfrowana za pomocą klucza, który Centrum Dystrybucji Kluczy (KDC) współdzieli z serwerem. Klient korzysta z biletu sesji, kiedy kontaktuje się z serwerem.
Rysunek 4.2. Dystrybucja kluczy Centrum Dystrybucji Kluczy (KDC) nie śledzi swoich komunikatów, aby w ten sposób upewnić się, czy dotarły pod właściwy adres — po prostu wydaje bilet (ticket). Jeśli komunikat wysłany przez centrum (KDC) dostanie się w niepowołane ręce, bezpieczeństwo nie jest zagrożone. Tylko ktoś, kto zna klucz tajny (secret key) klienta może odszyfrować kopię klienta klucza sesji (session key) i tylko ktoś, kto zna klucz tajny (secret key) serwera, może odczytać zawartość biletu (ticket). Klient wyodrębnia bilet i kopię klienta klucza sesji (session key) i umieszcza je w zabezpieczonej pamięci podręcznej (secure cache), znajdującej się w pamięci operacyjnej, a nie na dysku. Kiedy klient chce połączyć się serwerem, wysyła komunikat zawierający bilet (ticket) z wartością
uwierzytelniającą (authenticator) zaszyfrowane za pomocą klucza sesji. Bilet (ticket), nadal zaszyfrowany za pomocą klucza tajnego (secret key) serwera i wartość uwierzytelniająca (authenticator) razem tworzą dane uwierzytelniające (credentials) klienta dla serwera. Serwer odszyfrowuje bilet sesji (session ticket) za pomocą klucza tajnego (secret key), uzyskując w ten sposób klucz sesji (session key) i stosuje go do odszyfrowania wartości uwierzytelniającej (authenticator) klienta. Jeśli wszystko się zgadza, serwer wie, że dane uwierzytelniające (credentials) klienta zostały wydane przez centrum (KDC), które jest jednostką godną zaufania (trusted authority). Jeśli konieczne jest uwierzytelnianie wzajemne (mutual authentication), serwer używa swojej kopii klucza sesji do zaszyfrowania znacznika czasu (timestamp) zawartego w wartości uwierzytelniającej (authenticator) klienta, a wynik przesyła z powrotem do klienta jako wartość uwierzytelniającą (authenticator) serwera. Czyni to w sposób zaprezentowany na rysunku 4.3. Należy zwrócić uwagę, że serwer nie musi przechowywać klucza sesji (session key), którego używa do komunikacji z klientem. Klient jest odpowiedzialny za przechowywanie biletu (ticket) dla serwera w pamięci podręcznej danych uwierzytelniających (credentials cache) i przedstawianie biletu za każdym razem, gdy chce uzyskać dostęp do serwera. Kiedy serwer nie potrzebuje już dłużej klucza sesji (session key), może go odrzucić. Również klient nie musi zwracać się do Centrum Dystrybucji Kluczy za każdym razem, gdy chce uzyskać dostęp do konkretnego serwera, ponieważ bilety sesji (session tickets) mogą być wykorzystane ponownie, o ile nie utraciły ważności. Okres ważności biletu (ticket) zależy od zasad protokołu Kerberos (Kerberos policy) obowiązujących w danej domenie. Zwykle bilety (tickets) są ważne 8 godzin. Kiedy użytkownik wylogowuje się z komputera-klienta, pamięć podręczna danych uwierzytelniających (credentials cache) jest opróżniana, a wszystkie bilety sesji (session tickets) i klucze sesji są niszczone.
Rysunek 4.3. Uwierzytelnianie wzajemne (klient-serwer)
Zastosowanie biletu gwarantującego bilet (Ticket Granting Ticket — TGT)
Dla przykładu przyjmijmy, że Bonnie się loguje. Najpierw klient Kerberos, działający na stacji roboczej, zamienia swoje hasło na klucz kryptograficzny (cryptographic key), stosując jednokierunkową funkcję skrótu (one-way hashing function). Protokół Kerberos korzysta z algorytmu funkcji skrótu DES-CBC-MD5, chociaż dopuszcza się stosowanie innych algorytmów. Następnie klient Kerberos żąda biletu sesji (session ticket) i klucza sesji (session key), które może zastosować w kolejnych transakcjach pomiędzy klientem a Centrum Dystrybucji Kluczy podczas danej sesji logowania. Centrum (KDC) szuka w swojej bazie danych Bonnie i odczytuje z odpowiedniego rekordu bazy danych klucza długoterminowego (long-term key) Bonnie. Proces ten, czyli wyznaczanie kopii klucza na podstawie hasła i pobieranie kolejnej kopii klucza z bazy danych, ma miejsce tylko raz — gdy użytkownik loguje się do sieci. Centrum Dystrybucji Kluczy (KDC) odpowiada na żądanie klienta, zwracając specjalny rodzaj biletu sesji (session ticket), który nosi nazwę bilet gwarantujący bilet (Ticket Granting Ticket — TGT). Tak, jak zwykły bilet sesji (session ticket), bilet gwarantujący bilet (TGT) zawiera kopię klucza sesji (session key), który dana usługa, w tym przypadku Centrum Dystrybucji Kluczy (KDC) będzie stosować do komunikacji z klientem. Pakiet, który zwraca klientowi bilet gwarantujący bilet, zawiera także kopię klucza sesji (session key), który klient może stosować do komunikacji z centrum (KDC). Bilet gwarantujący bilet jest zaszyfrowany w kluczu długoterminowym (long term key) centrum (KDC), a kopia klienta klucza sesji (session key) jest zaszyfrowana w kluczu długoterminowym (long term key) użytkownika. W kolejnych wymianach komunikatów z centrum klient korzysta z klucza sesji (session key). Klucz kryptograficzny (cryptographic key) uzyskany na podstawie hasła użytkownika nie jest potrzebny i może być odrzucony. Tak, jak inne klucze sesji, klucz ten jest tymczasowy, ważny tylko do czasu utraty ważności przez bilet gwarantujący bilet (TGT) lub wylogowania się przez danego użytkownika. Z tego względu nazywany jest kluczem sesji logowania (logon session key). Klient, przed podjęciem próby połączenia z usługą, szuka w buforze danych uwierzytelniających (credentials cache) biletu sesji (session ticket) do danej usługi. Jeśli takiego biletu nie ma, klient szuka w buforze danych uwierzytelniających bilet gwarantujący bilet (TGT). Jeśli ten klucz zostanie znaleziony, klient pobiera z bufora właściwy klucz sesji logowania (logon session key), używa go do przygotowania wartości uwierzytelniającej (authenticator) i wysyła wartość uwierzytelniającą (authenticator) oraz bilet gwarantujący bilet do Centrum Dystrybucji Kluczy (KDC) razem z żądaniem biletu sesji dla tej usługi. Tak więc uzyskanie dostępu do centrum nie różni się niczym od uzyskiwania dostępu do pozostałych usług w domenie — wymagany jest klucz sesji (session key), wartość uwierzytelniająca (authenticator) i bilet (ticket), w tym przypadku jest to bilet gwarantujący bilet (TGT).
Podstawowe wiadomości o podprotokołach (subprotocols) protokołu Kerberos Protokół Kerberos składa się z trzech podprotokołów (subprotocols):
•
Authentication Service (AS) Exchange — stosowany przez Centrum Dystrybucji Kluczy (KDC) do przydzielania klientowi klucza sesji logowania (logon session key) i biletu gwarantującego bilet (TGT),
•
Ticket Granting Service (TGS) Exchange — stosowany przez centrum do przydzielania usłudze klucza sesji usługi (service session key) i biletu sesji (session ticket),
•
Client-Server (CS) Exchange — stosowany, gdy klient przedstawia bilet sesji (session ticket), aby uzyskać dostęp do usługi.
Aby zrozumieć, w jaki sposób te trzy podprotokoły (subprotocols) pracują razem, zobaczmy w jaki sposób Bonnie — użytkownik stacji roboczej uzyskuje dostęp do Clyde’a — usługi sieciowej.
Podprotokół Authentication Service Exchange Wymiana informacji za pomocą podprotokołu Authentication Service Exchange przebiega następująco: 1.
Bonnie loguje się w sieci. Klient Kerberos na stacji roboczej Bonnie zamienia jej hasło na klucz szyfru (encryption key) i zapisuje go w buforze danych uwierzytelniających (credentials cache).
2.
Klient Kerberos wysyła do usługi uwierzytelniania (authentication service) Centrum Dystrybucji Kluczy (KDC) komunikat Kerberos Authentication Service Request (KRB_AS_REQ). Pierwsza część tego komunikatu identyfikuje użytkownika, Bonnie i nazwę usługi, dla której żąda się danych uwierzytelniających (credentials) — usługi wydającej bilety (Ticket Granting Service). Druga część komunikatu zawiera dane do uwierzytelniania wstępnego (preauthentication data), które potwierdzają, że Bonnie zna hasło. Jest to zwykle znacznik czasu (timestamp) zaszyfrowany za pomocą klucza długoterminowego (long term key) Bonnie.
3.
Centrum Dystrybucji Kluczy (KDC) odbiera komunikat KRB_AS_REQ.
4.
Centrum Dystrybucji Kluczy (KDC) wyszukuje w swojej bazie danych użytkownika o nazwie Bonnie, odczytuje jej klucz długoterminowy (long term key), odszyfrowuje dane do uwierzytelniania wstępnego (preauthentication data) i ocenia zawarty w nich znacznik czasu (timestamp). Jeśli znacznik czasu (timestamp) jest do przyjęcia, Centrum Dystrybucji Kluczy (KDC) ma pewność, że dane do uwierzytelniania wstępnego (preauthentication data) zostały zaszyfrowane za pomocą klucza długoterminowego Bonnie i że klient jest autentyczny.
5.
Centrum (KDC) tworzy dane uwierzytelniające (credentials), które klient Kerberos na stacji roboczej Bonnie może przedstawić usłudze wydawania biletów (Ticket Granting Service): •
tworzy klucz sesji logowania (logon session key) i szyfruje jego kopię za pomocą klucza długoterminowego (long term key) Bonnie,
6.
•
umieszcza w bilecie gwarantującym bilet (TGT) jeszcze jedną kopię klucza sesji logowania (logon session key) razem z innymi informacjami dotyczącymi Bonnie, takimi jak jej dane uwierzytelniające (authorization data),
•
szyfruje bilet gwarantujący bilet za pomocą własnego klucza długoterminowego (long term key),
•
wysyła zaszyfrowany klucz sesji logowania (logon session key) i bilet gwarantujący bilet (TGT) z powrotem do klienta w komunikacie Kerberos Authentication Service Reply (KRB_AS_REP).
Klient po odebraniu komunikatu korzysta z klucza, uzyskanego na podstawie hasła Bonnie, do odszyfrowania jej klucza sesji logowania i zapisuje go w buforze danych uwierzytelniających (credentials cache). Następnie wyodrębnia z komunikatu bilet gwarantujący bilet (TGT) i również zapisuje w tym buforze (credentials cache).
Działanie podprotokołu Authentication Service Exchange ilustruje rysunek 4.4.
Rysunek 4.4. Wymiana komunikatów podprotokołu (subprotocol) Authentication Service (AS)
Podprotokół Ticket Granting Service Exchange Po zakończeniu wymiany informacji przez usługę uwierzytelniania (Authentication Service), proces wymiany komunikatów usługi wydawania biletów (Ticket Granting Service) przebiega w następujący sposób: 1.
Klient Kerberos na stacji roboczej Bonnie żąda danych uwierzytelniających dla usługi Clyde, wysyłając do Centrum Dystrybucji Kluczy (KDC) komunikat Kerberos Ticket Granting Service Request (KRB_TGS_REQ). Komunikat ten zawiera nazwę użytkownika, wartość uwierzytelniającą (authenticator) zaszyfrowaną za pomocą klucza sesji logowania (logon session key) użytkownika, bilet gwarantujący bilet (TGT), uzyskany w procesie wymiany
komunikatów usługi uwierzytelniania (Authentication Service) oraz nazwę usługi, dla której użytkownikowi potrzebny jest bilet (ticket). 2.
Centrum (KDC) odbiera komunikat KRB_TGS_REQ i odszyfrowuje bilet gwarantujący bilet (TGT) za pomocą własnego klucza tajnego (secret key), odczytując klucz sesji logowania (logon session key) Bonnie, który jest używany do odszyfrowania wartości uwierzytelniającej (authenticator).
3.
Jeśli wartość uwierzytelniająca (authenticator) jest poprawna, to Centrum Dystrybucji Kluczy odczytuje z biletu gwarantującego bilet (TGT) dane autoryzacji (authorization data) Bonnie i tworzy dla klienta (Bonnie) klucz sesji (session key), który jest współdzielony z usługą (Clyde).
4.
Centrum (KDC) szyfruje jedną kopię tego klucza sesji za pomocą klucza sesji logowania (logon session key) Bonnie, umieszcza inną kopię w bilecie (ticket) razem z danymi autoryzacji Bonnie i szyfruje ten bilet za pomocą klucza długoterminowego (long term key) Clyde’a.
5.
KDC wysyła te dane uwierzytelniające (credentials) z powrotem do klienta w komunikacie Kerberos Ticket Granting Service Reply (KRB_TGS_REP).
6.
Kiedy klient otrzyma odpowiedź, korzysta z klucza sesji logowania (logon session key) Bonnie do odszyfrowania klucza sesji używanego w przypadku danej usługi i zapisuje ten klucz w buforze danych uwierzytelniających (credentials cache). Następnie wyodrębnia bilet (ticket) do danej usługi i także zapisuje to w buforze.
Działanie podprotokołu Ticket Granting Service Exchange ilustruje rysunek 4.5.
Podprotokół Client-Server Exchange Po zakończeniu wymiany komunikatów usługi wydawania biletów (Ticket Granting Service) rozpoczyna się procedura wymiany informacji klient-serwer (CS information exchange): 1.
Klient Kerberos na stacji roboczej (workstation) Bonnie żąda obsługi od Clyde’a, wysyłając mu komunikat Kerberos Application Requests (KRB_AP_REQ). Komunikat ten zawiera wartość uwierzytelniającą zaszyfrowaną za pomocą klucza sesji (session key) danej usługi, bilet (ticket), uzyskany podczas wymiany informacji TGS oraz wstępnie skonfigurowany znacznik (preconfigured flag) wskazujący, czy klient wymaga uwierzytelniania wzajemnego (mutual authentication).
Rysunek 4.5. Komunikaty podprotokołu Ticket Granting Service Exchange 2.
Clyde odbiera komunikat KRB_AP_REQ, odszyfrowuje bilet i odczytuje dane autoryzacji (authorization data) Bonnie oraz klucz sesji (session key).
3.
Clyde korzysta z klucza sesji do odszyfrowania wartości uwierzytelniającej (authenticator) Bonnie i ocenia zawarty w niej znacznik czasu (timestamp).
4.
Jeśli wartość uwierzytelniająca (authenticator) jest prawidłowa, Clyde szuka w komunikacie klienta znacznika uwierzytelniania wzajemnego (mutual authentication flag).
5.
Jeśli znacznik jest ustawiony, usługa korzysta z klucza sesji (session key) do zaszyfrowania czasu zawartego w wartości uwierzytelniającej (authenticator) Bonnie, a wynik zwraca w komunikacie Kerberos Application Reply (KRB_AP_REP).
6.
Gdy klient Kerberos na stacji roboczej Bonnie odbiera komunikat KRB_AP_REP, odszyfrowuje wartość uwierzytelniającą (authenticator) Clyde’a za pomocą klucza sesji (session key) współdzielonego z Clydem i porównuje czas przesłany przez usługę z czasem zawartym w pierwotnej wartości uwierzytelniającej klienta.
7.
Jeśli czas jest ten sam, klient wie, że jest to usługa prawidłowa i połączenie jest utrzymane. W trakcie połączenia klucz sesji (session key) może być użyty do szyfrowania danych aplikacji lub też klient i serwer mogą w tym celu współdzielić inny klucz.
Na rysunku 4.6 przedstawiono proces wymiany komunikatów CS.
Rysunek 4.6. Wymiana komunikatów CS
Uwierzytelnianie logowania Podczas logowania do sieci, w której do uwierzytelniania stosuje się protokół Kerberos, najpierw otrzymuje się bilet gwarantujący bilet (Ticket Granting Ticket — TGT), który przedstawia się, żądając biletów sesji (session tickets) dla innych usług w domenie. Podczas logowania do domeny Windows 2000 zawsze konieczny jest przynajmniej jeden bilet sesji (session ticket) — bilet do komputera, do którego użytkownik się loguje. Komputery pracujące pod kontrolą systemu Windows 2000 mają własne konta w domenie, które należy traktować jako konta usług (service accounts). Użytkownicy interaktywni mogą mieć dostęp do zasobów w domenie Windows 2000 przez wysyłanie żądania do usługi Workstation danego komputera, ale użytkownicy zdalni wysyłają żądania do usługi Server tego komputera. Przed uzyskaniem dostępu do którejkolwiek z wyżej wymienionych usług lub jakiejkolwiek innej usługi, pracującej jako system lokalny (local system), należy przedstawić bilet sesji dla danego komputera. Przypuśćmy, że Bonnie ma konto sieciowe w domenie o nazwie West i loguje się do komputera o nazwie Clyde, który również ma konto w domenie West. Bonnie rozpoczyna od sekwencji Secure Attention Sequence (SAS) Ctrl+Alt+Delete. Usługa WinLogon na komputerze o nazwie Clyde, przełącza się na pulpit logowania (logon desktop) i uzyskuje dostęp do biblioteki dołączanej dynamicznie (Dynamic Link Library — DLL) Graphical Identification and Authentication (GINA), msgina.dll, która odpowiada za zbieranie od użytkowników danych logowania, pakowanie ich do struktury danych i wysyłanie całości do Lokalnej Jednostki Certyfikującej (Local Security Authority — LSA) w celu weryfikacji. Bonnie wpisuje swoją nazwę użytkownika oraz hasło i z listy rozwijalnej wybiera domenę West. Po naciśnięciu OK. biblioteka DLL MSGINA zwraca informacje logowania Bonnie do usługi WinLogon, która — korzystając z wywołania API LsaLogonUser — wysyła dane do Lokalnej Jednostki Certyfikującej (LSA) w celu sprawdzenia. Lokalna Jednostka Certyfikująca (LSA), po otrzymaniu struktury danych z danymi logowania Bonnie, natychmiast zamienia niezabezpieczone, podane zwykłym tekstem, hasło na klucz tajny (secret key) za pomocą jednokierunkowej funkcji skrótu (one-way hashing function). Wynik
zostanie zapisany w buforze danych uwierzytelniających (credentials cache), skąd może być pobrany w razie potrzeby do odnowienia biletu gwarantującego bilet (TGT) lub uwierzytelniania za pomocą protokołu NTLM w przypadku serwerów, dla których nie można dokonać autoryzacji za pomocą protokołu Kerberos. Aby sprawdzić informacje logowania Bonnie i ustanowić dla niej sesję logowania na danym komputerze, Lokalna Jednostka Certyfikująca (Local Security Authority — LSA) musi otrzymać bilet gwarantujący bilet (TGT), który jest odpowiedni do uzyskania dostępu do usługi gwarantującej bilet (Ticket Granting Service) oraz bilet sesji odpowiedni do uzyskania dostępu do komputera. Lokalna Jednostka Certyfikująca otrzymuje te bilety, korzystając z usługi Usługodawca Obsługi Zabezpieczeń (Security Support Provider — SSP), która wymienia komunikaty bezpośrednio z Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) w domenie West. Kolejność komunikatów jest następująca: 1.
2.
3.
Lokalna Jednostka Certyfikująca (LSA) wysyła komunikat KRB_AS_REQ do Centrum Dystrybucji Kluczy (KDC) w domenie West. Komunikat zawiera: •
nazwę główną (principal name) użytkownika, Bonnie,
•
nazwę domeny konta, West,
•
dane uwierzytelnienia wstępnego (preauthentication data) zaszyfrowane za pomocą klucza tajnego (secret key) uzyskanego z hasła Bonnie.
Jeśli dane uwierzytelniania wstępnego (preauthentication data) są poprawne, wówczas centrum (KDC) odpowiada komunikatem KRB-AS_REP. Komunikat ten zawiera: •
klucz sesji (session key) dla Bonnie, który będzie współdzielony z Centrum Dystrybucji Kluczy, zaszyfrowany za pomocą klucza tajnego (secret key), uzyskanego z hasła Bonnie,
•
bilet gwarantujący bilet (Ticket Granting Ticket — TGT) dla Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) w domenie West zaszyfrowany za pomocą klucza tajnego Centrum Dystrybucji Kluczy. Bilet gwarantujący bilet zawiera klucz sesji (session key) dla centrum (KDC), który będzie współdzielony z Bonnie oraz dane autoryzacji (authorization data) dla Bonnie. Dane te zawierają identyfikator zabezpieczeń (Security Identifier — SID) dla konta Bonnie, identyfikatory zabezpieczeń (SIDs) dla grup zabezpieczeń (security groups) w domenie West, do której należy Bonnie oraz identyfikatory zabezpieczeń dla grup uniwersalnych (universal groups) w przedsiębiorstwie, do których należy Bonnie lub jedna z jej grup domeny (domain groups).
Lokalna Jednostka Certyfikująca (LSA) wysyła do Centrum Dystrybucji Kluczy (KDC) w domenie West komunikat KRB_TGS_REQ. Komunikat ten zawiera: •
nazwę komputera docelowego, Clyde,
•
nazwę domeny komputera docelowego, West,
•
bilet gwarantujący bilet (TGT) Bonnie,
•
wartość uwierzytelniającą (authenticator) zaszyfrowaną za pomocą klucza sesji (session key), który Bonnie współdzieli z centrum (KDC).
4.
Centrum Dystrybucji Kluczy odpowiada komunikatem KRB_TGS_REP. Komunikat ten zawiera: •
klucz sesji (session key) dla Bonnie, który będzie współdzielony z Clydem., zaszyfrowany za pomocą klucza sesji Bonnie, który użytkownik ten współdzieli z Centrum Dystrybucji Kluczy,
•
bilet sesji Bonnie do komputera o nazwie Clyde, zaszyfrowany za pomocą klucza tajnego, który Clyde współdzieli z Centrum Dystrybucji Kluczy (KDC). Bilet sesji zawiera klucz sesji dla komputera o nazwie Clyde, skopiowany z biletu gwarantującego bilet Bonnie, który będzie współdzielony z Bonnie oraz dane autoryzacji (authorization data).
Gdy Lokalna Jednostka Certyfikująca (LSA) otrzymuje bilet sesji (session ticket) Bonnie, odszyfrowuje go za pomocą klucza tajnego (secret key) komputera i odczytuje dane autoryzacji (authorization data) Bonnie. Następnie wysyła kwerendy (queries) do lokalnej bazy danych SAM (Security Accounts Manager) aby poszukać, czy Bonnie jest członkiem lokalnej grupy zabezpieczeń na tym komputerze i czy nadano temu użytkownikowi uprawnienia specjalne na danym komputerze lokalnym. Każdy z identyfikatorów zabezpieczeń (SIDs), zwrócony przez kwerendę, jest dodawany do listy uzyskanej z danych autoryzacji (authorization data) biletu. Cała lista jest następnie używana do budowania znacznika dostępu (access token), a dojście (handle) do znacznika dostępu (access token) jest zwracane do usługi WinLogon razem z identyfikatorem sesji logowania (logon session) Bonnie i potwierdzeniem, że informacje logowania są prawidłowe. WinLogon dla użytkownika o nazwie Bonnie tworzy stację (window station) i kilka obiektów pulpitu (desktop objects), dołącza znacznik dostępu (access token) Bonnie i uruchamia powłokę (shell process), z której Bonnie korzysta przy pracy interaktywnej z komputerem. Każda aplikacja, którą Bonnie uruchomi w trakcie swojej sesji logowania (logon session), dziedziczy jej znacznik dostępu. Należy zwrócić uwagę, że w trakcie procesu opisanego poprzednio ten sam klucz jest używany zarówno do szyfrowania, jak i odszyfrowania. Z tego powodu klucze tajne (shared secret keys) stosowane do logowania za pomocą hasła (password logon) są symetryczne (symmetric).
Logowanie za pomocą kart elektronicznych (smart card logon) Do obsługi logowania za pomocą kart elektronicznych (smart card logons) w systemie Windows 2000 zaimplementowano rozszerzenie zakresu funkcji wstępnej wymiany komunikatów usługi uwierzytelniania (Authentication Service) protokołu Kerberos, które dotyczy stosowania klucza publicznego (public key). Kryptografia klucza publicznego (public key cryptography) jest niesymetryczna (asymmetric), tzn. konieczne są dwa klucze; jeden do szyfrowania, a drugi do odszyfrowania. Razem klucze te tworzą parę kluczy prywatny-publiczny (private key-public key). Klucz prywatny jest znany tylko właścicielowi danej pary kluczy i nie jest nigdy współdzielony. Klucz publiczny może być znany każdemu, z kim właściciel będzie wymieniał poufne informacje.
Kiedy zamiast hasła stosuje się kartę elektroniczną (smart card) para kluczy prywatny-publiczny zapisana na karcie elektronicznej użytkownika zastępuje klucz tajny (shared secret key) uzyskany z hasła użytkownika. W przypadku rozszerzenia protokołu Kerberos, dotyczącego klucza publicznego, wstępna wymiana komunikatów usługi uwierzytelniania (initial Authentication Service information exchange) jest zmodyfikowana w ten sposób, że Centrum Dystrybucji Kluczy szyfruje klucz sesji logowania (logon session key) użytkownika za pomocą publicznej części pary kluczy prywatny-publiczny użytkownika. Klient odszyfrowuje klucz sesji logowania za pomocą prywatnej połowy pary kluczy prywatny-publiczny. Logowanie za pomocą kart elektronicznych przebiega w następujący sposób: 1.
Użytkownik wkłada kartę elektroniczną (smart card) do czytnika kart dołączonego do danego komputera. Jeśli komputery z systemem Windows 2000 są skonfigurowane tak, aby można było korzystać z logowania za pomocą kart elektronicznych (smart card), włożenie karty jest równoważne sekwencji Secure Attention Sequence (SAS).
2.
WinLogon wysyła komunikat do biblioteki DLL o nazwie MSGINA, która wyświetla okno dialogowe Informacje logowania (logon information).
3.
Użytkownik wpisuje numer PIN (Personal Identification Number).
4.
Biblioteka DLL MSGINA wysyła informacje logowania użytkownika do lokalnej jednostki certyfikującej, korzystając z wywołania API LsaLogonUser.
5.
Lokalna Jednostka Certyfikująca (Local Security Authority — LSA) korzysta z numeru PIN, aby uzyskać dostęp do karty elektronicznej (smart card), na której zapisany jest klucz prywatny użytkownika oraz certyfikat X.509v3, zawierający publiczną połowę z pary kluczy prywatny-publiczny. Wszystkie operacje kryptograficzne korzystające z tych kluczy mają miejsce na karcie elektronicznej.
6.
Usługodawca Obsługi Zabezpieczeń (SSP) Kerberos na komputerze klienta wysyła w komunikacie żądania uwierzytelnienia wstępnego, KRB_AS_REQ, certyfikat z kluczem publicznym (public key certificate) użytkownika do Centrum Dystrybucji Kluczy (KDC) jako dane uwierzytelniania wstępnego (preauthentication data).
7.
Centrum Dystrybucji Kluczy sprawdza poprawność certyfikatu i odczytuje klucz publiczny (public key), który używa do szyfrowania klucza sesji logowania (logon session key). W komunikacie wysyłanym w odpowiedzi do klienta, KRB_AS_REP, zwraca zaszyfrowany klucz sesji logowania (logon session key) i bilet gwarantujący bilet (TGT).
8.
Jeśli klient posiada prywatną połowę z pary kluczy prywatny-publiczny, korzysta z klucza prywatnego (pivate key) do odszyfrowania klucza sesji logowania (logon session key).
Następnie zarówno klient, jak i Centrum Dystrybucji Kluczy korzystają z klucza sesji logowania do wymiany dwustronnej informacji. Nie ma innych odchyleń od protokołu standardowego. Usługodawca Obsługi Zabezpieczeń Kerberos (Kerberos SSP), działający na komputerze klienta, domyślnie wysyła dane uwierzytelniania wstępnego do Centrum Dystrybucji Kluczy (KDC preauthentication data) w postaci zaszyfrowanego znacznika czasu (timestamp). W systemach, w których zastosowano logowanie za pomocą kart elektronicznych (smart card), Usługodawca Obsługi Zabezpieczeń Kerberos (Kerberos SSP) wysyła dane uwierzytelniania wstępnego w postaci klucza publicznego. W rozdziale 6. znajduje się dokładniejszy opis kluczy publicznych, a w rozdziale 9. opisano szerzej korzystanie z kart elektronicznych (smart cards).
Uwierzytelnianie przekraczające granice domeny Funkcje Centrum Dystrybucji Kluczy są podzielone na dwie odmienne usługi: usługę uwierzytelniania, która wydaje bilety gwarantujące bilet oraz usługę wydawania biletów (Ticket Granting Service — TGS), która wydaje bilety sesji (session tickets). Umożliwia to protokołowi Kerberos przekraczanie granic domen. Klient może otrzymać bilet gwarantujący bilet od usługi uwierzytelniania (authentication service) w jednej domenie i użyć go do uzyskania biletów sesji od usługi wydawania biletów (TGS) z innej domeny. Po pierwsze rozważmy sieć, w której istnieją dwie domeny systemu Windows 2000, East i West. Jeśli ustanowiono relację zaufania (trust relationship), uwierzytelnianie przekraczające granice domeny zaimplementowano przez współdzielenie klucza międzydomenowego (interdomain key). Usługa wydawania biletów (Ticket Granting Service — TGS) w każdej z domen jest zarejestrowana jako obiekt typu security principal z centrami dystrybucji kluczy innych domen i usługa wydawania biletów (TGS) w każdej domenie może traktować tę samą usługę w innych domenach jako po prostu jeszcze jedną usługę, dla której klienci, uzyskawszy poprawne uwierzytelnienie, mogą żądać i uzyskać bilety sesji (session tickets). Kiedy użytkownik, którego konto znajduje się w domenie East chce uzyskać dostęp do serwera, którego konto znajduje się w domenie West, proces uwierzytelniania przebiega w następujący sposób: 1.
Klient Kerberos na stacji roboczej użytkownika wysyła żądanie biletu sesji (session ticket) do usługi wydawania biletów (Ticket Granting Service — TGS) w domenie East.
2.
Usługa wydawania biletów (TGS) w domenie East widzi, że pożądany serwer nie jest obiektem typu security principal w tej domenie i odpowiada, wysyłając klientowi bilet referencyjny (referral ticket), tzn. bilet gwarantujący bilet (TGT), zaszyfrowany za pomocą klucza międzydomenowego (interdomain key), który Centrum Dystrybucji Kluczy (KDC) w domenie East współdzieli z Centrum Dystrybucji Kluczy (KDC) w domenie West.
3.
Klient korzysta z biletu referencyjnego (referral ticket) do przygotowania drugiego żądania biletu sesji (session ticket) i tym razem wysyła żądanie do usługi wydawania biletów (TGS) w domenie West.
4.
Usługa wydawania biletów w domenie West używa swojej kopii klucza międzydomenowego do odszyfrowania biletu referencyjnego (referral ticket). Jeśli bilet referencyjny zostanie odszyfrowany prawidłowo, usługa wydawania biletów (TGS) wysyła klientowi bilet sesji (session ticket) do żądanego serwera w tej domenie.
Tam, gdzie istnieje drzewo domen (domain tree), klient z jednej domeny może uzyskać bilet do serwera w innej domenie, przechodząc ścieżką referencyjną (referral path) przez jedną lub kilka domen pośrednich. Przykład przedstawiono na rysunku 4.7.
Rysunek 4.7. Uwierzytelnianie poprzez granice domeny W firmie, w której pracuje Bonnie, jest domena nadrzędna (parent domain) coriolis.com oraz dwie domeny podrzędne (children domains), east.coriolis.com i west.coriolis.com. Bonnie loguje się na swoje konto w domenie west.coriolis.com i otrzymuje bilet gwarantujący bilet do Centrum Dystrybucji Kluczy w tej domenie. Bonnie potrzebny jest dostęp do dokumentów zapisanych w udziale publicznym (public share) na serwerze w domenie east.coriolis.com o nazwie Clyde. Ponieważ domena, w której Bonnie ma swoje konto jest inna niż domena serwera plików (file server), Usługodawca Obsługi Zabezpieczeń (SSP) na stacji roboczej Bonnie musi dostać bilet gwarantujący bilet (Ticket Granting Ticket) dla domeny east.coriolis.com i użyć go, by uzyskać bilet dla serwera. Proces referencyjny (referral process) przebiega w następujący sposób: 1.
2.
Stacja robocza Bonnie wysyła komunikat KRB_TGS_REQ do Centrum Dystrybucji Kluczy w domenie west.coriolis.com, który zawiera: •
nazwę komputera docelowego, Clyde,
•
nazwę domeny, w której znajduje się komputer docelowy, east.coriolis.com,
•
bilet gwarantujący bilet, który daje dostęp do Centrum Dystrybucji Kluczy w domenie west.coriolis.com,
•
wartość uwierzytelniającą (authenticator) zaszyfrowaną za pomocą klucza sesji (session key), który Bonnie współdzieli z wyżej wymienionym Centrum Dystrybucji Kluczy.
Centrum Dystrybucji Kluczy (KDC) w domenie west.coriolis.com wysyła komunikat KRB_TGS_REP. Komunikat ten zawiera:
3.
4.
5.
6.
•
klucz sesji (session key), który Bonnie będzie współdzielić z Centrum Dystrybucji Kluczy z domeny nadrzędnej (parent domain) coriolis.com zaszyfrowany za pomocą klucza sesji logowania (logon session key) Bonnie,
•
bilet gwarantujący bilet, który daje dostęp do Centrum Dystrybucji Kluczy w domenie coriolis.com zaszyfrowany za pomocą klucza tajnego (secret key) dla relacji zaufania (trust relationship) pomiędzy dwoma domenami coriolis.com i west.coriolis.com.
Stacja robocza Bonnie wysyła do Centrum Dystrybucji Kluczy (KDC) w domenie coriolis.com komunikat KRB_TGS_REQ, który zawiera: •
nazwę komputera docelowego, Clyde,
•
nazwę domeny, w której znajduje się komputer docelowy, east.coriolis.com,
•
bilet gwarantujący bilet, który daje dostęp do Centrum Dystrybucji Kluczy w domenie coriolis.com,
•
wartość uwierzytelniającą (authenticator) zaszyfrowaną za pomocą klucza sesji, który Bonnie współdzieli z wyżej wymienionym Centrum Dystrybucji Kluczy.
Centrum Dystrybucji Kluczy w domenie coriolis.com wysyła komunikat KRB_TGS_REP. Komunikat ten zawiera: •
bilet gwarantujący bilet, który daje dostęp do centrum w domenie east.coriolis.com, zaszyfrowany za pomocą klucza tajnego dla relacji zaufania (trust relationship) pomiędzy dwoma domenami,
•
klucz sesji (session key) dla Bonnie, który będzie współdzielony z wymienionym wyżej Centrum Dystrybucji Kluczy zaszyfrowany za pomocą klucza sesji (session key), który Bonnie współdzieli z Centrum Dystrybucji Kluczy w domenie coriolis.com.
Stacja robocza Bonnie wysyła do Centrum Dystrybucji Kluczy w domenie east.coriolis.com komunikat KRB_TGS_REQ. Komunikat ten zawiera: •
nazwę komputera docelowego, Clyde,
•
nazwę domeny, w której znajduje się komputer docelowy, east.coriolis.com,
•
bilet gwarantujący bilet, który daje dostęp do Centrum Dystrybucji Kluczy w domenie east.coriolis.com,
•
wartość uwierzytelniającą (authenticator) zaszyfrowaną za pomocą klucza sesji, który Bonnie współdzieli z wymienionym wyżej Centrum Dystrybucji Kluczy (KDC).
Centrum Dystrybucji Kluczy w domenie east.coriolis.com wysyła komunikat KRB_TGS_REP, który zawiera: •
klucz sesji (session key) dla Bonnie, który będzie współdzielić z komputerem o nazwie Clyde, zaszyfrowany za pomocą klucza sesji (session key) współdzielonego przez Bonnie z Centrum Dystrybucji Kluczy w domenie east.coriolis.com,
•
bilet sesji (session ticket), który daje dostęp do komputera o nazwie Clyde, zaszyfrowany za pomocą klucza tajnego (secret key), współdzielonego przez Clyde’a z Centrum Dystrybucji Kluczy. Bilet sesji zawiera klucz sesji (session key), który komputer o nazwie Clyde będzie współdzielił z Bonnie, dane autoryzacji (authorization data), skopiowane z
biletu gwarantującego bilet Bonnie oraz dane dla domeny lokalnej (local domain) east.coriolis.com. Dane autoryzacji zawierają identyfikator zabezpieczeń (Security ID) konta Bonnie, identyfikatory zabezpieczeń (SIDs) dla grup w domenie west.coriolis.com, których członkiem jest Bonnie, identyfikatory zabezpieczeń (SIDs) grup uniwersalnych (universal groups), których członkiem jest Bonnie lub jedna z grup, w której jest członkiem, z domeny west.coriolis.com oraz identyfikatory zabezpieczeń (SIDs) dla grup w domenie east.coriolis.com, których członkiem jest Bonnie, jedna z jej grup z domeny west.coriolis.com lub jedna z jej grup uniwersalnych (universal groups). 7.
8.
Stacja robocza Bonnie wysyła do komputera o nazwie Clyde komunikat KRB_AP_REQ. Komunikat ten zawiera: •
nazwę główną użytkownika (user principal name), Bonnie,
•
bilet do komputera o nazwie Clyde,
•
wartość uwierzytelniającą (authenticator) zaszyfrowany za pomocą klucza sesji (session key), który Bonnie współdzieli z komputerem o nazwie Clyde.
Komputer o nazwie Clyde odpowiada komunikatem KRB_AP_REP, który zawiera wartość uwierzytelniającą (authenticator) zaszyfrowany za pomocą klucza sesji (session key), który Clyde współdzieli z Bonnie.
Analiza biletów protokołu Kerberos (Kerberos tickets) Co zawierają bilety protokołu Kerberos? W jaki sposób oblicza się czas wygaśnięcia (expiration time)? Jak dużą część zawartości biletu jest znana klientowi? Odpowiedzi na te pytania są ważne, jeśli bierze się pod uwagę sposób konfigurowania zasad protokołu Kerberos (Kerberos policy).
Zawartość biletu W tej części rozdziału wymieniono pola biletu i opisano krótko, jakie informacje zwierają. Dokładne struktury danych biletów (tickets), jak również komunikatów (messages) można znaleźć w dokumencie RFC 1510 („Usługa uwierzytelniania sieciowego Kerberos 5”„ — „The Kerberos Network Authentication Service 5”) z września 1993, którego autorami są: J. Kohl i C. Neumann. W tabeli 4.1. zamieszczono pierwsze trzy pola biletu. Nie są one zaszyfrowane; informacje zapisane są w postaci zwykłego tekstu, więc klient może je wykorzystać do zarządzania biletami znajdującymi się w buforze.
Pozostałe pola są zaszyfrowane za pomocą klucza tajnego (secret key) serwera. Pola te przedstawiono w tabeli 4.2. Pole Znaczniki (Flags) jest polem bitowym, w którym opcje konfiguruje się, ustawiając lub kasując poszczególne bity. Chociaż pole to ma długość 32 bitów, tylko kilka znaczników biletu (ticket flags) jest interesujących. Przedstawiono je w tabeli 4.3. Klienci powinny znać niektóre informacje znajdujące się w biletach (tickets) i biletach gwarantujących bilety (TGTs), aby zarządzać swoim buforem danych uwierzytelniających (credentials cache). Centrum Dystrybucji Kluczy (KDC), zwracając bilet i klucz sesji (session key) jako wynik wymiany komunikatów usługi uwierzytelniania (AS information exchange) lub usługi wydawania biletów (TGS information exchange), umieszcza kopię klucza sesji klienta w strukturze danych, która zawiera informacje w polach biletu (ticket fields) Znaczniki (Flags), Authtime, Starttime, Endtime i Renew-till. Cała struktura jest zaszyfrowana w kluczu klienta i zwracana za pomocą komunikatów KRB_AS_REP i KRB_TGS_REP. Tabela 4.1. Pola biletu zawierające dane zapisane zwykłym tekstem Nazwa pola
Opis
Tkt-vno
Numer wersji formatu biletu (ticket format). W przypadku protokołu Kerberos 5 w polu tym zapisana jest 5.
Obszar (realm)
Nazwa obszaru (realm) — domeny, w której wydano dany bilet. Centrum dystrybucji kluczy (Key Distribution Centre — KDC) może wydawać bilety tylko dla serwerów we własnym obszarze (realm), więc jest to także nazwa obszaru (realm) serwera.
Sname
Nazwa serwera
Tabela 4.2. Zaszyfrowane pola biletu Nazwa pola
Opis
Znaczniki (flags)
Opcje biletu
Klucz (key)
Klucz sesji
Crealm
Nazwa obszaru (realm) — domeny klienta
Cname
Nazwa klienta
Transited
Lista obszarów protokołu Kerberos biorących udział w uwierzytelnianiu klienta, któremu wydano dany bilet.
Authtime
Czas pierwszego uwierzytelniania przez klienta. Centrum dystrybucji kluczy (KDC) umieszcza w tym znacznik czasu (timestamp), gdy wyda bilet gwarantujący bilet (Ticket Granting Bilet — TGT). Kiedy Centrum Dystrybucji Kluczy wydaje bilety na podstawie biletu gwarantującego bilet,
zapisuje kopię czasu pierwszego uwierzytelnienia biletu gwarantującego bilet (TGT) w polu Authtime w bilecie. Starttime
Czas, po którym bilet jest ważny
Endtime
Data ważności biletu
Renew-till
Maksymalny okres ważności, który można ustawić w bilecie za pomocą znacznika RENEW-ABLE. (opcja)
Caddr
Jeden lub kilka adresów, z których danych bilet może być wykorzystany. Jeśli pole jest wolne, bilet może być użyty z dowolnego adresu (opcja)
Authorization Data
Atrybuty uprawnień dla klienta. Protokół Kerberos nie interpretuje zawartości tego pola. Interpretacja jest dokonywana przez usługę (opcja)
Tabela 4.3. Znaczniki biletu Nazwa znacznika
Opis
FORWARDABLE
Informuje usługę wydawania biletów (Ticket Granting Service — TGS), że może wydać nowy bilet gwarantujący bilet (Ticket Granting Ticket — TGT) z innym adresem sieciowym na podstawie przedstawionego biletu gwarantującego bilet (tylko w przypadku biletów gwarantujących bilet (TGTs).
FORWARDED
Wskazuje, że bilet gwarantujący bilet został przekazany dalej lub, że dany bilet został wydany z przekazanego dalej biletu gwarantującego bilet.
PROXIABLE
Informuje usługę wydawania biletów (TGS), że może wydawać bilety z innymi adresem sieciowym niż ten, który znajduje się w danym bilecie gwarantującym bilet (TGT) (tylko w przypadku biletów gwarantujących bilety).
PROXY
Wskazuje, że adres sieciowy w bilecie jest inny niż adres w bilecie gwarantującym bilet (TGT) użytym do uzyskania danego biletu.
RENEWABLE
Używany w kombinacji z polami Endtime i Renew-till, aby bilety z długim okresem ważności były odświeżane okresowo w Centrum Dystrybucji Kluczy (KDC).
INITIAL
Wskazuje, że jest to bilet gwarantujący bilet (tylko w przypadku biletów gwarantujących bilety — TGT).
Ograniczanie czasu życia biletu
Bilety protokołu Kerberos mają określony czas początkowy (start time) i czas ważności (expiration time). W okresie ważności biletu klient, który otrzymał ten bilet do realizacji pewnej usługi, może go przedstawić i uzyskać dostęp do tej usługi, bez względu na to, ile razy korzystał wcześniej z danego biletu. Aby ograniczyć zagrożenia dla bezpieczeństwa biletu lub odpowiadającemu mu klucza sesji (session key), administratorzy mogą ustawić maksymalny czas „życia” biletów. Kiedy klient żąda od Centrum Dystrybucji Kluczy (KDC) biletu do jakiejś usługi, może żądać określonego czasu początkowego (start time). Jeśli żądanie nie zawiera tego czasu lub on minął, Centrum Dystrybucji Kluczy wpisujeczas aktualny w polu Starttime biletu. Niezależnie od tego, czy klienci podają czasy początkowe (start times) ich żądania muszą zawierać wymagany czas ważności (expiration time). Centrum Dystrybucji Kluczy ustala wartość zapisaną w polu Endtime danego biletu, dodając maksymalną wartość okresu ważności biletu, podaną w zasadach protokołu Kerberos (Kerberos policy), do wartości zapisanej w polu Starttime tego biletu a następnie porównuje wynik z wymaganym czasem ważności (expiration time) biletu. Zostanie ten czas, który jest wcześniejszy. Centrum Dystrybucji Kluczy nie powiadamia klientów, kiedy kończy się okres ważności biletów sesji (session tickets) lub biletów gwarantujących bilety (TGTs). Jeśli klient, żądając połączenia z serwerem, przedstawia bilet sesji, który utracił ważność, to serwer odsyła komunikat o błędzie i klient musi uzyskać nowy bilet sesji (session ticket) z Centrum Dystrybucji Kluczy (Key Distribution Center — KDC). Jednak jeśli połączenie zostało uwierzytelnione, to nie ma znaczenia czy bilet sesji (session ticket) traci ważność w tej sesji. Bilety sesji (session tickets) używane są tylko do uwierzytelniania nowych połączeń z serwerem i operacje w toku nie są przerywane w przypadku utraty ważności biletu sesji (session ticket). W przypadku, gdy klient, żądając od Centrum Dystrybucji Kluczy biletu sesji (session ticket), przedstawi bilet gwarantujący bilet, który utracił ważność, wówczas centrum (KDC) odpowiada komunikatem o błędzie. Klient musi zażądać nowego biletu gwarantującego bilet, jak i potrzebny mu będzie klucz długoterminowy (long term key) użytkownika. Jeśli podczas wstępnego logowania (initial logon process) klient nie zapisał tego klucza w buforze, to może zażądać hasła użytkownika.
Odnawialne bilety protokołu Kerberos Jednym ze sposobów obrony przeciwko „atakom na klucze sesji” (session keys) jest takie ustanowienie zasad protokołu Kerberos (Kerberos policy), aby maksymalny okres ważności biletu był stosunkowo krótki. Innym ze sposobów obrony jest umożliwienie stosowania biletów odnawialnych (renewable tickets). Gdy bilety są odnawialne, to klucze sesji (session keys) są odświeżane okresowo bez wydawania zupełnie nowego biletu. Jeśli zasady protokołu Kerberos (Kerberos policies) zezwalają na stosowanie biletów odnawialnych (renewable tickets), to Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) ustawia znacznik RENEWABLE w każdym bilecie, który wydaje i ustawia w nim dwa czasy ważności (expiration times). Pierwszy czas ogranicza okres ważności bieżącej postaci (instance) danego biletu, a drugi ogranicza łączny okres ważności wszystkich postaci (instance) danego biletu.
Czas ważności (expiration time) bieżącej postaci (instance) danego biletu jest zapisany w polu Endtime. Klient, który ma bilet odnawialny musi wysłać go do Centrum Dystrybucji Kluczy, aby został odnowiony, zanim osiągnięty zostanie czas zapisany w polu Endtime, przedstawiając także nową wartość uwierzytelniającą (authenticator). Kiedy centrum otrzyma bilet do odnowienia, sprawdza drugi, łączny czas ważności (expiration time) zapisany w polu Renew-till i upewnia się, czy ten czas już nie upłynął. Następnie wydaje nową postać (instance) biletu z późniejszym czasem ważności Endtime i nowym kluczem sesji.Oznacza to, że administrator może ustalić zasady protokołu Kerberos (Kerberos policies), tak aby bilety musiały być odnawiane w stosunkowo krótkich okresach czasu, ponieważ w takich sytuacjach wydawany jest nowy klucz sesji (session key), co minimalizuje straty, które mogłyby powstać w wyniku zagrożeń bezpieczeństwa klucza. Administratorzy mogą również podać stosunkowo długi łączny czas ważności biletu, po upływie którego bilet traci ostatecznie ważność i nie podlega odnowieniu.
Delegowanie uwierzytelniania W wielowarstwowych (multitier) aplikacjach klient-serwer, klient łączy się z serwerem, który z kolei musi połączyć się z drugim, wewnętrznym serwerem (back-end server). Aby do tego doszło, pierwszy serwer musi mieć bilet do drugiego. Byłoby doskonale, gdyby bilet ograniczał prawo dostępu pierwszego serwera do drugiego w sytuacjach, w których klient, a nie pierwszy serwer, jest upoważniony. W protokole Kerberos rozwiązano ten problem za pomocą mechanizmu zwanego Delegowaniem Uwierzytelniania (Delegation of Authentication), który polega na delegowaniu przez klienta uwierzytelnienia do serwera poprzez poinformowanie Centrum Dystrybucji Kluczy (KDC), że serwer jest uprawniony do reprezentowania tego klienta. Jest to idea podobna do personifikacji (impersonation) występującej w systemie Windows 2000. Delegowania można dokonać na dwa sposoby: •
bilety pośrednie (proxy tickets) — klient otrzymuje bilet dla serwera wewnętrznego (back-end server), a następnie przekazuje go do serwera zewnętrznego (front-end server). Trudność stosowania tego sposobu polega na tym, że klient musi znać nazwę serwera wewnętrznego (back-end server),
•
bilety przekazywane (forwarded tickets) — klient daje serwerowi zewnętrznemu (frontend server) bilet gwarantujący bilet (TGT), który serwer może w razie potrzeby używać do żądania biletów.
Zasady domen protokołu Kerberos (Kerberos domain policies) mogą korzystać tylko z jednej z tych metod.
Bilety pośrednie (proxy tickets) Kiedy Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) wydaje klientowi bilet gwarantujący bilet (Ticket Granting Ticket — TGT), sprawdza, czy zasady protokołu Kerberos (Kerberos policies) dopuszczają używanie biletów pośrednich (proxy tickets). Jeśli tak jest, Centrum Dystrybucji Kluczy ustawiaznacznik PROXIABLE w wydanym danemu klientowi bilecie gwarantującym bilet. Klient uzyskuje bilet pośredni, przedstawiając bilet gwarantujący bilet (TGT) usłudze wydawania biletów (Ticket Granting Service — TGS) i żądając biletu do serwera wewnętrznego (back-end server). Żądanie wysłane przez klienta zawiera znacznik, który sygnalizuje, że konieczny jest bilet pośredni (proxy ticket), a także nazwę serwera, który będzie reprezentował tego klienta. Kiedy centrum (KDC) otrzymuje żądanie klienta, tworzy bilet dla serwera wewnętrznego (back-end server), ustawia w tym bilecie znacznik PROXY i wysyła z powrotem do klienta. Następnie klient wysyła bilet do serwera zewnętrznego (front-end server), który korzysta z tego biletu, aby uzyskać dostęp do serwera wewnętrznego.
Bilety przekazywane (forwarded tickets) Jeśli klient chce delegować do serwera zewnętrznego (front-end server) zadanie uzyskiwania biletów dla serwera wewnętrznego (back-end server), to żąda od Centrum Dystrybucji Kluczy (KDC) przekazywalnego (forwardable) biletu gwarantującego bilet (TGT). Klient robi to za pomocą komunikatu żądania podprotokołu Authentication Service Exchange, wskazując Centrum Dystrybucji Kluczy nazwę serwera, który będzie działał w jego imieniu. Jeśli zasady (policies) protokołu Kerberos zezwalają na przekazywanie (forwarding), to Centrum Dystrybucji Kluczy (KDC) tworzy bilet gwarantujący bilet (TGT) dla serwera zewnętrznego,który jest używany w imieniu klienta, ustawia znacznik FORWARDABLE i wysyła bilet gwarantujący bilet z powrotem do klienta. Następnie klient przekazuje ten bilet do serwera zewnętrznego (front-end serwer). Serwer zewnętrzny (front-end server), żądając biletu do serwera wewnętrznego (back-end serwer) przedstawia Centrum Dystrybucji Kluczy bilet gwarantujący bilet klienta. Centrum, wydając bilet, sprawdza znacznik FORWARDABLE w tym bilecie gwarantującym bilet (TGT), ustawia w wydawanym bilecie znacznik FORWARDED i zwraca bilet do serwera zewnętrznego.
Konfigurowanie zasad domeny protokołu Kerberos (Kerberos domain policies)
W systemie Windows 2000 zasady (policies) protokołu Kerberos są określane na poziomie domeny i wprowadzane w życie przez Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) danej domeny. Zasady protokołu Kerberos są zapisane w Active Directory jako podzbiór atrybutów zasad zabezpieczeń domeny (domain security policy). Domyślnie zasady (policies) mogą być konfigurowane tylko przez administratorów sieci (członków grupy Domain Administrators). Do ustawień zasad (policy settings) protokołu Kerberos można uzyskać dostęp: edytując obiekt zasad grupy (GPO) Zasady Domeny (Domain Policies), rozwijając gałęzie Konfiguracja Komputera (Computer Configuration), Ustawienia Systemu Windows (Windows Settings), Ustawienia Zabezpieczeń (Security Settings) i Zasady konta (account policies), a następnie wybierając pozycję Zasady Protokołu Kerberos (Kerberos Policies), jak przedstawiono to na rysunku 4.8.
Rysunek 4.8. Ustawienia zasad domeny (domain policies) protokołu Kerberos Zasady Protokołu Kerberos obejmują następujące ustawienia:
•
Wwymuszaj ograniczenia logowania użytkowników (Enforce user logon restrictions) — jeśli ta opcja jest ustawiona, to Centrum Dystrybucji Kluczy zatwierdza każde żądanie biletu sesji (session ticket), sprawdzając zasady praw użytkownika (user rights policies) na komputerze docelowym, aby potwierdzić, że użytkownik ma prawo albo do logowania lokalnego, albo do dostępu poprzez sieć. Weryfikacja jest opcjonalna, ponieważ dodatkowy etap jest czasochłonny i może spowolnić dostęp sieciowy do usług. Domyślnie ustawione jest Zezwolenie (enabled),
•
Maksymalny okres ważności biletu usługi (Maximum lifetime for service ticket) — określenie bilet usługi (service ticket) oznacza bilet sesji (session ticket). Okres ważności podany jest w minutach i musi być dłuższy niż 10 minut i mniejszy lub równy wartości Maksymalny czas ważności biletu użytkownika (Maximum lifetime for user ticket). Domyślną wartością jest 600 minut (10 godzin),
•
Maksymalny czas ważności biletu użytkownika (Maximum lifetime for user ticket) — określenie bilet użytkownika (user's ticket) oznacza bilet gwarantujący bilet. Wartość podana jest w godzinach (domyślną wartością jest 10 godzin),
•
Maksymalny czas odnawiania biletu użytkownika (Maximum lifetime for user ticket renewal) — wartość podana jest w dniach (domyślnie jest to 7 dni),
•
Maksymalna tolerancja synchronizacji zegarów komputerów (Maximum tolerance for computer clock synchronization) — wartość podana jest w minutach (domyślnie — 5 minut).
Usługodawca obsługi zabezpieczeń Kerberos Usługodawca Obsługi Zabezpieczeń (Security Support Provider — SSP) był wspominany w niniejszym rozdziale kilkakrotnie, ale bez szczegółowych wyjaśnień. Usługodawca Obsługi Zabezpieczeń jest to biblioteka DLL (Dynamic Link Library) dostarczana z systemem operacyjnym, która jest implementacją protokołu zabezpieczeń (authentication protocol) Kerberos. System Windows 2000 zawiera także usługodawcę obsługi zabezpieczeń (SSP) dla uwierzytelniania za pomocą protokołu NTLM. Obydwie biblioteki są domyślnie pobierane podczas rozruchu systemu przez Lokalną Jednostkę Certyfikującą (LSA), pracującą na komputerze z systemem Windows 2000. Każdy z usługodawców może być użyty do uwierzytelniania logowania sieciowego i połączeń klient-serwer. To, który zostanie zastosowany, zależy od możliwości komputera po drugiej stronie połączenia. Jako pierwszy wybierany jest usługodawca zabezpieczeń Kerberos. Po tym, jak Lokalna Jednostka Certyfikująca ustanowi kontekst zabezpieczeń (security context) dla użytkownika interaktywnego, proces obsługi podpisywania (signing) i pieczętowania (sealing) komunikatów, działający w kontekście zabezpieczeń (security context) użytkownika, może załadować kolejną kopię (instance) Usługodawcy Obsługi Zabezpieczeń (SSP) Kerberos. Usługi systemowe (system services) i aplikacje warstwy transportowej (transport level applications) mają dostęp do usługodawców obsługi zabezpieczeń za pomocą Interfejsu Usługodawcy Obsługi Zabezpieczeń (Security Support Provider Interface — SSPI). Jest to interfejs Win32, który służy do wyliczania usługodawców dostępnych w systemie, wyboru
jednego z nich i użycia go w celu uzyskania połączenia uwierzytelnionego. Interfejs SSPI omówiono poniżej.
Zastosowanie interfejsu usługodawcy obsługi zabezpieczeń (SSPI) Interfejs Usługodawcy Obsługi Zabezpieczeń (SSPI) jest interfejsem Win32 pomiędzy aplikacjami warstwy transportowej a usługodawcami zabezpieczeń sieciowych (network security service providers). Integruje on uwierzytelnianie (authentication), spójność i poufność komunikatów z aplikacjami rozproszonymi (distributed applications). Szkielet aplikacji (application framework) modelu obiektowego składników rozproszonych (Distributed Component Object Model — DCOM) i uwierzytelnione, zdalne wywołania procedur (authenticated Remote Procedure Calls — RPCs) korzystają z usług Interfejsu Usługodawcy Obsługi Zabezpieczeń (SSPI) interfejsów wyższego poziomu. Usługi zabezpieczeń interfejsu SSPI są również zintegrowane z interfejsami poziomu aplikacji takimi jak WinSock 2.0 i WinInet. Na rysunku 4.9 przedstawiono miejsce usług zabezpieczeń interfejsu SSPI w całej strukturze aplikacji rozproszonej. Interfejs Usługodawcy Obsługi Zabezpieczeń (SSPI) stanowi warstwę abstrakcji (abstraction layer) pomiędzy protokołami poziomu aplikacji (application level protocol) a protokołami zabezpieczeń (security protocols). Usługi tego interfejsu SSPI mogą być używane w różny sposob: 1.
Tradycyjne aplikacje oparte na gniazdach (socket based applications) mogą wywoływać procedury Interfejsu Usługodawcy Obsługi Zabezpieczeń (SSPI routines) bezpośrednio i zastosować protokół aplikacji, który przekazuje dane dotyczące bezpieczeństwa Interfejsu Usługodawcy Obsługi Zabezpieczeń (SSPI security related data) za pomocą komunikatów żądania i odpowiedzi.
2.
Aplikacje mogą korzystać z modelu DCOM do wywoływania opcji zabezpieczeń, które zaimplementowano za pomocą uwierzytelnionych zdalnych wywołań procedur (authenticated RPC) i Interfejsu Usługodawcy Obsługi Zabezpieczeń (SSPI) na niższych poziomach. Aplikacje nie wywołują bezpośrednio tego interfejsu (SSPI).
3.
WinSock 2.0 rozszerza interfejs gniazd systemu Windows (Windows Sockets interface), aby umożliwić usługodawcom transportu (transport providers) ujawnienie funkcji zabezpieczeń (security features). Takie podejście integruje Interfejs Usługodawcy Obsługi Zabezpieczeń (SSPI) ze stosem sieciowym (network stack) i stanowi wspólny interfejs dla usług zabezpieczeń i transportowych.
4.
WinInet jest interfejsem protokołu aplikacji (application protocol interface), który jest przeznaczony do obsługi protokołów zabezpieczeń internetowych (Internet security protocols), takich jak Secure Socket Layer (SSL). Obsługa zabezpieczeń WinInet stosuje Interfejs Usługodawcy Obsługi Zabezpieczeń do usługodawcy zabezpieczeń bezpieczny kanał (secure channel security provider).
Rysunek 4.9. Interfejs usługodawcy obsługi zabezpieczeń (SSPI) i model bezpieczeństwa systemu Windows Języki skryptowe, takie jak VBscript czy JScript zezwalają programistom na dostęp do Interfejsu Usługodawcy Obsługi Zabezpieczeń (SSPI). O ile tworzenie aplikacji wykracza poza zakres niniejszej książki, to administrator zabezpieczeń (security administrator) powinien mimo wszystko wiedzieć o strukturze interfejsu usługodawcy obsługi zabezpieczeń i jego miejscu w architekturze systemu Windows 2000. Interfejs Usługodawcy Obsługi Zabezpieczeń stanowi wspólny interfejs pomiędzy aplikacjami warstwy transportowej, takimi jak Microsoft RPC lub program przeadresowujący systemu plików (file system redirector) oraz usługodawcami zabezpieczeń. Dostarcza również mechanizmy, za pomocą których aplikacje rozproszone mogą wywoływać jednego z wielu usługodawców zabezpieczeń, aby uzyskać połączenie uwierzytelnione, bez znajomości szczegółów protokołu zabezpieczeń. Interfejs Usługodawcy Obsługi Zabezpieczeń (SSPI) składa się z czterech rodzajów interfejsów: 1.
Interfejsy do zarządzania danymi uwierzytelniającymi (Credential management interfaces) — umożliwiają uzyskanie dostępu do danych uwierzytelniających (credentials) — dane, hasła, bilety, itd. — lub zwolnienie (free) tego dostępu. Dostępne są następujące metody: •
AcquireCredentialsHandle — uzyskuje dojście (handle) do wskazanych danych uwierzytelniających (credentials),
2.
3.
4.
•
FreeCredentialsHandle — zwalnia dojście do danych uwierzytelniających (credentials handle) i związane z tym zasoby,
•
QueryCredentialsAttributes — umożliwiają wysyłanie kwerend dotyczących różnych atrybutów danych uwierzytelniających (credentials), takich jak skojarzona nazwa, nazwa domeny, itd.
Interfejsy do zarządzania kontekstem (Context management interfaces) — dostarczają metody do tworzenia i stosowania kontekstów zabezpieczeń (security contexts). Konteksty te są tworzone zarówno po stronie klienta, jak i serwera połączenia komunikacyjnego i mogą być używane później z interfejsami obsługi komunikatów (message support interfaces). Dostępne są następujące metody: •
InitializeSecurityContext — inicjuje kontekst zabezpieczeń, generując komunikat nieprzejrzysty (opaque message) — znacznik zabezpieczeń (access token) — który może być przekazany do serwera,
•
AcceptSecurityContext — tworzy kontekst zabezpieczeń (security context), za pomocą komunikatu nieprzejrzystego (opaque message) otrzymanego od klienta,
•
DeleteSecurityContext — zwalnia kontekst zabezpieczeń i związane z nim zasoby,
•
QueryContextAttributes — pozwala na wysyłanie kwerend dotyczących różnych atrybutów kontekstu,
•
ApplyControlToken — wprowadza dodatkowe komunikaty zabezpieczeń do istniejącego kontekstu zabezpieczeń (security context),
•
CompleteAuthToken — uzupełnia znacznik uwierzytelnienia (authentication token). Jest to konieczne, ponieważ w przypadku niektórych protokołów, takich jak Distributed Computing Environment Remote Procedure Call (DCE RPC), konieczne jest przejrzenie informacji o zabezpieczeniach (security information), gdy tylko transport uaktualni określone pola komunikatu,
•
ImpersonateSecurityContext — dołącza kontekst zabezpieczeń klienta do wywoływanego wątku (calling) jako znacznik personifikacji (impersonation token),
•
RevertSecurityContext — przerywa personifikację (impersonation) i przywraca wywoływanemu wątkowi znacznik pierwotny (primary token).
Interfejsy obsługi komunikatów (Message support interfaces) — zawierają usługi zapewniające spójność i poufność komunikacji, które są oparte na kontekście zabezpieczeń. Dostępne są następujące metody: •
MakeSignature — generuje podpis zabezpieczony (secure signature) na podstawie komunikatu i kontekstu zabezpieczeń (security context),
•
VerifySignature — sprawdza, czy podpis (signature) jest zgodny z odebranym komunikatem.
Interfejsy do zarządzania pakietami (Package- management interfaces) — zawierają usługi dla różnych pakietów zabezpieczeń (security packages) obsługiwanych przez usługodawcę zabezpieczeń (security provider). Dostępne są następujące metody:
•
EnumerateSecurityPackages — przedstawia listę dostępnych pakietów zabezpieczeń i ich możliwości,
•
QuerySecurityPackageInfo — wysyła do pojedynczych pakietów zabezpieczeń (security package) kwerendy dotyczące ich możliwości.
Usługodawca Zabezpieczeń (Security Provider) to biblioteka dołączana dynamicznie (Dynamic Link Library — DLL), która jest implementacją interfejsu usługodawcy obsługi zabezpieczeń (interfejs SSP) i udostępnia aplikacjom jeden lub kilka pakietów zabezpieczeń (security packages). Pakiet zabezpieczeń SSP przyporządkowuje funkcje interfejsu SSPI implementacji protokołu zabezpieczeń (security protocol), właściwej dla danego pakietu, takiego jak NTLM, Kerberos czy SSL. Na etapie inicjalizacji identyfikacji określonego pakietu używana jest nazwa pakietu zabezpieczeń. Interfejs SSPI pozwala aplikacji na używanie dowolnego, dostępnego w systemie pakietu zabezpieczeń, bez zmiany interfejsu do korzystania z usług zabezpieczeń (security services). Ponadto nie ustanawia danych uwierzytelniających logowania (logon credentials), ponieważ zazwyczaj jest to operacja uprzywilejowana, przeprowadzana przez system operacyjny. Aplikacja może użyć funkcji zarządzania pakietami (package management functions) do prezentowania listy dostępnych pakietów zabezpieczeń (security packages) i wybrania tego, który jest potrzebny. Następnie aplikacja korzysta z funkcji do zarządzania danymi uwierzytelniającymi (credential management functions), aby uzyskać dojście (handle) do danych uwierzytelniających (credentials) użytkownika, w którego imieniu działa. Mając to dojście, aplikacja może skorzystać z funkcji do zarządzania kontekstem (context management functions), aby utworzyć kontekst zabezpieczeń (security context) usługi. Kontekst zabezpieczeń jest to struktura danych nieprzejrzysta (opaque data structure), zawierająca dane o zabezpieczeniach odpowiednich dla połączenia, takiego jak klucz sesji, czas trwania sesji, itd. Ostatecznie aplikacja korzysta z kontekstu zabezpieczeń (security context) z funkcjami obsługi komunikatów (message support functions) dla zapewnienia integralności i poufności komunikacji podczas trwania połączenia.
Możliwości pakietów zabezpieczeń Możliwości pakietu zabezpieczeń (security package) określają, jakie usługi dostarcza on danej aplikacji. Obejmują one, np. obsługę uwierzytelniania klienta uwierzytelnianie wzajemne (mutual authentication) lub obsługę spójności komunikatów (message integrity) oraz ich poufności (message privacy). Dodatkowo niektóre pakiety są przeznaczone do korzystania tylko z niezawodnych protokołów transportowych (transport protocols), a nie z transportów datagramowych (datagram transports). Możliwości pakietów zabezpieczeń (security package capabilities), dostępne w określonym pakiecie, można uzyskać za pomocą funkcji QuerySecurityPackageInfo. Poniższa lista przedstawia możliwości pakietów zabezpieczeń. 1.
Możliwości związane z uwierzytelnianiem:
2.
3.
•
uwierzytelnianie wyłącznie klienta (client only authentication),
•
wymagane uwierzytelnianie wieloetapowe (multileg authentication required),
•
obsługa personifikacji w systemie Windows (Windows impersonation).
Możliwości związane z transportem: •
transport z wykorzystaniem datagramów (datagram style transports),
•
transporty połączeniowe (connection oriented transports),
•
semantyka połączenia strumienia danych (data stream connection semantics).
Możliwości związane z komunikatami: •
obsługa integralności komunikatów (messages integrity),
•
obsługa poufności komunikatów (messages privacy).
W większości przypadków aplikacje wybierają pakiety zabezpieczeń (security packages) na podstawie rodzaju dostępnych możliwości zabezpieczeń, które zaspokajają potrzeby danej aplikacji. Powyższe informacje na temat interfejsu SSPI dają jego pełny obraz, bez wnikania w szczegóły programowania. Więcej wiadomości na ten temat można znaleźć w dokumentacji systemu Windows 2000: Books OnLine oraz Technet. Jeśli ktoś chce spróbować samodzielnego programowania, najpierw niech zapozna się z przykładami zamieszczonymi w Windows 2000 Software Development Kit (SDK).
Rozdział 5
System Szyfrowania Plików Natychmiastowe rozwiązania dotycząceznajdują się na stronie Zastosowanie polecenia Cipher Szyfrowanie foldera lub pliku Odszyfrowywania foldera lub pliku Kopiowanie, przenoszenie i zmiana nazwy zaszyfrowanego foldera lub pliku Wykonywanie kopii zapasowych zaszyfrowanego foldera lub pliku Odtwarzania zaszyfrowanego foldera lub pliku Odtwarzanie plików na innym komputerze Zabezpieczanie domyślnego klucza odzyskiwania na komputerze autonomicznym Zabezpieczanie domyślnego klucza odzyskiwania dla domeny Dodawanie agentów odzyskiwania Ustanawianie zasad odzyskiwania dla danej jednostki organizacyjnej Odzyskiwanie pliku lub foldera Wyłączanie systemu szyfrowania plików dla danego zestawu komputerów
W skrócie Dlaczego konieczne jest szyfrowanie danych Komputery osobiste mają zwykle możliwość zastosowania kilku systemów plików (file systems). Jest to dogodne, jeśli np. system Windows 2000 ulegnie uszkodzeniu. Jednakże ryzykowna jest możliwość uruchomienia przez użytkownika komputera, np. MS-DOS i ominięcie w ten sposób zabezpieczeń systemu plików NTFS. Wskazówka: Czasem jest to uważane za niebezpieczne tylko w przypadku tych systemów plików, które są dostępne z trybu SODA, np. woluminów sformatowanych w systemie plików FAT, które nie mają zabezpieczeń systemu NTFS. System FAT ze swojej istoty jest mniej bezpieczny niż NTFS, ale istnieją narzędzia, za pomocą których można obejść także uprawnienia NTFS. Nie wolno wierzyć bezgranicznie, że system jest bezpieczny, ponieważ ma ustawione zabezpieczenia systemu plików NTFS.
Nieautoryzowany dostęp do kluczowych danych może wystąpić również w innych sytuacjach, np. systemy komputerowe w biurach czasami pozostawiane są bez nadzoru, gdy użytkownik jest zalogowany i w ten sposób umożliwiają kradzież najważniejszych danych każdemu, kto w tym czasie przyjdzie. Komputery, szczególnie laptopy, są czasami kradzione, a dla złodzieja bardziej interesujące mogą być kluczowe dane zapisane na dysku niż sprzedaż samego komputera. Dostęp do najważniejszych danych można ograniczyć za pomocą haseł i uprawnień systemu NTFS. Jednak dla kogoś, kto uzyska fizyczny dostęp do komputera lub dysku twardego, dotarcie do tych danych nie stanowi większego problemu. Jak już wspomniano powyżej, dostępne są narzędzia pozwalające na uzyskanie dostępu do plików NTFS z systemów MS-DOS lub Unix. Rozwiązaniem opisanego powyżej problemu jest szyfrowanie danych. Istnieją programy narzędziowe umożliwiające szyfrowanie plików na poziomie aplikacji za pomocą kluczy, które pochodzą od haseł. Jednak większość z nich ma ograniczenia. Jeśli użytkownik powinien szyfrować pliki ręcznie, to — gdy zapomni to zrobić — pliki takie pozostają bez ochrony. Niektóre aplikacje, np. Microsoft Word, podczas edytowania dokumentu przez użytkownika tworzą pliki tymczasowe. (temporary files). Takie pliki tymczasowe pozostają na dysku w postaci niezaszyfrowanej nawet, jeśli oryginalny dokument został zaszyfrowany. Szyfrowanie na poziomie aplikacji pracuje w trybie użytkownika systemu Windows, często z kluczem użytkowania do szyfrowania zapisanym w pliku stronicowania (paging file). Przeszukanie pliku stronicowania mogłoby komuś z zewnątrz umożliwić dostęp do wszystkich dokumentów. zaszyfrowanych. W systemach, w których klucze szyfrowania uzyskiwane są na podstawie haseł, zabezpieczenia mogą być naruszone przez ataki słownikowe (dictionary attacks). Niektóre Systemy zapewniają odzyskiwanie danych w oparciu o hasła (password based data recovery). Do
uzyskania dostępu do plików zaszyfrowanych złodziejowi danych potrzebne jest tylko hasło mechanizmu odzyskiwania.
System Szyfrowania Plików System Szyfrowania Plików (Encrypting File System — EFS) firmy Microsoft dotyczy problemów opisanych powyżej. W systemie tym stosuje się szyfrowanie za pomocą klucza publicznego (public key encryption), korzystając z interfejsu programisty CryptoAPI. Każdy plik jest szyfrowany za pomocą klucza generowanego losowo, który jest niezależny od pary kluczy publiczny-prywatny użytkownika. Algorytmem szyfrowania jest Data Encryption Standard (DES). W kolejnych wersjach pojawią się również inne algorytmy szyfrowania. Wskazówka: Więcej informacji na temat algorytmu DES znajduje się w dokumencie Federal Information Processing Standard Publication (FIPS PUB 46-2), dostępnym pod adresem www.cryptosoft.com/html/fips46-2.htm. Algorytm DES jest kontrolowany przez Departament handlu USA (U.S. Department of Commerce), a jego wersja 128-bitowa podlega ograniczeniom eksportowym.
System Szyfrowania Plików obsługuje również szyfrowanie i odszyfrowywanie plików zapisanych na serwerach plików zdalnych (remote file servers). Jednak system EFS szyfruje tylko dane zapisane na dysku — nie szyfruje danych przesyłanych poprzez sieć. System Windows 2000 Server zawiera protokoły sieciowe, takie jak Secure Sockets Layer/Private Communication Technology (SSL/PCT), służące do szyfrowania danych w sieci. System Szyfrowania Plików (EFS) jest ściśle zintegrowany z systemem plików NTFS. Jeśli szyfrowany jest plik, system EFS szyfruje również jego kopie tymczasowe, o ile plik znajduje się na woluminie NTFS. System Szyfrowania Plików jest częścią jądra systemu operacyjnego (operating system kernel) i korzysta z pamięci niestronicowanej (nonpaged memory) do przechowywania kluczy szyfrowania, gwarantując w ten sposób, że nigdy nie znajdą się one w pliku stronicowania.
Ingerencja użytkownika (user interaction) Domyślnie System Szyfrowania Plików (EFS) umożliwia użytkownikom rozpoczęcie szyfrowania plików bez żadnego współdziałania ze strony administratora. System EFS automatycznie generuje dla użytkownika parę kluczy publicznych do szyfrowania plików, jeśli taka para jeszcze nie istnieje. Szyfrowanie i odszyfrowywanie plików wykonywane jest dla poszczególnych plików (per-file) lub folderów (per-folder). Wszystkie pliki oraz podfoldery (subfolders) utworzone w folderze, który ma być zaszyfrowany, zostaną zaszyfrowane automatycznie. Każdy z plików ma swój unikatowy klucz szyfrowania, więc po przeniesieniu tego pliku z foldera zaszyfrowanego do foldera niezaszyfrowanego na tym samym woluminie, pozostanie on zaszyfrowany. Usługi szyfrowania i odszyfrowywania są dostępne z poziomu Eksploratora Windows (Windows
Explorer). Dla administratorów i agentów odzyskiwania (recovery agents) dostępne są narzędzia wywoływane z wiersza poleceń (command line tools) oraz interfejsy dla administratorów (administrative interfaces). Szyfrowanie i odszyfrowywanie przebiega w sposób niezauważalny podczas zapisu i odczyty pliku z dysku, tak więc pliki nie muszą być odszyfrowywane zanim użytkownik z nich skorzysta. System Szyfrowania Plików automatycznie wykryje, że plik jest zaszyfrowany i znajdzie odpowiedni klucz użytkownika w systemowej składnicy kluczy (key store). Ponieważ mechanizm przechowywania kluczy jest oparty na interfejsie CryptoAPI, użytkownicy mogą zapisywać klucze na urządzeniach zabezpieczonych, takich jak karty elektroniczne (smart cards).
Odzyskiwanie danych W systemie Windows 2000 można korzystać z szyfrowania plików tylko wtedy, gdy system skonfigurowano w ten sposób, że istnieje przynajmniej jeden klucz odzyskiwania. System Szyfrowania Plików (EFS) umożliwia agentom odzyskiwania (recovery agents) konfigurowanie kluczy publicznych (public keys), z których korzysta się przy odzyskiwaniu plików. W trakcie korzystania z klucza odzyskiwania (recovery key) dostępny jest tylko wygenerowany losowo klucz szyfrowania pliku, a nie klucz prywatny (private key) użytkownika. Gwarantuje to, że żadne informacje poufne nie zostaną przypadkowo ujawnione agentowi odzyskiwania. Funkcja odzyskiwania danych jest przeznaczona dla systemów w przedsiębiorstwach, w których to systemach musi istnieć możliwość odzyskania plików zaszyfrowanych przez byłych pracowników lub odzyskania plików w razie utraty klucza szyfrowania. Zasady odzyskiwania (recovery policy) są określone na kontrolerze domeny (domain controller) i narzucone wszystkim komputerom w domenie. Zasady te są kontrolowane przez administratorów domeny, którzy mogą przekazać dane uprawnienia do wyznaczonych kont administratorów zabezpieczeń danych (data security administrator) i cofnąć te pełnomocnictwa, gdyby pojawiła się taka potrzeba. System Szyfrowania Plików może być również stosowany w domu, ponieważ on automatycznie generuje klucze odzyskiwania (recovery keys) i, jeśli komputer nie należy do żadnej domeny systemu Windows, zapisuje je jako klucze komputera (machine keys).
Szyfrowanie plików Działanie Systemu szyfrowania plików (EFS) zostanie omówione bardziej szczegółowo w dalszej części niniejszego rozdziału pod tytułem „Rozwiązania natychmiastowe”. Poniżej zamieszczono krótkie omówienie narzędzi dla użytkownika. Narzędzie interfejsu GUI (GUI tool) można uruchomić, klikając w oknie Eksploratora Windows (Windows Explorer) dany plik lub folder prawym przyciskiem myszy, i wybierając opcję Właściwości (Properties), a następnie naciskając przycisk Zaawansowane (Advanced), znajdujący się w oknie zakładki Ogólne (General). Umożliwia to szyfrowanie aktualnie wybranego pliku lub wszystkich plików (i podfolderów) w aktualnie wybranym folderze przez zaznaczenia danego foldera jako zaszyfrowany. Możliwe jest również działanie odwrotne: odszyfrowanie aktualnie
wybranego pliku lub wszystkich plików (i podfolderów) w aktualnie wybranym folderze przez zaznaczenie danego foldera jako niezaszyfrowany. Moduł dodatkowy (snap in) konsoli MMC Certyfikaty (Certificates) jest używany do eksportowania, importowania i zarządzania kluczami publicznymi. Na ogół użytkownicy nie muszą wykonywać tych czynności, ponieważ System Szyfrowania Plików (EFS) automatycznie generuje klucze, służące do szyfrowania plików. Funkcja ta jest przydatna administratorom lub użytkownikom zaawansowanym, którzy chcą skonfigurować klucz publiczny, zamiast korzystać z domyślnego. W systemie Windows 2000 jest również polecenie cipher, które wywołuje się z wiersza poleceń (command line). Polecenie to omówiono w części zatytułowanej „Rozwiązania natychmiastowe”. Wszystkie operacje zapisu i odczytu z pliku zaszyfrowanego są szyfrowane i odszyfrowywane w sposób niezauważalny. W normalnych warunkach jedynym spsobem, aby przekonać się, czy plik jest zaszyfrowany, jest sprawdzenie jego właściwości, np. użytkownik może otworzyć i edytować zaszyfrowany dokument Worda dokładnie w taki sam sposób, jak robi się to w przypadku dokumentu niezaszyfrowanego. Inni użytkownicy, próbując otworzyć ten zaszyfrowany plik, otrzymają komunikat o błędzie Dostęp zabroniony (access denied), ponieważ nie posiadają klucza do odszyfrowania pliku.
Odszyfrowywanie plików lub folderów Użytkownicy zazwyczaj nie mają potrzeby odszyfrowywania plików lub folderów, ponieważ System Szyfrowania Plików (EFS) szyfruje i odszyfrowuje dane w sposób niedostrzegalny podczas zapisywania i odczytywania. Jednak odszyfrowanie pliku może być niezbędne, np. gdy konieczne jest współdzielenie przez użytkownika pliku zaszyfrowanego z innymi użytkownikami. Użytkownicy mogą odszyfrowywać pliki i zaznaczać foldery jako niezaszyfrowane za pomocą Eksploratora Windows (Windows Explorer). Menu kontekstowe odszyfrowywania przy odszyfrowywaniu foldera zawiera opcje odszyfrowania wszystkich plików i podfolderów zaszyfrowanych znajdujących się w danym folderze.
Operacje odzyskiwania Zasady odzyskiwania (recovery policies) Systemu Szyfrowania Plików (EFS) stanowią część ogólnych zasad zabezpieczeń (security policy) systemu. Interfejs użytkownika zasad systemu EFS umożliwia agentom odzyskiwania (recovery agents) generowanie, eksportowanie, importowanie i wykonywanie kopii zapasowych kluczy odzyskiwania (recovery keys) za pomocą elementu sterującego do zarządzania kluczami (key management control). Podsystem zabezpieczeń (security subsystem) systemu Windows realizuje replikację i buforowanie zasad (policy) systemu szyfrowania plików, umożliwiając użytkownikom korzystanie z szyfrowania plików w systemach, które są chwilowo w trybie offline, za pomocą buforowanych danych uwierzytelniających (cached credentials).
System Szyfrowania Plików (EFS) wymaga, by zasady odzyskiwania danych (data recovery policies) były ustanawiane na poziomie domeny lub lokalnie, jeśli komputer nie należy do żadnej domeny. Zwykle zasady odzyskiwania są ustanawiane przez administratorów domen, którzy mają nadzór nad kluczami odzyskiwania dla wszystkich komputerów. Gdyby użytkownik utracił klucz prywatny (private key), plik chroniony przez ten klucz można odzyskać, eksportując go i wysyłając pocztą elektroniczną do jednego z agentów odzyskiwania. Agent odzyskiwania importuje ten plik do komputera zabezpieczonego (secure computer) za pomocą prywatnych kluczy odzyskiwania (private recovery keys), stosuje polecenie cipher do odszyfrowania pliku, a następnie odsyła go w postaci zwykłego tekstu z powrotem do danego użytkownika. W małych firmach lub w domu, gdzie nie tworzy się domen, odzyskiwanie można przeprowadzić na pojedynczym komputerze. Wyznaczenie agentów odzyskiwania może być wymagane przez prawo lub narzucone przez zasady przedsiębiorstwa. Na stanowisko agenta odzyskiwania może zostać wyznaczony administrator domeny lub też może on otrzymać polecenie przekazania tego pełnomocnictwa innej zaufanej jednostce. Nie ma żadnych przeszkód natury technicznej, aby ktoś z zewnątrz, np. prywatna firma ochroniarska, mógł zostać agentem odzyskiwania. Taka firma powinna cieszyć się dużym zaufaniem. Można zaufać firmie niezależnej, która ma dbać o pieniądze klientów i w takiej sytuacji będzie łatwo zauważalne „zniknięcie” pieniądzy, ale obdarzenie zaufaniem firmy niezależnej w zakresie prywatnych informacji poufnych — to całkowicie odmienna sytuacja.
Kryptografia System Szyfrowania Plików (EFS) przeprowadza szyfrowanie i odszyfrowywanie danych za pomocą klucza publicznego. Do szyfrowania plików danych służy szybki algorytm symetryczny (fast symmetric algorithm) z Kluczem Szyfrowania Plików (File Eencryption Key — FEK). Klucz Szyfrowania Plików (FEK) jest generowanym losowo kluczem o długości ściśle określonej przez algorytm szyfrowania lub przez obowiązujące przepisy, jeśli algorytm umożliwia stosowanie kluczy o różnej długości. W czasie pisania tej książki obowiązywały ograniczenia eksportowe, wprowadzone przez rząd USA, zgodnie z którymi 128-bitowy klucz DES mógł być stosowany tylko na terenie Ameryki Północnej. Wyjątek stanowiły, np. wielkie międzynarodowe banki. Pozostali użytkownicy korzystają z klucza 56-bitowego. Klucz Szyfrowania Plików jest zaszyfrowany za pomocą przynajmniej jednego klucza publicznego szyfrowania kluczy (key encryption public key), który służy do sporządzenia listy zaszyfrowanych Kluczy Szyfrowania Plików (FEK). Lista ta jest zapisana razem z plikiem zaszyfrowanym w specjalnym atrybucie Systemu Szyfrowania Plików (EFS) o nazwie Data Decryption Field (DDF). Do odszyfrowywania służy prywatna część pary kluczy użytkownika. Klucz Szyfrowania Plików (FEK) jest również zaszyfrowany za pomocą co najmniej jednego klucza publicznego szyfrowania klucza odzyskiwania (recovery key encryption public keys). Ponadto publiczna część każdej pary kluczy jest używana do szyfrowania kluczy szyfrowania plików, a lista zaszyfrowanych kluczy szyfrowania plików jest zapisywana razem z plikiem w specjalnym atrybucie systemu szyfrowania plików o nazwie Data Recovery Field (DRF). Do szyfrowania Klucza Szyfrowania Pliku (FEK) w atrybucie DRF konieczna jest tylko część publiczna pary kluczy odzyskiwania. Odzyskiwanie zazwyczajjest konieczne tylko wtedy, gdy
użytkownik opuści przedsiębiorstwo lub zgubi klucze. Z tego powodu agenci odzyskiwania mogą w dowolnym miejscu, bezpiecznie zapisywać prywatne części biletów, np.na kartach elektronicznych lub innych urządzeniach do zapisywania bezpiecznego.
Implementacja Na rysunku 5.1 przedstawiono składniki systemu szyfrowania plików (EFS) i ich miejsce w strukturze systemu.
Rysunek 5.1. Komponenty architektury EFS System Szyfrowania Plików składa się z następujących elementów: •
Sterownik Systemu Szyfrowania Plików (EFS driver) — komunikuje się z usługą EFS, aby żądać kluczy szyfrowania plików (file encryption keys), atrybutów DDF i DRF oraz
innych usług zarządzania kluczami (key management services). Następnie przekazuje te informacje do biblioteki EFS (File System Runtime Library — FSRTL), aby niedostrzegalnie wykonać różne operacje na systemie plików (otwieranie, odczyt, zapis i dodawanie), •
EFS FSRTL — jest implementacją wywołań systemu plików NTFS (NTFS callouts) do obsługi różnych operacji systemu plików, takich jak odczyt, zapis i otwieranie, wykonywanych na plikach i folderach zaszyfrowanych, jak również operacji szyfrowania, odszyfrowywania i odzyskiwania danych w trakcie odczytu i zapisu na dysku. Operacje zaimplementowane za pomocą mechanizmów kontroli plików (file control mechanism) obejmują zapis atrybutów EFS (DDF i DRF) jako atrybutów plików (files attributes) oraz przekazywanie do biblioteki FSRTL Klucza Szyfrowania Pliku (FEK) wyznaczonego przez usługę EFS, aby mógł być zainstalowany w kontekście pliku otwartego (open file context). Następnie kontekst ten jest używany do szyfrowania i odszyfrowywania w niezauważalny sposób zapisów i odczytów danych z dysku,
•
usługa EFS (EFS service) — część podsystemu zabezpieczeń (security subsystem). Do komunikacji ze sterownikiem EFS korzysta z istniejącego portu komunikacyjnego LPC pomiędzy Lokalną Jednostką Certyfikującą (Local Security Authority — LSA) a składnikiem jądra Security Reference Monitor (Kernel Mode Security Reference Monitor). W trybie użytkownika (user mode) łączy się z interfejsem CryptoAPI, aby dostarczyć klucze szyfrowania plików (file encryption keys) i wygenerować atrybuty DDF oraz DRF. Usługa EFS obsługuje także interfejsy Win32 API do szyfrowania, odszyfrowywania, odzyskiwania importowania i eksportowania,
•
Win 32 API — stanowi interfejsy programowe dla szyfrowania plików zapisanych w postaci zwykłego tekstu, odszyfrowywania lub odzyskiwania plików w postaci zaszyfrowanej oraz importowania i eksportowania plików zaszyfrowanych bez wcześniejszego odszyfrowywania. Interfejsy te obsługiwane są przez standardową bibliotekę DLL, advapi32.dll.
Rozwiązania natychmiastowe Zastosowanie polecenia Cipher
Polecenie cipher — wywoływane z wiersza poleceń — zostało już wcześniej wspomniane i będzie stosowane w dalszej części niniejszego rozdziału. Jednak w tym miejscu należy omówić je, zbadać jego składni oraz opisać znaczniki (flags) i opcji tego polecenia. Polecenie cipher umożliwia szyfrowanie i odszyfrowywanie plików z wiersza poleceń (command line), np. aby zaszyfrować folder secure_docs bieżącego woluminu można wpisać: Cipher /e "secure_docs"
Do zaszyfrowania wszystkich plików w bieżącym folderze, które zawierają w swojej nazwie ciąg znaków „coriolis” można wpisać: Cipher /e /a coriolis
Polecenie cipher ma następujące parametry: CIPHER [/E | /D] [/S[:dir]] [/A] [/I] [/F] [/Q] [/H] [/K] [pathname ]]
Oto znaczenie tych parametrów: •
/E — szyfruje określone pliki lub katalogi. Katalogi zostaną oznaczone, więc dodawane do nich pliki będą szyfrowane,
•
/D — odszyfrowuje określone pliki lub katalogi. Katalogi zostaną oznaczone, więc dodawane do nich pliki nie będą odszyfrowane,
•
/S — wykonuje podaną operacje na danym folderze i wszystkich jego podfolderach. Domyślnie dir oznacza bieżący folder,
•
/A — wykonuje określone operacje na plikach i folderach. Należy zwrócić uwagę, że plik może zostać odszyfrowany w trakcie modyfikacji, a folder, w którym go zapisano, nie jest zaszyfrowany,
•
/I — kontynuuje wykonywanie określonej operacji nawet po pojawieniu się błędów. Domyślnie polecenie cipher kończy działanie, gdy wystąpi błąd,
•
/F — wymusza operację szyfrowania wszystkich podanych plików, nawet tych, które są już zaszyfrowane. Domyślnie wszystkie pliki już zaszyfrowane są opuszczane. Funkcja ta gwarantuje, że pliki oznaczone jako zaszyfrowane są rzeczywiście zaszyfrowane. Jeśli wystąpi błąd sprzętowy w trakcie szyfrowania, plik może być oznaczony jako zaszyfrowany nawet, jeśli w rzeczywistości tak nie jest,
•
/Q — raportuje tylko najważniejsze informacje (quiet mode),
•
/H — podaje pliki z atrybutami ukryty (hidden) lub systemowy (system). Zwróćmy uwagę, że pliki systemowe nie powinny być szyfrowane, ponieważ w następstwie takiej operacji komputer mógłby się nie uruchomić,
•
/K — tworzy nowy klucz szyfrowania pliku (file encryption key) dla użytkownika, który uruchomił polecenie cipher. Jeśli ta opcja jest podana, to pozostałe są ignorowane,
•
Pathname (ścieżka) — podaje wzór, folder lub plik.
Polecenie cipher bez parametrów wyświetli aktualny stan szyfrowania bieżącego foldera i plików, które zawiera. Można podawać wiele nazw plików (multiple file names) i stosować symbole wieloznaczne (wildcards). Pomiędzy parametrami wstawia się spacje.
Szyfrowanie foldera lub pliku Do szyfrowania pliku można użyć Eksploratora Windows (Windows Explorer) lub z wiersza poleceń uruchomić program cipher.exe. Uwaga: Na potrzeby opisanych poniżej procedur przyjęto, że użytkownik otrzymał Certyfikat Bezpieczeństwa (Security Certificate) z Serwera certyfikatów systemu Windows 2000 (Windows 2000 Certificate Server), Menedżera Kluczy Wymiany (Exchange Key Manager) lub usługodawcy komercyjnego, takiego jak VeriSign. Dokonuje się tego zazwyczaj na etapie instalacji systemu podczas konfigurowania usług pocztowych (email service).
Rozwiązania pokrewne zobacz na stronie Konfigurowanie jednostki certyfikującej (Certification Authority — CA) Instalowanie certyfikatów jednostki certyfikującej (CA certificates)
Zastosowanie Eksploratora Windows (Windows Explorer) do szyfrowania foldera lub pliku W procedurze tej do szyfrowania foldera korzysta się z Eksploratora Windows (Windows Explorer). W taki sam sposób szyfruje się pliki. 1.
Uruchom Eksploratora Windows (Windows Explorer).
2.
Prawym przyciskiem myszki kliknij nazwę foldera lub pliku i z menu wybierz opcję Właściwości (Properties).
3.
W oknie zakładki Ogólne (General) naciśnij przycisk Zaawansowane (Advanced). Pojawi się okno dialogowe Atrybuty Zaawansowane (Advanced Attributes), jak przedstawiono to na rysunku 5.2.
4.
Zaznacz pole wyboru Szyfruj zawartość, aby zabezpieczyć dane (Encrypt contents to secure data) i naciśnij OK. Nastąpi powrót do okna dialogowego Pliki Zaszyfrowane Właściwości (Encrypted Files Properties). Naciśnij przycisk OK.
5.
Jeśli zaszyfrowany ma być folder, należy wybrać, czy ma być zaszyfrowany tylko sam folder, czy też folder wraz całą zawartością (rysunek 5.3). Na ogół, jeśli folder jest pusty, np. został niedawno utworzony, należy wybrać pierwszą możliwość. Jeśli folder zawiera pliki i podfoldery — wybiera się drugą możliwość.
6.
Naciśnij przycisk OK. Okno dialogowe pokaże status szyfrowania foldera lub pliku.
Uwaga: Microsoft zaleca szyfrowanie folderów, a nie pojedynczych plików.
Rysunek 5.2. Okno dialogowe Atrybuty Zaawansowane (Aadvanced Attributes)
Rysunek 5.3. Okno dialogowe Potwierdzanie zmian atrybutów (Confirm attribute changes)
Zastosowanie polecenia cipher do szyfrowania foldera lub pliku W procedurze tej do szyfrowania foldera używa się polecenia cipher. Polecenie to może służyć do szyfrowania pojedynczych plików (chociaż Microsoft zaleca, żeby tego nie robić). 1.
Wybierz niezaszyfrowany folder lub plik (raczej folder) zapisany na woluminie NTFS. W niniejszym przykładzie wybrano folder D:\secure_docs.
2.
W wierszu poleceń wpisz Cipher /e /s:":\secure_docs" /a
W oknie poleceń pojawi się potwierdzenie operacji, co przedstawiono na rysunku 5.4. Należy zwrócić uwagę, że parametr /a powoduje, iż — oprócz zaszyfrowania danego foldera — zaszyfrowane zostaną wszystkie pliki i podfoldery w tym folderze.
Rysunek 5.4. Szyfrowanie foldera za pomocą wiersza poleceń
Odszyfrowywanie foldera lub pliku
Tak samo, jak w przypadku szyfrowania do odszyfrowywania foldera lub pliku można użyć Eksploratora Windows (Windows Explorer) lub programu narzędziowego uruchamianego z wiersza poleceń. Należy zwrócić uwagę, że do otwierania pliku i jego edytowania odszyfrowywanie nie jest konieczne. Jedynym powodem odszyfrowania pliku jest udostępnienie go innym użytkownikom.
Zastosowanie Eksploratora Windows (Windows Explorer) do odszyfrowania foldera lub pliku W procedurze tej do odszyfrowania foldera lub pliku używa się Eksploratora Windows (Windows Explorer). Wybierz folder zaszyfrowany poprzednio. 1.
Uruchom Eksploratora Windows (Windows Explorer).
2.
Prawym przyciskiem myszki kliknij nazwę foldera lub pliku i z menu wybierz opcje Właściwości (Properties).
3.
W oknie zakładki Ogólne (General) naciśnij przycisk Zaawansowane (Advanced).
4.
W oknie dialogowym Atrybuty Zaawansowane (Advanced Attributes) odznacz pole wyboru Szyfruj zawartość, aby zabezpieczyć dane (Encrypt contents to secure data) i naciśnij OK.
5.
W oknie dialogowym Pliki Zaszyfrowane Właściwości (Encrypted Files Properties) naciśnij przycisk OK.
6.
Pojawi się możliwość dokonania wyboru między odszyfrowaniem danego foldera wraz z całą jego zawartością, a odszyfrowywaniem samego foldera. Domyślnie wybrane jest odszyfrowywanie tylko foldera.
7.
Naciśnij OK.
Zastosowanie polecenia cipher do odszyfrowywania foldera lub pliku Aby odszyfrować folder D:\secure_docs wpisz polecenie w następującej postaci: Cipher /d /s:”D:\secure_docs”
W tym przypadku nie podano parametru /a, więc pliki i podfoldery w wybranym folderze pozostaną zaszyfrowane. Żaden z nowo utworzonych w danym folderze plików lub podfolderów nie będzie szyfrowany.
Kopiowanie, przenoszenie i zmiana nazwy zaszyfrowanego foldera lub pliku W tej części wyjaśniono, co dzieje się podczas kopiowania, przenoszenia lub zmiany nazwy zaszyfrowanych folderów lub plików w ramach tego samego woluminu, pomiędzy woluminami lub pomiędzy komputerami. Należy zwrócić uwagę, że użytkownik może kopiować tylko te pliki i foldery, które sam zaszyfrował. Przy próbie kopiowania plików zaszyfrowanych przez innego użytkownika pojawi się komunikat Dostęp Zabroniony (Access Denied). Sposób kopiowania, przenoszenia i zmiany nazwy plików zaszyfrowanych jest dokładnie taki sam, jak sposób kopiowania, przenoszenia i zmiany nazwy plików niezaszyfrowanych. Jeśli kopiuje się plik lub folder zaszyfrowany w ramach tego samego komputera z jednej lokalizacji z systemem plików NTFS do drugiej, to kopia jest zaszyfrowana, niezależnie od tego czy folder docelowy jest zaszyfrowany, czy nie. Jeśli kopiuje się plik lub folder w ramach tego samego komputera z woluminu NTFS do woluminu FAT, to kopia jest zapisana w postaci zwykłego tekstu, ponieważ nie można szyfrować plików w systemie plików FAT. Należy zwrócić uwagę, że dyskietki zawsze są formatowane w systemie FAT. Jeśli kopiuje się plik lub folder zaszyfrowany z lokalizacji NTFS na jednym komputerze do lokalizacji NTFS na innym komputerze i komputer zdalny umożliwia szyfrowanie plików, to plik pozostanie zaszyfrowany. W przeciwnym razie kopia zostanie zapisana w postaci zwykłego tekstu (cleartext). Należy zwrócić uwagę, że komputer musi mieć cechę zaufania w kwestii delegowania (trusted for delegation). Szyfrowanie zdalne nie jest w domenach uaktywnione domyślnie. Jeśli kopiuje się pliki lub foldery z woluminu NTFS systemu Windows 2000 w danym komputerze do woluminu FAT lub woluminu NTFS systemu Windows NT 4 na innym komputerze, to wtedy kopia zapisana jest w postaci zwykłego tekstu, ponieważ docelowy system plików nie umożliwia szyfrowania. Uwaga: Jeśli plik pierwotny został zaszyfrowany, Microsoft zaleca korzystanie z opcji Zaawansowane Właściwości (Properties Advanced) Eksploratora Windows (Windows Explorer) do sprawdzania statusu pliku docelowego.
Jeśli plik jest przenoszony lub następuje zmiana nazwy w obrębie tego samego woluminu, wówczas plik lub folder docelowy pozostanie zaszyfrowany. Jeśli przenosi się pliki lub foldery pomiędzy woluminami, jest to właściwie operacja kopiowania, którą opisano powyżej.
Usuwanie foldera lub pliku zaszyfrowanego Mając prawo do usuwania pliku lub foldera, można usunąć go w taki sam sposób, jak plik niezaszyfrowany. Usuwanie pliku lub foldera zaszyfrowanego nie musi być koniecznie zastrzeżone dla użytkownika, który sam zaszyfrował dany plik.
Wykonywanie kopii zapasowych plików lub folderów zaszyfrowanych Kopie zapasowe, utworzone za pomocą polecenia copy lub opcji Kopia (Copy)z menu Eksploratora Windows (Windows Explorer), mogą zostać zapisane w postaci zwykłego tekstu, co opisano w poprzedniej części. Zalecanym sposobem wykonywania kopii zapasowych plików zaszyfrowanych jest skorzystanie z usługi Kopia zapasowa (Backup)systemu Windows 2000 lub innego programu narzędziowego do wykonywania kopii zapasowych, który obsługuje funkcje systemu Windows 2000. Operacja wykonywania kopii zapasowych zachowuje szyfrowanie plików, a operatorom wykonującym kopie zapasowe (backup operators) do wykonania takiej kopii nie jest potrzebny dostęp do kluczy prywatnych — niezbędne jest im tylko prawo dostępu do danego foldera lub pliku.
Zastosowanie usługi Utwórz kopię zapasową (backup) do wykonania kopii zapasowej pliku, foldera lub dysku Poniżej opisano zalecany sposób wykonywania kopii zapasowych plików, folderów lub dysków zaszyfrowanych. 1.
Z menu Akcesoria (Accessories) wybierz pozycję Narzędzia Systemowe (System Tools), a następnie Kopia zapasowa (Backup).
2.
Wybierz zakładkę Kopia zapasowa (Backup).
3.
Sprawdź dyski, pliki lub foldery, których kopie zapasowe chcesz wykonać, jak przedstawiono to na rysunku 5.5.
4.
Podaj Nośnik kopii zapasowej lub nazwa pliku (Backup media or file name). Za pomocą przycisku Przeglądaj (Browse) można zlokalizować istniejący już plik kopii zapasowej. Domyślną ścieżką dostępu jest A:\Backup.bkf. Należy zwrócić uwagę, że lista rozwijalna Miejsce Docelowe Kopii Zapasowej (Backup Destination) jest zaznaczone na szaro. Kopia zapasowa pliku zaszyfrowanego może być zapisana tylko w pliku BKF.
5.
Naciśnij przycisk Rozpocznij (Start backup). Możesz wybrać, czy zastąpić poprzedni plik kopii zapasowej lub dołączyć aktualną kopię zapasową. Jeśli wybierzesz zastąpienie pliku kopii zapasowej możesz nadać prawo dostępu do pliku tylko właścicielowi i administratorowi, co przedstawiono na rysunku 5.6.
6.
Naciśnij przycisk Zaawansowane (Advanced). W oknie Zaawansowane Opcje Kopii Zapasowej (Advanced Backup Options) można wybrać rodzaj kopii zapasowej i zaznaczyć pole wyboru Weryfikuj dane po wykonaniu kopii zapasowej (Verify data after backup). Okno to przedstawiono na rysunku 5.7. Należy zwrócić uwagę, że plików zaszyfrowanych nie można kompresować, a za pomocą Eksploratora Windows (Windows
Explorer) nie można szyfrować plików systemowych — więc opcje te są zaznaczone na szaro. Wybierz potrzebne odpowiednie opcje i naciśnij przycisk OK.
Rysunek 5.5. Okno dialogowe Kopia zapasowa (Backup) systemu Windows 2000
Rysunek 5.6. Okno dialogowe Informacje o Zadaniu Kopii Zapasowej (Backup Job Information)
Rysunek 5.7. Okno dialogowe Zaawansowane Opcje Kopii Zapasowej (Advanced Backup Options) 7.
Wybierz odpowiednie opcje w oknie dialogowym Informacje o Zadaniu Kopii Zapasowej (Backup Job Information) — zob.rysunek 5.6. Naciśnij przycisk Rozpocznij (Start backup).
8.
Po zakończeniu wykonywania kopii zapasowej w oknie Postęp Kopii Zapasowej (Backup Progress) naciśnij przycisk Zamknij (Close).
Usługa Kopia zapasowa (Backup)zapisuje kopie zapasowe całych plików, folderów lub dysków zaszyfrowanych w wybranym pliku kopii zapasowej. Plik ten może być kopiowany na nośniki z systemem plików FAT, takie jak dyskietki i pozostaje zabezpieczony, ponieważ jego zawartość jest zaszyfrowana.
Odtwarzanie zaszyfrowanego foldera lub pliku Zalecanym sposobem odtwarzania plików zaszyfrowanych jest użycie usługi Kopia zapasowa (Backup) systemu Windows 2000 lub innego programu narzędziowego, który obsługuje funkcje systemu Windows 2000. Operacja odtwarzania podtrzymuje szyfrowanie plików i agent odtwarzania nie musi mieć dostępu do kluczy prywatnych (restore keys). Po zakończeniu odtwarzania użytkownik posiadający klucz prywatny (private key) może korzystać z plików w normalny sposób.
Zastosowanie usługi Kopia zapasowa (backup) do odtwarzania pliku na tym samym komputerze Za pomocą opisanej poniżej procedury można odtworzyć pliki, foldery lub woluminy zaszyfrowane do innej lokalizacji na tym samym komputerze. Ta sama procedura służy do odtwarzania do lokalizacji pierwotnej. 1.
Z menu Akcesoria (Accessories) wybierz Narzędzia systemowe (System tools), a następnie naciśnij pozycję Kopia zapasowa (Backup).
2.
Wybierz zakładkę Odtwarzanie (Restore).
3.
Prawym przyciskiem myszki kliknij gałąź Plik (File) i z menu wybierz pozycję Plik wykazu (Catalog file). Pojawi się okno przedstawione na rysunku 5.8.
4.
Podaj ścieżkę do pliku kopii zapasowej lub potwierdź ustawienia domyślne.
5.
Rozwiń gałąź Plik (File) i sprawdź zaszyfrowany plik, folder lub wolumin, który ma być odtworzony.
6.
Plik będzie odtwarzany do lokalizacji alternatywnej. W polu listy (list box) Przywróć pliki do (Restore files to) wybierz opcję Lokalizacja Alternatywna (Alternate Location).
7.
W polu tekstowym Lokalizacja Alternatywna podaj nazwę foldera, do którego będzie odtwarzany zaszyfrowany plik, folder lub wolumin.
8.
Naciśnij przycisk Rozpocznij (Start restore).
9.
Naciśnij przycisk Zaawansowane (Advanced). Upewnij się, czy zaznaczono pole wyboru Przywróć Zabezpieczenia (Restore Security). Naciśnij przycisk OK.
10. Naciśnij przycisk OK, potwierdzając w ten sposób proces odtwarzania. 11. Naciśnij przycisk OK aby potwierdzić plik kopii zapasowej. Po zakończeniu odtwarzania naciśnij Raport (Report). Powinno pojawić się okno podobne do przedstawionego na rysunku 5.9. Sprawdź, czy wszystko jest w porządku, a następnie zamknij okno.
Rysunek 5.8. Okno dialogowe funkcji odtwarzania systemu Windows 2000 Nazwa Pliku Kopii Zapasowej (Backup File Name)
Rysunek 5.9. Dziennik Kopii Zapasowej (Backup Log) 12. W oknie dialogowym Postęp Przywracania (Restore Progress) naciśnij przycisk Zamknij (Close). 13. Za pomocą Eksploratora Windows (Windows Explorer) upewnij się, czy zaszyfrowane pliki i foldery zostały odtworzone prawidłowo.
Odtwarzanie plików do innego komputera Jeśli zachodzi konieczność korzystania z plików zaszyfrowanych na komputerze innym niż ten, na którym zaszyfrowano te pliki, trzeba zagwarantować, że w tamtym systemie dostępny będzie odpowiedni certyfikat szyfrowania (encryption certificate) i związany z nim klucz prywatny (private key). Można to zrobić za pomocą profilu mobilnego (roaming profile) lub przenosząc klucze ręcznie.
Jeśli użytkownik posiada profil mobilny, wtedy używane klucze szyfrowania (encryption keys) są jednakowe na wszystkich komputerach, na których się loguje. W tym przypadku można kopiować pliki zaszyfrowane do woluminu NTFS na innym komputerze, pracującym pod kontrolą systemu Windows 2000, dokładnie w taki sam sposób, jakby to były pliki niezaszyfrowane. Należy zwrócić uwagę, że pliki w trakcie przechodzenia przez sieć nie są chronione przez System Szyfrowania Plików (EFS). Do szyfrowania sieciowego konieczny jest protokół zabezpieczeń transportu, np. SSL. Aby przenieść klucze ręcznie, najpierw należy zrobić kopię zapasową certyfikatu szyfrowania (encryption certificate) i klucza prywatnego (private key), a następnie odtworzyć je na innym komputerze.
Wykonywanie kopii zapasowej certyfikatu szyfrowania (encryption certificate) i klucza prywatnego (private key) użytkownika Kopię zapasową certyfikatu szyfrowania i klucza prywatnego użytkownika wykonuje się zgodnie z poniższą procedurą. Są to cenne elementy. Należy konieczne zadbać, aby dysk kopii zapasowej był przechowywany w bezpiecznym miejscu nawet, jeśli zapisane na nim dane są zaszyfrowane. 1.
Uruchom konsolę MMC (Microsoft Management Console) i dodaj autonomiczny moduł dodatkowy (standalone snap-in) Certyfikaty (Certificates). Po pojawieniu się monitu wybierz opcję Moje Konto Użytkownika (My User Account), naciśnij przycisk Zakończ (Finish), potem naciśnij Zamknij (Close), a na koniecu OK.
2.
Rozwiń gałęzie Certyfikaty — bieżący użytkownik, Osobiste (Certificates — current user, Personal) i wybierz pozycję Certyfikaty (Certificates).
3.
Kliknij każdy z certyfikatów, który chcesz wyeksportować prawym przyciskiem myszki, z menu wybierz opcję Wszystkie zadania (All tasks), a następnie wybierz opcję Eksportuj (Export). Uruchomiony zostanie Kreator Eksportu Certyfikatów (Certificate Export Wizard).
4.
Naciśnij przycisk Dalej (Next).
5.
Zaznacz opcję Tak, eksportuj klucz prywatny (Yes, export the private key). Naciśnij przycisk Dalej.
6.
Pojawi się okno dialogowe Format Pliku Eksportowanego (Export File Format), przedstawione na rysunku 5.10. Domyślnie formatem eksportu jest Wymiana informacji osobistych — PKCS #12 (.PFX) (Personal information exchange — PKCS#12), z włączoną mocną ochroną (strong protection). Naciśnij przycisk Dalej.
7.
Podaj hasło chroniące plik PFX. Naciśnij przycisk Dalej.
8.
Podaj ścieżkę i nazwę pliku na dysku, na którym mają być zapisane dane w formacie PFX (np. D:\secure_docs\data.pfx). Naciśnij przycisk Dalej (next).
9.
Pojawi się lista ustawień. Potwierdź je, naciskając przycisk Zakończ (Finish).
10. Aby zamknąć kreatora (wizard), naciśnij przycisk OK.
Rysunek 5.10. Okno dialogowe Format Pliku Eksportowanego (Export File Format) W ten sposób certyfikat szyfrowania (encryption certificate) i klucz prywatny (private key) zostaną wyeksportowane do pliku PFX, który może być przesłany do innego komputera.
Odtwarzanie certyfikatu szyfrowania (encryption certificate) i klucza prywatnego (private key) użytkownika na innym komputerze W przykładzie opisanym poniżej do przenoszenia pliku PFX wykorzystano dyskietkę. Należy zwrócić uwagę, że plik PFX zawiera bardzo ważne informacje. Po zapisaniu na dyskietce pozostaje on zaszyfrowany, więc jest bezpieczny nawet, jeśli dyskietka zostanie zgubiona lub skradziona. Plik przesyłany przez sieć ma postać zwykłego tekstu, o ile nie korzysta się z zabezpieczeń sieciowych, takich jak SSL. Z tego względu nie należy przesyłać plików PFX przez
sieć, jeżeli nie ma pewności, że jest ona bezpieczna. Po przeniesieniu pliku zaleca się ponowne sformatowanie dyskietki. Odtwarzanie wykonuje się w następujący sposób: 1.
Zapisz kopię pliku PFX na dyskietkę i przenieś ją do komputera, na którym ma być wykonany import certyfikatu szyfrowania (encryption certificate) i klucza prywatnego (private key).
2.
Uruchom na tym komputerze moduł dodatkowy (snap-in) konsoli MMC Certyfikaty (Certificates).
3.
Prawym przyciskiem myszki kliknij składnicę (store) Osobiste (Personal), tzn. kontener Certyfikaty w gałęzi Osobiste, w menu włącz pozycję Wszystkie zadania (All tasks), a następnie wybierz opcję Import.
4.
Uruchomi się Kreator Importu Certyfikatów (Certificate Import Wizard). Naciśnij przycisk Dalej (Next) i podaj plik, który ma być zaimportowany, np. a:\data.pfx.
5.
Wpisz hasło, aby odczytać dane z pliku PFX. Upewnij się, czy zaznaczono odpowiednie pola wyboru, jak przedstawiono na rysunku 5.11. Naciśnij przycisk Dalej.
6.
Zaimportuj dane do składnicy Osobiste, jak przedstawiono to na rysunku 5.12. Naciśnij przycisk Dalej.
7.
Naciśnij przycisk Zakończ (Finish). Jeśli chcesz zmienić poziom zabezpieczeń (security level), naciśnij przycisk Ustaw Poziom Zabezpieczeń (Set Security Level). Ustawiony domyślnie poziom Średni (Medium) w większości przypadków jest wystarczający.
8.
Aby rozpocząć import, naciśnij przycisk OK. Po zakończeniu importowania zamknij Kreatora (Wizard), naciskając przycisk OK.
Mając dostępne te same klucze na dwóch komputerach, można przesyłać pliki zaszyfrowane dokładnie w ten sam sposób, w jaki przesyła się pliki niezaszyfrowane. Należy jednak pamiętać o podanych wcześniej ostrzeżeniach. Pliki zaszyfrowane w systemie EFS domyślnie są przesyłane przez sieć w postaci zwykłego tekstu, a do ich ochrony konieczny jest protokół zabezpieczeń sieciowych (network security protocol). Uwaga: Procedury opisane do tej pory w niniejszym rozdziale mogą być wykonane przez zwykłego użytkownika, chociaż tacy użytkownicy nie korzystają powszechnie z wiersza poleceń (command prompt). Następne procedury będą procedurami administracyjnymi, które może wykonać administrator lokalny, administrator domeny lub osoby, którym administrator nadał odpowiednie uprawnienia.
Rysunek 5.11. Rozwinięcie (unwrapping) pliku danych PFX
Rysunek 5.12. Importowanie danych do magazynu (store) Osobiste (Personal)
Zabezpieczenia domyślnego klucza odzyskiwania na pojedynczym komputerze Domyślne zasady odzyskiwania (recovery policy) są ustanawiane na każdym z komputerów indywidualnych jako część pierwszego logowania administratora lokalnego. Zasady te (policies) stanowią, że administrator lokalny (local administrator) jest domyślnym agentem odzyskiwania dla danego komputera. W procedurze opisanej poniżej zasada ta zostanie zmieniona tak, by na komputerze indywidualnym (standalone computer) nie było certyfikatu odzyskiwania (restore certificate) umożliwiającego kontrolowanie tożsamości agenta odzyskiwania (recovery agent) za pomocą dyskietki przechowywanej w miejscu zabezpieczonym: 1.
Na komputerze indywidualnym otwórz konsolę MMC i dodaj moduł dodatkowy Zasady Grupowe (Group Policy).
2.
Rozwiń gałęzie Zasady Komputera Lokalnego (Local Computer Policy), Konfiguracja Komputera (Computer Configuration), Ustawienia Systemu Windows (Windows Settings), Ustawienia Zabezpieczeń (Security Settings), Zasady Klucza Publicznego
(Public Key Policies), a następnie zaznacz pozycję Agenci Odzyskiwania Danych Zaszyfrowanych (Encrypted Data Recovery Agents). Wśród zasad znajduje się podpisany przez siebie certyfikat administratora (self-signed administrator certificate), który stanowi, że domyślnym agentem odzyskiwania (recovery agent) będzie administrator lokalny. 3.
Minimalizuj to okno.
4.
Uruchom moduł dodatkowy (snap-in) konsoli MMC Certyfikaty (Certificates).
5.
W magazynie (store) Osobiste (Personal) zlokalizuj certyfikat, który w polu listy (list box) Cele Certyfikatu (Certificate Purposes) ma zapisane Odzyskiwanie Plików (File Recovery), jak przedstawiono to na rysunku 5.13. Eksportuj ten certyfikat i klucz prywatny (private key) do pliku PFX na dyskietce.
6.
Przywróć okno modułu dodatkowego (snap-in) Zasady Grupowe (Group Policy) i usuń samopodpisany certyfikat administratora. Rysunek 5.14 przedstawia wynik tej operacji. Należy zwrócić uwagę, że magazyn Agenci odzyskiwania danych zaszyfrowanych nie zawiera żadnych certyfikatów. Po usunięciu certyfikatu nie ma zasad odzyskiwania (recovery policy), co spowodowało wyłączenie Systemu Szyfrowania Plików (EFS). System ten nie zezwala na szyfrowanie danych, jeśli nie skonfigurowano żadnego agenta odzyskiwania (recovery agent).
7.
Usuń także certyfikat i związany z nim klucz prywatny (private key) z magazynu Osobiste modułu dodatkowego (snap-in) konsoli MMC Certyfikaty. W ten sposób zagwarantujemy, że jedyna kopia klucza znajduje się w pliku PFX.
8.
Zamknij obydwa moduły dodatkowe (snap-ins).
9.
Przechowuj dyskietkę zawierającą plik PFX w kasie pancernej lub zamykanych szafkach i korzystaj z niej, gdy zachodzi konieczność odzyskania pliku.
Rysunek 5.13. Lokalizacja Certyfikaty Odzyskiwanie Pliku (File Recovery)
Rysunek 5.14. Usunięte zasady (policies) Agentów Odzyskiwania Danych Zaszyfrowanych (Encrypted Data Recovery Agents)
Zabezpieczanie domyślnego klucza odzyskiwania (recovery key) dla domeny Domyślne zasady odzyskiwania dla domeny są ustanawiane w sytuacji, gdy konfigurowany jest pierwszy kontroler domeny — tak samo, jak jest to w przypadku komputera autonomicznego (standalone computer). Domyślne zasady odzyskiwania (recovery policies) korzystają z podpisanych przez siebie certyfikatów (self-signed certificate) do uczynienia konta administratora domeny (domain administrator account) agentem odzyskiwania (recovery agent). Aby zmienić ustawienia domyślne trzeba zalogować się na pierwszym kontrolerze domeny (domain controller) w danej domenie i kontynuować zgodnie z opisaną wcześniej procedurą dla komputera autonomicznego (standalone computer). W ten sposób zostanie zabezpieczony klucz odzyskiwania dla domeny.
Dodawanie agentów odzyskiwania (recovery agents) W sytuacji, w której — zgodnie z prawem lub przepisami wewnętrznymi przedsiębiorstwa — dla danej domeny koniecznych jest kilku agentów odzyskiwania (recovery agents) lub agentem odzyskiwania musi być ktoś inny niż administrator domeny, może zajść konieczność ustanowienia agentami odzyskiwania konkretnych użytkowników. Aby to zrealizować, muszą zostać zakończone następujące operacje: •
musi zostać zainstalowana Jednostka Certyfikująca Przedsiębiorstwa (Enterprise Certificate Authority — CA), o ile takiej jednostki nie ma,
•
każdy użytkownik musi zażądać certyfikatu odzyskiwania plików (file recovery certificate),
•
dobrym rozwiązaniem jest utworzenie grupy, np. Agenci Odzyskiwania (Recovery Agents) i umieszczenie w tej grupie kont wyznaczonych użytkowników. Grupie tej można nadać odpowiednie prawa i uprawnienia dla operacji, np. nadanie uprawnienia do zapisywania w udziale sieciowym (network share), w którym mogą być przechowywane pliki certyfikatów.
Instalowanie jednostki certyfikującej przedsiębiorstwa (enterprise CA) Instalowanie jednostki certyfikującej w przedsiębiorstwie przebiega następująco: 1.
Zaloguj się do dowolnego kontrolera domeny.
2.
W oknie Panel Sterowania (Control Panel) wybierz pozycję Dodaj/Usuń programy (Add/Remove programs).
3.
Wybierz do instalowania usługę Serwer Certyfikatów (Certificate Server) i wykonaj kolejne czynności instalowania jednostki certyfikującej przedsiębiorstwa (enterprise CA).
Rozwiązania pokrewne zobacz na stronie: Instalowanie jednostki certyfikującej
Żądanie certyfikatu odzyskiwania plików
Każdy z wyznaczonych użytkowników powinien zalogować się do domeny i postępować według następującej procedury: 1.
Uruchom moduł dodatkowy (snap-in) konsoli MMC Certyfikaty (Certificates).
2.
Wybierz magazyn (store) Osobiste prawymprzyciskiem myszki, potem z menu włącz pozycję Wszystkie zadania (All tasks), a następnie opcję Żądaj Nowego Certyfikatu (Request New Certificate). Uruchomiony zostanie Kreator Żądania Certyfikatów (Certificate Request Wizard).
3.
Pierwsza strona kreatora jest stroną informacyjną. Aby przejść dalej, naciśnij przycisk Dalej (Next).
4.
W oknie dialogowym Szablon Certyfikatów (Certificates Template) wybierz Agent Odzyskiwania EFS (EFS Recovery Agent), a następnie naciśnij przycisk Dalej.
5.
Wprowadź przyjazną nazwę, aby odróżnić dany certyfikat od innych znajdujących się w magazynie (store). Można również podać opis. Naciśnij przycisk Dalej.
6.
Ostatnia strona przedstawia podsumowanie. Aby uzyskać certyfikat, naciśnij przycisk Zakończ (Finish). Wybierz instalowanie certyfikatu, który zostanie w ten sposób umieszczony w magazynie Osobiste.
Po otrzymaniu certyfikatu odzyskiwania plików (file recovery certificate) należy: •
skopiować dany certyfikat bez klucza prywatnego (private key) do pliku CER,o ile nie został opublikowany w usługach katalogowych. Umożliwi to administratorowi domeny dodać go do zasad odzyskiwania (recovery policies),
•
wyeksportować dany certyfikat z kluczem prywatnym do zabezpieczonego pliku PFX.
Kopiowanie certyfikatu do pliku CER Poniżej podano procedurę kopiowania certyfikatu do pliku CER. 1.
Uruchom moduł dodatkowy (snap-in) konsoli MMC Certyfikaty (Certificates) i wybierz certyfikat, który ma być skopiowany.
2.
Prawym przyciskiem myszki kliknij nazwę certyfikatu i z menu wybierz pozycję Wszystkie zadania (All tasks).
3.
Wybierz opcje Eksportuj (Export). Uruchomiony zostanie Kreator Eksportu Certyfikatów (Certificate Export Wizard). Aby rozpocząć eksportowanie, naciśnij przycisk Dalej (Next).
4.
Zaznacz opcję Nie eksportuj klucza prywatnego (No, do not export the private key). Naciśnij przycisk Dalej.
5.
Wybierz format pliku CER, np. certyfikat X.509 szyfrowany binarnie algorytmem DER (DER encoded binary X.509). Naciśnij przycisk Dalej.
6.
Podaj ścieżkę pliku do odpowiedniego udziału sieciowego. Naciśnij przycisk Dalej.
7.
Aby wyeksportować certyfikat, naciśnij przycisk Zakończ (Finish), a potem przycisk OK.
Eksportowanie certyfikatu do zabezpieczonego pliku PFX Po skopiowaniu certyfikatu do pliku CER, można wyeksportować go do zabezpieczonego pliku PFX na dyskietce. 1.
Postępuj zgodnie z opisem znajdującym się we wcześniejszej części niniejszego rozdziału pod tytułem „Odtwarzanie plików do innego komputera”.
2.
Po wyeksportowaniu certyfikatu z kluczem prywatnym (private key) do pliku PFX pamiętaj o usunięciu tego certyfikatu i klucza prywatnego z magazynu. Klucz ten jest bardzo ważny, ponieważ za jego pomocą można odszyfrować każdy z plików zaszyfrowanych, które obejmują dane zasady odzyskiwania (recovery policies).
Konfigurowanie zasad odzyskiwania dla domeny Po zidentyfikowaniu agentów odzyskiwania (recovery agents) i zapisaniu ich certyfikatów w plikach CER, administrator domeny może dodać te certyfikaty do zasad odzyskiwania, w sposób opisany poniżej: 1.
Edytuj obiekt zasad grupowych (GPO) Domyślne Zasady Domeny (Default Domain Policy).
2.
Rozwiń gałęzie Ustawienia Systemu Windows (Windows Settings), Ustawienia Zabezpieczeń (Security Settings), Zasady Klucza Publicznego (Public Key Policies), kliknij prawym przyciskiem myszki pozycję Agenci Odzyskiwania Danych Zaszyfrowanych (Encrypted Data Recovery Agents) i z menu wybierz pozycje Dodaj (Add), co przedstawiono na rysunku 5.15. Uruchomiony zostanie Kreator Dodawania Agenta Odzyskiwania (Add Recovery Agent Wizard).
Rysunek 5.15. Dodawanie agentów odzyskiwania danych zaszyfrowanych 3.
Pierwsza strona jest stroną informacyjną. Naciśnij przycisk Dalej (Next).
4.
Teraz można dodać agentów odzyskiwania. Jeśli certyfikaty agentów odzyskiwania są opublikowane w katalogu, skorzystaj z opcji Przeglądaj Katalog (Browse Directory). Jeśli nie są opublikowane, skorzystaj z opcji Przeglądaj Foldery (Browse Folders). W przypadku dodawania z katalogu ustalany jest identyfikator użytkownika dla certyfikatu, a informacja ta jest umieszczana w kolumnie Użytkownicy (Users). W przypadku dodawania z pliku w kolumnie Użytkownicy pojawi się informacja Użytkownik_nieznany (User_unknown), ponieważ przy dodawaniu certyfikatu z pliku CER nie ma identyfikatora zabezpieczeń (security identifier) właściciela klucza prywatnego (private key). Postępując zgodnie z procedurą opisaną wcześniej, przyszli agenci odzyskiwania (recovery agents) zapiszą swoje
certyfikaty w pliku CER. Dodawanie agentów odzyskiwania z pliku przedstawiono na rysunku 5.16. 5.
Dodaj agentów odzyskiwania według potrzeb. Naciśnij przycisk Dalej, a potem Zakończ.
Rysunek 5.16. Dodawanie certyfikatu odzyskiwania z pliku
Ustawianie zasad odzyskiwania (recovery policies) dla konkretnej jednostki organizacyjnej (OU) Za pomocą infrastruktury zasad grupowych (Group Policy infrastructure) można ustanowić unikatowe zasady odzyskiwania (recovery policy) dla grup komputerów w danej domenie. W przypadku jednostki organizacyjnej (OU) nie ma domyślnego obiektu zasad grupowych (Group Policy Object), który można odpowiednio skonfigurować. Z tego względu najpierw należy dodać nowy obiekt zasad grupowych, wybierając z menu Zasady Grupowe Właściwości (Group Policy
Properties) opcję Nowy (New). Następnie uruchom Edytor Zasad Grupowych (Group Policy Editor) i dla jednostki organizacyjnej (OU) powtarzaj czynności opisane powyżej dla gałęzi w domenie.
Odzyskiwanie pliku lub foldera Jeśli użytkownik zgubi swój klucz, przestanie pracować w danej firmie lub — jeśli jest to wymagane przez prawo — może zajść konieczność odzyskania foldera lub pliku przez agentów odzyskiwania (recovery agents). Proces odzyskiwania jest podobny do odszyfrowywania po tym, jak klucz odzyskiwania jest dostępny w systemie. Aby odzyskać plik lub folder, należy: 1.
Zapisać kopię zapasową pliku lub foldera w pliku BKF. Procedura opisana została wcześniej w części pod tytułem „Wykonywanie kopii zapasowej zaszyfrowanego foldera lub pliku”.
2.
Skopiować plik BKF do zabezpieczonego komputera agenta odzyskiwania (recovery agent).
3.
Agent odzyskiwania powinien odtworzyć pliki lub folder z pliku BKF lokalnie w systemie zabezpieczonym (secured system); zob. część pod tytułem „Odtwarzanie zaszyfrowanego foldera lub pliku”.
4.
Do importowania klucza odzyskiwania (recovery key) i certyfikatu z pliku PFX do systemu bezpiecznego (secured system) trzeba użyć modułu dodatkowego (snap-in) konsoli MMC Certyfikaty (Certificates); zob. część pod tytułem „Odtwarzanie zaszyfrowanego foldera lub pliku”.
5.
Po zaimportowaniu klucza odzyskiwania do odszyfrowania pojedynczych plików lub całych folderów można użyć Eksploratora Windows (Windows Explorer).
6.
Po odszyfrowaniu agent odzyskiwania (recovery agent) można ponownie utworzyć plik BKF, który tym razem będzie zawierał odszyfrowane pliki lub foldery i wysłać go do nadawcy żądania (requestor). Należy wziąć pod uwagę, że plik odszyfrowany może zawierać dane o kluczowym znaczeniu dla firmy i — zgodnie z przepisami prawa lub wewnętrznymi przepisami obowiązującymi w przedsiębiorstwie — muszą być przekazywane osobiście.
Wyłączanie systemu szyfrowania plików (EFS) dla określonego zestawu komputerów Czasami może zajść konieczność wyłączenia Systemu Szyfrowania Plików (EFS) dla autonomicznego komputera lub grupy komputerów w jednostce organizacyjnej (OU). Zalecanym sposobem jest ustanowienie zasad pustych (empty policies). Można to zrobić za pomocą lokalnego
Edytora Zasad Grupowych (Group Policy Editor) lub definiując obiekt zasad grupowych (GPO) z pustymi zasadami odzyskiwania (empty recovery policies) na poziomie jednostki organizacyjnej (OU), co opisano w części niniejszego rozdziału pod tytułem „Zabezpieczanie domyślnego klucza odzyskiwania na komputerze autonomicznym”. Należy zwrócić uwagę, że jest różnica pomiędzy zasadami pustymi (empty policies) a brakiem zasad (no policies). W Active Directory obowiązującą zasadą jest zbiór obiektów zasad grupowych (GPOs) zdefiniowanych na różnych poziomach struktury usług katalogowych. Brak zasad odzyskiwania (recovery policies) na wyższych poziomach, np. na poziomie domeny, powoduje, że obowiązują zasady ustalone na poziomach niższych. Puste zasady odzyskiwania w gałęziach wyższego poziomu wyłączają System Szyfrowania Plików poprzez brak obowiązujących certyfikatów odzyskiwania. Z drugiej strony, jeśli na poziomach wyższych po prostu brakuje zasad odzyskiwania, to mogą być one zdefiniowane w gałęziach niższego poziomu.
Rozdział 6
Klucze publiczne Rozwiązania natychmiastowe zobacz na stronie Uaktywnianie klientów domeny Stosowanie zabezpieczeń systemu Windows 2000 z kluczem publicznym Ustawianie zabezpieczeń sieci WWW Zastosowanie uwierzytelniania opartego na kluczach publicznych w programie Internet Explorer Konfigurowanie programu Microsoft Outlook, aby korzystać z protokołu Secure Sockets Layer Konfigurowanie zabezpieczeń poczty elektronicznej opartych na kluczu publicznym Konfigurowanie zabezpieczeń z zastosowaniem klucza publicznego (PK Security) dla programu Outlook Express Konfigurowanie programu Outlook do korzystania z zabezpieczeń z kluczem publicznym Uzyskiwanie współdziałania (interoperability)
W skrócie Kryptografia z kluczem publicznym (Public Key Cryptography — PKC) Infrastruktura Klucza Publicznego (Public Key Infrastructure — PKI) systemu Windows 2000 stanowi zintegrowany zestaw usług i narzędzi administracyjnych do tworzenia, wdrażania i zarządzania aplikacjami opartymi na kluczach publicznych, stosując kryptografię z kluczem publicznym (Public Key Cryptography — PKC). Algorytmy kryptograficzne służą do tworzenia szyfrogramów (ciphertext) na podstawie danych w postaci tekstu jawnego (plaintext data) i klucza szyfrowania (encryption key). Do odtworzenia danych w postaci zwykłego tekstu z danych zaszyfrowanych stosuje się klucz odszyfrowywania (decryption key). W kryptografii z kluczem symetrycznym (symmetric key cryptography) klucze szyfrowania i odszyfrowywania były identyczne. Strony, które chciały zabezpieczać wymianę danych za pomocą kluczy tajnych (secret keys) w przypadku kryptografii z kluczem symetrycznym (symmetric key cryptography) muszą wymienić się kluczami szyfrowaniaodszyfrowywania w sposób bezpieczny i przed rozpoczęciem wymiany danych zaszyfrowanych. W przypadku kryptografii z kluczem publicznym (PKC) klucz szyfrowania nie jest taki sam, jak klucz odszyfrowywania. Do zaszyfrowania za pomocą klucza publicznego służy funkcja jednokierunkowa (one-way function) zamieniająca dane w postaci tekstu jawnego (plaintext) w szyfrogram (ciphertext). Do odszyfrowania używa się innego klucza, związanego z kluczem szyfrowania, ale nie identycznego. Tak więc każdy z użytkowników posiada parę kluczy: klucz publiczny (public key) i klucz prywatny (private key). Klucz publiczny jest ogólnie dostępny, co umożliwia innym wysłanie danemu użytkownikowi danych zaszyfrowanych, które można odszyfrować tylko za pomocą klucza prywatnego tego użytkownika. Podobnie użytkownik — może użyć swojego klucza prywatnego do przetworzenia danych w taki sposób, żeby inni mogli sprawdzić, że dane te pochodzą od tego użytkownika. Ta druga cecha jest podstawą podpisów cyfrowych (digital signatures), co zostało opisane w dalszej części niniejszego rozdziału. W kolejnych podrozdziałach przedstawiono różne zastosowania kryptografii z kluczem publicznym (PKC). Tak, jak w poprzednich rozdziałach przyjęto, że użytkownikami są Bonnie i Clyde, którzy mogą wymieniać dane, ale nie mają ustalonego uprzednio klucza tajnego (shared secret).
Podpisy cyfrowe (digital signatures) Podpisy cyfrowe są oparte na przekształceniach matematycznych, które tworzą kombinację klucza prywatnego (private key) z danymi, które mają zostać opatrzone podpisem cyfrowym, spełniającą poniższe warunki: •
tylko posiadacz klucza prywatnego może utworzyć podpis cyfrowy (digital signature),
•
każdy, kto ma dostęp do odpowiedniego klucza publicznego może zweryfikować podpis cyfrowy,
•
każda modyfikacjach danych podpisanych unieważnia podpis cyfrowy.
Na przykład Clyde może wysłać do Bonnie wiadomość e-mail razem z dołączonym podpisem cyfrowym, dostarczając Bonnie w ten sposób informację do zweryfikowania pochodzenia komunikatu i potwierdzając, że zawartość komunikatu nie została naruszona na drodze od źródła do adresata.
Uwierzytelnianie podmiotu (entity authentication) Uwierzytelnianie podmiotu gwarantuje, że nadawca danych jest tym podmiotem, o którym odbiorca sądzi, że jest nadawcą, np. Bonnie otrzymuje dane od Clyde’a, a następnie wysyła do niego wyzwanie (challenge) zaszyfrowane za pomocą klucza publicznego Clyde’a. Ten dekoduje to wyzwanie i odsyła je Bonnie, potwierdzając w ten sposób swój dostęp do klucza prywatnego (private key) związanego z kluczem publicznym (public key), którego Bonnie użyła do wysłania wyzwania. Bonnie też może wysłać do Clyde’a wyzwanie w postaci tekstu jawnego (plaintext challenge). Clyde tworzy kombinację tego wyzwania z innymi informacjami opatrzonymi podpisem cyfrowym. Następnie Bonnie stosuje klucz publiczny (public key) Clyde’a do zweryfikowania podpisu i potwierdzenia, że Clyde ma związany z nim klucz prywatny. Wyzwanie (challenge) powoduje, że komunikat jest niepowtarzalny i zapobiega atakom metodą powtarzania (reply attacks), których mógłby dokonać ktoś zewnątrz, mający wrogie zamiary, np. Szeryf. Oba przypadki są określane jako wymiana komunikatów protokołu dowód posiadania (proof-ofposession), ponieważ Clyde potwierdza, że ma dostęp do konkretnego klucza prywatnego.
Uzgodnienie klucza tajnego (secret key) za pomocą klucza publicznego (public key)
Kryptografia z kluczem publicznym (PKC) pozwala również dwóm stronom na uzgodnienie klucza tajnego (secret key), korzystając z publicznych, niezabezpieczonych sieci komunikacyjnych. W tym przypadku oboje użytkowników, Bonnie i Clyde, generują liczbę losową, która tworzy połowę klucza tajnego (shared secret key). Clyde szyfruje swoją połowę klucza tajnego i wysyła do Bonnie, korzystając z jej klucza publicznego. Bonnie wysyła do Clyde’a swoja połowę, również zaszyfrowaną, korzystając z jego klucza publicznego. Każda ze stron może następnie odszyfrować komunikat przesłany przez druga stronę, uzyskując połowę klucza tajnego (shared secret) wygenerowanego przez drugą stronę. Po jednokrotnym przeprowadzeniu tej procedury klucz tajny może być zastosowany do zabezpieczenia łączności.
Wskazówka: Nie wolno przyjąć, że skoro klucz tajny (shared secret key) jest zabezpieczony, to pozostanie tajny na zawsze, bowiem nic nie jest wiecznie bezpieczne, np. 56-bitowy klucz tajny (shared secret key) we wrogim środowisku może być tajny tylko przez kilka godzin. Należy również pamiętać o tym, że klucze tajne (shared secret keys) są bezpieczne, jeśli dwie i tylko dwie strony znają klucz tajny. Administrator zabezpieczeń (security administrator) musi być czujny i pamiętać, że bezpieczeństwo sieci, którą administruje jest ruchomym celem.
Szyfrowanie danych masowych (bulk data) bez kluczy tajnych (shared secrets) Kryptografia z kluczem publicznym (PK cryptography) może służyć do szyfrowania danych masowych (bulk data) bez ustanowienia wcześniej klucza tajnego (shared secret). Można to osiągnąć, wybierając najpierw algorytm szyfrowania z kluczem tajnym (secret key encryption algorithm), a potem generując losowy klucz sesji (random session key) do szyfrowania danych. Przypuśćmy, że Clyde wysyła komunikat. Najpierw szyfruje klucz sesji (session key) za pomocą klucza publicznego (public key) Bonnie, a następnie wysyła do Bonnie klucz szyfrogramu (ciphertext key) razem z danymi zaszyfrowanymi. Bonnie może za pomocą swojego klucza prywatnego (private key) wyznaczyć klucz sesji, a potem użyć go do odszyfrowania danych.
Ochrona i określanie zaufania do kluczy kryptograficznych W przypadku kryptografii z kluczem tajnym (Secret Key Cryptography — SKC) Bonnie i Clyde mają zaufanie do swojego klucza tajnego (shared secret key), ponieważ komunikaty, w których przesyłają klucz, są zabezpieczone, a klucz jest przechowywany w sposób bezpieczny, co
uniemożliwia dostęp do klucza osobom nieuprawnionym, mającym złe zamiary. Stosując kryptografię z kluczem publicznym (PKC), Bonnie i Clyde muszą chronić tylko swoje klucze prywatne (private keys), a klucze publiczne (public keys), które nie muszą być tajne, jedynie współdzielić. Zaufanie do związku pomiędzy kluczem publicznym a znaną jednostką (entity) ma decydujące znaczenie dla zastosowania kryptografii z kluczem publicznym (PKC). Bonnie miałaby zaufanie do klucza publicznego Clyde’a, gdyby on przekazał jej ten klucz bezpośrednio, w sposób bezpieczny, ale bardziej prawdopodobne jest uzyskanie tego klucza w sposób niezabezpieczony, np. z ogólnodostępnego katalogu. Tak więc konieczne są inne sposoby, aby Bonnie miała pewność, że klucz publiczny, który otrzymała jest rzeczywiście kluczem publicznym należącym do Clyde’a. Jeden z takich sposobów korzysta z certyfikatów wydanych przez jednostkę certyfikującą (Certificate Authority — CA). Certyfikaty i jednostki certyfikujące (CA) opisano szczegółowo w rozdziale 7., a w niniejszym omówiono je krótko, aby umożliwić wyjaśnienie pojęcia klucz publiczny (public key).
Certyfikaty Certyfikaty stanowią sposób ustanowienia zaufania do relacji pomiędzy kluczem publicznym (public key) i właścicielem odpowiadającego mu klucza prywatnego (private key). Certyfikat jest oświadczeniem podpisanym cyfrowo, dotyczącym konkretnego przedmiotowego klucza publicznego (subject public key). Jego wystawca, posiadający inną parę kluczy prywatnych i publicznych, podpisuje certyfikat. Na ogół certyfikat zawiera także inne informacje związane z przedmiotowym kluczem publicznym, takie jak informacje o tożsamości podmiotu, który ma dostęp do właściwego klucza prywatnego. W ten sposób wystawca certyfikatu świadczy o ważności związku pomiędzy przedmiotowym kluczem publicznym a informacjami o tożsamości podmiotu certyfikowanego (subject identity information). Infrastruktura Klucza Publicznego (Public Key Infrastucture — PKI) w systemie Windows 2000 korzysta z certyfikatów opartych na standardzie ITU–T X.509, który jest obecnie najczęściej spotykaną formą certyfikatów. Jednak X.509 nie jest jedyną postacią certyfikatu, np. pakiet Pretty Good Privacy (PGP) korzysta ze specjalnej postaci certyfikatów. Wskazówka: Informacje na temat standardu Infrastruktury Klucza Publicznego (PKI) X.509 zawiera dokument RFC 2459m, który można znaleźć na stronie www.ietf.org/rfc/rfc2459.txt. Strona główna PGP znajduje się pod adresem www.pgpi.org.
Jednostki certyfikujące (Certificate Authorities) Jednostka certyfikująca (CA) jest to osoba lub usługa wydająca certyfikaty i działająca jako poręczyciel związku pomiędzy przedmiotowym kluczem publicznym (subject public key) a
informacją o tożsamości podmiotu certyfikowanego (subject identity information), który został zawarty w certyfikacie wydanym przez daną jednostkę certyfikującą. Różne jednostki certyfikujące (CAs) mogą weryfikować taki związek za pomocą różnych środków i przed obdarzeniem zaufaniem danej jednostki certyfikującej, która ma poręczyć za klucze publiczne (public keys), konieczne jest zrozumienie zasad i procedur tej jednostki (authority’s policies). Jednostką certyfikującą (CA) może zostać system Windows 2000 Server, jak również serwer Microsoft Exchange. Można także skorzystać z komercyjnych jednostek certyfikujących (commercial CA), takich jak VeriSign (www.verisign.com).
Zaufanie i sprawdzanie poprawności (validation) Po otrzymaniu podpisanego komunikatu Bonnie musi podjąć decyzję, czy zaufać (trust), że dany podpis jest ważny i został złożony, przez tego, kto tak twierdzi. Bonnie może za pomocą znanego klucza publicznego (public key) potwierdzić, że podpis jest matematycznie poprawny. Jednak nadal musi ona najpierw określić, czy klucz publiczny użyty do zweryfikowania podpisu należy do jednostki, która twierdzi, że złożyła dany podpis. Jeśli Bonnie nie ma pełnego zaufania, że dany klucz publiczny należy do Clyde’a, musi uzyskać niepodważalne dowody, świadczące o tym, kto jest właścicielem klucza. Jeśli Bonnie może zlokalizować certyfikat dla klucza publicznego Clyde’a, wydany przez jednostkę certyfikującą (CA), do której ma zaufanie, to może z kolei zaufać, że klucz publiczny Clyde’a naprawdę do niego należy. Bonnie może ufać, że naprawdę posiada klucz publiczny (public key) Clyde’a jeśli znajdzie certyfikat, który ma następujące właściwości: •
wystawca tego certyfikatu dostarczył podpis ważny w sensie kryptograficznym (cryptographically valid),
•
certyfikat ten poręcza związek pomiędzy nazwą „Clyde” i kluczem publicznym (public key) Clyde’a,
•
wydany został przez jednostkę, do której Bonnie ma zaufanie.
Przyjmując, że Bonnie znajduje taki certyfikat dla klucza publicznego (public key) Clyde’a, może następnie potwierdzić jego autentyczność za pomocą klucza publicznego jednostki certyfikującej, która wydała dany certyfikat. Skąd jednak Bonnie wie, że ten klucz publiczny naprawdę należy do danej jednostki certyfikującej (CA)? Bonnie musi teraz znaleźć certyfikat poręczający tożsamość jednostki certyfikującej (CA) i związek pomiędzy daną jednostką certyfikująca (CA) a kluczem publicznym tej jednostki. Ostatecznie Bonnie tworzy łańcuch certyfikatów (certificates chain) prowadzący od Clyde’a i jego klucza publicznego (public key), poprzez szereg jednostek certyfikujących (CA) i kończący się na certyfikacie wydanym temu, komu Bonnie ufa bez zastrzeżeń. Taki certyfikat nosi nazwę zaufanego certyfikatu głównego (trusted root certificate), ponieważ tworzy on część główną (root) hierarchii kluczy publicznych powiązań tożsamości (identity bindings), które Bonnie przyjmuje jako autentyczne. Kiedy Bonnie bez zastrzeżeń obdarzy zaufaniem konkretny zaufany certyfikat
główny (trusted root certificate), obdarzy również zaufaniem wszystkie certyfikaty wydane przez dany zaufany certyfikat główny, jak również wszystkie certyfikaty wydane przez dowolną podrzędną jednostkę certyfikującą (subordinate CA) poświadczoną przez dany zaufany certyfikat główny. Zestaw zaufanych certyfikatów głównych (trusted root certificates), którym Bonnie ufa bez zastrzeżeń jest jedyną informacją, którą musi zdobyć w sposób bezpieczny. Ten zestaw certyfikatów (certificates set) zabezpiecza system relacji zaufania (trust system) Bonnie i jej ufność do Infrastruktury Klucza Publicznego (PKI).
Składniki Infrastruktury Klucza Publicznego (PKI) systemu Windows 2000 Rysunek 6.1 przedstawia składniki tworzące Infrastrukturę Klucza Publicznego (PKI) systemu Windows 2000. Należy zwrócić uwagę, że jest to schemat logiczny — niektóre z tych składników mogą być uruchomione na tym samym komputerze. Usługi Certyfikatów firmy Microsoft (Microsoft Certificate Services) pozwalają użytkownikowi na wybranie jednej lub kilku jednostek certyfikujących (Ceritificate Authorities — CAs). Jednostki te są zintegrowane z usługami katalogowymi Active Directory, które dostarczają informacji o lokalizacji i zasady (policy) jednostki certyfikującej oraz umożliwiają publikowanie certyfikatów i informacji o odwołaniu (revocation information). Infrastruktura Klucza Publicznego (PKI) nie zastępuje mechanizmów ustanawiania relacji zaufania i autoryzacji w oparciu o kontroler domeny (DC) i Centrum Dystrybucji Kluczy (KDC) protokołu Kerberos. Infrastruktura Klucza Publicznego współpracuje z tymi usługami, stanowiąc ich rozszerzenie, które umożliwia aplikacjom sprostanie wymaganiom dotyczącym korzystania z nich przez Internet i ekstranet. W szczególności Infrastruktura Klucza Publicznego zaspokaja zapotrzebowanie na rozproszone, skalowalne identyfikowanie uwierzytelnianie, integralność i prywatność.
Rysunek 6.1. Infrastruktura Klucza Publicznego (PKI) systemu Windows 2000 Tworzenie, wdrażanie i zarządzanie aplikacjami korzystającymi z kluczy publicznych (PK-based applications) odbywa się na stacjach roboczych i serwerach pracujących pod kontrolą systemu Windows 2000 i Windows NT 4 oraz na stacjach roboczych pracujących pod kontrola systemu Windows 95 i Windows 98. Na rysunku 6.2 przedstawiono przegląd tych usług. Interfejs CryptoAPI Microsoftu zapewnia standardowy interfejs funkcji kryptograficznych usługodawców usług kryptograficznych (Cryptographic Service Providers — CSPs) programowych lub opartych na urządzeniach kryptograficznych. Niektórzy usługodawcy usług kryptograficznych (CSP), dostarczonych wraz z systemem Windows 2000 korzystają z infrastruktury kart elektronicznych zgodnej ze standardem Personal Computer/Smart Card (PC/SC) Microsoftu. Karty elektroniczne (smart cards) opisano w rozdziale 9.
Rysunek 6.2. Usługi aplikacji klucza publicznego Częścią interfejsu CryptoAPI jest zestaw usług do zarządzania certyfikatami w standardzie X.509 v3. Umożliwiają one obsługę magazynu trwałego (persistent storage), usługi wyliczeniowe (enumeration services) i dekodowanie (decoding). Usługi, które zawiera Infrastruktura Klucza Publicznego (PKI) zajmują się formatami komunikatów zgodnymi ze standardami Kryptografii z Kluczem Publicznym (Public Key Cryptography Standards — PKCS) oraz zmieniającym się projektem standardów PKIX (Public Key Infrastructure X.509) grupy Internet Engineering Task Force (IETF).
Uwaga: Więcej informacji na temat standardów PKCS można znaleźć pod adresem www.rsasecurity.com/rsalabs/pkcs.
Inne usługi korzystają z interfejsu CryptoAPI do udostępnienia programistom funkcji dodatkowych. Kanał bezpieczny (secure channel) obsługuje uwierzytelnianie i szyfrowanie sieciowe za pomocą protokołów standardowych (Transport Layer Security — TLS i Secure Sockets Layer — SSL). Dostęp do tych protokołów można uzyskać za pomocą interfejsu WinInet. Z wymienionych wyżej protokołów zabezpieczeń mogą korzystać protokoły HTTP i inne protokoły za pomocą Interfejsu Usługodawcy Usług Zabezpieczeń (Security Support Provider Interface — SSPI). Technologia zabezpieczeń (authenticode) obsługuje podpisywanie i weryfikację obiektów oraz określa pochodzenie i integralność składników pobranych z Internetu. Interfejsy kart elektronicznych ogólnego przeznaczenia (general purpose smart card interfaces)
umożliwiają obsługę logowania za pomocą kart elektronicznych (smart card logon), która jest dostępna w systemie Windows 2000.
System Szyfrowania Plików (Encrypting File System — EFS) W rozdziale 5. omówiono System Szyfrowania Plików (Encrypting File System — EFS) w systemie Windows 2000. Mówiąc krótko, System Szyfrowania Plików (EFS) umożliwia niezauważalne szyfrowanie i odszyfrowywanie plików zapisanych na dysku z systemem plików NTFS. Można szyfrować foldery i pojedyncze pliki. Aplikacje mają dostęp do zaszyfrowanych plików użytkownika w ten sam sposób, jak do plików niezaszyfrowanych, ale nie umożliwiają odszyfrowania zaszyfrowanych plików innego użytkownika. System szyfrowania plików korzysta z możliwości Infrastruktury Klucza Publicznego (PKI) do szyfrowania danych masowych (bulk encryption) bez wcześniejszego ustalania klucza tajnego (shared secrets). Każdy z użytkowników systemu szyfrowania plików generuje parę kluczy publicznych (public key pair) i uzyskuje Certyfikat Systemu Szyfrowania Plików (EFS certificate) wydany przez jednostkę certyfikującą przedsiębiorstwa (enterprise CA) w domenie systemu Windows 2000. System szyfrowania plików może także wygenerować certyfikat podpisany przez samego siebie (self-signed certificate) dla operacji autonomicznych (standalone operation), w których współdzielenie danych nie jest ważne. System Windows 2000 obsługuje zasady odzyskiwania (recovery policies) systemu szyfrowania plików, zgodnie z którymi zaufani agenci odzyskiwania (trusted recovery agents) generują parę kluczy publicznych odzyskiwania Systemu Szyfrowania Plików (EFS recovery), a jednostka certyfikująca przedsiębiorstwa wydaje im certyfikat odzyskiwania (recovery certificate) systemu szyfrowania plików. Certyfikaty agentów odzyskiwania systemu szyfrowania plików są publikowane dla klientów domeny za pomocą obiektów zasad grupowych (Group Policy Object — GPO). System Szyfrowania Plików (EFS) tworzy klucz losowy (random key) dla każdego pliku, który ma być zaszyfrowany. Następnie klucz publiczny (public key) systemu EFS użytkownika wykorzystywany jest do zaszyfrowania klucza tajnego (secret key) i skojarzenia go z danym plikiem. Oprócz tego kopia klucza tajnego (secret key), zaszyfrowana za pomocą klucza publicznego agenta odzyskiwania systemu szyfrowania plików, zostaje związana z plikiem. W systemie nie przechowuje się klucza tajnego (secret key) w postaci tekstu jawnego (plaintext). Podczas odzyskiwania pliku System Szyfrowania Plików (EFS) korzysta z klucza prywatnego (private key) użytkownika do uzyskania kopii klucza tajnego (secret key) zaszyfrowanego za pomocą klucza publicznego (public key) użytkownika. Jest on potem używany do odszyfrowania pliku w czasie rzeczywistym w trakcie operacji zapisu i odczytu z pliku. Podobnie agent odzyskiwania (recovery agent) może odszyfrować plik, korzystając z klucza prywatnego, aby uzyskać dostęp do klucza tajnego (secret key).
Logowanie za pomocą kart elektronicznych (smart cards) W systemie Windows 2000 wprowadzono możliwość logowania za pomocą kart elektronicznych (smart card logon) jako rozwiązanie alternatywne do uwierzytelniania za pomocą haseł. Rozwiązanie to jest oparte o infrastrukturę kart elektronicznych (smart card infrastructure), zgodną z zaleceniami grupy zadaniowej PC/SC i karty elektroniczne, w których zastosowano algorytm RSA, wraz z obsługującymi je usługodawcami usług kryptograficznych (CSP) interfejsu CryptoAPI. W procesie uwierzytelniania stosuje się protokół Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) integrujący w systemie Windows 2000 uwierzytelnianie za pomocą klucza publicznego (PK-based authentication) z systemem kontroli dostępu Kerberos. Działający system rozpoznaje włożenie karty elektronicznej (smart card) jako alternatywę dla standardowej sekwencji zwracającej uwagę zabezpieczeń (secure attention sequence) Ctrl+Alt+Delete, która inicjuje logowanie. Następnie użytkownik wprowadza kod PIN, który kontroluje dostęp do operacji za pomocą klucza prywatnego (private key) zapisanego na karcie elektronicznej. W tym systemie karta elektroniczna zawiera także kopie certyfikatu użytkownika, wydanego przez jednostkę certyfikującą przedsiębiorstwa (enterprise CA). Pozwala to użytkownikowi na przemieszczanie się w granicach domeny. Karty elektroniczne opisano szczegółowo w rozdziale 9.
Zabezpieczenia protokołu IP (IPSec) IPSec definiuje protokoły szyfrowania w sieci na poziomie warstwy (layer) protokołu IP. Nie wymaga to stosowania technologii klucza publicznego (PK-based), dlatego można wykorzystać klucze tajne (shared secret keys), które są bezpiecznie przesyłane do szyfrowania jako dane poza pasmem (out-of-band) do punktów końcowych sieci (network end-points). Technologia klucza publicznego (PK-based technology) jest praktycznym rozwiązaniem w przypadku tworzenia skalowalnej struktury z rozproszonymi relacjami zaufania (scalable distributed trust architecture), a szczególnie takiej, w której urządzenia korzystające z protokołu IPSec mogą dokonywać wzajemnego uwierzytelnienia i zgadzają się na klucze szyfrowania bez wstępnego ustanowienia kluczy tajnych (shared secrets). Firmy stosujące protokół IPSec, łącznie z Microsoftem, pracują nad ustanowieniem standardu certyfikatów współpracujących ze sobą (interoperable certificates), rejestrowania certyfikatów (certificate enrollment) oraz protokołów zarządzania (management protocols). W chwili tworzenia tej książki pozostało do wykonania zadanie dotyczące zapewnienia współpracy (interoperability) pomiędzy urządzeniami korzystającymi z protokołu IPSec (IPSec devices) i implementacją Infrastruktury Klucza Publicznego (PKI). Firma Microsoft rozwija opracowaną przez siebie Infrastrukturę Klucza Publicznego (PKI) systemu Windows 2000 w połączeniu ze zmieniającymi się standardami wymienionymi powyżej. IPSec opisano szczegółowo w rozdziale 10.
Rozwiązania natychmiastowe Uaktywnianie klientów domeny System Windows 2000 zwiera zestaw usług podstawowych (core services) do obsługi rozwijania i instalowania współdziałających aplikacji korzystających z klucza publicznego (PK-based applications). Najbardziej znaczącą nową funkcją systemu Windows 2000 jest integracja z administrowaniem domeną i modelem zasad (policies model). Technologia klucza publicznego (Public Key Technology — PKT) jest uzależniona od zdolności do generowania i zarządzania kluczami jednego lub kilku algorytmów z kluczem publicznym (PK algorithm). Interfejs CryptoAPI obsługuje instalowalnych usługodawców usług kryptograficznych (CSPs), którzy z kolei obsługują generowanie i zarządzanie kluczami dla wielu algorytmów kryptograficznych (cryptographic algorithms). Klient domeny (domain client) ma uaktywnione zabezpieczenia z kluczem publicznym (PK security) po uzyskaniu certyfikatu zabezpieczeń (security certificate) od serwera certyfikatów (certificate server) systemu Windows 2000, Menedżera Kluczy Wymiany (Exchange Key Manager) lub usługodawcy komercyjnego, np. VeriSign. Na ogół jest to etap instalacji, na którym konfiguruje się usługi pocztowe. Jeśli jednak użytkownik musi wysłać żądanie takiego certyfikatu, dokonuje się tego w następujący sposób: 1.
Otwórz przeglądarkę (browser) i połącz się z adresem http://ServerName/CertSRV, gdzie ServerName jest nazwą serwera jednostki certyfikującej (CA server).
2.
Ze strony powitalnej Usługi Certyfikacji Microsoftu (Microsoft Certificate Services) wybierz pozycję Żądanie Certyfikatu (Request a Certificate). Naciśnij przycisk Dalej (Next).
3.
Wybierz Żądanie Certyfikatu Dla Użytkownika (User Certificate Request) i w polu listy zaznacz Certyfikat Użytkownika (User Certificate). Naciśnij przycisk Dalej.
4.
Jeśli spróbujesz połączyć się z autonomiczną jednostką certyfikującą (standalone CA) pojawi się strona Certyfikat Użytkownika — identyfikator (User Certificate – identifying information). W tym przypadku wypełnij formularz w trybie online i naciśnij przycisk Dalej. W przypadku łączenia się z jednostką certyfikującą przedsiębiorstwa (enterprise CA) informacje zostaną oczytane z Active Directory i należy wówczas wysłać żądanie.
5.
Naciśnij przycisk Wyślij (Submit). Program wygeneruje parę kluczy publiczny-prywatny (public-private key) oraz żądanie certyfikatu (certificate request) na podstawie wprowadzonych danych, a następnie wysyła żądanie do jednostki certyfikującej (CA). Naciśnij przycisk Instaluj Certyfikat (Install this Certificate).
Uwaga: Na potrzeby powyższej procedury przyjęto, że jednostka certyfikująca (CA) została zainstalowana i uzyskano certyfikat główny (root certificate). Przyjęto także, że jednostka certyfikująca jest skonfigurowana w ten sposób, że zatwierdza żądania automatycznie. Jeśli te warunki nie są spełnione, należy zapoznać się z podrozdziałem „Instalowanie certyfikatów jednostek certyfikujących” w rozdziale 7.
Rozwiązania pokrewne zobacz na stronie Instalowanie certyfikatów jednostek certyfikujących Mechanizmy przechowywania danych do generowania kluczy (keys material) zależą od wybranego usługodawcy usług kryptograficznych (CSP). Programowi usługodawcy usług kryptograficznych software (CSPs), które dostarcza Microsoft, nazywani też podstawowymi usługodawcami kryptograficznymi (base CSPs), przechowują dane do generowania kluczy w formie zaszyfrowanej dla konkretnych użytkowników lub konkretnych komputerów. Umożliwiają również kontrolę nad możliwością eksportowania par kluczy publiczny-prywatny, kontrolując eksport kluczy prywatnych przez usługodawców usług kryptograficznych (CSPs) i kontrolę użycia, która określa zachowanie funkcji powiadamiania użytkownika (user notification) podczas próby użycia klucza prywatnego (private key) przez aplikację. Inni usługodawcy usług kryptograficznych mogą korzystać z innych mechanizmów, np. usługodawcy usług kryptograficznych (CSP) dla kart elektronicznych (smart card) przechowują parę kluczy publicznych (public key pair) na zabezpieczonym przed penetracją sprzęcie dla kart elektronicznych, gdzie zwykle wymagane jest wprowadzenie kodu PIN, aby uzyskać dostęp do operacji, które korzystają z klucza prywatnego.
Odzyskiwanie kluczy Przy odzyskiwaniu klucza zakłada się, że istnieje magazyn trwały (persistent storage) czyjegoś klucza prywatnego, co pozwala na dostęp uprawnionym osobom bez wiedzy i zgody właściciela. Może to być konieczne, aby zagwarantować dostęp do najważniejszej korespondencji przedsiębiorstwa lub, by spełnić wymagania wymiaru sprawiedliwości. Funkcja odzyskiwania klucza jest przydatna tylko wtedy, gdy stosuje się ją do kluczy, które były używane do szyfrowania danych trwałych (persistent data), takich jak klucze wymiany kluczy (key exchange keys). Archiwizowanie identyfikacji kluczy prywatnych podpisu cyfrowego jest rzadko spotykane, ponieważ zagraża to bezpieczeństwu systemu. Odzyskiwanie kluczy prywatnych mogłoby umożliwić podszywanie się osoby nieuprawnionej pod właściciela klucza. Microsoft Exchange umożliwia obecnie obsługę odzyskiwania kluczy wymiany kluczy (key exchange keys), więc można odczytywać zaszyfrowane e-maile. Są również dostępni niezależni usługodawcy usług kryptograficznych (CSPs) umożliwiający ogólną obsługę odzyskiwania kluczy. Zalecany sposób postępowania w przypadku utraty przez użytkownika klucza prywatnego jest następujący:
•
użytkownik żąda nowego certyfikatu zabezpieczeń (security certificate), co zostało opisane powyżej,
•
zaszyfrowane dokumenty użytkownika są odzyskiwane przez agenta odzyskiwania (recovery agent). Opisano to szczegółowo w rozdziale 5.
Rozwiązania pokrewne zobacz na stronie: Dodawanie agentów odzyskiwania (recovery agents) Odzyskiwanie pliku lub foldera
Rejestrowanie certyfikatu Technologia klucza publicznego (PK-based technology) zwykle polega na certyfikatach, aby związać klucze publiczne ze znanymi jednostkami (known entities). Infrastruktura Klucza Publicznego (PKI) systemu Windows 2000 obsługuje rejestrowanie się w celu uzyskania certyfikatu (certificate enrollment) od jednostki certyfikującej przedsiębiorstwa (enterprise CA) firmy Microsoft lub niezależnych jednostek certyfikujących (CAs). Do obsługi rejestrowania (enrollment) stosuje się komunikaty żądania certyfikatów w formacie PKCS #10 i odpowiedzi w formacie PKCS #7, zawierających certyfikat lub łańcuch certyfikatów (certificate chain). W czasie powstawania tej książki obsługiwane są certyfikaty, korzystające z algorytmu RSA, Digital Signature Algorithm (DSA) oraz Diffie – Hellman’a. Komunikaty w standardzie PKCS #10 i PKCS #7 są obsługiwane za pomocą elementu sterującego xenroll.dll, który może być umieszczony w skrypcie w przypadku rejestrowania poprzez sieć Web (Web-based enrollment) lub wywoływany programowo w przypadku innych procedur transportowych, takich jak wywołanie procedur zdalnych (Remote Procedure Call — RPC), model obiektowy składników rozproszonych (Distributed Component Object Model —DCOM) oraz poczta elektroniczna. Element ten umożliwia aplikacji wywołującej określenie atrybutów, które zawiera komunikat w formacie PKCS #10 oraz pozwala na korzystanie z istniejącej pary kluczy lub wygenerowanie nowej pary. Element sterujący rejestrowaniem (enrollment control) umożliwia zarządzanie informacjami o stanie aplikacji wywołującej (state management), aby porównać wydane certyfikaty z żądaniami oczekującymi i dostarcza środków do tworzenia wewnętrznych powiązań pomiędzy certyfikatem, usługodawcą usług kryptograficznych (CSP), który wygenerował parę kluczy oraz nazwą kontenera pary kluczy (key-pair container). Infrastruktura Klucza Publicznego (PKI) obsługuje wiele sposobów rejestrowania (enrollment), łącznie z rejestrowaniem przez sieć Web, kreatorem rejestrowania (enrollment wizard) oraz rejestrowaniem automatycznym sterowanym zasadami (policy driven autoenrollment), które jest częścią procesu logowania się użytkownika. Dokładny opis rejestrowania za pomocą pliku w standardzie PKCS #10 zamieszczono w rozdziale 7.
Rozwiązania pokrewne zobacz na stronie: Żądanie certyfikatów zaawansowanych Rejestrowanie za pomocą pliku żądania PKCS #10
Odnawianie certyfikatów Odnawianie certyfikatów (certificates renewal) jest zasadniczo podobne do rejestrowania (enrollment), ale korzysta z relacji zaufania danego certyfikatu. W przypadku odnawiania przyjęto, że jednostka żądająca chce uzyskać nowy certyfikat z takimi samymi atrybutami, jak istniejący, ważny certyfikat, ale z przedłużonym okresem ważności. Przy odnawianiu można użyć istniejącego klucza publicznego (public key) lub utworzyć nowy klucz publiczny. Żądanie odnowienia może być przetworzone wydajniej, ponieważ istniejące atrybuty certyfikatu nie muszą być powtórnie weryfikowane. Obecnie odnawianie (renewal) jest obsługiwane przez Infrastrukturę Klucza Publicznego (PKI) systemu Windows 2000 dla certyfikatów rejestrowanych automatycznie. W innych przypadkach odnowienie jest traktowane jako nowe żądanie zarejestrowania (enrollment request). Procedura odnawiania certyfikatu zabezpieczeń (security certificate) jest dokładnie taka sama, jak procedura żądania takiego certyfikatu opisana w niniejszym podrozdziale.
Zastosowanie kluczy i certyfikatów Klucze kryptograficzne (cryptographic keys) i związane z nimi certyfikaty są przechowywane i zarządzane przez podsystem CryptoAPI. Usługodawcy usług kryptograficznych (CSPs) zarządzają kluczami, a magazyny certyfikatów (certificate stores) CryptoAPI zarządzają certyfikatami. Magazyny certyfikatów są składnicami (repositories) związanych z nimi właściwości. Infrastruktura Klucza Publicznego (PKI) definiuje pięć standardowych magazynów certyfikatów: •
Moje (My) — przechowuje certyfikaty użytkowników lub komputerów, których klucz prywatny jest dostępny,
•
CA — przechowuje certyfikaty jednostek certyfikujących (CAs) wydających certyfikaty lub pośrednich jednostek certyfikujących (intermediate CAs), które służą do tworzenia łańcuchów weryfikacji certyfikatów (certificate verification chains),
•
ZAUFANIE (Trust) — przechowuje listy zaufań certyfikatów (Certificate Trust Lists — CTLs), które dostarczają mechanizmy umożliwiające administratorowi określenie zbioru zaufanych jednostek certyfikujących (CAs). Mogą one być przesyłane przez łącza niezabezpieczone, ponieważ są podpisane cyfrowo,
•
GŁÓWNY (Root) — przechowuje certyfikaty jednostek certyfikujących, podpisane przez nie same (self-signed), dla zaufanych głównych jednostek certyfikujących (root CAs),
•
UserDS — stanowi schemat logiczny (logical view) składnicy certyfikatów (certificate repository), zapisanych w Active Directory, np.we właściwości UserCertificate obiektu Użytkownik (User). Służy do uproszczenia dostępu do wyżej wymienionych składnic zewnętrznych.
Wymienione powyżej magazyny logiczne (logical stores) przedstawiają spójny widok certyfikatów w całym systemie, które są zapisane w różnych magazynach fizycznych (physical stores), takich jak dysk twardy, karty elektroniczne, itd. Magazyny te umożliwiają aplikacjom współdzielenie certyfikatów i gwarantują działanie zgodne z zasadami administracyjnymi (administrative policy). Funkcje zarządzania certyfikatami (certificate management functions) umożliwiają dekodowanie certyfikatów w standardzie X.509v3 i wyliczanie (enumeration functions), które pomaga zlokalizować konkretny certyfikat. Aby uprościć tworzenie aplikacji w magazynie (store) Moje (My) zapisane są właściwości certyfikatu, wskazujące usługodawcę usług kryptograficznych (CSP) i nazwę zestawu kluczy związanego z nim klucza prywatnego (private key). Po tym, jak aplikacja wybierze certyfikat, może skorzystać z tych informacji, aby uzyskać kontekst usługodawcy usług kryptograficznych (CSP context) dla właściwego klucza prywatnego (private key).
Odzyskiwanie par kluczy publicznych i certyfikatów Jeśli pary kluczy publicznych (public key pairs) i certyfikaty zostały utracone w wyniku awarii systemu, ich przywrócenie może być kosztowne i zająć dużo czasu. Z tego względu Infrastruktura Klucza Publicznego (PKI) systemu Windows 2000 umożliwia wykonywanie kopii zapasowych oraz odtwarzanie certyfikatów i związanych z nimi par kluczy za pomocą narzędzi administracyjnych do zarządzania certyfikatami. Eksportując certyfikat za pomocą Menedżera Certyfikatów (Certificate Manager) można podać, czy związana z nim para kluczy ma być również eksportowana. Jeśli opcja ta zostanie wybrana, informacja będzie wyeksportowana w postaci komunikatu w standardzie PKCS #12, zaszyfrowanego za pomocą dostarczonego hasła. Komunikat ten może być później zaimportowany do danego lub innego systemu i zastosowany do odtworzenia certyfikatu i kluczy. Poniżej opisano procedurę eksportowania certyfikatu i związanej z nim pary kluczy: 1.
W module dodatkowym (snap-in) konsoli MMC Certyfikaty (Certificates) rozwiń gałąź Certyfikaty i przejdź do certyfikatu, który chcesz wyeksportować.
2.
Prawym przyciskiem myszki kliknij certyfikat, z menu wybierz pozycje Wszystkie zadania (All tasks), a następnie opcję Eksportuj (Export). Uruchomi się Kreator Eksportu Certyfikatów (Certificate Export Wizard).
3.
Wybierz opcję eksportowania klucza prywatnego, określ format pliku eksportu i podaj hasło.
4.
Określ plik docelowy, naciśnij przycisk Dalej (Next), potem przycisk Zakończ (Finish) i OK.
Na potrzeby powyższej procedury przyjęto, że parę kluczy można wyeksportować za pomocą usługodawcy usług kryptograficznych (CSP). Założenie to jest prawdziwe w przypadku usługodawców usług kryptograficznych (CSPs) firmy Microsoft, jeśli znacznik możliwości eksportowania (exportable flag) CRYPT_EXPORTABLE został ustawiony przy generowaniu klucza. Niezależni usługodawcy usług kryptograficznych mogą, ale nie muszą, umożliwiać eksportowania klucza prywatnego — np. w przypadku usługodawców usług kryptograficznych dla kart elektronicznych (smart cards) często nie ma takiej możliwości. W przypadku programowych usługodawców usług kryptograficznych (software CSPs) z kluczami, których nie można eksportować, konieczne jest wykonanie kopii zapasowej całego systemu, włącznie ze wszystkimi danymi z Rejestru.
Wskazówka: Jeśli parę kluczy można eksportować, to ktoś może ją również zaatakować. Podczas pisania niniejszego rozdziału trwała w Internecie dyskusja dotycząca bezpieczeństwa kluczy, które można eksportować, korzystając z programu Internet Explorer lub Outlook Express. Zapis dyskusji można było znaleźć pod adresem www.drhconsultancy.demon.co.uk/cexport.html. Strony internetowe mogą mieć krótki żywot, więc właściwy adres URL można znaleźć, uruchamiając wyszukiwanie takich zwrotów, jak CRYPT_EXPORTABLE, CRYPT_USER_PROTECTED, CryptGenKey oraz CryptImportKey.
Stosowanie tych samych aplikacji korzystających z klucza publicznego (PK-based) na różnych komputerach Użytkownicy tych samych aplikacji korzystających z klucza publicznego (PK-based) na różnych komputerach pracujących w środowisku Windows w danym przedsiębiorstwie są określani jako użytkownicy mobilni (roaming users). Infrastruktura Klucza Publicznego (PKI) systemu Windows 2000 obsługuje użytkowników mobilnych (roaming users) na dwa sposoby: •
w przypadku usługodawców usług kryptograficznych (CSPs) firmy Microsoft przenoszenie (roaming) kluczy i certyfikatów jest dokonywane za pomocą profili mobilnych (roaming profile). Po ich uaktywnieniu odbywa się to w sposób niezauważalny dla użytkownika,
•
urządzenia, takie jak karty elektroniczne umożliwiają pracę użytkownikom mobilnym (roaming) pod warunkiem, że zawierają fizyczny magazyn certyfikatów (physical certificate store). Usługodawcy usług kryptograficznych dla kart elektronicznych, które dostarczono z systemem Windows 2000, mają taką funkcję.
Ufanie certyfikatowi Zaufanie związane z weryfikowaniem certyfikatu jest oparte na zaufaniu związanym z jednostką certyfikującą (CA), która wydała dany certyfikat. Na potrzeby Infrastruktury Klucza Publicznego (PKI) przyjęto hierarchię jednostek certyfikujących z główną jednostką certyfikującą (rooted CA hierarchy), w której kontrola relacji zaufania (control of trust) jest oparta na decyzjach dotyczących głównych jednostek certyfikujących (root CAs). Jeśli określony certyfikat końcowy (end-entity certificate) może być przedstawiony w łańcuchu certyfikatów znanej, zaufanej głównej jednostki certyfikującej (trusted root CA) i zastosowanie danego certyfikatu zgadza się z kontekstem aplikacji (application context), to certyfikat uznawany jest za ważny. Jeśli którykolwiek z warunków nie jest spełniony, certyfikat jest uznawany za nieważny. Wewnątrz Infrastruktury Klucza Publicznego (PKI) użytkownicy mogą podejmować tylko takie decyzje dotyczące bezpieczeństwa, które mają wpływ na nich samych. Robią to instalując lub usuwając zaufane główne jednostki certyfikujące oraz konfigurując związane z nimi ograniczenia stosowania za pomocą narzędzi administracyjnych do zarządzania certyfikatami. Jednak zarządzanie certyfikatami przez zwykłych użytkowników powinno być wyjątkiem, a nie regułą. Relacje zaufania powinny być ustanowione jako część zasad przedsiębiorstwa (enterprise policy). Relacje zaufania ustanowione poprzez zasady są automatycznie przekazywane do komputerówklientów pracujących pod kontrolą systemu Windows 2000.
Stosowanie zabezpieczeń z kluczem publicznym (public key security) systemu Windows 2000 Zasady zabezpieczeń (security policies) mogą być stosowane do stron sieci Web (Web sites), domen lub jednostek organizacyjnych i mają wpływ na związane z nimi grupy zabezpieczeń użytkowników i komputerów. Zasady zabezpieczeń z kluczem publicznym (PK security policy) umożliwiają definiowanie i zarządzanie zasadami centralnie, a wdrażanie tych zasad globalnie. Zaufanie do głównych jednostek certyfikujących (root CAs) może być ustawione za pomocą zasad, aby ustanowić relacje zaufania (trust relationships), które klienci domeny stosują, weryfikując certyfikaty z kluczem publicznym. Zestaw zaufanych jednostek certyfikujących konfiguruje się za pomocą Edytora Zasad Grupowych (Group Policy Editor). Zestaw ten może być skonfigurowany dla konkretnego komputera i można go zastosować globalnie do wszystkich użytkowników tego komputera. Zastosowanie zasad grupowych (Group Policy) i Edytora Zasad Grupowych opisano w rozdziale 3. Poniżej zamieszczono procedurę konfigurowania zaufania (trust) domeny do zewnętrznej jednostki certyfikującej (CA):
1.
Otwórz okno dialogowe Zasady Grupowe w Domenie Właściwości (Domain Group Policy Properties) i edytuj obiekt zasad grupowych (GPO) Domyślne Zasady Grupowe (Default Domain Policy).
2.
Rozwiń gałąź Konfiguracja Komputera\Ustawienia Systemu Windows\Ustawienia Zabezpieczeń\Zasady Kluczy Publicznych (Public Key Policies\Computer Configuration\Windows Settings\Security Settings), następnie prawym przyciskiem myszki kliknij pozycję Zaufane Główne Jednostki Certyfikujące (Trusted Root Certification Authorities).
3.
Z menu kontekstowego wybierz pozycje Wszystkie zadania (All tasks), a następnie wybierz Importuj (Import). Uruchomiony zostanie Kreator Importu Certyfikatów (Certificate Import Wizard).
4.
Naciśnij przycisk Dalej (Next). W polu Nazwa pliku (File name) wpisz nazwę pliku zawierającego certyfikat główny (root certificate), który chcesz importować lub naciśnij przycisk Przeglądaj (Browse) i znajdź ten plik. Naciśnij przycisk Dalej.
5.
Wpisz hasło i naciśnij przycisk Dalej. Wybierz opcję Umieść wszystkie certyfikaty w następującym magazynie (Place all certificates in the following store). Magazynem (store) docelowym jest Zaufane Główne Jednostki Certyfikujące (Trusted Root Certification Authorities) w obiekcie zasad grupowych (GPO).
6.
Aby zaimportować certyfikat, naciśnij przycisk Zakończ (Finish). Naciśnij przycisk OK, aby zamknąć okno komunikatów (message box). Aby zastosować zasady do obiektu zasad grupowych (GPO), naciśnij OK. Potem zamknij konsolę MMC.
Uwaga: Dokładniej omówiono powyższą procedurą w rozdziale 7., gdzie opisano ją w kontekście Usług Certyfikatów (Certificate Services). Tą samą procedurę można zastosować do obiektów zasad grupowych (GPO) niższego rzędu związanych z jednostkami organizacyjnymi (OUs) zawierającymi grupy użytkowników lub (i) komputerów.
Rozwiązania pokrewne zobacz na stronie Edytowanie obiektu zasad grupowych Konfigurowanie zaufania domeny do zewnętrznej jednostki certyfikującej Oprócz ustalenia zaufania do głównej jednostki certyfikującej (root CA) można także ustawić właściwości danej jednostki certyfikującej (CA), które ograniczą zakres stosowania certyfikatów wydanych przez tą jednostkę. Ograniczenia są określane na podstawie identyfikatorów obiektów (OID), zgodnie z rozszerzeniem ExtendedKeyUsage w dokumencie IETF PKIX część 1. Identyfikatory obiektów (OID) są środkami ograniczania korzystania do dowolnych kombinacji następujących elementów: •
uwierzytelnianie serwerów,
•
uwierzytelnianie klientów,
•
dołączanie do programu podpisów cyfrowych (code),
•
poczta elektroniczna,
•
system końcowy zabezpieczeń IP (IPSec end system),
•
tunel IPSec,
•
użytkownik IPSec,
•
znaczniki czasu (time-stamping),
•
System Szyfrowania Plików (Encrypted File System) firmy Microsoft.
Rodzaje certyfikatów zapewniają szablony dla certyfikatów i kojarzą je z nazwą uniwersalną (common name). Szablon ten określa elementy, takie jak wymagania dotyczące nazw (naming requirements), okres ważności (validity period), dopuszczeni do generowania kluczy prywatnych usługodawcy usług kryptograficznych (CSPs), algorytmy oraz rozszerzenia, które powinny być włączone do certyfikatu. Rodzaje certyfikatów (certificate types) są logicznie rozdzielone na rodzaje komputerów i użytkowników i są stosowane do odpowiednich obiektów zasad (policy objects). Mechanizm ten jest zintegrowany z zasadami wydawania certyfikatów (issuing policy) jednostki certyfikującej przedsiębiorstwa (enterprise CA). Usługa jednostka certyfikująca (CA service) otrzymuje zestaw rodzajów certyfikatów jako część swojego obiektu zasad (policy object). Rodzaje certyfikatów są używane przez moduł zasad przedsiębiorstwa (enterprise policy) do określania rodzajów certyfikatów, które dana jednostka certyfikująca może wydawać. Jednostka ta (CA) odrzuci żądanie certyfikatu, który nie spełnia określonych warunków. Rozwiązania pokrewne zobacz na stronie Instalowanie jednostki certyfikującej
Logowanie za pomocą kart elektronicznych (smart card) Logowanie się za pomocą kart elektronicznych (smart cards) jest kontrolowane dzięki zasadom związanym z obiektem użytkownika w sposób podobny do tego, który jest stosowany przy logowaniu z użyciem hasła (password logon). Zasady (policy) można ustalić w ten sposób, aby możliwy był wybór sposobu logowania (karta elektroniczna czy hasło) lub można narzucić logowanie tylko za pomocą kart elektronicznych (smart card). W drugim przypadku ochrona przed dostępem do danego konta osób nieuprawnionych jest znacznie lepsza, chociaż oznacza to, że użytkownicy nie mogą się zalogować, jeśli zapomną swoich kart lub będą chcieli używać komputera bez czytnika kart elektronicznych (smart card reader).
Ustawianie zabezpieczeń sieci Web Sieć Web szybko staje się kluczowym elementem przy tworzeniu i wdrażaniu rozwiązań dla efektywnej wymiany informacji na skalę światową, szczególnie dla przedsiębiorstw. W związku z tym pojawiają się następujące zagadnienia związane z bezpieczeństwem: •
uwierzytelnianie serwera — klientom potrzebne jest sprawdzenie czy serwer, z którym się komunikują, jest tym, za co się podaje,
•
uwierzytelnianie klienta — serwerom konieczne jest sprawdzenie tożsamości klienta, co stanowi podstawę do podejmowania decyzji dotyczących kontroli dostępu,
•
poufność (confidentiality) — szyfrowanie danych przesyłanych pomiędzy klientem a serwerem zapobiega przechwytywaniu ważnych danych przesyłanych poprzez publiczne połączenia internetowe.
Protokoły Secure Sockets Layer (SSL) i Transport Layer Security (TLS) odgrywają ważna rolę w zaspokajaniu wymienionych wyżej potrzeb. Protokoły SSL i TLS są elastycznymi protokołami zabezpieczeń (security protocols), które można umieścić w najwyższej warstwie innych protokołów transportowych (transport protocols). Są one oparte na technologii uwierzytelniania za pomocą klucza publicznego (PK-based authentication) i w celu generowania klucza szyfrowania (encryption key), niepowtarzalnego dla każdej sesji klienta-serwera, gdy stosują negocjowanie klucza (key negotiations) w oparciu o klucze publiczne (PK-based key negotiation). Protokoły SSL i TLS są zwykle związane z aplikacjami korzystającymi z sieci Web (Web-based applications) i protokołem HTTP (określanym jako HTTPS). Witrynę sieci Web, korzystającą z protokołu SSL, konfiguruje się w następujący sposób: 1.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Menedżer Usług Internetowych (Internet Services Manager).
2.
Prawym przyciskiem myszki kliknij nazwę serwera IIS i dodaj nową witrynę, jeśli nie ma innej witryny, dla której chcesz uaktywnić protokół SSL.
3.
Postępuj zgodnie z informacjami wyświetlanymi przez Kreator Tworzenia Sieci Web (Web Creation Wizard). Pamiętaj, że konieczne jest podanie początkowej części nazwy hosta (Host Header).
4.
Prawym przyciskiem myszki kliknij nową witrynę i z menu wybierz pozycję Właściwości (Properties).
5.
W części Komunikacja Bezpieczna (Secure Communications) zakładki Zabezpieczenia Katalogu (Directory Security) naciśnij przycisk Edytuj (Edit). Jeśli przycisk ten jest wygaszony (szary), włącz pozycję Certyfikat Serwera (Server Certificate) i postępuj zgodnie z wyświetlanymi informacjami.
6.
Wybierz opcję Wymagaj Kanału Bezpiecznego (Require Secure Channel (SSL)) i podaj ustawienia dotyczące szyfrowania oraz certyfikatów klientów. Naciśnij dwukrotnie przycisk OK., uruchom witrynę (site) i zamknij moduł dodatkowy (snap-in) konsoli MMC.
7.
Przejdź do witryny, korzystając z protokołu https zamiast http.
OSTRZEŻENIE! Nie należy włączać szyfrowania SSL dla witryny jeśli nie ma wystarczających powodów, aby to zrobić. Szyfrowanie za pomocą protokołu SSL znacznie spowalnia działanie witryny i bardzo obciąża procesor. Witryny internetowe, w których zastosowano ten protokół, służą do zapewnienia bezpieczeństwa operacjom, takim jak przesyłanie nazwy użytkownika i numeru jego karty kredytowej przez Internet.
Usługodawca SSPI SChannel (kanał bezpieczny) obsługuje protokoły SSL i TLS na platformie Windows. Zarówno Internet Explorer, jak i Internet Information Services korzystają z funkcji usługodawcy SChannel. Ponieważ SChannel jest zintegrowany z architekturą interfejsu SSPI Microsoftu, może być używany przez wiele protokołów do obsługi komunikacji uwierzytelnionej lub (i) zaszyfrowanej. Aby skorzystać w pełni z protokołów SSL i TLS, konieczne jest posiadanie przez klientów i serwery certyfikatów wydanych przez obustronnie zaufane jednostki certyfikujące (mutually trusted CAs), umożliwiając stronom wzajemne uwierzytelnienie. W tym trybie sposób postępowania jest następujący: 1.
Certyfikaty są wymieniane razem z danymi potwierdzającymi posiadanie odpowiadających im kluczy prywatnych (private key).
2.
Każda ze stron zatwierdza certyfikat i posiadanie klucza prywatnego za pomocą klucza publicznego certyfikatu.
3.
Dane identyfikacyjne zawarte w certyfikacie są stosowane do podjęcia dodatkowych decyzji dotyczących kontroli dostępu, np. klient może zadecydować, czy chce mieć do czynienia z danym serwerem, a serwer może zadecydować, do jakich danych klient może mieć dostęp.
Dzięki Infrastrukturze Klucza Publicznego (PKI) systemu Windows 2000 podejmowanie decyzji o uzyskaniu dostępu przez klienta jest standardową funkcją systemu Windows 2000 Serwer. Certyfikaty użytkowników mogą być przydzielane obiektom typu security principal (obiektom użytkowników) w Active Directory w trybie jeden-do-jednego (one-to-one basis) lub jeden-dowielu (one-to-many basis). SChannel korzysta z tych informacji do automatycznego utworzenia znacznika zabezpieczeń (security token) dla klienta, więc do narzucenia kontroli dostępu do zasobów służą mechanizmy ACL (Access Control List). Tak więc usługi mogą korzystać z tego samego mechanizmu kontroli dostępu w przypadku uwierzytelniania klienta za pomocą klucza publicznego i protokołu Kerberos. Po wzajemnym uwierzytelnieniu klienta i serwera można negocjować klucz sesji i zacząć komunikować się w sposób bezpieczny. Protokoły SSL i TLS pracują równie często w trybie, który nie wymaga uwierzytelniania klienta. Jednak w przedsiębiorstwach jest zalecane wzajemne uwierzytelnianie, ponieważ umożliwia korzystanie z systemowych mechanizmów kontroli
dostępu. Infrastruktura Klucza Publicznego (PKI) upraszcza również rejestrowanie (enrollment) certyfikatów i zarządzanie nimi.
Zastosowanie uwierzytelniania za pomocą klucza publicznego (PK-based authentication) w programie Internet Explorer Najbardziej rozpowszechnionym stosowaniem bezpiecznego protokołu HTTP jest umożliwienie szyfrowanych połączeń z uwierzytelnionym serwerem sieci Web (Web server). Kiedy klient chce ustanowić połączenie za pomocą bezpiecznego protokołu HTTP, uaktywniającego się zazwyczaj po podaniu adresu URL rozpoczynającego się od https://, klient i serwer wspólnie negocjują, który protokół zabezpieczeń ma być użyty, a następnie wymieniają dane uwierzytelniające. Internet Explorer obsługuje uniwersalne zabezpieczenia protokołu HTTP, takie jak: Transport Layer Security (TLS 1), Secure Sockets Layer (SSL 2 i 3), Private Communications Technology (PCT 1). Każdy z tych protokołów zapewnia usługi szyfrowania (encryption services), aby uzyskać poufność wymiany danych oraz usługi uwierzytelniania przeznaczone do wzajemnej identyfikacji klienta i serwera. Instalowanie uwierzytelniania klienta przebiega w następujący sposób: 1.
Uzyskaj certyfikat uwierzytelniania klienta. Usługi certyfikacji opisano szczegółowo w rozdziale 7., ale uzyskanie certyfikatu, czyli Identyfikatora Cyfrowego (Digital ID) jest dość proste. Można skorzystać z Serwera Certyfikatów (Certificate Server) Microsoftu lub dostawcy komercyjnego, np. VeriSign. Można będzie wybrać poziom zabezpieczeń (level of security). Na rysunku 6.3 przedstawiono witrynę internetową firmy VeriSign (www.verisign.com) z opisem wyjaśniającym wybór poziomu zabezpieczeń. O ile nie ma szczególnych wymagań, wybiera się zazwyczaj domyślny poziom Średni Poziom Zabezpieczeń (Medium Security).
2.
Zajrzyj pod adres URL, gdzie korzysta się z uwierzytelniania klienta.
3.
Po pojawieniu się monitu w oknie dialogowym Uwierzytelnianie Klienta (Client Authentication), jak przedstawiono na rysunku 6.4, wybierz certyfikat, który ma być stosowany (taki jak ten, który właśnie otrzymałeś) i naciśnij przycisk OK. Możesz zobaczyć zawartość certyfikatu, wybierając go, a następnie naciskając Wyświetl Certyfikat (View Certificate).
Uwaga: Jeśli do uwierzytelniania klienta używa się kart elektronicznych (smart cards) pojawi się okno dialogowe z monitem o włożenie karty (o ile karta nie jest już w czytniku). Włóż kartę i
naciśnij przycisk OK. Następnie pojawi się monit o kod PIN. Wprowadź go i naciśnij przycisk OK.
4.
Wyświetlona zostanie strona zabezpieczona (secure page).
Rysunek 6.3. Opis wyboru poziomu zabezpieczeń zamieszczony w witrynie internetowej firmy VeriSign
Rysunek 6.4. Okno dialogowe Uwierzytelnianie Klienta (Client Authentication)
Konfigurowanie programu Outlook, aby korzystał z protokołu Secure Sockets Layer Zabezpieczenia z kluczem publicznym w programie Outlook omówiono w dalszej części niniejszego rozdziału, ale przy omawianiu zabezpieczeń internetowych w tym podrozdziale opisano sposób konfigurowania programu Outlook tak, aby program Internet Mail mógł korzystać z uwierzytelniania za pomocą hasła (password authentication) i protokołu SSL. 1.
Uruchom program Outlook.
2.
Wybierz opcję Narzędzia\Usługi (Tools\Services) i wybierz pozycję Internet E-mail (rysunek 6.5).
3.
Naciśnij przycisk Właściwości (Properties), a następnie wybierz zakładkę Usługi (Services).
4.
Zaznacz pole opcji Logowanie z bezpiecznym uwierzytelnieniem hasła (Logon using secure password authentication), jak przedstawiono to na rysunku 6.6. Naciśnij przycisk Zastosuj (Apply).
Rysunek 6.5. Okno dialogowe Usługi (Services) programu Outlook
5.
Wybierz zakładkę Zaawansowane (Advanced).
6.
Dla obu serwerów SMTP i POP3 zaznacz opcję Ten serwer wymaga bezpiecznego połączenia (SSL) (This server requires a secure connection (SSL)), jak przedstawiono to na rysunku 6.7. Zwróć uwagę, że numery portów serwerów zmienią się automatycznie na numery protokołu SSL: 999 i 995.
7.
Naciśnij OK. Aby zamknąć okno dialogowe MSmail Właściwości (MSmail Properties), naciśnij ponownie przycisk OK.
Rysunek 6.6. Wybór opcji Logowanie z Bezpiecznym Uwierzytelnieniem Hasła (Logon Using Secure Password Authentication)
Rysunek 6.7. Wybór opcji połączeń z zastosowaniem protokołu Secure Socket Layer
Konfigurowanie zabezpieczeń poczty elektronicznej z zastosowaniem klucza publicznego (PK-based secure email) Programy do obsługi poczty elektronicznej korzystające z zabezpieczeń za pomocą kluczy publicznych (PK-based), takie jak Microsoft Exchange, są szeroko stosowane od lat. Systemy te korzystają z technologii klucza publicznego (PKT) zarówno przy podpisach cyfrowych — aby dowieść pochodzenia i autentyczności wiadomości e-mail — oraz do szyfrowania danych masowych (bulk encryption) bez wcześniej ustalonych kluczy tajnych (shared secrets), aby zapewnić poufność korespondencji.
Technologia klucza publicznego (PKT) jest przede wszystkim odpowiednia do zabezpieczania poczty elektronicznej dzięki temu, że jest to usługa rozproszona i korzysta ze sposobu przesyłania zapisz-i-przekaż dalej (store-and-forward transport) do wielu odbiorców. Rozwiązania alternatywne, oparte na kryptografii z kluczem tajnym (SKC), narzucają wymagania dotyczące zabezpieczeń fizycznych i administracyjnych, co utrudnia ich stosowanie. Ograniczeniem wcześniejszych wersji był brak możliwości współdziałania w przypadku różnych dostawców, ponieważ stosowano firmowe protokoły, kodowanie wiadomości oraz założenia dotyczące relacji zaufania. Ostatnio wraz z pojawieniem się standardu IETF S/MIME 3 (opracowanego na podstawie projektu S/MIME 2 firmy RSA Data Security) zaistniały podstawy do stworzenia współdziałających bezpiecznych programów do obsługi poczty elektronicznej. Standard S/MIME zaimplementowano w wielu programach, włącznie z klientem komunikacji i współpracy (messaging and collaboration client) programu Outlook oraz programem Outlook Express. Wymienione powyżej programy używają kluczy prywatnych użytkowników do podpisywania cyfrowego wychodzących wiadomości e-mail. Następnie razem z wiadomością e-mail wysyłany jest certyfikat użytkownika po to, aby odbiorca mógł zweryfikować podpis. Standard S/MIME określa parametry certyfikatu gwarantujące współdziałanie i zakłada model hierarchiczny jednostek certyfikujących (CAs), w celu umożliwienia skalowalnego zarządzania relacjami zaufania (scalable trust management). Aby zaszyfrować wiadomość e-mail, użytkownik uzyskuje certyfikat szyfrowania (encryption certificate) adresata z wcześniejszej wiadomości e-mail lub od usług katalogowych. Po zweryfikowaniu certyfikatu użytkownik może użyć zawartego w nim klucza publicznego do szyfrowania klucza tajnego, który z kolei jest stosowany do szyfrowania wiadomości e-mail.
Zawartość z podpisem cyfrowym Ciągła ekspansja Internetu powoduje częstsze korzystanie z elementów aktywnych (active content) pobranych z Internetu, takich jak aplikacje systemu Windows, elementy sterujące ActiveX (ActiveX controls) i aplety Javy. Wynikiem tego jest rosnąca troska o bezpieczeństwo pobierania z Internetu, które często stanowi efekt uboczny skryptów sieci Web (Web scripts) bez specjalnego powiadamiania użytkownika. W odpowiedzi na to Microsoft wprowadził technologię podpisu cyfrowego, Authenticode. Technologia podpisu cyfrowego — Authenticode umożliwia wydawcom oprogramowania (software publishers) podpisywanie podpisem cyfrowym elementów aktywnych (active content) w dowolnej postaci, włączając w to archiwa zawierające wiele plików (multiple-file archive). Podpisy te służą do weryfikacji wydawcy danego elementu aktywnego (content) i spójności tego elementu w czasie pobierania. Zintegrowane usługi i narzędzia do weryfikacji (verification infrastructure) korzystają z hierarchicznej struktury jednostek certyfikujących (CAs), w której kilka jednostek wydaje certyfikaty publikowania oprogramowania (software publishing certificates). Infrastruktura Klucza Publicznego (PKI) w systemie Windows 2000 umożliwia wydawanie certyfikatów modułu Authenticode (Authenticode certificates) wewnętrznym deweloperom (developers) lub wykonawcom (contractors) oraz umożliwia dowolnemu użytkownikowi weryfikację pochodzenia i integralności pobranej aplikacji.
Konfigurowanie zabezpieczeń z zastosowaniem klucza publicznego (PK Security) dla programu Outlook Express Przyjmijmy, że zainstalowano program Outlook Express do wysyłania i odbierania wiadomości przez dany serwer poczty elektronicznej (mail server). Poniżej opisano sposób ustawienia parametrów tego programu, aby generował on wiadomości zgodnie ze standardem S/MIME Secure Mail: 1.
Zaznacz pozycję Narzędzia\Konta (Tools\Accounts), a następnie wybierz zakładkę Poczta elektroniczna (Mail). Wybierz swoje konto pocztowe i naciśnij przycisk Właściwości (Properties).
2.
Wybierz zakładkę Zabezpieczenia (Security), aby zobaczyć właściwości swojego konta pocztowego związane z bezpieczeństwem.
3.
Zaznacz opcję Używaj cyfrowego ID przy wysyłaniu bezpiecznych wiadomości z: (Use a digital ID when sending secure messages from:), jak przedstawiono to na rysunku 6.8.
Rysunek 6.8. Zakładka Właściwości (Properties) konta poczty elektronicznej w programie Outlook Express 4.
Aby wybrać certyfikat, naciśnij przycisk Identyfikator Cyfrowy (Digital ID). Program Outlook Express rozpoznaje tylko te certyfikaty, które zawierają w polu Subject twój adres e-mailowy na użytek technologii S/MIME. Takie certyfikaty są wyświetlone w oknie dialogowym Wybierz identyfikator cyfrowy domyślnego konta (Delect default account digital ID), jak przedstawiono to na rysunku 6.9.
5.
Aby zamknąć okno dialogowe Wybierz identyfikator cyfrowy domyślnego konta (Select default account digital ID), naciśnij przycisk OK.
6.
Aby zamknąć okno dialogowe Właściwości twojego konta pocztowego, naciśnij przycisk OK.
7.
Aby zamknąć okno dialogowe Konta Internetowe (Internet Accounts), naciśnij przycisk Zamknij (Close).
8.
Wybierz pozycję Narzędzia\Opcje (Tools\Options), a następnie wybierz zakładkę Bezpieczeństwo (Security). Pojawi się okno dialogowe Opcje (Options), które przedstawiono na rysunku 6.10.
Rysunek 6.9. Okno dialogowe Wybierz identyfikator cyfrowy domyślnego konta (Select default account digital ID)
Rysunek 6.10. Okno dialogowe Opcje (Options) 9.
Jeśli chcesz, można dodać podpis cyfrowy do wszystkich wiadomości e-mail, które wysyłasz. W tym celu należy zaznaczyć opcję Dodaj podpis cyfrowy do wszystkich wysyłanych wiadomości (Digitally sign all outgoing messages). Częściej spotykane jest dodawanie podpisów cyfrowych do wybranych wiadomości.
10. Podobnie można zaznaczyć opcję Szyfruj zawartość i załączniki wszystkich wysyłanych wiadomości (Encrypt contents and attachments for all outgoing messages), aby wszystkie wysyłane wiadomości zostały zaszyfrowane. Zwykle stosuje się szyfrowanie wybranych wiadomości. 11. Naciśnij przycisk Zaawansowane. Pojawi się okno dialogowe Zaawansowane Ustawienia Zabezpieczeń (Advanced Security Settings), które przedstawiono na rysunku 6.11. 12. Sprawdź, czy w części okna o nazwie Wiadomości Zaszyfrowane (Encrypted Messages) zaznaczono pole wyboru Przy wysyłaniu zaszyfrowanej wiadomości zawsze szyfruj do mnie (Always encrypt to myself when sending encrypted mail). Wybranie tej opcji gwarantuje, że będziesz w stanie odszyfrować wysłane przez siebie zaszyfrowane wiadomości. 13. Z listy rozwijalnej Ostrzegaj przy szyfrowaniu wiadomości kluczem o sile mniejszej niż: (Warn on encrypting messages with less than this strength:) wybierz odpowiednią opcję: 40- lub 56 bitów.
14. Z listy rozwijalnej Poziom szyfrowania wiadomości przychodzących (Encryption level you wish to receive) wybierz odpowiednią opcję: Algorytm DES (56-bitowy) lub algorytm RC2 (40-bitowy). 15. Sprawdź, czy w części okna dialogowego o nazwie Wiadomości Podpisane Cyfrowo (Digitally Signed Messages) wybrane są następujące opcje: •
Dołącz mój identyfikator cyfrowy przy wysyłaniu podpisanych wiadomości (Include my digital ID when sending signed messages),
•
Dodaj certyfikaty nadawców do mojej książki adresowej (Add senders’ certificates to my address book).
Rysunek 6.11. Okno dialogowe Zaawansowane Ustawienia Zabezpieczeń (Advanced Security Settings) 16. Jeśli chcesz włączyć sprawdzanie odwołań certyfikatów (certificate revocation checking) w trakcie pracy w trybie online, upewnij się, czy w części okna pod nazwą Sprawdzanie Odwołań (Revocation Checking) zaznaczone jest jedynie pole opcji Tylko w trybie online (Only when online); opcja ta jest wybrana domyślnie. Odwołanie (Revocation) jest to proces unieważniania oświadczenia z dołączonym podpisem cyfrowym (digitally signed statement), które zwarte jest w certyfikacie cyfrowym (digital certificate). Jeśli włączone jest sprawdzanie odwołań (revocation checking) i zostanie odebrana wiadomość z dołączonym podpisem cyfrowym (digitally signed message), wówczas program Outlook
Express próbuje sprawdzić, czy żaden z certyfikatów zatwierdzających klucz publiczny stosowany do podpisywania wiadomości nie został odwołany. 17. Aby zamknąć okno dialogowe Zaawansowane Ustawienia Zabezpieczeń, naciśnij przycisk OK. 18. Aby zamknąć okno dialogowe Właściwości, naciśnij przycisk OK.
Wysyłanie wiadomości e-mail z dołączonym podpisem cyfrowym Po uzyskaniu podpisu cyfrowego i odpowiednim skonfigurowaniu programu Outlook wysyłanie wiadomości z dołączonym podpisem cyfrowym jest proste. Przed wysłaniem wiadomości należy kliknąć ikonę Opatrz wiadomość podpisem cyfrowym (Digitally sign message), jak przedstawiono to na rysunku 6.12. W przypadku stosowania kart elektronicznych (smart card), jeśli w czytniku nie ma żądanej karty, pojawi się okno dialogowe Wybierz Kartę (Select Card). Wybierz czytnik, do którego włożono kartę i naciśnij przycisk OK. Wprowadź kod PIN i znów naciśnij OK. Jeśli dana wiadomość nie zniknie ze skrzynki nadawczej (Outbox), naciśnij znajdującą się na pasku zadań ikonę Wyślij i Odbierz (Send and Receive), aby ręcznie przesłać wiadomość do serwera poczty wychodzącej.
Rysunek 6.12. Dołączanie podpisu cyfrowego do wiadomości e-mail
Wysyłanie wiadomości e-mail zaszyfrowanych cyfrowo Aby przesłać komuś wiadomość zaszyfrowaną, najpierw konieczne jest uzyskanie kopii klucza publicznego adresata lub jego certyfikatu szyfrowania, który zawiera kopię tego klucza. Jeśli osoba, do której ma być wysłana wiadomość, przysłała ją z dołączonym podpisem cyfrowym, to kopię jej klucza publicznego można otrzymać w sposób opisany poniżej. Jeśli już wcześniej uzyskano certyfikat klucza publicznego odbiorcy i odbiorca ten znajduje się na liście Kontakty (Contacts), wtedy można pominąć pierwsze dwie czynności poniższej procedury. 1.
Otwórz wiadomość z dołączonym podpisem cyfrowym od osoby, której chcesz przesłać wiadomość. Wiadomości z podpisem cyfrowym znajdujące się w skrzynce odbiorczej (Inbox) są oznaczone za pomocą znaku koperty z czerwoną wstążką.
2.
W polu Od (From) prawym przyciskiem myszki kliknij nazwę nadawcy i z menu wybierz pozycję Dodaj do książki adresowej (Add to address book). Następnie, aby dodać danego użytkownika i jego certyfikat klucza publicznego (public key certificate) do listy Kontakty programu Outlook Express, naciśnij przycisk OK.
3.
Ułóż nową wiadomość.
4.
Naciśnij ikonę Szyfruj Wiadomość (Encrypt Message), jak przedstawiono na rysunku 6.13. Jeśli chcesz również do danej wiadomości dołączyć podpis cyfrowy, oprócz ikony Szyfruj wiadomość, kliknij opcję Opatrz wiadomość podpisem cyfrowym (Digitally sign message).
5.
Włącz pozycję Wyślij (Send).
W przypadku stosowania kart elektronicznych (smart card), jeśli w czytniku nie ma żądanej karty pojawi się okno dialogowe Wybierz kartę. Wybierz czytnik, do którego włożono kartę i naciśnij przycisk OK. Wprowadź kod PIN i znów naciśnij OK.
Rysunek 6.13. Szyfrowanie wiadomości
Uzyskiwanie klucza publicznego odbiorcy od komercyjnej jednostki certyfikującej (CA) Jeśli osoba, do której ma być wysłana zaszyfrowana wiadomość, otrzymała swój identyfikator cyfrowy (digital ID) od komercyjnej jednostki certyfikującej (CA) przez Internet, można uzyskać jej klucz publiczny z witryny internetowej danej jednostki certyfikującej. Przyjmijmy, że potencjalny odbiorca wiadomości uzyskał swój identyfikator cyfrowy od firmy VeriSign. Można w publicznej książce adresowej VeriSign poszukać jego identyfikatora cyfrowego, pobrać identyfikator (ID) i zaimportować go do własnej książki adresowej. Aby uzyskać identyfikator cyfrowy (Digital ID) jakiejś osoby z publicznej książki adresowej VeriSign, należy: 1.
Zajrzeć na stronę https://digitalid.verisign.com./query.htm i postępując zgodnie z instrukcjami zlokalizować, zaznaczyć i pobrać identyfikator cyfrowy (digital ID).
2.
Będąc poproszonym o wybranie formatu pobierania, wybrać opcję Identyfikator cyfrowy innej osoby dla programu Microsoft IE (4.0 lub lepszy) (Someone else’s digital ID for IE) /Outlook Express/Outlook ’98.
3.
Nacisnąć przycisk Pobierz (Download) i zapisać certyfikat do pliku.
Konfigurowanie zabezpieczeń z zastosowaniem klucza publicznego (PK Security) dla programu Outlook Tak, jak poprzednio w przypadku programu Outlook Express, także w niniejszym podrozdziale przyjęto, że program Outlook jest odpowiednio skonfigurowany, a nadawca uzyskał identyfikator cyfrowy (digital ID) z serwera zarządzania kluczami (Key Management Server) — dla Microsoft Exchange), z serwera certyfikatów (certificate server) firmy Microsoft lub komercyjnej jednostki certyfikującej (commercial CA). 1.
Uruchom program Outlook.
2.
Wybierz pozycje Narzędzia\Opcje (Tools\Options), a następnie wybierz zakładkę Bezpieczeństwo (Security). Powinien pojawić się ekran podobny do tego z rysunku 6.14.
3.
Naciśnij przycisk Zmień Ustawienia (Change Settings) znajdujący się w części pod tytułem Zabezpieczenia poczty e-mail (Secure e-mail). Pojawi się okno dialogowe Zmiana Ustawień Zabezpieczeń (Change Security Settings), przedstawione na rysunku 6.15.
4.
W polu Nazwa Ustawień Zabezpieczeń (Security Settings Name) wprowadź Moje ustawienia standardu S/MIME (My S/MIME settings).
5.
Program Outlook 98 sprawdzi certyfikaty, które posiadasz, określi, które z nich obowiązują dla szyfrowaniu wiadomości e-mail i podpisów cyfrowych i kolejno wybierze dla nich po certyfikaty. Jeśli certyfikaty wybrane przez program Outlook nie są tymi, które chciałeś, możesz zmienić ustawienia domyślne w następujący sposób: •
aby wybrać certyfikat, który będzie używany przy dołączaniu podpisów cyfrowych do wiadomości e-mail, naciśnij przycisk Wybierz (Choose) znajdujący się w części okna dialogowego pod nazwą Podpis Cyfrowy (Digital Signature),
•
aby wybrać certyfikat, który będzie używany przy szyfrowaniu wiadomości email, naciśnij przycisk Wybierz (Choose) znajdujący się w części okna dialogowego pod nazwą Szyfrowanie (Encryption).
Rysunek 6.14. Okno dialogowe Opcje (Options), zakładka Bezpieczeństwo (Security)
Rysunek 6.15. Okno dialogowe Zmiana Ustawień Zabezpieczeń (Change Security Settings) 6.
Aby zamknąć okno dialogowe Zmiana Ustawień Zabezpieczeń i powrócić do okna dialogowego Opcje, naciśnij przycisk OK.
7.
Tak samo, jak w przypadku programu Outlook Express, możesz wybrać dołączanie podpisów cyfrowych do każdej wiadomości e-mail, zaznaczając opcję Dodaj podpis cyfrowy do wysyłanych wiadomości (Add digital signature to outgoing messages). Zazwyczaj dołącza się podpisy cyfrowe do wybranych wiadomości.
8.
Podobnie można szyfrować wszystkie wiadomości e-mail, zaznaczając opcję Szyfruj treść i załączniki wysyłanych wiadomości (Encrypt contents and attachments for all outgoing messages). Zwykle szyfruje się pojedyncze, wybrane wiadomości.
9.
Aby zamknąć okno dialogowe Opcje, naciśnij przycisk OK.
10. Kliknij pozycję Narzędzia\Usługi, a następnie wybierz zakładkę Adresowanie (Addressing). 11. W części Pokaż najpierw tę listę adresów (Show this address list first) z listy rozwijalnej wybierz pozycję Kontakty (Contacts).
12. W części W wysyłanej poczcie (When sending mail) przenieś pozycję Kontakty (Contacts), aby była pierwsza w kolejności przeszukiwania, a pozycję Globalna Lista Adresów (Global Address List) jako ostatnią. 13. Naciśnij przycisk OK.
Dodawanie opcji dołączania podpisów cyfrowych i szyfrowania do paska zadań Zanim wiadomości e-mail będą opatrywane podpisami cyfrowymi i szyfrowane, do paska zadań można dodać ikony dołączania podpisów cyfrowych i szyfrowania w sposób następujący: 1.
Otwórz okno nowej wiadomości.
2.
W oknie wiadomości wybierz opcję Widok\Paski narzędzi\Dostosuj (View\Toolbars\Customize).
3.
Wybierz zakładkę Polecenia (Commands) i w polu Kategorie (Categories) zaznacz pozycję Standardowe (Standard).
4.
Przewiń listę Polecenia (Commands) i, korzystając z mechanizmu przenieś-i-upuść (drag and drop), umieść na pasku zadań ikony Szyfruj Tekst Wiadomości (Encrypt Message Contents) oraz Opatrz Wiadomość Podpisem Cyfrowym (Digitally Sign Message) w dowolnym miejscu po lewej stronie ikony asystenta pakietu Office.
5.
Naciśnij przycisk Zamknij (Close).
Opatrywanie podpisem cyfrowym i szyfrowanie pojedynczych wiadomości Po dodaniu do paska zadań odpowiednich elementów sterujących opatrywanie podpisami cyfrowymi oraz szyfrowanie wiadomości polega po prostu na kliknięciu odpowiedniej ikony w oknie Zredaguj Wiadomość (Compose Message). Tak, jak poprzednio do zaszyfrowania wiadomości konieczna jest znajomość klucza publicznego odbiorcy, który można uzyskać w powyżej opisany sposób. Jeśli ikony nie zostały dodane do paska zadań, można dołączać podpisy cyfrowe i szyfrować wiadomości, klikając ikonę Opcje (Options) i zaznaczając odpowiednie. Chociaż jest to sposób mniej wygodny, jednak ogranicza ryzyko przypadkowego zaszyfrowania wiadomości; wiadomości zaszyfrowane są wolniejsze i zajmują większą część zasobów procesora. Możliwe jest również wybranie innych opcji, takich jak żądanie potwierdzenia dostarczenia wiadomości oraz planowanie wysyłania.
Uzyskiwanie współdziałania (achieving interoperability) Byłoby najlepiej, gdyby jednostki certyfikujące (CAs) wydawały, na podstawie standardowego protokołu żądania certyfikatów (certificate-request protocol), zestaw certyfikatów w pełni współpracujących ze sobą (completely interoperable certificates). Byłyby one oceniane przez aplikacje w jednakowy sposób i na żadnym etapie przetwarzania certyfikatu nie pojawiałyby się dwuznaczności dotyczące składni czy semantyki. Do tej pory nie osiągnięto takiego poziomu współdziałania (interoperability). Protokoły SSL/TLS i S/MIME umożliwiają poprawną współpracę programów od wielu dostawców, ale nowsze aplikacje, takie jak podpisywanie kodu (code signing) i formularze podpisane cyfrowo (digitally signed forms) nie są jeszcze niezawodne. Obecnie nie ma także metody porównania nazw w przypadku dwóch różnych sposobów kodowania języka (language encodings), np. w standardzie Unicode, co powoduje, że znaki akcentowane (accented characters) zakodowane są w wielu równoważnych postaciach. Firma Microsoft uczestniczy w pracach nad rozwijaniem standardów związanych z technologią klucza publicznego i, aby zwiększyć możliwości współdziałania (interoperability), zobowiązała się do tworzenia programów na podstawie aktualnych akceptowanych standardów. Do zakresu obowiązków specjalistów od bezpieczeństwa sieci należy nie tylko znajomość aktualnie rozwijanych standardów, ale również wypowiadanie swojego zdania na ich temat. Jeśli pozwolimy na pojawienie się wadliwego standardu, to będziemy mieli poważne problemy z usuwaniem błędów.
Stosowanie standardów internetowych Standardy internetowe są pomocne, ale nie gwarantują pełnego współdziałania (interoperability). W przeszłości wdrażanie programów komercyjnych zawsze wyprzedzało proces współpracy, szczególnie w dziedzinie klucza technologii publicznego (PKT). Wiele aplikacji, które są potencjalnymi beneficjantami takich standardów, zostało wypuszczonych na rynek. Ponadto żaden standard nie jest w stanie przewidzieć wszystkich wymagań i zależności aplikacji — nawet najbardziej wszechstronny standard musi być dostosowany do wymogów rzeczywistych. Grupą roboczą IETF, której zadaniem jest zdefiniowanie podstaw infrastruktury klucza publicznego, która ma możliwość współdziałania (interoperable PKI) jest PKIX (X.509). Firma Microsoft jest bardzo zaangażowana w opracowywanie tego standardu w ramach grupy roboczej IETF i zobowiązała się do zagwarantowania zgodności swoich programów, korzystających z Infrastruktury Klucza Publicznego (PKI), do zgodności z tymi standardami. Po ratyfikowaniu
standard ten stanie się istotnym czynnikiem podczas definiowania niezawodnej Infrastruktury Klucza Publicznego (PKI), która zagwarantuje, że żądania certyfikatów, ich interpretowanie i odwoływanie będzie odbywało się w sposób znormalizowany. Sposób uzyskania odpowiedniego dokumentu IETF (RFC 2459 Internet Public Key Infrastructure X.509 Certificate and CRL Profile, Part 1) i komentarzy do niego opisano poniżej. 1.
Połącz się z serwerem ftp pod adresem ftp://ftp.isi.edu/in-notes/rfc2459.txt.
2.
Pobierz dokument. Ma on ponad 100 stron, ale zwiera obszerny indeks.
3.
Przeczytaj interesujący cię fragment.
4.
Skopiuj dowolny fragment, który chcesz skomentować i wstaw go albo bezpośrednio do wiadomości e-mail, albo do edytora tekstu. Dodaj własne uwagi.
5.
Wyślij dany fragment wraz z komentarzem na adres
[email protected], upewniając się wcześniej, czy w polu tematu podano RFC 2459.
Uwaga: Dokument RFC (Request For Comments) jest tym, co sugeruje jego nazwa (żądanie komentarza). Grupa robocza IETF naprawdę czeka na komentarze praktyków w danej dziedzinie. Twoje uwagi zostaną przyjęte z wdzięcznością, przeczytane uważnie i opracowane dokładnie.
Niektóre, inne działania w ramach grupy roboczej IETF mogą mieć znaczący wpływ na możliwości współdziałania Infrastruktury Klucza Publicznego (PKI interoperability). Związane są one z zapotrzebowaniem na aplikacje korzystające z klucza publicznego (PK-based applications), szczególnie TLS, S/MIME oraz IPSec. Każda z tych aplikacji wymaga, aby był zdefiniowany podzbiór PKIX, który zaspokoi ich potrzeby. Często te potrzeby wykraczają poza zakres funkcji standardu PKIX. Grupa robocza IETF S/MIME (www.ietf.org/ids.by.wg/smime.html) obecnie opracowuje standardy i specyfikacje na podstawie zapotrzebowania na aplikacje. Najważniejsze z nich to S/MIME — Składnia wiadomości kryptograficznych (cryptographic message syntax), S/MIME 3 — Specyfikacja komunikatów (message specification), S/MIME wersja 3 — Obsługa certyfikatów (certificate handling) oraz Składnia żądania certyfikatów (certificate request syntax). PKIX część 1, podstawowy standard IETF, korzysta obecnie z doświadczeń nabytych podczas prób zastosowania go, np. do sprawdzania łańcucha certyfikatów (certificate-chain verification). Dostęp do dyskusji grupy roboczej IETF oraz wpis na jej listę wysyłkową (mailing list) można uzyskać w następujący sposób: 1.
Połącz się ze stroną o adresie www.ietf.org/ids/by/wg/smime.html
2.
Przedstawione zostaną streszczenia różnych dokumentów przygotowane przez członków grupy roboczej. Aby wybrać i pobrać interesujący cię dokument, kliknij odpowiednie połączenie (link). Zamieszczono tam również połączenia do innych witryn sieci Web.
3.
Subskrybuj listę wysyłkową (mailing list) IETF, wysyłając wiadomość na adres
[email protected], zawierającą jedno słowo: subscribe.
National Institute of Standards and Technology (NIST) powołał grupę roboczą do spraw współdziałania (interoperability workgroup), w skład której wchodzą firmy: AT&T, CertCo, Certicom, Cylink, Digital Signature Trust, Dynacorp, Entrust, Frontier Technologies, GTE, ID Certify, MasterCard, Microsoft, Motorola, Spyrus, VeriSign oraz Visa. Celem tego przedsięwzięcia jest zapewnienie minimalnego współdziałania (interoperability) pomiędzy implementacjami standardu PKIX część 1, opracowanymi przez firmy członkowskie. NIST zakłada optymistycznie, że grupa ta usunie wszystkie niejednoznaczności lub (i) błędy nowego standardu PKIX. Witryna internetowa NIST znajduje się pod adresem www.nist.gov. Całkowicie poza IETF został opracowany — przez RSA Laboratories — zbiór faktycznych standardów kryptograficznych (PKCS), które są szeroko stosowane. Szczegóły można znaleźć pod adresem www.rsa.com/rsalabs/html/standards.htm. Standardy dotyczące Infrastruktury Klucza Publicznego (PKI) to między innymi PKCS #7, Standard składni wiadomości kryptograficznych (cryptographic message syntax standard) oraz PKCS #10 Standard składni żądania certyfikatu (certification request syntax standard). Standardy opracowane przez RSA ustanawiają podstawy ogólnej struktury współdziałania (interoperability). Określenie Infrastruktura Klucza Publicznego (PKI) oznacza, że te usługi i narzędzia mogą być łączone ze sobą, np. jeśli jeden z oddziałów przedsiębiorstwa wybierze dla swoich aplikacji model Infrastruktury Klucza Publicznego (PKI model) dostawcy A, a przedsiębiorstwo wybierze później system pocztowy od dostawcy B, to powinny się one częściowo pokrywać. Sprawy bardziej się komplikują kiedy firma A i firma B postanowią połączyć swoje Infrastruktury Klucza Publicznego (PKI) tworząc ekstranet. Jest to skomplikowane, ponieważ konieczne jest przyporządkowanie relacji zaufania poszczególnym jednostkom oraz kontrolowanie ich cały czas. Obecnie istnieją trzy konkurujące ze sobą modele relacji zaufania: •
hierarchiczny, z główną jednostką certyfikującą (rooted hierarchy), np. firm VeriSign, Microsoft i Netscape,
•
sieciowy model relacji zaufania, np. firmy Entrust,
•
internetowy, np. PGP.
Modele te różnią się sposobami ustanawiania i utrzymywania relacji zaufania (trust relationships) oraz tym, czy relacje te tworzone są bezpośrednio, czy też przez pośredników. Różne modele prawdopodobnie nie będą współdziałać (interoperate) bez przeszkód. W najlepszym razie Infrastruktury Klucza Publicznego (PKI) mogą być na tyle elastyczne, by umożliwiać użytkownikom łączenie różnych modeli relacji zaufania w sposób odpowiedni dla konkretnych zastosowań.
Rozdział 7
Usługi certyfikatów Rozwiązania natychmiastowe zobacz na stronie Instalowanie jednostki certyfikującej (CA) Zastosowanie stron internetowych usług certyfikatów Instalowanie certyfikatów jednostek certyfikujących (CA certificates) Żądanie certyfikatów zaawansowanych Rejestrowanie (enrolling) za pomocą pliku żądania w standardzie PKCS #10 Konfigurowanie relacji zaufania pomiędzy domeną a zewnętrzną jednostką certyfikującą (external CA) Instalowanie automatycznego żądania certyfikatów dla komputerów Uruchamianie i zatrzymywanie usług certyfikatów Wykonywanie kopii zapasowych i odtwarzanie usług certyfikatów (certificate services) Wyświetlanie dziennika (log) i bazy danych usług certyfikatów (certificate services) Odwoływanie (revoking) wydanych certyfikatów i publikowanie listy CRL Konfigurowanie zasad i modułów zakończenia (exit modules) dla usług certyfikatów (certificate services)
W skrócie Certyfikaty Jak zostało opisane w poprzednim rozdziale, certyfikaty stanowią mechanizm uzyskania zaufania w relacji pomiędzy kluczem publicznym (public key) a jednostką, która jest właścicielem odpowiadającego mu klucza prywatnego (private key). Certyfikat jest oświadczeniem opatrzonym podpisem cyfrowym, dotyczy klucza publicznego konkretnego podmiotu certyfikowanego (subject public key) i jest podpisany przez wydawcę (issuer), który posiada inną parę kluczy prywatnych i publicznych. Zazwyczaj certyfikaty zawierają również inne informacje związane z danym kluczem publicznym, takie jak dane o tożsamości jednostki, która ma dostęp do klucza prywatnego, odpowiadającego temu kluczowi . Tak więc przekazując certyfikat, jego wydawca poświadcza ważność powiązania pomiędzy kluczem publicznym podmiotu certyfikowanego (subject public key) a danymi o jego tożsamości.
Jednostki certyfikujące (Certifcate Authorities) Jednostka certyfikująca (Certifcate Authority — CA) jest to instytucja lub usługa wydająca certyfikaty, będąca poręczycielem powiązania pomiędzy danym kluczem publicznym a informacjami o tożsamości podmiotu certyfikowanego, zawartymi w tym certyfikacie. Różne jednostki certyfikujące (CAs) mogą weryfikować te powiązania na różnorodny sposób, dlatego ważne jest zrozumienie zasad i procedur danej jednostki, zanim zostanie ona obdarzona zaufaniem w zakresie potwierdzania kluczy publicznych (public keys). Usługi certyfikatów (certificate services) firmy Microsoft, które są częścią systemu Windows 2000 służą do ustanawiania jednostek certyfikujących dla danego przedsiębiorstwa. Zawierają one moduł zasad domyślnych (default policy module) służący do wydawania certyfikatów jednostkom w danym przedsiębiorstwie (użytkownikom, komputerom lub usługom). Obejmują identyfikację jednostki żądającej certyfikatu oraz sprawdzanie, czy żądanie certyfikatu jest dozwolone przez zasady zabezpieczeń z kluczem publicznym (public key security policy) danej domeny. Zasady te mogą być modyfikowane lub rozszerzone w ten sposób, aby uwzględniać inne zasady lub rozszerzyć zakres funkcji jednostki certyfikującej o obsługę różnych scenariuszy ekstranetowych lub internetowych. W ramach Infrastruktury Klucza Publicznego (Public Key Infrastructure — PKI) systemu Windows 2000 można korzystać zarówno z firmowych, jak i zewnętrznych jednostek
certyfikujących (CAs), związanych z innymi przedsiębiorstwami lub usługodawcami komercyjnymi. Umożliwia to dopasowanie się do wymagań danego przedsiębiorstwa.
Hierarchia certyfikatów Na potrzeby Infrastruktury Klucza Publicznego (PKI) przyjęto hierarchiczny model jednostek certyfikujących (hierarchical CA model), który został wybrany ze względu na możliwości rozbudowy (scalability), łatwość administrowania oraz zgodność z rosnącą liczbą komercyjnych i niezależnych (third-party) systemów jednostek certyfikujących. W najprostszej postaci hierarchia jednostek certyfikujących (CAs) składa się z pojedynczej jednostki. Zwykle jednak hierarchia zawiera wiele jednostek certyfikujących ze ściśle określonymi relacjami pomiędzy nimi, jak przedstawiono to na rysunku 7.1. Może istnieć wiele niezwiązanych ze sobą struktur hierarchicznych — jednostki certyfikujące nie muszą mieć wspólnej nadrzędnej jednostki certyfikującej (parent CA). W ramach tego modelu certyfikaty wydane przez nadrzędną jednostkę certyfikującą, wiążące klucz publiczny jednostki certyfikującej z jego tożsamością (identity) i innymi atrybutami, określonymi przez zasady (policy), dotyczą jednostek potomnych. Jednostka certyfikująca, która znajduje się najwyżej w hierarchii, określana jest jako główna jednostka certyfikująca (root CA). Podległe jej jednostki (subordinate CAs) noszą nazwę pośrednich jednostek certyfikujących (intermediate CAs) lub jednostek wydających certyfikaty (issuing CA).
Rysunek 7.1. Hierarchia jednostek certyfikujących Zaletą tego modelu jest to, że weryfikacja certyfikatów wymaga istnienia relacji zaufania ze stosunkowo niewielką liczbą głównych jednostek certyfikujących (root CAs). Również liczba jednostek wydających certyfikaty (issuing CAs) może być zmienna. Oto kilka powodów, dla których obsługuje się wiele jednostek wydających certyfikaty: •
użytkowanie (usage) — certyfikaty mogą być wydawane w różnych celach: do zabezpieczania poczty elektronicznej, uwierzytelniania w sieci, itd. Zasady wydawania certyfikatów w każdym z powyższych przypadków mogą być odmienne, a rozdzielenie ich umożliwia jednoczesne administrowanie nimi,
•
podziały organizacyjne (organizational divisions) — w zależności od roli, jaką spełnia jednostka w danej organizacji, mogą istnieć różne zasady wydawania certyfikatów. Wiele jednostek wydających certyfikaty pozwala na rozdzielenie i administrowanie tymi zasadami,
•
podziały geograficzne (geographic divisions) — organizacje mogą mieć swoje siedziby w różnych miejscach. Aby zachować wydajność systemu, w przypadku wolnych połączeń sieciowych pomiędzy siedzibami, konieczne jest zastosowanie wielu jednostek wydających certyfikaty (issuing CAs).
Hierarchia jednostek certyfikujących ma również kilka zalet administracyjnych: •
elastyczność (flexibility) — elastyczna konfiguracja środowiska zabezpieczeń jednostki certyfikującej (CA), np. siła klucza (key strength), ochrona fizyczna, ochrona przed atakami przez sieć, itd. pozwala zachować równowagę pomiędzy bezpieczeństwem (security) a przydatnością (usability). Dla przykładu: w głównej jednostce certyfikującej (root CA) można zastosować specjalny sprzęt kryptograficzny i obsługiwać go w obszarze zabezpieczonym fizycznie (physically secure area) lub w trybie offline. Taki sposób nie będzie stosowany w przypadku jednostek wydających certyfikaty (issuing CA) ze względu na koszty i małą przydatność takiego rozwiązania w tym przypadku,
•
częste aktualizacje — klucze lub (i) certyfikaty dla jednostek wydających certyfikaty mogą być często aktualizowane bez konieczności zmiany ustanowionych relacji zaufania (trust relationships), ale wówczas są najbardziej narażone na niebezpieczeństwo,
•
zamykanie (shut down) — można wyłączyć określoną część hierarchii jednostek certyfikujących bez wpływu na ustanowione relacje zaufania i np. zamknąć i odwołać (revoke) certyfikat jednostki wydającej certyfikaty (issuing CA) określonego oddziału przedsiębiorstwa, co pozostanie bez wpływu na inne oddziały.
Można dodawać lub usuwać jednostki wydające certyfikaty podlegające danej głównej jednostce certyfikującej (root CA). Można także łączyć istniejące struktury hierarchiczne jednostek certyfikujących poprzez wydanie certyfikatu dla głównej jednostki (root CA) innej hierarchii, jako pośredniczącej jednostki certyfikującej (intermediate CA). Jednak przedtem należy pomyśleć, jakie niezgodności zasad (policy) można w ten sposób wprowadzić.
Instalowanie jednostki certyfikującej w przedsiębiorstwie (enterprise CA) Instalowanie Usług Certyfikatów (Certificate Services) firmy Microsoft jest łatwe. Zalecane jest ustanowienie domeny przed utworzeniem jednostki certyfikującej i ustalenie jednej lub kilku jednostek certyfikujących przedsiębiorstwa (enterprise CA). Proces ten zostanie opisany szczegółowo w części „Rozwiązania natychmiastowe” niniejszego rozdziału. Jego najważniejsze etapy przedstawiono poniżej: •
wybór serwera głównego (host server) — główna jednostka certyfikująca (root CA) może zostać uruchomiona na dowolnym komputerze pracującym pod kontrolą systemu
Windows 2000, co dotyczy również kontrolera domeny (domain controller). Podejmując taką decyzję, powinny być brane pod uwagę takie czynniki, jak: fizyczne zabezpieczenia, szacowane obciążenie, wymagania dotyczące połączeń (connectivity), itp., •
nazewnictwo (naming) — nazwy jednostek certyfikujących są umieszczone ma stałe w ich certyfikatach i nie mogą być zmieniane. Należy wziąć pod uwagę konwencję nazewniczą przedsiębiorstwa i potrzeby, które mogą wystąpić w przyszłości,
•
generowanie klucza (key generation) — para kluczy publicznych jednostki certyfikującej (CA) jest generowana w trakcie procesu instalowania i jest niepowtarzalna dla danej jednostki certyfikującej,
•
certyfikat jednostki certyfikującej — w procesie instalowania do automatycznego generowania podpisanego przez nią samą (self signed CA certificate)certyfikatu jednostki certyfikującej, korzysta się z pary kluczy publiczny-prywatny danej jednostki (CA). Można wygenerować żądanie certyfikatu dla podrzędnej jednostki certyfikującej (child CA) i wysłać je do pośredniczącej jednostki certyfikującej (intermediate CA) lub głównej (root CA),
•
integrowanie z usługami Active Directory (Active Directory integration) — informacje dotyczące jednostki certyfikującej są zapisywane w jej obiekcie (CA object) w Active Directory podczas instalowania. W ten sposób klienci domeny (domain clients) uzyskują informacje o dostępnych jednostkach certyfikujących oraz o rodzajach certyfikatów wydawanych przez te jednostki,
•
zasady wydawania (issuing policy) — jednostka certyfikująca przedsiębiorstwa (enterprise CA) automatycznie instaluje i konfiguruje Moduł Zasad Przedsiębiorstwa (Enterprise Policy Module) firmy Microsoft dla danej jednostki certyfikującej (CA). Upoważniony administrator może modyfikować te zasady, ale w większości przypadków nie jest to konieczne.
Po ustanowieniu głównej jednostki certyfikującej (root CA) możliwe jest zainstalowanie podporządkowanych jej jednostek certyfikujących pośredniczących (intermediate CA) lub wydających certyfikaty (issuing CA). Jedyna znacząca różnica w zasadach instalowania jest taka, że żądania certyfikatu są generowane w celu przesłania do głównej jednostki certyfikującej (root CA) lub pośredniczącej (intermediate CA). Żądanie może być skierowane bądź automatycznie do jednostki certyfikującej, pracującej w trybie online, którą lokalizuje się za pomocą usług Active Directory, bądź też ręcznie w trybie offline. W obu przypadkach otrzymany w ten sposób certyfikat musi zostać zainstalowany w jednostce certyfikującej zanim zacznie ona działać. Pojedyncza jednostka certyfikująca może obsługiwać jednostki w wielu domenach, a nawet jednostki spoza granic danej domeny. Możliwa jest też odwrotna sytuacja — w domenie może znajdować się wiele jednostek certyfikujących przedsiębiorstwa (enterprise CA). Jeśli zostanie podjęta decyzja o korzystaniu z niezależnej jednostki certyfikującej (third party CA), takiej jak VeriSign (www.verisign.com), pojawi się monit o zarejestrowanie (enroll) i uzyskanie certyfikatu w trybie online. Procedura jest łatwa i w trybie online dostępna jest również pomoc. Większość niezależnych jednostek certyfikujących zezwala na korzystanie ze swoich usług za darmo w okresie próbnym, głównie przez miesiąc. Następnie zostaje przysłana prośba o przekazanie z witryny bezpiecznej (secure site) danych dotyczących karty kredytowej. Jednostka
certyfikująca przesyła wiadomość e-mail o pierwszym zarejestrowaniu i po raz kolejny, gdy okres próbny skończy się. Jednostki certyfikujące są cennymi zasobami i zwykle są bardzo dobrze chronione. Ochrona ta obejmuje: •
ochronę fizyczną (physical protection) — fizyczne odizolowanie serwera jednostki certyfikującej (CA server), w pomieszczeniu dostępnym tylko dla administratorów zabezpieczeń, ogranicza możliwości przed penetracją ze strony osób niepowołanych,
•
zarządzanie kluczami (keys management) — klucze prywatne (private keys) muszą być chronione, ponieważ stanowią podstawę zaufania do procesu certyfikacji. Kryptograficzne Moduły Sprzętowe (Cryptographic Hardware Modules) umożliwiają odporne na penetrację (tamper-resistant key storage) przechowywanie kluczy i odizolowanie operacji kryptograficznych od innych programów uruchomionych na danym serwerze,
•
odtwarzanie (restoration) — utrata jednostki certyfikującej w wyniku awarii sprzętowej może być przyczyną niesprawności systemu i problemów administracyjnych oraz może zapobiec odwołaniu (revocation) istniejących certyfikatów. Usługi certyfikatów (certificate services) firmy Microsoft obsługują wykonywanie kopii zapasowej konkretnej jednostki certyfikującej i późniejsze jej odtworzenie.
Relacja zaufania w strukturach hierarchicznych z wieloma jednostkami certyfikującymi Infrastruktura Klucza Publicznego (PKI) systemu Windows 2000 rozwiązuje problem relacji zaufania (trust relationships) w strukturach hierarchicznych z wieloma jednostkami certyfikującymi (multiple CA hierarchy). Dotyczy to hierarchii jednostek certyfikujących (CA hierarchies) w jednym przedsiębiorstwie i w granicach wielu przedsiębiorstw oraz komercyjnych jednostek certyfikujących, takich jak VeriSign lub Thawte. Na podstawie obiektów zasad domen (domain policy objects) systemu Windows 2000 można ustanowić i wprowadzić w życie relacje zaufania oparte na jednostkach certyfikujących (CA-based trust relationships). Umożliwia to zastosowanie ograniczeń użycia certyfikatów wydanych przez każdą zaufaną główną jednostkę certyfikującą (root CA), np. można wybrać, że zatwierdzane będą tylko certyfikaty wydane przez jednostkę certyfikującą dla uwierzytelniania serwera nawet, jeśli ta jednostka certyfikująca wydaje certyfikaty dla wielu innych zastosowań. Użytkownicy indywidualni mogą dodawać relacje zaufania jednostek certyfikujących (CAs), które mają zastosowanie tylko do nich samych. Można to zrobić, korzystając z funkcji klienta i nie jest wymagana interwencja administratora.
Odwoływanie (revocation) Certyfikaty bywają długowieczne, ale istnieje kilka przyczyn, dlaczego mogą stać się niegodne zaufania przed upłynięciem terminu ich ważności. Oto niektóre z nich: •
naruszenie zabezpieczeń klucza prywatnego,
•
oszustwa (fraud) przy uzyskiwaniu certyfikatu,
•
zmiana statusu.
Na potrzeby funkcji korzystających z klucza publicznego założono weryfikację rozproszoną, dokąd można skierować komunikację z centralną jednostką zaufaną, która może zagwarantuje poprawność tych danych uwierzytelniających (credentials). Z tego względu pojawiło się zapotrzebowanie na informacje o odwołaniu (revocation information), które mogą być rozsyłane do jednostek próbujących zweryfikować certyfikaty. Infrastruktura Klucza Publicznego (PKI) systemu Windows 2000 korzysta ze Standardowych List Odwołań Certyfikatów (Certificate Revocation Lists — CRLs). Jednostki certyfikujące przedsiębiorstwa (enterprise CAs) obsługują odwoływanie certyfikatów (certificate revocation) i publikowanie CRL dla usług katalogowych Active Directory pod kontrola administracyjna. Klienci domen mogą uzyskać te informacje i zapisać w buforze lokalnym, aby korzystać z nich przy weryfikowaniu certyfikatów. Ten sam mechanizm służy do obsługi list (CRL) opublikowanych przez komercyjne jednostki certyfikujące (commercial CAs) i do niezależnych programów dla serwera certyfikatów, przy założeniu, że opublikowane listy odwołań są dostępne dla klientów poprzez sieć.
Rozwiązania natychmiastowe
Instalowanie jednostki certyfikującej (Certification Authority — CA) W zależności od struktury sieci można zainstalować jedną lub kilka jednostek certyfikujących, których rodzaje wymieniono poniżej: •
•
główna jednostka certyfikująca przedsiębiorstwa (enterprise root CA) — główna jednostka w hierarchicznej strukturze jednostek certyfikujących przedsiębiorstwa w systemie Windows 2000. Ze względów bezpieczeństwa jest ona (enterprise CA) na ogół skonfigurowana w ten sposób, że wydaje certyfikaty tylko bezpośrednio podległym jednostkom certyfikującym (subordinate CAs). Jednostka ta wymaga spełnienia następujących warunków: •
ze względu na usługi katalogowe Active Directory, musi być zainstalowana usługa systemu Windows 2000 Domain Name Service (DNS),
•
musi być zainstalowana usługa systemu Windows Directory Service. Zasady przedsiębiorstwa (enterprise policy) umieszczają dane w Active Directory,
•
uprawnienia administracyjne dotyczące serwerów usług DNS, Directory i jednostek certyfikujących. Są one ważne, ponieważ program instalacyjny modyfikuje informacje w wielu miejscach i w niektórych przypadkach konieczne są takie uprawnienia.
podrzędne jednostki certyfikujące przedsiębiorstwa (enterprise subordinate CAs) — wydają certyfikaty w granicach danego przedsiębiorstwa, ale nie są to jednostki certyfikujące obdarzone najwyższym stopniem zaufana w tym przedsiębiorstwie, ponieważ podlegają innej jednostce certyfikującej. Podległa jednostka certyfikująca (subordinate CA) wymaga spełnienia następujących warunków: •
nadrzędna jednostka certyfikująca (parent CA), którą może być zewnętrzna komercyjna jednostka certyfikująca (external commercial CA) lub autonomiczna jednostka certyfikująca (standalone CA),
•
usługa DNS systemu Windows 2000,
•
uprawnienia administracyjne dotyczące serwerów usług DNS, Active Directory i jednostek certyfikujących.
•
autonomiczna główna jednostka certyfikująca (standalone root CA) — główna jednostka w hierarchicznej strukturze relacji zaufania jednostek certyfikujących (CA trust hierarchy). Może wydawać certyfikaty poza sieć przedsiębiorstwa. Np. można wydać certyfikaty odbiorcom, aby mieli dostęp do witryny internetowej przedsiębiorstwa, ale utworzenie w katalogu konta dla każdego odbiorcy nie jest możliwe do wykonania. Autonomiczna jednostka certyfikująca (standalone root CA) wymaga uprawnień administratora na serwerze lokalnym,
•
autonomiczna podrzędna jednostka certyfikująca (standalone subordinate CA) — pracuje jako pojedynczy serwer certyfikatów lub jest częścią hierarchicznej struktury relacji zaufania jednostek certyfikujących (CA trust hierarchy). Powinna zostać zainstalowana,
jeśli wydaje się certyfikaty jednostkom spoza przedsiębiorstwa. Należy zwrócić uwagę, że zwykle autonomiczna główna jednostka certyfikująca (standalone root CA) wydaje certyfikaty innym jednostkom certyfikującym, podczas gdy autonomiczna podrzędna jednostka certyfikująca (standalone subordinate CA) wydaje certyfikaty użytkownikom. Autonomiczna podrzędna jednostka certyfikująca wymaga spełnienia następujących warunków: •
połączenie z jednostką certyfikującą, która będzie przetwarzać żądania certyfikatów wysłane przez daną autonomiczną podrzędną jednostkę certyfikującą. Może to być jednostka certyfikująca przedsiębiorstwa (enterprise CA), autonomiczna główna jednostka certyfikująca (standalone root CA) lub zewnętrzna komercyjna jednostka certyfikująca (external commercial CA),
•
uprawnienia administracyjne na serwerze lokalnym.
Uwaga: opisana poniżej procedura podaje sposób instalowania jednostki certyfikującej (CA). Jeśli mają być zainstalowane opcjonalne składniki sieci Web, to musi być także zainstalowany Internet Information Server (IIS).
Aby zainstalować jednostkę certyfikującą (CA) postępuj zgodnie z procedurą opisaną poniżej: 1.
W oknie Panel Sterowania (Control Panel) kliknij dwukrotnie ikonę Dodaj/Usuń programy (Add/Remove programs). Pojawi się okno dialogowe Dodaj/Usuń programy.
2.
Aby uruchomić Kreatora Składników Systemu Windows (Windows Components Wizard) naciśnij opcję Dodaj/Usuń składniki systemu Windows (Add/Remove Windows components).
3.
Wybierz pozycję Usługi Certyfikatów (Certificate Services).
4.
Aby zamknąć pole komunikatów (message box), zaznacz Tak (Yes). Jeśli masz zamiar korzystać ze składników internetowych usług certyfikatów, sprawdź, czy zaznaczone jest pole wyboru Internet Information Server (IIS).
5.
Naciśnij przycisk Dalej (Next). Kreator (wizard) wyświetli monit o podanie rodzaju jednostki certyfikującej (CA), która ma być zainstalowana. Program instalacyjny, aby uprościć instalację, spróbuje domyślić się, która opcja jest wybrana: •
jeśli nie wykryto usług katalogowych Active Directory, opcje z jednostkami certyfikującymi przedsiębiorstwa będą zablokowane,
•
jeśli wykryto usługi katalogowe, wybrana zostanie główna jednostka certyfikująca przedsiębiorstwa (enterprise root CA), o ile nie zarejestrowano jeszcze w Active Directory żadnej jednostki certyfikującej,
•
jeśli w Active Directory zarejestrowano jednostki certyfikujące, wybrana zostanie podrzędna jednostka certyfikująca przedsiębiorstwa.
Uwaga: Jeśli certyfikaty będą wydawane jednostkom w danej organizacji i będzie potrzebna całkowita integracja z usługami katalogowymi Active Directory albo uaktywnienie logowania za pomocą kart elektronicznych (smart card logon), powinna zostać wybrana jednostka certyfikująca przedsiębiorstwa (enterprise CA). Jeśli certyfikaty będą wydawane jednostkom spoza przedsiębiorstwa oraz usługi katalogowe Active Directory i inne funkcje Infrastruktury Klucza Publicznego (PKI) systemu Windows 2000 nie będą używane, powinna zostać wybrana autonomiczna jednostka certyfikująca (standalone CA).
6.
Na podstawie powyższych informacji dotyczących różnych rodzajów jednostek certyfikujących (CAs) wybierz tę jednostkę certyfikującą, która jest potrzebna. Naciśnij przycisk Dalej.
7.
Kreator wyświetli monit o podanie informacji dotyczących twojej organizacji i lokacji (site), co przedstawiono na rysunku 7.2.
Uwaga: Nazwa jednostki certyfikującej (CA) jest bardzo ważna, ponieważ służy do identyfikowania obiektu jednostki certyfikującej (CA object). Okres ważności może być ustalony tylko dla głównej jednostki certyfikującej (root CA). Rzeczywisty okres ważności jest rozwiązaniem kompromisowym pomiędzy względami bezpieczeństwa a wymogami administracyjnymi. Za każdym razem, gdy certyfikat traci ważność, administrator musi uaktualnić wszystkie relacje zaufania (trust relationships) i przenieść jednostkę certyfikującą do nowego certyfikatu.
8.
Po wpisaniu wszystkich informacji identyfikujących naciśnij przycisk Dalej.
9.
Pojawi się okno z komunikatem ostrzegającym, że podane informacje zawierają znaki, które będą zakodowane w standardzie Unicode. Aby zamknąć okno, naciśnij Tak (Yes).
10. Okno dialogowe określa lokalizację bazy danych certyfikatów, informacji o konfiguracji oraz miejsca przechowywania Listy Odwołań Certyfikatów (CRL). Jednostka certyfikująca przedsiębiorstwa (enterprise CA) zawsze zapisuje dane w katalogu CertSrv.
Uwaga: Zaleca się, aby sprawdzić zawartość pola Store przy zaznaczonym polu wyboru foldera udostępnionego (shared folder). Opcja ta określa lokalizację foldera, w którym zapisane będą dane o konfiguracji danej jednostki certyfikującej. Należy podać ścieżkę UNC do tego foldera i tak skonfigurować wszystkie jednostki certyfikujące (CA), by wskazywały na ten sam folder. Jeśli nie można skorzystać z usług katalogowych Active Directory, wówczas folder ten służy do określenia konfiguracji jednostki certyfikującej przez narzędzia administracyjne.
Rysunek 7.2. Dane identyfikacyjne jednostki certyfikującej wraz z ustawionym okresem ważności 11. Podaj lokalizację, w której mają zostać zapisane ustalone przez ciebie informacje, a następnie naciśnij przycisk Dalej (Next). 12. Może pojawić się okno komunikatów z informacją, że zostanie utworzony folder. Aby zamknąć okno, naciśnij przycisk Tak (Yes). 13. Jeśli usługa Internet Information Server (IIS) jest uruchomiona, pojawi się komunikat żądający zatrzymania tej usługi. Aby to zrobić naciśnij przycisk OK. 14. Jeśli instalowana jest podrzędna jednostka certyfikująca (subordinate CA), kreator wyświetli monit o informacje dotyczące sposobu wysyłania żądania certyfikatu. W trakcie instalowania głównej jednostki certyfikującej (root CA) to okno dialogowe nie pojawi się. W tym przypadku przejdź bezpośrednio do czynności 18. 15. Aby zlokalizować jednostkę certyfikującą pracującą w trybie online, naciśnij przycisk Przeglądaj (Browse). Jeśli korzystasz z komercyjnej jednostki certyfikującej (CA) lub z jednostki certyfikującej, która nie jest dostępna z sieci jako główna (root), wybierz opcję Zapisz Żądanie w Pliku (Save The Request To a File). Jeśli utworzysz plik, musisz go przekazać do jednostki certyfikującej (CA), aby mogła go przetworzyć. Jednostka certyfikująca dostarczy certyfikat, który instaluje się za pomocą modułu dodatkowego (snap-in) konsoli MMC.
16. Naciśnij Dalej (Next). Jeśli wybrałeś zapisywanie żądania w pliku, pojawi się komunikat, mówiący o tym, że musisz przekazać ten plik do jednostki certyfikującej (CA). Sposób przekazania opisano w dalszej części niniejszego rozdziału. W przeciwnym razie wykonanie czynności 17 spowoduje zainstalowanie jednostki certyfikującej. 17. Naciśnij przycisk OK. 18. Rozpocznie się instalowanie. Może pojawić się monit o włożenie instalacyjnego dysku CD-ROM systemu Windows 2000. Aby zamknąć kreatora (wizard), naciśnij przycisk Zakończ (Finish).
Zastosowanie stron internetowych usług certyfikatów Usługi Certyfikatów (Certificates Services) systemu Windows 2000 są dostarczane przez próbne strony internetowe, które umożliwiają użycie przeglądarki internetowej do połączenia się z daną usługą i zrealizowanie często wykonywanych zadań, takich jak żądanie certyfikatu jednostki administracyjnej, żądanie certyfikatów od jednostek certyfikujących, przetwarzanie pliku z żądaniem certyfikatu lub przetwarzanie pliku rejestrowania karty elektronicznej (smart card enrollment file). Jednostka certyfikująca przedsiębiorstwa (enterprise CA) wymaga zalogowania się na stronie internetowej, podając swój identyfikator użytkownika (user ID). Następnie wybiera się Szablon Certyfikatu (Certificate Template). Jednostka certyfikująca znajduje konto użytkownika w usługach katalogowych Active Directory i generuje certyfikat na podstawie informacji z Active Directory i wybranego szablonu (template). Autonomiczna jednostka certyfikująca nie wymaga podania Identyfikatora Logowania (Logon ID), ale zamiast tego korzysta z informacji podanych w żądaniu certyfikatu i na podstawie tych danych wydaje certyfikat. Domyślnie autonomiczna jednostka certyfikująca (standalone CA) nie wyda natychmiast certyfikatu użytkownikowi — najpierw administrator musi zatwierdzić żądanie za pomocą narzędzi administracyjnych. Oznacza to, że użytkownik musi odwiedzić strony internetowe dwukrotnie; aby wysłać żądanie oraz aby odebrać certyfikat. Administrator może skonfigurować jednostkę certyfikującą w ten sposób, aby certyfikaty były wydawane natychmiast i w tym przypadku użytkownik otrzyma certyfikat na żądanie. Na potrzeby poniższej procedury przyjęto, że zainstalowana jest usługa certyfikatów (certificate service) firmy Microsoft. Strony internetowe znajdują się pod adresem http://ServerNAme/CertSrv, gdzie ServerName jest nazwą serwera jednostki certyfikującej (CA server).
Wskazówka: Jeśli po połączeniu się ze stronami internetowymi usług certyfikatów (certificate services) wystąpi błąd, należy sprawdzić, czy strony te są zainstalowane. Jeśli nie zainstalowano usługi Internet Information Server (IIS) lub zainstalowano ją po usłudze
certyfikatów, to strony internetowe nie zostaną zainstalowane. W tym przypadku konieczne jest ponowne zainstalowanie usług certyfikatów i prawdopodobnie również usługi Internet Information Server.
Potwierdzanie ustawień stron internetowych Jeśli korzysta się z jednostki certyfikującej przedsiębiorstwa (enterprise CA), konieczne jest upewnienie się, czy prawidłowo ustanowiono zabezpieczenia stron internetowych. W przypadku autonomicznej jednostki certyfikującej (standalone CA), można to pominąć. Jednostka certyfikująca przedsiębiorstwa wymaga, aby żądający certyfikatu (requestor) został uwierzytelniony przez daną stronę internetową, więc może ustalić, które informacje mają być zamieszczone w certyfikacie. Poniżej opisano sposób potwierdzania ustawień zabezpieczeń: 1.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Menedżer Usług Internetowych (Internet Service Manager).
2.
Rozwiń gałąź Domyślna Witryna Sieci Web (Default Web Site) i zlokalizuj katalog wirtualny (virtual directory) CertSrv. Jeśli nie można go znaleźć, upewnij się, czy zainstalowano Usługę Certyfikatów (Certificate Service) a — w razie potrzeby — zainstaluj je ponownie.
OSTRZEŻENIE! Aby wymieniony powyżej katalog wirtualny był widoczny, może być konieczne usunięcie i ponowne zainstalowanie Usługi Certyfikatów (Certificate Service).
3.
Prawym przyciskiem myszki kliknij folder wirtualny CertSrv i z menu wybierz pozycję Właściwości (Properties).
4.
Wybierz zakładkę Zabezpieczenia Katalogu (Directory Security).
5.
W części okna Kontrola Dostępu Anonimowego i Uwierzytelniania (Anonymous Access and Authentication Control) naciśnij przycisk Edytuj (edit).
6.
Usuń zaznaczenie wszystkich pól wyboru oprócz Zintegrowane Uwierzytelnianie Systemowe Windows (Integrated Windows Authentication), jak przedstawiono to na rysunku 7.3.
7.
Naciśnij OK i zamknij wszystkie okna dialogowe.
Rysunek 7.3. Sposoby uwierzytelniania
Instalowanie certyfikatów jednostek certyfikujących (CA certificates) Uruchom przeglądarkę i połącz się ze stroną o adresie http://ServerName/CertSrv, gdzie ServerName jest nazwą serwera jednostki certyfikującej (CA server). W przypadku łączenia się z jednostką certyfikującą przedsiębiorstwa (enterprise CA), wymagane będzie zalogowanie na stronie internetowej przez podanie identyfikatora użytkownika (user ID) i hasła. Po połączeniu pojawi się ekran podobny do przedstawionego na rysunku 7.4.
Rysunek 7.4. Ekran powitalny Usługi Certyfikatów firmy Microsoft (Microsoft Certificate Services) W przypadku połączenia z jednostką certyfikującą przedsiębiorstwa, jeśli dany komputer należy do tego przedsiębiorstwa, można od razu przejść do procedury opisanej w podrozdziale „Żądanie certyfikatu”, pomijając procedurę zamieszczoną poniżej. W przypadku połączenia z autonomiczną jednostką certyfikującą (standalone CA) przed użyciem Infrastruktury Klucza Publicznego (PKI) konieczne jest pobranie certyfikatu głównego (root certificate) i podać, czy zostanie obdarzony zaufaniem.
Pobieranie certyfikatu głównego (root certificate) 1.
Zaznacz pozycję Pobieranie certyfikatu głównego lub listy unieważnionych certyfikatów (Retrieve the root certificate or certificate revocation list), a następnie naciśnij przycisk Dalej (Next). Pojawi się ekran podobny do zamieszczonego na rysunku 7.5.
2.
Wybierz łącze Pobieranie certyfikatu jednostki certyfikującej (Download CA certificate).
3.
Wybierz pozycję Otwórz ten plik z bieżącej lokalizacji (Open this file from its current location) i naciśnij przycisk OK. Pojawi się okno dialogowe podobne do zamieszczonego na rysunku 7.6.
4.
Jeśli zadecydujesz, że certyfikat jest godny zaufania we wszystkich wymienionych w oknie zastosowaniach, naciśnij przycisk Instaluj Certyfikat (Install Certificate). Uruchomiony zostanie Kreator Importu Certyfikatów (Certificate Import Wizard).
5.
Naciśnij przycisk Dalej. Kreator (wizard) poprosi o wybranie magazynu (store) dla danego certyfikatu. Wybierz opcję Automatycznie wybierz magazyn certyfikatów na podstawie typu certyfikatu (Automatically select the certificate store based on the type of the certificate). Naciśnij przycisk Dalej.
6.
Naciśnij przycisk Zakończ (Finish).
Rysunek 7.5. Okno dialogowe z instrukcjami instalacji jednostki certyfikującej (CA)
Rysunek 7.6. Okno dialogowe z informacjami o certyfikacie 7.
Jeśli operacja importowania zakończy się poprawnie, pojawi się komunikat potwierdzający. Naciśnij przycisk OK.
8.
Aby zamknąć okno dialogowe Informacje o Certyfikacie (Certificate Information), naciśnij OK. Teraz można przejść do następnej procedury żądania certyfikatu.
Żądanie certyfikatu Poniżej opisano procedurę żądania certyfikatu:
1.
Uruchom przeglądarkę i połącz się ze stroną o adresie http://ServerName/CertSrv. Pojawi się ekran powitalny Usługi Certyfikatów Firmy Microsoft (Microsoft Certificate Services), przedstawiony na rysunku 7.4.
2.
Włącz pozycję Żądanie Certyfikatu (Request a Certificate). Naciśnij przycisk Dalej (Next).
3.
Wybierz opcję Żądanie Certyfikatu Użytkownika (User Certificate Request) i w polu listy zaznacz pozycję Certyfikat Użytkownika (User Certificate). Naciśnij przycisk Dalej.
4.
W przypadku połączenia z autonomiczną jednostką certyfikującą (standalone CA) pojawi się strona Certyfikat Użytkownika — Informacja Identyfikacyjna (User Certificate — Identifying Information). Wypełnij wówczas formularz w trybie online i naciśnij przycisk Dalej. W przypadku połączenia z jednostką certyfikującą przedsiębiorstwa (enterprise CA) dane zostaną pobrane z Active Directory i pojawi się monit o wysłanie żądania.
5.
Naciśnij przycisk Wyślij (Submit). Na podstawie podanych informacji program wygeneruje parę kluczy prywatnych i żądanie certyfikatu oraz wyśle żądanie do jednostki certyfikującej (CA).
6.
Jeśli jednostka certyfikująca jest skonfigurowana w ten sposób, że zatwierdza żądania automatycznie, to zostanie wydany nowy certyfikat. W tym przypadku kliknij połączenie (link) Instaluj ten certyfikat (Install this certificate) i zostanie on zainstalowany. Jeśli jednostka certyfikująca wymaga przed wydaniem certyfikatu zatwierdzenia przez administratora, pojawi się okno Certyfikat Oczekujący (Certificate Pending). Teraz należy przejść do następnej procedury.
Zakończenie obsługi żądań oczekujących Procedura ta pozwala na zakończenie obsługi żądania certyfikatu, które wymaga zatwierdzenia przez administratora. Należy zwrócić uwagę, że poniższą procedurę wykonuje się tylko wtedy, gdy jednostka certyfikująca została skonfigurowana w ten sposób, że przed wydaniem certyfikatu wymagane jest zatwierdzenie przez administratora oraz po pojawieniu się komunikatu o certyfikacie oczekującym (certificate pending), kończącym procedurę opisaną powyżej. 1.
Uruchom przeglądarkę i połącz się ze stroną o adresie http://ServerName/CertSrv. Pojawi się ekran powitalny Usługi Certyfikatów Firmy Microsoft (Microsoft Certificate Services), przedstawiony na rysunku 7.4. Zaznacz opcję Sprawdzenie Certyfikatów Oczekujących (Check On a Pending Certificate) i naciśnij przycisk Dalej (Next).
2.
W polu listy pojawią się zatwierdzone żądania certyfikatów. Wybierz jedno i naciśnij przycisk Dalej.
3.
Kliknij łącze (link) Instalowanie niniejszego certyfikatu (Install this certificate).
4.
Certyfikat został zainstalowany. Aby zamknąć okno z komunikatem potwierdzającym, naciśnij przycisk OK.
Weryfikowanie wydanego certyfikatu Do zweryfikowania certyfikatu można użyć przeglądarki internetowej lub programu narzędziowego Jednostka certyfikująca (Certificate Authority — CA). Obydwa sposoby opisano poniżej.
Zastosowanie programu Internet Explorer 5 1.
Z menu programu Internet Explorer Narzędzia (Tools) wybierz pozycję Opcje Internetowe (Internet Options).
2.
Wybierz zakładkę Zawartość (Content).
3.
Naciśnij przycisk Certyfikaty (Certificates).
4.
Odszukaj pobrany certyfikat i kliknij go dwukrotnie, aby zobaczyć informacje szczegółowe. Jeśli certyfikatu nie ma na liście, jego pobranie nie zakończyło się poprawnie. Można wybrać zakładkę Ogólne (General), Szczegóły (Details) lub Ścieżka Certyfikacji (Certification Path). Na rysunku 7.7 przedstawiono okno zakładki Szczegóły.
Rysunek 7.7. Informacje szczegółowe o certyfikacie
Zastosowanie programu narzędziowego Jednostka certyfikująca (CA) 1.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Jednostka Certyfikująca (Certification Authority).
2.
Odszukaj pobrany certyfikat i kliknij go dwukrotnie, aby zobaczyć informacje szczegółowe. Jeśli certyfikatu nie ma na liście, jego pobranie nie zakończyło się poprawnie. Powinno pojawić się okno przedstawione na rysunku 7.7.
Żądanie certyfikatów zaawansowanych Jeśli zachodzi potrzeba wysłania do jednostki certyfikującej (CA) żądania certyfikatu specjalnego, należy skorzystać z opcji zaawansowanych. Można, np. żądać certyfikatu dla protokołu IP Security (IPSec) lub certyfikatu z kluczem o specjalnej długości. Poniżej zamieszczono procedurę żądania certyfikatu zaawansowanego: 1.
Za pomocą przeglądarki przejdź do strony Usługi Certyfikatów — Strona Powitalna (Certificate Services Welcome). Zaznacz opcję Żądanie Certyfikatu (Request a Certificate), a następnie naciśnij przycisk Dalej (Next).
2.
Wybierz opcję Żądanie Zaawansowane (Advanced Request) i włącz Dalej. Powinien pojawić się ekran podobny do zamieszczonego na rysunku 7.8.
Rysunek 7.8. Okno żądania certyfikatów zaawansowanych (Advanced Certificate Requests) 3.
Zaznacz opcję Prześlij żądanie certyfikatu do danej jednostki certyfikującej, używając formularza (Submit a certificate request to this CA using a form), a następnie naciśnij przycisk Dalej. Opcję wykorzystującą pliki w standardzie PKCS #10 omówiono w dalszej części niniejszego rozdziału.
Rozwiązania pokrewne zobacz na stronie: Wydawanie kart elektronicznych (smart cards) 4.
W przypadku połączenia z autonomiczną jednostką certyfikującą (standalone CA) zostaniesz poproszony o podanie informacji identyfikujących. Wybierz zastosowanie certyfikatu, które ci najbardziej odpowiada. Zmiana zawartości pola Usługodawca Usług Kryptograficznych (Cryptographic Service Provider) nie jest potrzebna, o ile nie jest wymagany inny algorytm klucza publicznego (public key algorithm) lub nie stosuje się urządzeń specjalnych, np. kart elektronicznych (smart cards).
5.
Podaj żądane informacje i naciśnij przycisk Dalej (Next) Powinno pojawić się okno podobne do przedstawionego na rysunku 7.9. W przypadku połączenia z jednostką certyfikującą przedsiębiorstwa (enterprise CA) okno to pojawi się od razu.
Rysunek 7.9. Wybór opcji zaawansowanych Okno Żądanie Certyfikatu Zaawansowanego (Advanced Certificate Request) umożliwia wybranie wielu opcji zaawansowanych:
•
Zastosowanie Klucza (Key Usage) — określa czy certyfikat będzie używany przy szyfrowaniu, opatrywaniu podpisem cyfrowym lub w obu tych przypadkach,
•
Rozmiar Klucza (Key Size) — zależy od używanych aplikacji i zainstalowanej wersji systemu Windows. Zazwyczaj dobrze jest wybrać klucz o długości 1024 bitów. W chwili pisania niniejszej książki istniały w wersji eksportowej systemu Windows 2000 ograniczenia długości klucza do maksymalnie 512 bitów,
•
Algorytm Funkcji Skrótu (Hash Algorithm) — nie należy zmieniać domyślnej zawartości tego pola bez wyraźnych przyczyn,
•
Użyj Magazynu w Komputerze Lokalnym (Use Local Machine Store) — umieszcza klucze i certyfikaty w magazynie (store) komputera, aby procesy systemowe, jak np. protokół IPSec, mogły z nich korzystać,
Uwaga: Jeśli używany jest istniejący zestaw kluczy, można je oznaczyć jako możliwe do eksportowania (exportable). Także zaznaczyć opcję Włącz Mocną Ochronę Klucza Prywatnego (Enable Strong Private Key Protection), ale jest to na ogół niewłaściwy wybór, w przypadku kluczy zapisanych w magazynie (store) na komputerze lokalnym. Jak zawsze należy zachować równowagę pomiędzy bezpieczeństwem a użytecznością.
•
Zapisz Żądanie Do Pliku w Formacie PKCS #10 (Save Request To a PKCS #10 File) — tworzy plik żądania, który można wysłać do innej jednostki certyfikującej (CA). Tę opcję wybiera się w przypadku wysyłania żądań do usług certyfikatów, innych niż usługi firmy Microsoft, np. VeriSign.
6.
Zaznacz potrzebne ci opcje i naciśnij przycisk Prześlij (Submit). Program wygeneruje parę kluczy prywatnych (private keys) i żądanie certyfikatu, zawierające wprowadzone uprzednio informacje. Żądanie jest wysyłane do jednostki certyfikującej.
7.
Nowy certyfikat zostanie wydany, jeśli jednostka certyfikująca (CA) jest skonfigurowana w ten sposób, aby żądania certyfikatów były zatwierdzane automatycznie. W tym przypadku naciśnij przycisk Zainstaluj Ten Certyfikat (Install This Certificate). W przeciwnym razie konieczne jest zakończenie obsługi żądań oczekujących w sposób opisany wcześniej w niniejszym rozdziale.
Rejestrowanie za pomocą pliku żądania w formacie PKCS #10 Wiele urządzeń i usług tworzy pliki żądania certyfikatu w formacie PKCS #10 (są to np. Internet Information Server, podrzędna jednostka certyfikująca (subordinate CA) czy protokół IPSec).
Zawierają one wszystkie dane i wskazówki niezbędne do wydania certyfikatu. Na potrzeby procedury zamieszczonej poniżej przyjęto, że uzyskano certyfikat w formacie PKCS #10 i zapisano go w pliku. Przetwarzanie pliku żądania certyfikatu w formacie PKCS #10 przebiega w następujący sposób: 1.
Postępując zgodnie z opisem zamieszczonym powyżej w niniejszym rozdziale, przejdź na stronę Żądanie Certyfikatu Zaawansowanego (Advanced Certificate Request), które przedstawiono na rysunku 7.8.
2.
Zaznacz opcję Prześlij żądanie certyfikatu, korzystając z pliku w formacie PKCS #10 zakodowanego algorytmem base64 lub żądanie wznowienia, korzystając z pliku w formacie PKCS #7 zakodowanego algorytmem base64 (Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file), a następnie naciśnij przycisk Dalej (Next).
3.
Wstaw plik w formacie PKCS #10 zakodowany algorytmem base64 w pole tekstowe Żądanie Zapisane (Saved Request), potem naciśnij przycisk Prześlij (Submit). Przykład przedstawiono na rysunku 7.10.
4.
Strony internetowe wygenerują parę kluczy prywatnych (private key pair) i żądanie certyfikatu zawierające podane informacje. Instalowanie certyfikatu odbywa się zgodnie z procedurą opisaną uprzednio.
Rysunek 7.10. Okno Przesyłanie Zapisanego Żądania (Submit a Saved Request)
Konfigurowanie relacji zaufania pomiędzy domeną a zewnętrzną jednostką certyfikującą Poniżej zamieszczono procedurę ustanawiania relacji zaufania pomiędzy domeną systemu Windows 2000 a zewnętrzną jednostką certyfikującą (CA), taką jak VeriSign, Thawte lub jednostka certyfikująca (CA) firmy Microsoft w innej domenie. Przyjęto, że otrzymano certyfikat główny (root certificate) od jednostki zewnętrznej i zapisano go w pliku. 1.
Uruchom okno dialogowe Zasady Grupowe Domeny Właściwości (Domain Group Policy Properties) i edytuj obiekt zasad grupowych (GPO) Domyślne Zasady Domeny (Default Domain Policy).
Rozwiązania pokrewne zobacz na stronie: Edytowanie obiektu zasad grupowych 2.
Rozwiń gałąź Konfiguracja komputera (computer configuration), Ustawienia systemu Windows (Windows settings), Ustawienia zabezpieczeń (security settings), Zasady kluczy publicznych (public key policies) i prawym przyciskiem myszki włącz pozycję Zaufane główne jednostki certyfikujące (trusted root CAs).
3.
Z menu wybierz opcję Wszystkie zadania (All tasks), a następnie kliknij Importuj (Import) (rysunek 7.11). Uruchomiony zostanie Kreator Importu Certyfikatów (Certificate Import Wizard).
4.
Naciśnij przycisk Dalej (Next). W polu Nazwa Pliku (File Name) wpisz nazwę pliku zawierającego certyfikat główny (root certificate), który ma zostać zaimportowany lub użyj przycisku Przeglądaj (Browse) do znalezienia tego pliku. Naciśnij Dalej, określ hasło i ponownie naciśnij Dalej. Powinno pojawić się okno podobne do przedstawionego na rysunku 7.12.
Rysunek 7.11. Importowanie zaufanego certyfikatu głównego (root certificate)
Rysunek 7.12. Podawanie magazynu (store) docelowego dla certyfikatu głównego (root certificate) 5.
Zaznacz opcję Umieść wszystkie certyfikaty w następującym magazynie (Place all certificates in the following store). Magazynem docelowym są Zaufane Główne Jednostki Certyfikujące w danym obiekcie zasad grupowych (GPO). Naciśnij przycisk Dalej.
6.
Aby zaimportować certyfikat, naciśnij przycisk Zakończ (Finish). Aby zamknąć okno komunikatów (message box), naciśnij przycisk OK. W celu zastosowania tych zasad do obiektu zasad grupowych (GPO), potwierdź OK, a następnie zamknij konsolę MMC. Można zweryfikować certyfikat, postępując zgodnie z procedurą opisaną w powyższych akapitach niniejszego rozdziału.
Instalowanie automatycznego żądania certyfikatów dla komputerów
Automatyczne żądania certyfikatów dla komputerów umożliwiają administratorom wysyłanie komunikatów z jednego miejsca z żądaniem certyfikatów od jednostek certyfikujących (CAs) systemu Windows 2000, na których ustanowiono zasady przedsiębiorstwa (enterprise policy) dla wszystkich komputerów w domenie lub jednostce organizacyjnej (OU). Procedurę przeprowadza się na kontrolerze domeny i zakłada się, że na jednostce certyfikującej systemu Windows 2000 ustanowiono zasady przedsiębiorstwa (enterprise policy) w danej domenie. 1.
Edytuj domyślne zasady domeny (default domain policy) obiektu zasad grupowych (GPO).
2.
Rozwiń gałąź Konfiguracja Komputera (Computer Configuration), Ustawienia Systemu Windows (Windows Settings), Ustawienia Zabezpieczeń (Security Settings), Ustawienia Klucza Publicznego (Public Key Settings) i prawym przyciskiem myszki kliknij pozycję Ustawienia Automatycznego Żądania Certyfikatu (Automatic Certificate Request Settings).
3.
Z menu kontekstowego wybierz pozycję Nowy (New) i naciśnij opcję Automatyczne Żądanie Certyfikatu (Automatic Certificate Request). Uruchomiony zostanie Kreator Instalatora Automatycznego Żądania Zertyfikatu (Automatic Certificate Request Setup Wizard). Naciśnij przycisk Dalej.
4.
Powinien pojawić się ekran podobny do tego, który przedstawiono na rysunku 7.13. Pozwoli to na wybranie szablonu certyfikatu, który będzie używany przy wysyłaniu żądań certyfikatów. Wybierz opcję Komputer (Computer) i naciśnij Dalej.
5.
W domenie systemu Windows 2000 wybierz jednostkę certyfikującą, do której wysyłane będą żądania certyfikatów. Zazwyczaj w domenie znajduje się tylko jedna jednostka certyfikująca (CA), ale w przedsiębiorstwie może być ich kilka. Zwróć uwagę, że na liście nie ma jednostek certyfikujących, na których nie działają zasady przedsiębiorstwa (enterprise policy). Naciśnij przycisk Dalej.
6.
Aby utworzyć automatyczne żądanie certyfikatów naciśnij przycisk Zakończ (Finish). Dla dokonania edycji domyślnych zasad domeny (default Domain Policy) obiektu zasad grupowych (GPO), żądanie certyfikatu zostanie wysłane po odświeżeniu obiektu zasad grupowych po stronie klienta.
Rysunek 7.13. Wybieranie szablonu certyfikatu
Uruchamianie i zatrzymywanie usług certyfikatów Usługi Certyfikatów (Certificate Services) uruchamiane są automatycznie po zainstalowaniu i przy ponownym uruchamianiu systemu. Może zajść konieczność zatrzymania lub uruchomienia danych usług ręcznie w celu kontroli odbioru żądań lub wydawania certyfikatów. Poniżej podano procedurę uruchamiania i zatrzymywania usług certyfikatów: 1.
Uruchom narzędzie administracyjne Jednostka Certyfikująca.
2.
Prawym przyciskiem myszki kliknij nazwę uniwersalną (Common Name — CN) jednostki certyfikującej (CA), o której jest mowa (rysunek 7.14). Wybierz opcję Wszystkie zadania (All tasks), a następnie pozycję Uruchom Usługę (Start Service) lub Zatrzymaj Usługę (Stop Service) — zależnie od bieżącego stanu usługi.
Uwaga: Usługi Certyfikatów (Certificate Services) można również uruchomić lub zatrzymać za pomocą przycisków Uruchom (Start) lub Zatrzymaj (Stop).
Rysunek 7.14. Uruchamianie lub zatrzymywanie Usług Certyfikatów (Certificate Services)
Wykonywanie kopii zapasowych i odtwarzanie usług certyfikatów (certificate services) Usługi Certyfikatów zapewniają narzędzia do wykonywania kopii zapasowych, odtwarzania kluczy, certyfikatów i baz danych (dziennik wydanych certyfikatów i kolejka żądań oczekujących). Tak samo, jak w przypadku innych ważnych danych, administrator jest odpowiedzialny za planowanie i stworzenie harmonogramu okresowego wykonywania kopii zapasowych. Uchybienia w tym zakresie mogą spowodować brak możliwości zachowania zapisu kontrolnego (audit trail) żądań certyfikatów i certyfikatów wydanych. Oprócz tego można utracić ewentualność unieważnienia wydanych certyfikatów oraz certyfikatów, którym wcześniej przywrócono ważność (unrevoked certificates). Nie ma innego wyjścia — kopie zapasowe są konieczne!
Wykonywanie kopii zapasowych usług certyfikatów Poniżej opisano procedurę wykonywania kopii zapasowych, certyfikatów i baz danych związanych z Usługami Certyfikatów (Certificate Services). 1.
Uruchom narzędzie Jednostka Certyfikująca (Certificate Authority) i przejdź do okna przedstawionego na rysunku 7.14.
2.
Wybierz opcję Kopia Zapasowa Jednostki Certyfikującej (Backup CA). Uruchomiony zostanie Kreator Wykonywania Kopii Zapasowej Jednostki Certyfikującej (Certification Authority Backup Wizard).
3.
Naciśnij przycisk Dalej (Next). Sprawdź pola wyboru elementów, które mają być zawarte w kopii zapasowej. Zwykle wybrane są opcje Klucz prywatny i certyfikat Jednostki Certyfikującej (Private Key and CA Certificate) oraz Dziennik wystawionych certyfikatów i kolejka oczekujących żądań certyfikatów (Issued certificate log and pending certificate request queue), tak jak przedstawiono to na rysunku 7.15. Określ folder, w którym ma być zapisana kopia zapasowa, wpisując jego nazwę lub wybierając za pomocą przycisku Przeglądaj (Browse). Zwróć uwagę, że folder kopii zapasowej musi już istnieć.
4.
Naciśnij przycisk Dalej. Wprowadź hasło, które będzie używane do zabezpieczenia pliku kopii zapasowej przed dostępem osób nieuprawnionych. Ochrona ta jest konieczna, gdyż plik kopii zapasowej zawiera klucz prywatny jednostki certyfikującej (CA). Naciśnij Dalej.
5.
Wyświetlone zostaną opcje wykonywania kopii zapasowej Klucz prywatny i certyfikat Jednostki Certyfikującej i Dziennik wystawionych i żądania oczekujące (Issued log and pending request), jak przedstawiono to na rysunku 7.16. Naciśnij przycisk Zakończ (Finish).
Rysunek 7.15. Wybór danych do zapisania w pliku kopii zapasowej i jego lokalizacji
Rysunek 7.16. Zakończenie działania Kreatora Wykonywania Kopii Zapasowej Usług Certyfikatów (Certificate Services Backup Wizard) Zamknięcie okna przedstawionego na rysunku 7.16. oznacza potwierdzenie zakończenia wykonywania kopii zapasowej. W folderze pliku kopii zapasowej powinien znajdować się plik z rozszerzeniem .p12 oraz podfolder o nazwie DataBase, w którym powinny być zapisane cztery pliki z rozszerzeniami .dat, .log, .edb i .pat.
Odtwarzanie usług certyfikatów (certificate services) z pliku kopii zapasowej Poniżej zamieszczono procedurę odtwarzania informacji z pliku kopii zapasowej, otrzymanego w sposób opisany w poprzedniej części: 1.
Tak, jak w procedurze opisanej powyżej, najpierw przejdź do okna przedstawionego na rysunku 7.14. Z menu wybierz opcję Odtwarzaj Jednostkę Certyfikującą (Restore CA).
Uruchomiony zostanie Kreator Odtwarzania Usług Certyfikatów (Certificate Services Restore Wizard). 2.
Jeśli Usługi Certyfikatów (Certificate Services) działają, zostaniesz poproszony o ich zatrzymanie. W takim przypadku naciśnij Dalej.
3.
Zaznacz, co ma zostać odtworzone. Jeśli kopia zapasowa była wykonana według procedury opisanej powyżej, wybierz pozycję Klucz prywatny i certyfikat Jednostki Certyfikującej oraz Dziennik wystawionych certyfikatów i kolejka oczekujących żądań certyfikatów. Naciśnij przycisk Dalej (Next).
4.
Podaj hasło zabezpieczające kopię zapasową. Naciśnij Dalej, a potem przycisk Zakończ (Finish).
5.
Po zakończeniu odtwarzania pojawi się monit ponowne uruchomienie usług certyfikatów. Naciśnij przycisk Tak (Yes).
Wyświetlanie dziennika (log) i bazy danych usług certyfikatów (certificate services) Wyświetlenie dziennika (log) i bazy danych jest przydatne przy wykonywaniu inspekcji (audits) żądań oczekujących w kolejce i wydanych certyfikatów oraz do wybierania certyfikatów, które mają być unieważnione. Dziennik i bazę danych usług katalogowych (certificate services log and database) można obejrzeć za pomocą modułu dodatkowego (snap-in) Menedżer Usług Certyfikatów (Certificate Services Manager) konsoli MMC. Narzędzie to umożliwia również dostosowanie sposobu wyświetlania danych do własnych potrzeb.
Uwaga: Przed podjęciem eksperymentów ze sposobem wyświetlania certyfikatów konieczne jest jako pierwsze dodanie kilku certyfikatów za pomocą sposobów opisanych powyżej, najlepiej w pewnym okresie czasu, aby miały różne daty i znaczniki czasu (timestamps). W ten sposób, podając graniczną (cut-off) datę i czas można dostosować wyświetlanie listy wydanych certyfikatów do własnych potrzeb. Później zostanie podana procedura unieważniania certyfikatów wydanych przed datą graniczną.
Oto procedura wyświetlana dziennika (log): 1.
Uruchom program narzędziowy Jednostka Certyfikująca (Certification Authority) i jak poprzednio rozwiń gałąź z nazwą CN jednostki certyfikującej.
2.
Wybierz pozycję Wydane Certyfikaty (Issued Certificates), co przedstawiono na rysunku 7.17.
3.
Prawym przyciskiem myszki kliknij pozycję Wydane Certyfikaty, wybierz Widok (View), a następnie opcję Wybierz Kolumny (Choose Columns).
4.
Wybierz pola, które mają być wyświetlone, np. pole obowiązkowe Identyfikator Żądania (Request ID), Numer Kolejny (Serial Number), Data Wprowadzenia Certyfikatu (Certificate Effective Date), Data Wygaśnięcia Certyfikatu (Certificate Expiration Date) oraz Nazwa Pospolita Wystawienia (Issued Common Name), jak przedstawiono to na rysunku 7.18. Naciśnij przycisk OK.
5.
Dopasuj szerokości kolumn do rozmiarów ekranu umieszczając wskaźnik myszki na granicy kolumny i przeciągając ją (tak, jak można to zrobić w arkuszach kalkulacyjnych).
6.
Aby zmienić kolejność wyświetlanych kolumn, prawym przyciskiem myszki kliknij kontener Wydane Certyfikaty, z menu wybierz pozycję Widok, a następnie opcję Wybierz Kolumny tak, jak opisano w punkcie 3. Można, np. zaznaczyć nazwę kolumny Nazwa Pospolita Wystawienia i nacisnąć przycisk Przenieś w górę (Move up). Zauważ, że pierwszą wyświetlaną kolumną jest zawsze Identyfikator Żądania (Request ID).
7.
Naciśnij przycisk OK., a następnie Odśwież (Refresh). Może zajść konieczność ponownego dostosowywania szerokości kolumn.
8.
Włączenie nagłówka kolumny Nazwa Pospolita Wystawienia umożliwia posortowanie według niej rekordów, ale w odwrotnej kolejności.
Rysunek 7.17. Okno przedstawiające wydane certyfikaty
Rysunek 7.18. Wybieranie kolumn, które mają być wyświetlane 9.
Aby pokazać tylko wiersze spełniające określone kryteria, prawym przyciskiem myszki kliknij pozycję Wystawione Certyfikaty (Issued Certificates), wybierz pozycję Widok, a następnie opcję Filtr (Filter).
10. Naciśnij przycisk Dodaj (Add). Ustaw odpowiednie wartości. W przykładzie przedstawionym na rysunku 7.19 wybrano usunięcie z listy certyfikatów wydanych później niż określa to podana data. 11. Naciśnij dwukrotnie przycisk OK.
Rysunek 7.19. Ustawianie wartości filtru wyświetlania
Odwoływanie (revoking) wydanych certyfikatów i publikowanie Listy Odwołań Certyfikatów (CRL) Funkcja odwoływania certyfikatów jest sposobem oznaczenia certyfikatu jako nieważny, zanim upłynie okres ważności (expiration). Status certyfikatu jest sprawdzany przed użyciem przez aplikacje, ale zwykłe odwołanie (revoking) certyfikatu nie wystarczy. Aby status ten był dostępny dla aplikacji, konieczne jest utworzenie i opublikowanie Listy Odwołań Certyfikatów (Certificate Revocation List — CRL).
Odwoływanie certyfikatów Poniższa procedura służy do odwoływania certyfikatów. Należy pamiętać o tym, że odwołanie nie daje żadnych efektów, jeśli nie zostanie także wykonana procedura utworzenia i opublikowania Listy Odwołań Certyfikatów (CRL). 1.
Wybierz certyfikat lub certyfikaty, które mają być odwołane. W niniejszym przykładzie odwołane zostaną wszystkie certyfikaty nieusunięte z listy w przykładzie poprzednim, ale można to wykonać dla dowolnego certyfikatu. Prawym przyciskiem myszki kliknij wybrane certyfikaty, wybierz opcję Wszystkie zadania (All tasks), a następnie Odwołaj Certyfikat (Revoke Certificate), jak przedstawiono to na rysunku 7.20.
2.
Na liście rozwijalnej zaznacz przyczynę odwołania, np. Złamanie Klucza (Key Compromise). Naciśnij przycisk Tak (Yes).
3.
Oglądając zawartość foldera Wydane Certyfikaty (Issued Certificates) i foldera Odwołane Certyfikaty (Revoked Certificates), sprawdź, czy odwołane certyfikaty są prawidłowo zaznaczone w bazie danych; odwołany certyfikat zaznaczony jest czerwonym znakiem z białym krzyżem.
Tworzenie Listy Odwoływania Certyfikatów (CRL)
Po odwołaniu certyfikatu konieczne jest utworzenie i opublikowanie Listy Odwoływanych Certyfikatów (CRL), aby aplikacje mogły sprawdzać odwołanie. 1.
Prawym przyciskiem myszki kliknij pozycję Certyfikaty Odwołane (Revoked Certificates). Z menu wybierz opcję Wszystkie zadania (All tasks), a następnie Publikuj (Publish), jak przedstawiono to na rysunku 7.21.
2.
Może pojawić się ostrzeżenie, że ostatnio opublikowana lista odwołań (CRL) jest nadal ważna. Jeśli tak jest, naciśnij przycisk Tak (Yes).
Oglądanie Listy Odwoływanych Certyfikatów (CRL) Lista (Certificate Revocation List) została opublikowana. To, czy jest prawidłowa, sprawdź w następujący sposób: 1.
Prawym przyciskiem myszki kliknij pozycję Certyfikaty Odwołane (Revoked Certificates) i z menu wybierz opcję Właściwości (Properties).
2.
Wybierz opcję Wyświetl Bieżącą Listę CRL (View Current CRL).
3.
Zakładka Ogólne (General) w oknie Lista Odwołań Certyfikatów (Certificate Revocation List) zawiera wszystkie informacje dotyczące danej listy (CRL).Przedstawia ona zawartość listy odwoływania certyfikatów (CRL).
4.
Zaznacz konkretny, odwołany (revoked) certyfikat, a jego zawartość pojawi się w polu Wpis Odwołania (Revocation Entry), jak przedstawiono to na rysunku 7.22. Pole Wartość (Value) jest używane w przypadku, gdy wartości zapisane w polach Pole (Field)/Wartość nie mieszczą się w danym wierszu. Wybranie wiersza w kolumnie Pole powoduje wyświetlenie jego pełnej zwartości.
Rysunek 7.20. Wybór certyfikatu do odwołania
Rysunek 7.21. Publikowanie Listy Odwoływania Certyfikatów (CRL)
Konfigurowanie modułów zasad i modułów zakończenia (exit modules) dla usług certyfikatów (certificate services) Architektura Usług Certyfikatów (Certificate Services) umożliwia stosowanie wymiennych modułów zasad i modułów wyjścia (policy and exit modules). Moduły zasad zawierają zasady podejmowania decyzji (decision logic) o tym, czy dane żądanie certyfikatu powinno zostać przyjęte, odrzucone czy pozostać w stanie oczekiwania na decyzję, która zostanie podjęta później. Moduły wyjścia (exit modules) dają możliwość wykonania przetwarzania końcowego (post processing), np. opublikowania wydanego certyfikatu. Jest to ważne dla użytkowników, którzy chcą wprowadzić własne moduły zasad za pomocą platformy Software Development Kit (SDK) lub uzyskać dane moduły od dostawców niezależnych.
Rysunek 7.22. Zawartość Listy Odwołań Certyfikatów (CRL) i szczegóły certyfikatu Zamieszczona poniżej procedura zamienia domyślny moduł zasad (policy module) na moduł przykładowy. Zarządzanie modułami wyjścia (exit module) odbywa się w ten sam sposób. W procedurze tej wykorzystano przykładowy moduł zasad Visual Basic (policyvb.dll), zamieszczony w platformie SDK. Można napisać własne moduły zasad i moduły wyjścia (exit modules), ale to zagadnienie wykracza poza zakres niniejszej książki.
Uwaga: Moduł policyvb.dll nie znajdzie się na dysku twardym po przeprowadzeniu zwykłej instalacji systemu Windows 2000. SDK musi zostać ściągnięty z witryny Microsoftu lub zainstalowany z dysku CD-ROM.
Konfigurowanie modułu zasad, aby mógł być używany przez usługę przebiega w następujący sposób: 1.
Skopiuj nowy moduł zasad (policy module) policyvb.dll do foldera %systemroot%system32.
2.
Zarejestruj nowy moduł zasad, wpisując w oknie dialogowym regsvr32 policyvb.dll.
3.
Uruchom program narzędziowy Jednostka Certyfikująca (CA), prawym przyciskiem myszki kliknij nazwę uniwersalną (CN) jednostki certyfikującej, którą chcesz skonfigurować i z menu wybierz pozycję Właściwości (Properties).
4.
Wybierz zakładkę Moduł Zasad (Policy Module). Powinno pojawić się okno podobne do przedstawionego na rysunku 7.23.
5.
Naciśnij przycisk Wybierz (Select) i wybierz nowy moduł zasad (policy), który zostanie zainstalowany, np. Certificate Services VB Policy. Naciśnij przycisk OK.
6.
Powinien nastąpić powrót do okna z zakładką Moduł Zasad. Zwróć uwagę, że zawartość pola Informacje o Module Zasad (Policy Module Information) zmieniła się odpowiednio do wprowadzonych zmian. Naciśnij przycisk Zastosuj (Apply).
7.
Aby ponownie uruchomić usługę, naciśnij przycisk Tak (Yes). Pasek postępu (progress bar) będzie pokazywał zatrzymywanie i ponowne uruchamianie usługi. Naciśnij OK.
Obecnie po wysłaniu żądania certyfikatu pojawią się inne wartości domyślne. Sprawdź to sam. Osoby znające Visual Basic lub inne osoby programujące w Visual Basicu mogą podjąć próby z własnymi modułami zasad (policy modules) i modułami wyjścia (exit modules).
Rysunek 7.23. Zakładka Moduły Zasad (Policy Module) okna Właściwości (Properties)
Rozdział 8
Przypisywanie certyfikatów do kont użytkowników Rozwiązania natychmiastowe zobacz na stronie: Instalowanie certyfikatu użytkownika Eksportowanie certyfikatu Instalowanie certyfikatu jednostki certyfikującej (CA) Konfigurowanie Active Directory, aby można było przypisywać nazwy główne użytkownika (User Principal Name — UPN) Konfigurowanie Active Directory, aby stosować odwzorowanie różnowartościowe (one-to-one mapping) Konfigurowanie usługi Internet Information Server (IIS), aby stosować przyporządkowanie jedendo-jednego (one-to-one mapping) Konfigurowanie Active Directory, aby stosować przyporządkowanie wiele-do-jednego (many-toone mapping) Konfigurowanie usługi Internet Information Server, aby stosować przyporządkowanie wiele-dojednego (many-to-one mapping)
Testowanie przypisania (mapping)
W skrócie Dlaczego konieczne jest przypisywanie (mapping) certyfikatów System operacyjny Windows 2000, dzięki uniwersalnemu modelowi administrowania, umożliwia zarządzanie kontami użytkowników na wiele sposobów. W systemach przedsiębiorstw, gdzie występuje stosunkowo niewiele zagrożeń, model konto użytkownika-hasło (user accountpassword) sprawdza się bardzo dobrze. Jednak sytuacja zmienia się w przypadku Internetu, który jest środowiskiem wrogim i ataki z zastosowaniem identyfikatora użytkownika oraz hasła (user ID password attacks) stanowią poważny problem. Przypisywanie certyfikatów (certificate mapping) umożliwia rozwiązanie tego problemu za pomocą technologii klucza publicznego, ponieważ klucze te są lepszym zabezpieczeniem niż systemy korzystające z haseł. W systemie Windows 2000 można przypisywać (map) certyfikat z kluczem publicznym wydany użytkownikowi do konta tego użytkownika. Certyfikat ten może być następnie używany z usługą Internet Information Server (IIS), więc aplikacje serwera do uwierzytelniania użytkownika stosują technologię klucza publicznego (Public Key Technology — PKT). Wynik jest taki sam, jak w przypadku podawania identyfikatora użytkownika (user ID) i hasła, ale proces jest bezpieczniejszy. Wraz z rozbudową systemu i zwiększeniem stopnia rozproszenia, z setkami tysięcy użytkowników, scentralizowany nadzór nad hasłami staje się coraz trudniejszy. Z drugiej strony, certyfikaty z kluczem publicznym mogą być szeroko stosowane, wydawane przez różne instytucje i weryfikowane bez konieczności odwoływania się do centralnej bazy danych. Jednak istniejące obecnie systemy operacyjne i narzędzia administracyjne dotyczą tylko kont, a nie certyfikatów. Rozwiązaniem jest utworzenie skojarzenia (przypisania — mapping), pomiędzy certyfikatem a kontem użytkownika. Umożliwia to systemowi operacyjnemu używanie kont, podczas gdy duże systemy i użytkownicy korzystają z certyfikatów.
W modelu tym użytkownik przedstawia certyfikat, a system sprawdza Odwzorowanie (Mapping) aby określić, na które konto użytkownika zostanie zalogowany. Nie należy tego mylić z logowaniem za pomocą kart elektronicznych (smart card logons), w tym przypadku również odwzorowuje się certyfikaty w sposób niejawny. Przyporządkowanie certyfikatu użytkownikowi systemu Windows 2000 może być wykonane za pomocą usług katalogowych Active Directory lub Internet Information Server (IIS). Usługa IIS korzysta z certyfikatu do uwierzytelnienia użytkownika. Rozwiązana pokrewne zobacz na stronie: Stosowanie zabezpieczeń systemu Windows 2000 z kluczem publicznym Logowanie się za pomocą kart elektronicznych (smart card)
Rodzaje odwzorowywania Certyfikat może być przyporządkowany do konta użytkownika na dwa sposoby: •
do jednego konta użytkownika przypisany jest jeden certyfikat — przyporządkowanie jedendo-jednego (one-to-one mapping),
•
do jednego konta użytkownika przypisanych jest wiele certyfikatów — przyporządkowanie wiele-do-jednego (many-to-one mapping).
Przypisywanie nazw głównych użytkowników (User Principal Name — UPN) Przypisywanie nazw głównych użytkowników (User Principal Name — UPN) jest specjalnym przypadkiem odwzorowania różnowartościowego (one-to-one mapping), którego można dokonać za pomocą usług katalogowych Active Directory. Jednostki certyfikujące przedsiębiorstwa (enterprise CA) umieszczają w każdym certyfikacie pozycję o nazwie Nazwa Główna Użytkownika (User Principal Name), która wygląda podobnie jak adres e-mail. Nazwa UPN jest niepowtarzalna w domenie systemu Windows 2000 i stosowana do znajdowania konta użytkownika w Active Directory. Przyporządkowanie nazw głównych użytkowników (UPN) w systemie Windows 2000 dokonywane jest w sposób niejawny i służy do logowania za pomocą kart elektronicznych (smart cards).
Przyporządkowanie jeden-do-jednego (one-to-one mapping) Odwzorowanie jeden-do-jednego (one-to-one mapping) polega na przypisaniu pojedynczego certyfikatu użytkownika do jednego konta użytkownika. Przyjmijmy, np. że firma chce udostępnić pracownikom stronę sieci Web, aby umożliwić im korzystanie z dokumentów firmowych oraz przesyłanie sprawozdań tygodniowych. Strona ta ma być dostępna przez Internet i zabezpieczona. Firma może wydać certyfikat każdemu pracownikowi za pomocą swoich służb certyfikujących lub korzystając z zatwierdzonych jednostek certyfikujących. Kontom użytkowników systemu Windows 2000 przyporządkowywane są certyfikaty użytkowników. Pracownik może potem łączyć się z daną stroną sieci Web, korzystając z protokołu Secure Sockets Layer (SSL) po przedstawieniu swojego certyfikatu.
Przyporządkowanie wiele-do-jednego (many-to-one mapping) Przyporządkowanie wiele-do-jednego (many-to-one mapping) polega na przypisaniu wielu certyfikatów do jednego konta użytkownika. Przyjmijmy, że korzystamy z usług agencji pośrednictwa pracy, ponieważ nasza firma chce zatrudnić pracowników w niepełnym wymiarze godzin. Personelowi tej agencji należy udostępnić stronę sieci Web, na której zamieszczono bieżące wakaty i do której mają dostęp tylko pracownicy firmy. Agencja ma własną jednostkę certyfikującą (CA), która wydaje certyfikaty jej pracownikom. Po zainstalowaniu certyfikatu głównego jednostki certyfikującej agencji jako zaufanego certyfikatu głównego (trusted root) w przedsiębiorstwie można ustanowić zasadę, aby wszystkie certyfikaty wydane przez daną jednostkę certyfikującą były przypisywane do jednego konta w systemie Windows 2000. Następnie można ustanowić odpowiednie prawa dostępu tak, by z danego konta można było uzyskać dostęp do strony sieci Web. Kiedy kandydaci na pracowników łączą się z serwerem agencji i przedstawiają swoje certyfikaty, są oni przypisywani do tego samego konta użytkownika i w ten sposób mają dostęp do danej firmowej strony sieci Web. Nie mają jednak dostępu do innych stron, ponieważ dla danego konta nie ustawiono takiego prawa. Agencja może wydawać certyfikaty i zarządzać użytkownikami bez konieczności interwencji ze strony administratora w przedsiębiorstwie.
Gdzie dokonywane jest przyporządkowywanie (mapping)? Przyporządkowywanie certyfikatów (certificate mapping) wykonuje się, korzystając z usługi Internet Information Server (IIS) lub usług katalogowych Active Directory.
Internet Information Server (IIS) Podczas przyporządkowywania (mapping) certyfikatu, usługa IIS porównuje go z listą reguł przechowywaną w metabazie (metabase). Usługa Internet Information Server znajduje regułę, która pasuje do wskazywanego konta systemu Windows 2000. Odwzorowywanie dokonywane przez tę usługę jest konfigurowane dla każdego serwera sieci Web i korzysta się z niego, kiedy potrzeba niewielu odwzorowań lub różnych odwzorowań dla każdego z serwera sieci Web. Częściej korzysta się z odwzorowania za pomocą usług Active Directory, ponieważ wymaga ono mniej działań administracyjnych.
Active Directory Kiedy odwzorowanie dokonywane jest przez usługi katalogowe Active Directory, usługa Internet Information Server (IIS) otrzymuje certyfikat użytkownika i przekazuje go do Active Directory, które przypisują certyfikat do konta użytkownika. Odwzorowywanie dokonywane przez usługi katalogowe Active Directory stosuje się, jeśli odwzorowania kont są takie same na wszystkich serwerach IIS. Administrowanie jest uproszczone, ponieważ odwzorowywanie (mapping) dokonywane jest tylko w jednym miejscu. Odwzorowanie jest dokonywane przez Active Directory na dwa sposoby: •
administrator przyporządkowuje certyfikat bezpośrednio do konta użytkownika. Certyfikat ten może być uzyskany z dowolnego źródła, przy założeniu, że jednostka certyfikująca (CA) jest zaufana dla uwierzytelniania klienta (client authentication),
•
stosuje się odwzorowanie nazw głównych użytkowników (UPNs). Certyfikat wydany przez jednostkę certyfikującą przedsiębiorstwa (enterprise CA) zawsze zawiera nazwę główną użytkownika. Dla każdego certyfikatu przekazanego do Active Directory, który ma być odwzorowany, najpierw sprawdza się odwzorowanie nazwy głównej użytkownika. Odwzorowywanie dokonywane jest przez administratora tylko wtedy, gdy niemożliwe jest odwzorowanie nazwy głównej użytkownika (UPN).
Uwaga: Odwzorowywanie nazw głównych użytkownika jest możliwe, jeśli certyfikat zawiera nazwę główną użytkownika, domena jest częścią struktury hierarchicznej Active Directory i jednostka certyfikująca (CA), która wydała dany certyfikat, jest obdarzona zaufaniem w zakresie umieszczania nazw głównych użytkownika w certyfikatach. Jeśli którykolwiek z wymienionych wyżej warunków nie jest spełniony, w katalogu poszukiwane jest przyporządkowanie dokonane przez administratora.
Rozwiązania natychmiastowe Instalowanie certyfikatu użytkownika Pierwszym etapem odwzorowywania (mapping) certyfikatu jest zalogowanie się na konto administratora i zainstalowanie certyfikatu użytkownika. Jeśli ma być dokonane odwzorowanie nazw głównych użytkownika (UPN), certyfikat powinien zostać uzyskany od jednostki certyfikującej przedsiębiorstwa (enterprise CA) z danej domeny. W przypadku innych metod odwzorowywania certyfikat powinien zostać uzyskany od jednostki certyfikującej, która nie należy do przedsiębiorstwa. Gwarantuje to, że nie dojdzie do odwzorowania nazwy głównej użytkownika, gdy certyfikat jest odwzorowywany bezpośrednio do konta użytkownika.
Instalowanie certyfikatu uzyskanego od serwera certyfikatów firmy Microsoft Jeśli certyfikaty uzyskuje się od Serwera Certyfikatów (Certificate Server) firmy Microsoft, to kontroler domeny w danej lokalizacji musi być skonfigurowany jako jednostka certyfikująca (CA). Jej konfigurowanie i potwierdzanie ustawień strony sieci Web opisano w rozdziale 7.
Rozwiązania pokrewne zobacz na stronie: Konfigurowanie jednostki certyfikującej Żądanie certyfikatu można wysłać na dwa sposoby: •
korzystając z programu Internet Explorer do połączenia się z stroną rejestrowania sieci Web (Web enrollment page),
•
korzystając z modułu dodatkowego (snap-in) Certyfikaty (Certificates) konsoli MMC do wysłania żądania certyfikatu od Usługi Certyfikatów (Certificate Services) firmy Microsoft.
Firma Microsoft zaleca stosowanie pierwszej z wymienionych metod, którą poniżej opisano. Jeśli uzyskano już certyfikat, postępując zgodnie z procedurami opisanymi w rozdziale 7., można pominąć poniższą procedurę. Procedura wysyłania żądania certyfikatu za pomocą Strony Rejestrowania (Enrollment Page) wymaga, aby: 1.
Uruchomić przeglądarkę i połączyć się ze stroną o adresie http://ServerName/CertSrv, gdzie ServerName jest nazwą serwera jednostki certyfikującej (CA server) w danej domenie. Pojawi się ekran powitalny Usługi Certyfikatów Firmy Microsoft (Microsoft Certificate Services).
2.
Wybrać opcję Żądanie Certyfikatu (Request a Certificate). Nacisnąć przycisk Dalej (Next).
3.
Wybrać opcję Żądanie Certyfikatu Użytkownika (User Certificate Request) i w polu listy zaznaczyć pozycję Certyfikat Użytkownika (User Certificate). Naciśnij przycisk Dalej.
4.
W przypadku połączenia z autonomiczną jednostką certyfikującą (standalone CA) pojawi się strona Certyfikat Użytkownika — Informacja Identyfikacyjna (User Certificate — Identifying Information). Należy wówczas wypełnić formularz w trybie online i nacisnąć przycisk Dalej. W przypadku połączenia z jednostką certyfikującą przedsiębiorstwa (enterprise CA) dane zostaną pobrane z Active Directory i pojawi się monit o wysłanie żądania.
5.
Nacisnąć przycisk Wyślij (Submit). Na podstawie podanych informacji program wygeneruje parę kluczy prywatnych i żądanie certyfikatu oraz wyśle żądanie do jednostki certyfikującej.
6.
Jeśli jednostka certyfikująca jest skonfigurowana w ten sposób, że zatwierdza żądania automatycznie, zostanie wydany nowy certyfikat. W tym przypadku należy zaznaczyć połączenie (link) Instaluj ten certyfikat (Install this certificate) i zostanie on zainstalowany. Jeśli jednostka certyfikująca wymaga przed wydaniem certyfikatu zatwierdzenia przez administratora, pojawi się okno Certyfikat Oczekujący (Certificate Pending). Teraz należy przejść do następnej procedury.
Zakończenie obsługi żądań oczekujących Procedura ta pozwala na zakończenie obsługi żądania certyfikatu, które wymaga zatwierdzenia przez administratora. Należy zwrócić uwagę, że poniższą procedurę wykonuje się tylko wtedy, gdy jednostka certyfikująca została skonfigurowana w ten sposób, że przed wydaniem certyfikatu wymagane jest zatwierdzenie przez administratora oraz po pojawieniu się komunikatu o certyfikacie oczekującym (certificate pending), kończącym procedurę opisaną powyżej. 1.
Uruchom przeglądarkę i połącz się ze stroną o adresie http://ServerName/CertSrv. Pojawi się ekran powitalny Usługi Certyfikatów Firmy Microsoft. Zaznacz opcję Sprawdzenie Certyfikatów Oczekujących (Check On a Pending Certificate) i naciśnij przycisk Dalej.
2.
W polu listy pojawią się zatwierdzone żądania certyfikatów. Wybierz jedno i naciśnij przycisk Dalej (Next).
3.
Kliknij łącze (link) Instalowanie niniejszego certyfikatu (Install this certificate).
4.
Certyfikat został zainstalowany. Aby zamknąć okno z komunikatem potwierdzającym, naciśnij przycisk OK.
Instalowanie certyfikatu uzyskanego od komercyjnej jednostki certyfikującej Zamiast korzystania z Serwera Certyfikatów (Certificate Server) firmy Microsoft można podjąć decyzję o zainstalowaniu certyfikatu uzyskanego od komercyjnej jednostki certyfikującej (commercial CA), takiej jak VeriSign. Można to zrobić, jeśli w domenie nie ma zainstalowanego serwera jednostki certyfikującej (CA server) lub jeśli istnieje jednostka certyfikująca przedsiębiorstwa (enterprise CA), a administrator chce zainstalować certyfikat autonomicznej jednostki certyfikującej (standalone CA), aby można było bezpośrednio przypisać certyfikat do konta użytkownika.
OSTRZEŻENIE! Zależnie od wybranej jednostki certyfikującej zamieszczona poniżej procedura może ulegać niewielkim modyfikacjom. Zazwyczaj strony internetowe komercyjnej jednostki certyfikującej (commercial CA) zawierają informacje pomocnicze dotyczące instalowania certyfikatów.
Poniżej zamieszczono procedurę wysyłania żądań do komercyjnej jednostki certyfikującej oraz instalowania otrzymanych certyfikatów: 1.
Połącz się ze stroną sieci Web komercyjnej jednostki certyfikującej (CA), np. www.verisign.com.
2.
Naciśnij przycisk służący do uzyskania certyfikatu lub identyfikatora cyfrowego (digital ID). Będzie na nim napis Certyfikaty Indywidualne (Individual Certificates).
3.
Jeśli znajdujesz się w Stanach Zjednoczonych możesz przygotować żądanie certyfikatu. W przeciwnym razie, aby uzyskać dostęp do usługodawcy, wybierz na stronie sieci Web łącze Międzynarodowy (International). Zgodnie z ograniczeniami nałożonymi przez rząd Stanów Zjednoczonych certyfikaty uzyskane od usługodawców międzynarodowych mogą mieć ograniczoną siłę szyfrowania (encryption strength).
Uwaga: Niektórzy dostawcy komercyjni proszą o wybranie lokalizacji z listy rozwijalnej zamiast włączania połączenia międzynarodowego (International).
4.
Zaznacz połączenie Certyfikaty Osobiste (Personal Certificates).
5.
Pojawi się informacja o tym, że żądasz dokumentu zabezpieczonego. Naciśnij przycisk Kontynuuj (Continue).
6.
Wypełnij Formularz Rejestrowania (Enrollment Form), przeczytaj umowę, a potem naciśnij Akceptuj (Accept).
7.
Aby potwierdzić adres poczty elektronicznej, naciśnij przycisk OK.
8.
Wprowadź hasło, a następnie naciśnij OK.
9.
Sprawdź swoją pocztę elektroniczną. Skopiuj swój numer PIN.
10. Kliknij łącze (link) podane w wiadomości e-mail. Zazwyczaj następuje powrót do strony z monitem o sprawdzenie poczty elektronicznej. Wybierz łącze, które umożliwi wprowadzenie twojego numeru PIN. 11. Wstaw swój PIN w wyświetlone pole i naciśnij OK. 12. Kliknij Zapisz jako (Save as). Możesz zapisać dany certyfikat na dyskietce, aby mieć kopię zapasową, ale przechowuj ją w miejscu zabezpieczonym. 13. Aby zainstalować certyfikat, potwierdź przyciskiem OK.
Eksportowanie certyfikatu Następnym krokiem po zainstalowaniu certyfikatu użytkownika jest jego wyeksportowanie. Poniżej opisano tę procedurę: 1.
Z menu Start wybierz pozycję Uruchom (Run) i wpisz mmc.
2.
Z listy rozwijalnej Konsola (Console) wybierz pozycję Dodaj/Usuń przystawkę (Add/Remove snap-in).
3.
Naciśnij przycisk Dodaj (Add).
4.
Zaznacz Certyfikaty (Certificates), a następnie naciśnij Dodaj.
5.
Wybierz Moje Konto Użytkownika (My User Account), a potem naciśnij przycisk Zakończ (Finish).
6.
Aby zamknąć okno dialogowe Dodawanie Przystawki Autonomicznej (Add Standalone Snapin), naciśnij przycisk Zamknij (Close).
7.
Aby zamknąć okno dialogowe Dodaj/Usuń przystawkę, naciśnij przycisk OK.
8.
Wybierz pozycję Certyfikaty — Bieżący Użytkownik (Certificates — Current User).
9.
Wybierz pozycję Widok|Opcje (View\Options) i upewnij się, czy wybrano opcję Logiczne Magazyny Certyfikatów (Logical Certificate Stores), jak przedstawiono to na rysunku 8.1. Naciśnij przycisk OK.
10. Rozwiń gałąź Certyfikaty — Bieżący Użytkownik|Osobiste (Certificates — Current Cser\Personal). 11. Otwórz kontener Certyfikaty (Certificates). 12. Prawym przyciskiem myszki zaznacz certyfikat wydany dla twojego konta. Nie wybieraj certyfikatu odzyskiwania plików (file recovery certificate). 13. Z menu wybierz pozycję Wszystkie zadania (All tasks), jak przedstawiono to na rysunku 8.2. Kliknij opcję Eksportuj (Export). 14. Uruchomiony zostanie Kreator Eksportu Certyfikatów (Export Certificate Wizard). Naciśnij przycisk Dalej (Next). 15. Wybierz opcję Nie eksportuj klucza prywatnego (No, do not export the private key), a następnie naciśnij przycisk Dalej.
Uwaga: Jest to opcja bardziej bezpieczna. Im mniej kopii twojego klucza prywatnego, tym lepiej. Nie oznacza to jednak, że wszystkie procedury opisane w niniejszym rozdziale muszą być uruchamiane z komputera, na którym zainstalowano twój certyfikat.
Rysunek 8.1. Okno dialogowe Opcje Widoku (View Options)
Rysunek 8.2. Eksportowanie certyfikatu 16. Wybierz opcję Zaszyfrowane Base64 X.509 (Base64 Encode X.509). Naciśnij przycisk Dalej. 17. Wpisz nazwę pliku, np. my-base64-cert i naciśnij przycisk Dalej. 18. Sprawdź, czy wszystkie ustawienia są prawidłowe, po czym naciśnij Zakończ (Finish). 19. Aby zamknąć okno dialogowe, naciśnij przycisk OK. Zamknij moduł dodatkowy (snap-in) konsoli MMC.
Instalowanie certyfikatu jednostki certyfikującej Jeśli stosowany jest certyfikat uzyskany od jednostki certyfikującej przedsiębiorstwa (enterprise CA) w danej domenie można pominąć tę procedurę, ponieważ certyfikat główny (root certificate) jest zaufany w danym systemie. Jeśli korzysta się z innej jednostki certyfikującej (CA) konieczne jest zainstalowanie głównej jednostki certyfikującej (root CA) i wszystkich pośredniczących certyfikatów głównych (intermediate roots) w magazynie (store) komputera, który jest serwerem sieci Web. Jest to konieczne, aby usługa Internet Information Server (IIS) mogła zweryfikować certyfikat klienta (client certificate). W rozdziale 7. opisano procedurę konfigurowania domeny poprzez edytowanie obiektu zasad grupy (GPO) domyślne zasady domeny (default domain policy) w ten sposób, by ufać zewnętrznej jednostce certyfikującej (CA). Poniżej opisano alternatywny sposób instalowania głównej jednostki certyfikującej, rozpoczynając od certyfikatu zewnętrznej jednostki certyfikującej, który może być zapisany, np. na dyskietce. Rozwiązania pokrewne zobacz na stronie: Konfigurowanie relacji zaufania pomiędzy domeną a zewnętrzną jednostką certyfikującą (external CA) Oto procedura instalowania certyfikatu jednostki certyfikującej (CA certificate): 1.
Zaloguj się jako administrator.
Wskazówka: Jeśli korzysta się z certyfikatu uzyskanego od jednostki certyfikującej w danej domenie i wyeksportuje się go bez klucza prywatnego, jak opisano to w części „Eksportowanie certyfikatu”, konieczne jest wykonanie odpowiedniej procedury odwzorowania (mapping) na
komputerze, na którym zainstalowano ten certyfikat. W sytuacjach, w których instaluje się certyfikat uzyskany od zewnętrznej jednostki certyfikującej i zapisany, np. na dyskietce, można zainstalować go na dowolnie wybranym komputerze. Procedury opisane w dalszej części niniejszego rozdziału będą działały szybciej, jeśli administrator zaloguje się do serwera sieci Web.
OSTRZEŻENIE! W niniejszym rozdziale zamiast określenia „komputer, na którym działa usługa Internet Information Server (IIS — IIS computer)” używane jest określenie „serwer sieci Web (Web server)”. Jest to ważne rozróżnienie. Na komputerze, który jest serwerem sieci Web może oczywiście działać usługa IIS, ale w sieci mogą znajdować się inne komputery, na których ona działa, a które zapewniają usługi intranetowe. Odwzorowanie (Mapping) certyfikatów wykonuje się na komputerze z zainstalowaną usługą IIS, który łączy się z siecią Web, tzn. na serwerze sieci Web.
2.
Uruchom Eksploratora Windows (Windows Explorer). Kliknij dwukrotnie plik certyfikatu jednostki certyfikującej (CA). Uruchomiony zostanie Kreator Importu Certyfikatu (Certificate Import Wizard). Naciśnij przycisk Dalej (Next).
3.
W oknie dialogowym Import Pliku (File To Import) pojawi się nazwa wybranego pliku. Jeśli wybrałeś zły plik, można to jeszcze zmienić. Następnie naciśnij przycisk Dalej.
4.
Wprowadź hasło i zaznacz opcję Oznacz klucz prywatny jako możliwy do eksportu (Mark the private key as exportable), a następnie naciśnij przycisk Dalej.
5.
Wybierz opcję Umieść wszystkie certyfikaty w następującym magazynie (Place all certificates into the following store). Naciśnij przycisk Przeglądaj (Browse). Pojawi się okno dialogowe Wybieranie Magazynu Certyfikatów (Select Certificate Store), które przedstawiono na rysunku 8.3.
Wskazówka: W przypadku wybrania opcji Automatycznie wybierz magazyn certyfikatów na podstawie typu certyfikatu (Automatically select the certificate store based on the type of certificate) certyfikaty jednostek certyfikujących (CAs) są umieszczane w magazynie użytkownika (user store) zamiast w magazynie komputera (machine store). Jeśli tak się stanie, należy użyć przystawki (snap-in) Certyfikaty (Certificates) konsoli MMC oraz przenieść certyfikat główny (root certificate) i wszystkie pośredniczące certyfikaty główne (intermediate roots) z magazynu (store) certyfikatów Osobiste (Personal) do magazynu certyfikatów Zaufane Główne Jednostki Certyfikujące (Trusted Root Certification Authority).
6.
Zaznacz opcję Pokaż Magazyny Fizyczne (Show Physical Stores).
7.
Rozwiń gałąź Zaufane Główne Jednostki Certyfikujące.
8.
Wybierz pozycję Komputer Lokalny (Local Computer), a następnie naciśnij przycisk OK.
9.
Nastąpi powrót do strony Magazyn Certyfikatów (Certificate Store) Kreatora Importu Certyfikatów (Certificate Import Wizard). Naciśnij przycisk Dalej.
10. Sprawdź podane ustawienia, a potem naciśnij Zakończ (Finish). 11. Aby zamknąć okno dialogowe, naciśnij przycisk OK. Zamknij Eksploratora systemu Windows (Windows Explorer).
Uwaga: Niektóre certyfikaty uzyskane od niezależnych jednostek certyfikujących (third-party CA) będą w strukturze hierarchicznej, w której główna jednostka certyfikująca (root CA) i wiele pośredniczących (intermediate) znajdują się powyżej certyfikatu użytkownika.
Rysunek 8.3. Wybór magazynu (store) certyfikatów
Konfigurowanie Active Directory, aby można było przypisywać nazwy główne użytkownika (User Principal Name — UPN) Kiedy usługi katalogowe Active Directory wykonują Odwzorowanie (Mapping), usługa Internet Information Server (IIS) otrzymuje certyfikat od użytkownika i przekazuje go do usług katalogowych Active Directory, który przypisuje (maps) ten certyfikat do konta użytkownika systemu Windows 2000. Usługi katalogowe Active Directory można skonfigurować w ten sposób, by przyporządkowywane były nazwy główne użytkowników (User Principal Name mapping) lub, aby przyporządkowanie wykonywane było przez administratora w sposób jawny. Poniżej opisano
przyporządkowywanie nazwy głównej użytkownika, które odwzorowuje certyfikat uzyskany od jednostki certyfikującej przedsiębiorstwa (enterprise CA). Rozwiązania pokrewne zobacz na stronie: Konfigurowanie jednostki certyfikującej
Uwaga: Większość procedur zamieszczonych w pozostałej części niniejszego rozdziału wyklucza się wzajemnie. Nie można jednocześnie skonfigurować odwzorowywania przez usługi katalogowe Active Directory i usługę internet Information Server (IIS). Nie można także skonfigurować usług katalogowych Active Directory, aby jednocześnie wykonywane było przyporządkowanie nazwy głównej użytkownika (UPN mapping) i przyporządkowanie jawne (explicit mapping).
1.
Z menu Start|Programy|Narzędzia administracyjne (Start\Programs\Administrative tools) wybierz pozycję Menedżer Usług Internetowych (Internet Services Manager). Uruchomiona zostanie przystawka (snap-in) IIS konsoli MMC. Prawym przyciskiem myszki wybierz nazwę serwera sieci Web (Web server) i z menu wybierz opcję Właściwości (Properties).
2.
Kliknij przycisk Edytuj (Edit) znajdujący się w części okna Właściwości Główne (Master Properties). Pojawi się okno Usługa WWW Właściwości Główne (WWW Service Master Properties), z którego wybierz zakładkę Zabezpieczenia Usługi Active Directory (Directory Security).
3.
Zaznacz opcję Włącz przyporządkowywanie za pomocą usług katalogowych systemu Windows (Enable the Windows directory service mapper). Wtedy usługa IIS korzysta z odwzorowania przez usługi katalogowe Active Directory (Active Directory mapping). Jeśli opcja ta nie jest wybrana, przyporządkowanie wykonywane jest przez usługę IIS (IIS mapping). Powinien pojawić się ekran podobny do przedstawionego na rysunku 8.4.
Rysunek 8.4. Uaktywnienie odwzorowywania przez Active Directory (Active Directory mapping) 4.
Naciśnij przycisk OK. Nastąpi powrót do okna Serwer Sieci Web Właściwości (Web Server Properties). Aby powrócić do przystawki (snap-in) IIS konsoli MMC, naciśnij przycisk OK.
Instalowanie certyfikatu serwera sieci Web Kolejnym krokiem jest zainstalowanie Certyfikatu Serwera Sieci Web. Po jego zainstalowaniu można skonfigurować protokół SSL i ustawić poziom zabezpieczeń konieczny do odwzorowywania certyfikatów.
5.
W oknie przystawki IIS konsoli MMC rozwiń gałąź Serwer Sieci Web (Web Server), a następnie prawym przyciskiem myszki kliknij pozycję Domyślna Witryna Sieci Web (Default Web Site). Z menu wybierz pozycję Właściwości (Properties).
6.
Wybierz zakładkę Zabezpieczenia Katalogu. Powinno pojawić się okno dialogowe podobne do przedstawionego na rysunku 8.5. Zwróć uwagę, że przycisk Edytuj w polu Komunikacja Bezpieczna (Secure Communications) jest nieaktywny. Pozostanie tak, dopóki nie zainstalujesz Certyfikatu Serwera Sieci Web.
7.
Naciśnij przycisk Certyfikat Serwera (Server Certificate). Uruchomiony zostanie Kreator Certyfikatu Serwera Sieci Web (Web Server Certificate Wizard).
8.
Naciśnij przycisk Dalej (Next).
9.
Wybierz opcję Utwórz Nowy Certyfikat (Create a New Certificate). Naciśnij przycisk Dalej.
10. Włącz pozycję Natychmiast wyślij żądanie do jednostki certyfikującej, pracującej w trybie online (Send the request immediately to an online certification authority) i naciśnij Dalej.
Rysunek 8.5. Zablokowane konfigurowanie komunikacji bezpiecznej
11. Wpisz nazwę nowego certyfikatu, np. mapcert. Potwierdź wartości domyślne zamieszczone w oknie dialogowym. Naciśnij przycisk Dalej. 12. Wpisz nazwę twojego przedsiębiorstwa i jednostki organizacyjnej. Naciśnij Dalej. 13. W oknie przeglądarki wpisz nazwę serwera sieci Web. Może to być nazwa DNS, NetBIOS lub LOCALHOST (jeśli jesteś zalogowany na serwerze sieci Web). Znów naciśnij Dalej. 14. W oknie Dane Geograficzne (Geographical Information) wpisz odpowiednie dane i zaznacz Dalej. 15. Z przedstawionej listy wybierz Certyfikat Serwera Sieci Web. O ile w twojej domenie nie ma kilku jednostek certyfikujących (CAs), wymieniona wyżej lista zawiera tylko jedną pozycję. Naciśnij przycisk Dalej.
Uwaga: Jeśli lista jest pusta, oznacza to, że w danej domenie nie ma jednostki certyfikującej przedsiębiorstwa (enterprise CA). Dana jednostka certyfikująca (CA) nie jest skonfigurowana, aby wydawać certyfikaty serwera sieci Web lub dany użytkownik nie ma uprawnień do żądania takiego certyfikatu. W tym przypadku należy wrócić do rozdziału 7.
16. Powinna pojawić się strona Przesyłanie Żądania Certyfikatu (Certificate Request Submission), podobna do przedstawionej na rysunku 8.6. Naciśnij przycisk Dalej. 17. Aby zakończyć działanie kreatora certyfikatu serwera sieci, kliknij Zakończ (Finish). Serwer ma teraz Certyfikat Serwera Sieci Web. Nastąpi powrót do zakładki Zabezpieczenia Katalogu okna Domyślna Witryna Sieci Web Właściwości (Default Web Site Properties).
Rysunek 8.6. Strona Przesłanie Żądania Certyfikatu (Certificate Request Submission)
Konfigurowanie protokołu Secure Sockets Layer Po zainstalowaniu Certyfikatu Serwera Sieci Web można skonfigurować protokół Secure Sockets Layer (SSL) i jednocześnie ustawić poziom zabezpieczeń konieczny dla odwzorowywania certyfikatów. 18. W oknie Domyślna Witryna Sieci Web Właściwości, na stronie zakładki Zabezpieczenia Katalogu przycisk Edytuj (Edit) znajdujący się w polu Komunikacja Bezpieczna (Secure Communications) jest uaktywniony, co przedstawiono na rysunku 8.7. Naciśnij go.
Rysunek 8.7. Uaktywniony przycisk Edytuj (Edit) w polu Komunikacja Bezpieczna (Secure Communications) 19. Pojawi się okno dialogowe Komunikacja Bezpieczna (Secure Communications), które służy do skonfigurowania odwzorowywania kont i protokołu SSL. Wykonaj następujące czynności: •
zaznacz opcję Włącz Przyporządkowywanie Certyfikatu Klienta (Enable Client Certificate Mapping),
•
wybierz opcję Akceptuj Certyfikaty Klientów (Accept Client Certificates) lub opcję Wymagaj Certyfikatów Klientów (Require Client Certificates). Opcja Akceptuj Certyfikaty Klientów oznacza, że negocjacje dotyczące uwierzytelniania certyfikatu klienta będą przeprowadzane w przeglądarce (Browser). Jeśli nie powiodą się, nastąpi powrót do jednego ze standardowych protokołów uwierzytelniania,
•
jeśli chcesz zaznaczyć opcję Wymagaj Certyfikatów Klienta najpierw trzeba zaznaczyć pozycję Wymagaj Kanału Bezpiecznego (Require Secure Channel (SSL)). W tym przypadku nie nastąpi powrót do innych sposobów uwierzytelniania. Żądanie Kanału
Bezpiecznego (Secure Channel) oznacza, że dana witryna sieci Web będzie widoczna za pomocą protokołu HTTPs, •
nie zaznaczaj opcji Włącz Listę Zaufań Certyfikatów (Enable Certificate Trust List), która dotyczy odwzorowywania nazw głównych użytkowników (UPN),
•
zaznacz opcję Wymagaj Szyfrowania 128-bitowego (Require 128-bit Encryption), jeśli jesteś pewien, że takie szyfrowanie jest obsługiwane. Zauważ, że opcję tę można wybrać tylko wtedy, jeśli zaznaczona jest opcja Wymagaj Kanału Bezpiecznego (SSL).
OSTRZEŻENIE! Obecnie oprogramowanie umożliwia konfigurowanie szyfrowania 128bitowego nawet, jeśli dany certyfikat czy system operacyjny nie obsługują takiego szyfrowania. W razie wątpliwości nie zaznaczaj opcji Wymagaj Szyfrowania 128-bitowego (Require 128-bit Encryption).
20. Po skonfigurowaniu okna dialogowego Komunikacja Bezpieczna (Secure Communications), jak przedstawiono na rysunku 8.8, naciśnij przycisk OK.
Rysunek 8.8. Konfigurowanie komunikacji bezpiecznej
21. Aby zamknąć okno dialogowe Domyślna Witryna Sieci Web Właściwości, naciśnij przycisk OK. W oknie dialogowym Zastępowanie Dziedziczenia (Inheritance Overrides) wybierz Zaznacz wszystko (Aelect all), a następnie naciśnij OK. Zamknij przystawkę konsoli MMC. Teraz można przejść bezpośrednio do procedury „Testowanie odwzorowania”.
Konfigurowanie Active Directory, aby stosować odwzorowanie różnowartościowe (one-to-one mapping) Jeśli procedura opisana w poprzednim podrozdziale została wykonana poprawnie, to nie jest konieczne wykonywanie poniższej procedury ani żadnych innych procedur odwzorowywania (mapping procedures), zamieszczonych w niniejszym rozdziale i można przejść bezpośrednio do podrozdziału „Testowanie odwzorowania”. Jeśli jednak nie uzyskano certyfikatu od jednostki certyfikującej przedsiębiorstwa (enterprise CA) i jeśli ma być zastosowane odwzorowanie jeden-do-jednego (one-to-one mapping) w Active Directory, należy postępować zgodnie z poniższą procedurą: 1.
Uruchom przystawkę (snap-in) Active Directory Użytkownicy i Komputery (AD Users and Computers).
2.
W menu Widok (View) wybierz pozycję Właściwości Zaawansowane (Advanced Features), o ile nie jest już wybrana.
3.
Kliknij dwukrotnie nazwę domeny i otwórz kontener Użytkownicy (Users).
4.
Prawym przyciskiem myszki zaznacz konto Administrator i z menu wybierz pozycję Mapowania Nazw (Name Mappings), jak przedstawiono to na rysunku 8.9. Pojawi się okno dialogowe Mapowanie Tożsamości Zabezpieczeń (Security Identity Mapping).
5.
Naciśnij przycisk Dodaj (Add). Wybierz certyfikat użytkownika z pliku CER zapisanego za pomocą procedury Eksportowanie Certyfikatu.
6.
Naciśnij przycisk Otwórz (Open). Pojawi się okno dialogowe Dodaj Certyfikat (Add Certificate).
7.
Upewnij się, czy zaznaczone są opcje Użyj wystawcy do alternatywnej tożsamości zabezpieczeń (Use issuer for alternate security identity) oraz Użyj tematu dla alternatywnej tożsamości zabezpieczeń (Use subject for alternate security identity), które powinny być zaznaczone domyślnie. Zagwarantuje to, że wprowadzone będzie odwzorowanie jeden-do-
jednego (one-to-one mapping). Jeśli którakolwiek z tych opcji nie zostanie wybrana, zastosowane zostanie odwzorowanie wiele-do-jednego (many-to-one mapping). 8.
Naciśnij przycisk OK. Aby zamknąć okno dialogowe Mapowanie Tożsamości Zabezpieczeń (Security Identity Mapping), kolejny raz naciśnij OK. Zamknij przystawkę (snap-in) konsoli MMC.
Zakończona została procedura konfigurowania przyporządkowania jeden-do-jednego Active Directory i można przejść bezpośrednio do podrozdziału „Testowanie odwzorowania”, zamieszczonego w dalszej części niniejszego rozdziału.
Rysunek 8.9. Odwzorowywanie (mapping) konta Administrator
Konfigurowanie usługi Internet Information Server (IIS) dla stosowania odwzorowania jeden-do-jednego (one-to-one mapping) Zamiast Active Directory do przechowywania odwzorowań (mappings) można użyć usługi Internet Information Server (IIS). Jeśli skonfigurowano odwzorowywanie w inny sposób, można pominąć poniższą procedurę. 1.
W oknie przystawki (snap-in) IIS konsoli MMC prawym przyciskiem myszki kliknij serwer IIS, z menu wybierz opcję Właściwości (Properties), a następnie, w części Usługa WWW Właściwości Główne (WWW Service Master Properties), naciśnij przycisk Edytuj (Edit).
2.
W oknie dialogowym Usługa WWW Właściwości Główne wybierz zakładkę Zabezpieczenia Katalogu (Directory Security) i upewnij się, czy opcja Włącz przyporządkowywanie za pomocą usług katalogowych systemu Windows (Enable the Windows directory service mapper) pozostaje niezaznaczona, jak przedstawiono to na rysunku 8.10. Zaznacz OK. Aby powrócić do przystawki IIS konsoli MMC, ponownie naciśnij OK.
3.
Z przystawki IIS konsoli MMC przejdź do zakładki Zabezpieczenia Katalogu strony Domyślna Witryna Sieci Web Właściwości (Default Web Site Properties). Przycisk Edytuj (Edit) w polu Komunikacja Bezpieczna (Secure Communications) powinien być uaktywniony, ponieważ odwzorowywanie przez usługi Active Directory (Active Directory mapping) jest wyłączone. Naciśnij ten przycisk.
4.
Ponownie naciśnij przycisk Edytuj (Edit), który znajduje się w części Włącz Przyporządkowywanie Certyfikatu Klienta (Enable Client Certificate Mapping) okna dialogowego Komunikacja Bezpieczna.
5.
Wybierz Dodaj (Add) znajdujący się w zakładce odwzorowania jeden-do-jednego okna dialogowego Przyporządkowywanie Kont (Accounts Mapping).
6.
Wybierz certyfikat użytkownika, jak przedstawiono to na rysunku 8.11. Naciśnij przycisk Otwórz (Open).
Rysunek 8.10. Uaktywnianie odwzorowywania przez usługę IIS
Rysunek 8.11. Wybieranie certyfikatu w formacie base64
Wskazówka: W przypadku odwzorowywania przez usługę IIS (IIS mapping), certyfikat musi być w formacie base64 (base64-encoded) i nie może być certyfikatem binarnym. Z tej przyczyny podczas eksportowania certyfikatu, według procedury zamieszczonej w niniejszym rozdziale, wybrano odpowiednią opcję kodowania.
7.
W oknie dialogowym Przyporządkuj Konto (Map To Account) naciśnij przycisk Przeglądaj (Browse) i dodaj konto Administrator. Naciśnij przycisk OK.
8.
Wprowadź hasło. Naciśnij OK. Potwierdź hasło i znów OK.
9.
Aby zamknąć okno dialogowe Mapowania Kont naciśnij przycisk OK. W kolejnych oknach dialogowych naciskaj OK, dopóki nie powrócisz do przystawki IIS. Zamknij ją.
Zakończona została procedura konfigurowania przyporządkowania jeden-do-jednego (one-to-one mapping) usługi IIS i można przejść bezpośrednio do podrozdziału „Testowanie odwzorowania”, zamieszczonego w dalszej części niniejszego rozdziału.
Konfigurowanie Active Directory, aby stosować odwzorowanie wiele-do-jednego (many-to-one mapping) Usługi katalogowe Active Directory można skonfigurować w ten sposób, aby zapisane było odwzorowanie wiele-do-jednego (many-to-one mapping). Jeśli skonfigurowano odwzorowywanie (mapping) w inny sposób, można pominąć poniższą procedurę. 1.
W oknie przystawki (snap-in) IIS konsoli MMC prawym przyciskiem myszki kliknij serwer IIS, z menu wybierz opcję Właściwości (Properties), a następnie w części Usługa WWW Właściwości Główne (WWW Service Master Properties) naciśnij przycisk Edytuj (Edit).
2.
W oknie dialogowym Usługa WWW Właściwości Główne wybierz zakładkę Zabezpieczenia Katalogu (Directory Security) i upewnij się, czy zaznaczono opcję Włącz przyporządkowywanie za pomocą usług katalogowych systemu Windows (Enable the Windows directory service mapper), jak przedstawiono to na rysunku 8.4. Dwukrotnie naciśnij przycisk OK i zamknij przystawkę.
3.
Uruchom przystawkę Active Directory Użytkownicy i Komputery (AD Users and Computers).
4.
W menu Widok (View) zaznacz opcję Zaawansowane Właściwości (Advanced Features), o ile nie jest jeszcze wybrana.
5.
Prawym przyciskiem myszki wybierz konto Administrator, a z menu — opcję Mapowania Nazw (Name Mappings).
6.
Naciśnij przycisk Dodaj (Add). Wybierz certyfikat użytkownika z pliku CER, który zapisano za pomocą procedury Eksportowanie Certyfikatu. Naciśnij Otwórz (Open).
7.
Usuń zaznaczenie opcji Użyj tematu dla alternatywnej tożsamości zabezpieczeń (Use subject for alternate security identity). Zagwarantuje to, że pozostawienie odwzorowania wiele-dojednego (many-to-one mapping) oraz że usługi katalogowe Active Directory zostały skonfigurowane w ten sposób, że wszystkie certyfikaty uzyskane od jednostek certyfikujących wydających certyfikaty (issuing CA) będą przypisane (map) do konta Administrator. Naciśnij przycisk OK. Jeśli pojawi się okno z komunikatem ostrzegawczym, aby je zamknąć, naciśnij przycisk Tak (Yes). Kolejny raz potwierdź OK i zamknij przystawkę konsoli MMC.
Teraz można przejść bezpośrednio do podrozdziału „Testowanie odwzorowania”, zamieszczonego w dalszej części niniejszego rozdziału.
Konfigurowanie usługi Internet Information Server (IIS), w celu stosowania odwzorowania wiele do jednego (many-toone mapping) Usługę Internet Information Server można skonfigurować w ten sposób, aby zapisane było odwzorowanie wiele-do-jednego. Jeśli skonfigurowano odwzorowywanie (mapping) w inny sposób, można pominąć poniższą procedurę. 1.
W oknie przystawki (snap-in) IIS konsoli MMC prawym przyciskiem myszki kliknij serwer IIS, z menu wybierz opcję Właściwości (Properties), a następnie, w części Usługa WWW Właściwości Główne (WWW Service Master Properties), naciśnij przycisk Edytuj (Edit).
2.
W oknie dialogowym Usługa WWW Właściwości Główne wybierz zakładkę Zabezpieczenia Katalogu (Directory Security) i upewnij się, czy opcja Włącz przyporządkowywanie za pomocą usług katalogowych systemu Windows (Enable the Windows directory service mapper) pozostaje niezaznaczona, jak przedstawiono to na rysunku 8.10. Naciśnij przycisk OK. Aby powrócić do przystawki IIS konsoli MMC, ponownie naciśnij OK.
3.
Z przystawki IIS konsoli MMC przejdź do zakładki Zabezpieczenia Katalogu (Directory Security) strony Domyślna Witryna Sieci Web Właściwości (Default Web Site Properties). Przycisk Edytuj w polu Komunikacja Bezpieczna (Secure Communications) powinien być uaktywniony, ponieważ odwzorowywanie przez usługi Active Directory (Active Directory mapping) jest wyłączone. Naciśnij ten przycisk.
4.
Wybierz Edytuj, znajdujący się w części Włącz Przyporządkowywanie Certyfikatu Klienta (Enable Client Certificate Mapping) okna dialogowego Komunikacja Bezpieczna.
5.
Naciśnij przycisk Dodaj (Add) znajdujący się w zakładce Wiele-do-jednego (Many-to-one).
6.
Pojawi się okno dialogowe Reguła Symboli Wieloznacznych (Wildcard Rule). Naciśnij przycisk Dalej (Next).
7.
Pojawi się okno dialogowe Reguły (Rules) i włącz Nowy (New).
8.
W oknie dialogowym Edytuj Człon Reguły (Edit Rule Element) wartość w polu Pole Niższego Rzędu (Sub Field) ustaw na CN i w polu Kryteria (Criteria) określ nazwę jednostki certyfikującej wydającej certyfikaty (issuing CA). W przykładzie zamieszczonym na rysunku 8.12. wpisano nazwę extcertCA. Jest to certyfikat uzyskany od zewnętrznej jednostki certyfikującej i zainstalowany w katalogu komputera, który jest serwerem sieci Web. Oznacza to, że wszystkie certyfikaty wydane przez tę jednostkę certyfikującą będą odwzorowywane. Naciśnij przycisk OK.
Wskazówka: Przy odwzorowywaniu przez usługę IIS nie wolno wpisywać ciągów znaków, zawierających znaki w standardzie Unicode, ponieważ spowoduje to błędne działanie (dotyczy to pól zawierających znak @). Należy wybierać tylko pola zawierające ciągi znaków, które można wydrukować (printable strings).
9.
W oknie dialogowym Reguły (Rules) naciśnij przycisk Dalej. Pojawi się okno dialogowe Odwzorowanie (Mapping).
Rysunek 8.12. Określenie Nazwy Uniwersalnej (Common Name — CN) jednostki certyfikującej (CA) 10. Naciśnij przycisk Przeglądaj (Browse) i wybierz konto Administrator. Włącz Dodaj (add), naciśnij OK. a potem Zakończ (Finish). 11. Aby zamknąć okna dialogowe, naciśnij przycisk OK i zamknij przystawkę konsoli MMC. Teraz można przejść do podrozdziału „Testowanie odwzorowania”, zamieszczonego poniżej i sprawdzić, czy certyfikaty wydane przez podaną jednostkę certyfikującą pozwalają na uzyskanie dostępu do danego serwera.
Testowanie odwzorowania
W niniejszym podrozdziale opisano sposób testowania wykonanych odwzorowań (mappings). W zależności od zastosowanej metody, do konta Administrator przyporządkowano jeden lub kilka certyfikatów. Obecnie skonfigurowana zostanie strona sieci Web oraz zostanie uzyskany dostęp do pliku, skonfigurowanego w ten sposób, że dostęp jest możliwy tylko po wykonaniu odwzorowania.
Tworzenie pliku zastrzeżonego Pierwszym etapem jest utworzenie pliku, do którego dostęp jest możliwy tylko z konta Administrator. Może on mieć rodzaj pliku spotykanego na stronach sieci Web, jak HTM, GIF, JPEG, itd. W niniejszym przykładzie użyty zostanie plik GIF. Oto procedura tworzenia pliku z ograniczonym dostępem: 1.
Za pomocą Exploratora Windows (Windows Explorer) otwórz katalog Inetpub\wwwroot.
2.
Skopiuj dowolny plik GIF (np. win2000.gif) do pliku test.gif.
3.
Prawym przyciskiem myszki kliknij plik test.gif i z menu wybierz Właściwości (Properties).
4.
Wybierz zakładkę Bezpieczeństwo (Security).
5.
Usuń zaznaczenie opcji Zezwalaj na pozwolenie możliwych do dziedziczenia uprawnień z obiektu nadrzędnego do tego obiektu (Allow inheritable permissions from parent to propagate to this object).
6.
W oknie dialogowym Bezpieczeństwo (Security) naciśnij przycisk Usuń (Remove).
7.
Kliknij Dodaj (add) i dodaj konto Administrator z uprawnieniami Pełna Kontrola (Full Control). Naciśnij przycisk OK. Zamknij Eksploratora Windows.
Dostęp do pliku test.gif można obecnie uzyskać tylko z konta Administrator.
Wyłączanie uwierzytelniania Kiedy usługa Internet Information Server (IIS) ma uzyskać dostęp do pliku, personifikuje (impersonate) użytkownika tak, by system stosował prawa dostępu użytkownika uwierzytelnionego. Należy upewnić się, czy proces uwierzytelniania korzysta z odwzorowania (mapping) certyfikatów. Do skonfigurowania usługi IIS, aby nie można było zastosować innego sposobu uwierzytelniania, w przypadku pliku test.gif, należy postępować zgodnie z poniższą procedurą: 1.
Uruchom przystawkę (snap-in) IIS konsoli MMC.
2.
Kliknij dwukrotnie pozycję Domyślna Witryna Sieci Web (Default Web Site).
3.
Prawym przyciskiem myszki kliknij plik test.gif, który wyświetlony jest w prawej części okna. Z menu wybierz pozycję Właściwości (Properties).
4.
Naciśnij zakładkę Zabezpieczenia Plików (File Security).
5.
Wybierz Edytuj (Edit), który znajduje się w polu Kontrola Dostępu Anonimowego i Uwierzytelniania (Anonymous Access and Authentication Control).
6.
Usuń zaznaczenie wszystkich opcji. Naciśnij przycisk OK.
7.
Aby zamknąć okno dialogowe Właściwości (Properties), naciśnij przycisk OK. Zamknij przystawkę konsoli MMC.
Teraz nie ma innej możliwości uwierzytelnienia prawa użytkownika do uzyskania dostępu do danego pliku niż przez odwzorowanie (mapping) certyfikatów. Ważne jest, aby zrozumieć, co będzie testowane. Plik test.gif ma właściwości ustawione w ten sposób, że dostęp do niego za pomocą przeglądarki jest możliwy tylko przez przyporządkowanie certyfikatu. Katalog lub całą stronę sieci Web można skonfigurować w ten sam sposób. Jeśli stosowane jest przyporządkowywanie jawne (explicit mapping), byłoby to wystarczające, ponieważ tylko konto administratora ma aktualnie przyporządkowany certyfikat. Warto pamiętać o ograniczeniu dostępu do pliku poprzez skonfigurowanie uprawnienia do pliku (file permissions). Aktualne ustawienia uprawnień umożliwiają dostęp tylko z konta Administrator. Jeśli stosuje się Odwzorowanie (Mapping) nazw głównych użytkowników (User Principal Name — UPN), wówczas każdy użytkownik, który posiada certyfikat, może zostać uwierzytelniony. W tym przypadku ustawienie uprawnień do pliku jest konieczne. Przy odwzorowywaniu (mapping) nazw głównych użytkowników (UPN), zwykły użytkownik mógłby uzyskać dostęp do pliku, ale uwierzytelnienie nie powiedzie się z powodu ustawienia uprawnień. Wpływa to na komunikaty otrzymywane przez użytkownika. Jeśli proces uwierzytelniania nie rozpocznie się, pojawi się komunikat, że dany plik (katalog czy strona sieci Web) nie został znaleziony. Jeśli uwierzytelnianie rozpoczęło się, ale zakończyło błędem, użytkownik zostanie poinformowany, że nie ma odpowiednich uprawnień.
Połączenie ze stroną sieci Web Poniżej zamieszczono procedurę połączenia ze stroną test.gif i sprawdzenia, czy odwzorowanie (mapping) działa poprawnie. 1.
Uruchom program Internet Explorer i połącz się ze stroną https://ServerName/test.gif, gdzie ServerName jest nazwą serwera sieci Web. Jeśli testowanie odbywa się na serwerze sieci Web, zamiast nazwy serwera wpisz LOCALHOST.
2.
Program Internet Explorer wyświetli komunikat ostrzegający, że zostanie użyty protokół SSL (o ile wcześniej wyświetlanie komunikatów nie zostało wyłączone). Naciśnij przycisk OK.
3.
W zależności od tego czy wpiszesz LOCALHOST, czy podasz nazwę serwera sieci Web, z którym chcesz się połączyć, Internet Explorer może wyświetlić ostrzeżenie, że certyfikat serwera nie zgadza się z podaną nazwą, jak przedstawiono to na rysunku 8.13. Aby przejść dalej, zaznacz Tak (Yes).
4.
Wybierz certyfikat, który ma odpowiedni klucz prywatny. Informację taką uzyskasz, naciskając przycisk Wyświetl Certyfikat (View Certificate). Naciśnij OK.
Uwaga: Niniejszy test powinien być przeprowadzony na komputerze, na którym pierwotnie zainstalowano dany certyfikat. Każdy certyfikat ma klucz prywatny, który jest zapisany na komputerze, z którego wysłano żądanie certyfikatu.
5.
Jeśli odwzorowanie (mapping) działa poprawnie, powinien pojawić się plik test.gif, jak przedstawiono to na rysunku 8.14.
Rysunek 8.13. Komunikat Alarm Zabezpieczeń Systemu Windows (Security Alert)
Rysunek 8.14. Poprawne odwzorowanie pozwala uzyskać dostęp do tego ekranu Jeśli pojawi się komunikat o błędzie, przyczyny jego mogą być następujące: •
komunikat Dostęp Zabroniony (Access Denied) wskazuje, że uwierzytelnienie było prawidłowe, ale dany użytkownik nie ma odpowiednich uprawnień, aby uzyskać dostęp do tego pliku. Należy sprawdzić uprawnienia do tego pliku i zobaczyć, do którego konta przypisany został dany certyfikat użytkownika,
•
komunikat Certyfikat Odwołany (Certificate Revoked) zazwyczaj wskazuje na odwołanie certyfikatu lub że usługa IIS nie jest w stanie wyszukać listy odwołań certyfikatów (Certificate Revocation List — CRL),
•
komunikat Certyfikat nie jest zaufany lub jest nieprawidłowy (certificate is not trusted or is invalid) oznacza zwykle, że nie zainstalowano certyfikatu głównego (root) w magazynie zaufanych certyfikatów głównych (trusted roots store) komputera na serwerze sieci Web. Często spotykanym błędem jest instalowanie certyfikatu głównego w magazynie zaufanych certyfikatów głównych użytkownika, zamiast w magazynie komputera.
Komunikaty o błędach są zwykle opisowe. Innymi źródłami informacji dotyczących komunikatów o błędach mogą być informacje o wersji (release notes), podręczniki w trybie online (books on line) i pliki pomocy (help files). W niniejszym rozdziale przedstawiono sposoby przyporządkowywania jednego lub kilku certyfikatów do konta Administrator. Korzystając z odwzorowywania nazw głównych użytkownika (UPN mapping), można ułatwiać użytkownikom z ważnymi certyfikatami przedsiębiorstwa (enterprise certificates), uzyskiwanymi przez każdego z nich od Usług
Certyfikatów (Certificate Server) firmy Microsoft, stosowanie odwzorowywania (mapping) certyfikatów, aby zatwierdzić ich prawa dostępu poprzez serwer sieci Web. W danym przypadku jest to po prostu kwestia odpowiednich ustawień uprawnień do plików i folderów oraz usunięcia innych metod sprawdzania certyfikatów. Jeśli korzysta się z przyporządkowywania jawnego (explicit mapping), wymaga to trochę większego wysiłku, ponieważ konta muszą być przyporządkowane w sposób jawny do certyfikatów. Jeśli jednak ma być dokonywane odwzorowanie wiele-do-jednego (many-to-one mapping) lub jeśli w danej domenie nie ma jednostki certyfikującej przedsiębiorstwa (enterprise CA), wtedy jawne odwzorowanie (explicit mapping) zapewnia wysoki stopień zabezpieczeń we wrogim środowisku.
Rozdział 9
Karty elektroniczne (smart cards) Rozwiązania natychmiastowe zobacz na stronie: Instalowanie czytnika kart elektronicznych (smart card reader) Konfigurowanie stacji rejestrowania kart elektronicznych (smart card enrollment station) Wydawanie kart elektronicznych (smart cards) Logowanie się za pomocą kart elektronicznych Wdrażanie kart elektronicznych Rozwiązywanie problemów związanych z kartami elektronicznymi Zabezpieczanie stacji rejestrowania kart elektronicznych (smart card enrollment station) Umieszczanie aplikacji na kartach elektronicznych Zastosowanie pakietu Smart Card Software Development Kit Zastosowanie interfejsów API firmy Microsoft Zastosowanie interfejsu Java Card API 2.1
Zastosowanie standardu (OpenCard Framework — OCF)
W skrócie Co to jest karta elektroniczna (smart card)? Jak wyjaśniono to w rozdziale 6., karty elektroniczne (smart cards) są elementem Infrastruktury Klucza Publicznego (Public Key Infrastructure — PKI) systemu Windows 2000. Mogą być stosowane przy logowaniu interaktywnym, uwierzytelnianiu klienta i logowaniu zdalnym (remote logon). Ponadto stanowią zabezpieczony przed penetracją (tamper resistant) — waham się określić je jako odporne na penetrację (tamper proof) — środek do przechowywania danych, który umożliwia ochronę kluczy prywatnych (private keys) i innych danych osobowych oraz oddzielenie operacji zabezpieczonych (secure operations), takich jak zatwierdzanie klucza publicznego, od innych funkcji systemowych, mniej ważnych z punktu widzenia bezpieczeństwa systemu. Jednak główną zaletą kart elektronicznych jest ich przenośność (portability). Użytkownik karty elektronicznej ma łatwą, bezpieczną i wygodną metodę przenoszenia danych uwierzytelniających logowania (logon credentials) i innych informacji poufnych pomiędzy komputerami w pracy, w domu lub drodze. Rozwiązania pokrewne zobacz na stronie Stosowanie zabezpieczeń z kluczem publicznym w systemie Windows 2000 Karta elektroniczna (smart card) jest miniaturowym komputerem wbudowanym w płaską kartę plastikową, która wygląda jak standardowa karta kredytowa lub bankomatowa, a podstawową różnicą jest brak paska magnetycznego i wielokrotnie większa ilość przechowywanych danych. Obwody karty elektronicznej zasilane są z czytnika kart elektronicznych (smart cards reader), do którego karta jest włożona. Dane pomiędzy kartą elektroniczną a usługą lub aplikacją uruchomioną na komputerze wymieniane są przez łącze szeregowe (serial interface), a obsługiwane przez czytnik i związany z nim sterownik urządzenia (device driver).
Karta elektroniczna może być kartą z wpisaną wartością (stored value card), kartą zbliżeniową (contacless card) lub kartą czipową (Integrated Circuit Card — ICC). W systemie Windows 2000 zastosowano karty czipowe (ICC), za pomocą których można wykonywać zaawansowane operacje takie jak wymiana klucza podpisu cyfrowego (digital signature key exchange). Zamiast wprowadzania nazwy konta użytkownika i hasła, użytkownik karty elektronicznej loguje się do systemu Windows 2000, wkładając kartę elektroniczną do czytnika i wpisując numer PIN w taki sam sposób, jak przy korzystaniu z bankomatu. Są dwa rodzaje kart elektronicznych — karty kontaktowe (contact smart cards) oraz karty bezkontaktowe (contactless smart cards). Te pierwsze mają na przedniej części złotą płytkę, nazywaną płytką łączącą (contact plate) lub modułem (module). Płytka ta ma osiem końcówek (contacts) i służy jako złącze pomiędzy układem scalonym wbudowanym w kartę elektroniczną a czytnikiem kart elektronicznych. Na rysunku 9.1 przedstawiono schemat takiej karty. Karty elektroniczne GemSAFE firmy Gemplus mają złącza (contacts) owalne, a karty elektroniczne Cryptoflex firmy Schlumberger — złącza prostokątne. Karta elektroniczna bezkontaktowa razem z układem scalonym ma wbudowaną antenę, która umożliwia komunikację z odbiornikiem (antena — coupler unit) bez fizycznego kontaktu. Karty bezkontaktowe stosowane są wtedy, gdy konieczne jest bardzo szybkie przetwarzanie transakcji, np. pobieranie opłat za przejazd autostradą (toll collection). Obecnie karty takie nie są obsługiwane przez system Windows 2000. Rozmiary i dane charakterystyczne kart elektronicznych określają normy ISO 7810 oraz ISO 7816.
Współdziałanie kart elektronicznych Współdziałanie (interoperability) pomiędzy kartami od różnych dostawców jest warunkiem koniecznym, aby karty elektroniczne zostały szeroko zaakceptowane. W celu zapobiegania lub przynajmniej zmniejszenia niezgodności pomiędzy aplikacjami, kartami i czytnikami, konieczne jest opracowanie norm, które zostaną powszechnie przyjęte. Normy dotyczące kart elektronicznych (smart cards) opracowywane są na podstawie norm ISO 7816 dla kart z układem scalonym ze złączem (integrated circuit cards with contacts). Normy te dotyczą współdziałania (interoperability) na poziomie fizycznym, elektrycznym i protokołu łącza transmisji danych (data link protocol).
Rysunek 9.1. Karta elektroniczna (contact smart card) W roku 1996 Eurocard, Masterplay i Visa (EMV) opracowały specyfikację kart elektronicznych, która jest adaptacją norm ISO 7816 i określa kilka dodatkowych typów danych i reguł kodowania na potrzeby świadczenia usług finansowych. Europejskie firmy telekomunikacyjne również zawarły normy ISO 7816 w swojej specyfikacji kart elektronicznych dla systemu GSM (Global System for Mobile Communications), umożliwiające identyfikowanie i uwierzytelnianie użytkowników telefonów komórkowych. Chociaż wszystkie te specyfikacje (ISO 7816, EMV i GSM) szły w dobrym kierunku, to każda z nich albo określała warunki współpracy tylko na niskim poziomie, albo dotyczyła tylko określonych zastosowań i nie uzyskała powszechnej akceptacji. Takie zagadnienia związane ze współpracą (interoperability), jak interfejsy API niezależne od sprzętu, narzędzia dla programistów i współużytkowanie zasobów, nie zostały poruszone w żadnej z nich.
Grupa robocza PC/SC Grupa robocza PC/SC (Personal Computer/Smart Card) została powołana w maju 1996 roku przez największe firmy komputerowe i producentów kart elektronicznych. Obecnie członkami tej grupy są: Bull, Gemplus, Hewlett Packard, IBM, Microsoft, Schlumberger, Siemens, Nixdorf Information Systems, Sun Microsystems i Toshiba. Grupa ta została powołana, aby wskazać ograniczenia w istniejących do tej pory standardach, które utrudniają stosowanie kart z wbudowanym układem scalonym (ICC) w komputerach osobistych, ale nie zdołała właściwie określić warunków współdziałania (interoperability) pomiędzy produktami od różnych dostawców z punktu widzenia aplikacji pracujących na komputerze osobistym. W szczególności członkowie grupy roboczej wskazali na potrzebę opracowania standardowych interfejsów programowych dla urządzeń sprzęgających oraz specyfikacji wspólnych interfejsów programowych (programming interface) i mechanizmów sterujących (control mechanizm) dla komputerów osobistych. Działania tej grupy również doprowadziły do wniosku, że opracowywane
rozwiązania muszą obejmować, w takim zakresie, jak to tylko możliwe, istniejące urządzenia i aplikacje. Dalszym celem grupy jest opracowanie rozwiązań, które zaspokoją potrzeby wszystkich firm, działających w tej dziedzinie. Specyfikacje opracowane przez grupę PC/SC są oparte na normach ISO 7816 i są zgodne ze specyfikacjami EMV i GSM. Mają one szerokie poparcie ze strony firm, działających w tej dziedzinie i podejmowane są wysiłki na rzecz uczynienia z nich w przyszłości norm (standards). Dokładniejsze informacje dotyczące grupy roboczej PC/SC i specyfikacji opracowanych przez jej członków można znaleźć pod adresem www.smartcardsys.com.
OpenCard Framework (OCF) OpenCard Framework (OCF) jest to osnowa oprogramowania obiektowego (object oriented software framework) do korzystania z kart elektronicznych (smart cards), opracowana i rozwijana przez grupę OpenCard Consortium. Grupa ta została założona przez firmy Bull, Dallas Semiconductor, First Access, Gemplus, IBM, Network Computer Inc., Schlumberger, SCM Microsystems, Sun Microsystems, UbiQ i Visa International. Standard OCF jest uważany za uzupełniający w stosunku do specyfikacji PC/SC i zawiera model strukturalny dwóch głównych usługodawców z branży kart elektronicznych: •
programistów aplikacji i usług,
•
dostawców kart i terminali.
W standardzie OCF ustalono dwa interfejsy: •
interfejs programisty API wysokiego poziomu (high level API), który pozwala na ukrycie cech konkretnych urządzeń — kart elektronicznych lub (i) terminali kart elektronicznych — przed programistami aplikacji i usług,
•
wspólny interfejs usługodawcy, który umożliwia integrację urządzeń związanych z kartami elektronicznymi, pochodzących od różnych dostawców.
Standard OCF jest zgodny ze standardem PKCS #11 (Cryptoki), specyfikacją EMV, normami CEN EN726, ISO 7816 oraz specyfikacją grupy PC/SC. Specyfikacja EMV i norma CEN726 określają dane techniczne kart. Standard PKCS #11 jest standardem zabezpieczeń danych aplikacji. OCF zapewnia usługi CardServices jako interfejs API zgodny ze standardem PKCS #11, aby aplikacje mogły korzystać z żetonów sprzętowych (hardware tokens) jako jednego ze sposobów zabezpieczeń cyfrowych. Specyfikacje PC/SC nie są istotnym elementem OCF, ale, jeśli tylko są obecne, mogą z nich korzystać interfejsy API OCF, przynajmniej gdy chodzi o czytnik kart elektronicznych. OCF i PC/SC nadal współpracują, aby osiągnąć pełną zgodność odnośnie samych kart elektronicznych. OCF może dostarczyć rozwiązań wielu problemów, na które napotykają producenci kart
elektronicznych i programiści, tworzący aplikacje do obsługi tych kart i dlatego zamieszczono szczegółowy opis w części niniejszego rozdziału pod tytułem „Rozwiązania natychmiastowe”. Więcej informacji można znaleźć na stronie www.opencard.org.
Technologia Java Card Karty Java Card są kartami elektronicznymi, na których można uruchomić programy zgodne ze specyfikacją Java Card API 2.1 opracowaną przez dział JavaSoft firmy Sun Microsystems. Stosując karty Javy, programiści aplikacji związanych z kartami elektronicznymi, korzystają z możliwości, jakie daje technologia obiektowa „Raz napisane, wszędzie uruchamiane” („Write once, run anywhere”) i zaawansowane narzędzia do tworzenia aplikacji. Specyfikacja Java Card API 2.1 została opracowana we współpracy z producentami kart elektronicznych (smart card manufacturers), firm wydających karty (issuers) oraz obsługujących karty elektroniczne (smart card associations). Do firm popierających technologię Java Card należą: Bull, Citicorp, De la Rue, First Union, Gemplus, Giesecke&Devrient, Hitachi, IBM Corporation, Mitsubishi Electric, Mondex, OKI, NTT Data Corporation, Motorola, Schlumberger, Texas Instruments, Toshiba, VeriFone i Visa. Specyfikacja Java Card API 2.1 jest zgodna z normami ISO 7816-4 oraz 7816-5. Norma ISO 7816-4 dotyczy funkcji interfejsu Java Card API, takich jak dostęp do systemu plików i operacji wejście-wyjście. Norma ISO 7816-5 dotyczy identyfikatorów (identifiers) i konwencji nazewniczych obsługiwanych przez Java Card API. Podczas gdy standard OpenCard Framework (OCF) jest zaimplementowany za pomocą programu w języku Java, działającego na komputerze lub terminalu komunikującym się kartą elektroniczną (smart card), to Java Card jest skróconą wersją Javy, zainstalowaną na samej karcie. Standard OCF może korzystać zarówno z kart elektronicznych typu Java Card (Java Card smart cards), jak i ze standardowych kart elektronicznych (standard smart cards), ale jeśli aplety Javy mają być zapisane bezpośrednio na karcie (tzw. cardlets), musi to być karta elektroniczna typu Java Card. Interfejs Java Card API 2.1 umożliwia rozwiązanie problemów występujących przy pisaniu aplikacji korzystających z kart elektronicznych i zagadnienie to omówione zostanie szczegółowo w części niniejszego rozdziału pod tytułem „Rozwiązania natychmiastowe”.
Rozwiązania dostarczane przez firmę Microsoft Firma Microsoft dostarcza interfejsy API, takie jak CryptoAPI, Scard COM i Win32 z rozszerzeniem zakresu funkcji o obsługę kart elektronicznych. Zagadnienie to omówiono w części niniejszego rozdziału pod tytułem „Rozwiązania natychmiastowe”. Podejście firmy Microsoft do tego zagadnienia zawiera następujące elementy:
•
standardowy model interfejsu pomiędzy czytnikami kart elektronicznych i kartami elektronicznymi a komputerami,
•
interfejsy programowe API niezależne od urządzeń, uaktywniające aplikacje korzystające z kart elektronicznych,
•
narzędzia do tworzenia oprogramowania,
•
integracja ze wszystkimi systemami Windows.
Standardowy model interfejsu pomiędzy czytnikami kart elektronicznych i kartami a komputerem daje możność współpracy pomiędzy czytnikami i kartami od różnych producentów. Interfejsy programowe API niezależne od urządzeń izolują programistów od różnic występujących pomiędzy bieżącymi a przyszłymi implementacjami. Uniezależnienie się od urządzeń ogranicza również koszty tworzenia oprogramowania poprzez uniknięcie dezaktualizacji oprogramowania po wprowadzeniu zmian w sprzęcie.
Obsługiwane karty elektroniczne Domyślnie instalowana jest wersja systemu Windows 2000 obsługująca kryptograficzne karty elektroniczne (cryptographic smart cards) GemSAFE firmy Gemplus i Cryptoflex firmy Schlumberger. Aby korzystać z tych kart, nie są potrzebne żadne zmiany w konfiguracji klienta ani serwera. Kryptograficzne karty elektroniczne są dostępne bezpośrednio u producenta. W tabeli 9.1. zamieszczono — istotne z punktu widzenia użytkownika — różnice pomiędzy kartami od różnych producentów. Inne kryptograficzne karty elektroniczne, w których zastosowano algorytm RSA (Rivest-ShamirAdleman) również współpracują z Infrastrukturą Klucza Publicznego (PKI) systemu Windows 2000, pod warunkiem, że dostawca kart opracował Usługodawcę Usług Kryptograficznych (Cryptographic Service Provider — CSP), korzystając z interfejsu CryptoAPI i pakietu Smart Card Software Development Kit (SDK). Pakiet ten jest dostępny za pomocą MSDN (Microsoft Developers Network). Pakiet Smart Card SDK omówiono w części niniejszego rozdziału pod tytułem „Rozwiązanie natychmiastowe”.
Obsługiwane czytniki kart elektronicznych Zanim karty elektroniczne zostaną zastosowane, konieczne jest zainstalowanie ich czytnika. System Windows 2000 zawiera sterowniki czytników kart elektronicznych, które zamieszczono w
tabeli 9.2., ale sterowniki te instalowane są tylko po wykryciu odpowiedniego czytnika kart elektronicznych, zgodnego ze standardem podłącz i pracuj (plug-and-play). Tabela 9.1. Karty elektroniczne obsługiwane przez system Windows 2000
Karta elektroniczna
Domyślny kod PIN
Kształt złącza
Usługodawca usług kryptograficznych — CSP
Gemplus GemSAFE
1234
Owalne
Gemplus GemaSAFE card CSP v1.0
Schlumberger Cryptoflex
00000000
Prostokątne
Schlumberger CSP
Firma Microsoft nie obsługuje ani nie zaleca stosowania czytników kart elektronicznych (smart card readers) nie mających funkcji plug-and-play. W firmie Microsoft opracowano zasady udzielania zezwoleń na umieszczanie na czytnikach kart elektronicznych logo „Zaprojektowane dla Windows”, co ma umożliwić stosowanie czytników kart elektronicznych od jednego producenta i kart elektronicznych (smart cards) od innego. Założenia tego programu są oparte na specyfikacji PC/SC (Personal Computer/Smart Card) i gwarantują współpracę (interoperability) czytników kart elektronicznych w systemie Windows. Tylko czytniki kart elektronicznych, które zostały sprawdzone przez laboratorium jakości sprzętu systemu Windows (Windows Hardware Quality Lab — WHQL) firmy Microsoft i uzyskały logo „Zaprojektowane dla Windows” mogą być instalowane w komputerach pracujących pod kontrolą systemu Windows 2000. Na rynku dostępne są czytniki kart elektronicznych, które nie współpracują z kartami z innego źródła, chociaż wiele z tych urządzeń oznaczonych jest jako „zgodne ze specyfikacją PC/SC”. Określenie to nie ma żadnego znaczenia, ponieważ nie opracowano żadnych testów zgodności z wyżej wymienioną specyfikacją. Uwaga: Wykaz czytników kart elektronicznych zamieszczony w tabeli 9.2. powstał w czasie pisania książki. Aktualne informacje dotyczące zgodności tych urządzeń z systemem Windows znajdują się na liście zgodności sprzętu (Hardware Compatibility List — HCL) pod adresem www.microsoft.com/hcl.
Tabela 9.2. Czytniki kart elektronicznych obsługiwane przez system Windows Producent
Typ czytnika
Interfejs
Sterownik urządzenia
Bull CP8
Smart TLP3
RS-232
bulltlp3.sys
Gemplus
GCR410P
RS-232
gcr410p.sys
Gemplus
GPR400
PCMCIA
gpr400.sys
Litronic
220P
RS-232
lit220p.sys
Rainbow Technologies
3531
RS-232
rnbo3531.sys
SCM Microsystems
SwapSmart
RS-232
scmstcs.sys
SCM Microsystems
SwapSmart
PCMCIA
pscr.sys
Rozwiązania natychmiastowe Instalowanie czytników kart elektronicznych Czytniki kart elektronicznych powinny mieć funkcję typu podłącz i pracuj (plug-and-play) i znajdować się na liście zgodności sprzętu Windows (Hardware Compatibility List — HCL). Listę czytników obsługiwanych przez system Windows, aktualną w czasie pisania książki, zamieszczono w tabeli 9.2. Instalowanie urządzeń plug-and-play, znajdujących się na HCL, jest łatwe. Na ogół wystarczy podłączyć urządzenie do komputera i zainstalować odpowiedni sterownik urządzenia, postępując zgodnie z poniższym opisem.
Podłączanie czytnika kart elektronicznych Czytniki kart elektronicznych (smart card readers) zazwyczaj są dostarczane z instrukcją instalacji i należy postępować zgodnie z nią. Jeśli nie ma instrukcji, należy skorzystać z poniższej, ogólnej procedury instalowania czytnika kart elektronicznych: 1.
Zamknij system i wyłącz komputer.
2.
Podłącz czytnik do portu szeregowego lub, jeśli jest to czytnik z interfejsem PC card, do gniazda PCMCIA Type II.
3.
Jeśli czytnik z łączem szeregowym ma dodatkowe gniazdo i kabel PS/2 podłącz do niego klawiaturę lub myszkę, a czytnik podłącz do gniazda PS/2 klawiatury lub myszki w
komputerze. Niektóre czytniki są zasilane za pomocą gniazda klawiatury lub myszki, ponieważ nie zawsze możliwe jest zasilanie z portu szeregowego. 4.
Uruchom komputer i zaloguj się.
Instalowanie sterownika czytnika kart elektronicznych Instalowanie urządzeń w kontrolerze domeny (Domain Controller — DC) możliwe jest tylko z konta administratora. W stacji roboczej pracującej pod kontrolą systemu Windows 2000 Professional urządzenia mogą instalować administratorzy (członkowie grup Administrators) i Użytkownicy Zaawansowani (Power Users). Jeśli dany czytnik jest urządzeniem plug-and-play („podłącz i pracuj”) to zostanie wykryty automatycznie przez kreatora sprzętu (hardware wizard). W przeciwnym razie należy uzyskać instrukcję producenta. Wszystkie urządzenia znajdujące się na liście zgodności sprzętu (HCL) są urządzeniami typu plug-and-play i firma Microsoft zaleca, by nie instalować sprzętu spoza listy. Po ponownym uruchomieniu komputera, po podłączeniu czytnika z funkcją plug-and-play, kreator sprzętu powinien go wykryć. Potem należy zainstalować sterownik postępując zgodnie z instrukcjami kreatora. Konieczny będzie instalacyjny dysk CD-ROM systemu Windows 2000 lub dyskietka ze sterownikiem urządzenia, dostarczona przez producenta. Może być również możliwość pobrania sterownika z udziału sieciowego (network share). Zawartość wyświetlanych ekranów będzie różnić się w zależności od typu instalowanego czytnika, ale w pewnym momencie pojawi się polecenie uruchomienia usługi Karta Elektroniczna (Smart Card) i skonfigurowania jej, aby uruchamiała się automatycznie. Poniżej zamieszczono procedurę uruchamiania usługi Karta Elektroniczna: 1.
Z menu Start wybierz pozycję Programy|Narzędzia administracyjne|Usługi (Programs\Administrative tools\Services).
2.
Prawym przyciskiem myszki kliknij usługę Karta Elektroniczna i z menu wybierz pozycję Właściwości (Properties).
3.
Z listy rozwijalnej Typ Uruchomienia (Startup Type) wybierz opcję Automatyczny (Automatic). W ten sposób zostanie ustawione automatyczne uruchamianie usługi Menedżer Zasobów Kart Inteligentnych (Smart Card Resource Manager).
4.
Jeśli usługa już działa, przycisk Uruchom (Start) będzie zaznaczony na szaro. Jeśli usługa jeszcze nie została uruchomiona, naciśnij Uruchom. Usługa zostanie uruchomiona i powinien pojawić się ekran podobny do przedstawionego na rysunku 9.2.
5.
Po wyświetleniu przez kreatora (wizard) odpowiedniego komunikatu, ponownie uruchom komputer.
Wskazówka: Jeśli kreator nie zostanie uruchomiony automatycznie, oznacza to, że dany czytnik kart elektronicznych (smart card reader) nie jest urządzeniem typu plug-and-play. Wtedy należy zwrócić się do producenta tego czytnika po odpowiedni sterownik i instrukcję instalowania.
Rysunek 9.2. Ustawienie automatycznego uruchamiania usługi Karta Elektroniczna (Smart Card)
Instalowanie stacji rejestrowania kart elektronicznych (smart card enrollment station)
Po zainstalowaniu czytnika kart elektronicznych, użytkownik karty elektronicznej musi zostać zarejestrowany (enroll) w celu uzyskania odpowiedniego certyfikatu. Proces rejestrowania (enrollment) w celu uzyskania certyfikatu karty elektronicznej musi zachodzić pod kontrolą. Można to porównać do wydawania pracownikom identyfikatorów (employee badges), potwierdzających ich tożsamość i umożliwiających dostęp do pomieszczeń firmy. Wówczas występują takie same ograniczenia ze względów bezpieczeństwa. Z tego powodu zwykli użytkownicy nie mogą rejestrować się sami w celu uzyskania certyfikatu karty elektronicznej. W ich imieniu robią to administratorzy. Zadanie to można wykonać na dowolnym komputerze pracującym pod kontrolą systemu Windows 2000 (Professional lub Server), który będzie używany jako stacja rejestrowania kart elektronicznych (smart card enrollment station). W danej lokacji (site) musi być zainstalowany serwer certyfikatów (certificate server), jednostka certyfikująca (CA) oraz przynajmniej jeden certyfikat administratora. Rozwiązania pokrewne zobacz na stronie: Instalowanie jednostki certyfikującej Instalowanie certyfikatów jednostki certyfikującej Zalecaną przez firmę Microsoft metodą rejestrowania się (enrolling) w celu uzyskania certyfikatów kart elektronicznych i kluczy jest korzystanie ze stacji rejestrowania kart elektronicznych, która jest częścią usług certyfikatów (certificate services) systemu Windows 2000 Server i Windows 2000 Advanced Server. Razem z instalowaniem jednostki certyfikującej przedsiębiorstwa (enterprise CA) instalowana jest stacja rejestrowania kart elektronicznych. Umożliwia to administratorowi wysłanie żądania i zainstalowanie certyfikatu logowanie się za pomocą karty elektronicznej (smart card logon) — uwierzytelnianie oraz użytkownik karty elektronicznej (smart card user) — uwierzytelnianie i poczta elektroniczna na karcie elektronicznej w imieniu użytkownika. Aby zainstalować Stację Rejestrowania Certyfikatów najpierw trzeba uzyskać certyfikat podpisywania (signing certificate), oparty na szablonie certyfikatu agent rejestrowania (enrollment agent). Certyfikat podpisywania będzie używany przy podpisywaniu żądania certyfikatu wygenerowanego w imieniu użytkownika karty elektronicznej.
OSTRZEŻENIE! Domyślnie tylko administratorzy domeny (członkowie grupy Domain Administrators) mają uprawnienie do żądania certyfikatu opartego na szablonie (template) agent rejestrowania (enrollment agent). Jeśli podjęta zostanie decyzja o delegowaniu rejestrowania kart elektronicznych (smart card enrollment), należy zachować szczególną ostrożność przy wyborze administratora kart elektronicznych. Osoba, która uzyska certyfikat agenta rejestrowania może zarejestrować się (enroll for) w celu uzyskania certyfikatu i wytworzyć kartę elektroniczną w imieniu dowolnej innej osoby z danego przedsiębiorstwa, łącznie z administratorami. Otrzymana w ten sposób karta elektroniczna może być użyta do zalogowania się do sieci i personifikowania (Impersonate) rzeczywistego użytkownika.
Uzyskiwanie certyfikatu agenta rejestrowania (enrollment agent) Przed wysłaniem żądania certyfikatów użytkowników, logowanie za pomocą kart elektronicznych (smart card logon) konieczne jest posiadanie certyfikatu agenta rejestrowania, który umożliwia wysłanie żądania certyfikatu karty elektronicznej w imieniu innych użytkowników. Uzyskanie tego certyfikatu jest możliwe tylko jeśli użytkownik posiada uprawnienia zabezpieczeń (security permissions), aby uzyskać dostęp do Szablonu Certyfikatu Agenta Rejestrowania (Enrollment Agent Certificate Templates). Domyślnie tylko administrator domeny ma takie uprawnienia, ale może je przekazać osobie, która została administratorem kart elektronicznych (smart card administrator) — przeczytaj ostrzeżenie zamieszczone powyżej.
Uwaga: Nie można otrzymać certyfikatu agenta rejestrowania, dopóki nie zostanie podłączony czytnik kart elektronicznych i zainstalowany odpowiedni sterownik.
Poniżej zamieszczono procedurę uzyskiwania Certyfikatu Agenta Rejestrowania (Enrollment Agent Certificate): 1.
Zaloguj się jako administrator, który będzie wydawał karty elektroniczne (smart cards).
2.
Z menu Start wybierz pozycję Uruchom (Run) i wpisz polecenie mmc.
3.
Z menu Konsola (Console) zaznacz Dodaj/Usuń przystawkę (Add/Remove snap-in), a następnie kliknij Dodaj (Add).
4.
Kliknij dwukrotnie pozycję Certyfikaty (Certificates).
5.
Wybierz Moje Konto Użytkownika (My User Account), które prawdopodobnie będzie wybrane domyślnie, a następnie naciśnij przycisk Zakończ (Finish).
6.
Naciśnij Zamknij (Close) i OK.
7.
Kliknij dwukrotnie pozycję Certyfikaty — Bieżący Użytkownik (Certificates — Current User).
8.
Z drzewa konsoli wybierz gałąź Osobiste (Personal). Powinno pojawić się okno podobne do przedstawionego na rysunku 9.3.
Rysunek 9.3. Wybrany Magazyn Certyfikatów Osobiste (Personal Certificate Store) 9.
W menu Akcje (Action) wybierz pozycję Wszystkie zadania (All tasks), a następnie zaznacz Żądaj Nowego Certyfikatu (Request New Certificate), jak przedstawiono na rysunku 9.4.
10. Uruchomiony zostanie Kreator Żądania Certyfikatu (Certificate Request Wizard). Naciśnij przycisk Dalej (Next). 11. Wybierz szablon certyfikatu agenta rejestrowania. Zostaniesz poproszony o podanie nazwy przyjaznej (friendly name) i opisu certyfikatu, jak przedstawiono to na rysunku 9.5. 12. Naciśnij przycisk Dalej i Zakończ. 13. Kiedy pojawi się odpowiedni komunikat Kreatora Żądania Certyfikatu, naciśnij przycisk Zainstaluj Certyfikat (Install Certificate). Aby zamknąć okno dialogowe, potwierdź OK. Obecnie posiadasz certyfikat konieczny do wysłania żądania certyfikatu kart elektronicznych w imieniu użytkowników. 14. Zamknij konsolę Certyfikaty.
Rysunek 9.4. Żądanie nowego certyfikatu osobistego
Rysunek 9.5. Definiowanie certyfikatu agenta rejestrowania (enrollment agent)
Uwaga: Można również zainstalować certyfikat agenta rejestrowania na karcie elektronicznej (smart card). W tym przypadku, wysyłając żądanie certyfikatu, korzysta się z Usługodawcy Usług Kryptograficznych (CSP) producenta karty. Naciskając przycisk Opcje Zaawansowane (Advanced Options) kreatora żądania certyfikatu, można wybrać Usługodawcę Usług Kryptograficznych dla Certyfikatu Agenta Rejestrowania.
Wydawanie kart elektronicznych Aby wydać użytkownikowi kartę elektroniczną należy zarejestrować się (enroll for) w celu uzyskania certyfikatu karty elektronicznej (smart card logon lub smart card user) w imieniu tego użytkownika i zainstalowanie tego certyfikatu na jego karcie. W tym miejscu i tylko w nim użytkownik może określić kod PIN.
Rejestrowanie się (enrolling for) w celu uzyskania certyfikatu karty elektronicznej w imieniu użytkownika Aby zarejestrować się w celu uzyskania certyfikatu logowania za pomocą karty elektronicznej (smart card logon) lub użytkownika karty elektronicznej (smart card user): 1.
Zaloguj się jako agent rejestrowania (enrollment agent), tzn. jako administrator wydający karty elektroniczne.
2.
Uruchom przeglądarkę i podaj adres //ServerName/CertSrv, gdzie ServerName jest nazwą serwera jednostki certyfikującej (CA server).
3.
Pojawi się strona powitalna usług certyfikatów firmy Microsoft (Microsoft certificate services), którą przedstawiono na rysunku 9.6. Zaznacz opcję Żądaj Certyfikatu (Request a Certificate), a następnie naciśnij przycisk Dalej (Next).
4.
Pojawi się strona Wybierz Typ Żądania (Choose Request Type), którą przedstawiono na rysunku 9.7. Zaznacz opcję Żądania Zaawansowane (Advanced Request), a następnie naciśnij Dalej.
Rysunek 9.6. Żądanie certyfikatu od usług certyfikatów firmy Microsoft (Microsoft certificate services) 5.
Pojawi się strona Zaawansowane Żądania Certyfikatów (Advanced Certificate Requests), którą przedstawiono na rysunku 9.8. Zaznacz opcję Żądaj certyfikatu dla karty elektronicznej w imieniu innego użytkownika, korzystając ze stacji rejestrowania kart elektronicznych (Request a certificate for a smart card on behalf of another user using the smart card enrollment station), po czym naciśnij Dalej.
6.
Jeśli pojawi się ostrzeżenie o zabezpieczeniach (security warning) z monitem o zatwierdzenie certyfikatu podpisywania (signing certificate) kart elektronicznych, naciśnij przycisk Tak.
Rysunek 9.7. Wybór żądania zaawansowanego
Rysunek 9.8. Strona Zaawansowane Żądania Certyfikatów (Advanced Certificate Requests)
Rysunek 9.9. Stacja Rejestrowania Kart Elektronicznych (Smart Card Enrollment Station) 7.
8.
Pojawi się strona Stacja Rejestrowania Kart Elektronicznych, którą przedstawiono na rysunku 9.9. Na stronie tej można wybrać: •
z listy rozwijanej Szablon Certyfikatu (Certificate Template) pozycję Smart card logon lub Smart card user. Ten drugi szablon stosuje się, jeśli karta elektroniczna oprócz logowania do systemu Windows ma służyć również do zabezpieczania poczty elektronicznej,
•
z listy rozwijanej Jednostka Certyfikująca jednostkę certyfikującą (CA). Na liście znajdują się tylko te jednostki certyfikujące (CAs), dla których uzyskano certyfikaty,
•
z listy rozwijalnej Usługodawca Usług Kryptograficznych (CSP) usługodawcę usług kryptograficznych (CSP) producenta karty elektronicznej.
W wierszu Status znajduje się monit o wybranie certyfikatu. Naciśnij przycisk Wybierz Certyfikat (Select Certificate) i wybierz pozycję Certyfikat Podpisu Administratora
(Administrator Signing Certificate). Pojawi się okno dialogowe Wybierz Certyfikat, w którym należy wybrać certyfikat Agent Rejestrowania (Enrollment Agent), który będzie służył do opatrywania żądania zarejestrowania (enrollment request) podpisem cyfrowym. Naciśnij przycisk OK. 9.
Teraz pojawi się monit o wybranie użytkownika. Naciśnij przycisk Wybierz Użytkownika (Select User). Tworzenie listy użytkowników może chwilę potrwać. Zwróć uwagę, że na liście znajdują się tylko nazwy użytkowników; karty elektroniczne nie mogą być wydawane grupom. Wybierz użytkownika, któremu zostanie wydana karta elektroniczna, jak przedstawiono to na rysunku 9.10. Naciśnij przycisk OK.
10. Nastąpi powrót do strony Stacja Rejestrowania Kart Elektronicznych. Przycisk Prześlij Żądanie Certyfikatu (Submit Certificate Request) jest teraz aktywny. Jeśli wszystkie ustawienia są prawidłowe, naciśnij go. 11. Jeśli karta elektroniczna nie znajduje się w czytniku, pojawi się monit o jej włożenie. Po włożeniu karty do czytnika kart elektronicznych i rozpoznaniu jej przez system, przycisk OK. będzie uaktywniony. Aby kontynuować proces rejestrowania (enrollment process) naciśnij OK. 12. Wpisz numer PIN karty, a następnie potwierdź OK. 13. Jeśli już zainstalowano certyfikat dla danej karty, tzn. wydano go poprzednio i użytkownik chce zmienić numer PIN, pojawi się zapytanie, czy zmienić dane uwierzytelniające (credentials) na karcie. W tym przypadku naciśnij przycisk Tak (Yes). 14. Teraz będziesz mieć możliwość podglądu utworzonego właśnie certyfikatu lub wysłania nowego żądania certyfikatu karty elektronicznej.
Rysunek 9.10. Wybór użytkownika Uwaga: Obecnie jedynym sposobem zmiany kodu PIN użytkownika jest wydanie nowego certyfikatu karty elektronicznej.
Logowanie za pomocą kart elektronicznych Podłączanie czytnika kart elektronicznych, instalowanie sterownika i uzyskiwanie certyfikatów dla użytkowników kart elektronicznych są zwyczajnymi operacjami. Z punktu widzenia powszechnych użytkowników logowanie za pomocą karty elektronicznej jest jeszcze bardziej rutynową procedurą. Po prostu wkłada się kartę, co jest równoważne naciśnięciu kombinacji przycisków Ctrl+Alt+Delete i wpisuje się numer PIN. Jednak administrator ustanawiający zasady kart elektronicznych (smart card policy) oraz wprowadzający je powinien wiedzieć i zrozumieć, co właściwie dzieje się w trakcie logowania za pomocą kart elektronicznych (smart card logon). Karta elektroniczna może być użyta do uwierzytelniania w domenie systemu Windows 2000 na trzy sposoby: •
logowanie interaktywne (interactive logon) — obejmuje usługi katalogowe Active Directory, protokół Kerberos 5 oraz certyfikaty z kluczem publicznym,
•
uwierzytelnianie klienta (client authentication) — użytkownik jest uwierzytelniany za pomocą certyfikatu z kluczem publicznym (public key certificate), odpowiadającego kontu zapisanemu w Active Directory,
•
logowanie zdalne (remote logon) — certyfikat z kluczem publicznym z protokołami stosowanymi do uwierzytelniania użytkownika (Extensible Authentication Protocol — EAP) oraz Transport Layer Security (TLS) jest używany do uwierzytelniania użytkownika zdalnego (remote user) konta w Active Directory. Protokół EAP opisano w dokumencie Request For Comment (RFC) 2294. Protokół TLS opisano w dokumencie RFC 2246, a wzajemne oddziaływanie protokołów TLS — Kerberos opisano w RFC 2712.
Wskazówka: Dokumenty RFC można znaleźć w Internecie pod adresem ftp://ftp.isi.edu/innotes/rfcxxxx.txt, gdzie xxxx jest numerem dokumentu RFC. Np. dokument RFC 2294 można znaleźć na stronie ftp://ftp.isi.edu/in-notes/rfc2294.txt.
Rozwiązania pokrewne zobacz na stronie: Uwierzytelnianie logowania Stosowanie zabezpieczeń z kluczem publicznym (public key security) systemu Windows 2000
Logowanie interakcyjne Logowanie interakcyjne (interactive logon) za pomocą kart elektronicznych rozpoczyna się, gdy użytkownik włoży kartę elektroniczną (smart card) do czytnika (reader). Jest to znak dla systemu Windows 2000, aby wyświetlić monit o numer PIN, który jest używany do uwierzytelniania tylko w zakresie korzystania z karty elektronicznej, a nie w domenie. Certyfikat z kluczem publicznym zapisany na karcie elektronicznej uwierzytelnia w danej domenie za pomocą protokołu Kerberos 5. Po wprowadzeniu numeru PIN przez użytkownika, system operacyjny rozpoczyna sekwencję działań, aby określić czy użytkownik może być zidentyfikowany i uwierzytelniony na podstawie dostarczonych przez siebie informacji (numer PIN i karta elektroniczna): 1.
Żądanie logowania przechodzi do Lokalnej Jednostki Zabezpieczającej (Local Security Authority — LSA).
2.
Lokalna Jednostka Zabezpieczająca (LSA) przekazuje żądanie logowania do pakietu uwierzytelniającego Kerberos, który pracuje na komputerze-kliencie.
3.
Pakiet Kerberos wysyła żądanie usługi uwierzytelniania (Authentication Service — AS) do usługi Centrum Dystrybucji Kluczy (Key Distribution Center — KDC), działającej na kontrolerze domeny (Domain Controller — DC), aby żądać uwierzytelnienia i biletu gwarantującego bilet (Ticket Granting Ticket — TGT). Jako część żądania usługi uwierzytelniania (AS request) pakiet Kerberos, uruchomiony na komputerze-kliencie, w polu danych uwierzytelniania wstępnego (preauthentication data) żądania usługi, zawiera certyfikat użytkownika X.509v3 odczytany z karty elektronicznej.
Uwaga: Dokument grupy roboczej IETF X.509 certyfikat PKI i dokument listy odwołań certyfikatów (Certificate Revocation List — CRL) Profile specification RFC 2459 można znaleźć pod adresem www.ietf.org/rfc/rfc1459.txt.
4.
Wartość uwierzytelniająca (authenticator), zawarta w polach danych uwierzytelniania wstępnego (preauthentication data) jest opatrzona podpisem cyfrowym za pomocą klucza prywatnego użytkownika, więc Centrum Dystrybucji Kluczy (KDC) może zweryfikować żądanie usługi uwierzytelniania pochodzące od właściciela towarzyszącego certyfikatu.
5.
Centrum Dystrybucji Kluczy weryfikuje ścieżkę certyfikacji (certification path) certyfikatu użytkownika, aby upewnić się, czy może zostać obdarzony zaufaniem, korzystając z interfejsu CryptoAPI do tworzenia ścieżki certyfikacji od certyfikatu użytkownika do certyfikatu głównej jednostki certyfikującej (root CA), znajdującej się w systemowym magazynie głównym (system root store). Jeśli Centrum Dystrybucji Kluczy (KDC) nie zdoła utworzyć poprawnego łańcucha certyfikacji (certificate chain), to zwraca komunikat o błędzie i nie odpowiada na żądanie.
6.
Centrum Dystrybucji Kluczy weryfikuje, czy jednostka certyfikująca wystawiająca (issuing CA) jest upoważniona do wystawiania certyfikatów, których informacje o nazwie mogą być stosowane jako podstawa uwierzytelniania w domenie.
Uwaga: Aby jednostka certyfikująca wystawiająca (issuing CA) była zaufana w celu uwierzytelniania, musi być jednostką certyfikującą przedsiębiorstwa (enterprise CA), opublikowaną w Active Directory. Jest to konieczne, aby zapobiec wystawianiu certyfikatów w przestrzeni nazw (namespace) innej domeny przez jednostkę certyfikującą „oszusta” (rogue CA), która jest zaufana w jednej z hierarchii jednostek certyfikujących (CA hierarchy). Chociaż taki atak jest niezmiernie trudny do przeprowadzenia i zależy od uzyskania prawa wystawiania przez jednostkę certyfikującą „oszusta" od prawowitej nadrzędnej jednostki certyfikującej (parent CA). Opublikowanie jednostki certyfikującej przedsiębiorstwa w Active Directory usuwa niebezpieczeństwo takiego ataku.
7.
Centrum Dystrybucji Kluczy (KDC) korzysta z interfejsu CryptoAPI do weryfikowania podpisu cyfrowego, którym opatrzona jest wartość uwierzytelniająca umieszczona w polach danych uwierzytelniania wstępnego (preauthentication data). Do weryfikowania podpisu służy klucz publiczny (public key) z certyfikatu użytkownika, za pomocą którego można udowodnić, że żądanie zostało wysłane przez właściciela tego klucza publicznego. Ponieważ certyfikat został odczytany z karty elektronicznej i wartość uwierzytelniająca została opatrzona podpisem z zastosowaniem klucza prywatnego, zapisanego na tej karcie, oznacza to, że podpis cyfrowy musi być prawomocny, ponieważ użytkownik musiał zostać uwierzytelniony w zakresie korzystania z karty elektronicznej, aby uzyskać klucz prywatny, za pomocą którego podpisano daną wartość uwierzytelniającą.
8.
Centrum Dystrybucji Kluczy stwierdza ważność znacznika czasu (timestamp) wartości uwierzytelniającej, aby upewnić się, że żądanie nie jest atakiem metodą powtórzenia (replay attack). Ataki metodą powtórzenia omówiono w rozdziale 4.
9.
Centrum Dystrybucji Kluczy wysyła zapytania do usług katalogowych domeny o informacje o koncie (account information). Odczytuje informacje o koncie użytkownika z Active Directory na podstawie nazwy głównej użytkownika (UPN) podanej w polu subject alternative name (alternatywna nazwa tematu) w certyfikacie użytkownika z kluczem publicznym.
10. Informacje o koncie, które centrum (KDC) uzyskuje od usług katalogowych są wykorzystywane do tworzenia biletu gwarantującego bilet (TGT). Są to: identyfikator zabezpieczeń (Security ID — SID) użytkownika, identyfikatory zabezpieczeń (SIDs) każdej z grup domeny, do której należy dany użytkownik oraz identyfikatory zabezpieczeń każdej z grup uniwersalnych, których dany użytkownik jest członkiem (w systemach wielodomenowych). Lista identyfikatorów zabezpieczeń znajduje się w polach danych autoryzacyjnych (authorization data) biletu gwarantującego bilet. 11. Centrum Dystrybucji Kluczy szyfruje bilet gwarantujący bilet (TGT) za pomocą klucza losowego (random key) wygenerowanego specjalnie w tym celu i szyfrowanego za pomocą klucza publicznego (public key), znajdującego się w certyfikacie użytkownika. Zaszyfrowany klucz losowy jest umieszczony w polu danych uwierzytelniania wstępnego odpowiedzi Centrum Dystrybucji Kluczy.
12. Centrum (KDC), stosując swój klucz prywatny (private key), opatruje odpowiedź podpisem, aby klient mógł zweryfikować, czy pochodzi ona od zaufanego Centrum Dystrybucji Kluczy (trusted KDC). 13. Klient weryfikuje podpis Centrum Dystrybucji Kluczy, tworząc najpierw ścieżkę certyfikacji od certyfikatu Centrum Dystrybucji Kluczy do zaufanej głównej jednostki certyfikującej (trusted root CA), a następnie, korzystając z klucza publicznego Centrum Dystrybucji Kluczy, weryfikuje podpis odpowiedzi. 14. Centrum Dystrybucji Kluczy dołącza podpis do danych autoryzacyjnych biletu gwarantującego bilet, korzystając z klucza serwera, który jest następnie opatrzony podpisem za pomocą klucza tajnego (secret key) centrum (KDC), aby "usługa-oszust” nie mogła zmienić danych autoryzacyjnych (authorization data) po wydaniu biletu gwarantującego bilet. 15. Klient po uzyskaniu odpowiedzi z Centrum Dystrybucji Kluczy odczytuje zaszyfrowany klucz losowy, odszyfrowuje go i stosuje do odszyfrowania biletu gwarantującego bilet. 16. Po tym, jak klient stanie się posiadaczem biletu gwarantującego bilet, do wysłania żądania biletu od usługi wydawania biletów (Ticket Granting Service — TGS) dla innych zasobów domeny stosowany jest standardowy protokół Kerberos 5.
Uwaga: Uzupełniające dane uwierzytelniające (credentials) są generowane jako część procesu logowania z użyciem protokołu Kerberos (Kerberos logon), więc nadal można uzyskać dostęp do serwerów pracujących pod kontrolą starszych wersji systemu Windows, np. Windows NT 4. Jest tak nawet, jeśli użytkownik nigdy nie używał hasła na danym komputerze. Kiedy konto jest tworzone, funkcja jednokierunkowa (one-way function) jest generowana i dodawana do atrybutów danego konta, aby korzystać z niej jako uzupełniającej danej uwierzytelniającej (credential) do uwierzytelniania przy połączeniach z serwerem pracującym pod kontrolą wcześniejszej wersji systemu Windows (down-level authentication).
Rozwiązania pokrewne zobacz na stronie: Zastosowanie Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) Podstawowe wiadomości o podprotokołach protokołu Kerberos Analiza biletów protokołu Kerberos
Uwaga: Użytkownik, który jest odłączony od sieci musi nadal być w stanie zalogować się na swoim komputerze. Logowanie musi być również możliwe, gdy kontroler domeny jest nieosiągalny z jakiegokolwiek powodu. W trakcie procesu logowania za pomocą kart elektronicznych (smart card logon), aby można było zalogować się w trybie offline, konieczny jest klucz prywatny użytkownika, który służy do odszyfrowania uzupełniających danych uwierzytelniających (credentials), zaszyfrowanych za pomocą klucza publicznego użytkownika. Jeśli użytkownik posiada wiele kart elektronicznych system musi zagwarantować, że użytkownik ten może zalogować się w trybie offline, niezależnie od tego, której karty użyje, stosując w celu zachowania bezpieczeństwa jednocześnie szyfrowanie i przetwarzanie danych uwierzytelniających za pomocą funkcji mieszającej (hashed credentials).
Logowanie się za pomocą uwierzytelniania klienta Ponieważ obsługa kart elektronicznych (smart cards) łączy w sobie interfejs CryptoAPI oraz protokoły Secure Sockets Layer (SSL) i Transport Layer Security (TLS), nie musi mieć podanych żadnych danych o kartach elektronicznych, aby mogły one pracować poprawnie. W czasie uwierzytelniania klienta (client authentication), na etapie wstępnego negocjowania sesji protokołu SSL (initial SSL session negotiation) karta elektroniczna opatruje podpisem część protokołu. Klucz prywatny odpowiadający danemu certyfikatowi z kluczem publicznym (public key certificate) jest zapisany na karcie elektronicznej, co daje w wyniku silne uwierzytelnienie (string authentication), ponieważ zastosowanie klucza prywatnego wymaga, by posiadacz karty został uwierzytelniony zarówno w zakresie korzystania z karty elektronicznej, jak i w domenie. Oprócz tego działania z kluczem publicznym, w trakcie wstępnego negocjowania sesji uwierzytelnienia wykonywane są na karcie, więc klucz prywatny nie jest nigdy dostępny w sieci ani dla komputera głównego (host computer). Obydwa protokoły, SSL 3 i TLS 1, obsługują uwierzytelnianie wzajemne (mutual authentication) — klient może dokonać uwierzytelnienia serwera, a dany serwer może dokonać uwierzytelnienia tego klienta. W systemie Windows 2000 wprowadzono usługę zabezpieczeń (security service), która korzysta z informacji znajdujących się w certyfikacie klienta do przyporządkowania do kont zapisanych w Active Directory, aby określić prawa dostępu dla klienta uwierzytelnionego. Działania te można wykonać na podstawie nazwy głównej użytkownika (User Principal Name — UPN) umieszczonej w certyfikacie lub przez szukanie w katalogu konta o określonych właściwościach, wydawcy (issuer) lub wydawcy (issuer) i tematu (subject) zamieszczonego w certyfikacie klienta. Proces logowania klienta przebiega w następujący sposób: 1.
Ustanawiana jest sesja protokołu SSL lub TLS.
2.
Usługodawca kanału bezpiecznego (secure channel provider) podejmuje próbę znalezienia konta użytkownika w katalogu domeny na podstawie nawy głównej użytkownika (UPN) zapisanej w certyfikacie, a znajdującej się w polu Alternatywna Nazwa Tematu (Subject Alternative Name) certyfikatu klienta i określającej dokładną nazwę użytkownika i domenę, w której znajduje się dane konto. Jeśli takie konto zostanie znalezione i jeśli jednostka certyfikująca wystawiająca (issuing CA) ma autoryzację do wydawania certyfikatów godnych zaufania dla domeny, to proces logowania będzie kontynuowany.
3.
Jeśli nie znaleziono nazwy zgodnej z podaną nazwą główną użytkownika lub jednostka certyfikująca wystawiająca nie ma właściwej autoryzacji, usługodawca wysyła zapytania do usług katalogowych Active Directory w celu znalezienia konta, którego atrybut Alternatywna Tożsamość Zabezpieczeń (Alternate Security Identities — ASI) zawiera bezpośrednie przypisanie certyfikatu klienta. Takie przypisanie może nastąpić na
podstawie nazwy wydawcy lub nazw wydawcy i tematu zamieszczonych w certyfikacie klienta. Jeśli przypisanie zostanie znalezione, proces logowania będzie kontynuowany.
Uwaga: Konto może mieć jeden lub kilka certyfikatów z nim związanych, umożliwiając w ten sposób wielu użytkownikom zewnętrznym korzystanie z jednego konta. Certyfikat nie może być przypisany do wielu kont.
4.
Po potwierdzeniu tożsamości klienta, serwer ustanawia kontekst zabezpieczeń (security context), określając do których zasobów domeny dany klient ma dostęp.
Logowanie zdalne Usługa dostępu zdalnego (Remote Access Service — RAS) systemu Windows 2000 obsługuje uwierzytelnianie użytkowników zdalnych za pomocą protokołu stosowanego do uwierzytelniania użytkownika (Extensible Authentication Protocol — EAP). Umożliwia to dodawanie modułów uwierzytelniających od innych dostawców i stosowanie wielu metod uwierzytelniania, również kart elektronicznych (smart card). System Windows 2000 zawiera moduł wbudowany do obsługi kart elektronicznych, umożliwiający silne uwierzytelnianie (strong authentication) użytkowników zdalnych. Logowanie zdalne wymaga dwukrotnego uwierzytelniania; jeden raz w celu skorzystania z serwera usługi dostępu zdalnego (RAS server), a drugi raz w sieci. W wyniku pierwszego uwierzytelniania serwer usługi dostępu zdalnego zostaje uwierzytelniony przez klienta i ustanawiane jest połączenie pomiędzy klientem a serwerem. Po ustanowieniu tego połączenia do klienta stosuje się zasady właściwe dla usługi dostępu zdalnego (RAS) oraz atrybuty konta (account attributes), które stosowane są dla konkretnych użytkowników (per-user basis) i obejmują takie właściwości, jak: prawa dostępu (access rights) oraz opcje wywołania zwrotnego (callback options). Drugi proces uwierzytelniania (do domeny) korzysta, zamiast z protokołu Kerberos czy SSL, z protokołu EAP poprzez TLS jako protokołu uwierzytelniania. Uwierzytelnianie do domeny za pomocą protokołu EAP/TLS jest bardzo podobne do uwierzytelniania klienta za pomocą protokołu SSL, oprócz tego, że certyfikat z kluczem publicznym (public key certificate) musi zawierać nazwę główną użytkownika (UPN), która jest zgodna z kontem zapisanym w Active Directory w domenie.
Wskazówka: Istnieje rozróżnienie pomiędzy logowaniem do domeny interakcyjnie, za pomocą połączenia telefonicznego wybranego z okna dialogowego logowania oraz lokalnym zalogowaniem na komputerze-hoście, a następnie połączeniem się z serwerem usługi dostępu zdalnego (RAS server) za pomocą programu Telefon (Dialer). W pierwszym przypadku zasady
domeny (domain policy) będą stosowane do użytkownika i klienta, podczas gdy w drugim przypadku nie. Jeśli użytkownik loguje się zdalnie po raz pierwszy, komputer nie będzie miał zasad domeny, o ile nie został skonfigurowany wstępnie jako członek domeny docelowej. Bez nich klient nie będzie w stanie uwierzytelnić serwera usługi dostępu zdalnego (RAS server), co spowoduje, że wstępne uwierzytelnienie zakończy się niepowodzeniem. Sposobem rozwiązania tego problemu jest początkowe skonfigurowanie komputera-hosta lub zdalne logowanie interakcyjne (remote interactive logon).
Wdrażanie kart elektronicznych Można nie mieć problemów z podłączaniem czytników kart elektronicznych, instalowaniem sterowników i uzyskiwaniem certyfikatów, można znać podstawy teoretyczne i protokoły stosowane przy logowaniu za pomocą kart elektronicznych (smart card logon), ale — jak zwykle — problemy związane są nie z techniką, lecz z ludźmi. W systemie Windows 2000 występuje możliwość łącznego zastosowania kart elektronicznych i technik zabezpieczeń z kluczem publicznym (public key technologies), więc korzystanie z nich jest opłacalne i nie ma konieczności stosowania zewnętrznego zarządzania certyfikatami lub kupowania kosztownego oprogramowania firmowego. Rozważając wprowadzenie kart elektronicznych, należy odpowiedzieć sobie na kilka pytań: •
komu powinno wydawać się karty elektroniczne,
•
czyimi kartami i certyfikatami trzeba zarządzać,
•
jak należy wydawać karty elektroniczne,
•
jaki sprzęt zgodny z systemem Windows 2000 i związany z kartami elektronicznymi jest dostępny?
Wybór użytkowników kart elektronicznych (smart cards) Zwykłym użytkownikom należy wydać karty elektroniczne, a nie hasła. Użytkownicy ci nie wykonują żadnych zadań zaawansowanych, takich jak dołączanie komputerów do domeny czy awansowanie serwera na kontroler domeny (domain controller), a stanowią znaczącą część załogi przedsiębiorstwa. Mogą to być pracownicy wykwalifikowani, dostawcy, kontrahenci i pozostali, którzy nie administrują komputerem ani siecią. Jest to grupa użytkowników, których hasła okazały się trudne do ochrony — zastosowanie kart elektronicznych opłaca się, ponieważ nie będzie już konieczne zarządzanie hasłami użytkowników.
Członkowie grup administratorzy lub użytkownicy zaawansowani (administrators or power users) nie powinni posługiwać się kartami elektronicznymi, ponieważ podejmują oni działania pociągające za sobą wtórne uwierzytelnianie, które wymaga podania nazwy użytkownika, nazwy domeny i hasła. W szczególności uwierzytelnianie za pomocą kart elektronicznych (smart cardbased authentication) nie może być stosowane w sytuacjach, gdy: •
konieczne jest dołączenie komputera do domeny przez danego użytkownika,
•
użytkownik wykonuje zadania administracyjne, takie jak awansowanie (promoting) serwera na kontroler domeny (domain controller),
•
użytkownik konfiguruje połączenia sieciowe, aby można było korzystać z dostępu zdalnego.
W następnych wersjach system Windows 2000 będzie dawał możliwość korzystania w wyżej wymienionych przypadkach z uwierzytelniania za pomocą certyfikatów z kluczem publicznym (public key certificate).
Wskazówka: Chociaż członkowie grup Administratorzy lub Użytkownicy Zaawansowani (Administrators or Power Users) będą mieli konta zabezpieczone hasłem, które służą do wykonywania zadań administracyjnych, powinni również mieć konta jak zwyczajni użytkownicy, z dostępem uzyskiwanym być może za pomocą kart elektronicznych. Wykonując zadanie, np. drukując sprawozdanie, które nie wymaga uprawnień administracyjnych, nie należy logować się jako użytkownik uprzywilejowany. Jeśli użytkownik jest zalogowany na konto administracyjne, wtedy zwiększa się ryzyko ataków, które nie są możliwe, gdy dany użytkownik wyloguje się z tego konta. Trzeba ograniczyć do niezbędnego minimum czas korzystania z konta administratora.
Ustawianie zasad używania kart elektronicznych (smart cards policies) Poniżej opisano ustawianie zasad (policies setting) dotyczących używania kart elektronicznych (smart cards) w obrębie domeny systemu Windows 2000.
Logowanie interakcyjne wymaga karty elektronicznej (smart card required for Interactive logon policy)
W systemie Windows 2000 istnieją zasady kont (account policies) dla konkretnych użytkowników, które narzucają konieczność karty elektronicznej do logowania interakcyjnego. Jeśli ta zasada jest ustanowiona dla danego konta, to użytkownik nie może zalogować się, korzystając z hasła ani interakcyjnie, ani za pomocą wiersza poleceń. Zasada (policy) ta nie dotyczy logowania w przypadku dostępu zdalnego, ponieważ wówczas stosowane są inne zasady skonfigurowane na serwerze usługi dostępu zdalnego (remote access server). Powyższa zasada powinna być ustawiona dla zwykłych użytkowników, którzy do logowania do domeny systemu Windows 2000 używają kart elektronicznych. Zasada ta nie będzie ustanawiana dla członków grup administratorzy lub użytkownicy zaawansowani, którzy w celu wykonania zadań administracyjnych muszą zostać uwierzytelnieni na podstawie hasła podanego przy logowaniu. Rozwiązania pokrewne zobacz na stronie: Zarządzanie zasadami grupowymi
Podczas usuwania karty elektronicznej (on smart card removal) Kiedy użytkownik odchodzi od komputera, na którym jest zalogowany, powinien albo wylogować się albo zablokować (lock) komputer. Jeśli użytkownik tego nie zrobi, a nie będzie wygaszacza ekranu, skonfigurowanego w ten sposób, by blokował dany komputer, wówczas sieć zostanie narażona na atak kogoś, kto ma wszystkie prawa, ale nie tożsamość, zalogowanego aktualnie użytkownika. Częściej zdarza się, że w instytucjach, w których jest więcej użytkowników niż komputerów, inny użytkownik bez wrogich zamiarów może siąść przy komputerze i wnieść poprawki do pliku poprzedniego użytkownika, będąc przekonanym, że korzysta ze swojego pliku. Zasada (policy) Podczas usuwania karty elektronicznej jest zasadą ustanawianą dla konkretnego komputera lokalnego, podczas gdy zasada Do zalogowania się w trybie dialogowym wymagana jest karta elektroniczna (Smart card required for interactive logon) jest ustanawiana dla konkretnego konta. Zasadę tę należy stosować w przypadku komputerów ogólnodostępnych (open floor or kiosk environment) lub w szkołach, gdzie na jeden komputer przypada więcej niż jeden uczeń. W sytuacji, w której dla danego użytkownika przeznaczono jeden lub kilka komputerów wyłącznie do jego dyspozycji, zasada (policy) ta nie musi być ustanawiana.
Rozwiązywanie problemów związanych z kartami elektronicznymi (smart cards)
Ilu jest użytkowników kart elektronicznych, tyle prawdopodobnie pojawi się problemów związanych z tymi kartami. Wspomniane tu zostaną tylko te, które występują najczęściej. Niewielkim pocieszeniem dla administratora może być fakt, że obecnie pojawia się mniej problemów niż 10, a nawet 5 lat temu. Ludzie przyzwyczaili się do korzystania z kart kredytowych czy bankomatowych i numerów PIN, więc związanych z tym problemów powinno być już mniej. Ale ludzie są tylko ludźmi...
Użytkownik pozostawił kartę w domu Co stanie się, kiedy użytkownik zapomni zabrać swoją kartę z domu? Jest kilka sposobów, aby poradzić sobie w takiej sytuacji. Najczęściej stosowane są dwa: •
wydanie tymczasowej karty elektronicznej (temporary smart card) z certyfikatem, który ma krótki okres ważności (zwykle jest to jeden dzień),
•
skonfigurowanie kont użytkowników, aby można było uzyskać dostęp do nich za pomocą haseł i udostępnienie hasła użytkownikowi, który zapomniał swojej karty. Później należy zmienić hasło. W przypadku zastosowania tej metody nie należy ustanawiać zasady (policy) Do zalogowania się w trybie dialogowym wymagana jest karta elektroniczna (Smart card required for interactive logon).
Użytkownik zapomniał numeru PIN W tym przypadku konieczny jest nowy certyfikat karty elektronicznej i nowy numer PIN. Należy również upewnić się, czy stary certyfikat karty elektronicznej znajduje się na Liście Odwołań Certyfikatów (CRL). W przyszłości w coraz większej liczbie kart elektronicznych zamiast numeru PIN będą stosowane dane biometryczne, np. linie papilarne, geometria dłoni, itp.
Użytkownik udostępnił numer PIN osobie postronnej Osoba mająca wrogie zamiary, w przypadku uzyskania numeru PIN stanowi mniejsze zagrożenie, niż gdyby weszła w posiadanie hasła, ponieważ oprócz numeru PIN konieczne jest posiadanie karty elektronicznej. Prawdziwe zagrożenie stanowi osoba mająca wrogie zamiary, która być może przemocą uzyskała i jedno, i drugie. Na razie jedyne, co można zrobić, aby uniknąć takiej sytuacji,
to nadawanie użytkownikom tylko takich praw i uprawnień, jakie są im niezbędnie konieczne. W przyszłości rozwiązaniem będzie korzystanie z danych biometrycznych.
Użytkownik wyciągnął kartę z czytnika przed zakończeniem operacji Na szczęście nowoczesne karty elektroniczne mają specjalne zabezpieczenia (przeciw ciągnięciu — antipulling, nierozrywalne — antitearing), chroniące pamięć karty elektronicznej, jeśli karta zostanie wyciągnięta z czytnika przed zakończeniem wszystkich operacji.
Problemy związane z numerem PIN Hasła mają swoją słabą stronę, ponieważ użytkownicy wybierają takie, które mają być łatwe do zapamiętania. Numer PIN, który jest łatwy do zapamiętania, nie powoduje poważnych problemów z kilku powodów: •
karta elektroniczna jest blokowana po kilku kolejnych próbach wprowadzenia błędnego numeru PIN,
•
numer nigdy nie jest przesyłany poprzez sieć w żadnej postaci,
•
atak metodą powtórzenia (replay attack) jest niezwykle trudny do przeprowadzenia, ponieważ wymaga posiadania karty,
•
w przypadku kart elektronicznych nie jest możliwe przeprowadzenie ataku słownikowego (dictionary attack).
Częste zmiany numeru PIN nie są konieczne, ponieważ karty zostały odpowiednio zaprojektowane i rodzaje ataków ich nie dotyczą. W praktyce użytkownik nie może zmieniać swojego numeru PIN z taką łatwością i częstotliwością, jak to jest w przypadku hasła. Numery PIN mogą być zmieniane wyłącznie jeśli wykonywana jest operacja z zastosowaniem klucza prywatnego (private key operation), a administrator rejestruje się w celu uzyskania certyfikatu karty elektronicznej w imieniu użytkownika. Ograniczenie to występuje z powodu braku standardów zarządzania numerami PIN w systemach operacyjnych korzystających z kart elektronicznych i obecnie nie ma innego wyjścia. Jak już wspominano wcześniej w niniejszym rozdziale, numery PIN zanikną w przyszłości. Rozwój biometrii dostarczy technik opartych na cechach fizycznych użytkownika, takich jak linie papilarne, geometria dłoni, badanie tęczówki czy rozpoznawanie głosu (voice print). Odpowiednia technologia jest już dostępna, ograniczeniem są obecnie koszty.
Wydawanie kart elektronicznych Ponieważ karta elektroniczna jest identyfikatorem zaufanym, podobnie jak identyfikator pracownika (employee badge), w wielu firmach wydaje się tylko ten drugi identyfikator, spełniający również rolę karty elektronicznej (smart card). Uzyskanie identyfikatora wymaga odwiedzenia działu ochrony (security office), gdzie dany pracownik potwierdza swoją tożsamość. Identyfikator będzie zawierać certyfikat karty elektronicznej (smart card certificate) wydany danemu pracownikowi przez firmę. W takim przypadku dział ochrony, a dokładniej mówiąc użytkownik, mający prawa administratora w ramach tego działu, spełnia funkcje jednostki rejestrującej użytkowników (registration authority), rejestrując się w imieniu pracownika (enroll-on-behalf operation), a następnie instalując certyfikat na identyfikatorze pracownika, wykonanym w technologii kart elektronicznych (smart card). Operacja taka stanowi część interfejsu rejestrowania w sieci Web (Web enrollment interface) usługi jednostka certyfikująca (CA) wchodzącej w skład systemów Windows 2000 Server i Windows 2000 Advanced Server. Decyzję zintegrowania zabezpieczeń za pomocą kart elektronicznych z identyfikatorami pracowników należy podjąć, biorąc pod uwagę wymagania przedsiębiorstwa, znajdując równowagę pomiędzy potrzebą większego bezpieczeństwa a użytecznością zastosowanego rozwiązania.
Zabezpieczanie stacji rejestrowania kart elektronicznych (smart card enrollment station) W każdej organizacji musi istnieć stacja rejestrowania kart elektronicznych (smart card enrollment station), która wykonuje operacje rejestrowania się w imieniu użytkowników (enroll-on-behalf) i wydaje certyfikaty kart elektronicznych. Użytkownicy nie mogą rejestrować się w celu uzyskania certyfikatów kart elektronicznych (smart card certificates) wydanych przez usługę jednostka certyfikująca (CA) systemu Windows 2000. Jeśli nie zmodyfikowano uprawnień dostępu w ten sposób, by inni użytkownicy godni zaufania mieli możliwość rejestrowania się, to dostęp do certyfikatów kart elektronicznych mają tylko administratorzy domeny. Jeśli tak nie jest, a użytkownik odejdzie od komputera bez wylogowania się lub zablokowania go, to ktoś mógłby skorzystać z danej sesji logowania i zarejestrować się w celu uzyskania certyfikatu karty elektronicznej, występując jako zalogowany użytkownik.
Aby obsługiwać stację rejestrowania kart elektronicznych systemu Windows 2000, trzeba uzyskać autoryzację jako agent rejestrowania (enrollment agent). W tym celu jednostka certyfikująca może wydać certyfikat agenta rejestrowania wprost dla rejestrowania się w imieniu użytkownika w celu uzyskania certyfikatów (enroll-on-behalf operation). Jest to certyfikat dający największe uprawnienia, ponieważ użytkownik z certyfikatem agenta rejestrowania może zarejestrować się dla uzyskania certyfikatów kart elektronicznych dowolnego użytkownika domeny, łącznie z administratorem. Jak w przypadku wszystkich zagadnień związanych z bezpieczeństwem, należy znaleźć równowagę pomiędzy poziomem zabezpieczeń a użytecznością. W przypadku wydawania kart elektronicznych pracownikom wielkiej firmy może zajść konieczność zarejestrowania się w imieniu kilku tysięcy użytkowników w krótkim czasie. W tej sytuacji najważniejsze jest delegowanie. Jednak po wydaniu kart elektronicznych wielkiej liczbie użytkowników rejestrowanie się (enrolling) w imieniu użytkownika będzie wykonywane sporadycznie. Dlatego można podjąć pewne działania zabezpieczające stację rejestrowania kart elektronicznych (smart card enrollment station): •
nadać prawo rejestrowania się w czyimś imieniu (enroll-on-behalf right) jak najmniejszej liczbie użytkowników zaufanych (trusted users),
•
unieważnić to prawo, gdy tylko zakończy się masowe rejestrowanie,
•
wyłączyć w jednostce certyfikującej (CA) wydawanie certyfikatów agenta rejestrowania (enrollment agent), o ile ten typ certyfikatu nie jest konieczny,
•
uaktywnić inspekcję (auditing) i upewnić się czy za każdym razem, kiedy korzysta się z prawa rejestrowania w imieniu innego użytkownika wysyłane są odpowiednie komunikaty,
•
utworzyć jednostkę certyfikującą wyłącznie do wydawania certyfikatów agenta rejestrowania (enrollment agent) i upewnić się, czy ta jednostka certyfikująca normalnie znajduje się w stanie offline. Ten środek ostrożności jest stosowany w wielkich instytucjach lub w takich, w których niezbędny jest wysoki stopień zabezpieczeń.
Umieszczanie aplikacji na kartach elektronicznych (smart cards) Na kartach elektronicznych oprócz certyfikatów można umieszczać aplikacje przystosowane odpowiednio dla użytkownika danej karty. Istnieją jednak pewne ograniczenia. Zwykle na karcie elektronicznej można zapisać od 2 kB do 8 kB danych, chociaż niektóre mogą pomieścić 16 kB. Należy zachować ostrożność, gdyż niektórzy dostawcy podają pojemność nie w kilobajtach, a w kilobitach. Na karcie będzie zapisany tylko pojedynczy certyfikat (obecnie nie ma możliwości zapisania wielu certyfikatów), a producenci często ograniczają rozmiar pamięci dostępnej dla jednej aplikacji, aby na danej karcie można było umieścić kilka aplikacji lub usług.
Architektura kart elektronicznych dla systemu Windows została zaprojektowana w ten sposób, by w komputerach osobistych można było korzystać z kart elektronicznych z 8 kB pamięci ROM. Jako narzędzia do tworzenia aplikacji stosowane są Visual Basic oraz Visual C++. Architektura ta została opracowana przez grupę roboczą PC/SC, tak więc każdy czytnik zgodny z tym standardem może odczytywać karty elektroniczne przeznaczone dla systemu Windows. Jednak architektura kart elektronicznych dla systemu Windows nie jest jedyną platformą rozwijania systemów, w których korzysta się z kart elektronicznych. Także grupa zadaniowa PC/SC nie jest jedyną grupą opracowującą standardy w tej dziedzinie. Standardy Java Cards i OCF opisane są w dalszej części niniejszego rozdziału.
Wskazówka: Tworzenie aplikacji korzystających z kart elektronicznych (smart cards) i związane z tym problemy opisano dokładnie w następnych trzech podrozdziałach. Wzrost liczby zastosowań kart elektronicznych jest wykładnią i przewiduje się, że w roku 2004 liczba kart elektronicznych znajdujących się w obiegu osiągnie trzy miliardy. Daje to duże możliwości zatrudnienia programującym w języku Visual Basic, Visual C++ lub Java albo tym, którzy chcą zacząć programowanie.
Zastosowanie pakietu Smart Card Software Development Kit Pakiet Smart Card Software Development Kit jest częścią pakietu platformy SDK firmy Microsoft. Pakiet ten zawiera programy narzędziowe i interfejsy API niezbędne do tworzenia aplikacji systemu Windows, korzystające z kart elektronicznych. Pakiet platformy SDK można zainstalować w następujący sposób: 1.
Przejdź na stronę http://msdn.microsoft.com/developer/sdk/paltfor,asp.
2.
Przeczytaj zamieszczony tam spis treści. Szczegółowe informacje o poszczególnych składnikach można uzyskać, klikając odpowiednie łącze (link).
3.
Kliknij opcję Instalowanie Pakietu Platformy SDK (Platform SDK Setup).
4.
Wybierz pozycję Instalacja Niestandardowa (Custom Install). Umożliwi to zainstalowanie środowiska do tworzenia aplikacji, programów przykładowych, dokumentacji i dodatkowych narzędzi programistycznych.
Wskazówka: Więcej informacji o kartach elektronicznych, a szczególnie strona FAQ (Frequently Asked Questions) oraz informacje dla programistów można uzyskać pod adresem www.microsoft.com/security/tech/smartcards/ i korzystając z zamieszczonych tam łączy (links).
Pakiet Smart Card SDK zawiera następujące interfejsy COM (Component Object Model interfaces): •
IbyteBuffer — do obsługi obiektu typu strumień (stream object),
•
ISCard — otwiera i zarządza połączeniem z kartą elektroniczną (smart card),
•
ISCardCmd — wykonuje operacje na bazie danych Menedżera Zasobów Karty Elektronicznej (Smart Card Resource Manager),
•
ISCardFileAccess — wykonuje najczęściej spotykane usługi związane z plikami, takie jak znajdowanie (locating), wybieranie (selecting), odczytywanie z pliku, zapisywanie do pliku, tworzenie i usuwanie plików,
•
ISCardISO7816 — tworzy polecenie protokołu APDU (Application Protocol Data Unit),
•
ISCardLocate — lokalizuje kartę elektroniczną,
•
ISCardManage — zarządza systemem kart elektronicznych,
•
ISCardTypeConv — zamienia typy danych i zarządza obiektami IStream,
•
ISCardVerify — potwierdza lub zmienia zasady (policies) Card Holder Verification (CHV).
IbyteBuffer Interfejs IbyteBuffer służy do odczytu, zapisywania i zarządzania obiektami typu strumień (stream objects). Obiekt ten jest zasadniczo interfejsem obiektowym (wrapper) obiektu Istream. Nie ma żadnych obowiązujących procedur dotyczących stosowania tego interfejsu. Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint1_86uq.htm
ISCard Interfejs ISCard jest używany do otwierania i zarządzania połączeniem z kartą elektroniczną (smart card). Każde połączenie z kartą wymaga odpowiedniego wystąpienia (instance) interfejsu ISCard. Przy każdym tworzeniu wystąpienia (instance) interfejsu ISCard, musi być dostępny Menedżer zasobów karty elektronicznej, jeśli nie będzie dostępny, wystąpi błąd. Interfejs ISCard jest stosowany do połączenia z kartą elektroniczną, przesłania transakcji (submit a transaction) i zwalniania kart elektronicznych w sposób następujący:
1.
Utwórz interfejs ISCard.
2.
Dołącz go do karty elektronicznej, określając czytnik karty elektronicznej lub za pomocą wcześniej ustanowionego poprawnego dojścia (handle).
3.
Utwórz polecenia transakcji za pomocą interfejsów ISCardCmd i ISCardISO7816.
4.
Użyj interfejsu ISCard, aby przesłać polecenia transakcji (submit the transaction commands) do przetwarzania za pomocą karty elektronicznej.
5.
Za pomocą interfejsu ISCard zwolnij kartę elektroniczną.
6.
Zwolnij interfejs ISCard.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint1_59ic.htm.
ISCardAuth Interfejs ISCardAuth może być użyty w celu uzyskania dostępu do usług uwierzytelniających obsługiwanych przez karty elektroniczne, takich jak uwierzytelnianie aplikacji, uwierzytelnianie kart elektronicznych czy uwierzytelnianie użytkownika. Na ogół interfejs ISCardAuth używany jest w następujący sposób: 1.
Utwórz interfejs ISCardAuth za pomocą odpowiedniej metody (method) interfejsu ISCardManage.
2.
Wywołaj odpowiednią metodę ISCardAuth (APP_Auth,GetChallenge, ICC_Auth lub User_Auth).
3.
Zwolnij interfejs ISCardAuth.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint1_1giw.htm.
ISCardCmd Interfejs ISCardCmd służy do tworzenia i zarządzania protokołem APDU (Application Protocol Data Unit) karty elektronicznej. Interfejs korzysta z dwóch buforów: •
bufor APDU — zawiera kolejne polecenia, które będą wysyłane do danej karty,
•
bufor APDUReplay — zawiera dane przesłane z karty po wykonaniu poleceń protokołu APDU. Dane te określane są jako powrotne APDU (return APDU).
Interfejs ISCardCmd jest używany do tworzenia protokołu APDU w następujący sposób: 1.
Utwórz interfejs ISCard i połącz z kartą elektroniczną.
2.
Utwórz interfejs ISCardCmd.
3.
Utwórz polecenia protokołu APDU karty elektronicznej (smart card APDU command) za pomocą ISCardISO7816 lub jednej z odpowiednich metod ISCardCmd.
4.
Wykonaj polecenie na karcie elektronicznej, wywołując odpowiednią metodę interfejsu ISCard.
5.
Oceń zwróconą odpowiedź.
6.
W razie potrzeby powtórz procedurę.
7.
Zwolnij interfejs ISCardCmd i inne wywołane w trakcie procedury.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint1_351w.htm.
ISCardDatabase Interfejs ISCardDatabase wykonuje operacje na bazie danych Menedżera Zasobów Karty Elektronicznej (Smart Card Resource Manager). Operacje te obejmują tworzenie list znanych kart elektronicznych (smart cards), czytników i grup czytników oraz pobieranie (retrieving) interfejsów obsługiwanych przez kartę elektroniczną i jej usługodawcę podstawowego (primary service provider).
Uwaga: Identyfikatorem Usługodawcy Podstawowego (Primary Service Provider) jest unikatowy identyfikator globalny COM (COM GUID), który identyfikuje i stosuje obiekty COM (COM objects) dla konkretnej karty.
W zamieszczonej poniżej procedurze interfejs ISCardDatabase jest używany do tworzenia listy wszystkich znanych kart elektronicznych: 1.
Utwórz interfejs ISCardDatabase.
2.
Wywołaj funkcje ListCards do odczytania wszystkich znanych kart elektronicznych na podstawie ich ciągów znaków ATR (ATR strings) lub obsługiwanych interfejsów.
Uwaga: Ciąg znaków ATR (ATR string) jest to sekwencja bajtów odczytana z karty elektronicznej, gdy jest ona uaktywniana. Bajty te są stosowane do identyfikowania karty.
3.
Zwolnij interfejs ISCardDatabase.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint1_5hk5.htm.
ISCardFileAccess Interfejs ISCardFileAccess jest stosowany do implementowania interfejsu wyższego poziomu do systemu plików opartego na kartach elektronicznych (card-based file system) za pomocą systemu plików tych kart, utworzonych na podstawie struktury i określonych normą ISO/IEC 7816-4. Interfejs ten ma funkcje umożliwiające lokalizowanie podanych plików i wykonywanie podstawowych operacji, takich jak wybieranie, odczytywanie, zapisywanie, tworzenie i usuwanie. Interfejs ISCardFileAccess hermetyzuje (encapsulates) i ukrywa większość szczegółów niższego poziomu (low-level) związanych z wykonywaniem wyżej wymienionych operacji na poziomie karty. Poniżej opisano procedurę zastosowania interfejsu ISCardFileAccess do wyboru, otwarcia i zapisania do pliku: 1.
Za pomocą wywołania ISCardManage::CreateFileAccess utwórz interfejs ISCardFileAccess.
2.
Wywołaj Otwórz (Open), aby wybrać i otworzyć plik.
3.
Wywołaj Pisz (Write).
4.
Wywołaj Zamknij (Close).
5.
Zwolnij interfejs ISCardFileAccess.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint2_348j.htm.
ISCardISO7816 Interfejs ISCardISO7816 jest implementacją funkcji określonych przez normę ISO 7816. Za wyjątkiem metody ISCardISO7816::SetDefaultClassID, interfejs ten tworzy polecenia APDU (APDU command), ukryte (encapsulated) w obiekcie ISCardCmd.
Uwaga: Specyfikacja ISO 7816-4 określa standardowe polecenia dostępne na kartach elektronicznych. Specyfikacja ta definiuje również sposób tworzenia polecenia APDU (APDU command) karty elektronicznej i wysyłania go do karty, aby tam zostało wykonane. Interfejs ISCardISO7816 automatyzuje wymieniony powyżej proces tworzenia.
W poniższym przykładzie interfejs ISCardISO7816 zastosowano do tworzenia polecenia APDU (APDU command), aby przesłać transakcję (submit a transaction) do określonej karty: 1.
Utwórz interfejs ISCardISO7816 i interfejs ISCardCmd, który jest stosowany do hermetyzacji APDU.
2.
Wywołaj odpowiednią metodę interfejsu ISCardISO7816, przekazując wymagane parametry i wskaźnik (pointer) do ISCardCmd. Polecenie APDU zgodne ze specyfikacją ISO 7816-4 zostanie utworzone i ukryte (encapsulated) w interfejsie ISCardCmd.
3.
Zwolnij interfejsy ISCardISO7816 i ISCardCmd.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint2_1trq.htm.
ISCardLocate Interfejs ISCardLocate służy do lokalizowania karty elektronicznej na podstawie jej nazwy. W razie potrzeby może wyświetlić interfejs użytkownika karty elektronicznej (smart card user interface).
Uwaga: Interfejs użytkownika karty elektronicznej jest to okno dialogowe, które pozwala użytkownikowi połączyć się z kartą elektroniczną i zastosować ją w danej aplikacji. Użytkownik może skorzystać z tego okna dialogowego do podania konkretnej karty lub szukania karty elektronicznej, która ma zostać otwarta.
W poniższym przykładzie interfejs ISCardLocate zastosowano do utworzenia pakietu danych APDU, który lokalizuje określoną kartę na podstawie jej nazwy: 1.
Utwórz interfejs ISCardLocate.
2.
Wywołaj metodę ConfigureCardNameSearch, aby znaleźć nazwę karty elektronicznej (smart card name).
3.
Wywołaj metodę FindCard, aby znaleźć daną kartę (smart card).
4.
Zinterpretuj wyniki.
5.
Zwolnij interfejs ISCardLocate.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint1_6rc5.htm.
ISCardManage Interfejs ISCardManage służy do dołączania (attach) określonej karty elektronicznej lub czytnika, do tworzenia innych opcjonalnych interfejsów, wykonujących funkcje specjalne związane z kartami elektronicznymi, do blokowania konkretnej karty, do wyłącznego użytku oraz do określania statusu karty elektronicznej lub czytnika. Usługi te podtrzymują ściśle określony kontekst (context), w którym aplikacja może komunikować się z kartą elektroniczną lub czytnikiem. Stosowanie interfejsu ISCardManage w aplikacjach jest obowiązkowe. W poniższym przykładzie interfejs ISCardManage zastosowano, aby połączyć się z kartą elektroniczną: 1.
Utwórz interfejs ISCardManage skojarzony z daną kartą.
2.
Połącz się z kartą elektroniczną poprzez dołączenie określonego czytnika kart (AttachByIFD) lub za pomocą uzyskanego wcześniej dojścia (AttachByHandle).
3.
Utwórz inne interfejsy w celu wykonania operacji związanych z kartami elektronicznymi za pomocą metod CreateAuth, CreateFileAccess, CreateVerify lub CreateInterfejs.
4.
Zwolnij kartę (detach).
5.
Zwolnij interfejs ISCardManage i inne wywoływane w niniejszej procedurze.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint2_88th.htm.
ISCardTypeConv Interfejs ISCardTypeConv obsługuje inne interfejsy COM dla kart elektronicznych, wykonując operacje, takie jak konwersja i tworzenie tablic (array conversion and creation) oraz zarządzanie wskaźnikami. Nie ma ścisłych zasad stosowania interfejsu ISCardTypeConv. Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint2_2pdi.htm.
ISCardVerify Interfejs ISCardVerify służy do zainstalowania programów CHV (Card Holder Verification code) i do weryfikowania użytkownika. Klasa ISCardVerify została zdefiniowana dla aplikacji, które implementują specyficzne zasady (policies) CHV i które zawierają szczegóły wewnętrznej implementacji karty elektronicznej (smart card). W poniższym przykładzie interfejs ISCardVerify zastosowano do zmiany programu CHV (CHV code) karty elektronicznej: 1.
Utwórz interfejs ISCardVerify za pomocą odpowiedniej metody interfejsu ISCardManage.
2.
Wywołaj metodę ChangeCode. Wprowadź nowy program i określ czy jest lokalny, czy globalny oraz czy jest włączony (enabled), czy też wyłączony (disabled).
3.
Zwolnij interfejs ISCardVerify.
Sposoby wykorzystania, włącznie ze składnią programu, można znaleźć na stronie http://msdn.microsoft.com/library/psdk/scard/scint2_5x4p.htm.
Wskazówka: Pobierając pakiet platformy SDK firmy Microsoft, otrzymuje się również próbkę kodu w różnych językach programowania. Jest to przydatne do nauki tworzenia aplikacji związanych z kartami elektronicznymi. Szczególnie warto spędzić czas nad zamieszczonym w pakiecie programem usuwania błędów.
Zastosowanie interfejsów API firmy Microsoft Firma Microsoft dostarcza trzy mechanizmy, które programiści mogą stosować, aby uzyskać dostęp do usług obsługiwanych przez karty elektroniczne: •
CryptoAPI,
•
SCard COM,
•
Microsoft Win32 API.
Wybór mechanizmu zależy od rodzaju aplikacji i możliwości konkretnej karty elektronicznej.
CryptoAPI Interfejs Cryptographic API umożliwia programistom korzystanie z algorytmów kryptograficznych w swoich aplikacjach. Funkcje interfejsu CryptoAPI mogą być stosowane bez wnikania w szczegóły implementacyjne, w ten sam sposób, w jaki korzysta się z bibliotek graficznych, nie wiedząc nic o konkretnej konfiguracji karty graficznej. Interfejs CryptoAPI zawiera zestaw funkcji do szyfrowania danych lub opatrywania ich podpisem cyfrowym, które zapewniają także ochronę klucza prywatnego użytkownika. Niezależne moduły Usługodawców Usług Kryptograficznych (Cryptographic Services Provider — CSP) wykonują wszystkie funkcje kryptograficzne. Jeden z usługodawców CSP, Microsoft RSA Base Provider, jest związany z systemem Windows. Każdy usługodawca usług kryptograficznych zawiera inną implementację interfejsu CryptoAPI. Niektóre z nich zawierają składniki sprzętowe, takie jak karty elektroniczne. W przypadku interfejsu CryptoAPI konieczne jest stosowanie oddzielnego pakietu do tworzenia oprogramowania (development kit) o nazwie CSP Development Kit (CSPDK), dostarczanego przez firmę Microsoft. Z powodu ograniczeń eksportowych rządu USA, pakiet ten dostępny jest tylko na terenie USA i Kanady. Poniżej podano procedurę uzyskania pakietu CSPDK: 1.
Połącz się ze stroną www.microsoft.com/security/tech/cryptoapi/cspdkintrocontent.asp.
Wskazówka: Adres, pod którym można uzyskać CSPDK może ulec zmianie. Jeśli po wpisaniu bezpośrednio adresu URL nie uzyska się połączenia z właściwą stroną, należy przejść do strony www.microsoft.com/security i rozwiń menu Technologie (Technologies) i wybierz pozycję CryptoAPI.
2.
Naciśnij przycisk Zarejestruj Teraz (Register Now), znajdujący się w dolnej części okna.
3.
Wypełnij formularze i zapoznaj się z warunkami umowy licencyjnej.
4.
Pobierz pakiet CSPDK.
5.
Pobierz dokument Microsoft Application Programmers’ Guide. Adres, spod którego można go pobrać, podano w punkcie 1. Subskrybenci MSDN otrzymują go kwartalnie jako część pakietu platformy SDK.
Stosowanie interfejsu CryptoAPI pozwala programistom na korzystanie z funkcji kryptograficznych wbudowanych w system Windows bez znajomości kryptografii ani konkretnych algorytmów kryptograficznych. Np. właściwie napisany program usługodawcy usług kryptograficznych kart elektronicznych (smart card CSP) korzystałby z istniejącego Usługodawcy Usług Kryptograficznych (CSP), takiego jak Microsoft Base Provider, do wykonywania wszystkich operacji związanych z kluczem publicznym i symetrycznym oraz korzystałby z karty elektronicznej do wykonywania operacji z kluczem prywatnym.
SCard COM SCard COM jest implementacją interfejsu niekryptograficznego, dostarczanego przez firmę Microsoft w celu korzystania z ogólnych usług związanych z kartami elektronicznymi z aplikacji napisanych w różnych językach programowania, takich jak C, Microsoft Visual C++, Java czy Microsoft Visual Basic. Zawiera zestaw podstawowych obiektów interfejsu COM, które można zastosować do tworzenia interfejsów, używanych w aplikacjach przeznaczonych dla systemu Windows. Programista może stosować standardowe programy narzędziowe do tworzenia aplikacji i usługodawców korzystających z kart elektronicznych. Aby korzystać z usług konkretnej karty elektronicznej za pomocą obiektów interfejsu COM, programista nie musi mieć szczegółowych informacji o funkcjonowaniu tej karty. Taki rodzaj abstrahowania przyspiesza pisanie aplikacji dla systemu Windows, umożliwiając również obniżenie kosztów tworzenia oprogramowania i uniknięcie szybkiej dezaktualizacji aplikacji, spowodowanej zmianami dokonanymi w kartach.
Win32 Interfejsy API Win32 są interfejsami API na poziomie podstawowym (base level API), umożliwiającymi korzystanie z kart elektronicznych. Aby korzystać z nich efektywnie konieczna jest głęboka wiedza na temat systemu Windows 2000 i kart elektronicznych. Interfejsy te
umożliwiają tworzenie uniwersalnych aplikacji sterujących czytnikami, kartami elektronicznymi i innymi elementami systemów, w których karty zostały zastosowane. Dla programistów, którzy chcą mieć całkowitą kontrolę nad korzystaniem przez aplikację z kart elektronicznych, przeznaczone są rozszerzenia funkcjonalne podstawowego interfejsu API Win32.
Zastosowanie interfejsu Java Card API 2.1 Istnieje rodzaj kart elektronicznych, na których można uruchamiać programy w języku Java. Programy te noszą nawę apletów i mogą być ładowane dynamicznie na kartę elektroniczną po jej wydaniu. Interfejs Java Card API 2.1 definiuje podzbiór instrukcji języka Java, dostosowany do korzystania w urządzeniach z ograniczonym rozmiarem pamięci, takich jak karty elektroniczne. Interfejsy Java Card API 2.1 został zaprojektowany we współpracy z czołowymi producentami kart elektronicznych i jak twierdzi firma Sun Microsystems, zostały przyjęty przez 95% producentów. Komputer wirtualny (virtual machine) Java Card — warstwa oprogramowania, która znajduje się nad właściwym systemem operacyjnym i wykonuje B-kod (bytecode) języka Java — ukrywa przed programistą złożoność i szczegóły konstrukcyjne karty elektronicznej oraz dostarcza znormalizowany zestaw interfejsów API do tworzenia aplikacji dla kart Java (Java Card). Programiści tworzący oprogramowanie dla kart elektronicznych w technologii Java Card mogą wybierać spośród wielu zintegrowanych pakietów do tworzenia programów w języku Java, opracowanych przez czołowe firmy, takie jak Borland, IBM, Microsoft, Sun czy Symantec. Każdy programista, tworzący programy w języku Java, który uzyska stosowną specyfikację, może zostać programistą piszącym aplikacje dla kart Java (Java Cards). Jak już wspomniano wcześniej możliwości zatrudnienia są wprost nieograniczone. Specyfikację Java Card 2.1 Platform i programy przykładowe można uzyskać w następujący sposób: 1.
Połącz się ze stroną o adresie http://java.sun.com/products/javacard.
2.
Kliknij łącze (link) Java Card 2.1 Specification.
3.
Pobierz następujące specyfikacje: •
Java Card 2.1 Runtime Environment (JCRE) specification,
•
Java Card 2.1 Virtual Machine (JCVM) specification,
•
JCVM specification Release Notes,
•
Java Card 2.1 API specification.
Wskazówka: Kompletna specyfikacja Java Card 2.1 Platform jest również dostępna pod adresem http://java.sun.com/products/javacard/htmldoc/index.html.
4.
Wybierając odpowiednie łącze, przejdź do strony sieci Kontakty Pomiędzy Programistami Javy (Web Java Developer Connection).
5.
Jeśli jeszcze nie jesteś zarejestrowanym użytkownikiem, wypełnij formularz rejestracyjny na stronie Java Developer Connection i zarejestruj się (rejestracja jest darmowa).
6.
Pobierz z tej witryny internetowej programy przykładowe, zasoby dla programistów i programy do tworzenia aplikacji. Można również pobrać kody źródłowe, przyłączając się do Java 2 Source Community.
Klikając odpowiednie łącza na stronie Java Developer Connection lub pod adresem http://developer.java.sun.com/developer/onlineTraining/J2EE/Intro/, można znaleźć bardzo dobre „samouczki”, dotyczące implementowania aplikacji napisanych w języku Java. Programy dotyczące aplikacji związanych z kartami elektronicznymi można znaleźć na stronie sieci Web smart card developers association pod adresem www.smartcard.org. Bogate zasoby są dostępne na stronie sieci Web JavaWorld pod adresem www.javaworld.com. Zainteresowane osoby mogą wziąć udział w comiesięcznych konkursach dla programujących w języku Java.
Zastosowanie osnowy aplikacji OpenCard (OpenCard Framework — OCF) W przypadku technologii rozwijającej się, jaką jest technologia kart elektronicznych (smart cards), zarówno programiści jak i dostawcy sprzętu napotykają problemy związane z brakiem powszechnie przyjętych standardów. Od programistów wymaga się pisania różnych wersji aplikacji dla różnych dostawców sprzętu, a często nawet dla różnych wersji tego samego sprzętu. Programowanie w językach niskiego poziomu (low level programming), z braku interfejsów API wyższego poziomu, powoduje że tworzenie programów jest nużące i oznacza, że piszący je muszą wiedzieć, jak działa sprzęt. Programy są nieprzenośne, mają krótki dopuszczalny okres magazynowania (shelf life), utrudnione jest także usuwanie błędów. Dostawcy kart i terminali napotykają problemy z niezgodnością. Czy dostarczany przez nich czytnik będzie współpracował ze wszystkimi rodzajami kart? Czy karty, które produkują, będą współpracować ze wszystkimi czytnikami? Czy zapisane na kartach aplikacje i informacje o zabezpieczeniach, będą zgodne ze wszystkimi systemami operacyjnymi? OpenCard Framework (OCF) może pomóc w rozwiązaniu tych problemów. Wdrażający (implementers) aplikacje i usługi, za pomocą interfejsów OCF mogą stosować swoje rozwiązania
z różnymi ustawieniami, bez konieczności ponownego pisania programu. Dostawcy (providers), stosujący te interfejsy, mogą zaopatrzyć w takie elementy, które będą wykorzystywane bezpośrednio przez programistów. OpenCard Framework przynosi korzyści nie tylko programistom, ale również dostawcom kart i terminali. Poniżej zamieszczono listę korzyści, jakie mają programiści ze stosowania OCF: •
niezależność od dostawcy — programiści mogą wybierać karty i terminale od różnych dostawców,
•
ochrona zasobów (asset protection) — architektura umożliwia programistom udział w rozwijaniu kart elektronicznych,
•
skrócenie czasu tworzenia oprogramowania (improved time-to-market) — programiści, korzystając z interfejsów API wyższego rzędu (high-level API), skracają czas poświęcony na tworzenie oprogramowania,
•
niższe koszty tworzenia oprogramowania — programiści ograniczają koszty przenoszenia aplikacji na różne platformy. Do wykonywania konkretnych zadań nie są również konieczne wysokie kwalifikacje.
Kolejna lista zawiera korzyści, jakie OCF daje dostawcom kart i terminali: •
zwiększenie liczby klientów — dostarczając produkty zgodne ze standardami stosowanymi w przemyśle, można uzyskać dostęp do nowych segmentów rynku,
•
niezależność od dostawcy — dostawcy mogą konkurować zakresem funkcji i nie grozi dominacja jednego producenta,
•
mniejszy nakład pracy na opracowywanie urządzeń — dostawcy dysponujący zestawem funkcji dostarczonym przez OCF, mogą ograniczyć nakład pracy poświęcony na rozwój urządzeń.
Aby umożliwić użytkownikom i programistom zapoznanie się ze standardem OCF, konsorcjum OpenCard udostępniło program demonstracyjny OCF Stockbroker. Jest to pełna wersja demonstracyjna, nie symulacyjna, do której uruchomienia konieczny jest czytnik kart elektronicznych. Celem tego ćwiczenia jest zademonstrowanie łatwości tworzenia aplikacji za pomocą interfejsów API OCF oraz możliwości tworzenia aplikacji niezależnych od rodzaju czytnika zainstalowanego w danym komputerze. Aby pobrać i uruchomić program demonstracyjny należy postępować zgodnie z poniższym opisem: 1.
Przejdź do strony o adresie www.opencard.org/index-downloads.shtml.
2.
Wybierz pozycję OpenCard Framework V1.1.1. Można wybrać plik w wersji skomprymowanej (zipped file) lub samo rozpakowujący się plik klasy (class file).
Uwaga: Z powodu ograniczeń eksportowych nałożonych przez rząd USA, programy oraz interfejsy kryptograficzne OCF nie mogą być pobierane spoza obszaru Ameryki Północnej. Wymieniony wyżej program demonstracyjny pozbawiony jest swojej części kryptograficznej, ale reszta jest taka sama, jak w pełnej wersji.
3.
Wypełnij formularz i przyjmij warunki umowy licencyjnej. Wykonuje się to tylko przy pierwszym pobieraniu.
4.
Jeśli przebywasz na terenie Stanów Zjednoczonych lub Kanady, pobierz część struktury OCF podlegającą ograniczeniom eksportowym. Można wybrać plik w wersji skomprymowanej (zipped file) lub samo rozpakowujący się plik klasy (class file).
5.
Pobierz General Information Web Document i Programmers Guide. Dokumenty te nie są niezbędne do uruchomienia programu demonstracyjnego, ale zawierają użyteczne informacje dodatkowe.
6.
Rozpakuj pobrane pliki lub uruchom samo rozpakowujące się pliki klas (class files) zgodnie z instrukcją podaną na stronie, z której pliki te były pobierane.
Uruchom program Stockbroker i postępuj zgodnie z wyświetlanymi instrukcjami.
Wskazówka: Lista określeń związanych z kartami elektronicznymi znajduje się pod adresem www.gemplus.com/basics/terms.htm. Inne przydatne adresy URL to www.slb.com/smartcards/, www.protekila.com.tr/, www.smartcard.com oraz http://cardtronix.com.
Rozdział 10
Zabezpieczenia protokołu IP Rozwiązania natychmiastowe zobacz na stronie: Analiza działania IPSec Ustawienia IPSec Konfigurowanie IPSec na pojedynczych komputerach Konfigurowanie IPSec dla domeny Zmiana sposobu zabezpieczania Konfigurowanie IPSec dla jednostki organizacyjnej
W skrócie Zabezpieczenia za pomocą IP Security W systemie Windows 2000 Server zaimplementowano zestaw usług i protokołów kryptograficznych IP Security (IPSec) opracowany przez Internet Engineering Task Force (IETF). IPSec znajduje się poniżej poziomu transportowego (transport level) i jego usługi zabezpieczające są dziedziczone niedostrzegalnie przez aplikacje. Dane o znaczeniu strategicznym bez przerwy są przesyłane przez sieć i muszą być zabezpieczone przed podsłuchiwaniem lub modyfikowaniem przez osoby nieupoważnione. Protokoły, takie jak Secure Sockets Layer 3/Transport Layer Security (SSP3/TLS) chronią dane o znaczeniu strategicznym, ale mogą być używane tylko przez niektóre aplikacje, np. przeglądarki (browsers). Do zapewnienia bezpieczeństwa sieci wykorzystującej protokół TCP/IP po obydwu stronach zapory ogniowej (firewall) przedsiębiorstwa niezbędny jest protokół niskiego poziomu (low level protocol). Warunek taki spełnia IPSec, który, zapewniając spójność, poufność i uwierzytelnianie danych umożliwia również ochronę przez atakami metodą powtarzania (replay attacks) (zob. rozdz. 4.) oraz rozszerzenie obsługi szyfrowania na Wirtualne Sieci Prywatne (Virtual Private Networks — VPN) (zob. rozdz. 11.). Większość stosowanych zabezpieczeń, takich jak zapory ogniowe czy routery zabezpieczone (secure routers), pozwalają uchronić się przed atakami z zewnątrz. Sieci komputerowe w przedsiębiorstwach narażone są jednak na ataki od wewnątrz, dokonywane przez niezadowolonych pracowników lub kontrahentów. IPSec umożliwia obronę zarówno przed atakami z zewnątrz, jak i od wewnątrz.
Właściwości IPSec W IPSec wprowadzono nagłówek uwierzytelniania (Authentication Header — AH) i protokół ESP (Encapsulating Security Payload). Nagłówek uwierzytelniania (AH) umożliwia przesyłanie danych z uwierzytelnianiem źródła (source authentication) i sprawdzaniem integralności (integrity checking). Protokół ESP zapewnia poufność (confidentiality). W przypadku transmisji danych chronionej za pomocą IPSec tylko nadawca i odbiorca znają klucz zabezpieczeń (security key). Jeśli dane uwierzytelniające (authentication data) są poprawne, odbiorca wie, że dane pochodzą od właściwego nadawcy i nie zostały zmienione w trakcie przesyłania.
IPSec obsługuje standardy opracowane przez IETF oraz protokoły zabezpieczeń (security protocols).
Obsługiwane standardy branżowe IPSec obsługuje standardowe algorytmy kryptograficzne i techniki uwierzytelniania, włącznie z niżej wymienionymi: •
algorytm Diffie-Hellmana (DH),
•
algorytm HMAC (Hash Message Authentication Code),
•
algorytm DES-CBC (Data Encryption Standard-Cipher Block Chaining).
Algorytm Diffie-Hellmana (DH) Algorytm Diffie-Hellmana (DH) jest algorytmem kryptograficznym z kluczem publicznym (public key cryptography algorithm) umożliwiającym komunikującym się stronom uzgodnienie klucza tajnego (shared key). Algorytm ten rozpoczyna się od wymiany informacji jawnych pomiędzy komunikującymi się stronami. Następnie każda ze stron łączy informację jawną, otrzymaną od drugiej strony, z własnymi danymi tajnymi, generując klucz tajny (shared secret value).
Algorytm HMAC (Hash Message Authentication Code) Algorytm HMAC jest algorytmem z kluczem tajnym (secret key algorithm) umożliwiającym integralność (integrity) oraz uwierzytelnianie (authentication). Do uwierzytelniania stosuje się funkcję skrótu z kluczem tajnym (keyed hash function), dołączając w ten sposób do pakietu podpis cyfrowy, który może zostać zweryfikowany przez odbiorcę. Jeśli komunikat ulegnie zmianie podczas transmisji, zmieni się skrót (hash value) i pakiet protokołu IP zostanie odrzucony. IPSec korzysta z dwóch funkcji skrótu algorytmu HMAC: •
HMAC-MD5 — Message Digest function 95 (MD5), jest funkcją skrótu (hash function), która daje w wyniku wartości 128-bitowe,
•
HMAC-SHA1 — Secure Hash Algorithm (SHA), jest to funkcja skrótu (hash function), która daje w wyniku wartości 160-bitowe. Algorytm HMAC-SHA1 jest wolniejszy niż HMAC-MD5, ale bezpieczniejszy.
Uwaga: Pojawiły się wątpliwości co do bezpieczeństwa funkcji skrótu MD5, szczególnie w środowisku, w którym możliwe są kolizje (Hans Dobbertin „RIPEMD with two-round compress function is not collision-free”, Journal of Cryptology 10(1): 51-70, Winter 1997), ale nie dotyczy to algorytmu HMAC-MD5. Należy jednak pamiętać, że nic nie jest całkowicie bezpieczne. Żadna informacja, przetworzona za pomocą funkcji skrótu (hashed information) nie jest bezpieczna na zawsze. Specjaliści z dziedziny bezpieczeństwa systemów komputerowych wiedzą, że nie ma nic bardziej niebezpiecznego niż zabezpieczenia, które już nie zapewniają bezpieczeństwa, a użytkownicy nadal w nie wierzą. Bezpieczeństwo systemów komputerowych powinno zawsze stanowić ruchomy cel.
Algorytm DES-CBC (Data Encryption Standard-Cipher Block Chaining) Algorytm DES-CBC (Data Encryption Standard-Cipher Block Chaining) jest algorytmem z kluczem tajnym (secret key algorithm), stosowanym w celu zapewnienia poufności (confidentiality). Do zaszyfrowania danych używany jest klucz tajny (secret key) razem z wygenerowaną liczbą losową.
Wskazówka: Więcej informacji na temat algorytmu DH można znaleźć pod adresem ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc. Opis algorytmu HMAC można znajduje się na stronie http://drax.isi.edu/in-notes/rfc/files/rfc2104.txt. Opis algorytmu DES-CBC zamieszczono pod adresem http://www.kashpureff.org/nic/rfcs/1800/rfc1829.txt.html oraz http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2405.txt.
Implementacja IPSec w systemie Windows 2000 jest zgodna z propozycjami standardu opracowanymi przez IETF w ramach grupy roboczej IPSec. Oprócz tego w skład IPSec wchodzi protokół ISAKMP (Internet Security Association and Key Management Protocol), w którym zastosowano protokół wyznaczania klucza Oakley (Oakley Key Determination protocol), umożliwiający automatyczne generowanie nowych kluczy w trakcie wymiany danych (dynamic rekeying). Protokół ISAKMP/Oakley jest używany do tworzenia skojarzeń zabezpieczeń (Security Associations — SAs) pomiędzy komunikującymi się komputerami. Skojarzenia zabezpieczeń opisano w dalszej części niniejszego rozdziału.
Protokoły zabezpieczeń W implementacji IPSec w systemie Windows 2000 zastosowano następujące protokoły zabezpieczeń:
•
protokół ISAKMP (Internet Security Association and Key Management Protocol),
•
protokół wyznaczania klucza Oakley (Oakley Key Determination),
•
nagłówek uwierzytelniania protokołu IP (IP Authentication Header),
•
protokół ESP (IP encapsulating security protocol).
Protokół ISAKMP (Internet Security Association and Key Management Protocol) Zanim pakiety protokołu IP zostaną przesłane, za pomocą IPSec musi zostać ustanowione skojarzenie zabezpieczeń (Security Association — SA)pomiędzy komunikującymi się komputerami. Protokół ISAKMP definiuje ogólne zasady ustanawiania skojarzenia zabezpieczeń zgodnie z opisem zamieszczonym w dalszej części niniejszego rozdziału.
Protokół wyznaczania klucza Oakley (Oakley Key Determination) Protokół Oakley jest protokołem wyznaczania klucza, korzystającym z algorytmu wymiany kluczy Diffie-Hellmana (DH key exchange algorithm). Protokół ten ma opcję Perfect Forward Secrecy (PFS), która gwarantuje, że jeśli pojedynczy klucz zostanie złamany, otwarty zostanie dostęp tylko do danych zabezpieczonych tym kluczem. Klucz ten i liczba, która posłużyła do jego wygenerowania (key generation material) nie będą nigdy wykorzystane do generowania innych kluczy. Rozwiązania pokrewne zobacz na stronie: Konfigurowanie protokołów z kluczami tajnymi (shared secrets protocol) Zastosowanie centrum dystrybucji kluczy (KDC)
Nagłówek uwierzytelniania protokołu IP (IP Authentication Header) Nagłówek uwierzytelniania protokołu IP (IP Authentication Header) zapewnia integralność (integrity), uwierzytelnianie i zapobiega atakom metodą powtórzenia (anti-replay), stosując w tym celu algorytm obliczania skrótu z kluczem tajnym (keyed message hash), HMAC, dla każdego pakietu protokołu IP.
IP Encapsulating Security Protocol Protokół ESP (IP Encapsulating Security Protocol) zapewnia poufność (confidentiality), korzystając w tym celu z algorytmu DES-CBC.
Skojarzenia zabezpieczeń (Security Associations — SAs) Skojarzenia zabezpieczeń (SAs) określają wspólne usługi, mechanizmy i klucze stosowane do ochrony wymiany danych. Security Parameters Index (SPI) jest unikatowym identyfikatorem, który pozwala na rozróżnienie pomiędzy wieloma skojarzeniami zabezpieczeń na komputerzeodbiorcy. Wiele skojarzeń zabezpieczeń występuje, gdy dany komputer komunikuje się bezpiecznie z wieloma komputerami jednocześnie, np., kiedy serwer plików (file server) lub serwer usługi dostępu zdalnego (remote access server) obsługuje wiele klientów. Wiele skojarzeń zabezpieczeń może występować także pomiędzy dwoma komputerami. Grupa IETF ustanowiła standard w zakresie skojarzeń zabezpieczeń (Security Associations) i wymiany kluczy (key exchange) do tworzenia skojarzeń zabezpieczeń pomiędzy komputerami. Metoda ta łączy w sobie protokół ISAKMP oraz protokół generowania kluczy Oakley (Oakley Key Generation protocol). Protokół ISAKMP umożliwia scentralizowane zarządzanie skojarzeniami zabezpieczeń (SA management) i skrócenie czasu potrzebnego na połączenie (connection time). Protokół Oakley służy do generowania i zarządzania kluczami uwierzytelnionymi, używanymi do zabezpieczania danych. Proces ten ochrania również komputery zdalne (remote computers), które żądają dostępu do sieci firmowej lub w każdej sytuacji, w której negocjowanie komputera docelowego (punktu końcowego — endpoint) jest prowadzone przez router zabezpieczony (security router) lub inny serwer Proxy. W drugim przypadku, określanym jako tryb klienta protokołu ISAKMP (ISAKMP client mode), tożsamości (identities) punktów końcowych są ukryte. Aby zapewnić poprawną i bezpieczną komunikację protokół ISAKMP/Oakley wykonuje operację w dwu etapach: •
faza wymiany kluczy (key exchange phase),
•
faza ochrony danych (data protection phase).
Proces taki zapewnia poufność (confidentiality) i uwierzytelnianie (authentication) w poszczególnych fazach za pomocą wynegocjowanych przez dwa komputery algorytmów szyfrowania i uwierzytelniania.
Faza wymiany kluczy (key exchange phase) W fazie tej dwa komputery ustanawiają skojarzenie zabezpieczeń protokołu ISAKMP. Protokół Oakley zapewnia ochronę tożsamości (identity protection) w trakcie tej wymiany, umożliwiając uzyskanie całkowitej poufności. Pomaga to zapobiegać atakom w sieci, które polegają na przejęciu tożsamości (identities), takim jak podszywanie się (spoofing). Przebieg negocjacji w fazie wymiany kluczy jest następujący: 1.
Negocjowane są: •
algorytm szyfrowania (DES, 3DES lub bez szyfrowania),
•
algorytm zapewniający integralność (integrity algorithm) (MD5 lub SHA1),
•
metoda uwierzytelniania: certyfikat z kluczem publicznym (public key certificate), klucz wstępny (preshared key) lub protokół Kerberos 5,
•
grupa Diffie-Hellmana (Diffie-Hellman group).
2.
Wymieniane są informacje konieczne do wygenerowania klucza tajnego (shared secret key) lub klucza głównego (master key) dla skojarzenia zabezpieczeń (SA) protokołu ISAKMP.
3.
Komputery uwierzytelniają wymianę danych koniecznych do wygenerowania klucza (key information exchange). Stosowany jest klucz główny w połączeniu z algorytmami ustalonymi w punkcie1. Niezależnie od zastosowanej metody uwierzytelniania, przesyłane dane nie mogą być przechwycone ani zmienione.
Komputer inicjujący wymianę przedstawia komputerowi odpowiadającemu listę możliwych poziomów zabezpieczeń. Komputer odpowiadający nie może zmodyfikować tej listy. Jeśli lista zostanie zmieniona, to komputer inicjujący odrzuci komunikat przesłany przez komputer odpowiadający. Komputer odpowiadający wysyła w odpowiedzi komunikat akceptujący przedstawioną listę lub wskazujący, że nie wybrano żadnej pozycji z tej listy. W drugim przypadku proces rozpocznie się od nowa.
Faza ochrony danych (data protection phase) Komunikaty negocjacyjne (negotiation messages) są automatycznie wysyłane pięciokrotnie. Po upływie trzech sekund ustanowione zostaną tymczasowe skojarzenia zabezpieczeń (soft SA). Jeśli odpowiedź protokołu ISAKMP zostanie odebrana przed upływem czasu cyklu, tymczasowe skojarzenia zabezpieczeń są usuwane i rozpoczynają się standardowe negocjacje skojarzeń zabezpieczeń (SA). Negocjowana jest para skojarzeń zabezpieczeń, określana jako skojarzenia zabezpieczeń IPSec (IPSec SAs). Proces jest prawie identyczny z negocjowaniem wymiany kluczy. Jednak jeśli w trakcie negocjowania pary skojarzeń zabezpieczeń (SAs) zostanie przekroczony ustalony czas, podejmowana jest próba renegocjowania. Natomiast, gdy odebrany
zostanie komunikat należący do fazy ochrony danych bez ustanowienia skojarzenia zabezpieczeń protokołu ISAKMP, to komunikat ten zostanie odrzucony.
Okres ważności skojarzeń zabezpieczeń (SA lifetimes) Kiedy upłynie okres ważności klucza głównego (master key) lub klucza sesji (session key), renegocjowane jest odpowiadające im skojarzenie zabezpieczeń, a stare skojarzenie (SA) protokołu ISAKMP zostanie oznaczone jako nieważne. Zapobiega to tworzeniu fałszywych skojarzeń zabezpieczeń IPSec (IPSec SA) na podstawie starych. Kiedy agent zasad IPSec (IPSec policy agent) pobiera aktualizacje zasad (policy updates) zaktualizuje listę filtrów IP (IP filter) zapisaną w sterowniku IPSec. Każde ze skojarzeń zabezpieczeń (SA) związane ze starymi filtrami, których już nie ma w zasadach, zostanie usunięte razem ze starymi filtrami, znajdującymi się w buforze sterownika IPSec. Jeśli komputer znajduje się w stanie hibernacji lub wstrzymania i wówczas upłynie okres ważności skojarzenia zabezpieczeń (SA), to skojarzenia (SAs) będą automatycznie renegocjowane po uaktywnieniu komputera. Jeśli system Windows 2000 jest zamykany, protokół Oakley usuwa wszystkie pozostałe skojarzenia zabezpieczeń i renegocjowane są nowe. Jeśli system Windows 2000 zakończy pracę w sposób nieprawidłowy, stare skojarzenia zabezpieczeń mogą nadal istnieć, o ile nie upłynął domyślny okres ważności. Jeśli tak się stanie, te skojarzenia (SA) muszą zostać usunięte ręcznie.
Rozwiązania natychmiastowe Analiza działania IPSec
Przed podaniem ustawień IPSec i skonfigurowaniem zasad IPSec (IPSec policy) konieczne jest poznanie zasady działania IPSec. Załóżmy, że użytkownik na komputerze o nazwie Laurel wysyła komunikat do użytkownika na komputerze o nazwie Hardy. Procedura jest następująca: 1.
Sterownik IPSec (IPSec driver) na komputerze Laurel sprawdza listę filtrów IP (filter IP) aktywnej zasady (policy), aby znaleźć pozycję zgodną z adresem lub rodzajem ruchu w sieci (traffic type) pakietów wychodzących.
2.
Sterownik IPSec wysyła do usługi ISAKMP komunikat powiadamiający o rozpoczęciu negocjowania zabezpieczeń z komputerem o nazwie Hardy.
3.
Usługa ISAKMP na komputerze o nazwie Hardy odbiera żądanie negocjowania zabezpieczeń.
4.
Obydwa komputery wymieniają klucze (key exchange), ustanawiają skojarzenia zabezpieczeń (SAs) protokołu ISAKMP oraz ustalają klucz tajny (shared secret key).
5.
Obydwa komputery negocjują poziom zabezpieczeń transmisji danych, ustanawiają parę skojarzeń zabezpieczeń IPSec (IPSec SA) oraz klucze do zabezpieczania pakietów protokołu IP.
6.
Za pomocą wychodzącego skojarzenia zabezpieczeń IPSec (outbound IPSec SA) oraz klucza, sterownik IPSec na komputerze o nazwie Laurel opatruje pakiety podpisem cyfrowym, aby zapewnić ich integralność (integrity) oraz szyfruje pakiety, jeśli wynegocjowano poufność (confidentiality) transmisji.
7.
Sterownik IPSec na komputerze o nazwie Laurel przekazuje pakiety do odpowiedniego rodzaju połączenia (connection type), aby przesłać je do komputera o nazwie Hardy.
8.
Komputer o nazwie Hardy odbiera pakiety zabezpieczone (secured packets) i przekazuje je do sterownika IPSec (IPSec driver).
9.
Za pomocą przychodzących skojarzeń zabezpieczeń (inbound SA) oraz klucza, sterownik IPSec sprawdza podpis, mający zagwarantować integralność i w razie konieczności odszyfrowuje pakiety.
10. Sterownik IPSec na komputerze o nazwie Hardy przekazuje odszyfrowane pakiety do sterownika protokołu TCP/IP, który z kolei przekazuje je do aplikacji-odbiorcy. Proces ten jest niezauważalny dla użytkownika. Routery lub przełączniki (switches) na ścieżce danych (data path) pomiędzy komputerami nie wymagają IPSec i będą automatycznie przekazywać zaszyfrowane pakiety protokołu IP do adresata. Jednak jeśli router pracuje jako zapora ogniowa (firewall), brama zabezpieczeń (security gateway) lub serwer Proxy, musi zostać włączone filtrowanie specjalne, aby zabezpieczone pakiety protokołu IP (secured IP packets) nie były odrzucane. W tym przypadku dla połączenia internetowego muszą zostać określone następujące filtry wejściowe i wyjściowe: Filtry wejściowe
IP Protocol ID 51 (0x33) dla przychodzącego nagłówka uwierzytelniania (AH) IPSec (inbound IPSec AH) IP Protocol ID 50 (0x32) dla przychodzącego protokołu ESP IPSec (inbound IPSec ESP)
UDP port 500 (0x1F4) dla przychodzących negocjacji ISAKMP/Oakley (inbound ISAKMP/Oakley negotiations traffic) Filtry wyjściowe
IP Protocol ID 51 (0x33) dla wychodzącego nagłówka uwierzytelniania (AH) IPSec (outbound IPSec AH) IP Protocol ID 50 (0x32) dla wychodzącego protokołu ESP IPSec (outbound IPSec ESP) UDP port 500 (0x1F4) dla wychodzących negocjacji ISAKMP/Oakley (outbound ISAKMP/Oakley negotiations traffic).
Konfigurowanie wymienionych powyżej filtrów opisane jest w dokumentacji routera.
Ustawienia IPSec W zależności od stopnia ważności (sensitivity) danych, względnej podatności medium transmisyjnego na uszkodzenia (relative vulnerability of the transmission carrier) oraz ograniczeń eksportowych odnoszących się do poszczególnych poziomów szyfrowania, można określić ustawienia IPSec, czyli atrybuty (attributes) odpowiednie w danej sytuacji. Każdy z zestawów atrybutów IPSec nosi nazwę zasad zabezpieczeń (security policy). Zasady te są tworzone na podstawie związanych z nimi zasad negocjacji (negotiation policies) oraz filtrów protokołu IP (IP filters) i mogą być przypisane do domeny, pojedynczego komputera lub jednostek organizacyjnych (OUs). Filtry protokołu IP (IP filters), na podstawie adresata i protokołu pojedynczych pakietów IP, określają jakie operacje należy wykonać.
Wskazówka: Poniższa procedura jest ćwiczeniem na papierze. Niemniej jednak jest niezbędnym etapem na drodze do ustanowienia solidnych zasad IPSec (IPSec policy). Zanim dojdzie do etapu wdrażania zasad zabezpieczeń, należy je zaplanować na papierze. Cechą dobrego specjalisty z dziedziny zabezpieczeń jest to, że zanim podejdzie do komputera, planuje wszystko bardzo szczegółowo na papierze.
Poniżej zamieszczono procedurę określania ustawień IPSec: 1.
Wybierz poziom zabezpieczeń (security level). Opcje są następujące: •
Klient (tylko odpowiada) (Client; respond only) — wysyła żądania niezabezpieczone, ale zabezpiecza odpowiedzi na żądania transmisji danych zabezpieczanych za pomocą IPSec, zabezpieczając protokół i port dla tych żądań. Komputery, na których zastosowano tę zasadę (policy), nie mogą komunikować się z komputerami, na których zastosowano zasadę serwera zabezpieczeń (security server),
2.
•
Serwer (żądaj zabezpieczeń) (Server; request security) — akceptuje niezabezpieczoną transmisję danych, ale podejmuje próbę zabezpieczenia komunikacji, żądając zabezpieczeń od nadawcy. Jeśli zostanie przekroczony czas negocjacji (40 sekund), dozwolone jest przesyłanie danych zabezpieczonych,
•
Serwer z zabezpieczeniami (zabezpieczenia wymagane) (Secure server; require security) — odrzuca niezabezpieczone dane przychodzące i zabezpiecza wszystkie komunikaty wychodzące. Komunikacja zostanie zablokowana jeśli zabezpieczenia nie zostaną ustalone z komputerem-partnerem (per komputer).
Określ tryb transportu (transport mode) lub tryb tunelowania (tunnel mode): •
Tryb transportu (Transport mode) — zabezpiecza transmisję danych pomiędzy komputerami równorzędnymi (per computers). Jest to domyślny tryb IPSec, zapewniający bezpieczeństwo na całej drodze danych pomiędzy komputerem-nadawcą a komputerem (lub komputerami) odbierającymi dane. Tryb transportu może być stosowany przez komputery komunikujące się przez serwer dostępu zdalnego (Remote Access Server — RAS) i w intranecie, w przypadku zastosowania routerów . Stosowanie tego trybu nie jest wskazane jeśli komunikaty muszą przechodzić przez sieci zewnętrzne lub przez wrogie środowisko, takie jak Internet,
•
Tryb tunelowania (Tunnel mode) — zabezpiecza transmisję danych pomiędzy sieciami zdalnymi (remote networks). Wprowadza zasady IPSec dla transmisji danych przez Internet i obsługuje połączenia point-to-point. Uwierzytelnia i szyfruje dane przesyłane przez tunel IP (IP tunnel) utworzony pomiędzy dwoma urządzeniami logicznymi (logical devices). Zwykle są to komputery lub routery RRAS (Routing and Remote Access Services) dla systemu Windows 2000. Punkty końcowe tunelu (tunnel endpoints) określa się podając adres IP lub nazwę hosta. Tunelowanie (tunneling) i Wirtualne Sieci Prywatne (Virtual Private Networks — VPNs) opisano w rozdziale 11.
Rozwiązania pokrewne zobacz na stronie: Określanie strategii wirtualnych sieci prywatnych (VPN Strategy)
OSTRZEŻENIE! Tunelowanie IPSec (IPSec tunneling) określa komputery jako punkty końcowe (endpoints) i do sprawdzania poprawności korzysta z certyfikatów komputerów, a nie certyfikatów użytkowników. Każdy użytkownik, który ma dostęp do komputera — punktu końcowego, ma także dostęp do tunelu, a to stanowi zagrożenie. Rozwiązaniem tego problemu jest zastosowanie protokołu PPTP (Point-To-Point Tunneling Protocol) lub protokołu L2TP (Layer 2 Tunneling Protocol). Sposób ten opisano w rozdziale 11.
3.
Określ rodzaj sieci. Zasady zabezpieczeń IPSec muszą być dostosowane do rodzaju sieci. Do wyboru są: •
wszystkie połączenia sieciowe,
•
sieci lokalne (LAN),
• 4.
dostęp zdalny.
Określ sposób uwierzytelniania komputera. Są trzy możliwości: •
Kerberos 5 — domyślny sposób uwierzytelniania w systemie Windows 2000, może być stosowany w przypadku komputerów pracujących pod kontrolą systemu Windows 2000 lub Unix, na których uruchomiono protokół Kerberos 5,
•
certyfikaty z kluczem publicznym (public key certificates) — sposób ten może być stosowany przez dowolnych klientów uzyskujących dostęp do Internetu lub intranetów w przedsiębiorstwach za pomocą infrastruktury klucza publicznego (public key certificate infrastructure) zgodnej ze standardem X.509,
•
klucz wstępny (preshared key) — sposób ten może być stosowany przez dowolnych klientów, którym potrzebne jest pojedyncze połączenie er-to-per, ale protokół Kerberos 5 nie jest uruchomiony. Klucz wstępny służy tylko do uwierzytelniania, a nie do szyfrowania danych.
Uwaga: Jeśli do uwierzytelniania używa się certyfikatów lub kluczy wstępnych (preshared keys), tożsamość komputera jest chroniona. W przypadku użycia protokołu Kerberos 5, tożsamość komputera pozostanie niezaszyfrowana, dopóki nie zostaną zaszyfrowane wszystkie dane identyfikujące (identity payload).
5.
Podaj lub skonfiguruj listę filtrów IP (IP filter list). Określa to typ ruchu w sieci (traffic) do którego ma zastosowanie reguła zabezpieczeń IPSec (IPSec security rule). Domyślnie można podać całą transmisję danych za pomocą protokołu IP lub całą transmisję za pomocą protokołu ICMP (Internet Control Message Protocol). Można również zdefiniować własną listę filtrów IP. Poniżej zamieszczono listę opcji: • Źródło munikacji IP (IP traffic source) — określa adres źródła. Do wyboru są następujące ustawienia: adres IP danego komputera, dowolny adres IP, konkretna nazwa DNS, konkretny adres IP lub konkretna podsieć IP (IP subnet). Domyślne ustawienie to „Mój adres IP” („My IP address”), • Miejsce docelowe komunikacji IP (IP traffic destination) — określa adres docelowy. Do wyboru są następujące ustawienia: adres IP danego komputera, dowolny adres IP, konkretna nazwa DNS, konkretny adres IP lub konkretna podsieć IP (IP subnet). Jeśli nie istnieje żaden szczególny powód, aby ograniczać adresy docelowe, Microsoft zaleca ustawienie „Dowolny adres IP” („Any IP address”), • Typ protokołu (IP protocol type) — określa zastosowany protokół. Przedstawiona jest cała gama protokołów, m.in. Exterior Gateway Protocol (EGP), Host Monitor Protocol (HMP), Internet Control Message Protocol (ICMP), Remote Desk Protocol (RDP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP) oraz Xerox Network Systems Internet Data Protocol (XNS-IDP). Wybrany protokół musi być zainstalowany zarówno na komputerze źródłowym, jak i na komputerze docelowym,
• Port protokołu IP (IP protocol port) — określa port źródłowy i docelowy w zależności od wybranego protokołu. 6.
Wybierz akcję filtru (filter action) dla reguły zabezpieczeń IPSec. Standardowe akcje odpowiadają poziomom zabezpieczeń opisanym w punkcie 1. niniejszej procedury. Można jednak określić akcje niestandardowe. Ustawienia są następujące: • Opcje Ogólne (General Options) — ustawia zachowanie akcji filtru. Zezwalaj (Permit) jest to zasada umożliwiająca swobodny dostęp komunikatów przychodzących (passthrough policy). Blokuj (Block) zatrzymuje wszystkie komunikaty przychodzące i wychodzące zarówno zaszyfrowane, jak i niezaszyfrowane. Negocjuj protokół zabezpieczeń (Negotiate Security) daje możliwość wyboru: wymiana danych tylko z komputerami obsługującymi IPSec lub powrót do komunikacji niezabezpieczonej, •
7.
8.
Zabezpieczenia Komunikacji IP (Traffic Security IP) — określa sposób zabezpieczenia komunikacji IP. Wysoki (High) oznacza szyfrowanie i uwierzytelnianie danych. Średni (Medium) oznacza, że dane będą uwierzytelniane, ale nie szyfrowane. Można również wybrać Niestandardowy (Custom) i wprowadzić odpowiednie ustawienia, jak przedstawiono to na rysunku 10.1.
Określ algorytm uwierzytelniania. Do wybory są dwa algorytmy: •
SHA1 — stosowany jest klucz 160-bitowy. Wybierz tę opcję w przypadku aplikacji, które wymagają wysokiego stopnia ochrony, jak np. kontrakty rządowe,
•
MD5 — stosowany jest klucz 128-bitowy. Jest zazwyczaj wystarczający w warunkach normalnej, typowej działalności.
Określ algorytm szyfrowania. Do wyboru są następujące algorytmy: •
3DES — zastosowano w nim klucze 128-bitowe. Wybierz tę opcję w przypadku transmisji danych na terenie Stanów Zjednoczonych, która wymaga wysokiego poziomu zabezpieczeń,
Rysunek 10.1. Ustawienia niestandardowego sposobu zabezpieczenia komunikacji •
DES — zastosowano w nim pojedynczy klucz 56-bitowy. Jest to niższy poziom zabezpieczeń, ale używa się go w przypadku aplikacji eksportowanych, zgodnie z ograniczeniami eksportowymi rządu USA.
Uwaga: Aby zapewnić bardzo wysoki poziom zabezpieczeń, można zastosować bardziej zaawansowane algorytmy szyfrowania, takie jak zmieniająca się długość klucza (dynamic key length), w którym długość ta jest określana w trakcie wykonywania obliczeń. Obecnie nie są to standardowe ustawienia IPSec i można je spotkać tylko w systemach zabezpieczeń tworzonych na zamówienie. Jednak należy wiedzieć o ich istnieniu, ponieważ mogą się pojawić w przyszłych wersjach systemu.
9.
Wybierz grupę Diffie-Hellmana (stopień zabezpieczenia): 1 — niski (low) lub 2 — średni (medium).
10. Określ, czy stosować IPSec na pojedynczych komputerach, na poziomie domeny lub jednostki organizacyjnej (OU). Opcje te zostaną omówione w kolejnych podrozdziałach.
Konfigurowanie IPSec na pojedynczych komputerach Zamieszczona poniżej procedura opisuje konfigurowanie IPSec na podstawie decyzji podjętych przy wykonywaniu poprzedniej procedury „Określanie ustawień IPSec”. Wykonując daną procedurę, można zmienić niektóre ustawienia, a ona nie ulegnie zmianie. Można skonfigurować IPSec na pojedynczym komputerze, skonfigurować zasady IPSec w domenie (IPSec domain policy), na kontrolerze domeny lub skonfigurować ustawienia IPSec dla jednostek organizacyjnych (OUs) i umieścić komputery w tej jednostce organizacyjnej. Do testowania zasad IPSec konieczne są co najmniej dwa komputery. Aby wykonać test zgodnie z zamieszczonym opisem, niezbędny jest dostęp do kontrolera domeny (DC) i do dwóch innych komputerów pracujących pod kontrolą systemu Windows 2000 w danej sieci. Następnie można skonfigurować IPSec na pojedynczych komputerach, wykonać testy, skonfigurować IPSec dla domeny, sprawdzić jego działanie, a potem skonfigurować IPSec dla jednostki organizacyjnej i zainstalować na komputerach, które nie są kontrolerami domeny w danej jednostce organizacyjnej. Poniżej zamieszczono procedurę konfigurowania IPSec na pojedynczym komputerze, który nie jest kontrolerem domeny: 1.
Zaloguj się jako administrator.
2.
Za pomocą menu Start|Uruchom (Start\Run) uruchom konsolę MMC, wpisując polecenie mmc.
3.
Z menu Konsola (Console) wybierz pozycję Dodaj/Usuń przystawkę (Add/Remove snap-in).
4.
W oknie dialogowym Dodaj/Usuń przystawkę kliknij Dodaj (Add).
5.
Wybierz opcję Zarządzanie Zasadami Zabezpieczeń IP (IP Security Policy Management). Naciśnij przycisk Dodaj.
6.
Sprawdź, czy wybrana jest opcja KomputerLokalny (Local Computer). Naciśnij Zakończ (Finish).
7.
Wybierz opcję Usługi (Services) i zaznacz Dodaj.
8.
Sprawdź, czy wybrana jest opcja Komputer Lokalny. Naciśnij Zakończ.
9.
Zamknij okno dialogowe Dodawanie przystawki autonomicznej (Add standalone snap-in).
10. Aby zamknąć okno dialogowe Dodaj/Usuń przystawkę, naciśnij przycisk OK. 11. Zaznacz gałąź Zasady Zabezpieczeń IP Na Komputerze Lokalnym (IP Security Policies On Local Machine). W prawej części okna prawym przyciskiem myszki kliknij pozycję Serwer z Zabezpieczeniami (Secure Server) i z menu wybierz opcję Właściwości (Properties), zob. rysunek 10.2. 12. Teraz możesz wybrać w oknie Serwer z Zabezpieczeniami (zabezpieczenia wymagane) Właściwości (Secure Server (require security) Properties ) zakładkę Ogólne (General), nacisnąć przycisk Zaawansowane (Advanced) i zobaczyć okno Ustawienia Wymiany Klucza (Key Exchange Settings). Następnie można zaznaczyć Metody (Methods) i zobaczyć okno
Metody Zabezpieczeń Wymiany Klucza (Key Exchange Security Methods). Na razie nie zmieniaj żadnych ustawień. W obu oknach dialogowych naciśnij przycisk Anuluj (Cancel), co spowoduje powrót do okna dialogowego Serwer z Zabezpieczeniami (zabezpieczenia wymagane) Właściwości. 13. W oknie dialogowym Serwer z Zabezpieczeniami (zabezpieczenia wymagane) Właściwości wybierz zakładkę Reguły (Rules) i sprawdź, czy zaznaczone są wszystkie reguły zabezpieczeń IP (IP Security Rules). Naciśnij przycisk Dodaj. 14. Pojawi się Kreator Reguł Zabezpieczeń IP (IP Security Rule Wizard). Naciśnij Dalej (Next).
Wskazówka: W dalszej części niniejszej procedury można wprowadzić własne ustawienia. Pomoc kontekstową (in-context help) dotyczącą dowolnego ustawienia można uzyskać po naciśnięciu przycisku funkcyjnego F1.
15. Wybierz opcję Ta reguła nie określa żadnego tunelu (This rule does not specify a tunnel). Naciśnij przycisk Dalej. 16. Zaznacz opcję Wszystkie Połączenia Sieciowe (All Network Connections) i ponownie Dalej. 17. Zaznacz opcję Użyj tego ciągu do ochrony wymiany kluczy (klucz wstępny) (Use this string to protect the key exchange (preshared key)) i wpisz ciąg znaków. Przykład przedstawiono na rysunku 10.3. Naciśnij przycisk Dalej.
Rysunek 10.2. Otwieranie okna Właściwości Serwera z Zabezpieczeniami (Secure Server)
Rysunek 10.3. Ustawienia uwierzytelniania klucza wstępnego (preshared key)
Wskazówka: Należy podać ciąg znaków składający się z małych i dużych liter, który jest łatwy do zapamiętania, ale trudny do odgadnięcia przez osoby trzecie. Wybranie tej metody uwierzytelniania oczywiście nie jest konieczne. W niniejszym przykładzie nie pozostawiono uwierzytelniania za pomocą protokołu Kerberos, który jest ustawiony domyślnie, aby odróżnić zasadę skonfigurowaną do zasad domyślnych.
18. Zaznacz opcję Cały Ruch IP (All IP Traffic). Naciśnij przycisk Dalej. 19. Zaznacz opcję Wymagaj Zabezpieczeń (Require Security) i kontynuuj wybierając Dalej. 20. Aby zamknąć Kreator Reguł Zabezpieczeń IP naciśnij przycisk Zakończ (Finish). 21. W oknie dialogowym Serwer z Zabezpieczeniami (zabezpieczenia wymagane) Właściwości zaznacz tylko właśnie skonfigurowaną regułę (zob. rysunek 10.4). 22. Zamknij okno dialogowe Serwer z Zabezpieczeniami (zabezpieczenia wymagane) Właściwości. 23. W prawej części okna przystawki (snap-in) konsoli MMC prawym przyciskiem myszki kliknij pozycję Serwer z Zabezpieczeniami i z menu wybierz pozycję Przypisz (Assign).
24. Zapisz przystawkę konsoli MMC jako IPSecSer. Będzie używana w kolejnych przykładach. Utworzono i przypisano nową regułę zabezpieczeń. Aby wykonać testy, konieczny jest drugi komputer.
Testowanie ustawień IPSec Poniżej zamieszczono procedurę testowania ustawień IPSec: 1.
Powtórz poprzednią procedurę na drugim komputerze, aby mieć w sieci dwa komputery z identycznymi zasadami IPSec (IPSec policies).
Rysunek 10.4. Wybór reguły zabezpieczeń IP
2.
Zapisz adres IP drugiego komputera.
3.
Zaloguj się na pierwszym komputerze jako administrator.
4.
Uruchom przystawkę konsoli MMC o nazwie IPSecSer, utworzoną w poprzednim przykładzie. Powinieneś mieć dostęp do niej za pomocą menu Start|Programy|Narzędzia administracyjne (Start\Programs\Administrative tools).
5.
Wybierz pozycję Usługi (lokalne) (Services (local)).
6.
W prawej części okna kliknij prawym przyciskiem myszki Agent zasad IPSEC (IPSEC policy agent) i z menu wybierz pozycję Uruchom (Start), jeśli usługa nie została jeszcze uruchomiona.
7.
Sprawdź połączenie z drugim komputerem za pomocą polecenia Ping, podając adres IP komputera. Powinna pojawić się informacja o tym, że zabezpieczenia IPSec są negocjowane. Zanim połączenie zostanie sprawdzone może być konieczne kilkukrotne uruchomienie polecenia Ping. Przykład odpowiedzi zamieszczono na rysunku 10.5.
Wskazówka: W przypadku testowania połączenia pomiędzy komputerami, na których zainstalowano zasady (policies) Serwer (żądaj zabezpieczeń) (Server (request security)) lub Serwer z Zabezpieczeniami (żądaj zabezpieczeń) (Secure Server (request security)), polecenie Ping rzadko pokazuje stan prawidłowy za pierwszym razem. Pakiet protokołu ICMP wysyłany przez to polecenie będzie odpowiadał pozycji na liście filtrów IP tych zasad (policies) i IPSec będzie próbować zastosować zabezpieczenia do niego. Proces ten trwa dłużej, niż polecenie Ping czeka na odpowiedź. Z tego powodu mogą pojawić się komunikaty „Destination unreachable”. Rozwiązaniem tego problemu jest wyłączenie transmisji danych za pomocą protokołu ICMP (ICMP traffic) ze wszystkich zasad (policies) IPSec.
Rysunek 10.5. Negocjowanie zabezpieczeń IPSec podczas wysyłania komunikatów polecenia Ping 8.
Przejdź do pozycji menu Start|Uruchom (Start\Run) i wpisz polecenie ipsecmon. Uruchomiony zostanie Monitor Protokołu IP Security (IP Security Monitor). Narzędzie to dostarczy informacji o ustanowionych skojarzeniach zabezpieczeń (SAs), pokaże statystykę
protokołu IPSEC (IPSec statistics) oraz statystykę protokołu ISAKMP/Oakley (ISAKMP/Oakley statistics). 9.
Zamknij Monitor Protokołu IP Security i przystawkę konsoli MMC.
Usuwanie przypisanych zasad IPSec Postępując zgodnie z poniższą procedurą, usuwa się zasady IPSec (IPSec policy) z obydwu komputerów, które nie są kontrolerami domeny. 1.
Zaloguj się jako administrator.
2.
Uruchom przystawkę (snap-in) konsoli MMC o nazwie IPSecSer, utworzoną w poprzednim przykładzie. Powinieneś mieć dostęp do niej za pomocą menu Start|Programy|Narzędzia administracyjne (Start\Programs\Administrative tools).
3.
Wybierz pozycję Zasady Zabezpieczeń IP Na Komputerze Lokalnym (IP Security Policies On Local Machine).
4.
W prawej części okna zaznacz prawym przyciskiem myszki pozycję Serwer z Zabezpieczeniami (Ssecure Server) i z menu wybierz pozycję Usuń Przypisanie (Unassign).
Konfigurowanie IPSec dla domeny Poniżej zamieszczono procedurę konfigurowania IPSec na kontrolerze domeny i zastosowania do całej domeny. 1.
Zaloguj się na kontrolerze domeny jako administrator.
2.
Utwórz przystawkę (snap-in) konsoli MMC pod nazwą IPSecSer, zgodnie z procedurą zamieszczoną w podrozdziale „Konfigurowanie IPSec na pojedynczych komputerach”. W tym przypadku, dodając przystawkę Zarządzanie Zasadami Zabezpieczeń IP (IP Security Policy Management), zaznacz Zarządzaj zasadami domeny tego komputera (Manage domain policy for this computer’s domain).
3.
Wybierz Zasady Zabezpieczeń IP w Active Directory (IP Security Policies On Active Directory).
4.
W prawej części okna prawym przyciskiem myszki kliknij pozycję Serwer z Zabezpieczeniami i z menu wybierz opcję Właściwości (Properties).
5.
Aby uruchomić Kreator Reguł Zabezpieczeń IP (IP Security Rule Wizard) naciśnij przycisk Dodaj (Add).
6.
Skonfiguruj ustawienia podane w opisie procedury „Konfigurowanie IPSec za pomocą pojedynczych komputerów”. Różnicą jest ustawienie na stronie Metoda Uwierzytelniania (Authentication Method) — zob. rysunek 10.3), gdzie należy zaznaczyć opcję Użyj certyfikatu z tej jednostki certyfikującej (CA) (Use a certificate from this Certificate Authority (CA)). Po naciśnięciu przycisku Przeglądaj (Browse), jeśli pojawi się ostrzeżenie, że Active Directory nie zawiera współużytkowanego magazynu certyfikatów (shared certificate store), naciśnij przycisk Tak (Yes), aby wybrać jednostkę certyfikującą z magazynu certyfikatów (certificate store) komputera lokalnego.
7.
Usuń zaznaczenie wszystkich reguł zabezpieczeń IP (IP security rules) poza tymi, które właśnie zostały skonfigurowane i zamknij okno dialogowe Serwer z Zabezpieczeniami (zabezpieczenia wymagane) Właściwości.
Uwaga: Jeśli skonfigurujesz IPSec w Active Directory nie musisz ich przypisywać. Można to sprawdzić, wybierając zasady zabezpieczeń IP w Active Directory (IP security policies on Active Directory) i klikając w prawej części okna prawym przyciskiem myszki pozycję Serwer z Zabezpieczeniami (Secure Server). W tym przypadku w menu kontekstowym nie pojawi się pozycja Przypisz (Assign).
8.
W przystawce konsoli MMC kliknij pozycję Usługi (lokalnie) i uruchom usługę Agent Zasad IPSEC (IPSEC Policy Agent), o ile nie została jeszcze uruchomiona.
Testowanie zasad IPSec domeny Poniżej zamieszczono procedurę przypisania lokalnych zasad IPSec (IPSec policy) na komputerze, który nie jest kontrolerem domeny i należy do domeny, dla której skonfigurowano zasady IPSec. 1.
Zaloguj się na komputerze lokalnym jako administrator.
2.
Uruchom lub utwórz przystawkę (snap-in) IPSecSer konsoli MMC. Upewnij się, czy w przystawce ZarządzanieZzasadami Zabezpieczeń IP (IP Security Policy Management) podano Komputer Lokalny (Local Computer).
3.
Wybierz Zasady Zabezpieczeń IP Na Komputerze Lokalnym (IP Security Policies On Local Machine). Powinien pojawić się komunikat o błędzie, zawierający informację, że zasady IPSec podał kontroler domeny. Naciśnij przycisk OK.
4.
W prawej części okna prawym przyciskiem myszki kliknij pozycję Serwer z Zabezpieczeniami (Secure Server) i z menu wybierz pozycję Przypisz (Assign).
5.
Powinien pojawić się komunikat stwierdzający, że zasady zostały przypisane, ale zasady domeny (domain policy) są nadrzędne.
6.
Usuń przypisanie zasad.
Zmiana metody zabezpieczeń Domyślnie metodą zabezpieczeń jest kombinacja szyfrowania pakietów za pomocą algorytmu 3DES z kluczem 128-bitowym oraz uwierzytelniania za pomocą algorytmu SHA1 z algorytmem Diffie-Hellmana z kluczem 1024-bitowym (grupa 2-medium). Jest to bardzo dobre zabezpieczenie, ale jeśli sieć jest międzynarodowa, to w siedzibach poza USA odszyfrowanie danych uwierzytelniających lub pakietów może być niemożliwe. W tym przypadku należy ustawić niższy poziom zabezpieczeń. Poniżej zamieszczono procedurę zmiany metody zabezpieczeń. Przyjęto, że w Active Directory skonfigurowano IPSec dla całej domeny. 1.
Zaloguj się na kontrolerze domeny jako administrator.
2.
Uruchom przystawkę (snap-in) o nazwie IPSecSer konsoli MMC.
3.
Zaznacz opcję Zasady Zabezpieczeń IP w Active Directory (IP Security Policies On Active Directory). W prawej części okna włącz prawym przyciskiem myszki pozycję Serwer z Zabezpieczeniami (Secure Server) i z menu wybierz opcję Właściwości (Properties).
4.
Wybierz zakładkę Ogólne (General), naciśnij przycisk Zaawansowane (Advanced), a następnie kliknij Metody (Methods).
5.
W oknie Metody Zabezpieczeń Wymiany Klucza (Key Exchange Security Methods) (zob. rysunek 10.6) wybierz dowolną metodę i za pomocą przycisku Przenieś w górę (Move up) przesuń na początek listy. Jeśli którekolwiek z metod nie będą używane, należy usunąć je z listy. Jeśli żadna ze standardowych metod nie jest odpowiednia, można sporządzić własną, korzystając z przycisku Edytuj (Edit).
6.
Naciśnij dwukrotnie przycisk OK, a następnie, aby powrócić do przystawki konsoli MMC, naciśnij Zamknij (Close). Zamknij przystawkę.
Rysunek 10.6. Okno Metody Zabezpieczeń Wymiany Klucza (Key Exchange Security Methods)
Konfigurowanie IPSec dla jednostki organizacyjnej (OU) W niniejszym przykładzie zostanie utworzona jednostka organizacyjna (OU) — można również skorzystać z istniejącej już w Active Directory na kontrolerze domeny — dla której zostaną skonfigurowane zabezpieczenia IPSec, a ustawienia te zostaną uaktywnione na pojedynczych komputerach poprzez umieszczenie ich w danej jednostce (OU). Jeśli wykonana była procedura z poprzedniego podrozdziału, pokazane zostanie wzajemne oddziaływanie zasad IPSec jednostki organizacyjnej (OU-based IPSec policy) z zasadami domeny oraz zasadami pojedynczych komputerów.
Uwaga: Ustawienia IPSec w niniejszym przykładzie różnią się od ustawień z poprzedniego przykładu, aby można było odróżnić zasady (policies) oraz w celu zademonstrowania
sporządzania listy filtrów (filter list) za pomocą kreatora filtrów IP (IP filter wizard). Można podać własne ustawienia IPSec odpowiednie dla danej sieci.
1.
Uruchom przystawkę (snap-in) konsoli MMC Active Directory Użytkownicy i Komputery (AD Users and Computers) i dodaj jednostkę organizacyjną (OU) o nazwie IPSec policies lub wybierz jedną z istniejących jednostek organizacyjnych.
2.
Prawym przyciskiem myszki wybierz tę jednostkę (OU) i z menu pozycję Właściwości (Properties).
3.
Dodaj obiekt zasad grupowych (Group Policy Object — GPO) i nadaj mu nazwę IPSec GPO. Edytuj ten obiekt zasad grupy.
4.
Rozwiń gałąź Konfiguracja Komputera\Ustawienia Systemu Windows\Ustawienia Zabezpieczeń (Computer Configuration\Windows Settings\Security Settings) i zaznacz pozycję Zasady Zabezpieczeń IP w Active Directory (IP Security Policies On Active Directory).
5.
Prawym przyciskiem myszki kliknij pozycję Serwer z Zabezpieczeniami i z menu wybierz pozycję Właściwości.
6.
Wybierz zakładkę Reguły (Rules) i naciśnij Dodaj (Add). Uruchomiony zostanie Kreator Reguł Zabezpieczeń IP (IP Security Rule Wizard).
7.
Zaznacz Dalej (Next), a potem opcję Ta reguła nie określa żadnego tunelu (This rule does not specify a tunnel).
8.
Naciśnij przycisk Dalej. Zaznacz opcję Wszystkie Połączenia Sieciowe (All Network Connections).
9.
Ponownie naciśnij Dalej. Zaznacz opcję Użyj tego ciągu do ochrony wymiany kluczy (klucz wstępny) (Use this string to protect the key exchange (preshared key)) i podaj klucz wstępny.
10. Wybierz przycisk Dalej. Aby podać nowy filtr IP, naciśnij przycisk Dodaj. 11. Naciśnij przycisk Dodaj. Uruchomiony zostanie Kreator Filtrów IP (IP Filter Wizard). 12. Kontynuuj przyciskiem Dalej. Podaj adres IP źródła. 13. Naciśnij przycisk Dalej. Podaj docelowy adres IP. 14. Naciśnij Dalej. Z listy wybierz pozycję Inne (Other), a następnie wybierz protokół TCP. 15. Zaznacz Dalej. Aby zaakceptować domyślne przypisanie portu protokołu IP (IP Protocol Port), naciśnij kolejny raz przycisk Dalej. 16. Naciśnij przycisk Zakończ (Finish). 17. Wpisz nazwę i opis nowego filtru (zob. rysunek 10.7). 18. Naciśnij przycisk Zamknij (Close). Wybierz filtr, który właśnie został utworzony. 19. Wybierz Dalej, a następnie opcję Wymagaj Zabezpieczeń (Require Security). 20. Naciśnij przycisk Dalej i Zakończ.
21. Upewnij się, że zaznaczone są tylko zasady IPSec (IPSec policy), które zostały właśnie utworzone. 22. Naciśnij przycisk Zamknij (Close). Nastąpi powrót do przystawki konsoli MMC Zasady Grupowe (Group Policy). 23. Prawym przyciskiem myszki kliknij pozycję Serwer z Zabezpieczeniami i z menu wybierz pozycję Przypisz (Assign). 24. Zamknij przystawkę konsoli MMC Zasady Grupowe. 25. Naciśnij przycisk Zamknij. W przystawce konsoli MMC Active Directory Użytkownicy i Komputery (AD Users and Computers) do jednostki organizacyjnej (OU) IPSec policies dodaj co najmniej jeden komputer, który nie jest kontrolerem domeny — najlepiej ten, który został skonfigurowany wcześniej. 26. Sprawdź, czy komputery te mają ustawienia IPSec danej jednostki organizacyjnej.
Reguły ustawiania zasad IPSec Poniżej zamieszczono reguły ustawiania zasad IPSec (IPSec policies): •
zasady (policies) domeny są nadrzędne w stosunku do zasad pojedynczego komputera,
•
zasady ustanowione dla jednostki (OU) są nadrzędne w stosunku do zasad domeny,
•
zasady ustanowione dla jednostki organizacyjnej niższego poziomu są nadrzędne w stosunku zasad ustanowionych dla jednostki organizacyjnej, która znajduje się na wyższym poziomie struktury drzewiastej Active Directory,
•
aby uprościć administrowanie, zasady należy ustanawiać na tak wysokim poziomie, jak to tylko możliwe.
Rysunek 10.7. Definiowanie filtru IP
Rozdział 11
Wirtualne Sieci Prywatne Rozwiązania natychmiastowe zobacz na stronie Określanie startegii Wirtualnych sieci prywatnych (VPN) Instalowanie serwera VPN Konfigurowanie serwera VPN Konfigurowanie klienta VPN Organizowanie kont użytkowników usługi Dostęp zdalny (remote access) Tworzenie zasad dostępu zdalnego (remote access policy) dla połączeń VPN ruter-ruter Włączanie uwierzytelniania wzajemnego Automatyczne uzyskiwanie certyfikatu komputera Dodawanie portów L2TP i PPTP Konfigurowanie serwera usługi RADIUS
W skrócie Zastosowanie Wirtualnych Sieci Prywatnych Wirtualne Sieci Prywatne (Virtual Private Networks — VPNs) umożliwiają użytkownikom zdalnym (remote users) bezpieczne łączenie się z serwerem w firmie, korzystającym z sieci publicznych, takich jak Internet. Wirtualne Sieci Prywatne mogą również zapewniać kanały bezpieczne w wielkiej sieci intranet firmy. Rodzaj sieci pośrednich (intermediate internetwork) nie ma nic wspólnego z użytkownikiem, ponieważ wygląda to, jak gdyby dane były przesyłane przez specjalne łącze prywatne. Korzystając z wirtualnych sieci prywatnych, użytkownicy mobilni (roaming users) mogą łączyć się z najbliższym usługodawcą internetowym (Internet Service Provider — ISP) i ustanowić kanał bezpieczny praktycznie z dowolnego miejsca. Filie przedsiębiorstwa, podłączone do Internetu łączami stałymi, takimi jak linie T1 lub T3 czy też technologia Frame Relay, mogą łączyć się z centralą na żądanie (on-demand connection) znacznie taniej niż w przypadku łącza dzierżawionego. Dane o szczególnym znaczeniu mogą być przesyłane bezpiecznie poprzez sieć firmową, chronione jak tylko można najlepirj przed atakami od wewnątrz. Połączenia poprzez Wirtualne Sieci Prywatne (VPN) mogą być jedno- lub dwukierunkowe. Jednak nie odnosi się to do przepływu informacji, który zawsze odbywa się w obu kierunkach, ale do sposobu inicjowania wymiany danych. Użytkownik mobilny będzie inicjował sesję połączenia z centralą przedsiebiorstwa, a jego oddziały przedsiębiorstwa na ogół będą inicjować połączenie z dyrekcją główną (corporate headquaters). Są to przykłady połączeń jednokierunkowych (one-way connections), w których centrala przedsiębiorstwa lub dyrekcja główna akceptują połączenia za pomocą serwera Wirtualnych Sieci Prywatnych (VPN server), tzn. serwera RRAS (Routing and Remote Access Service server), który ma możliwości ustanawiania połączeń poprzez Wirualne Sieci Prywatne (VPN connections), określanego nazwą routera odpowiadającego (answering router). W przypadku oddziałów przedsiębiorstwa komputery-klienci będą łączyć się za pomocą własnego, lokalnego serwera RRAS, określanego nazwą routera wywołującego (calling router). Czasem może zajść potrzeba zainicjowania wymiany danych ze strony dyrekcji głównej. W takim przypadku serwery Wirtualnych Sieci Prywatnych na obu końcach połączenia Wirtualnej Sieci Prywatnej (VPN link) lub tunelu (tunnel) są konfigurowane jako wzajemni klienci, tzn. obydwa są jednocześnie routerami wywołującymi i odpowiadającymi.
Uwaga: Niezależnie od tego, czy router odpowiadający jest połączony z Internetem za pomocą usługodawcu internetowego (ISP) czy też do serwera IIS (Internet Information Server) w przedsiębiorstwie, musi to być połączenie stałe, ponieważ router ten musi być dostępny dla danych przychodzących za pomocą Wirtualnych Sieci Prywatnych (VPNs) 24 godziny na dobę.
Tunelowanie (tunneling) Tunelowanie jest sposobem przesyłania danych krążących w jednej sieci poprzez drugą sieć pośredniczącą. Przesyłane dane (payload) są podzielone na pakiety (packets) lub ramki (frames). Protokół tunelowania (tunneling protocol) opatruje (encapsulates) każdą ramkę lub pakiet dodatkowym nagłówkiem, zawierającym informacje dotyczące marszrutowania (routing information), aby dane użyteczne (payload) mogły przejść przez sieć pośredniczącą. Po dotarciu danych do punktu końcowego tunelu (tunnel endpoint) w sieci pośredniczącej, informacja jest rozpakowywana (unecapsulated) i przekazywana do ostatecznego adresata. Tunelowanie obejmuje hermetyzowanie (encapsulation), przesyłanie (transmission) i rozpakowywanie (unencapsulation).
Uwaga: Ramka zawiera nagłówek (header), właściwy dla danego protokołu transmisji, dane (frame data) oraz pole kontrol parzystości (CRC lub suma kontrolna). Pakiet może zawierać kilka związanych ze sobą ramek. Protokoły tunelowania warstwy 2. (warstwa łącza danych) (layer 2 (data-link layer) tunneling protocols) hermetyzują ramki. Protokoły tunelowania warstwy 3. (warstwa sieciowa) (layer 3 (network layer) tunneling protocols) hermetyzują pakiety.
Tunele mogą być tworzone na dwa sposoby: •
tunele nieobowiązkowe (voluntary tunnels) — klient wysyła żądanie VPN skonfigurowania i utworzenia tunelu nieobowiązkowego. W tym przypadku punktem docelowym tunelu (tunnel endpoint) jest komputer-klient. W przykładzie zamieszczonym w poprzednim rozdziale użytkownik mobilny (roaming user), łącząc się z centralą (central office), tworzy tunel nieobowiązkowy,
•
tunele przymusowe (compulsory tunnels) — serwer dostępu telefonicznego (dial-up access server) umożliwiający korzystanie z Wirtualnych Sieci Prywatnych (VPNs) konfiguruje i tworzy tunel przymusowy. W tym przypadku komputer użytkownika nie jest punktem końcowym tunelu. Tunel przymusowy tworzone są zwykle pomiędzy oddziałami terenowymi a centralą firmy.
Tunelowanie można wykonywać w oparciu o protokół tunelowania warstwy 2. (warstwa łącza danych) lub protokół tunelowania warstwy 3. (warstwa sieciowa) albo obu razem. W przypadku protokołów warstwy 3. przyjęto, że konfigurowanie obsługiwane jest gdzie indziej, a zabezpieczenia na poziomie sieci (network-level security), które zapewniają te protokoły, są niewidoczne dla użytkownika. Zazwyczaj w tych protokołach nie ma etapu utrzymywania kanału (tunnel maintenance phase). Wyjątkiem jest protokół ISAKMP (Internet Protocol Security — Internet Security Association and Key Management Protocol — IPSec ISAKMP), który umożliwia obustronne uwierzytelnianie punktów końcowych (endpoints) tunelu. W przypadku protokołów
warstwy 2 tunel musi zostać utworzony, podtrzymywany, a następnie zamknięty. W systemie Windows 2000 obsługiwane są następujące protokoły: •
Point-To-Point Tunneling Protocol (PPTP) — umożliwia szyfrowanie danych, dołączanie nagłówka IP i przesyłanie za pomocą protokołu IP (Internet Protocol), IPX (Internetwork Packet Exchange) lub NetBEUI (Network Basic Input/Output System Enhanced User Interface) przez sieć IP, np. Internet. Protokół PPTP jest protokołem warstwy 2 (layer 2),
•
Layer 2 Tunneling Protocol (L2TP) — umożliwia szyfrowanie danych przesyłanych za pomocą protokołu IP, IPX czy NetBEUI i transmitowanie ich poprzez dowolną sieć zgodną ze standardami IP, X.25, Frame Relay lub Asynchronous Transfer Mode (ATM). Protokół L2TP jest protokołem warstwy 2,
•
IPSec Tunnel Mode — umożliwia szyfrowanie danych użytecznych (payloads) protokołu IP, dołączanie nagłówka IP (IP header) i przesyłanie ich poprzez sieć IP, np. przez Internet. IPSec jest protokołem warstwy 3.
Wskazówka: Aby zapewnić ochronę na poziomie sieci i utrzymywanie tunelu (tunnel maintenance), zazwyczaj korzysta się z kombinacji protokołów warstwy 3. i warstwy 2. Domyślnie system Windows 2000 oprócz protokołu IPSec korzysta z protokołu L2TP (L2TP over IPSec). Pozwala to na przezwyciężenie słabości związanych ze stosowaniem tylko protokołu IPSec, który korzysta wyłącznie z certyfikatów komputerów i każdy użytkownik, mający dostęp do komputera, który jest punktem końcowym tunelu (tunnel endpoint), ma również dostęp do tunelu.
Protokoły PPTP i L2TP oparte są na protokole Point-To Point Protocol (PPP) i mają następujące cechy: •
uwierzytelnianie użytkownika — w protokołach PPTP i L2TP zastosowano taki sam sposób uwierzytelniania, jak w protokole PPP, łącznie z protokołem EAP (Extensible Authentication Protocol — EAP) opisanym z dalszej części niniejszego rozdziału. Protokoły te zawierają wiele metod uwierzytelniania, takich jak: hasła jednorazowe (one-time passwords), kalkulator kryptograficzny (cryptographic calculator) i karty elektroniczne (smart cards),
Uwaga: Protokoły tunelowania warstwy 3. (layer 3 tunneling protocols) umożliwiają również uwierzytelnianie użytkownika. Np. IPSec definiuje uwierzytelnianie za pomocą certyfikatu z kluczem publicznym na etapie negocjacji protokołu ISAKMP/Oakley.
Rozwiązania pokrewne zobacz na stronie: Analizowanie operacji IPSec
•
dynamiczne przyporządkowywanie adresów (dynamic address assignment) — protokoły PPTP i L2TP umożliwiają dynamiczne przydzielanie adresów klientów na podstawie mechanizmu negocjowania Network Control Protocol (NCP),
•
kompresowanie danych — w implementacji protokołów PPTP i L2TP, dokonanych przez firmę Microsoft, zastosowano Microsoft Point-To-Point Compression (MPPC),
•
szyfrowanie danych — w implementacji protokołu PPTP, dokonanej przez firmę Microsoft (Microsoft Point-To-Point Encryption — MPPE) jest możliwość zastosowania, opartego na algorytmie, szyfrowania RSA/RC4. W implementacji protokołu L2TP, dokonanej przez Microsoft, do ochrony strumienia danych zastosowano szyfrowanie IPSec (IPSec encryption),
•
zarządzanie kluczami — MPPE korzysta z klucza wstępnego (initial key), wygenerowanego podczas uwierzytelniania użytkownika i odświeża go okresowo. IPSec jawnie (explicitly) negocjuje klucz wspólny w trakcie wymiany komunikatów protokołu ISAKMP i również odświeża go okresowo,
•
obsługa wielu protokołów — protokoły PPTP i L2TP mogą obsługiwać wiele protokołów, chociaż w przypadku PPTP konieczny jest protokół TCP/IP. IPSec Tunnel Mode obsługuje tylko sieci docelowe (target networks), w których można stosować protkół IP.
Uwaga: IPSec jest nadal w fazie rozwoju i może zawierać wiele funkcji obecnie wprowadzonych w protokołach PPTP i L2TP. Szczegółowe informacje na temat nowości wprowadzonych w IPSec można znaleźć pod adresem www.itef.org/html.charters/ipsedcharter.html.
Uwierzytelnianie W protokołach warstwy 2. (layer 2 protocols) zastoswano takie same metody uwierzytelniania, jak w przypadku protokołu PPP, tzn. Password Autentication Protocol (PAP), Challenge Handshake Authentication Protcol (CHAP) oraz Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). W wersji protokołów PPTP i L2TP, opracowanej przez Microsoft, zastosowano również protokół EAP, a zwłaszcza EAP Transaction Level Security (EAP-TLS). W systemie Windows 2000 dostępne są następujące metody uwierzytelniania warstwy połączenia danych (data-link layer): •
PAP — metoda uwierzytelniania tekstu jawnego (clear-text authentication), która w wyniku daje nazwę użytkownika i hasło w postaci tekstu jawnego (niezaszyfrowanego). Nie jest to metoda bezpieczna i nie daje ochrony przed atakami metodą powtórzenia (replay attacks) ani przed atakami przez podszywanie się pod klienta zdalnego (remote client impersonation) po złamaniu hasła użytkownika,
•
CHAP — mechanizm uwierzytelniania z szyfrowaniem (encrypted authentication mechanism), za pomocą którego można uniknąć przesyłania rzeczywistego hasła poprzez połączenie. Serwer NAS (Network Access Server) wysyła do klienta zdalnego wyzwanie (challenge) składające się z identyfikatora sesji i dowolny ciąg znaków. Klient zdalny zwraca nazwę użytkownika, zaszyfrowane wyzwanie (encryption of the challenge), identyfikator sesji i hasło klienta, korzystając z funkcji skrótu MD 5 (Message Digest 95 hash function). CHAP chroni przed atakami metoda powtórzenia, używając dowolnego ciągu znaków dla każdej próby uwierzytelniania. Chroni również przed podszywaniem się pod klienta zdalnego, wysyłającpowtarzające się wyzwania (challenges) do klienta zdalnego (remote client) w czasie trwania połączenia i w sposób niemożliwy do przewidzenia,
•
MS-CHAP — mechanizm uwierzytelniania z szyfrowaniem (encrypted authentication mechanism) bardzo podobny do PAP, zapewniający dodatkowe zabezpieczenia poprzez umożliwienie serwerowi przechowywanie haseł przetworzonych za pomocą funkcji skrótu (hashed password), zamiast haseł w postaci tekstu jawnego (clear-text passwords). Uwierzytelnianie za pomocą protokołu uwierzytelniania z szyfrowaniem MS-CHAP jest konieczne dla szyfrowania danych za pomocą algorytmu MPPE,
•
MS-CHAP v2 — podobna do MS-CHAP, działająca tylko na komputerach pracujących pod kontrolą systemu Windows 2000,
•
SPAP (Shiva PAP) — metoda stosowana w mieszanych środowiskach sieciowych do obsługi klientów korzystających z oprogramowania Shiva LAN Rover,
•
EAP-TLS — metoda silnego uwierzytelniania (strong authentication method) oparta na certyfikatach z kluczem publicznym (public key certificates). Klient przedstawia serwerowi certyfikat użytkownika dostępu telefonicznego (dial-in server), a serwer przedstawia klientowi certyfikat serwera. Pierwszy certyfikat umożliwia serwerowi uwierzytelnienie klienta, drugi — pozwala upewnić się, czy użytkownik uzyskał dostęp do właściwego serwera. Certyfikat użytkownika może być zapisany na komputerze klienta połączenia telefonicznego (dial-up client computer) lub na karcie elktronicznej (smart card).
Uwaga: Można również zezwolić użytkownikom zdalnym na łączenie się bez uwierzytelniania.
Na poziomie warstwy transportowej (transport layer) IPSec definiuje szyfrowanie danych i integralność danych (data integrity), korzystając z nagłówka uwierzytelniania (Authentication Header — AH), aby zapewnić uwierzytelnienie i integralność źródła (source authentication and integrity) bez szyfrowania oraz ukrytych danych uwierzytelniających (Encapsulated Security Payload — ESP), aby zapewnić uwierzytelnianie i integralność razem z szyfrowaniem. IPSec można wyobrazić sobie jako warstwę (layer) poniżej stosu TCP/IP (TCP/IP stack). Warstwa ta jest kontrolowana przez zasady zabezpieczeń (security policy) każdego komputera i negocjuje skojarzenia zabezpieczeń (security association) pomiędzy nadawcą a odbiorcą. Zasady składają się z zestawu filtrów i związanego z tym zachowania. Jeśli adres IP pakietu, protokół i numer portu są zgodne z danym filtrem, to łączy się z tym określone działanie związane z zabezpieczeniami. IPSec omówiono w rozdziale 10.
Rozwiązania pokrewne zobacz na stronie: Określanie ustawień IPSec
Porównanie protokołów PPTP i L2TP Protokół PPTP do utrzymywania kanału korzysta z połączeń TCP, a do przesyłania danych przez tunel stosuje ukryte ramki PPP (encapsulated PPP frames) za pomocą protkołu GRE (Generic Routing Encapsulation). Dane użyteczne (payloads) zawarte w ukrytych ramkach PPP mogą być szyfrowane lub (i) skompresowane. Protokół L2TP ukrywa (encapsulates) ramki PPP przesyłane przez sieci IP, X.25, Frame Relay lub ATM. Może być stosowany jako protokół tunelowania (tunneling protocol) w Internecie lub używany bezpośrednio w sieciach, w których nie ma warstwy transportowej IP (IP transport layer), takich jak Frame Relay. Protokół L2TP do utrzymywania tunelu i do przesyłania przez tunel ramek PPP ukrytych za pomocą tego protokołu, korzysta z protokołu UDP (User Datagram Protocol). Dane użyteczne zawarte w ukrytych ramkach PPP mogą być szyfrowane lub (i) skompresowane. Obydwa protokoły korzystają z protokołu PPP, aby zapewnić kopertę wstępną (initial envelope) dla danych, a potem dołączyć dodatkowe nagłówki (headers) w celu przesłania danych poprzez intersieć (internetwork). Protokoły te są podobne, ale występują między nimi pewne różnice: •
protokół PPTP wymaga sieci IP, podczas gdy w przypadku L2TP konieczne jest tylko, aby ośrodek, w którym tworzony jest tunel, zapewniał funkcje pakietowego połączenia dwupuntowego (packet-oriented point-to-point connectivity),
•
protokół PPTP może obsługiwać tylko pojedynczy tunel pomiędzy punktami końcowymi (endpoints). Protokół L2TP pozwala na tworzenie wielu tuneli,
•
jeśli włączona jest kompresja nagłówka (header compression), to w przypadku protokołu L2TP występują 4 bajty pomocnicze, a w protokole PPTP — 6 bajtów pomocniczych,
•
protokół L2TP umożliwia uwierzytelnianie tunelu (tunnel authentication), w przypadku protokołu PPTP nie ma takiej możliwości. Jednak jeśli którykolwiek z protokołów jest stosowany obok IPSec, wówczas uwierzytelnianie tunelu zapewnia IPSec.
Uwaga: Protokół PPTP jest opisany w propozycji dokumentu RFC „Point-To-Point Tunneling Protocol” (pptp-draft-ietf-ppext-pptp-02.txt). Protokół L2TP opisano w propozycji dokumentu RFC „Layer 2 Tunneling Protocol L2TP” (draft-ietf-pppext-l2tp-09.txt).
Protokół RADIUS (Remote Authentication Dial-in User Service) Protokół RADIUS (Remote Authentication Dial-in User Service)jest oparty na protokole UDP i może być stosowany do zarządzania uwierzytelnianiem i autoryzacją użytkowników zdalnych (remote users). Usługi pośredniczące (proxy services) serwerów protokołu RADIUS mogą przekazywać żądania uwierzytelniania (authentication requests) do serwerów RADIUS, znajdujących się w loaklizacjach odległych. Wielu usługodawców internetowych (ISPs) utworzyło konsorcja, które umożliwiają abonentom mobilnym (roaming subscribers) połączenie się telefoniczne do internetu, korzystając z usług lokalnych (local services) najbliższego usługodawcy internetowego (ISP). Jeśli usługodawca internetowy rozpozna nazwę użytkownika, który jest abonentem sieci odległej (remote network), to wtedy do przekazania żądania dostępu do właściwej sieci korzysta z usługi pośredniczącej protokołu RADIUS (RADIUS proxy). Protokół RADIUS umożliwia również rozliczanie połączeń. Serwer RADIUS tworzy zapis rozliczeniowy (accounting record) na początku i na zakończenie połączenia oraz w określonych wcześniej przedziałach czasu w trakcie połączenia. Rozliczeniowy serwer RADIUS (accounting RADIUS server) może być skonfigurowany niezależnie od tego czy protokół RADIUS jest używany do uwierzytelniania, a następnie może gromadzić zapisy dotyczące wszystkich połączeń za pomocą Wirtualnych Sieci Prywatnych (VPN connection), aby później można było je przanalizować.
Rozwiązania natychmiastowe Określanie startegii Wirtualnych Sieci Prywatnych (VPNs)
Zanim nastąpi etap wdrażania, tzn. instalowania i konfigurowania punktów końcowych Wirtualnych Sieci Prywatnych (VPN endpoints), konieczne jest zapoznanie się ze strategią wprowadzania wirtualnych sieci prywatnych w danej firmie. Niewielu specjalistów ma luksus tworzenia nowej sieci od podstaw. Wdrażanie wirtualnych sieci prywatnych będzie uzależnione od istniejącej struktury sieci, wymagań dotyczących dostępu zdalnego, stopnia bezpieczeństwa uznanego za odpowiedni oraz planów rozwoju sieci w przyszłości. Każda sieć ma swoje specyficzne cechy i nie ma reguł, które można stosować powszechnie. Konieczne będzie podejmowanie decyzji, biorąc pod uwagę usługę RAS (Remote Access Service) oraz Wirtualne Sieci Prywatne (VPNs). Procedura określania startegii Wirtualnych Sieci Prywatnych (VPNs) jest następująca: 1.
Określ topologię sieci na podstawie struktury organizacyjnej firmy. Typowe sytuacje przedstawiono na rysunkach 11.1. do 11.4.
Rysunek 11.1. Dostęp zdalny dla klientów mobilnych (roaming clients)
Rysunek 11.2. Dostęp zdalny dla pracowników pracujących w domu (home workers)
Rysunek 11.3. Dostęp zdalny dla oddziałów firmy
Rysunek 11.4. Komunikacja dwukierunkowa pomiędzy głównymi lokacjami (sites) 2.
3.
Określ sposób połączenia z Internetem. Pojawia się tu kilka kwestii: •
usługodawca internetowy (ISP) — z usług usługodawcy internetowego korzysta się, jeśli występują zdalni użytkownicy mobilni (remote roaming users), a zwłaszcza jeśli można znaleźć konsorcjum usługodawców internetowych (ISP consortium) świadczące usługi na całym świecie bez dodatkowych wymagań dotyczących konfiguracji. Telepracownicy (home workers) także będą łączyć się za pomocą usługodawcy internetowego. W przypadku oddziału firmy (branch office) łączącego się z dyrekcja główna (corporate headquarters) można wziąć pod uwagę zainstalowanie serwera IIS,
•
router wywołujący (calling router) — czy każdy z komputerów w odziale firmy będzie klientem Wirtualnej Sieci Prywatnej (VPN client) czy też powinno zostać zainstalowane połączenie router-router (router-to-router connection)? Drugi przypadek jest zazwyczaj stosowany we wszystkich oddziałach, oprócz tych najmniejszych.
Określ połączenia klientów korzystających z dostępu zdalnego. Należy wziąć pod uwagę następujące czynniki: •
połączenia portów (port connections) — jak wiele portów PPTP lub L2TP musi być zainstalowanych aby przyjąć maksymalną liczbę połączeń klientów?
•
konta użytkowników — kto będzie miał zezwolenie na zdalne logowanie się do sieci? Czy wszyscy użytkownicy zdalni (remote users) będą mieli te same prawa i uprawnienia? Innymi słowy, czy skonfigurowana będzie jedna grupa użytkowników zdalnych, czy też będzie kilka kategorii użytkowników zdalnych?
•
ograniczenia — jakie specjalne ograniczenia będą ustanowione dla użytkowników zdalnych (remote users)? Dzięki Wirtualnym Sieciom Prywatnym (VPNs) dostęp zdalny stanowi mniejsze zagrożenie dla bezpieczeństwa sieci, ale nadal można chronić pewne części intranetu firmy. W systemach wymagających wysokiego poziomu zabezpieczeń można rozważyć umieszczenie wszystkich zasobów, które będą potrzebne użytkownikom zdalnym na serwerze Wirtualnych Sieci Prywatnych (VPN server) i ograniczenie dostępu dla użytkowników zdalnych tylko do tego komputera,
•
4.
5.
uwierzytelnianie klienta — należy określić, w jaki sposób serwer wirtualnych sieci prywatnych będzie uwierzytelniać klienta. Można korzystać z usług katalogowych Active Directory lub protokołu RADIUS,
Określ połączenie pomiędzy routerami (router-to-router connection). Należy określić kilka opcji: •
technologia połączenia — w jaki sposób zostanie ustanowione połączenie stałe (persistent connection) z Internetem? Czy natężenie ruchu w sieci usprawiedliwia, np. koszt dzierżawienia całej linii T1 lub jej części?
•
połączenie na żądanie (demand dialing) — czy zainstalowane zostanie łączenie na żądanie, aby zautomatyzować inicjowanie połączenia pomiędzy odległymi oddziałami,
•
typ połączenia — czy należy ustanowić jedno- lub dwukierunkowe połączenia za pomocą Wirtualnych Sieci Prywatnych (VPN connections)? Czy dyrekcja główna (corporate headquarters) będzie kiedykolwiek inicjować połączenie?
•
uwierzytelnianie wzajemne — określ w jaki spsoób serwery, korzystające z usługi RRAS, będą wzajemnie się uwierzytelniać. Można stosować weryfiakcję za pomocą protokołu RADIUS lub usług katalogowych Active Directory. W drugim przypadku wszystkie serwery RRAS powinny znajdować się w grupie zabezpieczeń (security group).
Określ metodę szyfrowania. Protokoły obsługują kilka metod szyfrowania. Obecnie IPSec zabezpiecza dane przesyłane przez sieć, ale nie zapewnia w pełni funkcjonalnego rozwiązania Wirtualnych Sieci Prywatnych (VPNs). Wybór jest następujący: •
protokół PPTP z zastosowaniem MPPE — wybierz tę opcję, jeśli pracujesz w środowisku mieszanym, jeśli nie istnieje infrastruktura certyfikatów komputerów (machine-based certificate infrastructure) lub jeśli wystarczające jest uwierzytelnianie użytkownika i nie jest konieczne uwierzytelnianie komputera,
•
L2TP w IPSec (L2TP over IPSec)— wybierz tę opcję, jeśli wszystkie komputery, które są punktami końcowymi tuneli (tunnel endpoints) pracują pod kontrolą systemu Windows 2000. Istnieje infrastruktura certyfikatów komputerów, jak np. Kerberos 5 i potrzebne jest dodatkowe zabezpieczanie uwierzytelniania komputera. Jest to domyślne ustawienie systemu Windows 2000.
6.
Określ długość klucza. Wybór szyfrowania z kluczem 128-bitowym daje wysoki poziom zabezpieczeń, ale nie jest dostępny poza Ameryką Północną.
7.
Określ metodę uwierzytelniania. Metody uwierzytelniania opisano w części niniejszego rozdziału pod tytułem „W skrócie”. Oto krótkie przypomnienie: •
EAP — metody, w skład których wchodzą między innymi Wyzwanie MD5 (MD5 challenge) oraz Karta elektroniczna lub inny certyfikat (smart card or other certificate). Protokół EAP jest głównie stosowany do uwierzytelniania za pomocą kart elektronicznych (smart card authentication),
Uwaga: W rzeczywistości metodą uwierzytelniania jest EAP-TLS, ale w oknie dialogowym Instalator (Setup) podano tylko „EAP”. Konfigurowanie metody uwierzytelniania opisano w dalszej części niniejszego rozdziału, w podrozdziale „Konfigurowanie serwera VPN”.
8.
•
MS-CHAP v2 — służy do uwierzytelniania zaszyfrowanego wyłącznie klientów Windows 2000,
•
MS-CHAP — służy do uwierzytelniania zaszyfrowanego klientów Windows 95, Windows 98, Windows 98 i Windows 2000,
•
CHAP — służy do uwierzytelniania zaszyfrowanego klientów używających różnych systemów operacyjnych,
•
SPAP — służy do uwierzytelniania zaszyfrowanego klientów korzystających z oprogramowania Shiva LAN Rover,
•
PAP — umożliwia uwierzytelnianie niezaszyfrowane. Stosuje się go w przypadku, gdy klient nie obsługuje żadnego innego protokołu,
•
dostęp nieuwierzytelniony — umożliwia systemom zdalnym łączenie się bez uwierzytelniania.
Określ metodę przydzielania adresów IP. Serwer VPN może mieć przyporządkowaną statyczną pulę adresów IP lub można korzystać z protokołu DHCP (Dynamic Host Configuration Protocol). Mogą wystąpić problemy jeżeli komputerom-klientom VPN przydziela się statyczne adresy IP.
Wskazówka: Jeśli serwer VPN jest skonfigurowany w ten sposób, by przydzielać adresy IP za pomocą protokołu DHCP, a serwer DHCP nie jest dostępny, wówczas serwer VPN przydziela adresy z zakresu adresów Automatic Private IP Addressing (APIPA) 169.254.0.1 do 169.254.255.254. Przydzielanie klientom zdalnym adresów z zakresu APIPA działa poprawnie tylko wtedy, gdy sieć, w której znajduje się serwer VPN również korzysta z adresów APIPA.
9.
Określ pozycję serwera VPN względem zapory ogniowej (firewall). Jeśli zapora ogniowa lub server NAT (Network Address Translation), taki jak serwer Proxy, ochrania sieć firmową (corporate network), można podjąć decyzję o umieszczeniu serwera VPN w strefie chronionej lub poza nią: •
na zewnątrz zapory ogniowej — serwer VPN można umieścić na zewnątrz zapory ogniowej jeśli ryzyko narażenia serwera na ataki przez Internet nie zagraża bezpieczeństwu sieci, a wszystkie dane o znaczeniu strategicznym znajdują się za zaporą ogniową i dostęp zdalny poprzez nią jest ograniczony tylko do serwera VPN. Umieszczenie serwera VPN na zewnątrz zapory może rozwiązać zagrożenia związane z umożliwieniem dostępu do pełnego zakresu adresów IP wirtualnych sieci prywatnych poprzez zaporę (firewall). Kiedy serwer VPN znajduje się na zewnątrz zapory ogniowej, rozdzielone zostają funkcje wirtualnych sieci prywatnych i usługi RRAS. Inaczej mówiąc, serwer RRAS połączony z serwerem VPN znajduje się za zaporą ogniową,
Wskazówka: Kiedy serwer VPN jest umieszczony na zewnątrz zapory ogniowej (firewall) należy utworzyć tunel IPSec (IPSec tunnel) pomiędzy serwerem VPN a serwerem RRAS, znajdującym się za zaporą ogniową i skonfigurować zaporę w ten sposób, by umożliwić komunikacje tylko przez ten tunel. Konieczne jest szyfrowanie wszystkich danych przesyłanych pomiędzy serwerami, korzystając z klucza o maksymalnej możliwej długości i skonfigurowanie serwera VPN jako serwera autonomicznego (standalone server), co ograniczy dostęp do baz danych usług katalogowych Active Directory.
•
za zaporą ogniową (firewall) — jeśli nie wolno narażać serwera VPN na ataki przez Internet, a można zezwolić na dostęp do pełnego zakresu adresów IP wirtualnych sieci prywatnych poprzez zaporę, konieczne jest umieszczenie serwera VPN za zaporą ogniową. W tym przypadku należy ją skonfigurować w ten sposób, aby umożliwić przesyłanie danych za pomocą protokołów PPTP i L2TP w całym zakresie adresów VPN.
10. Zajmij się zagadnieniami związanymi z zastosowaniem translatora adresów sieciowych (Network Address Translator — NAT). Jeśli w danej sieci znajduje się serwer NAT, taki jak serwer Proxy, może pojawić się problem związany z podłączeniem do sieci serwera VPN, ponieważ niektóre serwery aplikacji (application severs) zapisują bezpośrednio adres IP i numer portu klienta zdalnego. Aby takie aplikacje mogły pracować prawidłowo, konieczna jest dla nich tablica translacji (translation table) w urządzeniu mającym funkcję translatora adresów sieciowych (NAT device). Protokół PPTP nie szyfruje nagłówków IP (IP headers) i może być stosowany z dowolnym urządzeniem, mającym funkcję translatora adresów sieciowych (NAT device). Jednak IPSec z szyfrowaniem za pomocą nagłówków uwierzytelnijących (AH encryption) szyfruje nagłówki IP. Tak więc protokół L2TP po IPSec może nie działać prawidłowo w przypadku apliakcji, które wymagają tablic translacji translatora adresów sieciowych (NAT translation tables). 11. Podejmij decyzję, czy wprowadzić protokół RADIUS. Jest to korzystne w następujących przypadkach: •
konieczne jest uwierzytelnianie kont użytkowników zdalnych za pomocą metod innych niż uwierzytelnianie w systemie Windows 2000, np. klientów uniksowych (Unix clients),
•
w danej sieci jest wiele serwerów VPN lub (i) RRAS, które należy tak skonfigurować, aby korzystały ze wspólnych zasad (common policies),
•
konieczne jest scentralizowane zapisywanie (accounting) statusu logowania.
12. Zajmij się zagadnieniami związanymi z serwerami VPN. Wiele serwerów VPN zapewnia wysoką dostępność zasobów sieciowych oraz przełączanie awaryjne (fail-over support). Można je skonfigurować, korzystając z któregoś z podanych poniżej sposobów: •
klastrowanie w systemie Windows (Windows clustering) — zapewnia redundancję serwerów VPN i scentralizowane administrowanie. Wszystkie serwery w danym klastrze (cluster) powinny mieć szybkie łącza stałe. Klastrowanie jest zasobochłonne (resourceintensive). Przełączanie awaryjne (fail-over) następuje automatycznie i klienci dostępu zdalnego (remote access clients) nie otrzymują komunikatów o przekroczeniu czasu (time-out messages), próbując połączyć się z nieczynnym serwerem VPN,
•
cykliczny system DNS (Domain Name System round-robin) — w metodzie tej dla grupy serwerów VPN stosuje się tę samą pełną nazwę domeny (Fully Qualified Domain Name — FQDN), ale oddzielne adresy IP. Metoda cykliczna (round-robin) zapewnia redundancję (redundancy), dostępność (availability) i jest mniej zasobochłonna niż klastrowanie. Przełączanie awaryjne nie jest automatyczne i użytkownicy, próbując połączyć się z nieczynnym serwerem VPN, będą otrzymywali komunikaty o przekroczeniu czasu (time-out messages).
Konfigurowanie serwera VPN Zwykle Wirtualna Sieć Prywatna (Virtual Private Network) jest ustanawiana pomiędzy klientem zdalnym (remote client) a serwerem RRAS lub pomiędzy dwoma serwerami RRAS. Poniżej opisano procedurę instalowania serwera RRAS, który jest skonfigurowany w ten sposób, by używać Wirtualnych Sieci Prywatnych (VPNs) za pomocą serwera IIS domeny lub usługodawcy internetowego (ISP).
Uwaga: Serwer RRAS skonfigurowany w ten sposób, by stosować Wirtualne Sieci Prywatne (VPN) nosi nazwę serwera VPN. Jest to wygodne określenie, stosowane w niniejszym rozdziale, chociaż nie jest ścisłe, ponieważ Wirtualne Sieci Prywatne (VPN) nie są usługą.
1.
Zaloguj się jako administrator na serwerze Windows 2000, który będzie obsługiwał dostęp zdalny.
2.
Przejdź do menu Start/Programy/Narzędzia administracyjne (Start\Programs\Administrative tools) i wybierz opcję Routing i Dostęp Zdalny (Routing and Remote Access).
3.
Kliknij pozycję Routing i Dostęp Zdalny. Z menu Akcje (Action) wybierz polecenie Dodaj Serwer (Add Server).
4.
Zaznacz opcję Ten Komputer (This Computer) i naciśnij przycisk OK.
5.
Prawym przyciskiem myszki zaznacz nazwę serwera i z menu wybierz Konfiguruj i włącz routing i dostęp zdalny (Configure and enable routing and remote access).
6.
Uruchomiony zostanie Kreator instalacji serwera routingu i dostępu zdalnego (Routing and remote access server setup wizard). Naciśnij przycisk Dalej (Next).
7.
Wybierz opcję Serwer Wirtualnej Sieci Prywatnej (Virtual Private Network Server) i wybierz Dalej.
Uwaga: Można również określić połączenia przychodzące, przechodząc do menu Start\Ustawienia\Połączenia sieciowe i telefoniczne (Start\Settings\Network and dial-up connections) i wybierając polecenie Utwórz Nowe Połączenie (Make New Connection).
8.
Jeśli lista protokołów komunikacyjnych zawiera wszystkie wymagane protokoły, zaznacz opcję Tak, wszystkie dostępne protokoły są na tej liście (Yes, all of the available protocols are on this list). W przeciwnym razie wybierz Nie, chcę dodać protokoły (No, I need to add protocols). Protokół, który ma zostać dodany, musi być zainstalowany na tym komputerze. W niniejszym przykładzie przyjęto, że wszystkie protokoły znajdują się na liście.
9.
Naciśnij przycisk Dalej. Podaj połączenie z Internetem, z którego korzysta serwer. Połączenie może być wykonywane za pomocą IIS w danej sieci lub za pomocą usługodawcy internetowego.
10. Naciśnij Dalej. 11. Aby przydzielić adresy użytkownikom zdalnym oraz użytkownikom wewnętrznym (internal user), można korzystać z usługi RAS, która przydziela adresy IP z podanego zakresu lub z serwera DHCP. Jeśli adresy mają być przydzielane z określonego zakresu, należy upewnić się, czy wszystkie te adresy zostały usuniete z zakresu DHCP. Wybierz odpowiednią opcję i naciśnij przycisk Dalej. 12. Jeśli wybrałeś przydzielanie adresów z określonego zakresu (pula statyczna — static pool) podaj zakres adresów i naciśnij przycisk Dalej (Next). 13. W przypadku jeśli jest kilka serwerów RRAS i chcesz zarządzać nimi w sposób scentralizowany, możesz w tym celu wybrać serwer RADIUS. Jeśli opcja ta została wybrana, zostaniesz poproszony o podanie nazw serwera podstawowego i serwera alternatywnego RADIUS w danej sieci oraz klucza tajnego (hasła), koniecznego do uzyskania dostępu. Wybierz opcję Nie, nie chcę teraz konfigurować tego serwera do używania usługi RADIUS (No, I don’t want to set up this server to use RADIUS now) lub opcję Tak, chcę używać serwera usługi RADIUS (Yes, I want to use a RADIUS server) i podaj odpowiednie informacje.
Wskazówka: Można skonfigurować serwery usługi RADIUS z mocą wsteczną (retrospectively).
14. Naciśnij przycisk Dalej, a potem Zakończ (Finish). 15. Pojawi się komunikat radzący, by skonfigurować agenta przekazywania DHCP (DHCP relay agent), podając adres serwera DHCP w danej sieci. Aby zamknąć okno komunikatu, potwierdź, klikając OK. 16. Rozwiń drzewo Routing i Dostęp Zdalny (Routing And Remote Access) w sposób przedstawiony na rysunku 11.5. Prawym przyciskiem myszki kliknij pozycję Agent Przekazywania DHCP (DHCP Relay Agent) i z menu wybierz opcję Właściwości (Properties).
17. Do listy Agent Przekazywania DHCP Właściwości (DHCP Relay Agent Properties) wpisz adres serwera DHCP danej sieci. Naciśnij przycisk OK. 18. Zamknij przystawkę (snap-in) konsoli MMC.
Rysunek 11.5. Konfigurowanie Agenta Przekazywania DHCP (DHCP Relay Agent)
Konfigurowanie serwera VPN Kiedy serwer RRAS zostanie skonfigurowany w ten sposób, by korzystać z Wirtualnych Sieci Prywatnych (VPNs), konieczne jest podjęcie wielu decyzji dotyczących konfiguracji. Poniższa
procedura konfigurowania serwera VPN nie określa konkretnych opcji, ale podaje, gdzie można je znaleźć i omawia skutki dokonanych zmian. 1.
Zaloguj się jako administrator na serwerze RRAS.
2.
Przejdź do menu Start|Programy|Narzędzia administracyjne (Start\Programs\Administrative tools) i wybierz polecenie Routing i Dostęp Zdalny (Routing And Remote Access).
3.
Prawym przyciskiem myszki kliknij nazwę serwera i z menu wybierz pozycję Właściwości (Properties). Prawdopodobnie nie będziesz chciał zmieniać ustawień w zakładce Ogólne (General), o ile nie będzie chodziło o wyłączenie usługi RAS lub routingu.
4.
Wybierz zakładkę Zabezpieczenia (Security).
5.
Przejdź do listy usługodawców uwierzytelniania (authentication provider drop — down box). Usługodawcą (provider) może być system Windows lub usługa RADIUS. Jeśli nie określiłeś serwera usługi RADIUS na etapie konfigurowania usługi RRAS lub jeśli teraz zainstalowałeś w sieci taki serwer, można to zrobić teraz.
Wskazówka: Uwierzytelnianie przez usługę RADIUS może uwierzytelniać użytkowników zdalnych za pomocą metod innych niż w przypadku uwierzytelniania przez system Windows 2000, np. korzystając z usługi RADIUS, serwer VPN może uwierzytelniać użytkowników zdalnych, uzyskując dostęp do bazy danych kont użytkowników systemu Unix.
6.
Przejdź do listy Dostawca Księgowania (Accounting Provider drop — down box). Dostawca księgowania utrzymuje listę żądań i ustawień połączeń. Do wyboru są: Windows, RADIUS lub brak.
7.
Naciśnij przycisk Metody Uwierzytelniania (Authentication Methods). Można wybrać jeden lub kilka protokołów uwierzytelniania (zob. rysunek 11.6). Naciśnij OK.
8.
Wybierz zakładkę IP. W oknie tym można dodać adres do puli adresów statycznych, włączyć przydzielanie adresów przez usługę DHCP, włączyć lub wyłączyć routing IP oraz włączyć lub wyłączyć połączenia dostępu zdalnego i wybierania numerów na żądanie oparte na protokole IP.
9.
Wybierz zakładkę PPP. W oknie tym można włączyć lub wyłączyć następujące funkcje: •
łącze wielokrotne (multilink). Jeśli jest włączone, masz również możliwość włączenia dynamicznej kontroli przepustowości (dynamic bandwidth control),
•
rozszerzenia protokołu kontroli łączy (Link Control Protocol (LCP) extensions),
•
kompresja programowa.
Rysunek 11.6. Wybór metod uwierzytelniania 10. Wybierz zakładkę Rejestrowanie Zdarzeń (Event Logging). W oknie tym można ustawić poziom rejestrowania zdarzeń i włączyć zapisywanie komunikatów sterujących protokołu PPP (dziennik protokołu PPP, który jest przydatny jako narzędzie do wykrywania błędów w przypadku występowania problemów z połączeniami zdalnymi). 11. Po wybraniu odpowiednich opcji naciśnij przycisk OK. Jeśli pojawi się okno dialogowe odsyłające do pliku pomocy naciśnij Nie (No), aby je zamknąć. Zaznacz OK i zamknij przystawkę (snap-in) konsoli MMC.
Konfigurowanie klienta VPN Komputerem-klientem VPN może być stacja robocza, laptop przenoszony z miejsca na miejsce przez sprzedawcę (salesperson) i używany do łączenia się z usługodawcą internetowym (ISP) z dowolnego miejsca. Komputerem-klientem może być również komputer stacjonarny, np. w oddziale firmy, który ma bezpośredni dostęp do Wirualnej Sieć Prywatnej (VPN) przez połączenie intranetowe lub interentowe. Na ogół takie komputery mają dostęp do Wirtualnej Sieci Prywatnej
(VPN) za pośrednictwem serwera usługi RRAS, zainstalowanego w oddziale firmy. W takim przypadku klientem VPN jest zdalny serwer usługi RRAS lub router wywołujący. Poniżej zamieszczono procedurę konfigurowania komputera-klienta: 1.
Zaloguj się na komputerze-kliencie.
2.
Przejdź do menu Start/Ustawienia/Połączenia sieciowe i telefoniczne (Start\Settings\Network and dial-up connections) i wybierz polecenie Utwórz Nowe Połączenie (Make New Connection).
3.
Uruchomiony zostanie Kreator Połączeń Sieciowych (Network Connection Wizard). Naciśnij przycisk Dalej (Next).
4.
Pojawi się okno dialogowe Typ Połączenia Sieciowego (Network Connection Type); zob. rysunek 11.7. Użytkownik mobilny (roaming user) łączący się za pośrednictwem usługodawcy internetowego (ISP) wybierze opcję Połącz z siecią Internet używając połączenia telefonicznego (Dial-up to the Internet) i poda niezbędne informacje.
5.
Aby skonfigurować stacjonarnego klienta zdalnego, korzystającego z Wirtualnych Sieci Prywatnych (VPN) bezpośrednio lub, co bardziej prawdopodobne, za pomocą serwera usługi RRAS na drugim końcu tunelu, wyierz opcję Połącz z siecią prywatną za pośrednictwem Internetu (Connect to a private network through the Internet). Naciśnij Dalej. Po pojawieniu się monitu określ, czy chcesz, aby system Windows 2000 wybierał automatycznie połączenie początkowe, a nstępnie zaznacz Dalej.
6.
Podaj nazwę komputera (host name) lub adres IP punktu końcowego tunelu (tunnel endpoint), tzn. serwera RRAS, który obsługuje Wirtualne Sieci Prywatne (VPN-enabled RRAS server).
OSTRZEŻENIE! Jeśli połączenie nie było konfigurowane z obydwu stron przez tą samą osobę, konieczne będzie przekazanie komuś innemu adresu IP lub nazwy komputera (host name) serwera usługi RRAS, co stanowi zagrożenie dla bezpieczeństwa systemu. W takiej sytuacji należy rozważyć zastosowanie usługi NAT, np. serwera Proxy. Trzeba jednak pamietać, że zastosowanie protokołu L2TP w IPSec (L2TP over IPSec) może nie działać prawidłowwo w przypadku aplikacji, które wymagają tablic translacji translatora adresów sieciowych (NAT translation tables).
Rysunek 11.7. Wybór typu połączenia sieciowego 7.
Jeśli konfigurujesz połączenie dla pojedynczego komputera-klienta, wybierz opcję Tylko Dla Mnie (Only For Myself). W przeciwnym razie zaznacz Dla Wszystkich Użytkowników (For All Users). W zależności od domyślnych zasad dostępu zdalnego (remote access policy) w danym serwerze, może pojawić się pytanie, czy włączyć udostępnianie połączenia internetowego (Internet connection sharing)? Jeśli tak, to przejdź do czynności 8. Jeśli nie, naciśnij Dalej i przejdź bezpośrednio do czynności 10.
8.
Jeśli chcesz, aby inne komputery w sieci miały dostę do zasobów poprzez dane połączenie, a jest tak w przypadku skonfigurowania usługi RRAS w punkcie końcowym (RRAS endpoint), zaznacz opcję Włącz udostępnianie połączenia internetowego dla tego połączenia (Enable Internet connection sharing for this connection). Daje to możliwość włączenia wybierania numerów na żądanie (demand dialing). Naciśnij przycisk Dalej (Next).
9.
Jeśli włączyłeś udostępnianie połączenia internetowego (Internet connection sharing) pojawi się ostrzeżenie o tym, że możesz stracić możliwość łączenia się z innymi komputerami w sieci, które mają skonfigurowane adresy statyczne. Ostrzeżenie to pojawia się, ponieważ adres IP może być wybrany z puli adresów statycznych zdalnego serwera usługi RRAS lub za pomocą DHCP. W tym przypadku powinieneś upewnić się, czy komputery te mają wybraną opcję automatycznego uzyskiwania adresów IP. Aby wprowadzić udostępnianie połączenia internetowego, naciśnij przycisk Tak (Yes).
10. Podaj nazwę połączenia lub zaakceptuj domyślną, a następnie naciśnij Zakończ (Finish). 11. Aby podłączyć się do Wirtualnych Sieci Prywatnych (VPNs) w oknie dialogowym Połącz Wirtualne Połączenia Prywatne (Connect VPN) podaj nazwę twojego konta i hasło, a następnie kliknij Połącz (Connect). Twoje konto musi mieć włączoną opcję zdalnego dostępu. Aby zamknąć okno dialogowe Połączenie Zakończone (Connection Complete), zaznacz OK.
Organizowanie kont użytkowników usługi Dostęp Zdalny (Remote Access) Włączenie uprawnień do wybierania numerów(dial-in permission) dla konta użytkownika odbywa się kolejno dla każdego konta (account-by-account basis). Jednak dobrze jest utworzyć grupy kont, aby można było zastosować zasady grupowe (group policies), np. zasady inspekcji (audit policies). Konta, z których korzysta się, aby uzyskać dostęp zdalny, umiesczone są w jednej lub kliku grupach, zależnie od tego, czy istnieją użytkownicy zdalni o różnym zakresie dostępu do zasobów. Zazwyczaj umieszcza się taką grupę (lub grupy) w jednostce organizacyjnej (OU) i stosuje się wobec niej zasady zabezpieczeń (security policies). Jeśli użytkownikami zdalnymi są pracownicy oddziału firmy, mogą oni już znajdować się w jednostce organizacyjnej. Ponieżej przedstawiono procedurę organizowania kont użytkowników zdalnych: 1.
Zaloguj się jako administrator i uzyskaj dostęp do kontrolera domeny (DC).
2.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Active Directory Użytkownicy i Komputery (Active Directory Users and Computers).
3.
Prawym przyciskiem myszki zaznacz domenę lub jednostkę organizacyjną (OU) w drzewie domeny i utwórz nowa jednostkę (OU). Nazwij ją Home Workers.
4.
Prawym przyciskiem myszki wybierz nową jednostkę organizacyjną i utwórz grupę. Nazwij ją Ordinary Home Workers. Później możesz w danej jednostce dodać inne grupy, np. grupę Administrative Home Workers.
5.
Prawym przyciskiem myszki kliknij nową jednostkę organizacyjną i z menu wybierz opcję Właściwości (Properties).
6.
W oknie zakładki Zasady Grupowe (Group Policy) utwórz obiekt zasad grupowych (Group Policy Object — GPO). Edytuj ten obiekt zasad grupowych (GPO), aby zdefiniować zasady grupowe, które mają być stosowane wobec telepracowników (home worker).
Rozwiązania pokrewne zobacz na stronie: Edytowanie obiektu zasad grupowych (Group Policy Object — GPO)
7.
Zaznacz wszystkie konta użytkowników zdalnych, przenieś je do jednostki organizacyjnej Home Workers i umieść w grupie Ordinary Home Workers. Zwróć uwagę, że operacje te można wykonywać jednocześnie dla wielu kont, co przedstawia rysunek 11.8. Jeśli nie ma jeszcze kont użytkowników zdalnych, to utwórz je w jednostce organizacyjnej Home Workers.
8.
Prawym przyciskiem myszki klikaj każde konto i z menu wybieraj opcję Właściwości. Jeśli chcesz umożliwić dostęp zdalny za pomocą połączenia telefonicznego, to w oknie zakładki telefonowanie (Dial-in) możesz zaznaczyć opcję Zezwalaj Na Dostęp (Allow Access). Jeśli ustanowione są zasady dostępu zdalnego (remote access policy), które mogą np. ograniczać godziny, w których użytkownik zdalny może logować się lub ograniczać czas połączenia, można zaznaczyć opcję Kontroluj dostęp poprzez zasady dostępu zdalnego (Control access through remote access policy). Zasady dostępu zdalnego (remote access policies) są konfigurowane za pomocą przystawki (snap-in) Ruting i dostęp zdalny (Routing and remote access), co opisano w kolejnym podrozdziale.
Rysunek 11.8. Przenoszenie kilku kont użytkowników
Tworzenie Zasad Dostępu Zdalnego (Remote Access Policy) dla połączeń VPN ruter-ruter
Jeśli topologia Wirtualnej Sieci Prywatnej (VPN) wymaga połączenia ruter-ruter (zob. rysunki 11.3 oraz 11.4), to wtedy można ustanowić zasady, które mówią, że w przypadku takiego połączenia będą stosowane określone metody uwierzytelniania i klucz o określonej długości. Porcedura tworzenia zasad dostępu zdalnego (remote access policy) jest następująca: 1.
Z menu Narzędzia admnistracyjne (Administrative tools) wybierz pozycję Active Directory Użytkownicy i Komputery (Active Directory Users and Computers).
2.
W kontenerze Komputery (Computers container) utwórz globalną grupę zabezpieczeń (global security group) pod nazwą VPN-Routers.
3.
Dodaj konta ruterów wywołujących (callin routers), które inicjują połączenia VPN ruter-ruter.
4.
Z menu Narzędzia administracyjne wybierz pozycję Ruting i dostęp zdalny.
5.
Kliknij dwukrotnie nazwę komputera-rutera odpowiadającego (answering router). Prawym przyciskiem myszki wybierz pozycję Zasady Dostępu Zdalnego (Remote Access Policies) i Nowe Zasady Dostępu Zdalnego (New Remote Access Policy).
6.
Podaj nazwę zasad, np. Router-to-Router. Naciśnij przycisk Dalej (Next).
7.
Naciśnij przycisk Dodaj (Add). Kliknij Typ Portu NAS (NAS Port Type) i ponownie Dodaj.
8.
Zaznacz Virtual (VPN). Naciśnij przycisk Dodaj i OK.
9.
W oknie dialogowym Zasady Dostępu Zdalnego zaznacz Dodaj. Wybierz Grupy Systemu Windows (Windows Groups).
10. Naciśnij przycisk Dodaj. Pojawi się okno dialogowe Grupy (Groups). Naciśnij Dodaj. 11. Wybierz grupę VPN-Routers. Znów naciśnij Dodaj i OK. Aby zamknąć okno dialogowe Grupy, naciśnij OK. 12. Naciśnij przycisk Dalej. Zaznacz opcję Udziel Uprawnień Do Dostępu Zdalnego (Grant Remote Access Permission). 13. Naciśnij przycisk Dalej oraz Edytuj Profil (Edit Profile). 14. Określ odpowiednią metodę uwierzytelniania i długość klucza. Naciśnij przycisk OK. Jeśli pojawi się okno odsyłające do pliku pomocy, zamknij je naciskając Nie (No). 15. Zaznacz Zakończ (Finish).
Wskazówka: Powyższą procedurę można również zastosować do tworzenia oddzielnych zasad dostępu zdalnego (remote access policies) dla połączeń za pomocą protokołu PPTP i L2TP. W oknie dialogowym Dodaj Zasady Dostępu Zdalnego (Add Remote Access Policies) wybierz opcję Typ Tunelu (Tunnel Type). Typ tunelu ustaw, np. na Point-to-Point Tunneling Protocol, udziel uprawnień dostępu zdalnego, a następnie — po naciśnięciu przycisku Edytuj Profil (Edit Profile) — podaj ustawienia uwierzytelniania i szyfrowania.
Włączanie uwierzytelniania wzajemnego W przypadku dwukierunkowych połączeń inicjowanych dowolny z ruterów może być serwerem VPN lub klientem VPN, w zależności od tego, kto zainicjował połączenie (zob. rysunek 11.4). Obydwa rutery muszą być skonfigurowane w ten sposób, by mogły inicjować i akceptować połączenia VPN. W przypadku dwukierunkowego inicjowanego połączenia VPN ruter-ruter konieczne jest dodanie kont użytkowników do obydwu ruterów, aby dane uwierzytelniające rutera wywołującego (calling router) mogły być sprawdzone przez ruter odpowiadający (answering router). Interfejsy łączenia na żądanie (demand-dial interfaces), noszące taką sama nazwę jak konto użytkownika, z którego korzysta ruter wywołujący muszą być w pełni skonfigurowane dla obydwu ruterów, włącznie z podaniem nazwy komputera (host name) lub adresu IP rutera odpowiadającego oraz danymi uwierzytelniającymi konta użytkownika (user account credentials) do uwierzytelniania rutera wywołującego. Poniżej zamieszczono procedurę konfigurowania uwierzytelniania wzajemnego dla dwukierunkowego połączenia inicjowanego (two-way initiated connection): 1.
Skonfiguruj obydwa rutery jako serwery VPN w sposób opisany powyżej w podrozdziałach „Instalowanie serwera VPN” i „Konfigurowanie serwera VPN”. Upewnij się, czy ustawienia szyfrowania i uwierzytelniania są jednakowe w obu komputerach.
2.
Skonfiguruj obydwa rutery jako klienty VPN, podając ten drugi jako serwer VPN, zgodnie z procedurą opisaną wcześniej w części „Instalowanie klienta VPN”.
3.
Jeśli do uwierzytelniania na poziomie komputerów korzysta się z certyfiaktów, to dla obydwu ruterów wymagane będą certyfikaty wydane przez jednostkę certyfikującą przedsiebiorstwa (enterprise CA). Odpowiednią procedurę podano w następnym podrozdziale.
Wskazówka: Jeśli klienic VPN łączą się za pomocą połączenia telefonicznego z serwerem VPN, pracującym pod kontrolą systemu Windows NT 4, który jest członkiem domeny systemu Windows 2000 w trybie mieszanym, konieczne jest sprawdzenie, czy w domenie włączono uwierzytelnianie usługi RAS systemu Windows NT 4. Aby zobaczyć aktualny status domeny, użyj polecenia Netsh ras show domain access. Aby w domenie włączyć uwierzytelnianie serwerów dostępu zdalnego, pracujących pod kontrolą systemu Windows NT 4, użyj polecenia Netsh ras set domain access.
Automatyczne uzyskiwanie certyfikatu komputera
Stosowanie certyfikatów komputerów do uwierzytelniania klientów VPN i serwerów VPN na poziomie komputerów jest wymagane w przypadku połączeń korzystających z protokołu L2TP w IPSec (L2TP over IPSec). Aby utworzyć połączenie L2TP over IPSec na komputerze-kliencie VPN i komputerze-serwerze VPN muszą zostać zainstalowane certyfikaty komputerów. Można to zrobić na dwa sposoby: •
skonfigurowanie komputerom w domenie systemu Windows 2000 automatycznego przydzielania certyfikatów komputerów,
•
użycie Menedżera Certyfikatów (Certificate Manager) do uzyskania certyfikatu komputera.
W przypadku dużej liczby klientów VPN metoda druga, ręczna, może być nużąca i bywa stosowana tylko, jeśli jednostka certyfikująca przedsiębiorstwa (enterprise CA) nie jest dostępna w domenie. Konfigurowanie automatycznych żądań certyfikatów dla komputerów, oprócz konfigurowania jednostki certyfikującej i instalowania certyfikatów jednostki (CA certificates), omówiono szczegółowo w rozdziale 7. Skrócony opis zamieszczono poniżej: Rozwiązania pokrewne zobacz na stronie: Konfigurowanie automatycznego żądania certyfikatów dla komputerów 1.
Edytuj obiekt zasad grupowych (GPO) Domyslne Zasady Domeny (Default Domain Policy).
2.
Rozwiń gałąź Konfiguracja Komputera/Ustawienia Systemu Windows/Ustawienia Zabezpieczeń/Zasady Klucza Publicznego (Computer Configuration/Windows Settings/Security Settings/Public Key Policies) i prawym przyciskiem myszki kliknij pozycję Ustawienia Automatycznego Żądania Certyfikatu (Automatic Certificate Request Settings).
3.
Z menu kontekstowego wybierz pozycję Nowy (New) i zaznacz Automatyczne Żądanie Certyfikatu. Uruchomiony zostanie Kreator Instalacji Automatycznego Żądania Certyfikatu (Automatic Certificate Request Setup Wizard). Naciśnij przycisk Dalej (Next).
4.
Wybierz szablon certyfikatu (certificate template) Komputer (Computer) i naciśnij Dalej.
5.
Wybierz jednostkę certyfikującą przedsiębiorstwa (enterprise CA) — zazwyczaj na liście jest tylko jedna — i naciśnij Dalej.
6.
Aby utworzyć automatyczne żądanie certyfikatu, wybierz Zakończ (Finish). Aby edytować obiekt zasad grupowych (GPO) Domyslne Zasady Domeny, naciśnij przycisk OK.
7.
Aby utworzyć certyfikat komputera dla serwera lub klienta VPN, uruchom ponownie komputer lub w wierszu poleceń systemu Windows 2000 wpisz: secedit /refreshpolicy machine_policy.
Rozwiązania pokrewne zobacz na stronie: Konfigurowanie jednostki certyfikującej (Certification Authority) Instalowanie certyfikatów jednostki certyfikującej (CA certificates)
Zastosowanie polecenia secedit
Dodawanie portów L2TP i PPTP Domyślnie dla przesyłania danych za pomocą protokołu L2TP lub PPTP włączonych jest 128 portów. Jeśli jest więcej niż 128 klientów VPN, konieczna jest większa liczba portów. Poniżej zamieszczono procedurę dodawania portów protokołów PPTP lub L2TP: 1.
Zaloguj się do serwera VPN jako administrator.
2.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Ruting i Dostęp Zdalny (Routing And Remote Access).
3.
Rozwiń gałąź Nazwa Serwera, prawym przyciskiem myszki zaznacz pozycję Porty (Ports) i z menu wybierz Właściwości (Properties).
4.
W zależności od stosowanego protokołu wybierz opcję WAN Miniport (PPTP) lub WAN Miniport (L2TP). Naciśnij przycisk Konfiguruj (Configure).
5.
W polu Maksymalna Liczba Portów (Maximum Ports) wpisz liczbę portów (maksymalnie do 30 000) i naciśnij przycisk OK.
6.
Naciśnij OK i zamknij przystawkę (snap-in) konsoli MMC.
Konfigurowanie serwera usługi RADIUS Serwer usługi RADIUS korzysta z usługi uwierzytelnienia internetowego (Internet Authentication Service — IAS), aby zapewnić uwierzytelnianie i rozliczanie (accounting support) w sieciach, w których występuje wiele serwerów RRAS i VPN. Usługa RADIUS może być stosowana nawet w sieciach rozległych (WAN) i zaimplementowana w systemie Windows 2000 Advanced Server, na którym także musi być uruchomiona usługa IIS. W niniejszym podrozdziale krótko omówiono instalowanie i konfigurowanie serwera usługi RADIUS. Pełne omówienie tego zagadnienia stworzyłoby osobną książkę. Poniżej zamieszczono procedurę instalowania serwera usługi RADIUS: 1.
Zaloguj się do serwera IIS w domenie jako administrator.
2.
Zainstaluj usługę IAS za pomocą polecenia Dodaj/Usuń programy (Add/Remove programs) znajdującego się w Panelu Sterowania (Control Panel), o ile nie została wcześniej zainstalowana. Zwróć uwagę, że usługa IAS jest składnikiem Usług Sieciowych (Networking Services).
3.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Usługa Uwierzytelniania Internetowego (Internet AS).
4.
Prawym przyciskiem myszki kliknij usługę Usługa Uwierzytelniania Internetowego i z menu wybierz Właściwości (Properties).
5.
W oknie zakładki Usługa (Service) zaznacz obydwie opcje dziennika zdarzeń.
6.
W oknie zakładki RADIUS określ porty UDP uwierzytelniania i obsługi kont usługi RADIUS.
7.
Jeśli nazwy obszarów (realm names) stosowane u usługodawców internetowych (ISPs) do uzyskania dostępu do sieci przedsiebiorstwa różnią się od tych, które są konieczne do uzyskania dostępu do domen przedsiebiorstwa (corporate domains), w oknie zakładki Obszary (Realms) określ reguły zamiany tekstu (text replacement rules) dla manipulowania przy nazwach obszarów.
8.
Naciśnij przycisk OK. W drzewie konsoli prawym przyciskiem myszki wybierz pozycję Klienty (Clients) i opcję Nowy Klient (New Client).
9.
Postępuj zgodnie z komunikatami wyświetlanymi przez system i podaj informacje o każdym z klientów usługi RADIUS.
Wskazówka: Jeśli dany serwer usługi RADIUS jest osiągalny tylko za pomocą interfejsu internetowego, dodaj filtr wejściowy i filtr wyjściowy do interfejsu internetowego dla portu UDP 1812 (lub — w przypadku starszej wersji usługi RADIUS — portu UDP 1645) dla uwierzytelniania usługi RADIUS. Dla obsługi kont usługi RADIUS (RADIUS accounting) dodaj filtr wejściowy lub wyjściowy do interfejsu internetowego dla portu UDP 1813 (lub portu UDP 1646 — w przypadku starszych wersji serwerów RADIUS).
Rozdział 12
Narzędzia do konfigurowania i analizowania zabezpieczeń Tworzenie i analizowanie konfiguracji zabezpieczeń Edytowanie konfiguracji zabezpieczeń Eksportowanie konfiguracji zabezpieczeń Edytowanie szablonów zabezpieczeń Zastosowanie polecenia secedit
W skrócie Narzędzia do konfigurowania Zabezpieczenia można skonfigurować, edytując Listę Kontroli Dostępu (Access Control List — ACL) i korzystając z przystawki (snap-in) konsoli MMC Zasady Grupowe (Group Policy) do edytowania obiektów zasad grupowych (GPOs) w Active Directory. Obydwa sposoby zostały omówione w rozdziałach 2. i 3. W systemie Windows 2000 znajdują się dodatkowe przystawki konsoli MMC oraz polecenia, służące do konfigurowania i analizowania ustawień zabezpieczeń na podstawie szablonów standardowych, które można załadować, łączyć i edytować w celu skonfigurowania zabezpieczeń lokalnych. Narzędzia pozwalają na analizowanie ustawień zabezpieczeń poprzez porównywanie ich z ustawieniami domyślnymi oraz eksportowanie niestandardowych szablonów zabezpieczeń, aby mogły być stosowane dla innych komputerów w danej sieci. Umożliwiają skonfigurowanie zabezpieczeń dla komputera lokalnego lub wnoszenie poprawek do szablonów dla konkretnego rodzaju komputera tak, aby mogły być zastosowane dla dowolnego rodzaju komputera podłączonego do danej sieci (stacja robocza, serwer członkowski, itp.) Poniżej zamieszczono listę takich narzędzi: •
przystawka (snap-in) Szablon Zabezpieczeń (Security Template) — jest to główne narzędzie, za pomocą którego pełny zakres zabezpieczeń można oglądać, przystosowywać do własnych potrzeb i stosować do komputera lokalnego lub importować do obiektu zasad grupowych (GPO). Narzędzie to nie wprowadza nowych parametrów zabezpieczających, ale skupia wszystkie atrybuty zabezpieczające w jednym miejscu, ułatwiając w ten sposób administrowanie zabezpieczeniami. Szablony Zabezpieczeń w połączeniu z przystawką Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis) mogą służyć również jako podstawowa konfiguracja przy analizowaniu zabezpieczeń,
•
przystawka (snap-in) Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis) — służy do analizowania i konfigurowania zabezpieczeń systemu lokalnego. Umożliwia szybkie przeglądanie wyników analizy zabezpieczeń i podaje przy aktualnych ustawieniach systemowych ustawienia zalecane. Narzędzie to jest także używane do usuwania wszelkich niezgodności znalezionych podczas analizowania zabezpieczeń i do bezpośredniego konfigurowania zabezpieczeń systemu lokalnego. Stosowana jest również do importowania szablonów zabezpieczeń utworzonych za pomocą przystawki Szablony Zabezpieczeń oraz stosowania ich do obiektu zasad grupowych (GPO) dla komputera lokalnego i skonfigurowania w ten sposób zabezpieczeń systemu lokalnego na poziomie określonym w szablonie (template),
•
Zabezpieczenia Instalatora (Setup Security) — służy do nadzorowania początkowej konfiguracji zabezpieczeń wykonywanej w trakcie instalowania za pomocą konfiguracji wstępnych (predefined configurations) dostarczanych razem z systemem. Na każdym komputerze z nową instalacją systemu Windows 2000 utworzona zostaje początkowa baza danych zabezpieczeń pod nazwą: Baza Danych Zasad Komputera Lokalnego (Local Computer Policy Database). Zabezpieczenia Instalatora nie jest przystawką (snap-in) konsoli MMC, właściwie jest jednym z szablonów dostępnych za pomocą przystawki Szablon Zabezpieczeń, ale z powodu znaczenia, jakie ma podczas pierwszego instalowania systemu, została umieszczona jako osobna pozycja na niniejszej liście,
Wskazówka: Jeśli dokonywana jest aktualizacja systemu Windows w wersji NT 4 lub wcześniejszej, to wtedy baza danych Zasady Komputera Lokalnego (Local Computer Policy) nie jest tworzona, ponieważ konfiguracja zabezpieczeń mogła zostać odpowiednio zmodyfikowana przez użytkownika i nie wolno jej zastępować inną. W takim przypadku można zmienić konfigurację za pomocą funkcji Konfiguruj Komputer Teraz (Configure Computer Now) przystawki Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis).
•
Secedit.exe — Program narzędziowy uruchamiany z wiersza poleceń, który służy do przeprowadzenia analizy zabezpieczeń w sposób wsadowy (batch analysis). Można z niego korzystać, jeśli konieczne jest częste analizowanie zabezpieczeń dużej liczby komputerów, np. w strukturach opartych na domenach. Po zakończeniu działania tego programu należy przejrzeć wyniki analizy za pomocą przystawki (snap-in) Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis) lub edytora tekstów, np. Notatnika (Notepad).
Ustawienia szablonów zabezpieczeń Szablony umożliwiają zmianę ustawień zabezpieczeń w zakresie: •
zasady kont (account policies),
•
zasady lokalne (local policies),
•
dziennik zdarzeń (event log),
•
grupy z ograniczeniami (restricted groups),
•
usługi systemowe (system services),
•
rejestr systemowy (registry),
•
system plików (file system).
Do skonfigurowania różnych aspektów zabezpieczeń systemu Windows 2000 można użyć i zaadaptować jeden lub kilka Szablonów Zabezpieczeń (Security Templates).
Zasady kont (Account policies) Zasady kont (account policies) dla kont domeny są konfigurowane w domenie, a zasady kont dla kont lokalnych są konfigurowane lokalnie na danym komputerze. Zasady konta w domenie określają ustawienia dotyczące hasła, ustawienia blokowania konta oraz ustawienia protokołu Kerberos.
Zasady lokalne (Local policies) W systemie Windows 2000 zasady lokalne (local policies) są lokalne dla danego komputera bez rozróżniania pomiędzy rodzajami komputerów w sieci (kontroler domeny, serwer lub stacja robocza). W skład zasad lokalnych wchodzą zasady inspekcji (auditing policy), prawa i uprawnienia użytkownika oraz inne opcje zabezpieczeń, które można skonfigurować lokalnie. Zasady inspekcji określają, które ze zdarzeń związanych z zabezpieczeniami systemu są zapisywane w dzienniku zabezpieczeń (security log) komputera. Ustawienia praw i uprawnień (privileges) użytkownika dotyczą uprawnień w danym systemie. Opcje zabezpieczeń dotyczą szerokiego zakresu ustawień, np. praw dostępu do zasobów, takich jak napęd dyskietek czy CDROM.
Dziennik zdarzeń (Event log) Ustawienia dziennika zdarzeń umożliwiają konfigurowanie dzienników aplikacji, zabezpieczeń i systemowych. Można ustawić parametry, takie jak maksymalny rozmiar pliku dziennika, ograniczenia dostępu dla gości (guest access) oraz metody przechowywania (retention methods).
Grupy z ograniczeniami (Restricted groups)
Lista grupy z ograniczeniami (restricted group) umożliwia zarządzanie grupami wbudowanymi, które mają uprzednio zdefiniowane możliwości. Są to między innymi grupy lokalne, takie jak Administratorzy (Administrators), Użytkownicy Zaawansowani (Power Users), Operatorzy Wydruku (Print Operators), Operatorzy Serwera (Server Operators), itd. Do tej listy można dodać grupy uznane za szczególnie ważne lub uprzywilejowane wraz z informacjami dotyczącymi członkostwa w tych grupach. Umożliwia to śledzenie i zarządzanie tymi grupami, co jest częścią konfigurowania systemu lub zasad (policies) systemowych. Oprócz tego można również śledzić przynależność każdej grupy z ograniczeniami (restricted group) w innych grupach, co zapisane jest w kolumnie Członek Grupy (Members Of ). Można wykorzystać odpowiednią funkcję przystawki (snap-in) Konfigurowanie i Analizowanie Aabezpieczeń (Security Configuration and Analysis), aby kontrolować, do których grup mogą należeć członkowie grupy z ograniczeniami (restricted group) lub umieszczać użytkowników w jednej grupie, uniemożliwiając im w ten sposób przynależność do innej.
Usługi systemowe Lista usług systemowych zawiera szeroki zakres usług, takich jak usługi sieciowe, plikowe, drukowania, telefoniczne i faksowe (telephony and fax services) oraz usługi internetowe i intranetowe. Szablony obsługują bezpośrednio ustawienia ogólne każdej usługi systemowej. Ustawienia ogólne obejmują tryb uruchamiania (startup mode) danej usługi (automatycznie, ręcznie i wyłączona) oraz jej zabezpieczenia.
Rejestr systemowy (Registry) Szablony umożliwiają zarządzanie rejestrem systemowym (registry) przez umieszczenie deskryptora zabezpieczeń (security descriptor) w kluczach rejestru. Lista rejestru systemowego (registry) zawiera pełną ścieżkę dostępu do rejestru systemowego (registry) oraz deskryptor zabezpieczeń (security descriptor). Ustawieniami rejestru systemowego dotyczącymi zabezpieczeń można zarządzać za pomocą przystawki (snap-in) Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis), klikając w załadowanym szablonie prawym przyciskiem myszki dowolny klucz rejestru systemowego.
System plików
Lista szablonu (template list) traktuje wszystkie woluminy w systemie jako część jednego drzewa, w którym gałęzie pierwszego poziomu (first-level nodes) są katalogami głównymi (root directory) każdego z woluminów. Jeśli szablon jest załadowany do przystawki (snap-in) Konfigurowanie i Analizowanie Zabezpieczeń, to wtedy można przeglądać katalog lokalny i określić ustawienia zabezpieczeń dla dowolnego pliku lub foldera.
Skonfigurowane wstępnie Szablony Zabezpieczeń (Security Templates) Dla najczęściej spotykanych sposobów zabezpieczeń dostarczono zestaw szablonów zabezpieczeń, które opisano w rozdziale 2. W niniejszym rozdziale zostaną one zastosowane do tworzenia zasad zabezpieczeń (security policy), stosowanych dla komputera lokalnego, które mogą być przeanalizowane i wyeksportowane do podobnych komputerów znajdujących się w danej sieci. Szablony te mogą być przypisywane do komputera bezpośrednio w postaci, w jakiej je dostarczono lub też zmodyfikowane za pomocą przystawki (snap-in) konsoli MMC Szablony Zabezpieczeń (Security Templates).
OSTRZEŻENIE! Przed zastosowaniem zdefiniowanych wstępnie Szablonów Zabezpieczeń (Security Templates) do działającego systemu, konieczne jest ich sprawdzenie, aby upewnić się, czy zachowany zostanie odpowiedni poziom zabezpieczeń.
Poniżej zamieszczono listę wstępnie zdefiniowanych Szablonów Zabezpieczeń (Security Templates): •
domyślny stacja robocza (basicwk.inf),
•
domyślny serwer (basicsv.inf),
•
domyślny kontroler domeny (basicdc.inf),
•
zgodny stacja robocza lub serwer (compatws.inf),
•
bezpieczny stacja robocza lub serwer (securews.inf),
•
ściśle zabezpieczony (highly secure) stacja robocza lub serwer (hisecws.inf),
•
specjalizowany kontroler domeny (dedicadc.inf),
•
bezpieczny kontroler domeny (securedc.inf),
•
ściśle zabezpieczony kontroler domeny (hisecdc.inf).
Domyślnie szablony te są zapisane w folderze \%systemroot%\security\templates. Szablon Zabezpieczenia Instalatora (Setup Security), opisany powyżej w podrozdziale „Zestaw narzędzi konfiguracyjnych”, również zapisany jest w tym folderze. Szablony podzielone są na pięć kategorii, zgodnych z wymaganiami dotyczącymi zabezpieczeń: podstawowy, zgodny, bezpieczny, ściśle zabezpieczony (highly secure) i specjalizowany kontroler domeny.
Szablony podstawowe (Basic) Szablony Konfiguracyjne (Security Templates) podstawowe (inaczej domyślne) służą do zastępowania innych konfiguracji zabezpieczeń. Konfiguracje podstawowe stosują domyślne ustawienia zabezpieczeń systemu Windows 2000 do wszystkich zabezpieczanych obszarów za wyjątkiem tych, które dotyczą praw użytkownika. Nie są one modyfikowane w szablonach podstawowych (basic templates), ponieważ zazwyczaj programy instalacyjne aplikacji modyfikują prawa użytkownika, umożliwiając w ten sposób prawidłowe korzystanie z danej aplikacji. Konfiguracja podstawowa nie unieważnia tych zmian.
Szablony zgodne (Compatible) Domyślnie zabezpieczenia systemu Windows 2000 są skonfigurowane w ten sposób, aby członkowie grupy lokalnej Użytkownicy (Users) mieli najlepsze ustawienia zabezpieczeń, a członkowie grupy lokalnej Użytkownicy zaawansowani (Power Users) mieli ustawienia zabezpieczeń zgodne z zabezpieczeniami dla użytkowników systemu Windows NT 4. Taka domyślna konfiguracja pozwala na tworzenie aplikacji zgodnych ze standardową definicją zabezpieczeń systemu Windows, umożliwiając jednocześnie poprawne działanie aplikacji już istniejących. Domyślnie wszyscy użytkownicy uwierzytelnieni przez system Windows 2000 są członkami grupy power users. Zabezpieczenie to może być niedostateczne w takich systemach, w których bardziej odpowiednie jest, aby domyślnie wszyscy użytkownicy byli członkami grupy users. W takich sytuacjach korzysta się z szablonów zgodnych (compatible templates). Obniżając poziom zabezpieczeń dla poszczególnych plików, folderów i kluczy rejestru najczęściej używanych przez aplikacje, szablony zgodne umożliwiają prawidłowe działanie większości aplikacji. Oprócz tego wszyscy zaawansowani użytkownicy zostają usunięci.
Szablony bezpieczne (Secure) Szablony Bezpieczne (Secure Templates) wprowadzają zalecane ustawienia zabezpieczeń dla wszystkich zabezpieczanych obszarów, oprócz plików, folderów i kluczy rejestru (registry), które nie są modyfikowane, ponieważ uprawnienia dotyczące systemu plików i rejestru są konfigurowane domyślnie jako bezpieczne.
Szablony ściśle zabezpieczone (Highly secure) Szablony Ściśle Zabezpieczone (Highly Secure Templates) określają ustawienia zabezpieczeń dla komunikacji przez sieć w systemie Windows 2000. Obszary zabezpieczane są konfigurowane w ten sposób, aby maksymalnie chronić wymianę danych poprzez sieć pomiędzy komputerami pracującymi pod kontrolą systemu Windows 2000. Komputer, dla którego zastosowano szablony ściśle zabezpieczeń może komunikować się wyłącznie z komputerami pracującymi pod kontrolą systemu Windows 2000.
Specjalizowany Kontroler Domeny (Dedicated Domain Controller) Domyślne zabezpieczenia kontrolerów domen (DCs) pracujących pod kontrolą systemu Windows 2000 nie są idealne. Umożliwia to administratorom uruchamianie na kontrolerach domen starszych wersji aplikacji korzystających z serwera (server-based applications). Jeśli takie aplikacje nie będą uruchamiane, wówczas można określić domyślne uprawnienia dotyczące systemu plików i rejestru (registry) w takim sam sposób, jak dla stacji roboczych i serwerów autonomicznych (standalone servers). Do tego służą specjalizowane szablony zabezpieczeń (dedicated security templates).
Wskazówka: Nie zaleca się uruchamiania starszych wersji aplikacji oraz aplikacji innych niż narzędzia do administrowania na kontrolerach domen (DCs).
Rozwiązania natychmiastowe Tworzenie i analizowanie konfiguracji zabezpieczeń Poniżej podany zostanie przykład zastosowania podstawowego lub domyślnego szablonu zabezpieczeń serwera dla serwera członkowskiego i analiza uzyskanej w ten sposób konfiguracji zabezpieczeń. Procedurę taką przeprowadza się, jeśli zachodzi potrzeba odtworzenia domyślnych ustawień zabezpieczeń. Podobne procedury postępowania obowiązują w przypadku stosowania któregokolwiek ze wstępnie zdefiniowanych szablonów zabezpieczeń (predefined security templates) do odpowiadającego mu rodzaju komputera, opisanych w części niniejszego rozdziału „W skrócie”. W niniejszym podrozdziale również zostanie utworzona przystawka (snap-in) konsoli MMC pod nazwą Narzędzie Do Konfigurowania (Configuration Tool), która będzie używana w kolejnych podrozdziałach. 1.
Zaloguj się do serwera członkowskiego jako administrator.
2.
Wybierz z menu Start pozycję Uruchom (Run) i wpisz polecenie mmc.
3.
Z menu Konsola (console) wybierz Dodaj/Usuń przystawki (Add/Remove snap-ins).
4.
Kliknij pozycję Dodaj (Add).
5.
Wybierz opcję Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis). Kliknij Dodaj.
6.
Zaznacz pozycję Szablony Zabezpieczeń (Security Templates) i kliknij Dodaj.
7.
Naciśnij przycisk Zamknij (Close). Aby powrócić do przystawki konsoli MMC, naciśnij OK.
8.
Prawym przyciskiem myszki wybierz pozycję Konfigurowanie i Analizowanie Zabezpieczeń i z menu polecenie Otwórz Bazę Danych (Open Database).
9.
W polu Nazwa Pliku (File Name) wpisz nazwę bazy danych konfiguracji, np. member server. Naciśnij przycisk Otwórz (Open).
10. Zaznacz szablon basicsv.inf i wybierz Otwórz (Open). 11. Prawym przyciskiem myszki kliknij pozycję Konfigurowanie i Analizowanie Zabezpieczeń i z menu wybierz polecenie Konfiguruj Komputer Teraz (Configure Computer Now). 12. Podaj ścieżkę pliku dziennika błędów lub zaakceptuj domyślną. Zanotuj tę ścieżkę i potwierdź OK. 13. Zabezpieczenia komputera są skonfigurowane. Może to chwilę potrwać.
14. Aby zobaczyć daną konfigurację zabezpieczeń, musisz najpierw uruchomić analizę. Prawym przyciskiem myszki zaznacz pozycję Konfigurowanie i Analizowanie Zabezpieczeń i z menu wybierz polecenie Analizuj Komputer Teraz (Analyze Computer Now). 15. Podaj tę samą ścieżkę do pliku dziennika błędów jak poprzednio. Naciśnij przycisk OK. 16. Zabezpieczenia komputera są analizowane. Może to chwilę potrwać. 17. Pojawi się konsola MMC, która w lewej części okna zawiera kontener Konfigurowanie i Analizowanie Zabezpieczeń z nową konfiguracją zabezpieczeń. 18. Prawym przyciskiem myszki kliknij pozycję Konfigurowanie i Analizowanie Zabezpieczeń i zaznacz polecenie Wyświetl Plik Dziennika (View Log File); jeśli było wybrane, usuń zaznaczenie i ustaw jeszcze raz. Powinno pojawić się okno podobne do przedstawionego na rysunku 12.1. Zwróć uwagę, że podstawowy szablon zabezpieczeń (basic security template) nie dotyczy praw użytkowników i mogą pojawić się w dzienniku ostrzeżenia i zapisy informujące o błędach, dotyczące zabezpieczeń plików. 19. Zapisz konsolę MMC jako Narzędzie Do Konfigurowania (Configuration Tool). Pozostaw ścieżkę domyślną, aby mieć dostęp do danej przystawki (snap-in) z menu Narzędzia administracyjne (Administrative tools). 20. Zamknij konsolę MMC.
Rysunek 12.1. Skonfigurowane i zanalizowanie podstawowych zabezpieczeń serwera
Edytowanie konfiguracji zabezpieczeń Poniżej przedstawiony zostanie sposób edytowania zabezpieczeń skonfigurowanych poprzednio dla serwera członkowskiego. Ta sama procedura może być wykorzystana do lokalnego edytowania dowolnej konfiguracji zabezpieczeń, na dowolnym komputerze w danej sieci. W przykładzie tym użyta zostanie przystawka konsoli MMC Narzędzie Do Konfigurowania (Configuration Tool) utworzona w poprzednim podrozdziale „Tworzenie i analizowanie konfiguracji zabezpieczeń”. 1.
Zaloguj się na serwerze członkowskim jako administrator.
2.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Narzędzie Do Konfigurowania (Configuration Tool).
3.
Rozwiń gałąź Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis).
4.
Rozwiń gałąź Zasady Lokalne (Local Policies) i zaznacz pozycję Opcje Zabezpieczeń (Security Options).
5.
W prawej części okna kliknij dwukrotnie pozycję Nie wyświetlaj nazwy ostatnio zalogowanego użytkownika (Do not display last logged on user name).
6.
Wybierz opcję Włączone (Enabled). Jeśli opcja ta jest wyświetlona na szaro, zaznacz Definiuj w bazie danych następujące zasady (Define this policy in the database).
7.
Zwróć uwagę, że to ustawienie nie ma wpływu na aktualne ustawienia komputera, dopóki ta konfiguracja nie będzie zastosowana i zanalizowana. Naciśnij przycisk OK.
8.
W ten sam sposób dodaj nagłówek i treść komunikatu dla użytkowników, którzy podejmują próby zalogowania się.
9.
Ogranicz dostęp do napędu dyskietek i CD-ROM-u tylko do użytkowników zalogowanych lokalnie.
10. Zmień nazwę konta administratora. 11. Skonfiguruj pozostałe opcje, które chcesz umieścić w zasadach serwera członkowskiego (member server policy). Pamiętaj, że niektóre z tych ustawień (szczególnie w kontenerze Przypisywanie Praw Użytkownika (User Rights Assignment) mogą być zastąpione przez zasady domeny (domain policies). 12. W lewej części okna prawym przyciskiem myszki wybierz pozycję Konfigurowanie i Analizowanie Zabezpieczeń i z menu wybierz polecenie Konfiguruj Komputer Teraz (Configure Computer Cow). 13. Naciśnij przycisk OK, aby zaakceptować ścieżkę do pliku dziennika błędów. 14. Kiedy zabezpieczenia komputera zostaną skonfigurowane, prawym przyciskiem myszki włącz pozycję Konfigurowanie i Analizowanie Zabezpieczeń i z menu wybierz polecenie Analizuj Komputer Teraz (Analyze Computer Now). 15. Naciśnij przycisk OK, aby zaakceptować ścieżkę dostępu do pliku dziennika błędów.
16. Po zakończeniu analizowania, prawym przyciskiem myszki kliknij pozycję Konfigurowanie i Analizowanie Zabezpieczeń i zaznacz polecenie Wyświetl Plik Dziennika (View Log File); jeśli było wybrane, usuń zaznaczenie i zaznacz jeszcze raz. Przewiń plik dziennika i sprawdź, czy nie ma wpisów o błędach lub ostrzeżeń dotyczących wprowadzonych zmian. Typowe okno dialogowe zostało przedstawione na rysunku 12.2.
Rysunek 12.2. Sprawdzanie dziennika błędów
Wskazówka: Dziennik błędów jest plikiem tekstowym. Może być odczytany za pomocą programów Notatnik (Notepad), Wordpad lub Word. Można wyszukać w nim odpowiedni ciąg znaków, można go również wydrukować.
Eksportowanie konfiguracji zabezpieczeń
W poprzednim podrozdziale opisano przykład użycia narzędzia pod nazwą Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis) do skonfigurowania zasad lokalnych (local policy) dla serwera członkowskiego. Po skonfigurowaniu, zanalizowaniu i sprawdzeniu zasad na jednym komputerze, można je eksportować w postaci pliku zasad (policy file) i zastosować na podobnych komputerach w sieci. Pozwala to na znaczne skrócenie czasu i ograniczenie błędów instalowania. Poniżej zamieszczono procedurę eksportowania zasad: 1.
Zaloguj się na serwerze członkowskim jako administrator.
2.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Narzędzie Do Konfigurowania (Configuration Tool).
3.
Prawym przyciskiem myszki zaznacz pozycję Konfiguracja i Analizowanie (Configuration and Analysis) i z menu wybierz polecenie Eksportuj Szablon (Export Template).
4.
W polu Nazwa Pliku (File Name) wpisz: serwer członkowski (member server). Naciśnij przycisk Zapisz (Save).
5.
Zamknij przystawkę (snap-in) konsoli MMC. Jeśli pojawi się okno dialogowe Wybierz Do Zapisania (Choose To Save) upewnij się, czy zaznaczone są wszystkie pliki, a następnie naciśnij przycisk OK.
6.
Otwórz ponownie przystawkę Narzędzie Do Donfigurowania.
7.
Rozwiń gałąź Szablony Zabezpieczeń (Security Templates), jak przedstawiono to na rysunku 12.3. Nowy szablon zabezpieczeń pojawi się w danym drzewie.
Rysunek 12.3. Szablon Serwer członkowski zapisany w magazynie Szablony Zabezpieczeń (Security Templates) 8.
Za pomocą Eksploratora Windows (Windows Explorer) udostępnij folder \%systemroot%\security\templates i grupie Domain Admins nadaj uprawnienia Pełna Kontrola (Full Control). Teraz plik może być pobierany i stosowany do dowolnego komputera w danej sieci.
OSTRZEŻENIE! Pamiętaj o usunięciu grupy Everyone.
Edytowanie Szablonów Zabezpieczeń Powyższe podrozdziały przedstawiały procedury importowania szablonów zabezpieczeń i stosowania ich do konfigurowania i edytowania zasad zabezpieczeń (security policies). Zasady zabezpieczeń po edycji i sprawdzeniu mogą być eksportowane do kontenera Szablony Zabezpieczeń (Security Templates), aby można było z nich korzystać na innych komputerach. Można zmienić wstępnie zdefiniowany szablon i zastosować go do odpowiednich komputerów w danej sieci, zmieniając w ten sposób ich ustawienia domyślne. Oprócz tego można stosować funkcje edycji kopiuj i wklej (copy-and-paste) przystawki (snap-in) konsoli MMC Szablony Zabezpieczeń (Security Templates) do jednoczesnego wnoszenia poprawek do wszystkich zasad (policies) w jednym kontenerze szablonów. Należy pamiętać o tym, że poprawki wprowadzone w szablonach do konfiguracji zabezpieczeń wstępnych lub utworzonych przez użytkownika, nie zmieniają żadnych zasad na komputerach dopóki nowy szablon zasad nie zostanie zastosowany.
Edytowanie szablonu wstępnie zdefiniowanego (predefined template) Poniżej zamieszczono przykład edytowania szablonu wstępnie zdefiniowanego (predefined template). Należy zwrócić uwagę, że szablon nie jest edytowany bezpośrednio — zapisywany jest pod inną nazwą i dopiero ten plik jest edytowany. Edytowanie szablonu wstępnie zdefiniowanego jest złym rozwiązaniem. Nowemu plikowi można zmienić nazwę na nazwę szablonu domyślnego tylko po dokładnym sprawdzeniu nowych ustawień, ale nawet wtedy należy na wszelki wypadek zrobić kopię zapasową poprzedniej wersji szablonu, najlepiej na przechowywanej bezpiecznie dyskietce. Poniższa procedura przedstawia sposób edytowania podstawowego szablonu stacji roboczej (basic workstation template). W takim przypadku należy edycję przeprowadzić na serwerze. Konieczne będzie pobranie (download) danego pliku do innych komputerów, najpierw do jednej ze stacji roboczej w celu sprawdzenia, a potem do pozostałych stacji roboczych w sieci. Jest zadanie do wykonania na serwerze. Na większości stacji roboczych nie jest i nie powinna być uruchomiona usługa Serwer. 1.
Zaloguj się na serwerze członkowskim jako administrator.
2.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Narzędzie Do Konfigurowania (Configuration Tool).
3.
Rozwiń drzewo Szablony Zabezpieczeń (Security Templates) i prawym przyciskiem myszki kliknij kontener basicwk.
4.
Wybierz polecenie Zapisz jako (Save as). W polu Nazwa Pliku (File Name) wpisz newbasicwk. Naciśnij Zapisz.
5.
Rozwiń kontener newbasicwk i zmień zasady haseł (password policies), co przedstawiono na rysunku 12.4. lub zmodyfikuj inne zasady, które uznasz za stosowne.
Rysunek 12.4. Zmiana Zasad Haseł (Password Policies) 6.
Prawym przyciskiem myszki zaznacz kontener newbasicwk i z menu wybierz polecenie Zapisz.
7.
Pobierz szablon zasad (policy template) do stacji roboczej pracującej pod kontrolą systemu Windows 2000 Professional. Skonfiguruj stację roboczą za pomocą szablonu zasad zgodnie z procedurą opisaną powyżej, w podrozdziale „Tworzenie i analizowanie konfiguracji zabezpieczeń”. Dokładnie sprawdź konfigurację.
Edytowanie szablonu utworzonego przez użytkownika za pomocą funkcji kopiowania i wklejania W zamieszczonym poniżej przykładzie użyto szablonu zabezpieczeń serwera członkowskiego, który został utworzony, edytowany i wyeksportowany zgodnie z procedurami opisanymi we wcześniejszych podrozdziałach. Procedura ta może być stosowana do dowolnego szablonu zasad. Poniżej opisano sposób zastosowania wszystkich zasad lokalnych z szablonu zasad securedc do szablonu serwera członkowskiego. 1.
Zaloguj się jako administrator do serwera członkowskiego, na którym utworzono szablon zabezpieczeń serwera członkowskiego.
2.
Z menu Narzędzia administracyjne (Administrative tools) wybierz pozycję Narzędzie Do Konfigurowania (Configuration Tool).
3.
Rozwiń gałąź Szablony Zabezpieczeń (Security Templates) i prawym przyciskiem myszki kliknij pozycję Zasady Lokalne (Local Policies) w kontenerze securedc. i wybierz Kopiuj.
4.
Prawym przyciskiem myszki kliknij pozycję Zasady Lokalne w kontenerze serwer członkowski (member server). Wybierz polecenie Wklej (Paste).
5.
Prawym przyciskiem myszki kliknij kontener Serwer Członkowski (Member Server). Wybierz polecenie Zapisz (Save).
6.
Stosując procedurę opisaną we wcześniejszym podrozdziale „Tworzenie i analizowanie konfiguracji zabezpieczeń”, zaimportuj do przystawki (snap-in) Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis) poprawiony szablon zabezpieczeń serwera członkowskiego i zastosuj nowe ustawienia do danego serwera członkowskiego.
7.
Sprawdź ustawienia.
Zastosowanie polecenia Secedit Program narzędziowy Secedit uruchamiany z wiersza poleceń używany jest do konfigurowania i analizowania zabezpieczeń, szczególnie gdy konieczne jest częste przeprowadzanie analiz dużej liczby komputerów. Wyniki uzyskane za pomocą polecenia secedit można obejrzeć za pomocą narzędzia Konfigurowanie i Analizowanie Zabezpieczeń.
Analizowanie zabezpieczeń systemu Składnia polecenia secedit w przypadku analizowania zabezpieczeń systemu jest następująca: secedit /analyze [/DB nazwa pliku] [/CFG nazwa pliku] [/log ścieżka dostępu do dziennika] [/verbose] [/quiet]
Parametry polecenia zdefiniowane są w następujący sposób: •
DB nazwa pliku — podaje ścieżkę dostępu do bazy danych zawierającej analizowaną konfigurację. Jeśli nazwa pliku określa nową bazę danych należy podać również parametr CFG nazwa pliku,
•
CFG nazwa pliku — podaje się tylko razem z parametrem DB. Określa ścieżkę dostępu do szablonu zabezpieczeń zaimportowanego do bazy danych w celu przeprowadzenia analizy. Jeśli parametr ten nie występuje, analiza jest wykonywana dla dowolnej konfiguracji zapisanej już w bazie danych,
•
log ścieżka dostępu do dziennika — ścieżka dostępu do pliku dziennika dla danego procesu. Jeśli nie jest podana, używa się domyślnego pliku dziennika,
•
verbose — podaje szczegółowe informacje podczas przeprowadzania analizy,
•
quiet — pomija wyświetlanie kolejnych ekranów i komunikatów. Wyniki analizy można wyświetlić za pomocą narzędzia Konfigurowania i Analizowanie Zabezpieczeń (Security Configuration and Analysis) lub za pomocą edytora tekstów, np. Notatnika (Notepad).
Przykład: ustawienia bazy danych serwera członkowskiego (member server database) są porównywane z ustawieniami domyślnymi: secedit /analyze /DB „member server.sdb” /CFG „setup security.inf” /log difference.log /verbose
Uwaga: Aby uzyskać zwięzłość i przejrzystość powyższych przykładów przyjęto, że polecenie secedit jest uruchamiane z katalogu %\systemroot%\security\templates. Potrzebne bazy danych konfiguracji skopiowano do tego katalogu i jest w nim także utworzony plik dziennika. W przypadku systemu rzeczywistego, w wierszu poleceń razem z poleceniem secedit należy podać wszystkie pełne ścieżki dostępu.
Otrzymany plik dziennika można wyświetlić za pomocą narzędzia Konfigurowanie i Analizowanie Zabezpieczeń lub za pomocą Notatnika (Notepad), co przedstawiono na rysunku 12.5.
Rysunek 12.5. Różnice pomiędzy ustawieniami aktualnymi a domyślnymi
Konfigurowanie zabezpieczeń systemu Składnia polecenia secedit w przypadku konfigurowania zabezpieczeń systemu poprzez zastosowanie zapisanego wcześniej szablonu jest następująca: secedit /configure [/DB nazwa pliku] [/CFG nazwa pliku] [/overwrite] [/areas obszar1 obszar2...] [/log ścieżka dostępu do dziennika] [/verbose] [/quiet]
Parametry polecenia zdefiniowane są w następujący sposób:
•
DB nazwa pliku — podaje ścieżkę dostępu do bazy danych zawierającej konfigurację, która ma zostać zastosowana. Parametr ten musi być podany,
•
CFG nazwa pliku — podaje się tylko razem z parametrem DB. Określa ścieżkę dostępu do szablonu zabezpieczeń zaimportowanego do bazy danych i zastosowanego do danego systemu. Jeśli parametr ten nie występuje, stosowany jest dowolny szablon, zapisany już w bazie danych,
•
overwrite — podaje się tylko łącznie z parametrem CFG. Określa, czy szablon zabezpieczeń podany jako argument CFG ma zastąpić szablony lub szablon złożony (composite template) zapisane już w bazie danych. Jeśli parametr ten zostanie pominięty, szablon podany jako argument CFG będzie dodany do zapisanego szablonu,
•
areas — określa obszary zabezpieczeń (security areas) — zob. tabela 12.1. — które mają być zastosowane w danym systemie. Domyślnie jest to „all areas”. Poszczególne obszary oddzielane są spacjami,
•
log ścieżka dostępu do dziennika — ścieżka dostępu do pliku dziennika dla danego procesu. Jeśli nie jest podana, używa się domyślnego pliku dziennika,
•
verbose — podaje szczegółowe informacje podczas przeprowadzania analizy,
•
quiet — pomija wyświetlanie kolejnych ekranów i komunikatów.
Tabela 12.1. Obszary zabezpieczeń określane przez parametr areas Nazwa obszaru
Opis
Securitypolicy
Zasady lokalne i zasady domeny systemu, łącznie z zasadami kont, zasadami inspekcji, itd.
Group_mgmt
Ustawienia grup z zabezpieczeniami (restricted group) dla każdej z grup określonej w szablonie zabezpieczeń
User_rights
Prawa i uprawnienia logowania użytkownika
Regkeys
Zabezpieczenia kluczy rejestru lokalnego
Filestore
Zabezpieczenia lokalnego magazynu plików (local file storage)
Services
Zabezpieczenia wszystkich zdefiniowanych usług
Przykład: obszar praw użytkownika bazy danych zasad zabezpieczeń serwera członkowskiego (member server security policy database) jest konfigurowany z ustawieniami praw użytkownika z szablonu securedb za pomocą polecenia w następującej postaci: secedit /analyze /DB „member server.sdb” /CFG „secure.inf” /overwrite /areas user_rights /log overwrite.log /verbose
Na rysunku 12.6 przedstawiono zapis w dzienniku dotyczący prawidłowego przebiegu konfigurowania
Rysunek 12.6. Zapis w dzienniku o prawidłowym przebiegu konfiguracji praw użytkownika
Sprawdzanie pliku konfiguracji zabezpieczeń Poniższa postać polecenia secedit służy do sprawdzania pliku konfiguracji zabezpieczeń: secedit /validate nazwa pliku
Odświeżanie ustawień zabezpieczeń Poniższa postać polecenia secedit służy do odświeżania zabezpieczeń systemu poprzez ponowne zastosowanie ustawień zabezpieczeń do obiektu zasad grupowych (GPO) Komputer Lokalny (Local Machine):
secedit /refreshpolicy {machine_policy | user_policy} [/enforce]
Parametry polecenia zdefiniowane są następująco: •
machine_policy — odświeża ustawienia zabezpieczeń dla komputera lokalnego,
•
user_policy — odświeża ustawienia zabezpieczeń konta użytkownika lokalnego aktualnie zalogowanego na danym komputerze,
•
enforce — odświeża ustawienia zabezpieczeń, nawet jeśli nie wprowadzono zmian w obiekcie zasad grupowych (GPO).
Eksportowanie ustawień zabezpieczeń Składnia polecenia secedit w przypadku eksportowania zapisanego wcześniej szablonu z bazy danych zabezpieczeń do pliku szablonu zabezpieczeń, aby mógł być zastosowany do innego komputera, jest następująca: secedit /export [/MergedPolicy] [/DB nazwa pliku] [/CFG nazwa pliku] [/areas obszar1 obszar2...] [/log ścieżka dostępu do dziennika] [/verbose] [/quiet]
Parametry polecenia zdefiniowane są w następujący sposób: •
MergedPolicy — scala i eksportuje ustawienia zabezpieczeń zasad domeny lub zasad lokalnych,
•
DB nazwa pliku — podaje ścieżkę dostępu do bazy danych zawierającej szablon, który ma być wyeksportowany. Jeśli parametr ten pominięto, stosowana jest baza danych zasad systemowych,
•
CFG nazwa pliku — określa ścieżkę dostępu i nazwę pliku, w którym zapisywany jest dany szablonu,
•
areas area1 area2 — określa obszary zabezpieczeń (security areas) — zob. tabela 12.1 — które mają być wyeksportowane. Domyślnie jest to „all areas”. Poszczególne obszary oddzielane są spacjami,
•
log ścieżka dostępu do dziennika — ścieżka dostępu do pliku dziennika dla danego procesu. Jeśli nie jest podana, używa się domyślnego pliku dziennika,
•
verbose — podaje szczegółowe informacje podczas przeprowadzania analizy,
•
quiet — pomija wyświetlanie plików i komunikatów.
Przykład: obszar usług (service area) bazy danych zasad zabezpieczeń serwera członkowskiego (member server security policy database) jest eksportowany do pliku szablonu usług za pomocą polecenia w następującej postaci: secedit /export /MergedPolicy /DB „member server.sdb” /CFG services.inf /areas services /log export.log /verbose
Wskazówka: Program narzędziowy Secedit, tak jak wszystkie programy korzystające z wiersza poleceń wygląda na pierwszy rzut oka na nieporęczny i trudny do użycia. Jego główną zaletą jest jednak to, że może być zastosowany w plikach wsadowych (batch files) w celu zautomatyzowania konfigurowania wielu komputerów. Jeśli występuje konieczność skonfigurowania wielu komputerów lub jeśli potrzebne jest częste konfigurowanie komputerów, dobrze jest poznać to narzędzie.
Polecenia uruchamiane za pomocą okna Uruchom (Run) Tabela 1. Zawiera polecenia uruchamiane za pomocą pozycji menu Start/Uruchom (Start/Run)
Dokumenty RFC (Request For Comment) Lista dokumentów RFC (Request For Comment) znajduje się pod adresem http://info.internet.isi.edu/innotes/rfc/files lub http://ercole.di.unito.it/CIE/RFC/rfc-ind.htm. Adres URL konkretnego dokumentu RFC to ftp://ftp.isi.edu/innotes/rfcxxxx.txt, gdzie xxxx jest numerem danego dokumentu RFC, np. adres URL dokumentu RFC2065 to ftp://ftp.isi.edu/innotes/rfc2065.txt. W tabeli 2. zamieszczono listę tematów i odpowiadających im dokumentów RFC.
Grupy i organizacje W tabeli 5. przedstawiono źródła informacji o grupach i organizacjach zajmujących się tworzeniem standardów związanych z bezpieczeństwem systemów komputerowych.
Źródła informacji W tabeli 6. zamieszczono spis źródeł informacji innych niż dokumenty RFC.
Strona Microsoft Certificate Services Welcome Aby uzyskać dostęp do strony powitalnej usług certyfikatów Microsoftu (Microsoft Certificate Services) i wysłać żądanie certyfikatu, należy za pomocą przeglądarki przejść na stronę http://Nazwa_serwera/CertSRV, gdzie Nazwa_serwera jest nazwą serwera, który jest jednostką certyfikującą firmy Microsoft (Microsoft Certificate Authority Server).
Magazyny certyfikatów CryptoAPI Magazyny certyfikatów (certificate stores) CryptoAPI są składnicami certyfikatów i związanych z nimi właściwości. Infrastruktura Klucza Publicznego Systemu Windows 2000 (Windows 2000 Public Key Infrastructure) definiuje pięć standardowych magazynów certyfikatów (certificate store): •
MY — zawiera certyfikaty użytkowników lub komputerów, dla których dostępny jest związany z nimi klucz prywatny (private key),
•
CA — zawiera certyfikaty jednostki certyfikującej wydającej (issuing CA) lub jednostki certyfikującej pośredniczącej (intermediate CA), z których korzysta się do tworzenia łańcucha weryfikacji certyfikatów,
•
TRUST — zawiera listy zaufań certyfikatów (Certificate Trust Lists — CTLs), które pozwalają administratorowi na podanie zbioru zaufanych jednostek certyfikujących (trusted
CA). Mogą być przesyłane przez łącza niezabezpieczone, ponieważ są opatrzone podpisem cyfrowym, •
ROOT — zawiera certyfikaty zaufanych, głównych jednostek certyfikujących (trusted root CAs), które zostały podpisane przez te jednostki (self-signed CA certificates),
•
UserDS — przedstawia strukturę logiczną (logical view) składnicy certyfikatów (certificate repository), zapisanej w Active Directory, np. jako właściwość user Certificate obiektu Użytkownik (User). Jego przeznaczeniem jest uproszczenie dostępu do składnic zewnętrznych (external repositories).
Zawartość biletu protokołu Kerberos (Kerberos ticket contents) Bilet protokołu Kerberos 5 zawiera pola danych, zapisanych w postaci tekstu jawnego (plaintext), które przedstawiono w tabeli 3., pola zaszyfrowane, zamieszczone w tabeli 4. oraz pole znacznika. Chociaż pole znacznika jest 32-bitowe, ważne są tylko niektóre pola. Zamieszczono je w tabeli 7.
Domyślne ustawienia zabezpieczeń Domyślne ustawienia zabezpieczeń w systemie Windows 2000 są zapisane w następujących folderach: Stacje robocze
%systemroot%\inf\defltwk.inf
Serwery członkowskie (member servers)
%systemroot%\inf\defltsv.inf
Kontrolery domeny
%systemroot%\inf\defltdc.inf
Zdefiniowane wstępnie szablony zabezpieczeń System Windows 2000 zawiera zestaw szablonów dla najczęściej spotykanych zadań zabezpieczeń. Są to: •
domyślna stacja robocza (default workstation) (basicwk.inf),
•
domyślny serwer (default server) (basicsv.inf),
•
domyślny kontroler domeny (default domain controller) (basicdc.inf),
•
zgodna stacja robocza lub serwer (compatible workstation or server) (compatws.inf),
•
zabezpieczona stacja robocza lub serwer (secure workstation or server) (securews.inf),
•
ściśle zabezpieczona stacja robocza lub serwer (highly secure workstation or server) (hisecws.inf),
•
specjalizowany kontroler domeny (dedicated domain controller) (dedicadc.inf),
•
zabezpieczony kontroler domeny (secure domain controller) (securedc.inf),
•
ściśle zabezpieczony kontroler domeny (highly secure domain controller) (hisecdc.inf).
Te domyślnie szablony zapisane są w katalogu \%systemroot%\security\templates.
Host skryptów Cscript Aby uruchomić hosta skryptów (scripting host) cscript.exe, należy w wierszu poleceń (command prompt) wpisać następujące polecenie: cscript [nazwa skryptu] [parametry hosta] [parametry skryptu],
gdzie nazwa skryptu jest to pełna ścieżka dostępu do pliku skryptu (z rozszerzeniem włącznie), parametry skryptu — to opcje hosta skryptów Windows Scripting Host (WSH), a parametry skryptu są to parametry przekazywane do danego skryptu. Parametry skryptu poprzedzone są pojedynczym ukośnikiem (znakiem /), a parametry hosta — podwójnym znakiem ukośnika (//). Oto lista parametrów hosta wykorzystywanych przez program cscript: •
//B — oznacza tryb wsadowy (batch mode), w którym nie są wyświetlane komunikaty o alarmach, błędach skryptów ani okna dialogowe,
•
//D — włącza aktywne usuwanie błędów (active debugging),
•
//E:engine — oznacza, że do wykonania skryptu użyty będzie aparat (engine),
•
//H:Cscript lub //H:Wscript — ustanawia domyślny program uruchamiający skrypty (cscript.exe lub wscript.exe). Jeśli nie zostanie wybrany żaden z programów, domyślnym programem uruchamiającym skryptem jest wscript.exe,
•
//I — oznacza wybór trybu interaktywnego. Wyświetlane są komunikaty o alarmach, błędach skryptów oraz monity (input prompts). Jest to tryb domyślny, przeciwny trybowi ustawianemu za pomocą parametru //B,
•
//Job:xxxx — powoduje wykonanie zadania Windows Scripting (WS job).
•
//Logo — oznacza, że podczas działania wyświetlany będzie banner. Jest to tryb domyślny, odwrotne znaczenie ma //Nologo,
•
//S — informuje, że bieżące parametry podane w wierszu poleceń zostaną zapisane dla aktualnego użytkownika,
•
//T:nn — podaje maksymalny czas pracy skryptu w sekundach. Górna granica to 32 767 sekund. Domyślnie nie ma ograniczenia czasu,
•
//X — powoduje wykonanie skryptu w trybie usuwania błędów,
•
//U — oznacza, że bezpośrednie operacje wejście-wyjście z konsoli będą stosować znaki w standardzie Unicode,
•
//? — powoduje wyświetlenie informacji, w jaki sposób korzystać z tego polecenia. To samo można uzyskać, wpisując polecenie cscript.exe bez żadnych parametrów.
Program narzędziowy Cipher Program Cipher umożliwia szyfrowanie i odszyfrowywanie plików za pomocą wiersza poleceń, np. aby zaszyfrować folder secure_docs bieżącego woluminu można wpisać: Cipher /e „secure_docs”
Do zaszyfrowania wszystkich plików w bieżącym folderze, które zawierają w swojej nazwie ciąg znaków „coriolis” można wpisać: Cipher /e /a *coriolis*
Polecenie cipher ma następujące parametry: CIPHER [/E | /D] [/S[:dir]] [/A] [/I] [/F] [/Q] [/H] [/K] [pathname ]]
Znaczenie tych parametrów jest następujące: •
/E — szyfruje określone pliki lub katalogi. Katalogi zostaną oznaczone, więc dodawane do nich pliki będą szyfrowane,
•
/D — odszyfrowuje określone pliki lub katalogi. Katalogi zostaną oznaczone, więc dodawane do nich pliki nie będą szyfrowane,
•
/S — wykonuje podaną operacje na danym folderze i wszystkich jego podfolderach. Domyślnie dir oznacza bieżący folder,
•
/A — wykonuje określone operacje na plikach, jak również na folderach. Należy zwrócić uwagę, że plik może zostać odszyfrowany w trakcie modyfikacji, a folder, w którym go zapisano, nie jest zaszyfrowany,
•
/I — kontynuuje wykonywanie określonej operacji nawet po pojawieniu się błędów. Domyślnie polecenie cipher kończy działanie, kiedy wystąpi błąd,
•
/F — wymusza operację szyfrowania wszystkich podanych plików, nawet tych, które są już zaszyfrowane. Domyślnie wszystkie pliki już zaszyfrowane są opuszczane. Funkcja ta gwarantuje, że pliki oznaczone jako zaszyfrowane są rzeczywiście zaszyfrowane. Jeśli wystąpi błąd sprzętowy w trakcie szyfrowania, plik może być oznaczony jako zaszyfrowany nawet, jeśli w rzeczywistości nie jest zaszyfrowany,
•
/Q — raportuje tylko najważniejsze informacje (quiet mode),
•
/H — podaje pliki z atrybutami ukryty (hidden) lub systemowy (system). Zwróćmy uwagę, że pliki systemowe nie powinny być szyfrowane, ponieważ, w następstwie takiej operacji, komputer mógłby się nie uruchomić,
•
/K — tworzy nowy klucz szyfrowania pliku (file encryption key) dla użytkownika, który uruchomił polecenie cipher. Jeśli ta opcja jest podana, to wtedy pozostałe opcje są ignorowane,
•
ścieżka (Pathname) — podaje wzór, folder lub plik.
Polecenie cipher bez parametrów wyświetli aktualny stan szyfrowania bieżącego foldera i plików, które zawiera. Można podawać wiele nazw plików (multiple file names) i stosować symbole wieloznaczne (wildcards). Pomiędzy parametrami wstawia się spacje.
Polecenie Secedit Program narzędziowy Secedit uruchamiany z wiersza poleceń używany jest do konfigurowania i analizowania zabezpieczeń, szczególnie gdy konieczne jest częste przeprowadzanie analiz dużej liczby komputerów. Składnia polecenia secedit w przypadku analizowania zabezpieczeń systemu jest następująca: secedit /analyze [/DB nazwa pliku] [/CFG nazwa pliku] [/log ścieżka dostępu do dziennika] [/verbose] [/quiet]
Składnia polecenia secedit w przypadku konfigurowania zabezpieczeń systemu poprzez zastosowanie zapisanego wcześniej szablonu jest następująca: secedit /configure [/DB nazwa pliku] [/CFG nazwa pliku] [/overwrite] [/areas obszar1 obszar2...] [/log ścieżka dostępu do dziennika] [/verbose] [/quiet]
Poniższa postać polecenia secedit służy do sprawdzania pliku konfiguracji zabezpieczeń: secedit /validate nazwa pliku
Poniższa postać polecenia secedit służy do odświeżania zabezpieczeń systemu poprzez ponowne zastosowanie ustawień zabezpieczeń do obiektu zasad grupowych (GPO) komputera lokalnego (local machine): secedit /refreshpolicy {machine_policy | user_policy} [/enforce]
Składnia polecenia secedit, w przypadku eksportowania zapisanego wcześniej szablonu z bazy danych zabezpieczeń do pliku szablonu zabezpieczeń, aby mógł być zastosowany do innego komputera, jest następująca: secedit /export [/MergedPolicy] [/DB nazwa pliku] [/CFG nazwa pliku] [/areas obszar1 obszar2...] [/log ścieżka dostępu do dziennika] [/verbose] [/quiet]
Parametry polecenia zdefiniowane są w następujący sposób: •
DB nazwa pliku — podaje ścieżkę dostępu do bazy danych zawierającej konfigurację, która ma zostać zastosowana,
•
CFG nazwa pliku — określa ścieżkę dostępu do szablonu zabezpieczeń zaimportowanego do bazy danych i zastosowanego do danego systemu,
•
log ścieżka dostępu do dziennika — ścieżka dostępu do pliku dziennika dla danego procesu,
•
verbose — podaje szczegółowe informacje podczas przeprowadzania analizy,
•
quiet — pomija wyświetlanie kolejnych ekranów i komunikatów,
•
overwrite — podaje się tylko łącznie z parametrem CFG. Określa, czy szablon zabezpieczeń, podany jako argument CFG, ma zastąpić szablon złożony lub szablony (composite template), zapisane już w bazie danych,
•
areas — określa obszary zabezpieczeń (security areas) — patrz tabela 8. — które mają być zastosowane w danym systemie. Domyślnie są to wszystkie obszary (all areas). Poszczególne obszary oddzielane są spacjami,
•
machine_policy — odświeża ustawienia zabezpieczeń dla komputera lokalnego,
•
user_policy — odświeża ustawienia zabezpieczeń konta użytkownika lokalnego aktualnie zalogowanego na danym komputerze,
•
enforce — odświeża ustawienia zabezpieczeń nawet, jeśli nie wprowadzono zmian w obiekcie zasad grupowych (GPO),
•
MergedPolicy — scala i eksportuje ustawienia zabezpieczeń zasad domeny lub zasad lokalnych.
Tabela 1. Polecenia uruchamiane za pomocą okna Uruchom (Run) Polecenie
Funkcja
dcpromo
Awansowanie serwera systemu Windows 2000 na kontroler domeny.
mmc
Uruchamianie konsoli zarządzania Microsoftu (Microsoft Management Console).
runas
Umożliwienie administratorowi zalogowania się jako użytkownik (członek
grupy Users) lub zaawansowany użytkownik (Power Users) i uruchamiania programów do administrowania w kontekście administracyjnym (administrative context), bez konieczności wylogowywania się i ponownego logowania. schupgr
Aktualizowanie schematu (schema).
Tabela 2. Lista dokumentów RFC Temat
RFC
Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
2712
C programming for LDAP applications
1823
Clarifications to the Domain Name Service (DNS) specification
2181
Data Encryption Standard-Cipher Block Chaining (DES-CBC)
2405
Data Encryption Standard-Cipher Block Chaining (DES-CBC) (2)
1829
Domain Name Systems Security Extensions
2535
Dynamic updates in the Domain Name Service
2136
Extensible Authentication Protocol (EAP)
2294
Generic Security Service Application Program Interface (GSS-API)
1508
Hash Message Authentication Code (HMAC)
2104
Internet X.509 Public Key Infrastructure (PKI) standard
2459
Kerberos Network Authentication Service (V5)
1510
Lightweight Directory Access Protocol (LDAP)
2133
Lightweight Directory Access Protocol (LDAP) (2)
1823
MD2 Message Digest Algorithm
1319
MD4 Message Digest Algorithm
1320
MD5 Message Digest Algorithm
1321
Security Association and Key Management Protocol (SAKMP)
2408
Transport Layer Security
2246
Tabela 3. Pola biletu w postaci tekstu jawnego (plaintext) Nazwa pola
Opis
Tkt-vno
Numer wersji formatu biletu. W przypadku protokołu Kerberos 5 w polu tym wpisane jest 5.
Obszar (Realm)
Nazwa obszaru (domeny), w którym wydano bilet. Centrum dystrybucji
kluczy (KDC) może wydawać bilety tylko dla serwerów w tej samej domenie, więc jest to również nazwa obszaru, w którym znajduje się serwer. Sname
Nazwa serwera
Tabela 4 Zaszyfrowane pola biletu Nazwa pola
Opis
Znaczniki (Flags)
Opcje biletu
Klucz (Key)
Klucz sesji
Crealm
Nazwa obszaru (realm), domeny klienta
Cname
Nazwa klienta
Transited
Lista obszarów protokołu Kerberos, biorących udział w uwierzytelnianiu klienta, któremu wydano dany bilet.
Authtime
Czas pierwszego uwierzytelniania przez klienta. Centrum dystrybucji kluczy (Key Distribution Center — KDC) umieszcza w tym znacznik czasu (timestamp), kiedy wyda bilet gwarantujący bilet (Ticket Granting Ticket — TGT). Kiedy centrum dystrybucji kluczy (KDC) wydaje bilety na podstawie biletu gwarantującego bilet (TGT), zapisuje kopię czasu pierwszego uwierzytelnienia biletu gwarantującego bilet (Ticket Granting Ticket — TGT) w polu Authtime w bilecie.
Starttime
Czas, po którym bilet jest ważny.
Endtime
Data ważności biletu.
Renew-till
Maksymalny okres ważności, który można ustawić w bilecie za pomocą znacznika RENEW-ABLE. (Opcja)
Caddr
Jeden lub kilka adresów, z których dany bilet może być wykorzystany. Jeśli pole jest wolne, bilet może być użyty z dowolnego adresu (Opcja)
Authorization Data
Atrybuty uprawnień dla klienta. Protokół Kerberos nie interpretuje zawartości tego pola. Interpretacja jest dokonywana przez usługę. (Opcja)
Tabela 5. Grupy i organizacje Nazwa
Adres URL
Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (PKIX)
www.ietf.org/html.charters/pkixcharter.html
Internet Engineering Task Force (IETF)
www.ietf.org/ids.by.wg/smime.html
International Standards Organization (ISO)
www.iso.ch/infoe/sitemap.htm
Witryna internetowa JavaWorld
www.javaworld.com
The National Institute of Standards and Technology (NIST)
www.nist.gov
The OpenCard Consortium
www.opencard.org
Pretty Good Privacy (PGP)
www.pgpi.org
RSA Security Laboratories
www.rsasecurity.com
Smart Card Developers Assocation
www.smartcard.org
Grupa robocza PC/SC (personal computer/smart card)
www.smartcardsys.com
VeriSign
www.verisign.com
Tabela 6 Źródła informacji ogólnych dostępne w Internecie Temat
Adres URL
Cryptographic Application Programming Interface (CryptoAPI)
www.microsoft.com/security/tech/cryptoapi/
Cryptographic Service Provider Development Kit (CSPDK)
www.microsoft.com/security/tech/cryptoapi/cspdkintrocontent.asp
Data Encryption Standard (DES)
www.cryptosoft.com/html/fips46-2.htm
Technika DiffieHellmana (DH)
ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc
Zalecenia Internet Engineering Task Force (IETF) Internet Protocol Security (IPSec)
www.ietf.org/html.charters/ipsed-charter.html
Java Card 2.1 Platform http://java.sun.com/products/javacard Specification (download) Java Card 2.1 Platform Specification (online)
http://java.sun.com/products/javacard/htmldoc/index.html
Lista określeń związanych z kartami elektronicznymi
www.gemplus.com/basics/terms.htm
Message Digest Algorithms
www.rsasecutiy.com/rsalabs/faq/3-6-6.html
Microsoft Software Developer’s Kit (SDK)
http://msdn.microsoft.com/developer/sdk/platform.asp
Prezentacja OpenCard Framework
www.opencard.org/index-downloads.shtml
Public Key Cryptography www.rsasecurity.com/rsalabs/pkcs/ Standards (PKCS) Szyfr z kluczem publicznym RivestShamir-Adleman (RSA)
www.rsasecurity.com/rsalabs/faq/2-1-4.htm
Szyfr z kluczem publicznym RivestShamir-Adleman (RSA) (2)
www.rsasecurity.com/rsalabs/faq/2-1-5.htmlProtokół
Protokół Secure Elektronic Transaction (SET) (opis ogólny)
www.mastercard.com/shoponline/set/
Protokół Secure Elektronic Transaction (SET) (szczegóły techniczne)
http://trienadecet.mkn.co.uk/help/system/set/info
Informacje i FAQ dotyczące kart elektronicznych (smart card)
www.microsoft.com/security/tech/smartcards/
Windows 2000 Application Catalog
www.microsoft.com/windows/compatible
Windows 2000 http://msdn.microsoft.com/winlogo/win2000.asp Application Specification Windows Hardware www.microsoft.com/hcl Compatibility List (HCL) Tabela 7. Znaczniki biletu Znacznik
Opis
FORWARDABLE
Informuje usługę wydawania biletów (Ticket Granting Service — TGS), że może wydać nowy bilet gwarantujący bilet (Ticket Granting Ticket — TGT) z innym adresem sieciowym na podstawie przedstawionego biletu gwarantującego bilet (TGT) (tylko w przypadku biletów gwarantujących bilet — TGT)
FORWARDED
Wskazuje, że bilet gwarantujący bilet (Ticket Granting Ticket — TGT) został przekazany dalej lub, że dany bilet został wydany z przekazanego dalej biletu gwarantującego bilet (TGT).
PROXIABLE
Informuje usługę wydawania biletów (Ticket Granting Service — TGS), że może wydawać bilety z innymi adresem sieciowym niż ten, który znajduje się w danym bilecie gwarantującym bilet (Ticket Granting Ticket — TGT) (tylko w przypadku biletów gwarantujących bilety — TGTs).
PROXY
Wskazuje, że adres sieciowy w bilecie jest inny niż adres w bilecie gwarantującym bilet (Ticket Granting Ticket — TGT), użytym do uzyskania danego biletu.
RENEWABLE
Używany w kombinacji z polami Endtime i Renew-till, aby bilety z długim okresem ważności były odświeżane okresowo w centrum dystrybucji kluczy (Key Distribution Center — KDC).
INITIAL
Wskazuje, że jest to bilet gwarantujący bilet (Ticket Granting Ticket — TGT) (tylko w przypadku biletów gwarantujących bilety — TGTs).
Tabela 8. Obszary zabezpieczeń określane przez parametr areas Nazwa obszaru
Opis
Securitypolicy
Zasady lokalne i zasady domeny systemu, łącznie z zasadami kont, zasadami inspekcji, itd.
Group_mgmt
Ustawienia grup z zabezpieczeniami (restricted group) dla każdej z grup określonej w szablonie zabezpieczeń
User_rights
Prawa i uprawnienia logowania użytkownika
Regkeys
Zabezpieczenia kluczy Rejestru lokalnego
Filestore
Zabezpieczenia lokalnego magazynu plików (local file storage)
Services
Zabezpieczenia wszystkich zdefiniowanych usług
Słownik Active Directory — katalog hierarchiczny w systemie Windows 2000. Serwer, przechowujący zasady zabezpieczeń domeny (domain security policy) i informacje o kontach. Agenty Odzyskiwania Danych Zaszyfrowanych (Encrypted Data Recovery Agents) — służą do konfigurowania kluczy publicznych, korzystając z systemu szyfrowania plików (Encrypting File System — EFS) systemu Windows 2000, by możliwe było odzyskiwanie plików. Za pomocą klucza odzyskiwania (recovery key) dostępny jest tylko wygenerowany losowo klucz szyfrowania pliku (encryption key), a nie klucz prywatny (private key) użytkownika. System Windows 2000 nie zezwala na szyfrowanie plików ani folderów, jeśli nie skonfigurowano przynajmniej jednego agenta odzyskiwania danych zaszyfrowanych. Algorytm SHA 1 (Secure Hash Algorithm 1) — funkcja skrótu (hash function), dająca w wyniku wartość 160-bitową. Algorytmy Message Digest (MD2, MD4 i MD5) — funkcje skrótu (hash functions) stosowane w aplikacjach tworzących podpis cyfrowy, w których duża wiadomość musi zostać w bezpieczny sposób skompresowana, zanim zostanie opatrzony podpisem za pomocą klucza prywatnego (private key). Aplikacja Opublikowana (Published Application) — aplikacja, którą można zainstalować za pomocą programu narzędziowego Dodaj/Usuń programy (Add/Remove programs). Aplikacja Przypisana (Assigned Application) — aplikacja, która jest anonsowana (advertised) na pulpicie użytkownika. Skrót do aplikacji (shortcut) pojawia się w menu Start, Rejestr (Registry). Jest aktualizowany poprzez wpisanie informacji dotyczących danej aplikacji. Aplikacja jest instalowana, kiedy użytkownik uruchomi ją po raz pierwszy.
Atak metodą powtórzenia (Replay attack) — próba podszywania się pod jedną ze stron współdzielących klucz tajny (secret key), podejmowana przez stronę, która ma wrogie zamiary, a polegająca na przejęciu i ponownym wysłaniu danych uwierzytelniających (authenticator). Autonomiczna Główna Jednostka Certyfikująca (Standalone Root Certificate Authority) — główna jednostka w hierarchii zaufanych jednostek certyfikujących (CA). Autonomiczna jednostka certyfikująca (standalone CA) może wydawać certyfikaty poza sieć przedsiębiorstwa. Autonomiczna Podporządkowana Jednostka Certyfikująca (Standalone Subordinate Certificate Authority) — działa jako pojedynczy serwer certyfikatów lub stanowi część hierarchii zaufania jednostek certyfikatów (CA trust hierarchy). Zwykle autonomiczna, główna jednostka certyfikująca (standalone root CA) wydaje certyfikaty tylko innym jednostkom certyfikującym (CAs), podczas gdy autonomiczna jednostka, podporządkowana jednostka certyfikująca, (standalone subordinate CA) wydaje certyfikaty użytkownikom. Authentication Service (AS) Exchange — podprotokół protokołu uwierzytelniania Kerberos używany, gdy Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) wydaje klientowi klucz sesji logowania (logon session key) oraz bilet gwarantujący bilet (Ticket Granting Ticket — TGT). Authenticode — standardowy sposób uwierzytelniania, korzystający z podpisu cyfrowego do weryfikowania integralności oprogramowania pobranego z Internetu i do zidentyfikowania publikującego oprogramowanie (software publisher). Bilet gwarantujący bilet (Ticket Granting Ticket — TGT) — specjalny rodzaj biletu sesji (session ticket), który Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) przydziela sobie i korzysta do komunikowania się z klientem. Bilet pośredniczący (Proxy ticket) — bilet, który umożliwia danej aplikacji personifikowanie (impersonate) innej, nawet w przypadku wywoływania trzeciej aplikacji. Zob. Uwierzytelnianie Delegowane (Delegated Authenication). Bilet protokołu Kerberos odnawialny (Renewable Kerberos ticket) — bilet protokołu Kerberos z ustawionym znacznikiem RENEWABLE. Umożliwia to okresowe odnawianie kluczy sesji (session keys), bez konieczności wydawani zupełnie nowego biletu. Bilet przekazywany (Forwarded ticket) — bilet gwarantujący bilet (Ticket Granting Ticket — TGT) protokołu Kerberos z ustawionym znacznikiem FORWARDABLE. Jeśli klient chce przekazać (delegate) zadanie uzyskiwania biletów (tickets) dla serwerów wewnętrznych (back-end servers) do serwera zewnętrznego (front-end server), to wtedy żąda od Centrum Dystrybucji
Kluczy (Key Distribution Center — KDC) przekazywanego biletu gwarantującego bilet (forward TGT). Bilet referencyjny (Referral ticket) — bilet gwarantujący bilet (Ticket Granting Ticket — TGT) zaszyfrowany za pomocą klucza międzydomenowego (interdomain key), który Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) jednej domeny współdzieli z Centrum Dystrybucji Kluczy (KDC) w innej domenie. Bilety referencyjne (referral tickets) stosowane są w przypadku uwierzytelnienia ponaddomenowego (cross-domain authentication). Bilet sesji (Session ticket) — struktura danych, w której umieszczona jest kopia klucza sesji serwera oraz informacje o kliencie. Następnie cała struktura jest szyfrowana za pomocą klucza współdzielonego przez serwer z Centrum Dystrybucji Kluczy (Key Distribution Center — KDC). Klient korzysta z danego biletu, kiedy kontaktuje się z serwerem. Biometria (Biometrics) — zastosowanie cech fizycznych użytkownika, takich jak linie papilarne lub budowa tęczówki oka, do weryfikowania tożsamości użytkownika. Metoda alternatywna do podawania numeru PIN (personal identification code) podczas logowania się za pomocą kart elektronicznych (smart card logon). Blokowanie Dziedziczenia Zasad ( Block Policy Inheritance) — ustawienie w obiekcie zasad grupowych (GPO) związane z jednostką organizacyjną (OU), które zapobiega dziedziczeniu przez jednostkę organizacyjna (OU) ustawień zasad (policy settings) nadrzędnej jednostki organizacyjnej (parent OU). Zob. także No override. Cardlets — aplety Javy umieszczone na karcie elektronicznej (smart card) wykonanej w standardzie Java-Card. Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) — w protokole z kluczem tajnym (shared secret protocol), np. Kerberos 5, zaufany pośrednik wydający klucze tajne (secret keys, key pads). Certyfikat (Certificate) — oświadczenie opatrzone podpisem cyfrowym, dotyczące konkretnego klucza publicznego. Wydający certyfikat, który posiada inną parę kluczy prywatny-publiczny, podpisuje certyfikat. Certyfikat jest również określany jako identyfikator cyfrowy (digital identity). Certyfikat Agenta Rejestrowania (Enrollment Agent Certificate) — umożliwia administratorowi kart elektronicznych uzyskanie certyfikatu karty elektronicznej (smart card certificate) w imieniu innego użytkownika.
Certyfikat logowania się za pomocą karty elektronicznej (Smart card logon certificate) — zapisany na karcie elektronicznej, aby umożliwić uwierzytelnianie użytkownika (user authentication). Certyfikat odzyskiwania plików (File recovery certificate) — certyfikat wydawany dla administratorów, stosowany przy odzyskiwaniu danych zaszyfrowanych. Certyfikat użytkownika karty elektronicznej (Smart card user certificate) — zapisany na karcie elektronicznej, aby umożliwić uwierzytelnianie użytkownika (user authentication) oraz zapewnić dodatkowe funkcje poczty elektronicznej. Certyfikaty z kluczem publicznym X.509v3 (X.509v3 public key certificates) — dane uwierzytelniające (credentials) używane przez usługi katalogowe Active Directory do zapewnienia dostępu do zasobów jednostkom, takim jak użytkownicy, którzy nie mają danych uwierzytelniających protokołu Kerberos. Challenge Handshake Authentication Protocol (CHAP) — mechanizm uwierzytelniania zaszyfrowanego (encrypted authentication mechanism), który pomija przesyłanie rzeczywistego hasła. Cipher — program narzędziowy uruchamiany za pomocą wiersza poleceń, służący do szyfrowania i odszyfrowywania plików i folderów. Client-Server (CS) Exchange — podprotokół protokołu Kerberos stosowany, gdy klient przedstawia usłudze bilet sesji (session ticket). Ustawienia Komputera ( Computer Settings) — gałąź główna (parent node) w Edytorze Zasad Grupy (Group Policy Editor) zawierająca zasady, które określają zachowanie systemu operacyjnego, wygląd pulpitu, ustawienia aplikacji, aplikacje przypisane, opcje korzystania z plików, ustawienia zabezpieczeń oraz skrypty uruchamiania i zamykania komputera. CryptoAPI (Cryptographic Application Programming Interface) — standardowy interfejs funkcji kryptograficznych usługodawców usług kryptograficznych (Cryptographic Service Providers — CSPs). Zawiera on zestaw usług do zarządzania certyfikatami zgodnymi ze standardem X.509v3 i zapewnia magazyn trwały (persistent storage), usługi enumeratora (enumeration services) oraz dekodowanie.
Cscript — host skryptów (scripting host) wywoływany z wiersza poleceń, który służy do uruchamiania skryptów napisanych w języku Visual Basic Scripting Edition (VBScript) lub JavaScript. Dane właściwe (Payload) — dane przesyłane przez sieć. Data Encryption Standard (DES) — standard szyfrowania danych. Algorytm 3DES korzysta z trzech kluczy 128-bitowych. W algorytmie DES zastosowano pojedynczy klucz 56-bitowy. Dcpromo — polecenie uruchamiane za pomocą menu Start/Uruchom (Start/Run), które służy do awansowania serwera pracującego pod kontrolą systemu Windows 2000 na pozycję kontrolera domeny. Deskryptory Zabezpieczeń (Security Descriptors) — służą do kontrolowania dostępu do obiektów w Active Directory za pomocą List Kontroli Dostępu (Access Control Lists — ACLs). Distributed Password Authentication (DPA) — protokół uwierzytelniania z kluczem tajnym (shared-secret authentication protocol), stosowany przez serwisy internetowe, takie jak Microsoft Network (MSN) czy CompuServe. Domain Name System (DNS) — usługa lokalizująca (locator service) używana w Internecie i w większości prywatnych intranetów. DNS jest najczęściej używaną usługą katalogową. Domena główna (Root domain) — pierwsza domena w drzewie domen. Drzewo (Tree) — struktura z wieloma domenami, w której każda domena ufa innym domenom w danym drzewie. Dynamic Domain Name System (DDNS) — implementacja usługi DNS w systemie Windows 2000, która obsługuje dynamiczną bazę danych nazw w domenie i odpowiadających im adresów IP. Edytor Listy Kontroli Dostępu (Access Control List editor) — narzędzie do bezpośredniej zmiany ustawień listy kontroli dostępu (ACL) dostępne za pomocą przystawki (snap-in) konsoli MMC Zasady Grupowe (Group Policy).
Edytor Zasad Grupowych (Group Policy Editor) — narzędzie dostępne za pomocą przystawki (snap-in) konsoli MMC Zasady Grupowe (Group Policy), które służy do edytowania obiektów zasad grupowych (GPOs). Extensible Authentication Protocol (EAP) — protokół stosowany do uwierzytelniania użytkownika. Extensible Authentication Protocol Transport Layer Security (EAP-TLS) — metoda silnego uwierzytelniania oparta na certyfikatach z kluczem publicznym. Filtrowanie w grupach zabezpieczeń (Security group filtering) — Edytor Listy Kontroli Dostępu (Access Control List Editor) może być zastosowany do odpowiedniego ustawiania (filtrowania) zasad w obiekcie zasad grupowych (Group Policy Object — GPO) zależnie od członkostwa użytkownika lub komputera w grupach zabezpieczeń (security group membership). Generic Security Service Application Program Interface (GSSPI) — interfejs API używany do zarządzania kontekstem zabezpieczeń (security context management). Główna Jednostka Certyfikująca Przedsiębiorstwa (Enterprise Root Certificate Authority) — jednostka, która tworzy gałąź główną hierarchii jednostek certyfikujących przedsiębiorstwa w systemie Windows 2000. Wydaje certyfikaty użytkownikom i komputerom w danym przedsiębiorstwie. Graphical Identification and Authentication (GINA) — biblioteka dołączana dynamicznie (Dynamic Link Library — DLL), służąca do gromadzenia danych logowania użytkownika, umieszczania ich w odpowiedniej strukturze danych i wysyłania do lokalnego autorytetu bezpieczeństwa (Local Security Authority — LSA) w celu ich zweryfikowania. Grupa robocza Personal Computer/Smart Card (PC/SC) — tworzy specyfikacje na podstawie norm ISO 7816, zgodne ze specyfikacjami Eurocard, Masterplay and Visa (EMV) i Global System for Mobile Communications (GSM). Hash Message Authentication Code (HMAC) — algorytm z kluczem tajnym, w którym do uzyskania podpisu cyfrowego zastosowano zaszyfrowaną funkcję skrótu (keyed hash function). Jeśli zawartość komunikatu ulegnie zmianie podczas transmisji, zmienia się również skrót (hash value) i pakiet IP zostaje odrzucony. Identyfikator Cyfrowy (Digital Identity) — zob. certyfikat.
Infrastruktura Klucza Publicznego (Public Key Infrastructure — PKI) — infrastruktura klucza publicznego (PKI) systemu Windows 2000 stanowi zintegrowany zestaw usług i narzędzi administracyjnych do tworzenia, wdrażania i zarządzania aplikacjami, korzystającymi z klucza publicznego, za pomocą algorytmów kryptograficznych z kluczem publicznym (Public Key Cryptography — PKC). Interfejs SSPI (Security Support Provider Interface) — interfejs usługodawcy obsługi zabezpieczeń Win32 pomiędzy aplikacjami warstwy transportowej (transport level applications) a usługodawcami zabezpieczeń sieciowych (network security service providers). Interfejsy programowe aplikacji SSPI umożliwiają stosowanie uwierzytelniania (authentication), integralności komunikatów i poufności w aplikacjach rozproszonych. Interfejsy usług Active Directory (Active Directory Service Interfaces — ADSI) — zestaw interfejsów modelu COM (Component Object Model) umożliwiających korzystanie z usług katalogowych. Internet Engineering Task Force (IETF) — instytucja normalizacyjna odpowiedzialna za zdefiniowanie zaleceń (draft standards), np. dla Infrastruktury Klucza Publicznego (Public Key Infrastructure X.509) PKIX. Internet Protocol Encapsulating Security Protocol (IESP) — zapewnia poufność (confidentiality) poprzez zastosowanie algorytmu DES — CBC (Data Encryption Standard — Cipher Block Chaining). Internet Protocol Security (IPSec) — niewidoczny dla użytkownika protokół warstwy sieciowej (warstwa 3) , w którym zastosowano standardowe algorytmy szyfrowania i wszechstronne zarządzanie zabezpieczeniami (comprehensive security management approach). Służy do zapewnienia bezpieczeństwa transmisji za pomocą protokołu TCP/IP po obu stronach zapory ogniowej (firewall) przedsiębiorstwa. Internet Security Association and Key Management Protocol (ISAKMP) — określa wspólny szkielet (framework) do obsługiwania ustanawiania skojarzeń zabezpieczeń (security associations). Java Cards — karty elektroniczne, na których można uruchomić B-kod (bytecode) języka Java, zgodne ze specyfikacją Java Card API 2.1, opracowaną przez oddział JavaSoft firmy Sun Microsystems.
Jednostka Certyfikująca (Certificate Authority — CA) — jednostka lub usługa wydająca certyfikaty i pełniąca rolę gwaranta powiązania pomiędzy danym kluczem publicznym a informacją o tożsamości zawartą w wydanym przez siebie certyfikacie. Jednostka Organizacyjna (Organizational Unit — OU) — składnik Active Directory, który może zawierać użytkowników, grupy i komputery. Karta elektroniczna (Smart card) — niewielka plastikowa karta, podobna do karty bankomatowej, na której zapisane są dane uwierzytelniające, konieczne do zalogowania się przez użytkownika (logon credentials). Karty czipowe (Intergrated Circuit Cards — ICCs) — standard kart elektronicznych, które można stosować w systemie Windows 2000. Karty czipowe mogą wykonywać zaawansowane operacje, takie jak wymiana klucza podpisu cyfrowego (digital signature key exchange). Katalog Globalny (Global Catalog) — usługa umożliwiająca użytkownikom znajdowanie obiektów, niezależnie od tego, czy jest on w drzewie domen (domain tree), czy też w lesie domen (forest). Wszystko, co znajduje się w drzewie domen (domain tree), pojawi się w katalogu globalnym (global catalog). Kerberos — według mitologii to trójgłowy pies, który jest strażnikiem Hadesu. Protokół uwierzytelniania Kerberos używa klucza tajnego (shared secret) znanego dwóm stronom (principals), który jest dostarczany przez zaufaną jednostkę zewnętrzną (trusted third-party) lub przez Centrum Dystrybucji Kluczy (Key Distribution Center — KDC). Kerberos 5 — standardowy, internetowy protokół zabezpieczeń z kluczem tajnym (shared secret). Domyślnie ustawiony w systemie Windows 2000 jako główny protokół uwierzytelniania. Kerberos trust — obustronna, przechodnia relacja zaufania tworzona automatycznie, kiedy domena jest dodawana do drzewa domen. Key pad — klucz tajny (secret key) znany dwóm i tylko dwóm jednostkom. Klucz sesji (Session key) — unikatowy, krótkoterminowy klucz tajny (short-term secret key) dla obydwu stron, używany podczas wzajemnego uwierzytelniania w jednej sesji wymiany danych (communication session). Zob. także: Klucz sesji logowania (Logon session key).
Klucz sesyjny logowania (Logon session key) — klucz sesyjny, który jest ważny tylko do czasu, gdy bilet gwarantujący bilet (Ticket Granting Ticket) nie utraci ważności lub użytkownik nie wyloguje się. Klucz symetryczny (Symmetric key) — pojedynczy klucz umożliwiający zarówno szyfrowanie, jak i odszyfrowanie. Klucze symetryczne są stosowane w algorytmach kryptograficznych z kluczem tajnym (secret key cryptography). Konsola MMC (Microsoft Management Console) — konsola, która stanowi uniwersalny graficzny interfejs użytkownika (Graphical User Interface —GUI), który służy do administrowania systemem Windows 2000. Pojedyncze narzędzia dla konkretnych zastosowań uruchamiane w ramach konsoli MMC są znane jako przystawki (snap-ins) konsoli MMC. Kontroler domeny (Domain controller) — serwer pracujący pod kontrolą systemu Windows 2000, przechowujący dane kont użytkowników i komputerów, Listy Kontroli Dostępu (ACLs) oraz informacje związane z Active Directory. W domenie może występować jeden lub kilka kontrolerów domeny. W drugim przypadku kontrolery domeny dokonują pomiędzy sobą replikacji informacji, które przechowują. Kryptografia (Cryptography) — korzysta z algorytmów kryptograficznych, które przetwarzają tekst jawny (plaintext data) i klucz szyfrowania (encryption key) w dane zaszyfrowane (ciphertext). Do odczytania tekstu jawnego (plaintext data) z danych zaszyfrowanych (ciphertext) używa się klucza odszyfrowywania. Kryptografia asymetryczna (Asymmetric cryptography) — algorytmy kryptograficzne, w których korzysta się z dwu kluczy: jednego do zaszyfrowywania, a drugiego do odszyfrowywania. Obydwa klucze stanowią parę kluczy prywatny-publiczny. Kryptografia z kluczem publicznym (Public Key Cryptography — PKC) — kryptografia, w której korzysta się z kluczy szyfrowania i odszyfrowywania. Klucz szyfrowania zamienia dane w postaci jawnej (plaintext) w dane zaszyfrowane (ciphertext). Klucz odszyfrowywania (związany, ale nie identyczny, z kluczem szyfrowania) zamienia z powrotem dane zaszyfrowane (ciphertext) na dane w postaci jawnej (plaintext). Tak więc każdy z użytkowników ma parę kluczy: klucz publiczny (public key) i klucz prywatny (private key). Kryptografia z kluczem tajnym (Secret key cryptography) — strony wymieniające dane współdzielą klucz kryptograficzny i korzystają z niego w celu weryfikowania tożsamości drugiej strony. Zob. również Klucz symetryczny (Symmetric key).
Las (Forest) — co najmniej dwa drzewa domen (domain trees) połączone ze sobą poprzez relacje zaufania pomiędzy domenami głównymi (root domains). Layer 2 Tunneling Protocol (L2TP) — szyfruje komunikaty IP, IPX lub NetBEUI i przesyła je przez sieci, które umożliwiają przesyłanie datagramów bezpośrednio pomiędzy węzłami, np. sieci IP, X.25, Frame Relay lub ATM (Asynchronous Transfer Mode). Lightweight Directory Access Protocol (LDAP) — protokół, który wymaga systemu operacyjnego do wprowadzania kontroli dostępu. Lista Kontroli Dostępu (Access Control List — ACL) — lista wpisów w deskryptorze zabezpieczeń (security descriptor) obiektu Active Directory, która określa prawa dostępu pojedynczych użytkowników lub grup. Lista Odwołań Certyfikatów (Certificate Revocation List — CRL) — lista certyfikatów odwołanych, sprawdzana w trakcie uwierzytelniania za pomocą certyfikatów. Certyfikat, który został unieważniony lub wygasł musi zostać umieszczony na tej liście, aby jego odwołanie odniosło skutek. Lokalny Autorytet Bezpieczeństwa (Local Security Authority — LSA) — sprawdza dane uwierzytelniające (credentials) logowania użytkownika. Łańcuch Certyfikatów — prowadzi od danej jednostki i jej klucza publicznego, poprzez szereg jednostek certyfikujących (CAs), a kończy się na certyfikacie wydanym przez kogoś, kto ufa drugiej jednostce w sposób niejawny. Taki certyfikat nosi nazwę zaufanego certyfikatu głównego (trusted root certificate). Magazyny Certyfikatów (Certificate Stores) — magazyny certyfikatów (certificate stores) CryptoAPI zarządzają certyfikatami i stanowią składnice dla certyfikatów i związanych z nimi właściwości (properties). Magazyn chroniony (Protected store) — magazyn bezpieczny (secure storage) występujący w technologiach zabezpieczeń internetowych, w którym umieszczone są klucze prywatne i certyfikaty wydane użytkownikom. Menedżer Kluczy Wymiany (Exchange Key Manager) — zintegrowana usługa Microsoft Exchanga dostarczająca certyfikaty zabezpieczeń (security certificates).
Message Digest function 95 (MD5) — funkcja skrótu (hash function) tworząca wartość 128bitową. Messaging Application Programming Interface (MAPI) — interfejs komunikacyjny API spełniający zalecenia WOSA (Windows Open Services Architecture). Metoda Diffie-Hellmana (Diffie-Hellman technique) — algorytm kryptograficzny z kluczem publicznym, umożliwiający dwóm łączącym się jednostkom uzgodnienie klucza tajnego (shared key). Dwie komunikujące się jednostki rozpoczynają od wymiany informacji publicznych. Następnie każda z nich tworzy kombinację informacji publicznej, przesłanej przez drugą stronę, z własną informacją tajną (secret information) i generuje w ten sposób klucz tajny (shared secret value). Microsoft Challenge Handshake Authentication Protocol (MS CHAP) — mechanizm uwierzytelniania szyfrowanego (encrypted authentication) omijający przesyłanie rzeczywistego hasła. MS CHAP jest bardzo podobny do CHAP, oprócz tego, że zapewnia dodatkowy poziom zabezpieczeń, ponieważ umożliwia serwerowi zapisywanie hasła nie w postaci jawnej, lecz przetworzone za pomocą funkcji skrótu. MS CHAP 2 jest podobny do MS CHAP, ale działa tylko na komputerach pracujących pod kontrolą systemu Windows 2000. Microsoft Graphical Identification and Authentication (MSGINA) — zob. Graphical Identification and Authentication (GINA). Microsoft Point-To-Point Encryption (MPPE) — metoda szyfrowania oparta na algorytmie Rivest Shamir Adleman (RSA) RC4. Moduł (Module) — płytka kontaktowa karty elektronicznej (smart card). Składa się z ośmiu styków (contacts) i służy jako złącze pomiędzy układem scalonym (integrated circuit chip) wbudowanym w kartę elektroniczną (smart card) a czytnikiem kart elektronicznych. Moduł Zakończenia Usług Certyfikatów (Certificate Services Exit Module) — wykonuje przetwarzanie końcowe (post-processing), np. publikowanie wydanego certyfikatu. Nagłówek Uwierzytelniania (AH) Protokołu IP (Internet Protocol Authentication Header) — zapewnia integralność (integrity), uwierzytelnianie i ochronę przed atakami metodą powtórzenia (antireplay) za pomocą algorytmu wyliczania zaszyfrowanego skrótu wiadomości (keyed message hash) (Hash Message Authentication Code — HMAC) dla każdego pakietu IP.
Narzędzia Do Konfigurowania Zabezpieczeń (Security Configuration Tools) — programy narzędziowe przeznaczone do konfigurowania, analizowania, eksportowania i ustawień zabezpieczeń na komputerach lokalnych, oparte na zestawie szablonów zabezpieczeń (security templates). Narzędzia te obejmują przystawkę (snap-in) konsoli MMC Szablony Zabezpieczeń (Security Templates), przystawkę (snap-in) konsoli MMC Konfigurowanie i Analizowanie Zabezpieczeń (Security Configuration and Analysis) oraz program narzędziowy Secedit. Nazwa Prywatna Użytkownika (User Private Name — UPN) — nazwa umieszczona w polu Subject Alternative Name certyfikatu klienta, która określa zarówno dokładną nazwę użytkownika, jak i domeny, w której znajduje się dane konto. Nie zastępuj (No override) — ustawienie zapisane w obiekcie zasad grupowych (Group Policy Object — GPO) związanym z jednostką organizacyjną (OU), które gwarantuje, że potomne jednostki organizacyjne (child OUs) dziedziczą ustawienia zasad (policy settings) macierzystej jednostki organizacyjnej (parent OU). Ustawienie Nie zastępuj (No override) anuluje ustawienie Zablokuj Dziedziczenie Zasad (Block Policy Inheritance) w potomnych jednostkach organizacyjnych (child OUs). Numer PIN (personal identification number) — czterocyfrowy numer używany do potwierdzania tożsamości użytkownika posługującego się kartą elektroniczną. Oakley — protokół generowania klucza, w którym zastosowano algorytm wymiany klucza DiffieHellman (DH). Oakley stosuje Perfect Forward Secrecy (PFS). Obiekt zasad grupowych (Group Policy Object — GPO) — obiekt Active Directory zawierający zasady grupowe (group policies), takie jak zasady zabezpieczeń (security policy). Ustawienia obiektu zasad grupowych (GPO) mogą być zastosowane do lokacji (sites), domen i jednostek organizacyjnych (OUs). Object Linking and Embedding Directory Services (OLE DS) — zestaw usług sterujących przesyłaniem danych pomiędzy aplikacjami i zapewniający obsługę języków skryptowych. Obszar (Realm) — w protokole Kerberos odpowiednik domeny systemu Windows 2000. OpenCard Consortium — grupa firm definiująca i rozwijająca standard OpenCard Framework. OpenCard Framework (OCF) — osnowa (framework) oprogramowania obiektowego do korzystania z kart elektronicznych (smart card).
Open Directory Services Interface (ODSI) — interfejs API (Application Programming Interface) umożliwiający korzystanie z wielu usług katalogowych. Otwartość (Openness) — stopień dostępności katalogów sieciowych, np. Active Directory, dla klientów (poza tymi, dla których są bezpośrednio przeznaczone). Password Authentication Protocol (PAP) — sposób uwierzytelniania, który zwraca nazwę użytkownika i hasło w postaci tekstu jawnego . Perfect Forward Secrecy (PFS) — gwarantuje, że w przypadku złamania klucza uzyskiwany jest dostęp wyłącznie do danych zabezpieczanych za pomocą tego klucza. Podpis cyfrowy (Digital signature) — gwarantuje, że dane naprawdę zostały wysłane przez jednostkę, która podaje się za nadawcę. Oparty jest na przekształceniach matematycznych, tworzących kombinację klucza prywatnego (private key) nadawcy z podpisywanymi danymi. Podporządkowana jednostka certyfikująca (Subordinate certificate authority) — jednostka certyfikująca (Certificate Authority — CA) znajdująca się w łańcuchu certyfikatów (certificate chain) inna niż główna jednostka certyfikująca (root CA). Podporządkowane jednostki certyfikujące (subordinate CAs) są często określane jako pośredniczące jednostki certyfikujące (intermediate CA) lub jednostki certyfikujące wydające certyfikaty (issuing CA). Podporządkowana jednostka certyfikująca przedsiębiorstwa (Enterprise subordinate certificate authority) — jednostka wydająca certyfikaty w danej sieci, ale nie jest najbardziej zaufana w danym przedsiębiorstwie, ponieważ jest podporządkowana innej jednostce certyfikującej w danej strukturze hierarchicznej. Point-To-Point Tunneling Protocol (PPTP) — protokół, który służy do szyfrowania danych przesyłanych za pomocą protokołów IP, IPX lub NetBEUI, ukrywania (encapsulate) w nagłówku protokołu IP i przesyłania przez sieci IP, np. Internet. Pośrednicząca jednostka certyfikująca (Intermediate certificate authority) — zob. podporządkowana jednostka certyfikująca przedsiębiorstwa (Enterprise subordinate certificate authority).
Private Communications Technology (PCT 1) — protokół umożliwiający zarówno szyfrowanie (aby zapewnić poufność wymienianych danych), jak i uwierzytelnianie (aby umożliwić wzajemną identyfikację klienta i serwera). Dowód Posiadania (Proof of Possession) — za pomocą protokołu dowód posiadania (proof of possession), w trakcie wymiany danych, odbiorca potwierdza, że ma dostęp do danego klucza prywatnego, szyfrując wezwanie (challenge) za pomocą tego klucza. Następnie nadawca korzysta z klucza publicznego odbiorcy w celu potwierdzania tożsamości odbiorcy. Przechodnia Relacja Zaufania (Transitive Trust) — zachodzi, gdy domena A ufa domenie B i domena B ufa domenie C, to domena A ufa domenie C. Przydzielanie Certyfikatów (Certificate Mapping) — skojarzenie pomiędzy certyfikatem a kontem użytkownika. Przyporządkowanie jeden do jednego (One-to-one mapping) — przyporządkowanie pojedynczego certyfikatu użytkownika do jednego konta użytkownika. Przyporządkowywanie nazwy głównej użytkownika (User Principal Name mapping) — przyporządkowanie certyfikatu jeden do jednego (one-to-one certificate mapping) dostępne tylko za pomocą Active Directory. Przyporządkowanie wiele do jednego (Many-to-one mapping) — przyporządkowanie wielu certyfikatów do jednego konta użytkownika. Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) — protokół integrujący uwierzytelnianie na podstawie klucza publicznego (public key based authentication) z systemem kontroli dostępu Kerberos w systemie Windows 2000. Public Key Cryptography Standards (PKCS) — zestaw standardowych algorytmów szyfrowania z kluczem publicznym, opartych na algorytmie Rivest Shamir Adleman (RSA). PKCS #10 definiuje komunikaty żądania certyfikatów. PKCS #7 definiuje odpowiedzi zawierające żądany certyfikat lub łańcuch certyfikatów (certificate chain). Komunikaty PKCS #12 zawierają parę kluczy prywatny-publiczny zaszyfrowaną za pomocą hasła. Public Key Infrastructure X.509 (PKIX) — zestaw zaleceń opracowanych przez Internet Engineering Task Force (IETF).
Remote Authentication Dial-in User Service (RADIUS) — usługa stosowana do uwierzytelniania (authentication) i autoryzacji (authorization) użytkowników zdalnych (remote users). Na ogół z usługi RADIUS korzysta się w dużych sieciach z wieloma serwerami Wirtualnych Sieci Prywatnych (Virtual Private Network servers). Roaming — używanie tych samych aplikacji, korzystających z klucza publicznego na różnych komputerach w danej sieci systemu Windows 2000. Rozszerzenie Ustawień Zabezpieczeń (Security Settings Extension) — rozszerzenie Edytora Zasad Grupowych (Group Policy Editor) stosowane do określania konfiguracji zabezpieczeń grup użytkowników lub grup komputerów w obiekcie zasad grupowych (Group Policy Object — GPO). Runas — program narzędziowy uruchamiany za pomocą wiersza poleceń, umożliwiający administratorowi zalogowanie się jako członek grupy użytkowników (User) lub zaawansowanych użytkowników (Power Users) i uruchomienie programów do administrowania w kontekście administratora (administrative context), bez konieczności wylogowania się i ponownego zalogowania się. Ruter odpowiadający (Answering router) — ruter docelowy w połączeniu RRAS (Routing and Remote Access Service). W przypadku korzystania z Wirtualnych Sieci Prywatnych (VPN), ruter odpowiadający jest punktem końcowym tunelu (tunnel endpoint). Ruter wywołujący (Calling router) — ruter nadający w połączeniu RRAS (Routing and Remote Access Service). W przypadku korzystania z Wirtualnych Sieci Prywatnych (VPN), ruter odpowiadający jest punktem końcowym tunelu (tunnel endpoint). Script — plik wsadowy (BAT), plik poleceń (CMD) lub plik wykonywalny (EXE) włączany podczas uruchamiania lub zamykania komputera lub za każdym razem, kiedy użytkownik loguje się lub wylogowuje na dowolnym komputerze w sieci. Secedit — program narzędziowy uruchamiany za pomocą wiersza poleceń do konfigurowania i analizowania ustawień komputera lokalnego, opartych na zestawie szablonów zabezpieczeń. Secure Attention Sequence (SAS) — w Windows 2000 i NT 4 jest to Ctrl+Alt+Delete. Secure Channel (Schannel) — usługa, korzystająca z interfejsu CryptoAPI, która obsługuje uwierzytelnianie (authentication) i szyfrowanie sieciowe za pomocą protokołów TLS (Transport Layer Security) i SSL (Secure Sockets Layer).
Secure Electronic Transaction (SET) — protokół zabezpieczania płatności (secure payment protocol) dla transakcji dokonywanych za pomocą kart kredytowych. Secure Sockets Layer 3 (SSL 3) — protokół zabezpieczeń stosowany do szyfrowania w przeglądarkach internetowych i tworzenia bezpiecznych witryn internetowych. Zob. również Transport Layer Security (TLS). Security Parameters Index (SPI) — identyfikator stosowany do odróżniania skojarzeń zabezpieczeń (Security Associations — SAs) istniejących w komputerze-odbiorcy. Serwer Certyfikatów (Certificate Server) — usługodawca, wydający aplikacjom certyfikaty i zarządzający nimi, korzystający z metod kryptografii z kluczem publicznym (PKC). Umożliwia to domenom systemu Windows 2000 wydawanie certyfikatów wewnątrz danej domeny. Domena może również zostać swoją własną jednostką certyfikującą (Certificate Authority — CA). Serwer NAT (Network Address Translation server) — serwer, który chroni adresy IP w intranecie poprzez przyporządkowanie ich adresom internetowym. Przykładem serwera NAT jest serwer Proxy Microsoftu (Microsoft Proxy server). Serwer Wirtualnych Sieci Prywatnych (Virtual Private Network server) — serwer usługi RRAS (Routing and Remote Access Service) obsługujący połączenia za pomocą Wirtualnych Sieci Prywatnych (VPN connections). Shiva Password Authentication Protocol (SPAP) — mechanizm uwierzytelniania (authentication mechanism) stosowany w środowisku mieszanym do obsługi klientów korzystających z oprogramowania Shiva LAN Rover. Skojarzenie Zabezpieczeń (Security Association — SA) — określa usługi zabezpieczeń (security services), sposoby i klucze stosowane do ochrony wymiany danych na drodze od nadawcy do odbiorcy. Specyfikacja kart elektronicznych dla GSM (Global System for Mobile Communications smart card specification) — specyfikacja opracowana przez europejskie firmy telekomunikacyjne, oparta na normach ISO 7816, umożliwiająca identyfikację i uwierzytelnianie użytkowników telefonów komórkowych.
Sprzężenie zwrotne (Loopback) — właściwość zasad grupowych (Group Policy feature) umożliwiająca administratorowi zastosowanie zasad grupowych (Group Policy) do komputera lub grup komputerów w danej strukturze Active Directory. Ustawienia zasad (policy) są określone przez tożsamość danego komputera, a nie użytkownika. Stacja rejestrowania kart elektronicznych (Smart card enrollment station) — to komputer skonfigurowany w ten sposób, by wydawać karty elektroniczne. Musi być zainstalowany odpowiedni sprzęt oraz trzeba uzyskać certyfikat agenta rejestrowania (enrollment agent certificate), aby administrator kart elektronicznych (smart card administrator) mógł zarejestrować się w imieniu użytkownika i uzyskać certyfikat dla karty elektronicznej (smart card certificate). Standard EMV (Eurocard, Masterplay and Visa Standard) — branżowa specyfikacja kart elektronicznych oparta na normach ISO 7816 i definiująca dodatkowe typy danych i reguły pisania programów, które są stosowane przez firmy świadczące usługi finansowe. Stosowanie zasad grupy Wpis kontroli dostępu (Apply Group Policy Access Control Entry — AGP ACE) — grupy, które dla obiektu zasad grupowych (GPO) mają ustawione uprawnienie AGP (Apply Group Policy) oraz wpis kontroli dostępu (ACE) umożliwiający odczyt (read access) otrzymują Zasady grupowe (Group Policies) zawarte w danym obiekcie zasad grupowych (GPO). System Szyfrowania Plików (Encrypting File System — EFS) — sposób szyfrowania plików danych. Każdy plik zostanie zaszyfrowany za pomocą losowo wygenerowanego klucza, który jest niezależny od należącej do użytkownika pary kluczy publiczny-prywatny. Do szyfrowania plików zastosowano algorytm DES (Data Encryption Standard). Szablon Administracyjny (Administrative Template) — hierarchiczna struktura kategorii i podkategorii, które razem określają, w jaki sposób zorganizowane są opcje interfejsu użytkownika Zasady Grupowe (Group Policy), znanego również pod nazwą Szablon Zasad (Policy Template). Szablon Zasad (Policy Template) — zob. Szablon administracyjny (Administrative Template). Ticket Granting Service (TGS) Exchange — podprotokół protokołu Kerberos stosowany, gdy Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) przesyła klucz sesji usługi (service session key) i bilet sesji (session ticket) dla danej usługi. Transport Layer Security (TLS) — protokół opracowany na podstawie protokołu Secure Sockets Layer 3 (SSL3/TLS), który obsługuje uwierzytelnianie klienta za pomocą przyporządkowania danych uwierzytelniających użytkownika (mapping user credentials) w postaci certyfikatów z kluczem publicznym (public key certificates) do istniejących kont systemu Windows NT.
Tryb tunelu IPSec (IPSec tunnel mode) — tryb, który szyfruje dane zawarte w pakietach IP, ukrywa je (encapsulates) w nagłówku pakietu IP (IP header) i przesyła je przez sieci IP, takie jak Internet. Tunelowanie (Tunneling) — sposób przesyłania danych do danej sieci za pomocą drugiej sieci pośredniej. Protokół tunelowania ukrywa (encapsulates) ramki (frames) lub pakiety (packets) w dodatkowym nagłówku (header), który umożliwia rutowanie (routing), aby dane mogły zostać przesłane poprzez sieć pośredniczącą. Usługa lokalizująca (Locator) — usługa, która tłumaczy nazwę domeny, np. www.mycompany.com, na adres IP. Usługa RRAS (Routing and Remote Access Service) — usługa umożliwiająca zdalny dostęp za pomocą linii telefonicznej lub za pomocą Wirtualnych Sieci Prywatnych (Virtual Private Networks) Usługodawca internetowy (Internet Service Provider — ISP) — firma zewnętrzna zapewniająca połączenie z siecią WWW. Usługodawca Usług Kryptograficznych (Cryptographic Service Provider — CSP) — jednostka dostarczająca usługi kryptograficzne. Usługodawcy usług kryptograficznych mogą być programowi lub też korzystać z urządzeń kryptograficznych (cryptographic hardware devices). Usługodawca Obsługi Zabezpieczeń (Security Support Provider — SSP) — element protokołu Kerberos, umożliwiający lokalnemu autorytetowi zabezpieczeń (Local Security Authority — LSA) w jednej domenie bezpośrednie komunikowanie się z Centrum Dystrybucji Kluczy (Key Distribution Center — KDC) w innej domenie. Ustawienia Użytkownika (User Settings) — gałąź nadrzędna (parent node) w Edytorze zasad grupowych (Group Policy editor) zawierająca informacje dotyczące konkretnego użytkownika, takie jak: zachowanie się systemu operacyjnego, ustawienia pulpitu, ustawienia aplikacji, aplikacje przydzielone (assigned applications) i opublikowane (published applications), opcje instalowania plików, ustawienia zabezpieczeń oraz skrypty logowania i wylogowywania się użytkownika. Uwierzytelnianie Delegowane (Delegated Authentication) — mechanizm pośredniczący (proxy mechanism) umożliwiający usłudze personifikację klienta (impersonate its client) podczas łączenia się z innymi usługami.
Uwierzytelnianie Wzajemne (Mutual Authentication) — właściwość protokołu Kerberos 5, dzięki której po obu stronach połączenia sieciowego wiadomo, że po tej drugiej stronie połączenia naprawdę jest ten, kto się przedstawia. Wartość uwierzytelniająca (Authenticator) — informacja zaszyfrowana za pomocą klucza tajnego (secret key) i zawierająca pole znacznika czasu (timestamp field). Windows NT LAN Manager (NTLM) — podstawowy protokół zabezpieczeń zastosowany w systemie Windows NT 4 i wersjach wcześniejszych Windows NT. Został zachowany w systemie Windows 2000 w celu zapewnienia zgodności wstecznej (backward compatibility). Windows Scripting Host (WSH) — interfejs Microsoftu do uruchamiania skryptów obiektowych (object-oriented scripts). Wirtualne Sieci Prywatne (Virtual Private Network — VPN) — sieci te umożliwiają tworzenie tunelu w Internecie lub innej sieci publicznej, zachowując taki sam poziom zabezpieczeń, jaki byłby zapewniony w sieci prywatnej. Wystawiająca jednostka certyfikująca (Issuing certificate authority) — zob. Podporządkowana jednostka certyfikująca przedsiębiorstwa (Enterprise subordinate certificate authority) Zasady Grupowe (Group Policy) — ustawienia zapisane w obiekcie zasad grupowych (Group Policy Object — GPO), które następnie mogą być zastosowane w obiektach Active Directory, takich jak lokacje (sites), domeny czy jednostki organizacyjne (OUs). Zaufany Certyfikat Główny (Trusted Root Certificate) — certyfikat wydawany przez jednostkę certyfikującą (CA), której użytkownik ufa bezgranicznie. Zob. również Łańcuch Certyfikatów (Certificate Chain).
