NOVELL2(4).DOC

5. Opisz obiekty sieci i ich własności

W Novell-u mamy do czynienia z bazą danych o charakterze obiektowym, dodatkowo jeszcze uporządkowaną hierarchicznie, którą dla uproszczenia będziemy w dalszej części rozważań określać jako bazę NDS (od angielskiego sformułowania NetWare Directory Services) lub krótko NDS. Baza ta została tak pomyślana przez twórców systemu, by w sposób możliwie precyzyjny i zrozumiały opisać logikę działania systemu komputerowego sieciowego, zaimplementowa­nego w rzeczywistych warunkach. Jakie są te "rzeczywiste warunki"? Odpowiedź jest prosta. Prawie zawsze instalacja sieci komputerowej odbywa się po to, by zautomatyzować obieg informacji w jakiejś instytucji (firmie) lub jej części, a czasem proces ten rozciąga się na kilka nierzadko oddalonych geograficznie instytucji. W każdym przypadku ważne jest, by informacja była bezpieczna i zawsze dostępna właściwym zainteresowanym, a więc właściwie uporządkowana i chroniona. Postulaty te wydaje się spełniać NDS. Po pierwsze, nawet w przypadku komputeryzacji bardzo dużej instytucji, baza NDS odzwierciedla jej kształt organizacyjny (jasno widać strukturę organizacyjną firmy, miejsce pracy poszcze­gólnych zatrudnionych - tutaj użytkowników systemu, a także rozmieszczenie ważnych z punktu widzenia funkcjonalności systemu obiektów jak drukarki, serwery itp.). Po drugie - cały system podlega ścisłym regułom (prawom) dostępu jednego obiektu do drugiego, co zapewnia ochronę nie tylko przechowywanych w systemie danych, ale i zabezpieczenie obiektów NDS przed niepożądaną ingerencją ze strony innych obiektów (np. użytkowników jednego oddziału firmy w implementację struktury organizacyjnej innego oddziału). Jak wiemy cała struktura hierarchiczna posiada wspólny korzeń zwany też symbolicznie [Root]. Jest to obiekt abstrakcyjny, jakby główny kontener, w którym zawiera się cała struktura sieci. Jego znaczenie wszakże nie jest tylko symboliczne, co poznamy bliżej przy szczegółowej analizie systemu zabezpieczeń w bazie NDS. W tym głównym kontenerze zawarte, są wszelkie inne kontenery, a w nich z kolei mogą być zawarte obiekty, które nie mogą już w swojej strukturze zawierać innych obiektów, czyli tzw. liście (ang. leaf objects). Przykładowa  struktura NDS zobrazowany jest na rysunku. Mamy tutaj do czynienia z przykładową firmą SATI, której trzy działy: handlowy (SPRZEDAŻ), techniczny (TECHN) oraz księgowość (FINANSE) zostały skomputeryzowane w ten sposób, że w każdym z nich postawiono jeden serwer NetWare 4 (SSPRZ, STECH, SFIN), dostępne są woluminy tych serwerów, ponadto w każdym z nich są kolejki drukarskie i drukarki oraz pewna liczba użytkowników (pracowników) pracujących w systemie komputerowym.

Kierowaniem zadań z kolejek do drukarek zajmuje się tzw. serwer drukowania (ang. prim server) - obiekt DRUKARZ, który jest zawarty w kontenerze głównym. W tym samym kontenerze figuruje również obiekt o nazwie SZEF_WYDRUKÓW, który pełni ważną rolę, gdyż ma prawa do konfigurowania i ustalania trybu pracy elementów systemu drukarskiego (tj. obiektu DRUKARZ, wszystkich kolejek i drukarek). Jego zadanie polega między innymi na ustalaniu kolejności zadań do drukowania w kolejkach, decydowaniu, która drukarka obsługuje którą kolejkę itp. Dział techniczny posiada dwie jednostki podległe - dział obsługi klienta (SERWIS-1) i dział napraw (SERWIS-2). Oba te działy posiadają pracowników - użytkowników sieci, ale nie mają własnych serwerów, drukarek ani kolejek, gdyż korzystają z serwera, kolejek i drukarek działu technicznego (zawartych w kontenerze o jeden poziom poniżej [Root]).

                            [Root]             

                            O=SATI             

                                CN=DRUKARZ             

                            CN=SZEF WYDRUKÓW

              OU=SPRZEDAŻ              OU=TECHN              OU=FINANSE

              CN=SSPRZ              CN=STECHN              CN=SFIN

              CN=SSPRZ_SYS              CN=STECHN_SYS              CN=SFIN_SYS

              CN=DR_SPRZ              CN=DR_TECHN              CN=DR_FIN

              CN=KOL_SPRZ              CN=KOL_TECHN              CN=KOL_FIN

              CN=SPRZEDAW CA1                            CN=KSI~GOWY

              OU=SERW IS-1              OU=SERW IS-2             

                 CN=JAN                CN=JANEK             

