DOSTĘPEM DO
SYSTEMU
INFORMATYCZNEGO
Problemy
G 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 POSIADAŁ
DOSTĘP DO WSZYSTKICH ZASOBÓW.
G 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
G 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.
♦ 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.
♦ W systemie Unix także wykonywanie procesów realizowane jest w
dwóch trybach: w trybie monitora – root’a oraz w trybie 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.
Maszyny wielostanowe (c.d)
G 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 w nim występować dużo mniej błędów.
G 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.
G 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, w praktyce osiągnięcie zaufania może być trudne.
Typowe mechanizmy sterowania dostępem
G 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.
G 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ń.
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):
G podmiot, będący źródłem wszelkich żądań (poleceń) w systemie, G polecenie wykonania określonej operacji na obiekcie (dostępu do obiektu),
G monitor referencyjny - straż nik obiektu, weryfikujący każde polecenie dostępu do obiektu i zezwalający lub odmawiający wykonania
polecenia,
G 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 źródła polecenia, zasad oraz aksjomatów dostępu.
Poznanie źródła polecenia odbywa się w fazie uwierzytelnienia, zaś interpretacja zasad - w fazie autoryzacji.
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).
Logow anie
P rofile
użytkow ników
P odm iot
A udytor
P ole ce nie
U w ierz yte lnia nie
D z iennik
z darz eń
S yst e m Z a rz ąd za nia U pra w n ie nia m i
A d m in i st ra t or
S yst e m A u t o ryza cj i
A k s j om at y
Z a sa dy w ery fik a cji
(S A )
u pra w ni e
och ron y
ń
A d m i n i s t ra t or
Z a rządca da nych
Z ar ządca ope ra cji
o ch ro n y
D a n e , n p .
n a s t a w y
re g u l a to ra
P rogra m y a plikac yjne
o
b
i
e
S ys t e m p l i k ó w
k
t
y
kontrola prze z system ope rac yjny
kontrola sp rzętow a
D a ne, np.
P li k i w yk onyw al ne
m oni torow an e
Operacje dostępu: semantyka i atrybuty
G 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.
G 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.
G 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)
G 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.
G 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.
G 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.
Macierz sterowania dostępem (macierz dostępu) – c.d.
G Wyobraźmy 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
G 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
G 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).
Lista sterowania dostępem
G 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.
G 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.
G 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.
Lista możliwości
G 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
G 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.
G 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ń w sprzęcie
G 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.
G 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.
G 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ę.
Więcej zabezpieczeń w sprzęcie (c.d)
G 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
G 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ów bitów, niezależnie od sposobu przechowywania macierzy dostępu.
G 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.
G 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.
G 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.