Microsoft w Windows Server 2003 położył szczególny nacisk na bezpieczeństwo, które w najnowszej wersji Windows było najważniejszym celem, jaki przyświecał projektantom i programistom tego systemu.

Wysoki stopień bezpieczeństwa został osiągnięty na wiele sposobów. Oprócz zmian w samej konstrukcji systemu (przebudowanych zostało wiele składników w Windows), zmieniono także „domyślny” poziom bezpieczeństwa, ustawiany w momencie instalowania systemu operacyjnego.

Wszystko to sprawia, że administrator musi podjąć świadomą decyzję, zanim udostępni określoną usługę czy pozwoli na dostęp użytkownikom do danego serwera. W poprzednich wersjach systemu domyślnie instalowane były niemal wszystkie składniki, teraz instalowane są tylko te, które są potrzebne do realizacji odpowiednich ról.

Widać to chyba najlepiej na przykładzie Internet Information Server w wersji 6.0. Jest to zupełnie nowy produkt – o innej, znacznie bezpieczniejszej konstrukcji, w porównaniu z wersją 5.0. Jednak mimo to domyślna instalacja serwera w ogóle nie wgrywa IIS. Aby zainstalować IIS, trzeba dodać rolę serwera aplikacyjnego. Jednak nawet to nie powoduje włączania potencjalnie ryzykownych elementów. Aby np. możliwe było uruchomienie usługi indeksowania, musi zostać jawnie włączone odpowiednie rozszerzenie serwera IIS. Oczywiście można to wszystko wygodnie skonfigurować z poziomu kreatora ról serwera – należy jednak jeszcze raz podkreślić – w Windows Server 2003 administrator musi bardzo dokładnie określić, jakie usługi mają działać na serwerze.

Innym przykładem jest np. udostępnianie folderów. W Windows 2000 Server, jeżeli tworzony był udział sieciowy, to domyślnie grupa „Wszyscy” (Everyone) miała pełny dostęp; w Windows Server 2003 – może tylko czytać z danego udziału.

Na bezpieczeństwo w Windows Server 2003 składa się kilka kluczowych elementów – różne sposoby autoryzacji i identyfikacji użytkownika, listy dostępu i praw, a także polisy i inne mechanizmy pozwalające tworzyć spójną politykę bezpieczeństwa obejmującą różne aspekty działania serwera.

Autoryzacja

Autoryzacja jest procesem weryfikacji obiektu – czy rzeczywiście jest tym, za kogo się podaje. Najpowszechniejszym przykładem autoryzacji jest logowanie się użytkownika do systemu. W najprostszym przypadku – podaje swój identyfikator oraz hasło. Jednak Windows Server 2003 obsługuje także smart card czy inne mechanizmy przekazywania informacji do autoryzacji.

Smart cards (czyli inteligentne karty) są trudnymi do zniszczenia obiektami przechowującymi poufne i osobiste informacje. Są kluczem, który pozwala uzyskać dostęp do określonych zasobów, a także zalogować się do serwera. Odgrywają także istotną rolę w zaawansowanej infrastrukturze klucza publicznego PKI (dostępnej z poziomu Windows XP oraz Windows Server 2003). smart cards oddzielają komputer od mechanizmów związanych z autoryzacją i identyfikacją – podpisami cyfrowymi, mechanizmem wymiany kluczy itp. Wszystkie te operacje dzieją się na karcie. Może ona stanowić podstawę „cyfrowej identyfikacji” użytkownika.

Logowanie przy użyciu smart card to najpewniejszy sposób autoryzacji. Użytkownik musi posiadać kartę, a dodatkowo znać swój kod PIN (który w odróżnieniu od kart bankomatowych może zawierać także znaki alfanumeryczne). Smart Card utrudnia też nieautoryzowane wejście do systemu. Włamywacz musi nie tylko podsłuchać PIN użytkownika, ale także ukraść kartę. Jest to znacznie trudniejsze do wykonania niż samo „złamanie” hasła. I – należy to mocno podkreślić – jest niemożliwe w sytuacji, gdy włamanie ma być wykonane zdalnie – konieczny jest fizyczny kontakt między włamywaczem a ofiarą, by stworzyć okazję do kradzieży.
Warto dodać, że w prawie wielu krajów trudno jest dowieść włamania do systemu informatycznego. Łatwiej można pokazać, że włamywacz/haker ukradł fizyczny obiekt – smart card.

Logowanie przy użyciu smart card nie wymaga naciskania CTRL+ALT+DEL. Wystarczy, by użytkownik wsunął kartę do czytnika, a system operacyjny poprosi go o podanie identyfikatora PIN (a nie o wprowadzenie nazwy użytkownika i hasła).

Dodatkowo w Windows Server 2003 można ograniczyć dostęp do części poleceń administracyjnych w taki sposób, by mógł je wykonać tylko administrator z odpowiednią smart card. Są to polecenia takie jak: DCPromo (do instalacji lub poważnych zmian w strukturze katalogu), mapowanie dysków sieciowych, polecenie Run As czy Net.

Smart Card może być także wykorzystana przy sesjach terminalowych, a może nawet być określone wymaganie, że logowanie do serwera terminali musi opierać się na mechanizmie SmartCard.

