STEROWANIE DOSTPEM DO SYSTEMU INFORMATYCZNEGO PROWADZENIE (1) Problemy Po pomyślnym przejściu procedury identyfikacji i uwierzytelniania użytkownik uzyskuje dostęp do zasobów informatycznych. ZWYKLE NIE CHCEMY, ABY KAŻDY Z UŻYTKOWNIKÓW POSIADAA DOSTP DO WSZYSTKICH ZASOBÓW. System informatyczny musi więc posiadać mechanizmy, które pozwolą określić przywileje poszczególnych użytkowników (np. Stosownie do pełnionych przez nich ról) i nadzorować ich realizację. Mechanizmy te określamy wspólną nazwą sterowanie dostępem (ang. access control). Maszyny wielostanowe Wiele procesorów (CPU) posiadają wbudowany prosty mechanizm sprzętowy, w oparciu o który możliwe jest budowanie mechanizmów sterowania dostępem wyższego poziomu. f& Wczesne mainframe y IBM posiadały procesor dwustanowy: maszyna mogła znajdować się albo w stanie autoryzowanym albo nie. W pierwszym z przypadków uprawnienia procesu zamykały się w obrębie segmentu pamięci przydzielonego przez SO. W drugim proces mógł swobodnie poruszać się po pamięci i zmieniać inne programy oraz ich dane. Autoryzacja była rozpoznawana dzięki odpowiednio skonstruowanym bibliotekom procedur, którą należało chronić przed błędami lub złośliwym oprogramowaniem. Mainframe był całkowicie zależny od personelu takiego jak programiści systemowi, którzy mieli dostęp do bibliotek. f& W systemie Unix także wykonywanie procesów realizowane jest w dwóch trybach: w trybie monitora root a oraz wtrybie użytkownika. W tym przypadku także jesteśmy na łasce każdego kodu uruchamianego jako root. Stąd wiele dziur w zabezpieczeniach wynika z błędów uprzywilejowanego kodu (lub które umożliwiają użytkownikom uruchamianie swojego kodu z uprawnieniami root a. Ponieważ często łatwo jest napisać pogram, który może pracować jako root, stoimy przed poważnym problemem. WPROWADZENIE (2) Maszyny wielostanowe (c.d) Przyczyną wielu dziur w zabezpieczeniach są błędy kodu. Z tego powodu należy minimalizować rozmiar tego kodu, któremu musimy zaufać poprzez koncentrację funkcji krytycznych z punktu widzenia bezpieczeństwa w podzbiorze systemu, określanego często mianem wiarygodnej bazy obliczeniowej (ang. TRUSTED COMPUTING BASE, TCB). Jeśli TCB zawiera dużo mniej kodu niż inne moduły, to oczywiste jest, że może wnimwystępować dużomniej błędów. Architektury Intela są trochę bezładne. Chociaż procesory 80386 i następne umożliwiają uruchamianie wielu wirtualnych 80286 oraz wspomagają wieloużytkownikowe SO, to nie są one w pełni wirtualizowane. Z tego powodu projektanci systemów sterowania dostępem do PC borykając się zarówno z 80286 jak i następnymi z rodziny procesorami stanęli przed wyborem: mogliby sterować dostępem tylko do aplikacji DOS, dodać dodatkowy sprzęt (taki jak kość szyfrującą w kontrolerze dysku) lub zapewnić bezpieczeństwo poprzez niejasność (utajnienie). Większość wybrała to ostatnie rozwiązanie, narażając się na ataki typu disasemblacja. Konkludując: CPU powinny być procesorami wielostanowymi zawsze wtedy, gdy należy zapewnić wzajemne bezpieczeństwo wielu użytkownikom. Jeden bit w rozkazu procesora teoretycznie wystarcza, wpraktyce osiągnięcie zaufania może być trudne. Typowe mechanizmy sterowania dostępem Każdy system musi mieć przynajmniej jednego użytkownika, posiadającego prawa dostępu do wszystkich części systemu. Użytkownikiem takim jest administrator systemu, który posiada uprawnienia umożliwiające mu kontrolowanie systemu w imieniu tych innych, którzy mu ufają. Administrator musi posiadać pełny dostęp do mechanizmów bezpieczeństwa. Uprawnienia przekazywane innym powinny być mniejsze. Ogólnie, im mniejsze uprawnienia tym mniejsza szansa, że użytkownik może być przyczyna zniszczeń lub przełamania zabezpieczeń. WPROWADZENIE (3) Monitor referencyjny Podstawowy model ograniczania przywilejów polega na traktowaniu zasobów, które chcemy chronić, tak samo jak obiekty (ang. object)o określonych atrybutach. Podmiot (ang. subject) próbuje osiągnąć dostęp do obiektu posiadając określony zbiór uwierzytelnień, bazujących na jego tożsamości. Monitor referencyjny stoi pomiędzy użytkownikiem a obiektem. Sprawdza prawa dostępu, udzielając lub odmawiając odpowiedniego dostępu. Wykonaj Monitor Podmiot Obiekt operację referencyjny Żródło Polecenie Strażnik Zasoby Ogólny model sterowania dostępem zawiera): podmiot, będący zródłem wszelkich żądań (poleceń) w systemie, polecenie wykonania określonej operacji na obiekcie (dostępu do obiektu), monitor referencyjny - strażnik obiektu, weryfikujący każde polecenie dostępu do obiektu i zezwalający lub odmawiający wykonania polecenia, obiekt - tworzy zasoby systemu, takie jak dane, procedury, obszary pamięci, pliki, itp. Monitor referencyjny jest elementem decyzyjnym, opierającym swoje decyzje (o dopuszczeniu do wykonania określonego plecenia) na jednoznacznej identyfikacji podmiotu, treści samego polecenia oraz zasadach weryfikacji uprawnień (DAC) i aksjomatach ochrony (MAC). Podjęcie decyzji wymaga dostarczenia monitorowi wiarygodnego sposobu poznania zródła polecenia, zasad oraz aksjomatów dostępu. Poznanie zródła polecenia odbywa się w fazie uwierzytelnienia, zaś interpretacja zasad - w fazie autoryzacji. WPROWADZENIE (5) Ogólna architektura ochrony systemu Każde polecenie podmiotu (po wcześniejszym zalogowaniu się) podlega dwustronnemu uwierzytelnieniu (proces ten jest transparentny dla podmiotu) oraz kontroli przez procedury Systemu Autoryzacji (SA) poprzez porównywanie zgodności uprawnień podmiotu (tzw. profilu użytkownika) z predefiniowanymi zasadami weryfikacji uprawnień, przechowywanymi w odpowiednich plikach lub obszarach pamięci. System Autoryzacji zezwala na realizację zapytania tylko wtedy, gdy jest ono zgodne ze wzorcem zapisanym w obszarze autoryzacyjnym. W przeciwnym przypadku system SA informuje o błędzie i/lub rejestruje informację o naruszeniu systemu ochrony w odpowiednim dzienniku zdarzeń (ang. log file). Logowanie P rofile użytkowników Podmiot Audytor Polecenie U w ierzytelnianie Dziennik zdarzeń System Zarządzania Uprawnieniami Administrator S ystem A utoryzacji Aksjom aty Z a sa dy w ery fik a cji (S A) uprawnień och ron y Zarządca danych Zar ządca operacji Administrator ochrony Dane, np. nastawy P rogramy aplikacyjne regulatora o b i e System plikó w k t y kontrola przez system operacyjny kontrola sprzętow a D a ne, np. P lik i w yk onyw alne m onitorow an e WPROWADZENIE (6) Operacje dostępu: semantyka i atrybuty Wyróżnia się dwa podstawowe tryby dostępu do obiektów: pasywny i aktywny, tzn. odpowiednio read-only i read-write. Tryby te określane są czasami trybami obserwuj i zmieniaj. Semantyka dostępu do współdzielonych zasobów, np. plików określa, jakie operacje na zasobie może jednocześnie wykonywać wielu użytkowników. Operacje takie realizowane są zwykle z blokowaniem dostępu do zasobu innym użytkownikom, np. read-only z blokowaniem lub read-write z blokowaniem. Tego rodzaju semantyka dostępu może mieć wpływ na integralność zasobu, postrzeganą przez różnych użytkowników. Np. w systemie Unix plik może być zmieniany przez jeden z procesów podczas, gdy pozostałe mogą czytać go. Sytuacja taka rodzi problemy. Wynika to z tego, że Unix rozwiązuje problem dostępu tylko w oparciu o ochronę typu DAC (ang. Discretionary Acces Control, inne systemy zabraniają pisania do zasobu w czasie gdy inne procesy czytają go. Jest to możliwe dzięki ochronie typu MAC (ang. Mandatory Access Control). Macierz sterowania dostępem (macierz dostępu) Macierz dostępu umożliwia realizację ochrony typu DAC, tzn. ogranicza dostęp użytkowników do zasobów systemu i jest podstawowym elementem systemu sterowania dostępem. System sterowania dostępem jest albo częścią albo ściśle związany z systemem operacyjnym. Ponieważ system operacyjny pracuje na poziomie rozróżniania pliku, stąd plik jest zwykle najmniejszym obiektem, z którym związana jest ochrona dostępu. Z tego powodu np. w bazach danych lub innych aplikacjach implementowane mogą być dodatkowe systemy sterowania dostępem. Macierz dostępu M jest podstawą budowy system sterowania dostępem. Jeśli w systemie wyróżnimy zbiór podmiotów S, zbiór obiektów O oraz zbiór praw dostępu A, to każdemu elementowi s"S odpowiada wiersz macierzy , o"O kolumną, zaś A[s,o] elementem macierzy. WPROWADZENIE (6) Macierz sterowania dostępem (macierz dostępu) c.d. Wyobrazmy sobie, że Plik 1 jest systemem operacyjnym, Plik 2 aplikacją, Plik 3 zawiera dane, zaś Plik 4 jest rejestrem prób dostępu do systemu. Kowalski pełni w systemie rolę administratora i ma pełna prawa dostępu do plików(za wyjątkiem Plik 4, który może być przez niego tylko czytany). Górny menedżer musi mieć możliwość uruchomienia systemu operacyjnego i aplikacji, jak również czytać i zapisywać dane. Gondek jest audytorem i może czytać wszystko (oraz uruchamiać system operacyjny). Macierz dostępu odpowiadająca przedstawionym uprawnieniom musi mieć więc wygląd: S/O Plik 1 Plik 2 Plik 3 Plik 4 Kowalski rwx rwx rw r Górny x x rw -- Gondek rx r r r Macierze dostępu odgrywają bardzo ważna rolę przy definiowaniu modeli zabezpieczeń. Przykładem może być model Clark-Wilsona, o którym wspominałem w jednym z początkowych wykładów. Jeśli przez CDI oznaczymy tzw. ograniczenia pozycji danych, zaś przez TP procedury przekształcające, rejestrujące wszystkie próby w systemie, wówczas macierz dostępu może w tym przypadku wyglądać np. tak: S/O Plik 1 TP CDI Plik 4 Kowalski rwx rwx rw r Górny x x -- -- TP x -- rw w Gondek rx r r r Macierze dostępu trudno się poszerza o nowe obiekty i nowych użytkowników (problem skalowania). Występują także problemy z przechowywaniem i dostępem do nich (problem pamięci i szybkości dostępu). WPROWADZENIE (6) Listasterowaniadostępem Macierz można podzielić na części i pamiętać kolumnami. W tym przypadku każda kolumna określa listę sterownia dostępem (ACL, ang. Access Control List) do określonego obiektu. Na przykład w przypadku pliku TP lista ACL ma postać: S/O TP Kowalski rwx Górny x TP -- Gondek r Listę ACL można pamiętać wewnątrz samego pliku. Wg tej zasady funkcjonyje system operacyjny Unix: każdy plik posiada atrybuty rwx określające prawa właściciela pliku, prawa grupy do której należy właściciel oraz prawa wszystkich pozostałych. Z punktu widzenia zarządzania stanem zabezpieczeń ACL posiadają zarówno zalety jak i wady. ACL są dobrze przystosowane do pracy w środowisku, w którym użytkownicy zarządzają swoimi własnymi zabezpieczeniami plików tzw. ziarniste sterowanie dostępem (DAC), bazujące na pojęciu własności pliku (zasobu). Właściciel może nadawać zasobom dowolne atrybuty nie istnieje żaden mechanizm, który zabroniłby mu wykonywania tego typu operacji. Z drugiej strony ACL nie są zbytnio przydatne podczas wykonywania złożonych operacji typu np. przekazywania (oddelegowywania) swoich praw w zakresie uruchamiania aplikacji innym podmiotom. ACL nie są także zbyt efektywnym mechanizmem weryfikacji bezpieczeństwa systemu w trakcie jego pracy. System operacyjny wie bowiem raczej, kto z użytkowników uruchomił określoną aplikację, aniżeli czy dostęp do plików podlegał autoryzacji od czasu uruchomienia aplikacji. System operacyjny musi albo sprawdzać ACL przy każdej próbie dostępu, albo przechowywać w jakiś sposób ścieżkę aktywnych (autoryzowanych) praw dostępu. WPROWADZENIE (7) Lista możliwości Inny sposób podziału macierzy dostępu, ułatwiający jej zarządzanie, polega na przechowywaniu jej wierszami. Określa to tzw. listę możliwości podmiotu (ang. capabilities list). Np. w naszym przykładzie możliwości Kowalskiego są następujące: S/O Plik 1 TP CDI Plik 4 Kowalski rwx rwx rw r W pewnych przypadkach postać ta preferowana. Weryfikacja w trakcie biegu systemu jest bardziej efektywna i co więcej możemy oddelegować uprawnienia bez większego problemu: Gondek może wystawić zaświadczenie o treści Niniejszym oddelegowuję Rozwodowskiemu prawo do odczytu Pliku 4 w godz. Od 9.00 do 14.00. Podpisano Gondek. W załączeniu lista moich możliwości. Z drugiej strony zmiana statusu pliku jest procesem bardzo uciążliwym. Bardzo trudne może być bowiem nawet określenie, którzy z użytkowników posiadają dostęp do zasobu. Jest to żmudne zwłaszcza w przypadku prób wykrycia incydentu lub wystawienia wniosku o popełnieniu przestępstwa. Więcej zabezpieczeń wsprzęcie Jeśli chcemy efektywnie konstruować zabezpieczenia, należy znaczną część ochrony przerzucić na sprzęt. Tak zrobiono na początku lat 70- tych, kiedy podejmowano próby budowy systemów komputerowych opartych na listach możliwości. Przykładem jest system CAP, który posiadał pamięć podręczną przechowującą listy możliwości. Zapewniało to wystarczający poziom bezpieczeństwa, przy znacznej wydajności systemu autoryzacji. Innym przykładem jest system Multics, zaprojektowany w mniej więcej w tym samym czasie co i CAP. Multics był szeroko używany w sieciach obrony US. Maszyny Multics mogły pracować w więcej niż tylko jednym trybie chronionym (pierścieniu) każdy proces miał numer od 0 w górę. WPROWADZENIE (8) Więcej zabezpieczeń wsprzęcie (c.d) Do ochrony sprzętowej wystarcza już jeden bit. Jego ustawienie umożliwia pracę np. mikrojądra maszyny dwustanowej; mikrojądro może emulować zarówno komputer CAP, jak i Multics. Systemy hybrydowe W przypadku systemu idealnego można zarządzać użytkownikami przy pomocy list możliwości, zas plikami przy pomocy ACL. Wg tej zasady pracuje Kerberos, w którym użytkownicy są uwierzytelniani przez serwer bezpieczeństwa (centrum dystrybucji kluczy), podczas gdy pliki przez inny serwer (bilety udostępniania usług). Grupy i role W dużych organizacjach typu bank mamy do czynienia z tysiącami użytkowników oraz setkami aplikacji. Pełne odwzorowanie stanu systemu wymaga milionówbitów, niezależnie od sposobu przechowywania macierzy dostępu. W ramach organizacji zawsze jest możliwe zaklasyfikowanie pracowników do jednej lub większej liczby kategorii (kasjer, szef kasjerów, szef oddziału, itp.). Dzięki temu zamiast złożonej listy ACL lub listy możliwości, można uzyskać znaczne ich zmniejszenie, porządkując przy okazji uprawnienia poszczególnych grup użytkowników. Zarządzanie uprawnieniami ulega znacznemu uproszczeniu. Opiera się ono na pojęciu członkostwa - przynależności zarówno podmiotów, jak i obiektów do sklasyfikowanych grup. Tego typu podział umożliwia odbieranie lub nadawanie uprawnień każdej z grup. W przypadku omówionym powyżej często zamiennie używa się określenia grupa lub rola. W rzeczywistości stosowalność tych pojęć jest trochę inna: podczas gdy członkowie grupy są dość stabilni, to role są z założenia pełnione przez określony okres czasu. Klasycznym przykładem może być oficer wachtowy na statku. W danym okresie (odmierzanym wachtami) na mostku znajduje się dokładnie jeden wachtowy, i zwykle powinien być to jeden spośród oficerów statku; w przypadku nieszczęścia wachtę może trzymać jednak dowolny inny marynarz.