Wykonał Rafał Zaród

Microsoft w Windows 2003 Server 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 2003 Server 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 2003 Server – może tylko czytać z danego udziału. Na bezpieczeństwo w Windows 2003 Server 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 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 2003 Server obsługuje także smart card czy inne mechanizmy przekazywania informacji do autoryzacji. Smart Card (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 2003 Serwer). Smart Card 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 2003 Serwer 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 2003 Server 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 2003 Server i np. pozwalają przeglądać zasoby Active Directory.

W ramach usługi katalogowej Active Directory, Zasady grupy ustalają i kontrolują Zasady kont dla całej domeny. Dzieje się to podczas początkowej instalacji domeny usługi katalogowej Active Directory i jest osiągane dzięki domyślnemu obiektowi zasad grupy (obiekt GPO) połączonemu z węzłem domeny w usłudze katalogowej Active Directory. Ten obiekt GPO o nazwie Domyślne zasady domeny posiada domyślną konfigurację dla wszystkich trzech sekcji Zasad kont. Rys. 2. przedstawia kompletną listę początkowych ustawień dla elementów Zasad haseł w domenie Windows Server 2003.

Ustawienia w tym obiekcie GPO kontrolują Zasady kont dla wszystkich kont użytkowników domen, jak również dla każdego komputera w domenie. Ważne jest, aby pamiętać, że wszystkie komputery domeny (komputery stacjonarne i serwery) posiadają menedżera kont zabezpieczeń (Security Accounts Manager – SAM). Menedżer ten jest kontrolowany przez ustawienia w domyślnym obiekcie GPO. Oczywiście lokalne menedżery SAM zawierają także konta lokalnych użytkowników dla odpowiednich komputerów. Ustawienia w domyślnych zasadach domeny mają wpływ na wszystkie komputery domeny za sprawą zwyczajnego dziedziczenia obiektu GPO w strukturze usługi katalogowej Active Directory. Ponieważ obiekt GPO jest połączony z węzłem domeny, ma on wpływ na wszystkie konta komputerów w domenie.

 Udostępnianie plików realizowane jest przez systemową usługę Server. Zatrzymanie tej usługi sprawi, że dane nie będą dostępne, co może mieć zarówno pozytywne jak i negatywne konsekwencje. Wewnętrznie, usługa Server nazywa się LanmanServer i można ją "obejrzeć" poleceniem sc.exe query LanmanServer.  Listę udziałów sieciowych można wyświetlić poleceniem "net share". Można też zapytać przez WMI, używając klasy Win32_Share w PowerShellu, WMIC albo w aplikacji.  Listę otwartych przez udziały plików można wyświetlić poleceniem "net file". Polecenia tego można również użyć do wymuszenia zamknięcia otwartego pliku, ale należy liczyć się z tym, że użytkownik może nie być z tego powodu szczęśliwy zwłaszcza, gdy utraci niezapisane dane.  Udostępnianie plików wykorzystuje protokół CIFS, który jest dialektem protokołu SMB. Dla chcących pogrzebać w specyfikacji, Microsoft udostępnił odpowienie zasoby. Protokół ten został na przestrzeni lat znacząco usprawniony. Od czasów Windows Vista / Windows Server 2008 działa naprawdę wydajnie i nazywany jest SMB2.  Domyślnie, udostępniane są wszystkie dyski (C$, D$...) i folder z systemem Windows (ADMIN$). Są to specjalne udziały z dostępem tylko dla administratorów. Technicznie możliwe jest ich wyłączenie, jednak w wielu przypadkach może to spowodować kłopoty z działaniem różnych narzędzi do zdalnego zarządzania czy zdalnej instalacji  Znak dolara ($) na końcu nazwy udziału oznacza, że serwer nie "chwali się" takim udziałem w sieci. Udział działa normalnie, ale póki ktoś nie wie jak się nazywa, to go nie zobaczy. Przydaje się to do porządkowania widoków dla użytkowników, jednak nie powinno być traktowane jako skuteczne zabezpieczenie przed nieautoryzowanym dostępem.

 Serwer plików publikuje swoje zasoby pod własną nazwą i pod swoim adresem IP. Zrobienie aliasu (na przykład przez utworzenie rekordu CNAME w DNS) wcale nie sprawi, że do serwera będzie można sięgnąć w ten sposób. Zachowanie takie jest możliwe do zmiany przy pomocy parametru DisableStrictNameChecking opisanego w KB  Jeżeli pliki udostępnia klaster, powyższe ustawienie nie będzie działać i dostęp możliwy jest tylko przez zarejestrowane w klastrze nazwy.  Jeżeli ktoś chce przenieść całą strukturę plików i udziałów na nowy serwer, może użyć narzędzia FSMT udostępnianego bezpłatnie przez Microsoft.  Aby usługa Server "wiedziała" które foldery udostępnić i na jakich zasadach, sięga do swojej bazy danych zapisanej w rejestrze, w kluczu Services\LanmanServer\Shares. Można ten klucz zapisywać i odtwarzać, jednak poza ścieżkami zawiera on na przykład dane o uprawnieniach i ręczna edycja jego zawartości jest ryzykowna.  Inne obecne w gałęzi Services\LanmanServer parametry opisane są(choć dość pobieżnie i bardzo nieaktualnie) na stronach TechNet.  Na udziale można założyć ograniczenie liczby równoczesnych połączeń oraz ustawić prawa. Ustawianie praw na udziałach ma swoich zwolenników i przeciwników. Jeżeli ktoś nie ma bardzo silnych argumentów za taką konfiguracją, to mocno zachęcam do zrezygnowania z ustawiania uprawnień na udziale i korzystania z uprawnień na plikach i folderach. Są znacznie trudniejsze do przypadkowego ominięcia w codziennym sieciowym bałaganie.  Używanie adresów IP zamiast nazw serwerów plików to proszenie się o kłopoty. Jeżeli tylko DNS działa poprawnie, użycie nazw znacząco uprości przyszłe zmiany. Jeszcze większą elastyczność da zastosowanie DFS.

 Serwer plików pozwala (przy pomocy wbudowanych mechanizmów audytu) na zapisywanie kto, kiedy, do czego i po co sięgnął. Należy tylko zdawać sobie sprawę, że nie pozostanie to bez wpływu na wydajność serwera. Domyślnie funkcjonalność ta jest wyłączona.  Nie da się utworzyć udziałów o nazwie "pipe" ani "mailslot". Wynika to z faktu, że takimi nazwami usługa serwer posługuje się przy specjalnych trybach komunikacji.  Udziały na dyskach klastra traktowane są w specjalny sposób, choć w nowszych systemach do zarządzania nimi służą te same API. Nie da się jednak utworzyć udziałów na wolumenach CSV.