Jeżeli system rozpozna przekazane dane, użytkownik jest zalogowany i może wykonywać określone operacje w systemie. Dzięki mechanizmowi DACL (Dicrete Access Control List) administrator może dość dokładnie określić, co dany użytkownik może robić. Windows Server 2003 pozwala na jednorazowe logowanie się do wszystkich zasobów sieciowych.

Typy autoryzacji

W Windows 2000 dostępnych jest wiele różnych protokołów autoryzacyjnych – w zależności od potrzeb można wykorzystać jeden z poniższych sposobów autoryzacji. Niektóre z nich przeznaczone są tylko dla aplikacji WWW i służą ochronie poufności informacji umieszczanych na stronach inter- lub intranetowych, inne służą do logowania się do Windows Server 2003 i np. pozwalają przeglądać zasoby Active Directory.

Kontrola oparta na liście praw dostępu

Prawa dostępu w Windows Server 2003 oparte są na tzw. listach DACL – czyli listach, gdzie każdy użytkownik lub grupa ma precyzyjnie określone prawa, co może zrobić z określonym obiektem. Dostęp oparty na ACL (czy – DACL) dotyczy każdego aspektu działania Windows Server 2003.

Każdy autoryzowany użytkownik ma swój unikatowy identyfikator (SID), który tworzony jest w momencie zakładania konta. Następnie z tym SID (lub SID grupy) związywane są określone prawa. Prawa te można wiązać z konkretnym komputerem, czy wręcz jednostką organizacyjną (OU).

Samą kontrolą praw zajmuje się ważny element jądra Windows 2003 – Object Manager. Tak więc badanie praw dostępu odbywa się na dosyć szczegółowym poziomie i obejmuje każdy aspekt działania Windows Server 2003.

Administrator używając różnych narzędzi może ustalać prawa dostępu do plików, folderów, drukarek, kluczy rejestru czy poszczególnych usług. Dzięki umiejętnej konfiguracji deskryptorów bezpieczeństwa w obiektach (np. Active Directory) określona grupa użytkowników może uzyskać dostęp np. tylko do podzbioru informacji, tzn. szeregowy pracownik nie może domyślnie widzieć adresu domowego innego pracownika.

Dostęp DACL pozwala także na szczegółowe monitorowanie operacji wykonywanych przez użytkownika – np. kiedy odwoływał się on do danego obiektu czy też kiedy ktoś próbuje uzyskać dostęp do elementu, do którego nie ma praw.

Aby zrozumieć DACL, warto poznać kilka kluczowych pojęć związanych z listą kontroli dostępu.

Prawa

Prawa definiują, jakie operacje dany użytkownik (a raczej element o danym numerze SID) może wykonać na określonym obiekcie.

Prawa mogą być przypisane m.in. do następujących obiektów:

• użytkowników/grup danej domeny,
• komputerów i innych „specjalnych” obiektów występujących w Active Directory,
• użytkowników czy grup należących do innej domeny, która jest połączona relacją zaufania z daną domeną,
• lokalnie zdefiniowanych użytkowników/grup na danym komputerze.

Należy podkreślić, że zalecane jest przypisywanie praw do grup użytkowników, a nie do poszczególnych osób. Wynika to stąd, że numer SID jest unikatowy i jeżeli np. Kowalski będzie miał określony numer SID, a pewne prawa będą związane bezpośrednio z Kowalskim, to po usunięciu konta użytkownika nie ma możliwości, by np. drugi raz utworzyć Kowalskiego z tym samym numerem SID.

Pełna lista możliwych typów praw obejmuje kilkadziesiąt pozycji o określonej roli – w zależności od typu chronionego obiektu (np. inne będą dotyczyć pliku, a inne drukarki).

Można jednak wyodrębnić cztery główne „typy” dostępu:

• prawa do odczytu
• prawa do modyfikacji
• prawa do zmiany właściciela
• prawa do usunięcia obiektu.

Definiując prawa należy pamiętać, że prawa „zakazujące” (ang. deny) dostępu mają priorytet nad prawami „zezwalającymi”. Innymi słowy – jeżeli Kowalski należy do grupy „Sprzedawcy” i „Staż”, a grupa „Sprzedawcy” ma prawa zapisu do określonego foldera, ale grupa „Staż” ma jawnie te prawa zabrane, to wtedy Kowalski nie ma prawa zapisu do danego foldera.

Własność obiektu

Każdy obiekt kontrolowany przez Windows Server 2003 ma swojego właściciela. Domyślnie – ten kto stworzył obiekt, jest jego właścicielem. Bez względu na uprawnienia, właściciel zawsze może zmienić ustawione DACL-e dla „swojego obiektu”. Może też zabrać sobie samemu prawa do tego obiektu. Wtedy nie ma możliwości, by np. odczytać dany plik, jeżeli wcześniej nie przywróci sobie tych praw.

Dziedziczenie uprawnień

Jedną z ważniejszych zalet mechanizmu DACL jest możliwość dziedziczenia uprawnień. Można określić, że np. wszystkie pliki czy podfoldery będą dziedziczyły uprawnienia z folderu nadrzędnego. Warto dodać, że w Windows Server 2003 można dokładnie określić, które uprawnienia mają być dziedziczone w obiektach „potomnych” (czyli tych, które są zawarte w danym obiekcie).

