Administrator i programista - zgodne zarządzanie uprawnieniami

Prawa dostępu w systemie Windows 2003 oparte są na tzw. listach DACL - czyli takich listach, gdzie każdy użytkownik lub grupa mają przypisane odpowiednie uprawnienia.

Prawa dostępu w systemie Windows 2003 oparte są na tzw. listach DACL - czyli takich listach, gdzie każdy użytkownik lub grupa mają przypisane odpowiednie uprawnienia.

Każdy autoryzowany użytkownik, czy grupa ma swój unikatowy identyfikator (SID), tworzony razem z danym obiektem (np. kontem użytkownika). Prawa na liście DACL powiązane są właśnie z tym numerem SID.

Samą kontrolą praw zajmuje się ważny element jądra Windows Server 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 uprawnień w Active Directory określona grupa użytkowników może uzyskać dostęp do wybranego podzbioru informacji, np. zapewniając poufność adresu czy ogólnie - danych osobowych.

W przypadku, gdy na serwerze ma działać określona aplikacja, a użytkownik "loguje się" na serwer (zwykle do domeny) wtedy każda uruchomiona przez niego aplikacja może wykonywać tylko te operacje, które wynikają z uprawnień danego użytkownika.

Wykorzystuje to np. Exchange Server czy Microsoft SQL Server, pracujący w tzw. trybie zintegrowanym, gdzie użytkownik nie loguje się oddzielnie do serwera, tylko przekazywany jest tzw. żeton bezpieczeństwa do danej aplikacji i tam w zależności od ustawień zalogowany użytkownik jest lub nie jest "wpuszczany".

Jednak taki sposób autoryzacji zakłada współpracę pomiędzy programistą - autorem danego programu - a administratorem, który przypisuje prawa w danym środowisku. I często, niestety, kończy się tak (zwłaszcza w małych sieciach), że użytkownik ma prawa administratora, bo inaczej "program nie chce działać".

Drugi problem wynika stąd, że są to uprawnienia statyczne - na zasadzie, że użytkownik ma (lub nie) dostęp do danego obiektu w systemie operacyjnym. Czasem można ustalać dodatkowe ograniczenia - np. dozwolone godziny logowania. Jednak w większości obecnych aplikacji łańcuch uprawnień jest znacznie bardziej rozbudowany - i z tego powodu dysponują one zupełnie "oddzielnym" systemem uprawnień. W takiej sytuacji administrator stoi przed trudnym zadaniem: nie tylko musi przypisać właściwe uprawnienia w sieci, ale jeszcze dodatkowo określić prawa w danej aplikacji, zgodnie z mglistymi zazwyczaj zaleceniami autorów programu.

Windows Authorization Manager służy do definiowania ról.

Windows Authorization Manager służy do definiowania ról.

W Windows Server 2003 jest to znacznie prostsze dzięki specjalnemu programowi pozwalającemu definiować "role" i związywać je z określonymi użytkownikami, grupami czy innymi obiektami bezpieczeństwa. Authorization Manager pozwala, żeby programista po swojej stronie (w aplikacji) badał, czy użytkownik "należy" do określonej roli (i jeżeli tak - odblokowywał daną funkcjonalność programu). Dodatkowo zasada "przynależności" do roli może być dynamiczna. Jeżeli wystawianie faktur nie może się odbywać ostatniego dnia miesiąca, wystarczy tak określić rolę, aby wszyscy użytkownicy w danym okresie czasu byli "wykluczeni". A aplikacja tylko bada, pytając Authorization Manager, czy aktualnie zalogowany użytkownik należy (w danym momencie) do danej grupy "fakturzystka".

Ma to jeszcze jedną zaletę - definicja roli znajduje się poza programem. To administrator definiuje zasady przynależności (przy użyciu specjalnego narzędzia - zatrzasku MMC). Tak więc jeżeli się okaże, że trzeba zmienić zasadę - zakazując wystawiania faktur w dodatkowe dni - wystarczy zmienić sposób opisu roli, niczego nie zmieniając w aplikacji.

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: deweloperski, który pozwala definiować grupy, aplikacje itp., oraz administracyjny, przeznaczony do definiowania uprawnień w konkretnym działającym środowisku.

Definiując role, można wykorzystać wiele różnych metod. Można użyć tzw. podstawowej grupy (statycznej) gdzie definiowana jest po prostu liczba użytkowników (lub grup) którzy należą do danej grupy.

Rola może być też zdefiniowana przy użyciu zapytania LDAP (analizującego zawartość Active Directory). Wtedy na przykład można zdefiniować tak rolę, że maksymalna wysokość zamówienia wystawianego przez danego pracownika zależy od stażu pracy (a staż pracy pobierany jest ze struktur AD przy użyciu zapytania LDAP).

Wreszcie w celu określenia przynależności do roli można wykorzystać skrypty (JScript lub VBScript). W takim przypadku nic nie ogranicza administratora - korzysta z pełnych możliwości, jakie daje określony język.

Aby ułatwić sobie pracę, administrator może także definiować zadania - czyli zbiór operacji wymaganych do wykonania określonej czynności - oraz zakresy - czyli zbiory zadań, które mają wspólny zakres uprawnień. Wykorzystując te obiekty, może w prostszy sposób manipulować rolami.

Dzięki mechanizmowi autoryzacji pisanie aplikacji i ich wdrażanie jest znacznie prostsze. Wystarczy, żeby developer przekazał administratorowi listę zadań oraz role, które analizuje w swojej aplikacji - a pozostałe elementy związane z ustalaniem praw dostępu można już określić na poziomie konsoli administracyjnej (z odrobiną VBScriptu). Wtedy rzeczywiście administrator ma kontrolę nad uprawnieniami użytkownika.


Zobacz również