Najpierw trzeba zdecydować na jakim serwerze ma być utworzony folder: Function CreateHomeFolder { Param($userinfo) $server1 = 'a','b','c','d' $server2 = 'e','f','g','h' Switch ($userinfo['samAccountName']. substring(0,1).tolower()) { { $server1 –contains $_ } { $homeserver = '\\homeserver1\'; break; } { $server2 –contains $_ } { $homeserver = '\\homeserver2\'; break; } }

Teraz trzeba pozwolić PowerShell utworzyć folder: Function CreateHomeFolder { Param($userinfo) $server1 = 'a','b','c','d' $server2 = 'e','f','g','h' Switch ($userinfo['samAccountName']. substring(0,1).tolower()) { { $server1 –contains $_ } { $homeserver = '\\homeserver1\'; break; } { $server2 –contains $_ } { $homeserver = '\\homeserver2\'; break; } } Mkdir ($homeserver + '\$Homes\' + $userinfo['samAccountName']) }

 Polecenie MkDir – które w rzeczywistości jest wbudowaną funkcją wykorzystującą polecenie cmdlet New-Item – akceptuje ścieżki UNC. Tak więc wystarczy połączyć ustaloną wcześniej nazwę serwera z nazwą udziału administracyjnego $Homes oraz atrybutem samAccountName użytkownika. Jeśli nazwą logowania (samAccountName) jest DonJ, polecenie MkDir utworzy folder \\server1\$Homes\DonJ.

 Uprawnienia definiują typ dostępu udzielanego użytkownikom lub grupom do obiektu lub właściwości obiektu. Na przykład grupie Finanse można udzielić uprawnień Odczyt i zapis do pliku wynagrodzenia.dat.  Za pomocą interfejsu użytkownika kontroli dostępu można ustawiać uprawnienia NTFS dla takich obiektów, jak pliki, obiekty usługi Active Directory, obiekty rejestru lub obiekty systemowe, np. procesy. Uprawnień można udzielić dowolnemu użytkownikowi, grupie lub komputerowi. Dobrym rozwiązaniem jest przypisanie uprawnień do grup, co zwiększa wydajność systemu podczas weryfikacji dostępu do obiektu.  Do każdego obiektu można udzielić uprawnień:  Grupom, użytkownikom i innym obiektom mającym identyfikatory zabezpieczeń w domenie.  Grupom i użytkownikom z domeny oraz z innych zaufanych domen.  Grupom i użytkownikom lokalnym, utworzonym na komputerze, na którym znajduje się dany obiekt.

 Uprawnienia przyłączone do obiektu zależą od typu obiektu. Na przykład uprawnienia, które można przyłączyć do pliku, różnią się od uprawnień, które można przyłączyć do klucza rejestru. Jednak niektóre uprawnienia są wspólne dla większości typów obiektów. Tymi wspólnymi uprawnieniami są:  Odczyt  Modyfikowanie  Zmiana właściciela  Usuwanie  Podczas ustawiania uprawnień określany jest poziom dostępu dla grup i użytkowników. Na przykład jednemu użytkownikowi można pozwolić na odczytywanie zawartości pliku, drugiemu użytkownikowi na wprowadzanie zmian do tego pliku, a wszystkim innym użytkownikom zabronić dostępu do tego pliku. Podobne uprawnienia można ustawiać w odniesieniu do drukarek, tak aby określeni użytkownicy mogli konfigurować drukarkę, a inni mogli tylko na niej drukować.  Aby zmienić uprawnienia do pliku, należy uruchomić Eksploratora Windows, kliknąć prawym przyciskiem myszy nazwę pliku, a następnie kliknąć polecenie Właściwości. Na karcie Zabezpieczenia można zmienić uprawnienia do pliku. Aby uzyskać więcej informacji, zobacz temat Zarządzanie uprawnieniami.