Łańcuch uprawnień

W skomplikowanych przypadkach trudno od razu określić, jakie uprawnienia ma konkretna grupa czy użytkownik. Wynika to stąd, że w Windows Server 2003 prawa można ustalać na dowolnym poziomie drzewa katalogu – użytkownik może należeć do wielu grup, grupy mogą być zagnieżdżone itp. Tak więc przy skomplikowanej strukturze administrator musi poświęcić wiele uwagi, aby prawidłowo określić prawa dostępu. W Windows Server 2003 pomoże mu w tym dodatkowa zakładka w oknie zaawansowanego ustawiania uprawnień. Można w niej wybrać określoną grupę, czy wręcz danego użytkownika i podejrzeć „obowiązujące” uprawnienia dla danej grupy.

Dzięki zakładce “Czynne uprawnienia” można podejrzeć, jakie efektywne uprawnienia dla danego folderu ma da określona grupa czy użytkownik. Jest to nieocenione narzędzie.

Przykład - praca z uprawnieniami

Aby dodać lub sprawdzić jakie uprawnienia są przypisane do określonego pliku, można skorzystać na przykład z interfejsu eksploratora Windows. W tym celu wystarczy kliknąć prawym przyciskiem.

Dalszy sposób postępowania zależy od tego, co się chce osiągnąć. Jeżeli uprawnienia do plików ustawiane są na poziomie partycji NTFS, wtedy należy przełączyć się na zakładkę Zabezpieczenia po czym można np. dodać nowego użytkownika (lepiej – grupę) i przypisać mu określone prawa.

Analogiczne operacje można wykonać po wejściu w pozycję Właściwości w menu podręcznym.

Jeżeli natomiast chcemy ustawiać prawa na poziomie udziału sieciowego, w takim przypadku należy wejść na zakładkę Uprawnienia udziału.

Należy tu jeszcze raz podkreślić różnicę pomiędzy ustawianiem praw na poziomie udziału sieciowego, a praw przypisywanych poszczególnym obiektom na dysku (praw wykorzystujących uprawnienia NTFS i mechanizm DACL). Po pierwsze – zakres praw „dla udziału” jest znacznie bardziej ubogi – można określić, że dany użytkownik/grupa ma albo pełną kontrolę, prawo do odczytu lub też prawo do zmiany. Przy użyciu mechanizmów NTFS można ustawić znacznie dokładniejsze uprawnienia. Po drugie – prawa ustawione na poziomie udziału sieciowego, nie mają znaczenia, jeżeli np. użytkownik zaloguje się lokalnie.

Jeżeli równocześnie ustawiamy prawa na poziomie udziału sieciowego, oraz na poziomie NTFS, to aby dana grupa miała możliwość skorzystania z określonego udziału, musi mieć „prawo” zarówno do udziału jak i do zasobów w NTFS.

W Windows 2003 wszystkie operacje związane z uprawnieniami można także wykonywać z poziomu linii poleceń. Polecenie cacls pozwala wyświetlać albo zmieniać listę praw dostępu (DACL) dla wybranych plików / katalogów.

Na przykład, chcąc sprawdzić uprawnienia folderu Jan, można wydać polecenie cacls Jan (będąc oczywiście w określonym katalogu):

E:\Publiczne>cacls Jan

E:\Publiczne\Jan BUILTIN\Administratorzy:(OI)(CI)F

               ZARZĄDZANIE NT\SYSTEM:(OI)(CI)F

               BUILTIN\Administratorzy:F

               TWÓRCA-WŁAŚCICIEL:(OI)(CI)(IO)F

               BUILTIN\Użytkownicy:(OI)(CI)R

               BUILTIN\Użytkownicy:(CI)(dostęp specjalny:)

                               FILE_APPEND_DATA 

               BUILTIN\Użytkownicy:(CI)(dostęp specjalny:)

                               FILE_WRITE_DATA

Jeżeli chcemy przypisać prawo tylko do odczytu dla użytkownika Adam, można wydać polecenie:

Przełącznik /E powoduje że nowo określane parametry ACL będą dopisane do już istniejących uprawnień. Jeżeli go zabraknie, wtedy istniejące uprawnienia zostaną skasowane, a (w powyższym przypadku) do danego folderu będzie miał dostęp tylko Adam z prawem tylko do odczytu.

Innym pożytecznym poleceniem związanym z uprawnieniami jest takeown. Pozwala ono administratorowi przejąć plik/folder na własność. Na przykład, po wydaniu polecenia:

folder E:\Publiczne\Jan należy do administratora.

Większość operacji dostępnych z linii poleceń w Windows 2003 może dotyczyć dowolnego serwera w sieci – używając takeown można podłączyć się do konkretnego komputera (jako dany użytkownik). Skrócona składnia tego polecenia ma postać:

Tak samo można ustalać prawa dostępu dla udziałów sieciowych. Do wykonywania takiej operacji służy polecenie net

Po wykonaniu powyższego polecenia, utworzony został nowy udział o nazwie Jan, do którego ma dostęp użytkownik ADAM w trybie tylko do odczytu.

Autoryzacja oparta na rolach

