STEROWANIE
DOST
PEM DO
SYSTEMU
INFORMATYCZNEGO
WIELOPOZIOMOWE ZABEZPIECZONE RELACYJNE BAZY
DANYCH - PRZEGL
D PROBLEMÓW
OCHRONA BAZ DANYCH
Model ochrony SeaView
Model ochrony SeaView sformułowany jest w formie dwóch
modeli warstwowych: model MAC oraz model TCB (wiarygodna
baza danych, ang. Trusted Computing Base).
Model MAC odpowiada monitorowi referencyjnemu, forsujÄ…cemu
realizacjÄ™ mandatowej polityki ochrony wg modelu Bella-
LaPaduli. Z kolei model TCB określa koncepcję relacji
wielopoziomowych, wspomaga dyskretnÄ… ochronÄ™ relacji i
perspektyw (ang.views), jak również umożliwia formalizację
realizowanej polityki ochrony.
Warstwa zawierajÄ…ca model TCB umieszczona jest nad warstwÄ… z
modelem MAC. StÄ…d wszystkie informacje z TCB
przechowywane są w obiektach i mogą być przez nie
udostępniane podmiotom tylko na drodze mediacji za
pośrednictwem monitora referencyjnego modelu MAC.
Model MAC
Polityka ochrony mandatowej SeaView oparta jest na
aksjomatach modeli Bella-LaPaduli i Biby, korzystając także z
wprowadzonych w nich pojęć podmiotu, obiektu i klasy dostępu.
Klasa dostępu posiada komponent sekretów, zwany klasą
sekretów (odpowiadający poziomowi ochrony modelu Bell a-
LaPaduli) oraz komponent integralności, zwany klasą
integralności (odpowiednik poziomu integralności w modelu
Biby).
Każdy obiekt posiada jednoznacznie, i na cały okres swojego
życia, przypisane identyfikator oraz klasę dostępu. Każdemu
użytkownikowi przypisany jest pewien zakres klasy sekretów oraz
integralności, w obrębie którego może realizować swoje operacje.
OCHRONA BAZ DANYCH
Model MAC
Klasy minimalnych sekretów oraz integralności użytkownika,
oznaczone sÄ… odpowiednio przez minsecrecy i minintegruty, zaÅ›
ich standardowe maksymalne klasy przez maxsecrecy i
maxintegrity.
Para minsecrecy, maxintegrity nazywana jest klasÄ… zapisu i
oznaczana jako writeclass, z kolei para maxsecrecy,
minintegrity - klasą zapisu i oznaczana przez readclsass. Zakłada
się, że dla każdego podmiotu klasa readclass dominuje nad klasą
writeclass. Jeśli readclass podmiotu ściśle dominuje nad
writeclass, wtedy mówi się, że podmiot jest wiarygodny.
Jeśli ostra nierówność spełniona jest dla klasy sekretów, wtedy
podmiot jest wiarygodny ze względu na sekrety. Jeśli taka sama
ostra nierówność zachodzi dla klasy integralności, wtedy podmiot
jest wiarygodny ze względu na integralność.
Podmiot wiarygodny ze względu na sekret, może zapisywać dane
o klasie sekretu niższej od klasy niektórych odczytywanych przez
siebie danych. Jednak w tym przypadku należy dowieść, że
podmiot nie przeniesie informacji w dół do obiektów o niższej
klasie ochrony.
Podobnie, podmiot wiarygodny ze względu na integralność, może
czytać dane o klasie integralności niższej od klasy niektórych
danych zapisywanych. Podmioty niewiarygodne posiadają równe
wartości readclass i writeclass.
Aksjomaty ochrony MAC modelu SeaView
Tryb dostępu do obiektów wg omawianego modelu MAC określa
z góry określony zbiór aksjomatów.
OCHRONA BAZ DANYCH
Aksjomaty ochrony MAC modelu SeaView
" Własność odczytu. Podmiot s może czytać obiekt o tylko wtedy
gdy jego klasa odczytu readclass dominuje nad klasą dostępu
obiektu, tzn. wtedy gdy zachodzi relacja readclass(s) e". klasa
dostępu(o). Własność ta odpowiada zasadzie sekretów No Read-
Up modelu Bell a-LaPaduli oraz zasadzie integralności No Read-
Down modelu Biby.
" Własność zapisu. Podmiot s może pisać do obiektu o tylko wtedy,
gdy jego klasa zapisu writeclass jest zdominowana przez klasÄ™
dostępu obiektu, tzn. wtedy gdy spełniona jest relacja
writeclass(s) d". klasa dostępu(o). Własność zapisu odzwierciedla
zasadę sekretów No Write-Down modelu Bell a-LaPaduli oraz
zasadę integralności No Write-Up modelu Biby.
" Własność wykonania. Podmiot s może wykonać (uruchomić)
obiekt o tylko wtedy, gdy wartość jego maxintegrity jest mniejsza
lub równa klasie integralności przypisanej obiektowi, zaś wartość
jego maxsecrecy jest większa lub równa klasie sekretu obiektu.
Model TCB
Model TCB nadrzędnej warstwy ochrony modelu SeaView
precyzuje pojęcie relacji wielopoziomowej oraz formalizuje
politykÄ™ ochrony dyskretnej.
Przyjmuje się, że relacja wielopoziomowa składa się z dwóch
podstawowych elementów: schematu relacji oraz instancji relacji.
Schemat relacji zawiera atrybuty klasyfikujÄ…ce Ci przypisane
każdemu atrybutowi Ai oraz każdej krotce Tc, co formalnie można
przedstawić w postaci następującego schematu:
R(A1,C1,..., An,Cn,Tc)
OCHRONA BAZ DANYCH
Model TCB
Każda krotka w schematu relacji wielopoziomowej ma formę
a1ćłc1 , ..., anćłcn ,t , gdzie każda para aićłci oznacza
odpowiednio wartość oraz klasyfikację i-tego atrybutu. Element t
oznacza z kolei klasę dostępu przypisaną krotce, czyli klasę
dostępu do informacji znajdującej się wkrotce.
Przykład relacji wielopoziomowej o postaci
SID(StatekKosmiczny, CStatekKosmiczny, IdMisji, CIdMisji, CelMisji,
CCelMisji, Tc) i kluczu pierwotnym zdefiniowanym przez pierwsze
pole krotki (tj. StatekKosmiczny), przedstawiony jest na rys.1 (dla
uproszczenia przyjęto, że pod uwagę brane są tylko poziomy
ochrony informacji, np. U - niesklasyfikowana, C - poufna, S -
tajna, TS - ściśle tajna).
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Rys.1 Przykład relacji wielopoziomowej
Każda instancja relacji o klasie dostępu Ac widzi wszystkie te
pola relacji wielopoziomowej, których klasa dostępu jest
zdominowana przez Ac. Zapisujemy to następująco, gdzie każda
wartość ci jest mniejsza niż Ac:
RAc(A1,C1,..., An ,Cn ,Tc )
Przy takiej definicji, informacje zawarte w instancji relacji klasy
Ac dostępne są tylko dla użytkownikówklasy Ac. Powoduje to, że
podmioty o różnych klasach odczytu readclass mogą pobierać
dane z relacji wielopoziomowych, ale będą widzieć różne wersje
danych, zawartych w tych relacjach (porównaj rys.2).
OCHRONA BAZ DANYCH
Model TCB
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U U U
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Rys.2 Instancje relacji wielopoziomowej z rys.1 dla klasy dostępu U i S
Różne instancje relacji muszą być tak skonstruowane, aby każda
krotka, która występuje w instancji relacji o danej klasie dostępu,
występowała także w instancjach relacji klas wyższych, chociaż
niektóre puste pola krotek niższego rzędu mogą być zastąpione
przez niepuste wartości w krotkach wyższych klas (jest to tzw.
własność 0 - Inter-Instance).
Model SeaView definiuje dwie podstawowe własności, które
muszą spełniać zasady klasyfikacji relacji wielopoziomowych.
" Własność 1: Wielopoziomowa integralność encji - MEI (ang.
multilevel entity integrity). Niech AK będzie zbiorem atrybutów
danych, tworzÄ…cych klucz pierwotny relacji R. Wszystkie atrybuty
klasyfikujÄ…ce Ci, odpowiadajÄ…ce atrybutom danych Ai"AK, muszÄ…
mieć te same wartości (są równomiernie sklasyfikowane) dla
dowolnej danej krotki relacji RAc , będącej instancją relacji R, i co
więcej klasa ta jest zdominowana przez wartość każdego atrybutu
klasyfikującego Cj, którego atrybut danych Aj "AK. Zakłada się
także, że żadna z krotek poszczególnych instancji RAc relacji R nie
może posiadać pustego (niezdefiniowanego) klucza pierwotnego.
OCHRONA BAZ DANYCH
Model TCB
" Własność 2: Wielopoziomowa integralność relacyjna - MRI (ang.
multilevel relational integrity). Dopóki istnieje krotka, będąca w
relacji odniesienia za pośrednictwem klucza pierwotnego, dotąd
żadna z krotek relacji nie może posiadać pustego klucza wtórnego.
Dla określonej krotki, klasa dostępu do każdego elementu danych,
zawierającego klucz wtórny, musi być taka sama i musi
dominować nad klasą elementów klucza pierwotnego, określonego
w krotce odniesienia.
W standardowym modelu relacyjnym, każdą krotkę można
równomiernie zidentyfikować na podstawie wartości klucza.
Podejście to zawodzi w przypadku relacji wielopoziomowych,
gdyż często ze względu na konieczność uniknięcia niepożądanego
przepływu informacji poprzez kanał ukryty, dopuszcza się
jednoczesne istnienie więcej niż jednej krotki o tym samym
kluczu, ale o innym przypisanym mu poziomie klasyfikacji.
Zjawisko to nazywa się wieloinstancyjnością.
W relacjach wielopoziomowych klasyfikacja dostępu może
dotyczyć: relacji (wieloinstancyjność relacji), krotek w relacji
(wieloinstancyjność krotek), atrybutów (wieloinstancyjność
atrybutów) oraz elementów danych - pól krotek
(wieloinstancyjność pól, zwana także wieloinstancyjnością
encji). Wieloinstancyjność powstaje w sposób pośredni tylko
wtedy, gdy klasyfikacji podlegają całe relacje lub atrybuty relacji.
Wieloinstancyjność pola występuje wtedy, gdy relacja zawiera
krotki o takiej samej wartości klucza pierwotnego, ale o różnych
klasach dostępu (rys.3).
W przypadku wieloinstancyjności atrybutów relacja może
zawierać dwie lub więcej krotek o takim samym kluczu
pierwotnym i identycznym poziomie ochrony, ale różniących się
przynajmniej jednym z pól nie wchodzących w skład klucza
pierwotnego (patrz rys.4).
OCHRONA BAZ DANYCH
Model TCB
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Voyager U 104 U Talos U U
Rys.3 Przykład relacji wielopoziomowej z wieloinstancyjnością pól
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Voyager S 103 S Talos TS TS
Rys.4 Przykład relacji wielopoziomowej z wieloinstancyjnością
atrybutów
Klasyfikacja na poziomie krotek prowadzi w sposób bezpośredni
do pojawienia się wieloinstancyjności krotek. Jeśli rozważyć
przykład z rys.4 po usunięciu wszystkich poziomów ochrony
przypisanych polom, wtedy np. użytkownik sklasyfikowany na
poziomie TS zobaczy relacjÄ™ wielopoziomowÄ… o postaci z rys.5.
TS - instancja relacji
StatekKosmiczny IdMisji CelMisji Tc
Enterprise 101 Jupiter U
Columbia 102 Księżyc S
Voyager 103 Mars S
Voyager 103 Talos TS
Rys.5 Przykład relacji wielopoziomowej z wieloinstancyjnością
krotek
OCHRONA BAZ DANYCH
Model TCB
Należy zauważyć, że klasyfikowanie tylko na poziomie krotek
znacznie utrudnia (o ile nawet wręcz uniemożliwia) rozróżnienie
pomiędzy wieloinstancyjnością pól, a wieloinstancyjnością
atrybutów.
Wprzykładzie z rys.5 możliwe jest, że obie ostatnie krotki opisują
ten sam statek kosmiczny, a krotka o poziomie ochrony S
pojawiła się wskutek chęci uniknięcia ujawnienia informacji
osobie z niższego poziomu ochrony (tzw. cover story). Możliwe
jest jednak, że są to całkiem różne statki, którym omyłkowo
nadano te same nazwy.
Każdy ze wspomnianych powyżej typów wieloinstancyjności może
pojawić się z dwóch podstawowych przyczyn, które dla wygody
nazywane są wieloinstancyjnością jawną i niejawną
" Wieloinstancyjność jawna występuje wtedy, gdy podmiot o wyższym
poziomie klasyfikacji próbuje dokonać operacji włożenia danej do
pola, które zawiera już dane o niższym poziomie klasyfikacji.
Ponieważ dopuszczenie w tym przypadku do wymazania poprzedniej
danej i nadpisania nowej o wyższym poziomie klasyfikacji,
prowadziłoby do powstania kanału sygnałowego, umożliwiającego
przepływ informacji w dół do podmiotów o niższym poziomie
klasyfikacji, stąd system ochrony musi utworzyć w tym przypadku
nową krotkę i do niej wpisać daną owyższym poziomie klasyfikacji.
" Wieloinstancyjność niejawna pojawia się w przypadku odwrotnym:
podmiot o niższym poziomie klasyfikacji próbuje wpisać daną w
pole, które zawiera już daną o wyższym poziomie klasyfikacji (stąd
jest niewidoczna dla podmiotu modyfikujÄ…cego). Odmowa
zrealizowania tego rodzaju operacji pozwoli oczywiście
wywnioskować podmiotowi o niższym poziome informacji, że polu
tym jest informacja tajna (powstaje kanał sygnałowy), stąd ponownie
system ochrony musi utworzyć nową krotkę i wpisać do niej żądaną
danÄ….
OCHRONA BAZ DANYCH
Model TCB
W modelu SeaView rozwiązanie problemów wynikających z
wieloinstancyjności bazuje na integralności wieloinstancyjności,
sformułowanej poniżej w formie trzeciej własności podstawowej:
" Własność 3: Integralność wieloinstancyjności - PI (ang.
polyinstantiation integrity). Mówi się, że dana instancja relacji
RAc relacji R o kluczu pierwotnym AK i klasie klucza CK spełnia
warunek integralności wieloinstancyjności wtedy i tylko wtedy,
gdy dla każdego RAc oraz każdego Ai"AK relacji RAc zachodzi:
AK,CK ,Ci Ai
AK,CK Ai,Ci
Własność PI pośrednio określa, co rozumie się pod pojęciem
klucza pierwotnego w przypadku relacji wielopoziomowych.
Ponieważ z własności PI wynika, że AK AR (dla AR
zawierającego wszystkie atrybuty nie należące do klucza AK),
stąd klucz pierwotny relacji wielopoziomowej ma postać
AK*"CK*"CR, gdzie CR jest zbiorem poziomów klasyfikujących
atrybuty nie formułujący klucz pierwotny AK.
Rozpatrzmy dalej dla przykładu tylko operację zapisu (włóż,
aktualizuj), biorąc pod uwagę przypadek, gdy klasa dostępu SC
podmiotu jest zdominowana przez klasę dostępu obiektu OC
(krotki lub pola) i odwrotnie, gdy klasa podmiotu SC dominuje
nad klasÄ… obiektu OC.
Klasa SC jest zdominowana przez klasÄ™ OC. Rozpatrzmy
wielopoziomową relację przedstawioną na rys.1 i załóżmy, że
podmiot o klasie dostępu U żąda wykonania następującej
operacji:
INSERT INTO SID VALUES ( Voyager , 104,  Talos )
OCHRONA BAZ DANYCH
Model TCB
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Voyager U 104 U Talos U U
Rys.6 Przykład relacji wielopoziomowej z wieloinstancyjnością
krotek
Wykonanie opisanej operacji prowadzi do powstania
wieloinstancyjności krotek (rys.6).
Jeśli na tych samych danych wyjściowych z rys.1 podmiot o
klasie dostępu U dokona modyfikacji krotki, przy pomocy
polecenia:
UPDATE SID SET CelMisji =  Talos WHERE StatekKosmiczny =
 Columbia
