Zugriffskontrolle
This commit is contained in:
parent
29e356bf7d
commit
ed53c98b63
BIN
Network Security - Cheatsheet.pdf
(Stored with Git LFS)
BIN
Network Security - Cheatsheet.pdf
(Stored with Git LFS)
Binary file not shown.
@ -2521,89 +2521,72 @@
|
||||
\section{Zugriffskontrolle}
|
||||
\subsection{Was ist Zugangskontrolle?}
|
||||
\begin{itemize*}
|
||||
\item Definition: Die Zugriffskontrolle umfasst die Mechanismen, die die Vermittlung von Subjektanfragen für den Zugriff auf Objekte, wie sie in einer bestimmten Sicherheitspolitik definiert sind, erzwingen.
|
||||
\item Ein wichtiges konzeptuelles Modell in diesem Zusammenhang ist der Referenzmonitor:
|
||||
\item Die Zugriffskontrolle umfasst die Mechanismen, die die Vermittlung von Subjektanfragen für den Zugriff auf Objekte, wie sie in einer bestimmten Sicherheitspolitik definiert sind, erzwingen.
|
||||
\item wichtiges konzeptuelles Modell ist der Referenzmonitor
|
||||
%\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-reference-monitor.png}
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Sicherheitspolitik}
|
||||
\begin{itemize*}
|
||||
\item Um Entscheidungen über die Zugriffskontrolle treffen zu können, muss der Referenzmonitor die Sicherheitspolitik des Systems kennen
|
||||
\item Definition: Die Sicherheitspolitik eines Systems definiert die Bedingungen, unter denen Subjektzugriffe auf Objekte durch die Funktionalität des Systemreferenzmonitors vermittelt werden
|
||||
\item Bemerkungen
|
||||
\begin{itemize*}
|
||||
\item Die obige Definition wird gewöhnlich im Zusammenhang mit der Sicherheit von Computern und Betriebssystemen gegeben.
|
||||
\item Der Referenzmonitor ist nur eine konzeptionelle Einheit, er muss nicht unbedingt ein physisches oder logisches Gegenstück in einem bestimmten System haben.
|
||||
\item Der Begriff Sicherheitspolitik wird oft auch in einem weiteren Sinne verwendet, um eine Spezifikation aller Sicherheitsaspekte eines Systems einschließlich Bedrohungen, Risiken, Sicherheitsziele, Gegenmaßnahmen usw. zu beschreiben.
|
||||
\end{itemize*}
|
||||
\item Die \textbf{Sicherheitspolitik} eines Systems definiert die Bedingungen, unter denen Subjektzugriffe auf Objekte durch die Funktionalität des Systemreferenzmonitors vermittelt werden
|
||||
\item wird gewöhnlich im Zusammenhang mit der Sicherheit von Computern und Betriebssystemen gegeben
|
||||
\item Referenzmonitor ist nur eine konzeptionelle Einheit%, er muss nicht unbedingt ein physisches oder logisches Gegenstück in einem bestimmten System haben
|
||||
\item Der Begriff Sicherheitspolitik wird oft auch in einem weiteren Sinne verwendet, um eine Spezifikation aller Sicherheitsaspekte eines Systems einschließlich Bedrohungen, Risiken, Sicherheitsziele, Gegenmaßnahmen usw. zu beschreiben
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Klassische Computersubjekte, Objekte und Zugriffsarten}
|
||||
\begin{itemize*}
|
||||
\item Definition: Ein Subjekt ist eine aktive Entität, die eine Anfrage nach Ressourcen initiieren und diese Ressourcen nutzen kann, um eine Aufgabe zu erfüllen.
|
||||
\item Definition: Ein Objekt ist ein passives Repository, das zur Speicherung von Informationen dient
|
||||
\item Die beiden obigen Definitionen stammen aus der klassischen Computerwissenschaft:
|
||||
\begin{itemize*}
|
||||
\item Subjekte sind Prozesse, und Dateien, Verzeichnisse usw. sind Objekte.
|
||||
\end{itemize*}
|
||||
\item Es ist jedoch nicht immer offensichtlich, Subjekte und Objekte im Zusammenhang mit der Kommunikation zu identifizieren:
|
||||
\begin{itemize*}
|
||||
\item Stellen Sie sich vor, eine Einheit sendet eine Nachricht an eine andere Einheit: Ist die empfangende Einheit als Objekt zu betrachten?
|
||||
\end{itemize*}
|
||||
\item Außerdem müssen wir wissen, was ein Zugriff ist und welche Arten von Zugriffen es gibt:
|
||||
\subsection{Klassische Subjekte, Objekte und Zugriffsarten}
|
||||
\begin{itemize*}
|
||||
\item Ein Subjekt ist eine aktive Entität, die eine Anfrage nach Ressourcen initiieren und diese Ressourcen nutzen kann, um eine Aufgabe zu erfüllen
|
||||
\item Ein Objekt ist ein passives Repository, das zur Speicherung von Informationen dient
|
||||
\item Die beiden obigen Definitionen stammen aus der klassischen Computerwissenschaft
|
||||
%\item Subjekte sind Prozesse, und Dateien, Verzeichnisse usw. sind Objekte
|
||||
\item Es ist jedoch nicht immer offensichtlich, Subjekte und Objekte im Zusammenhang mit der Kommunikation zu identifizieren
|
||||
%\item Stellen Sie sich vor, eine Einheit sendet eine Nachricht an eine andere Einheit: Ist die empfangende Einheit als Objekt zu betrachten?
|
||||
\item Außerdem muss man wissen, was ein Zugriff ist und welche Arten von Zugriffen es gibt
|
||||
\item Beispiele aus der klassischen Informatik für Zugriffsarten: Lesen, Schreiben, Ausführen
|
||||
\item Objektorientierte Sichtweise: Jede Methode eines Objekts definiert eine Art des Zugriffs
|
||||
\end{itemize*}
|
||||
%\item Objektorientierte Sichtweise: Jede Methode eines Objekts definiert eine Art des Zugriffs
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Sicherheitskennzeichen}
|
||||
\begin{itemize*}
|
||||
\item Definition: Eine Sicherheitsstufe wird als hierarchisches Attribut zu Entitäten eines Systems definiert, um deren Sensibilitätsgrad zu kennzeichnen
|
||||
\item \textbf{Sicherheitsstufe} wird als hierarchisches Attribut zu Entitäten eines Systems definiert, um deren Sensibilitätsgrad zu kennzeichnen
|
||||
\begin{itemize*}
|
||||
\item Beispiele:
|
||||
\item Militär: unklassifiziert $<$ vertraulich $<$ geheim
|
||||
\item Kommerziell: öffentlich $<$ sensibel $<$ eingeschränkt
|
||||
\end{itemize*}
|
||||
\item \textbf{Sicherheitskategorie} definiert als nicht-hierarchische Gruppierung von Entitäten, um den Grad ihrer Sensibilität zu kennzeichnen
|
||||
\begin{itemize*}
|
||||
\item Militär: unklassifiziert < vertraulich < geheim < streng geheim
|
||||
\item Kommerziell: öffentlich < sensibel < proprietär < eingeschränkt
|
||||
\item Beispiel: Abteilung A, Abteilung B, Verwaltung usw.
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Definition: Eine Sicherheitskategorie ist definiert als eine nicht-hierarchische Gruppierung von Entitäten, um den Grad ihrer Sensibilität zu kennzeichnen.
|
||||
\begin{itemize*}
|
||||
\item Beispiel (Wirtschaft): Abteilung A, Abteilung B, Verwaltung usw.
|
||||
\end{itemize*}
|
||||
\item Definition: Eine Sicherheitskennzeichnung ist definiert als ein Attribut, das mit Systemeinheiten verbunden ist, um deren hierarchische Sensibilitätsstufe und Sicherheitskategorien zu kennzeichnen.
|
||||
\item \textbf{Sicherheitskennzeichnung} definiert als Attribut, das mit Systemeinheiten verbunden ist, um deren hierarchische Sensibilitätsstufe und Sicherheitskategorien zu kennzeichnen.
|
||||
\begin{itemize*}
|
||||
\item In Form von mathematischen Mengen: $Labels = Levels \times Powerset(Categories)$
|
||||
\end{itemize*}
|
||||
\item Sicherheitslabels, die die Sicherheitsempfindlichkeit von:
|
||||
\item Sicherheitslabels, die die Sicherheitsempfindlichkeit von
|
||||
\begin{itemize*}
|
||||
\item Subjekte werden Freigaben genannt
|
||||
\item Objekte werden Klassifizierungen genannt
|
||||
\end{itemize*}
|
||||
\item Ein wichtiges Konzept für die Spezifikation von Sicherheitspolitiken sind binäre Relationen auf der Menge der Kennzeichnungen:
|
||||
\begin{itemize*}
|
||||
\item Eine binäre Relation auf einer Menge S ist eine Teilmenge des Kreuzprodukts $S\times S$
|
||||
\item Beispiel:
|
||||
\begin{itemize*}
|
||||
\item Dominiert: $Labels \times Labels$
|
||||
\item Dominiert $={(b1,b2) | b1, b2 \in Labels \wedge level(b1) \geq level(b2) \wedge categories(b2) \subseteq categories(b1)}$
|
||||
\item Wenn $(b1, b2) \in Dominates$, schreiben wir auch b1 dominates b
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Ein wichtiges Konzept für die Spezifikation von Sicherheitspolitiken sind binäre Relationen auf der Menge der Kennzeichnungen: Eine binäre Relation auf einer Menge S ist eine Teilmenge des Kreuzprodukts $S\times S$
|
||||
%\begin{itemize*}
|
||||
% \item Dominiert: $Labels \times Labels$
|
||||
% \item Dominiert $={(b1,b2) | b1, b2 \in Labels \wedge level(b1) \geq level(b2) \wedge categories(b2) \subseteq categories(b1)}$
|
||||
% \item Wenn $(b1, b2) \in Dominates$, schreiben wir auch b1 dominates b
|
||||
%\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Spezifikation der Sicherheitspolitik}
|
||||
\begin{itemize*}
|
||||
\item Formale Ausdrücke für Regeln der Sicherheitspolitik:
|
||||
\item Betrachten Sie die folgenden Zuordnungen:
|
||||
\item Formale Ausdrücke für Regeln der Sicherheitspolitik
|
||||
\item Betrachten Sie die folgenden Zuordnungen
|
||||
\begin{itemize*}
|
||||
\item $allow: Subjects \times Accesses \times Objects \rightarrow boolean$
|
||||
\item $own: Subjects \times Objects \rightarrow boolean$
|
||||
\item $admin: Subjects \rightarrow boolean$
|
||||
\item $dominates: Labels \times Labels \rightarrow boolean$
|
||||
\end{itemize*}
|
||||
\item Die oben genannten Zuordnungen können verwendet werden, um bekannte
|
||||
Sicherheitsrichtlinien zu spezifizieren:
|
||||
\item Die oben genannten Zuordnungen können verwendet werden, um bekannte Sicherheitsrichtlinien zu spezifizieren
|
||||
\begin{itemize*}
|
||||
\item $ownership: \forall s \in Subjects, o \in Objects, a \in Accesses: allow(s, o, a) \Leftrightarrow own(s, o)$
|
||||
\item $own_admin: \forall s \in Subjects, o \in Objects, a \in Accesses: allow(s, o, a) \Leftrightarrow own(s, o) \wedge admin(s)$
|
||||
@ -2616,13 +2599,13 @@
|
||||
\begin{itemize*}
|
||||
\item Ein Zugriffskontrollmechanismus ist eine konkrete Umsetzung des Referenzmonitor-Konzepts
|
||||
\item Es gibt zwei Haupttypen von Zugriffskontrollmechanismen:
|
||||
\begin{itemize*}
|
||||
\item Diskretionäre Zugriffskontrolle umfasst diejenigen Verfahren und Mechanismen, die die spezifizierte Vermittlung nach dem Ermessen der einzelnen Benutzer durchsetzen
|
||||
\item Beispiel: Das Unix-Betriebssystem ermöglicht es den Benutzern, die Zugriffsrechte für Dateien, die ihnen gehören, zu erteilen oder zu entziehen (Lesen, Schreiben, Ausführen).
|
||||
\item Die obligatorische Zugriffskontrolle umfasst die Verfahren und Mechanismen, die die angegebene Vermittlung nach dem Ermessen einer zentralen Systemverwaltung durchsetzen.
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[Diskretionäre Zugriffskontrolle] umfasst diejenigen Verfahren und Mechanismen, die die spezifizierte Vermittlung nach dem Ermessen der einzelnen Benutzer durchsetzen
|
||||
%\item Beispiel: Das Unix-Betriebssystem ermöglicht es den Benutzern, die Zugriffsrechte für Dateien, die ihnen gehören, zu erteilen oder zu entziehen (Lesen, Schreiben, Ausführen).
|
||||
\item[obligatorische Zugriffskontrolle] umfasst die Verfahren und Mechanismen, die die angegebene Vermittlung nach dem Ermessen einer zentralen Systemverwaltung durchsetzen.
|
||||
\end{description*}
|
||||
\item Beide Arten können kombiniert werden, wobei die obligatorischen Zugriffskontrollentscheidungen in den meisten Fällen Vorrang vor den diskretionären Entscheidungen haben
|
||||
\item Beispiel: Verwendung einer diskretionären Zugangskontrolle auf Personalcomputern kombiniert mit einer obligatorischen Zugangskontrolle für die Kommunikation ($\rightarrow$ Firewalls)
|
||||
%\item Beispiel: Verwendung einer diskretionären Zugangskontrolle auf Personalcomputern kombiniert mit einer obligatorischen Zugangskontrolle für die Kommunikation ($\rightarrow$ Firewalls)
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Zugriffsmatrizen}
|
||||
@ -2648,21 +2631,22 @@
|
||||
\begin{itemize*}
|
||||
\item Zugriffskontroll-Listen (ACL)
|
||||
\begin{itemize*}
|
||||
\item ACLs sind die Grundlage für ein Zugriffskontrollschema, bei dem für jedes Objekt eine Liste gültiger Subjekte gespeichert wird, die Zugriff auf dieses Objekt haben könnten (möglicherweise zusammen mit der Art des erlaubten Zugriffs).
|
||||
\item ACLs werden in der Regel bei der diskretionären Zugriffskontrolle verwendet, da es zu viele ACLs gibt, als dass sie von einer zentralen Verwaltungseinrichtung verwaltet werden könnten.
|
||||
\item Grundlage für Zugriffskontrollschema, bei dem für jedes Objekt eine Liste gültiger Subjekte gespeichert wird, die Zugriff auf dieses Objekt haben könnten %(möglicherweise zusammen mit der Art des erlaubten Zugriffs)
|
||||
\item in der Regel bei der diskretionären Zugriffskontrolle verwendet, da es zu viele ACLs gibt, als dass sie von einer zentralen Verwaltungseinrichtung verwaltet werden könnten
|
||||
\end{itemize*}
|
||||
\item Fähigkeiten
|
||||
\item Capabilities
|
||||
\begin{itemize*}
|
||||
\item Capabilities sind gewissermaßen das Gegenkonzept zu ACLs, da bei Capabilities jedes Subjekt eine Liste von Zugriffsrechten auf Objekte besitzt
|
||||
\item Der Vorteil (und die Gefahr) von Capabilities ist, dass ein Subjekt einige seiner Capabilities an andere Subjekte weitergeben kann
|
||||
\item gewissermaßen das Gegenkonzept zu ACLs, da bei Capabilities jedes Subjekt eine Liste von Zugriffsrechten auf Objekte besitzt
|
||||
\item Der Vorteil ist, dass ein Subjekt einige seiner Capabilities an andere Subjekte weitergeben kann
|
||||
\end{itemize*}
|
||||
\item Label-basierte Zugriffskontrolle
|
||||
\begin{itemize*}
|
||||
\item Wenn Sicherheitslabels mit den Entitäten eines Systems gespeichert und verarbeitet werden, können sie zur Durchführung einer label-basierten Zugriffskontrolle verwendet werden
|
||||
\item Dieses Verfahren wird in der Regel als obligatorischer Zugriffskontrollmechanismus verwendet.
|
||||
\item Dieses Verfahren wird in der Regel als obligatorischer Zugriffskontrollmechanismus verwendet
|
||||
\end{itemize*}
|
||||
\item[$\rightarrow$] Die Datenintegrität von Zugriffskontrolldatenstrukturen ist entscheidend!
|
||||
\item[$\rightarrow$] die Datenintegrität von Zugriffskontrolldatenstrukturen ist entscheidend
|
||||
\end{itemize*}
|
||||
\columnbreak
|
||||
|
||||
\section{Integration von Sicherheitsdiensten in Kommunikationsarchitekturen}
|
||||
\subsection{Motivation: Was ist wo zu tun?}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user