Przed Windows Server 2003 EE jedyny model praw dostępu oparty był na obiekcie. Dla konkretnego elementu określana była lista DACL definiująca, jakie operacje konkretny użytkownik (lub grupa użytkowników) może wykonać. Jest to optymalne rozwiązanie w wielu sytuacjach – np. blokada dostępu do elementów konfiguracyjnych zawartych w rejestrze czy ochrona plików.

Jednak mechanizm DACL nie sprawdza się w sytuacjach, gdy trzeba zapewnić ochronę w warstwie logiki biznesowej. Wyobraźmy sobie mechanizm tworzenia zamówień. Tak naprawdę nie wystarczy zbadać praw dostępu do jednego obiektu, by zezwolić lub zabronić wystawienia zamówienia. Aplikacja musi analizować cały ciąg uprawnień do wykonywania tej czynności, np. prawa dostępu do bazy itp. Jednak równocześnie można wyobrazić sobie ograniczenie, że np. dana osoba może wystawiać zamówienia tylko do określonej kwoty. Tego typu uprawnienie nie może być wyrażone w języku DACL. Standardowo, tego typu sprawdzenie aplikacja musiała je wykonywać samodzielnie.W Windows Server 2003 Enterprise Edition można jednak wykorzystać mechanizm dynamicznych reguł biznesowych określających uprawnienia użytkownika.

Kontrola oparta na obiektach

Tradycyjnie aplikacja Windows chcąc uzyskać dostęp do danego obiektu w imieniu użytkownika, przekazywała żądanie wraz z tokenem identyfikującym danego klienta. Komponent zarządzający dostępem do danych (Resource Manager) analizując listę ACL pozwalał lub nie na dostęp.

Innymi słowy, gdy klient żąda od aplikacji wykonania operacji, która wymaga dostępu do chronionego obiektu, aplikacja przekazuje token klienta dalej, do RM, który decyduje o dostępie. Zakłada to, że administrator odpowiednio zdefiniował prawa dostępu i w porozumieniu z developerem ustalił, kto do jakich obiektów musi mieć dostęp. Ale część praw ma ze swojej „natury” dynamiczny charakter – np. do niektórych elementów może być dostęp tylko w określonych godzinach, a czasami ograniczenia wynikają ze stanowiska – np. początkujący handlowiec nie może podejmować zbyt wysokich zobowiązać. Rzeczywiste aplikacje biznesowe wykorzystują takie ograniczenia, co sprawia, że informacja o prawach dostępu jest rozproszona pomiędzy mechanizmy wbudowane w aplikacje i w system operacyjny. Równocześnie zmiana struktury bezpieczeństwa w firmie (lub rozbudowa aplikacji) wymaga ponownych konsultacji administratorów z developerami. Zwykle powstaje kompromis, w którym administrator daje „pełny” dostęp, wychodząc z założenia, że za prawa dostępu odpowiada aplikacja.

Kontrola oparta na rolach

W Windows Server 2003 Enterprise Edition można wykorzystać zupełnie nowy mechanizm praw. Z poziomu aplikacji definiowane są „role” określające grupy użytkowników, którzy mogą wykonywać określone aplikacje (dobrą analogią są tu np. role w serwerze bazodanowym – gdzie jedna osoba może mieć prawa do modyfikacji struktur tabel, inna może wykonać kopię zapasową, a jeszcze inna jest zwykłym użytkownikiem, który może tylko czytać dane).

Użytkownik przy wysyłaniu żądania przyporządkowywany jest przez Authorization Manager do jednej z ról, a następnie aplikacja widzi dane żądanie jako żądanie określonej „roli”.

Największą zaletą tego systemu autoryzacji jest jego elastyczność, gdyż tak naprawdę przynależność do roli może zależeć od wielu czynników i mogą być dowolnie konfigurowane przez administratora. Podstawowe składniki Authorization Manager to:

• Centralna składnica – miejsce przechowywania definicji ról, zasad przypisania, zadań oraz operacji.
• Zadania – kolekcja operacji (lub innych zadań) wymaganych do wykonania określonej czynności, która ma znaczenie dla administratora (np. czynności wymagane do złożenia zamówienia).
• Zakres – kolekcja zadań, które mają wspólny zakres uprawnień (takie same wymagania dotyczące autoryzacji).
• Role – zestaw uprawnień do wykonania danej czynności. Rola jest przypisywana do zestawu obiektów.
• Podstawowe grupy – pozwalające przypisać określonego użytkownika lub grupę do roli.
• Dynamiczne grupy – w momencie badania przynależności do grupy wykonywane jest odpowiednie zapytanie LDAP, które może dotyczyć pewnych atrybutów danego klienta zdefiniowanych w katalogu. Na przykład można określić, że w określonych godzinach prawo do składania zamówień mają ci, których tytuł to manager, lub mają określony staż pracy. Można określić maksymalny czas wykonywania kwerendy.
• Skrypty (nazywane BizRules) – są to skrypty związane z danym zadaniem. Do jednego zadania może być dołączony najwyżej jeden skrypt. Jest on wykonywany w momencie, gdy zachodzi potrzeba podjęcia decyzji. BizRules jest skryptem VBScript lub JScript. Jeżeli operacja wykonania skryptu zakończy się sukcesem, użytkownik może wykonać zadanie, z którym związany jest BizRule. Warto dodać, że w Authentication Manager można określić sposób zachowania się systemu, gdy skrypt jest nieprawidłowo lub błędnie napisany. Można określić np. maksymalny czas oczekiwania na zakończenie wykonywania skryptu.

