Autorisierung
Hierbei wird festgelegt, was beispielsweise ein User auf einer Webseite oder einem Rechner an Zugriffsrechten (Lesen, Schreiben, Löschen,Erzeugen,…) hat. Danach erfolgt wie Zugriffskontrolle durch das System.
Zugriffskontrolle
Überprüft den Zugriff auf aktiv nicht manipulierbar auf Korrektheit und erlaubt oder lehnt dann den Zugriff auf eine Datei/ Objekt ab.
Access Control Lists (ACLs)
ACLs werden bei Unix-basierten Systemen zur Zugriffskontrolle verwendet, Hierbei wird einem Ordner oder einer Datei mittels ACL Parameter die Zugriffseigenschaft festgelegt. Die Semantik ist dabei relativ einfach definiert und wie folgt aufgebaut (zur Erklärung durch Doppelpunkte getrennt und mit Variablen gekennzeichnet): O:BBB:GGG:AAA
O gibt an, ob es sich um ein „l“, eine Verlinkung, „d“, einen Ordner oder „-“ eine Datei handelt. Danach folgen jeweils drei Gruppen mit jeweils drei Variablen. Die erste Dreiergruppe steht hierbei für den Besitzer, der den Link, den Ordner oder die Datei angelegt hat, die zweite Dreiergruppe für eine (variable definierbare) Gruppe, beispielsweise könnte man auf einem Firmen-Server folgende Gruppen festlegen: Vorstand, Abteilungsleiter, Mitarbeiter und Kunden. Jede Gruppe hätte dann eine eigens definierte Domäne, also Dateizugriffsrechte. Und zu guter letzt noch Rechte für alle anderen Benuter, welche nicht von den vorherigen Gruppen betroffen sind.
Das erste Objekt ist ein Link, dessen Besitzer der Admin war und die Gruppenzugehörigkeit der Datei ist „wheel“ definiert. (Wheel ist in BSD eine Abkürzung für „big wheel“ was für eine starke Person steht und traditionelle der Sicherheitsgruppe Null in BSD ist. Die Gruppe Wheel ist eine der wichtigsten systeminternen Gruppen zu denen auch der Administrator (Root) gehört.)
Die ersten Variablen definieren den Zugriff für den Benitzer: hier „rwx“.
„r“ steht für den Lesezugriff, „w“ für den Schreibzugriff und „x“ dass root dieses Objekt ausführen darf.
Die Gruppe „wheel“ hat dagegen nur folgenden Zugriff: „r-x“, das steht dafür, dass die Gruppe nur lesen und ausführen darf. Alle anderen Benutzer des Systems haben die Zugriffsrechte „r-x“, also die selben rechte wie die Gruppe wheel, lesen und ausführen.
Das Zweite Objekt ist eine Datei, dessen Besitzer wieder root ist und der Gruppe wheel gehört. Die Datei darf vom Admin gelesen und geschrieben werden. Die Gruppe wheel darf nur lesen und alle anderen Nutzer haben keinen Zugriff.
Das letzte Objekt aus dem Beispiel ist ein Ordner, dessen Besitzer wieder root ist und der Gruppe wheel gehört. Root hat hier volle Lese- und Schreibrechte, und darf den Ordner auch „ausführen“, sprich öffnen.
Die Gruppe wheel darf den Ordner öffnen und lesen, genauso die anderen Benutzer des Systems.
Modelle für Zugriffskontrollen
Discretionary Access Control (DAC)
Hierbei legt der Eigentümer des Objekts die Zugriffsrechte für Subjekte fest, dies ist ein gängiges Verfahren in Unix Systemen.
Mandatory Access Control (MAC)
Eine Autorität z.B. ein Projektleiter lässt die Zugriffsrechte durch einen Systemadministrator festsetzen. Diese Art der Zugriffskontrolle wird bei Behörden wie beispielsweise BND, BKA und LKA zur Geheimhaltung von staatlichen Dokumenten verwendet. Hier legt der Entscheidungsträger der verschiedenen Behörde die Zugriffsrecht für das operatives Personal fest. Zudem kommen noch lokale Faktoren hinzu. So hat ein Bearbeiter welcher Behördenintern auf das Dateisystem zugreift mehr rechte als wenn er von Extern zugreift.
Role-Based Access Control (RBAC)
Zugriffsrechte durch Rolle festgelegt (i.d.R. mit MAC). Diese Methode ist bei (Web-)Server typisch, hier legt der Systemadministrator die Ordnerhierarchie fest, und vergibt die zugehörigen Rechte. Vereinfacht dargestellt: Ein (Web-)Seitenbesucher der die Seite Aufruft, darf nur lesen, Ein der Webdesigner Dateien nur verändern und ein Administrator darf Dateien anlegen und auch löschen.
Attribute-Based Access Control (ABAC)
Role-Based Access Control nur etwas feiner gestaltete Zugriffsrechte gemäß logischer Formeln. Ein gutes Beispiel für dieses Modell ist das Bell-LaPadula Sicherheitskonzept.
Bell-LaPadula (BLP)
Diese Sicherheitsprinzip wurde in den 70er Jahren von David Elliott Bell und Leonard J. LaPadula für US Air Force entwickelt. Ziel war es die Sicherheit der Vertraulichkeit zu verbessern. Dafür wurde eine logische Formel mittels eines Systems durchgesetzt um die Vertraulichkeit von Informationen besser zu schützen. Es darf nicht möglich sein, Informationen einer höheren Sicherheitsstufe lesen zu können um dadurch Informationen der höheren Schutzstufe in eine Niedrigere zu überführen.
Kurze Erklärung, wenn ich keine Informationen von einer übergestellten Instanz bekommen kann, kann ich diese auch nicht (wissentlich oder unwissentlich) in meine Geheimhaltungsstufe oder niedriger verteilen. Jedoch können übergestellte Instanzen auf gleich oder weniger geheime Dokumente zugreifen. Logische Formel: „no read-up and no write-down“.
Quelle: Wikipedia.
Simple Security Property (no read-up and no write-down)
Dieser Mechanismus verhindert, dass Benutzer mit höheren Rechten in Dateien mit niedrigeren Rechten schreiben und damit Informationen preisgeben. Nachteil ist jedoch, dass es keinen Integritätsschutz in Form von „write-up“ gibt. Bedeutet Es darf von Mitarbeitern tiefere Sicherheitsebene nicht erlaubt sein, Daten in eine höhere Sicherheitsebene zu schreiben. Also wenn ein Bearbeiter aus einer höheren Stufe eine Änderung, z.B. in Form einer Ergänzung oder Anmerkung im Dokument vornimmt, so ist das Dokument ab diesem Moment für den Ersteller gesperrt.
Identität
Eine Identität wird in den System genötigt um überhaupt ein System nutzen zu können. Schließlich muss ich in einem System eine Rolle annehmen um mit diesem interagieren zu können. Wie oben schon angesprochen gibt es in einem System verschiedene Identitäten, beispielsweise die des Administrators, des Mitarbeiters oder eines Besuchers. Über diese Identitäten werden dann die verschiedenen Berechtigungen zugeteilt (Rollen- oder Rechteverteilung).
Eine Identität wird meist mit der Zugangskontrolle eines Systems verknüpft, so wird beim Einloggen in ein System eine Identität beispielsweise durch Eingabe eines Benutzername und dem zugehörigen Passwort überprüft. Hierbei ist hinter dem Benutzernamen ein Account und damit verbundene Zugriffsrechte verknüpft.
Bei der Erstellung eines Benutzers in einem (sicheren) System muss eine Identitätsüberprüfung erfolgen. Je nach dem welche Relevanz das System mit sich trägt. Beispiel für ein „sicheres“ System mit einer Identitätsüberprüfung ist das eröffnen eines Bankkontos. Hierbei überprüft die Bank Ihre Identität mittels Personalausweise und gibt Ihnen Zugang zu einem Konto. Dabei verlässt sich die Bank auf die Korrektheit eines Zertifikats / Dokuments in Form Ihres Personalausweisen. Diese Form der Identitäsfeststellung lautet föderierte Identität. Hierbei vertraut die Bank dem Ausstellers des Personalausweises.
föderierte Identität
Bei der föderierte Identität besteht ein „Circle-of-Trust“, das bedeutet ein Serviceprovider verlässt sich auf die Integrität eines Identität-Providers.
Zum Beispiel bietet ein Serviceprovider die Anmeldung mittels vorhandenem Amazon Account an, hierbei verlässt sich der Serviceprovider auf die Integrität von Amazon und erstellt auf dieser Grundlage einen Account, mit dem sich der Benutzer beim Serviceprovider mittels Amazonaccount einloggen kann. Technischerablauf:
- Zugriffsanfrage durch den Benutzer aus den Service des Providers
- Serviceprovider erfragt Identität des Benutzers
- Benutzer Identifiziert sich mittels Amazonaccount
- Serviceprovider erfragt Autorisierung bei Amazon für den Benutzer
- Amazon erfragt Autorisierung beim Benutzer durch Login
- Benutzer legitimiert sich über gültigen Login bei Amazon
- Amazon sendet dem Serviceprovider die Autorisierung des Benutzers
- Serviceprovider erteilt Legitimation für den Benutzer
Natürlich ist hierbei eine Standardisierung für diesen Ablauf zwischen den Verschieden Instanzen essentiell. Siehe SAML, OAUTH2.0.
Security Assertion Markup Language (SAML)
SAML ist eine XML-basierte Sprache zum Austausch von Authentisierungs-/Autorisierungsinformation bei dem entweder nur eine Authentisierungsbestätigung (User ist ist Authentisiert) erfolgt oder Autorisierungsinformation (Attribute, wie z.B. Adresse oder Berechtigungen) übertragen werden können. Leider gab es auch in der Vergangenheit gezielte Angriffe auf genau diese Art der Anmeldung mittels HTTP Session Cookies Klau.
Angriff auf SAML
Die wohl einfachste Methode Cookies zu stehlen besteht darin dem Opfer einen Link auf eine präparierte Seite zu schicken, auf der dann die Cookies ausgelesen werden. Siehe Cross-Site-Scripting (auch XSS).
Noch gefährlicher ist dies, wenn der Angreifer seinen Skript-Code direkt auf der Webseite zum Beispiel als Blog-Kommentar, Wiki-Seite oder Foren-Beitrag platzieren kann.
Antworten