wtedy ze względu na powstałą wieloinstancyjność jawną
(wieloinstancyjność pola), baza przyjmie postać taką jak na rys.7.
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Columbia U 102 U Talos U U
Voyager S 103 S Mars S S
Rys.7 Przykład relacji wielopoziomowej z wieloinstancyjnością pól
Klasa SC dominuje nad klasÄ… OC. Rozpatrzmy tym razem
wielopoziomową relację rys.8. i załóżmy, że podmiot o klasie
dostępu S żąda wykonania następującej operacji (skutki
wykonania operacji INSERT z wartością klucza pierwotnego są
takie same jakpowyżej):
OCHRONA BAZ DANYCH
Model TCB
UPDATE SID SET IdMisji = 101 WHERE StatekKosmiczny =
 Columbia .
Polecenie to spowoduje wprowadzenie do bazy więcej niż jednej
krotki (rys.8), co wynika z konieczności zachowania własności PI.
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Columbia U 102 U Talos U U
Columbia U 101 TS Księżyc S S
Columbia U 101 TS Talos U S
Voyager S 103 S Mars S S
Rys.8 Przykład relacji wielopoziomowej z powielanymi krotkami
Jeśli ten sam podmiot zażąda wykonania operacji
UPDATE SID SET IdMisji = 102, CelMisji =  Talos WHERE
StatekKosmiczny =  Enterprise
na wyjściowej relacji z rys.7, wówczas przyjmie ona postać jak
na rys.9.
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Enterprise U 102 S Jupiter U S
Enterprise U 101 U Talos S S
Enterprise U 102 S Talos S S
Columbia U 102 U Księżyc S S
Columbia U 102 U Talos U U
Voyager S 103 S Mars S S
Rys.9 Przykład relacji wielopoziomowej z powielanymi krotkami
OCHRONA BAZ DANYCH
Model TCB
Na podstawie dwóch ostatnich przykładów widać, że model
SeaView generuje krotki w sposób ekspotencjalny, zależny od
liczby atrybutów nie wchodzących w skład klucza pierwotnego
AK. Cecha ta wynika z przyjętej w modelu własności PI, a
głównie z wprowadzonej tam zależności wielowartościowej.
Model TCB umożliwia także realizowanie dyskretnej polityki
ochrony, określającej którzy użytkownicy lub grupy
użytkowników posiadają określone uprawnienia dostępu do
poszczególnych obiektów bazy danych. Obiektami podlegającymi
szczególnej dyskretnej ochronie są: bazy danych, relacje bazy
danych oraz obiekty MAC niskiego poziomu, przechowujÄ…ce
informacje o realizowanych aksjomatach ochrony.
Model ochrony Jajodia-Sandhu
Punktem wyjścia modelu Jajodia-Sandhu jest określenie pojęcia
relacji wielopoziomowej składającej się, podobnie jak w
przypadku modelu SeaView, z dwóch elementów: schematu
relacji oraz instancji relacji.
Operacje typu czytaj i pisz, wykonywane na relacjach
wielopoziomowych modelu Jajodia-Sandhu kontrolowane sÄ…
zgodnie z zasadami No Read-Up oraz No Write-Down,
wynikajÄ…cymi z realizowanej polityki ochrony MAC, forsowanej
przez model Bell a-LaPaduli.
Spełnienie tego typu wymagań narzuca szereg ograniczeń na
relacje wielopoziomowe. W większości pokrywają się one z
ograniczeniami modelu SeaView, przedstawionymi powyżej.
Własności te definiowane są podobnie w modelu Jajodia-Sandhu
(poza oczywiście własnością PI). Poniżej przedstawione zostaną
tylko dwie spośród nich: własność 0  III oraz 4 - PI.
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu
Własność 0: Integralność Inter-Instance - III (ang. Inter-Instance
integrity). Mówimy, że relacja R spełnia warunek integralności
Inter-instance wtedy i tylko wtedy, gdy dla danego klucza
pierwotnego AK oraz c d"c, Rc =Ã(R , c ), gdzie funkcja filtrujÄ…ca Ã
c
generuje c - instancje relacji R (w oparciu o schemat relacji R) w
c
sposób następujący:
" dla każdej krotki t " Rc takiej, że t[CAK] d" c istnieje taka krotka
t " Rc dla której t [AK, CAK] = t[AK, CAK], zaś dla Ai "AK
zachodzi
2
t[Ai ,Ci]dlat[Ci]d" c
2
t [Ai ,Ci]=
null,t[CAK ] wprzypadku przeciwnym
" nie istnieją żadne inne krotki Rc , jak tylko te wyprowadzone w
oparciu o wyżej przedstawioną zasadę,
" końcowy wynik jest wolny od krotek podciąganych pod
określoną kategorię poprzez ich wyczerpujące eliminowanie z
instancji relacji.
Proces pojawiania siÄ™ krotek wielokrotnych krotek w modelu
SeaView podlegał kontroli zgodnej z własnością PI modelu
SeaView i mogło objawiać się lawinowym narastaniem krotek. W
modelu Jajodia-Sandhu kontrola ta prowadzona jest zgodnie z
własnością przedstawioną poniżej.
Własność 3: Integralność wieloinstancyjności - PI (ang.
polyinstantiation integrity). Relacja wielopoziomowa R spełnia
własność integralności wieloinstancyjności PI wtedy i tylko wtedy,
gdy dla każdej instancji relacji Rc oraz każdego Ai"AK zachodzi:
AK,CK ,Ci Ai
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu
Własność PI, podobnie jak w przypadku modelu SeaView,
definiuje klucz pierwotny relacji wielopoziomowej o postaci
AK*"CK*"CR.
W modelu Jajodia-Sandhu szczególna uwagę zwraca się na
operacje zapisu danych do bazy (operacja odczytu kontrolowana
zresztą zgodnie z zasadą No Read-Up, nie wpływa na zmianę
stanu bazy danych).
Operacje modyfikujÄ…ce stan bazy sÄ… wynikiem nie tylko
bezpośrednich poleceń podmiotu, ale także konieczności
spełnienia własności, narzuconych przez model ochrony, np.
własność typu PI.
Rozpatrzmy podmiot o klasie dostępu c, uprawniający go do
operowania na instancji Rc relacji R oraz podzielmy pozostałe
instancje relacji na trzy klasy:
2
Rc2 2
Rc2 >c = {Rc2 : "c > c}
2
Rc2 \c = {Rc2 :c jestniepor  wnywalnezc}
Warunki ochrony, w szczególności *-własność modelu Bell a-
LaPaduli, oznaczają, że podmiot o poziomie ochrony c (c-
podmiot) nie może dopisywać, modyfikować lub usuwać krotek,
należących do zbioru instancji relacji Rc podmiot nie może wpływać na krotki zbioru relacji Rc wspomniane operacje muszą bezpośrednio oddziaływać tylko na
te krotki relacji Rc, których klasa dostępu jest równa c. Pośrednio
efekt tych operacji musi być także odnotowany w krotkach relacji
ze zbioru Rc >c.
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja INSERT
Składania operacji dopisania nowej krotki przez c-podmiot ma
następująca składnię:
INSERT INTORc[(Ai[, Aj]...)]VALUES(ai[,a ]...)
j
gdzie nawiasy kwadratowe [] oznaczają opcje, zaś okrągłe (...)
możliwość powtórzenia odpowiednią ilość razy.
Operacja INSERT powoduje przypisanie wszystkim polom krotki
domyślnego poziomu ochrony Ci równego wartości c. Załóżmy, że
dla definiowana krotka t ma postać: t[Ai]=ai, jeśli wartość Ai jest
na liście atrybutów polecenia INSERT, t[Aj]=pusty, jeśli wartość
Ai nie występuje na liście atrybutów oraz t[Cj]=c dla 1d"jd"n.
Zezwolenie na wykonanie operacja włożenia nowej krotki
następuje wówczas wtedy i tylko wtedy, gdy:
1.t[AK] nie jest puste
2.dla każdego u"Rc: u[AK] `" t[AK].
Jeśli warunki te są spełnione, następuje dopisanie krotki t do
instancji relacji Rc oraz konsekwentnie do zbioru relacji Rc >c.
Przykład: Rozważmy relację z rys.1 (pokazano ją jeszcze raz
poniżej).
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Rys.1 Przykład relacji wielopoziomowej
Niech podmiot o klasie dostępu U (U-podmiot) zażąda wykonania
operacji:
INSERT INTO SID VALUES ( Apollo , 104,  Księżyc )
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja INSERT
Efekt wykonania polecenia jest identyczny z wykonaniem tej samej
operacji na relacjach jednopoziomowych o odpowiednich
poziomach ochrony i widoczny jest na rys.10.
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U U U
Apollo U 104 U Księżyc U U
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Apollo U 104 U Księżyc U U
Rys.10 Wpływ realizacji operacji INSERT INTO SID VALUES
( Apollo , 104,  Księżyc ) na instancje U i S
Z drugiej strony przyjmijmy teraz, że z kolei S-podmiot zleca
wykonanie polecenia (na relacji z rys.10) typu:
INSERT INTO SID VALUES ( Enterprise , 104,  Talos )
Wykonanie tej operacji spowoduje pojawienie siÄ™ w relacji krotki
o kluczu równym kluczowi krotki już istniejącej. W tym
przypadku system zarządzania ochroną bazy danych może
odmówić dopisania nowej krotki, informując o tym S-podmiot
(nie grozi to ujawnieniem informacji, ponieważ S-podmiot widzi
istniejącą już instancję klucza) lub zaakceptować polecenie,
dopisujÄ…c drugÄ… krotkÄ™ o takim samym kluczu, ale o innej klasie
dostępu (wynik operacji przedstawiono na rys.11).
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja INSERT
Należy zwrócić uwagę, że pojawienie się wieloinstancyjności
krotek nie musiało wcale w tym przypadku wystąpić: użytkownik
mógł być poinformowany o powstałym konflikcie. W modelu
Jajodia-Sandhu sytuację taką nazwano wieloinstancyjnością
opcjonalnÄ….
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U U U
Apollo U 104 U Księżyc U U
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Enterprise S 104 S Talos S S
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Apollo U 104 U Księżyc U U
Rys.11 Wpływ realizacji operacji INSERT INTO SID VALUES
( Enterprise , 104,  Talos ) na instancje U i S
W wielu innych przypadkach wieloinstancyjność jest konieczna.
Można to zilustrować operacją podobną do poprzedniej, ale
wykonanÄ… przez U-podmiot na relacji z rys.12:
INSERT INTO SID VALUES ( Voyager, 103,  Jowisz)
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja INSERT
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U U U
Voyager U 103 U Jowisz U U
Apollo U 104 U Księżyc U U
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Enterprise S 104 S Talos S S
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Voyager U 103 U Jowisz U U
Apollo U 104 U Księżyc U U
Rys.12 Wpływ realizacji operacji INSERT INTO SID VALUES
( Voyager, 103,  Jowisz) na instancje U i S
Ponieważ w momencie dopisywania krotki o kluczu Voyager U-
podmiot nie widział żadnej krotki o tym kluczu (była poufna w
stosunku do jego klasy ochrony) odmowa zapisu krotki
prowadziłaby do ujawnienia informacji o istnieniu poufnej krotki,
stąd system ochrony musi pozwolić na pojawienie się krotki o
takim samym kluczu (wieloinstancyjność konieczna).
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja UPDATE
Składania operacji modyfikacji wybranych pól krotki t przez c-
podmiot ma następująca składnię:
UPDATERcSET Ai = si[, Aj = s ]...[WHERE p]
j
gdzie si jest wyrażeniem skalarnym, zaś p predykatem,
określającym które krotki mają być zmodyfikowane. Zakłada się
przy tym, że modyfikowanym wartościom atrybutów przypisuje
się domyślnie klasę ochrony podmiotu, tj. c.
Podobnie jak w przypadku operacji INSERT efekt zrealizowania
operacji UPDATE powinien być widoczny zarówno w instancjach
relacji Rc, jak i wzbiorze Rc >c.
Klasa instancji relacji Rc. Przez S oznaczmy zbiór krotek w relacji
Rc, spełniających predykat p. Wówczas:
" po pierwsze, zgodnie z żądaniem podmiotu, krotka t została
zastąpiona przez krotkę t , różniącą się od krotki t tylko tymi
wartościami atrybutów, którym w klauzuli SET zostały
przypisane nowe wartości. Formalnie można to zapisać w postaci:
t[Ai,Ci] Ai " SETklauzula
t'[Ai,Ci]=
si, c Ai " SETklauzula
" po drugie, w celu uniknięcia powstania kanału sygnałowego,
należy wprowadzić nową krotkę t  w celu ukrycia efektu
modyfikacji przed podmiotami o klasie dostępu niższej od klasy
dostępu c-podmiotu, żądającego wykonania operacji UPDATE;
problem ten zdarza siÄ™ zawsze wtedy, gdy pewne atrybuty
określone w klauzuli SET posiadają klasę ochrony t[Ci]formalnie nową krotkę t  można zdefiniować następująco:
t[Ai,Ci] "t[Ci]< c
2 2
t [Ai,Ci]=
puste,t[AK ] "t[Ci]= c
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja UPDATE
Klasa instancji relacji Rc >c. Każda modyfikacja instancji Rc
(oczywiście przy złożeniu, że zakończyła się pomyślnie) musi
znalez
ć swoje odzwierciedlenie (jest propagowana) także w
zbiorze instancji Rc >c. Propagacja ta realizowana jest zgodnie z
zasadą minimalnej propagacji i zapewnia spełnienie własności
Inter-instance modelu Jajodia-Sandhu.
Oznaczmy, tak jak poprzednio, przez S zbiór krotek spełniający
predykat p polecenia UPDATE oraz niech Ai będzie atrybutem
występującym w klauzuli SET, spełniającym warunki:
t[Ci ]= c'" t[Ai]= x, gdzie x niepusty
co oznacza, że c-podmiot modyfikuje wartość t[Ai], przypisując
temu atrybutowi nową wartość si oraz domyślną klasę dostępu c.
Ponieważ ze względu na wieloinstancyjność w zbiorze relacji
Rc >c może istnieć jednocześnie kilka krotek u o takim samym
kluczu pierwotnym, co i modyfikowana krotka t, jak również o
takich samych wartościach atrybutów oraz klasie dostępu, tzn.
takich, że zachodzi: u[AAK, CAK] = t[AAK, CAK] oraz u[Ai, Ci] =
t[Ai, Ci]. Aby w tym przypadku spełniony był warunek
integralności wieloinstancyjności PI modelu Jajodia-Sandhu,
wartość atrybutu Ai musi zostać zmieniona z x na si. Żądanie to
formalnie można wyrazić następująco:
Niech dla każdego Ai"SET klauzula oraz t[Ai] `" null
U = {u " Rc'>c : u[AAK ,CAK ]= t[AAK ,CAK ]'" u[Ai ,Ci]= t[Ai ,Ci]}
" Zastąp każdą krotkę u"U krotką u równą u, za wyjątkiem
modyfikowanego pola atrybutu, dla którego u [Ai, Ci]=.
" Dopisz do Rc >c krotkę t oraz t  (patrz wyżej, przy czym ta
ostatnia tylko wtedy, gdy nie jest podciągana pod określoną
kategoriÄ™).
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja UPDATE
Przykład: Zilustrujmy oba powyższe przypadki klas relacji paroma
przykładami. W tym celu rozpatrzmy relacje wielopoziomowe z
rys.2 i załóżmy, że S-podmiot chce wykonać operację:
UPDATE SID SET CelMisji =  Saturn WHERE StatekKosmiczny
=  Columbia
Wynik polecenia pokazany jest na rys.13: modyfikacji uległa tylko
krotka w instancji relacji Rc na poziomie klasy dostępu S-podmiotu.
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U U U
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U Saturn S S
Voyager S 103 S Mars S S
Rys.13 Wpływ realizacji operacji UPDATE SID SET CelMisji =
 Saturn WHERE StatekKosmiczny= Columbia na instancje U i S