Dzięki mechanizmowi autoryzacji opartej na rolach w Windows Server 2003 EE można w jednym miejscu mieć pełną informację o uprawnieniach użytkownika. Nie jest już konieczne, by aplikacja samodzielnie „pilnowała” uprawnień użytkownika. Wystarczy, by developer przekazał administratorowi listę zadań oraz role – a pozostałe elementy związane z ustalaniem praw dostępu można już określić na poziomie konsoli administracyjnej (z odrobiną VBScript). Wtedy rzeczywiście administrator ma kontrolę nad uprawnieniami użytkownika.

Definiowanie autoryzacji opartych na rolach

Standardowo, podczas instalacji Windows Server 2003 nie jest instalowany skrót do Authorization Manager (Menedżera Autoryzacji). Aby go dodać, należy:

1. Uruchomić konsolę administracyjną w trybie edycji (Start – Uruchom i wpisać mmc.exe /a).
2. Wejść w Plik – Dodaj/Usuń przystawkę (lub nacisnąć CTRL-M).
3. Po otworzeniu się okna Dodaj/Usuń przystawkę kliknąć przycisk Dodaj i z listy wybrać Menedżer autoryzacji.
4. Zamknąć okno.

W tym momencie został zdefiniowany nowy zestaw konsoli administracyjnej, w którym wczytany jest zatrzask odpowiedzialny za konfigurację Authorization Manager. W kolejnych krokach można zdefiniować aplikację, jej zestaw „uprawnień” itp. Sama definicja zasad obsługi ról może być zapisana jako obiekt w Active Directory lub jako dowolny plik XML. Menedżer autoryzacji ma dwa tryby pracy: jeden, developerski, pozwala definiować grupy, aplikacje itp., Drugi, administracyjny przeznaczony jest do definicji uprawnień w konkretnym działającym środowisku.

Polisy

W Windows 2003 rozbudowane zostały możliwości tworzenia tzw. polis bezpieczeństwa. Dzięki nim administrator określa zestaw uprawnień obowiązujących w danej sieci. Dzięki mechanizmowi dystrybucji, polisy (czyli – zasady bezpieczeństwa) są dystrybuowane na każdy z komputerów w sieci.

Polisa jest zbiorem zasad określających ogólne uprawnienia komputera pełniącego określoną rolę w domenie czy też prawa użytkownika. Określane są zasady postępowania z hasłami (minimalna długość, po jakim czasie hasło musi zostać zmienione itp.), w jakich warunkach konto jest blokowane, dokładne mechanizmy dystrybucji informacji w Kerberos czy zasady audytu.

Polisy mogą obowiązywać na lokalnym komputerze jak i na komputerach wykorzystującą usługę katalogową. Mechanizm ustawiania polis oraz zakres elementów jest bardzo podobny – w zależności od tego, gdzie polisa ma obowiązywać, należy otworzyć odpowiednią konsolę MMC – Ustawienia zabezpieczeń lokalnych, Ustawienia zabezpieczeń domeny lub Ustawienia zabezpieczeń kontrolera domeny.

Wraz z instalacją Windows Server 2003, instalowane są wzorcowe „zestawy” polis – które określają standardowe zabezpieczenia w zależności od tego, jaką rolę ma pełnić dany serwer czy stacja robocza. Także administrator może opracowywać nowe wzorce a następnie dystrybuować je w sieci, tak by w firmie obowiązywała wspólna polityka bezpieczeństwa.

Główne narzędzia do konfiguracji bezpieczeństwa stanowią tzw. pakiet do zarządzania i konfiguracji bezpieczeństwa (ang. Security Confguration Manager). Mogą one służyć do automatyzacji wielu zadań związanych z bezpieczeństwem.

Narzędzia do konfiguracji bezpieczeństwa

Nowym elementem w Windows Server 2003 jest możliwość dokładnego określania zestawu aplikacji, jakie mogą być uruchamiane – czy to na stacjach roboczych, czy to na serwerach.

Prawa do uruchomiania aplikacji

W Windows Server 2003 można na poziomie polis ustalać prawa do uruchamiania (dotyczy to zwłaszcza serwerów 2003 oraz stacji roboczych działających pod kontrolą Windows XP).

Używając ustawień zabezpieczeń (czy to lokalnych, czy też na poziomie katalogu) można:

• ograniczyć uruchamianie nieznanych programów (w tym – wirusów),
• określić, jakiego typu komponenty ActiveX mogą być ściągane i uruchamiane na komputerze,
• wymóc, by można było uruchamiać tylko skrypty podpisane cyfrowo.

Można na przykład wskazać określony katalog, z którego można (lub nie) uruchamiać programy. Mogą to być udziały sieciowe, lub dyski lokalne. Administrator określając ścieżkę może używać zmiennych systemowych, oraz znaków wieloznacznych.

Można także wskazać konkretny plik EXE czy DLL. Wtedy, Windows Server 2003 policzy klucz mieszający (ang. hash) który identyfikuje np. plik EXE czy DLL. Następnie przy użyciu tego klucza badane jest czy uruchamiany program pasuje do wzorca – i w zależności od uprawnień dana aplikacja jest uruchamiana lub też nie.

