-
Notifications
You must be signed in to change notification settings - Fork 18
/
Copy path12-zugriffskontrolle.tex
299 lines (266 loc) · 14.5 KB
/
12-zugriffskontrolle.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
\chapter{Zugriffskontrolle}
Nachdem wir uns in \hyperref[cha11]{Kapitel 11} mit der
Benutzerauthentifikation\indexAccessControl beschäftigt haben, ist der
nächste Schritt, authentifizierten Nutzern Rechte zuzuweisen, um Zugriff
auf Informationen regulieren zu können. Die Zugriffskontrolle ist ein
Mechanismus, um Vertraulichkeit und Datenschutz in einem
zusammenhängenden System zu gewährleisten. Betrachten wir als
naheliegendes Szenario ein Unternehmen, in dem Informationen
unterschiedlich schützenswert sind. Beispielsweise muss die
Finanzabteilung Zugriff auf die Löhne aller Mitarbeiter haben, die
anderen Mitarbeiter hingegen nicht. Andererseits soll sie
Produktplanungen der Ingenieur-Abteilung nicht einsehen dürfen.
Ein erster möglicher Ansatz stellt eine feste Zuweisung von Rechten an
verschiedene Benutzergruppen dar. Formalisieren wir obiges Beispiel,
benötigen wir:
\begin{itemize}
\item eine Menge $\calS$ von Subjekten, die Mitarbeiter
\item eine Menge $\calO$ von Objekten aller Informationen (Gehälter, Produktskizzen,...)
\item eine Menge $\calR$ von Zugriffsrechten (Leserecht, Schreibrecht,...)
\item eine Funktion $f\colon \calS \times \calO \rArrow \calR$, die das Zugriffsrecht eines Subjektes auf ein Objekt angibt
\end{itemize}
Ein Problem dieses Modells ist, dass eigentlich vertrauliche
Informationen, gewollt oder ungewollt, an nicht autorisierte Personen
gelangen. Ein Ingenieur mit Leserechten auf eine Produktskizze kann
diese in ein öffentliches Dokument eintragen, sofern er die notwendigen
Schreibrechte besitzt. Nach dem Lesen vertraulicher Daten sollte das
Schreiben auf öffentliche Dokumente untersagt sein.
Für ein Unternehmen ist das vorgeschlagene Modell daher in vielen Fällen
zu statisch. Praktische Verwendung findet es dennoch, zum Beispiel in
der UNIX-Rechteverwaltung.
\section{Das Bell-LaPadula-Modell}\indexBellLaPadula
Ein Modell mit dynamischer Zugriffskontrolle ist Bell-LaPadula. Um die
Zugriffskontrolle zu ermöglichen, betrachten wir zunächst die
elementaren Bestandteile und formalisieren ähnlich wie oben:
\begin{itemize}
\item eine Menge \calS\ von Subjekten
\item eine Menge \calO\ von Objekten
\item eine Menge \calA\ \(=\) \{\texttt{read}, \texttt{write}, \texttt{append}, \texttt{execute}\} von Zugriffsoperation
\item eine halbgeordnete\footnote{Unter einer halbgeordneten Menge
versteht man eine Menge, auf der eine reflexive, transitive und
antisymmetrische Relation definiert ist, zum Beispiel \((\N,
\geq)\).} Menge \calL\ von Sicherheitsleveln, auf der ein
eindeutiges Maximum definiert ist % Rücksprache mit Hofheinz %
\end{itemize}
Die obige Auflistung beschreibt das System, für das Bell-LaPadula einen
Zugriffskontrollmechanismus realisieren soll. Da Bell-LaPadula im
Gegensatz zum bereits vorgeschlagenen Modell dynamisch sein soll,
interessieren wir uns vor allem für den Systemzustand. Den Systemzustand
\indexBLPSystemStatus formalisieren wir dabei als Tripel \((B,M,F)\),
wobei
\begin{itemize}
\item $B \subseteq \calS \times \calO \times \calA$ die Menge aller aktuellen Zugriffe ist,
\item $M = (m_{i, j})_{i = 1,..., \vert \calS \vert, j = 1,...,\vert
\calO \vert}$ die Zugriffskontrollmatrix ist, deren Eintrag $m_{i,
j} \subseteq \calA$ die erlaubten Zugriffe des Subjektes $i$ auf das
Objekt $j$ beschreibt und
\item $F = (f_s, f_c, f_o)$ ein Funktionstripel ist, mit:
\begin{itemize}
\item $f_s: \calS \rArrow \calL$ weist jedem Subjekt ein maximales Sicherheitslevel zu
\item $f_c: \calS \rArrow \calL$ weist jedem Subjekt sein aktuelles Sicherheitslevel zu
\item $f_o: \calO \rArrow \calL$ weist jedem Objekt ein Sicherheitslevel zu
\end{itemize}
\end{itemize}
In einem Unternehmen \(U\), in dem \calS\ = \{\texttt{Smith},
\texttt{Jones}, \texttt{Spock}\} die Menge der Angestellten und \calO\ =
\{\texttt{salary.txt}, \texttt{mail}, \texttt{fstab}\} die
schützenswerten Informationen sind, könnte eine Zugriffskontrollmatrix
\(M\) demnach wie folgt aussehen:
\begin{center}
\begin{tabular}{r||c|c|c}
& \texttt{salary.txt} & \texttt{mail} & \texttt{fstab} \\
\hline
\texttt{Smith} & \(\{\texttt{read}\}\) & \(\{\texttt{execute}\}\) & \(\emptyset\) \\
\texttt{Jones} & \(\{\texttt{read},\texttt{write}\}\) & \(\{\texttt{read},\texttt{write},\texttt{execute}\}\) & \(\emptyset\) \\
\texttt{Spock} & \calA & \calA & \calA
\end{tabular}
\end{center}
Sei weiterhin \calL\ = \(\{\texttt{topsecret}, \texttt{secret},
\texttt{unclassified}\}\) die Menge der Sicherheitslevel, die \(U\) zur
Realisierung der Zugriffskontrolle mittels Bell-LaPadula verwendet. Die
darauf definierte Halbordnung sei \texttt{unclassified} \(<\)
\texttt{secret} \(<\) \texttt{topsecret}. Ein Beispiel für das
Funktionstripel wäre somit:
\begin{center}
\begin{tabular}{r||c|c}
& \(f_s(\cdot)\) & \(f_c(\cdot)\) \\
\hline
\texttt{Smith} & \(\texttt{unclass.}\) & \(\texttt{unclass.}\) \\
\texttt{Jones} & \(\texttt{secret}\) & \(\texttt{unclass.}\) \\
\texttt{Spock} & \(\texttt{topsecret}\) & \(\texttt{unclass.}\)
\end{tabular}
\quad
\begin{tabular}{r||c}
& \(f_o(\cdot)\) \\
\hline
\texttt{salary.txt} & \(\texttt{secret}\) \\
\texttt{mail} & \(\texttt{unclass.}\) \\
\texttt{fstab} & \(\texttt{topsecret}\)
\end{tabular}
\end{center}
Es fällt auf, dass ein Matrixeintrag \(m_{i, j}\) nicht leer sein muss,
selbst wenn das maximale Sicherheitslevel des Subjektes kleiner dem des
Objektes ist. Wäre der Systemzustand \((B, M, F)\) von \(U\) mit obiger
Matrix und Funktionstripel allerdings sicher, sollte \texttt{Smith}
lesend auf \texttt{salary.txt} zugreifen wollen? Intuitiv natürlich
nicht. Wie aber können wir formal korrekt einen sicheren Systemzustand
beschreiben und was heißt sicher im Kontext der Zugriffskontrolle
überhaupt? Hierfür müssen wir zunächst eine Menge an Eigenschaften
definieren:
\begin{definition}[Discretionary-Security/ds-Eigenschaft]\indexBLPDiscretionarySecurity
Ein Systemzustand \((B, M, F)\) hat die ds-Eigenschaft, falls:
\[
\forall (s, o, a) \in B : a \in m_{s,o}\, .
\]
\end{definition}
Die ds-Eigenschaft ist die erste naheliegende Forderung, die ein
sicherer Systemzustand nach Bell-LaPadula erfüllen sollte. So wird
sichergestellt, dass alle aktuellen Zugriffe konsistent mit der
Zugriffsmatrix sind.
\begin{definition}[Simple-Security/ss-Eigenschaft]\indexBLPSimpleSecurity
Ein Systemzustand \((B, M, F)\) hat die ss-Eigenschaft, falls:
\[
\forall (s, o, \texttt{read}) \in B : f_s(s) \geq f_o(o)\, .
\]
\end{definition}
Ebenso naheliegend ist es, dass kein Subjekt lesend auf Objekte
zugreifen sollte, deren Sicherheitslevel das maximale Sicherheitslevel
des zugreifenden Subjekts übersteigt. Insbesondere ist zu beachten, dass
die ss-Eigenschaft in diesem Skript ausschließlich für Leseoperationen
definiert ist. Oftmals wird sie daher auch als "{}no read up"{}
bezeichnet.
% Rücksprache mit Hofheinz %
Ist für eine gegebene Anfrage \((s, o, \texttt{read})\) die
ss-Eigenschaft und die ds-Eigenschaft erfüllt, wird das aktuelle
Sicherheitslevel des Subjektes angepasst: \(f_c(s) = \max \{f_c(s),
f_o(o)\}\). Die ss-Eigenschaft ist somit zentral für den dynamischen
Ansatz des Bell-LaPadula-Modells.
\begin{definition}[Star Property/\(\star\)-Eigenschaft]\indexBLPStarProperty
Ein Systemzustand \((B, M, F)\) hat die \(\star\)-Eigenschaft, falls:
\[
\forall\ (s, o, \texttt{\{write, append\}}) \in B : f_o(o) \geq f_c(s)\, .
\]
\end{definition}
Ein bisschen weniger intuitiv ist die \(\star\)-Eigenschaft, die
verhindert, dass sensitive Informationen in weniger sensitive Objekte
geschrieben werden. Sie verlangt, dass Subjekte, die lesend auf
(sensitive) Objekte zugegriffen haben, nur noch in Objekte schreiben
dürfen, deren Sicherheitslevel mindestens genauso hoch ist. Als
alternative Bezeichnung dieser Eigenschaft wird deswegen oft "{}no write
down"{} verwendet.
Wir bezeichnen einen Systemzustand \((B, M, F)\)\indexBLPSystemStatus
als sicher, falls es keinen Zugriff \(b \in B\) gibt, der eine der drei
Eigenschaften verletzt. Bell-LaPadula erlaubt einen Zugriff
ausschließlich bei Erhalt des Systemsicherheit.
\subsection{Nachteile des Bell-LaPadula-Modells}\indexBellLaPadula
Ein offensichtlicher Nachteil dieses Modells ist, dass die aktuellen
Sicherheitslevel nie herabgesetzt werden. Das Lesen eines Objektes \(o\)
mit \(f_o(o) > f_c(s)\) schränkt folglich dauerhaft die Menge an
Objekten ein, auf die ein Subjekt \(s\) schreibend zugreifen kann. Ein
Zurücksetzen des aktuellen Sicherheitslevels zu einem Zeitpunkt ist
nicht realistisch, da die Subjekte in der Regel nicht gezwungen werden
können, gelesene Informationen zu vergessen.
Ein anderer Lösungsansatz für dieses Problem stellt die Einteilung der
Subjekte in vertrauenswürdige und nicht vertrauenswürdige Subjekte
dar. Für Erstere wird, ausgehend davon, dass keine Weitergabe von
Informationen an nicht berechtigte Subjekte erfolgt, die
\(\star\)-Eigenschaft ausgesetzt. Hier ist die Qualität der Prüfung, ob
ein Subjekt vertrauenswürdig ist oder nicht, entscheidend für die
Sicherheit des Modells.
Ein zweiter gravierender Nachteil ergibt sich daraus, dass Subjekte auf
Objekte höheren Sicherheitslevels schreibend zugreifen dürfen. Somit
können gezielt sensitive Objekte von nicht autorisierten Subjekten
geändert werden, was zu hohen Schäden führen kann. Ein subtilerer
Nachteil ergibt sich aus der Tatsache, dass Subjekte beispielsweise die
Existenz von sensitiven Objekten erfahren können. % Umschreiben % Zwar
ist Bell-LaPadula dynamischer als das in der Einleitung vorgestellte
Modell, doch sind die Zugriffskontrollmatrix \(M\) und die Funktionen
\(f_s, f_o\) unveränderlich.
Zusammenfassend betrachtet realisiert das Bell-LaPadula-Modell eine
Zugriffskontrolle, die zuverlässig vor Informationsweitergabe an
unautorisierte Subjekte schützt, jedoch in vielen Szenarien auf Dauer zu
unflexibel ist und auch nicht vor Datenmanipulation schützen kann.
\section{Das Chinese-Wall-Modell}\indexChineseWall
% Zugriffsarten wie bei Bell-LaPadula formalisieren? Wäre auf jeden Fall konsistenter. %
Das Chinese-Wall-Modell realisiert, ähnlich dem Bell-LaPadula-Modell,
eine dynamische Zugriffskontrolle. Das Szenario, in welchem die beiden
Modelle jeweils angewandt werden, unterscheidet sich allerdings
fundamental. Während das Bell-LaPadula-Modell grundsätzlich
Informationen in einem geschlossenen System, wie zum Beispiel einer
Firma, schützen soll, ist das Chinese-Wall-Modell beispielsweise für
Szenarien konzipiert, in denen Interessenskonflikte zwischen mehreren
Firmen entstehen können. Stellen wir uns vor, eine Menge von Beratern
berät Firmen zu einer Menge von Objekten. Dieses Gedankenspiel ist
gänzlich unproblematisch, solange jeder Berater maximal eine Firma
berät. Ist allerdings bereits ein Berater bei mehreren Firmen unter
Vertrag, so kann es, sollten die Firmen konkurrieren, zu einem
Interessenkonflikt kommen. Bell-LaPadula liefert auf diese
Problemstellung keine Antwort. Es gibt weder Sicherheitslevel, noch kann
ein Systemzustand formuliert werden, da Zugriffskontrollmatrix und
Funktionen fehlen. Um eine Lösung anbieten zu können, müssen wir
zunächst die neue Wirklichkeit als System formalisieren. Wir brauchen
gemäß unserem Szenario
\begin{itemize}
\item eine Menge $\calC$ von Firmen,
\item eine Menge $\calS$ von Beratern,
\item eine Menge $\calO$ von Objekten,
\item eine Menge $\calA = \{\texttt{read}, \texttt{write}\}$ von Zugriffsoperationen,
\item eine Funktion $y\colon \calO \rArrow \calC$, die jedem Objekt seine eindeutige Firma zuweist und
\item eine Funktion $x\colon \calO\ \rArrow\ \calP(\calC)$, die jedem Objekt die \textbf{Menge} an Firmen zuweist, mit denen es in Konflikt steht.
\end{itemize}
Das Ziel ergibt sich ebenfalls aus unserem Gedankenspiel: Eine
konfliktfreie Zuordnung von Beratern zu Objekten. Doch wie kann
garantiert werden, dass eine Zuordnung konfliktfrei ist? % Wieso auch
bei Lesezugriffen? % Es ist naheliegend, dass bei jedem Schreib- oder
Lesezugriff $(s, o, a) \in \calS \times \calO \times \calA$ ein Konflikt
entsteht, falls \(s\) in der Vergangenheit bereits Zugriff auf ein
Objekt hatte, das in Konflikt mit \(y(o)\) steht. Formal definieren wir:
\begin{definition}[Simple-Security/ss-Eigenschaft]\indexCWSimpleSecurity
Eine Anfrage $(s, o, a) \in \calS \times \calO \times \calA$ hat die
ss-Eigenschaft, falls: \(\forall\ o' \in\) \calO, auf die \(s\) schon
Zugriff hatte, gilt:
\[
y(o) = y(o') \lor y(o) \notin x(o')\, .
\]
\end{definition}
Eine konfliktfreie Zuordnung muss jeden Zugriff ablehnen, für den die
ss-Eigenschaft nicht gilt. Hinreichend ist das jedoch nicht, da ein
ungünstiges Zusammenspiel von Beratern ungewollten Informationsfluss
ermöglichen kann.
\begin{beispiel}
Für zwei Berater \(s_1, s_2 \in\) \calS\ wird folgender Ablauf betrachtet:
\begin{multicols}{2}
\begin{enumerate}
\item Lesezugriff \((s_1, o_1, \texttt{read})\)
\item Schreibzugriff \((s_1, o_2, \texttt{write})\)
\item Lesezugriff \((s_2, o_2, \texttt{read})\)
\item Schreibzugriff \((s_2, o_3, \texttt{write})\)
\end{enumerate}
\end{multicols}
Es ist denkbar, dass \(y(o_3) \in x(o_1)\), die Firma von \(o_3\) also
mit \(o_1\) in Konflikt steht. Durch den letzten Schreibzugriff könnte
demnach indirekt Information geflossen sein, die das
Chinese-Wall-Modell eigentlich hätte schützen sollen.
\end{beispiel}
Um indirekten Informationsfluss zu verhindern, brauchen wir neben der
ss-Eigenschaft eine zusätzliche Forderung. Eine Schreibanfrage eines
Beraters soll nur dann erlaubt werden, falls alle von ihm zuvor gelesen
Objekte entweder aus der gleichen Firma stammen oder mit keiner Firma in
Konflikt stehen. Formalisieren wir unsere Forderung als Eigenschaft,
ergibt sich:
\begin{definition}[Star Property/\(\star\)-Eigenschaft]\indexCWStarProperty
Eine Schreibanfrage $(s, o, \texttt{write}) \in \calS \times \calO$
hat die \(\star\)-Eigenschaft, falls: \(\forall\ o' \in\) \calO, auf
die \(s\) schon lesend zugegriffen hat, gilt:
\[
y(o) = y(o') \lor x(o') = \emptyset\, .
\]
\end{definition}
Erlauben wir ausschließlich Anfragen, die beide Eigenschaften erfüllen,
können wir eine konfliktfreie Zuordnung garantieren. Ungewollter
Informationsfluss - direkter, sowie indirekter - kann ausgeschlossen
werden. Auffällig ist jedoch die Striktheit der \(\star\)-Eigenschaft,
die gerade mit zunehmender Dauer den Beratern enge Grenzen steckt. Eine
Möglichkeit, die gelesenen Objekte eines Beraters (nach einer gewissen
Zeit) zurückzusetzen, gibt es nicht. Um höchstmögliche Sicherheit zu
bieten, ist das Fehlen eines solchen Mechanismus allerdings sinnvoll.