Jeśli ten sam podmiot zażąda wykonania kolejnego polecenia (na
relacjach z rys.13) o postaci:
UPDATE SID SET IdMisji = 104 WHERE StatekKosmiczny =
 Columbia
wówczas instancje relacji dla U-podmiotu oraz S-podmiotu przyjmą
postać, przedstawioną na rys.14.
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja UPDATE
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U U U
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisji Tc
Enterprise U 101 U Jupiter U U
Columbia U 102 U S S
Columbia U 104 S Saturn S S
Voyager S 103 S Mars S S
Rys.14 Wpływ realizacji operacji UPDATE SID SET IdMisji = 104
WHERE StatekKosmiczny =  Columbia na instancje U i S
Jak widać modyfikacji uległy tylko krotki o kluczu pierwotnym
Columbia z instancji relacji RS. I o ile zmiany w krotce drugiej sÄ…
wynikiem zrealizowania żądania S-podmiotu, o tyle zmiany w
krotce pierwszej (puste pole CelMisji) wynikają z konieczności
zachowania własności integralności Inter-instance.
Rozpatrzmy teraz ponownie relacje z rys.2 i przyjmijmy, że S-
podmiot zlecił wykonanie operacji:
UPDATE SID SET IdMisji = 102, CelMisji =  Talos WHERE
StatekKosmiczny =  Enterprise
Wynik operacji widoczny jest na rys.15 i wytłumaczyć go można
podobnie jak w przypadku rys.14. Istotny jest jednak inny fakt: w
dzięki innemu zdefiniowaniu własności PI, model Jajodia-Sandhu
wprowadza tylko jedną dodatkową krotkę, w przeciwieństwie do
modelu SeaView, który wprowadza tych krotek aż trzy.
OCHRONA BAZ DANYCH
Model ochrony Jajodia-Sandhu  operacja UPDATE
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisj Tc
i
Enterprise U 101 U Jupiter U U
Columbia U 102 U U U
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CIdMisji CelMisji CCelMisj Tc
i
Enterprise U 101 U Jupiter U U
Enterprise U 102 S Talos S S
Columbia U 102 U Księżyc S S
Voyager S 103 S Mars S S
Rys.15 UPDATE SID SET IdMisji = 102, CelMisji =  Talos
WHERE StatekKosmiczny =  Enterprise
Model ochrony Smitha-Winsletta
Podstawowym problemem, występującym zarówno w modelu
ochrony SeaView, jak i modelu Jajodia-Sandhu, jest
wieloinstancyjność krotek. Podmiot o danej klasie dostępu,
postrzegający dane z bazy, często staje przed dylematem, którym
danym ufać?
Próbą usunięcia tego typu niedogodności jest model Smitha-
Winsletta. Model ten umożliwia realizację mandatowej ochrony
danych MAC i bazuje na koncepcji zaufania (ang. belief).
Podejście Smitha-Winsletta jest odbiciem idei, iż dane na każdym
z poziomów ochrony odzwierciedlają stopień zaufania podmiotu
(o takim samym poziomie klauzuli dopuszczenia do tajności) do
otaczającego go rzeczywistego świata.
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta
Stąd podejście oparte na idei zaufania wprowadza rozróżnienie
pomiędzy danymi, które podmiot widzi i danymi, którym ufa.
Baza danych, a właściwie opisujący ją schemat relacji, o poziomie
(klasie) dostępu równym klasie ochrony podmiotu, zawiera dane,
którym podmiot ten wierzy całkowicie i bez zastrzeżeń. Podmiot
widzi to, w co wierzy oraz to, w co wierzą podmioty z niższych
poziomów, a wco on nie wierzy.
Dostęp podmiotów do bazy danych realizowany jest w oparciu o
dwa podstawowe aksjomaty:
" Własność modyfikacji danych. Dane z określonego poziomu
mogą być modyfikowane (dopisywane, uaktualniane, kasowane)
tylko przez podmiot o takim samym poziomie ochrony.
Własność powyższa odpowiada zasadzie No Write-Down modelu
Bell a-LaPaduli, wnosząc jednocześnie silniejsze ograniczenia,
niedopuszczające do zapisu danych do relacji z poziomów
wyższych. Stąd dane z bazy o określonym poziomie zawsze
odzwierciedlają całkowite zaufanie podmiotu - o tym samym
poziomie - do tych danych.
" Własność odczytu danych. Zapytaniu sformułowanemu przez
podmiot o poziomie ochrony l może być przydzielone prawo
dostępu do danych tylko z tych baz danych (relacji), których
poziom ochrony jest zdominowany przez l.
Własność odczytu danych odpowiada, jak można zauważyć,
zasadzie No Read-Up, sformułowanej w modelu Bell a-LaPaduli
i oznacza, że podmiot może odzyskiwać dokładnie tylko te dane,
co do których jest przekonany, iż budzą one zaufanie innych
podmiotów.
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta
Model Smitha-Winsletta, w przeciwieństwie do modeli SeaView
oraz Jajodia-Sandhu, nie zajmuje siÄ™ klasyfikacjÄ… informacji na
poziomie pojedynczych pól (atrybutów), ograniczając się jedynie
do przypisania klasy dostępu atrybutom klucza pierwotnego oraz
krotce jako całości.
Według Smith a i Winslett a przypisanie klasyfikacji tylko krotce
umożliwia stworzenie równie silnego mechanizmu ochrony
danych w bazie, jak i w przypadku zastosowania klasyfikacji
atrybutów. Wynika to także z faktu, iż dowolny wielopoziomowy
schemat relacji bazy danych z klasyfikacją atrybutówmożna przy
pomocy odpowiedniej dekompozycji przekształcić w zbiór
schematów relacji, w których klasyfikacji poddane są tylko i
wyłącznie krotki.
WielopoziomowÄ… relacjÄ™ w modelu Smitha-Winsletta opisuje
schemat o postaci:
R(K, Kc, A1,..., An,Tc)
gdzie KC oznacza poziom klasyfikacji klucza, TC - poziom
klasyfikacji krotki, zaś Ai atrybuty relacji. Relacje tą uzupełniają
dwa ograniczenia:
" W dowolnej krotce poziom klasyfikacji TC musi dominować nad
poziomem klasyfikacji klucza KC.
" Dla zbioru atrybutów, formujących klucz K oraz dla wszystkich
atrybutówAi nie wchodzących w skład klucza, ale należących do
instancji relacji Rc, musi zachodzić:
K, Kc,Tc A1,..., An
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta
Sformułowana w ten sposób relacja wielopoziomowa oznacza, że
krotki o takich samych wartościach klucza, ale różnych
poziomach ich klasyfikacji, odnoszą się do różnych rzeczy świata
rzeczywistego.
Z kolei krotki o identycznych kluczach oraz poziomach
klasyfikacji KC, ale różniące się przypisanym im poziomem
klasyfikacji TC są odbiciem różnego stopnia zaufania do tych
samych rzeczy świata rzeczywistego, postrzeganego przez różne
podmioty.
Stąd krotka o poziomie ochrony l, która zawiera tylko puste pola
(poza polem klucza i jego klasyfikacją - K i Kc) oznacza, że
podmiot o klasie dostępu wierzy, iż krotka istnieje, ale nie ufa
zawartym tam danym. Jeśli z kolei nie istnieje krotka dla
określonej pary (K i Kc) i poziomu l, wówczas podmiot o klasie
dostępu l nie wierzy, że krotka taka (a właściwie rzecz przez nią
opisywana) istnieje.
Zakłada się jednocześnie, że w momencie, gdy zapisywana
informacja (rzecz), powodujÄ…ce pojawienie siÄ™
wieloinstancyjności krotki, w bazie musi już istnieć tzw. krotka
bazowa, tzn. taka, której klasa ochrony klucza jest równa klasie
ochrony krotki.
Przykład. Niektóre z powyższych cech modelu Smitha-Winsletta
ilustruje rys.17, który jest interpretacją relacji z rys.16 dla różnych
poziomów klasyfikacji krotki.
Wynika z niego, że U-podmiot ma zaufanie tylko do pierwszej i
drugiej krotki, C-podmiot darzy zaufaniem krotkÄ™ trzeciÄ…, zaÅ› S-
podmiot - wierzy krotce czwartej.
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta
Druga i trzecia krotka z rys.17 odnosi siÄ™ do tej samego
rzeczywistego statku kosmicznego, ale U-i C-podmiot majÄ…
odmienne zaufanie do jego identyfikatora oraz celu misji. Z kolei
krotka pierwsza oraz czwarta odnoszą się różnych statków
kosmicznych.
StatekKosmiczny CStatekKosmiczny IdMisji CelMisji Tc
Enterprise U 101 Jupiter U
Columbia U 102 Księżyc U
Columbia U 104 Talos C
Voyager S 103 Talos S
Rys.16 Przykład relacji wielopoziomowej wg. modelu Smith a-
Winslett a
Model ochrony Smitha-Winsletta: operacja SELECT
Operacja SELECT, umożliwiająca podgląd odpowiednio
wyselekcjonowanych krotek, ma postać:
SELECT Ai[, Aj]* FROMRk[, Rl]*WHERE p[BELIEVED BY L]
gdzie symbol * oznacza możliwość wielokrotnego powtórzenia
nazw atrybutów, nawiasy kwadratowe [] - czynność opcjonalną.
Podmioty mają prawo wglądu we wszystkie krotki, których poziom
ochrony jest zdominowany przez ich klasę dostępu.
Opcjonalne słowo kluczowe BELIEVED BY L (L - lista widoczności,
zawierająca jeden lub więcej z przypisanych krotkom jawnych
poziomów ochrony, lub lista poziomów niejawnych typu SELF
odpowiadajÄ…cych tylko poziomowi ochrony podmiotu lub ANYONE -
wszystkim krotkom zdominowanym przez dany poziom ochrony
podmiotu) umożliwia podmiotowi dalsze ograniczenie ich liczby
poprzez wyselekcjonowanie tylko tych krotek, którym ufa.
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta: operacja SELECT
Stąd np. S-podmiot może zażądać przedstawienia mu wszystkich
dostępnych dla niego krotek lub tylko tych krotek, którym ufają
C- i S-podmioty, itd.
U - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CelMisji Tc
Enterprise U 101 Jupiter U
Columbia U 102 Księżyc U
C - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CelMisji Tc
Columbia U 104 Talos C
S - instancja relacji
StatekKosmiczny CStatekKosmiczny IdMisji CelMisji Tc
Voyager S 103 Talos S
Rys.17 Interpretacja relacji z rys.16 na różnych poziomach klasyfikacji
U - podmiot
CelMisji Tc
Księżyc U
C - podmiot
CelMisji Tc
Księżyc U
Talos C
Rys.18 Interpretacja polecenia SELECT CelMisji FROM SID WHERE
StatekKosmiczny=  Columbia BELIEVED BY ANYONE dla
podmiotóworóżnych klasach dostępu
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta: operacja SELECT
Jeśli, korzystając z powyższej definicji SELECT, sformułować
zapytanie do relacji z rys.16, dotyczące pokazania wszystkich celów
misji statku kosmicznego Columbia
SELECT CelMisji FROM SID WHERE
StatekKosmiczny= Columbia BELIEVED BY ANYONE
wówczas w zależności od klasy dostępu podmiotu, otrzymamy
odpowiedzi przedstawione na rys.18.
Model ochrony Smitha-Winsletta: operacja INSERT
Operacja INSERT ma postać:
INSERT INTO R[(Ai[, Aj]*)]VALUES(ai[,a ]*)
j
gdzie zastosowane oznaczenia sÄ… takie same, jak w przypadku
polecenia SELECT.
Operacja INSERT dopisuje nowÄ… krotkÄ™ o poziomie ochrony
równym klasie dostępu podmiotu, zlecającego tą operację, zaś
atrybutom Ai przypisywane są odpowiednie wartości ai,
występujące na liście klauzuli VALUES.
Klasie ochrony klucza K oraz krotki jako całości, przypisywana
jest klasa dostępu podmiotu. Jeśli dopisywana krotka posiada
wartość klucza oraz poziom jego klasyfikacji (tzn. K i Kc) o
wartościach występujących już w innej krotce, wówczas system
ochrony odmawia dopisania jej do bazy danych.
Ponieważ wartość istniejącej krotki są widoczne dla podmiotu
dopisującego, tego typu odmowa (w przeciwieństwie do modelu
SeaView i Jajadia-Sandhu) nie spowoduje utworzenia ukrytego
kanału, poprzez który będzie przepływała informacja do
podmiotówoniższych klasach dostępu.
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta: operacja UPDATE
Operacja UPDATEma postać:
UPDATE R SET Ai = ai[Aj = a ]*WHERE P[BELIEVED BY L]
j
i umożliwia modyfikację wartości atrybutów oraz zaufania do
wybranych, istniejących krotek o poziomie ochrony równym klasie
dostępu podmiotu, żądającego wykonanie tego polecenia.
Klauzule WHERE oraz BELIEVED BY umożliwiają
wyselekcjonowanie tylko tych krotek relacji R, na których ma być
wykonana operacja modyfikacji. BiorÄ…c jednak pod uwagÄ™
własność modyfikacji danych, spośród tak wyselekcjonowanych
krotek modyfikowane mogą być tylko te, których poziom ochrony
jest równy klasie dostępu podmiotu (jeśli w bazie nie ma żadnej
takiej krotki, wówczas dopisywana jest nowa krotka).
Rozpatrzmy krotkę E, która spełnia warunki określone przez
klauzule WHERE oraz BELIEVED BY. Wówczas dla każdej
wartości ai, wymienionej w klauzuli SET:
" jeśli poziom podmiotu, żądającego modyfikacji krotki, jest
wymieniony na liście L, wówczas nowa wartość ai jest wpisywana
do krotki o poziomie ochrony równym klasie dostępu podmiotu,
" jeśli żadna wartość nie jest dostępna na poziomie podmiotu, ale
zdefiniowana jest lista poziomówL wklauzuli BELIEVEDBY,
wówczas następuje jej sekwencyjne przeszukiwanie; każdej
zmiennej relacyjnej ai przypisywana jest wartość z pierwszego
napotkanego poziomu ochrony, której krotka zawiera wartość ai,
" jeśli w klauzuli BELIEVED BY użyto wartości ANYONE,
tworzona jest wówczas wcześniej zdefiniowana podkrata
ochrony, zdominowana przez podmiot; uporzÄ…dkowanie podkraty
powinno być narzucone przez system DBMS lub samego
użytkownika,
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta: operacja UPDATE
" jeśli żadna z powyższych operacji nie zapewnia wygenerowanie
prawidłowej wartości dla ai, krotka E nie jest uaktualniana.
Przykład. Rozpatrzmy polecenie modyfikujące relację z rys.16,
sformułowane przez S-podmiot:
UPDATE SID SET CelMisji= Andromeda WHERE
CelMisji= Talos BELIEVED BY ANYONE
Sens tego polecenie sprowadza się do tego, iż wszystkim celom
misji statków kosmicznych, o których ktokolwiek sądził, że udają
się na Talos, zawierzy także S-podmiot i przyjmie od tego
momentu, że udają się na Andromedę. Warunek zdefiniowany przez
klauzulę WHERE spełnia statek kosmiczny Voyager i Columbia. W
przypadku statku kosmicznego Columbia S-podmiot nie ma
zaufania do danych zawartych w tej krotce. Stąd musi nastąpić
dopisanie nowej krotki na o poziomie ochrony S. Z kolei w
przypadku statku kosmicznego Voyager, spełniającego także
warunek zaufania S-podmiotu, następuje tylko bezpośrednia
modyfikacja pola CelMisji (patrz rys.19).
StatekKosmiczny CStatekKosmiczny IdMisji CelMisji Tc
Enterprise U 101 Jupiter U
Columbia U 102 Księżyc U
Columbia U 104 Talos C
Columbia U 104 Androme S
da
Voyager S 103 Androme S
da
Rys.19 Efekt zrealizowania polecenia UPDATE SID SET
CelMisji= Andromeda WHERE CelMisji= Talos BELIEVED BY
ANYONE
OCHRONA BAZ DANYCH
Model ochrony Smitha-Winsletta: operacja DELETE
Operacja DELETE ma postać:
DELETE FROM R WHERE P [BELIEVED BY L]
gdzie, podobnie jak w przypadku operacji SELECT i UPDATE,
klauzule WHERE oraz BELIEVED BY określają zbiór krotek,
które w zamierzeniu podmiotu powinny zostać usunięte z bazy
danych. Jeśli polecenie takie wydaje l-podmiot, wówczas ze zbioru
tak określonych encji usuwane są tylko te, których klasa ochrony
jest równa l, przy czym w przypadku usuwania krotki bazowej,
encja ta ciągle istnieje na poziomie wyższym. Efekt ten widać po
wykonaniu np. polecenia:
DELETE FROM SID WHERE StatekKosmiczny= Columbia
BELIEVED BY ANYONE
przez U-podmiot na relacji z rys.16 (patrz rys.20).
StatekKosmiczny CStatekKosmiczn IdMisji CelMisji Tc
y
Enterprise U 101 Jupiter U
Columbia U 104 Talos C
Voyager S 103 Talos S
Rys.20 Wynik wykonania operacji DELETE FROM SID WHERE
StatekKosmiczny= Columbia BELIEVED BY ANYONE