Wreszcie – można wskazać dowolny certyfikat używany do podpisywania kodu (lub – skryptów), po czym wskazać, że np. tylko elementy podpisane danym kluczem będą mogły być uruchamiane na konkretnym serwerze (czy stacji roboczej).

Jeszcze bardziej wyrafinowane możliwości kontroli ma administrator w przypadku, gdy na serwerze uruchamiane są komponenty .NET (np. witryna ASP.NET). Można określać prawa przypisywane poszczególnym pakietom podpisanym danym kluczem kryptograficznym. Na przykład można określić, że kod podpisany kluczem A ma tylko prawo do odczytu określonych katalogów na dysku, a np. kod podpisany kluczem B – ma nieograniczone możliwości. Jeżeli kod .NET próbuje przekroczyć przypisane uprawnienia (czy to w wyniku błędu, czy świadomego działania programisty), nie będzie mógł tego wykonać, a administrator zostanie poinformowany o próbie przekroczenia uprawnień. W przypadku .NET administrator dokładnie określa, kto może napisać kod uprawniony do wykonywania określonych operacji na serwerze Windows Server 2003.

Zasady bezpieczeństwa i audyt

Mówiąc o bezpieczeństwie nie można zapominać o konieczności stworzenia kompleksowych zasad polityki bezpieczeństwa. Bez tego nawet najlepiej zabezpieczony serwer może okazać się podatny na ataki wynikające ze złej organizacji. Równocześnie trudno jest utrzymać spójne zasady bezpieczeństwa na wielu serwerach, setkach stacji roboczych. Dodatkowo administrator musi mieć możliwość przeprowadzenia audytu – czyli móc określić sposób wykorzystania zasobów serwera.

Dzięki audytowi, administrator (czy – oficer bezpieczeństwa) może na bieżąco analizować potencjalne problemy związane z naruszeniem bezpieczeństwa – oraz z wyprzedzeniem reagować na problemy zgłaszane przez użytkowników. Jednak – przy audycie należy bardzo uważnie zaplanować, jakie elementy będą analizowane. Do często rejestrowanych zdarzeń, należą np. zdarzenie zalogowania oraz wylogowania użytkowników z systemów, czy próby dostępu do określonych zasobów.

Warto także pamiętać, że trudno efektywnie zarządzać prawami dostępu użytkowników, oraz zasadami autoryzacji bez mechanizmu usług katalogowych. Dzięki Active Direcory administrator ma do dyspozycji potężne narzędzie które pozwala mu definiować dowolne relacje związane z bezpieczeństwem, tworzyć grupy użytkowników czy nawet delegować uprawnienia do wykonywania określonych czynności. Active Directory przechowuje nie tylko informacje niezbędne do „logowania się” użytkownika, ale także uprawnienia do wykonywania odpowiednich operacji.

Analiza zabezpieczeń

Ważnym narzędziem jest mechanizm automatycznego sprawdzania bezpieczeństwa systemu. Dostępne jest specjalne narzędzie Konfiguracja i analiza zabezpieczeń, które potrafi zbadać, czy na pewno aktualne ustawienia odpowiadają założeniom. Często się zdarza tak, że administrator chcąc „natychmiast” rozwiązać problem niepotrzebnie zwiększa uprawnienia obniżając poziom bezpieczeństwa danego komputera. Po wykonaniu niezbędnych napraw zwykle zapomina ponownie podwyższyć poziom bezpieczeństwa lub zmniejszyć uprawnienia użytkownika czy komputera. W konsekwencji w całym systemie IT pojawi się dziura.

Dzięki temu narzędziu administrator może szybko analizować poszczególne maszyny i wykrywać potencjalne luki w bezpieczeństwie. Zalecane operacje są bardzo czytelnie prezentowane na ekranie. Można niemal od razu wykonać dane czynności i zabezpieczyć system.

Równocześnie narzędzie Konfiguracja i analiza zabezpieczeń może być wykorzystywane także jako dodatkowe narzędzie do automatycznego konfigurowania lokalnego komputera – tutaj można definiować „wzorcowe” ustawienia i nakładać je na wybrane maszyny. Obsługa tego programu sprowadza się do wyboru odpowiedniej bazy danych z wzorcowymi zabezpieczeniami (lub – stworzenia nowej bazy). Następnie można albo wymusić konfigurację danej maszyny zgodnie z założeniami, albo też zażądać wygenerowania raportu pokazującego, które elementy konfiguracji odbiegają od przyjętych wymagań.

Przykład – konfiguracja audytu

Przed konfiguracją audytu, należy upewnić się, że rejestrowane zdarzenia będą w odpowiedni sposób przechowywane. Wybierając menu podręczne w podglądzie zdarzeń systemowych, można ustawić wielkość dziennika, oraz co się będzie działo w momencie, gdy dziennik zostanie przepełniony.

Nie ma uniwersalnych zasad ustalania wielkości plików dziennika. Administrator musi dobrać taką wielkość, która będzie współgrała z założonym obciążeniem oraz liczbą rejestrowanych zdarzeń.

Same elementy które mają być rejestrowane (elementy audytu) można określać razem z określaniem zasad zabezpieczeń w polisach. Można podać, czy rejestrowane mają być zdarzenia zakończone sukcesem, czy też takie, w których żądanie zostało odrzucone (np. – błędne podanie hasła przy logowaniu).