Rysunek Schemat drzewa obiektów firmy SATI

Zgodnie z zasadami konstrukcji bazy NDS, kontenerami mogą być obiekty typu Country, oznaczone symbolem (kwalifikatorem) C, symbolizujące kraj, w którym znajduje się cały kontener oznaczony tym symbolem, dalej obiekty typu Organization oznaczone symbolem O, symbolizujące jakąś jednostkę organizacyjną, obiekty typu Organizational Unit oznaczone symbolem OU, symbolizujące oddział jednostki organizacyjnej oraz cała gama obiektów typu liść (ang. lectf objects) oznaczonych symbolem CN (ang. Common Name), z których każdy symbolizuje określony obiekt prosty (tj. nie zawierający podstruktury). Zasady hierarchicznego uporządkowania tych obiektów opisane są w poniższej tabelce:

O ile obiektów mogących posiadać strukturę jest niewiele (dokładnie cztery), to obiektów typu liść jest znacznie więcej. Obiekty organizacyjne (poza (Root i Country) mają  oczywiście związek ze strukturą organizacyjną jakiejś skomputeryzowanej instytucji, a to oznacza, że są to Organization - czyli firma (instytucja) jako taka, oraz Organizatlonal  Units - czyli jej oddziały (podległe jednostki), ułożone hierarchicznie według przyjętej  w tej instytucji zasady. Dodać należy, że w każdej strukturze NDS musi istnieć przynajmniej olę, jeden obiekt Organization, pozostałe obiekty są opcjonalne.

Obiekty typu liść są tak pomyślane, by obrazowały rozmieszczenie różnych fizycznych i logicznych elementów sieci w całej strukturze NDS. Mogą to być użytkownicy systemu komputerowego, serwery, drukarki i wiele innych.

6.Podaj pojęcie kontekstu

Pojęcie kontekstu jest nieco podobne do pojęcia ścieżki w hierarchicznej strukturze katalogów w systemie DOS. Tak jak ścieżka w DOS-ie              jasno określa, o który katalog (lub zbiór) chodzi, tak kontekst precyzuje w którym miejscu struktury NDS dany obiekt się znajduje. Wszelkie odwołania do zbioru pod systemem DOS są na pewno poprawne, jeżeli wyspecyfikowana jest pełna ścieżka dostępu do tego zbioru. Podobnie w NDS odwołanie do obiektu jest poprawne, jeżeli polega na wyspecyfikowaniu pełnego jego kontekstu (tj. "ścieżki" zawierającej listę wszystkich kontenerów dzielących dany obiekt od [Root]).              Idąc dalej z analogią struktury katalogów systemu DOS i struktury NDS warto zdefiniować pojęcie kontekstu bieżącego. Jest nim aktualna pozycja w NDS, w której znajduje się umowny "niewidzialny" wskaźnik bieżącego kontenera. Z pozycji tej bezpośrednio dostępne są inne obiekty NDS (pod warunkiem posiadania prawa dostępu do nich) zawarte w tym samym kontenerze, albo - jak mówimy - po prostu w tym samym kontekście. Wtedy, podobnie jak w systemie DOS, nie musimy odwoływać się do tych obiektów przez podanie pełnej "ścieżki" reprezentującej ich kontekst w NDS, lecz bezpośrednio poprzez nazwę. Uogólniając dalej, można stwierdzić, że tak jak w systemie DOS dopuszczalne są znane czytelnikom tzw. odwołania względne do katalogu lub zbioru (przez podanie tzw. ścieżki częściowej), tak w NDS można odwołać się do dowolnego obiektu podając częściową "ścieżkę" - listę kontenerów dzielącą dany obiekt od kontekstu bieżącego.

Ściślejsze sformułowanie zasad dostępu do obiektów NDS przedstawione będzie w następnym rozdziale podręcznika, poświęconym konwencjom syntaktycznym (czyli zasadom nazywania).

7. Konwencje syntaktyczne w NDS

Wszelkie obiekty istniejące w strukturze NDS muszą mieć swoją nazwę, albo inaczej mówiąc własność Name (ang. nazwa) musi być obowiązkowo wypełniona wartością (czyli ciągiem znaków) już przy tworzeniu obiektu. Zasady nazywania obiektów są dosyć proste. Ich nazwy nie mogą być dłuższe niż 64 znaki (za wyjątkiem dwuznakowych nazw kontenera typu Country, które są międzynarodowym skrótem nazwy kraju), w jednym kontenerze nie może wystąpić więcej niż jeden obiekt o tej samej nazwie, a do tworzenia nazwy można użyć dowolnego znaku specjalnego. Jest to odstępstwo od zasady nazywania obiektów (zbiorów/katalogów) w DOS-ie, gdzie pewne znaki nie mogły być użyte (np. znak zapytania, gwiazdka itp.). Jedynie obiekt typu Bindery Emulation musi przestrzegać konwencji przyjętej w systemie DOS, a to dlatego, że jest uźywany przez stacje poprzednich wersji NetWare (tj. Z.x, 3.x), a ponadto moźe mieć co najwyżej 47 znaków.

Małe i duże litery są w nazwach obiektów traktowane jak te same znaki, a znak odstępu (spacja) jest utożsamiany ze znakiem podkreślenia ('-"). Tak więc nazwa STACJA KASI znaczy tyle samo co nazwa STACJA_KASI i choć system przy wpisywaniu dowolnej z nich wyświetla ją tak jak jest wprowadzona, to jednak później utożsamia je.

Warto żwrócić uwagę, że we wszelkich nazwach w bazie NDS dopuszczalne jest użycie znaków narodowych. Oczywiście, wpisanie z klawiatury polskich liter wymaga zastosowania odpowiednich narzędzi programowych, np. polskiej wersji systemu MS-Windows.

Nieco bardziej skomplikowana jest zasada odwoływania się do obiektu przez podanie "ścieżki" do niego (czyli nazwy obiektu wraz z jego kontekstem). Tutaj przyzwyczajenia i analogie z systemem DOS są już nieprzydatne. O ile bowiem w systemie DOS pełna ścieżka zaczyna się od podania "korzenia" czyli szczytu struktury hierarchicznej i dalej katalogów "w dół" na danym katalogu/zbiorze kończąc, tak w NDS specyfikacja kontekstu zaczyna się od nazwy obiektu i dalej wymieniane są kolejne nazwy kontenerów w kierunku szczytu struktury (obiektu [Root] jako ostatniego nie wymienia się). Dodatkowo jeszcze przyjęto założenia, że każdy obiekt może ("może" - bo w pewnych sytuacjach nie musi) być poprzedzony kwalifikatorem typu właściwym dla niego (czyli: C albo O albo OU albo CN) ze znakiem "=” , a kolejne nazwy odpowiadające kolejnym poziomom oddziela się znakiem kropki ("."). Dodatkowo, jeżeli specyfikacja kontekstu jest pełna , czyli zawiera całą scieżkę w NDS od obiektu do szczytu struktury ( jest to tzw. pełna nazwa), to całą specyfikację poprzedza znak kropki. Kropka wiodąca ma zatem znaczenie , specjalne i informuje, że ciąg znaków następujący po niej to pełna nazwa. Brak kropki wiodącej niesie zaś ważną informację, że ciąg znaków w nazwie to nie jest pełna nazwa, lecz odwołanie względne w stosunku do bieżącego kontekstu ( jest to tzw. nazwa częściowa). Wtedy system "przykleja" podaną nazwę częściową (względną) do nazwy specyfikującej kontekst bieżący              do jego lewej strony i całą powstałą nazwę traktuje jako pełną  nazwę obiektu             

Pozostaje jeszcze omówić ważną konwencję związaną ze stosowaniem kropek, mianowicie rolę kropki (lub wielu kropek) postawionych na końcu specyfikacji obiektu. Ułatwia ona odwołanie się do takiego obiektu, do którego "dojście" polega najpierw na wykonaniu pewnej liczby skoków "w górę" struktury NDS z kontekstu bieżącego, a potem ewentualnie kilku kroków "w dół" struktury. Najpierw wykonywane są "skoki" w górę struktury i jest ich dokładnie tyle, ile kropek postawionych jest na końcu specyfikacji. Po osiągnięciu w ten sposób jakiegoś kontenera "nadrzędnego" w stosunku do kontekstu bieżącego, następuje "zejście w dół" struktury po ścieżce opisanej w pozostałej (czyli już bez kropek) części specyfikacji obiektu. Formalnie rzecz biorąc, po "skokach w górę" następuje "doklejenie" specyfikacji obiektu pozbawionej kropek do lewej strony pełnej nazwy osiągniętego w wyniku skoków w górę kontenera i wynik traktowany jest przez system jako pełna nazwa wskazywanego obiektu.

Pozostał do omówienia jeszcze jeden element konwencji nazewniczych, mianowicie możliwość pomijania kwalifikatora typu obiektów w jego nazwie (czyli w specyfikacji obiektu). Jest to dosyć wygodny mechanizm, pozwala bowiem na uniknięcie wypisywania dodatkowych znaków (tj. CN=, OU=, O=, C=) w odwołaniu do obiektu. Niestety, w wielu przypadkach stosowanie tej techniki prowadzi do niejednoznaczności i pomyłek, bowiem system sam próbuje uzupełnić nazwę bez typów o kwalifikatory typów. Oto zasady, które są przy tym stosowane:

· System uzupełnia podaną specyfikację bez tyów tylko wtedy, gdy jest to pełna nazwa, a więc zaczyna się od znaku kropki. W przypadku, gdy nie zaczyna się od znaku kropki (czyli podana nazwa jest częściową) to system "przykleja" tą nazwę częściową do specyfikacji kontekstu bieżącego od jego lewej strony i powstałą w ten sposób nazwę traktuje jako pełną, którą będzie uzupełniał o kwalifikatory typów obiektów.

· Jeżeli nazwa pełna zawiera nie więcej obiektów niż specyfikacja bieżącego kontekstu (tak może być tylko w przypadku, gdy podana została od razu nazwa pełna zaczynająca się od kropki, nie dłuższa niż ilość poziomów w nazwie bieżącego kontekstu), to system przypisuje kolejnym obiektom w tej nazwie od jej prawej strony takie kwalifikatory typu, jakie istnieją w specyfikacji (nazwie) bieżącego kontekstu, począwszy od szczytu struktury. Jedynie w przypadku, gdy odwołanie ze swojej natury dotyczy obiektu typu CN (np. chodzi o użytkownika w poleceniu LOGIN, kolejkę w poleceniu CAPTURE itp.) to skrajnie lewy obiekt w uzupełnianej nazwie otrzyma kwalifikator CN niezależnie od bieżącego kontekstu.

· W przypadku, gdy nazwa pełna zawiera więcej obiektów niż ich zawiera specyfikacja bieżącego kontekstu, to skrajnie lewemu obiektowi w tej nazwie przypisuje się typ CN, skrajnie prawemu obiektowi typ O, zaś pozostałe obiekty otrzymują typ OU. Wyjątek stanowi tu sytuacja, w której z natury odwołania do obiektu wynika, że chodzi o obiekt typu kontenerowego (np. chodzi o nazwę obiektu podaną w pole­ceniu CX. Wtedy skrajnie lewy obiekt otrzymuje kwalifikator O lub OU a nie CN.

Jak widać, podane zasady nie należą do zbyt oczywistych i dlatego można wyciągnąć prozaiczny wniosek dla użytkownika systemu, żeby używał nazw pozbawionych typów tylko wtedy, gdy jest absolutnie pewien efektu, jaki uzyska. W przypadku wątpliwości zawsze lepiej, by użył nazwy z kwalifikatorami typu i żadna niespodzianka nie powinna go spotkać (o ile oczywiście nie popełni dodatkowych błędów innego typu, co jak wiadomo często się zdarza).

8.Opisz globalny system zabezpieczeń w NetWare 4.x

System zabezpieczeń to inaczej zestaw mechanizmów pozwalających na skuteczną ochronę zasobów sieci. Zasobami sieci, które powinny być chronione są nie tylko dobrze wszystkim znane dane (zbiory, programy itp.), lecz także same omówione już wcześniej obiekty struktury hierarchicznej NDS. Dlaczego ochrona zasobów jest tak istotna? Po pierwsze dlatego, że sieć komputerowa z samej swojej natury dostępna jest dla wielu, może nawet bardzo wielu użytkowników równocześnie i brak ochrony danych jednego użytkownika prled ingerencją w nie ze strony drugiego użytkownika czyniłby system praktycznie bezużytecznym (co widać choćby na klasycznym przykładzie systemu kont bankowych utrzymywanych komputerowo). Ponadto, jak to w życiu bywa, mogłoby dochodzić do niezamierzonego - np. omyłkowego skasowania lub zniszczenia istotnych informacji nie należących do tego, kto to zniszczenie spowodował. Szczegółowe uzasadnianie celowości stosowania mechanizmów zabezpieczających sieć nie należy do tego rozdziału, zresztą i bez takiego uzasadniania jest to rzecz aż nadto oczywista.

Jeżeli konieczność ochrony danych (zbiorów, katalogów) wydaje się czymś naturalnym, to ochrona struktury hierarchicznej bazy obiektowej NDS jest jakby mniej intuicyjna. Co to znaczy, że obiekty NDS mają być chronione i przed czym? Otóż przypomnijmy sobie, że obiekty NDS mogą być różnych typów (kontenery, liście) i niezależnie od tego każdy z nich posiada zestaw opisujących go informacji, czyli tak zwane własności albo cechy (ang. properties). Wyobraźmy sobie dalej, że interesująca nas sieć komputerowa obejmuje wiele oddziałów jednej firmy, być może nawet rozlokowanych w różnych krajach. Mamy wtedy do czynienia z dużymi podstrukturami hierarchicznymi, będącymi w istocie poddrzewami całego drzewa NDS, które, z racji przynależności do zupełnie różnych (choć może w jakiś sposób organizacyjnie związanych) instytucji, mają całkowicie własne obiekty np. serwery, użytkowników czy oddziały organizacyjne w swojej podgałęzi NDS. Nie do wyobrażenia jest, by jakiś użytkownik (ogólniej: obiekt) należący do jednej gałęzi mógł swobodnie manipulować obiektami zawartymi w drugiej gałęzi, przy czym chodzi tutaj zarówno o kasowanie, zakładanie lub przemieszczanie w ramach NDS tych obiektów, jak i o dostęp do ich własności (np. ingerencja w treść programu Login Script dla użytkowników należących do jakiegoś innego działu firmy). Wynika stąd jasno, że dostęp do obiektów NDS jak i do ich własności musi być ściśle kontrolowany i zespół tych właśnie mecha­nizmów określamy jako system zabezpieczeń na poziomie NDS.

Mamy więc do czynienia z następującymi zabezpieczeniami funkcjonującymi w zasadzie niezależnie od siebie:

· Login resirictions - zabezpieczenia na poziomie rejestracji użytkownika do sieci,

· NDS security - zabezpieczenia na poziomie struktury hierarchicznej NDS,

· File system security - zabezpieczenia stosowane do ochrony danych (zbiorów i katalogów w woluminach).

Wszystkie trzy poziomy zabezpieczeń są na ogół stosowane równocześnie i niezależnie od siebie. Ponieważ mechanizmy używane przez nie są dosyć skomplikowane, każdy z poziomów zostanie omówiony oddzielnie.

9. Określ  zabezpieczenia na poziomie rejestracji do systemu

System dopuszcza do korzystania ze swoich zasobów tylko wtedy, gdy dany użytkownik przedstawi się, podając swoją nazwę. Pod pojęciem "nazwy" rozumie się tutaj nazwę istniejącego w jakimś kontenerze użytkownika.

Do zarejestrowania się do sieci używane jest polecenie LOGIN, które musi mieć przynajmniej jeden parametr - nazwę użytkownika. Tak więc można się zarejestrować do tej przykładowej sieci jako JAN w kontenerze SERWIS poleceniem:

LOGIN .CN=JAN.OU=SERWIS.O=ATC

albo jako JAN w kontenerze TECH poleceniem: LOGIN .CN=JAN.OU=TECH.O=ATC

Faktem jest, że choć podane pełne nazwy użytkownika gwarantują poprawność odwołania w poleceniu LOGIN, to jednak w praktyce nie zawsze są stosowane. Jeżeli bowiem kontekstem bieżącym jest:

.OU=SERWIS.O=ATC to poprawne jest polecenie: LOGIN JAN które zgodnie z zasadami odwołania względnego i uzupełniania kwalifikatorów typu przez system jest równoważne poleceniu:

LOGIN .CN=JAN.OU=SERWIS.O=ATC pop...