W Windows Server 2003 audyt można ustawiać także na poziomie poszczególnych obiektów wchodzących w skład katalogu Active Directory. Może to być także udział sieciowy – czy dowolny folder (znajdujący się na partycji NTFS). W takim przypadku, konfigurując audyt (inspekcję) obiektu, należy określić:

• jakiego użytkownika (lub grupy) dotyczy analiza,
• jakie operacje związane z danym obiektem mają być rejestrowane.

EFS – szyfrowany system plików

Pisząc o bezpieczeństwie nie można zapomnieć o rewelacyjnym systemie szyfrowania plików. Dzięki temu użytkownik ma pewność, że tylko on może odczytać dany plik – niezależnie od tego, czy jest to plik znajdujący się na serwerze plików, czy zareplikowany na jego stację roboczą.

Aby uaktywnić szyfrowanie plików, wystarczy zaznaczyć jeden dodatkowy atrybut w pliku lub w katalogu. Jednak warto pamiętać, że zaszyfrowane pliki są deszyfrowane w momencie, gdy odczytuje je osoba o odpowiednich uprawnieniach. Tak więc w sieci przesyłany jest niezaszyfrowany plik. Aby zapewnić danym bezpieczny transport, trzeba wykorzystać jedną z możliwości szyfrowania transmisji w Windows Server 2003 – protokół IPSec oraz kodowanie PPTP.

Uważny administrator bezpieczeństwa od razu zauważy, że w kilku przypadkach takie szyfrowanie plików może być niebezpieczne dla całego przedsiębiorstwa. Użytkownik może zgubić lub skasować swój klucz prywatny, (który pozwala na odszyfrowanie pliku), może także zmienić pracę nie udostępniając swoich plików innym pracownikom. Aby zabezpieczyć system przed takimi sytuacjami, w Windows Server 2003 można zdefiniować rolę „agenta odzyskiwania” Jest to specjalny użytkownik, który ma prawo odszyfrować dowolny plik w ramach danej domeny. W polityce bezpieczeństwa trzeba określić bezpieczny sposób postępowania z „agentami odzyskiwania”; można w Polisie Grupowej (Group Policy) definiować np. większą liczbę agentów odzyskiwania, co zapewni dodatkowy sposób odzyskania danych przedsiębiorstwa.

Przykład - tworzenie agenta bezpieczeństwa

Sposób dodawania agenta bezpieczeństwa, mającego prawo odzyskiwania plików zależy od tego, czy jest już skonfigurowany katalog Active Directory. Aby dodać takiego agenta do domeny Active Directory, należy:

1. Otworzyć Użytkownicy i Komputery usługi katalogowej (element znajduje się w narzędziach administracyjnych).
2. Wybrać Właściwości z menu podręcznego dla tej domeny, gdzie agent ma być utworzony.
3. Wejść na zakładkę Polisy grupowe.
4. Wybrać jedną z polis (która ma zostać zmieniona), a następnie kliknąć na przycisk Edytuj.
5. Otworzony zostanie nowe okno, z listą elementów które można ustawiać w ramach polis GPO.
6. W gałęzi EFS kliknąć prawym przyciskiem i albo dodać istniejącego agenta bezpieczeństwa, albo – utworzyć nowego. Domyślnie administrator jest agentem bezpieczeństwa.

Warto tu podkreślić, że mechanizm tworzenia agentów odzyskiwania wykorzystuje mechanizm PKI (usługi certyfikacyjne) dostępne w Windows Server 2003. Po utworzeniu agenta bezpieczeństwa, warto wyeksportować certyfikat związany z tym użytkownikiem i umieścić go w bezpiecznym miejscu – tak by w razie awarii można było odzyskać pliki.

Jeżeli agent bezpieczeństwa jest dodawany z poziomu katalogu, wtedy odpowiedni certyfikat musi być opublikowany w usłudze katalogowej. Domyślny wzorzec certyfikatu do odzyskiwania EFS nie ma włączonej tej opcji – należy samemu zmodyfikować nowy wzorzec (np. kopiując istniejący) i zmienić wartość w Publikuj certyfikat w usłudze katalogowej.

W przypadku gdy domeny nie ma, należy otworzyć Ustawienia zabezpieczeń lokalnych (pozycja znajduje się w menu Narzędzia administracyjne). Następnie rozwinąć Zasady kluczy publicznych, i z menu podręcznego wybrać pozycję Dodaj agenta odzyskiwania danych.

Następnie należy wskazać użytkownika oraz jego certyfikat (który może być wygenerowany przez dowolnego wystawcę certyfikatów, ale także przez firmowy serwer certyfikatów).

Obiekty polis grupowych (GPO)

Polisy grupowe (Group Policy) udostępniają administratorom mechanizmy bardzo szczegółowej kontroli systemów wykorzystujących Windows. Pozwalają z wyprzedzeniem ustalać zasady polis bezpieczeństwa – na różnym poziomie infrastruktury IT – praw użytkowników czy konfiguracji maszyn. Równocześnie GPO doskonale współgrają ze strukturą katalogu – można określać zasady obowiązywania polis w dowolnym węźle drzewa (tak by były aktywne dla wszystkich podrzędnych elementów).

A wszystkie te operacje mogą być wykonane za pośrednictwem wygodnego interfejsu użytkownika – GPMC (Group Policy Management Console). GPMC pozwala użytkownikom skupić się na efektywnym zarządzaniu przy użyciu GPO bez poszukiwania właściwego narzędzia do wykonania określonej operacji administracyjnej. Można powiedzieć, że praktycznie GPMC jest „centralnym” punktem zarządzania polisami grupowymi.

GPMC pozwala tworzyć kopie zapasowe polis (i odtwarzać je w razie potrzeby). Administrator może kopiować i wklejać obiekty GPO (polisy), może też dowolnie tworzyć filtry WMI, które np. ograniczają wyświetlane obiekty Active Directory. Skrypty WMI mogą być zapisywane, wczytywane z plików czy też „przeklejane” pomiędzy różnymi oknami GPMC.

Dzięki GPMC można generować szczegółowe raporty zabezpieczeń – na przykład można podejrzeć ostateczne ustawienia polis dla danego elementu (Resultant Set of Policy, RSoP). Można na to patrzeć jak na mechanizm analogiczny do podglądu efektywnych ustawień praw dostępu do plików, jednak RSoP pokazuje wszystkie ustawienia wynikające z nakładania się różnych obiektów GPO w danym elemencie drzewa Active Directory. Administrator może w ten sposób sprawdzić, jakie prawa ostatecznie będzie miał dany użytkownik czy komputer. Raporty w HTML można także wykorzystać jako narzędzie, które pozwoli sprawdzić, czy np. ustawienia praw i polis są spójne i odpowiadają założeniom polityki bezpieczeństwa.

GPMC – oprócz tego, że pozwala łatwo ustawiać prawa polis GPO czy podglądać efektywne ustawienia na dowolnym poziomie drzewa Active Directory – zawiera moduł symulacji „co by było, gdyby ustawić takie a nie inne parametry bezpieczeństwa”. Po takiej symulacji można wygenerować analogiczne raporty jak dla „realnych” ustawień bezpieczeństwa. Jest to nieoceniona pomoc dla administratorów, którzy planują zmiany w obiektach w Active Directory.

Zarządzanie polisami GPMC może obejmować zarówno domeny Windows 2000, jak i Windows Server 2003.

Podstawowym składnikiem GPMC jest widok domen. Jest to nazwa domeny (nazwa DNS) w ramach „lasu”. Użytkownik może wybierać domenę, która ma być wyświetlona na konsoli. Obiekty GPO nie są dziedziczone pomiędzy domenami – można jednak definiować zasady migracji obiektów GPO.

Po wybraniu jednej domeny administrator widzi składniki danego drzewa Active Directory. Sites to węzły, które odpowiadają podstawowym sites w drzewie. Po kliknięciu prawym przyciskiem tego węzła i wybraniu „Show Sites”, wyświetlane są składowe danej domeny. Tak samo zachowują się inne węzły drzewa – administrator musi jawnie wskazać, który obiekt ma być rozwinięty. W ten sposób w interfejsie użytkownika pobierane są tylko te elementy z drzewa AD, które są niezbędne do pracy administratorowi.

Element modelowania grupowych polis (Group Policy Modeling) pozwala na dostęp do części testowej Resultant Set of Policy (RSoP). Tam administrator może zasymulować nałożenie konkretnego obiektu GPO na dany składnik Active Directory. Jest to bardzo wygodny mechanizm do planowania – jest on dostępny tylko w drzewach Windows Server 2003 (ale nie w drzewach Windows 2000 lub działających w trybie zgodności z Windows 2000).

Drugim elementem związanym z RSoP jest „Group Policy Result”. Jest to mechanizm, który pozwala podejrzeć aktywny zestaw polis nałożony na danego użytkownika i komputer. Informacje jest pobierana bezpośrednio z docelowego komputera. Interfejsy Group Policy Modeling oraz Group Policy Result są bardzo podobne. Group Policy Result może być odczytywany tylko z komputerów wyposażonych w Windows XP lub w Windows Server 2003.

Jednym z ciekawszych zastosowań, jakie można zrealizować przy użyciu GPO, jest synchronizacja domen. Microsoft Group Policy Management Console (GPMC) potrafi kopiować obiekty GPO z jednej domeny do innej. Dzięki temu można np. synchronizować domenę produkcyjną z domeną testową.

• Wprowadzenie
• Autoryzacja
• Typy autoryzacji
• Kontrola oparta na liście praw dostępu
• Prawa
• Własność obiektu
• Dziedziczenie uprawnień
• Łańcuch uprawnień
• Przykład - praca z uprawnieniami
• Autoryzacja oparta na rolach
• Kontrola oparta na obiektach
• Kontrola oparta na rolach
• Definiowanie autoryzacji opartych na rolach
• Polisy
• Prawa do uruchomiania aplikacji
• Zasady bezpieczeństwa i audyt
• Analiza zabezpieczeń
• Przykład – konfiguracja audytu
• EFS – szyfrowany system plików
• Przykład - tworzenie agenta bezpieczeństwa
• Obiekty polis grupowych (GPO)

Pobierz dokument w formacie Microsoft Word (576 KB, 25 stron)