Bundesamt für Sicherheit in der Informationstechnik

M 4.387 Sichere Vergabe von Zugriffsrechten auf OpenLDAP

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Die richtige Vergabe und korrekte Umsetzung von Zugriffsrechten sind elementare Voraussetzungen, um die Informationssicherheit zu gewährleisten. Wann immer ein Benutzer eine Operation gegen ein Objekt im Verzeichnisdienst richtet, muss entschieden werden, ob es zulässig ist, diese Operation auszuführen. Das Berechtigungskonzept ist im Rahmen der Maßnahme M 2.405 Erstellung einer Sicherheitsrichtlinie für den Einsatz von Verzeichnisdiensten festzulegen. Die dort getroffenen Regelungen müssen in Open LDAP technisch umgesetzt werden. Allgemeine Informationen zu diesem Thema finden sich auch in der Maßnahme M 4.309 Einrichtung von Zugriffsberechtigungen auf Verzeichnisdienste . Der LDAP-Standard bestimmt lediglich, dass eine Zugriffskontrolle stattfinden soll und definiert im Rahmen des Standards Server-Antworten für den Fall, dass Operationen wegen unzureichender Berechtigungen abgewiesen werden. Wie eine Zugriffskontrolle jedoch konkret umzusetzen ist, wird im LDAP-Standard nicht spezifiziert und ist in hohem Maße vom eingesetzten Verzeichnisdienst abhängig. Auf die Vergabe von Zugriffsrechten in OpenLDAP wird deshalb in dieser Maßnahme umfassend eingegangen.

Zugriffskontrolllisten in OpenLDAP

In OpenLDAP werden Zugriffskontrolllisten (Access Control Lists, ACLs) in Form von Direktiven in der Konfiguration geführt. Bei jeder von einem Benutzer ausgelösten Operation wird ermittelt, ob diese durch eine Direktive gedeckt ist.

Eine Zugriffsdirektive hat folgende Syntax:

access to [Zielobjekt]

by [Benutzer] [Berechtigungsumfang]

by [Benutzer] [Berechtigungsumfang]

...

Als Zielobjekt können dabei unter anderem Suffixe, Objekte oder Attribute bestimmt werden. Sogar das Ergebnis einer LDAP-Suche oder bestimmte Attributbelegungen können hier vorgegeben werden. Dabei sind fast beliebige Detailtiefen und Kombinationen möglich, auf die hier nicht eingegangen werden kann. Besonders zu nennen ist jedoch das Zielobjekt *, das alle möglichen Zielobjekte des Verzeichnisdienstes umfasst.

Benutzer

Als Benutzer sieht OpenLDAP unter anderem folgende Eintragungen vor:

  • * für alle Benutzer des Verzeichnisdienstes, einschließlich nicht authentisierter Benutzer
  • anonymus für nicht authentisierte Benutzer
  • users für authentisierte Benutzer (für die Unterscheidung von authentisierten und nicht authentisierten Benutzern siehe M 4.388 Sichere Authentisierung gegenüber OpenLDAP )
  • self für Benutzer, die einen "bind" mit der Identität des Zielobjektes vollzogen haben
  • Distinguished Names (DNs) für voll qualifizierte Benutzer oder reguläre Ausdrücke
  • Attributsfilter, um den Zugriff auf ein Objekt zu gewähren, bei dem der Benutzer in ein Attribut eingetragen ist, beispielsweise als Vorgesetzter einer Person
  • Gruppenattribute, um Zugriffsrechte über statische oder dynamische Gruppenmitgliedschaften zu steuern
  • IP-Einträge für alle Benutzer, deren Client aus einem vorgegeben IP -Adressraum oder mit einer vorgegebenen Domäne verbunden ist

Obwohl von OpenLDAP akzeptiert, sollte die Zugriffssteuerung in keinem Fall anhand der IP-Adressen vorgenommen werden, da IP-Adressen einfach gefälscht werden können.

Berechtigungsumfang

Als Berechtigungsumfang kennt OpenLDAP folgende Werte:

  • none: keine Zugriffsberechtigung
  • disclose: Existenzprüfung zur Fehlerverfolgung
  • auth: Möglichkeit, einen "bind" als Zielobjekt durchzuführen
  • compare: Durchführung von Vergleichen
  • search: Anwendung von Suchfiltern auf das Zielobjekt
  • read: Lesender Zugriff auf das Zielobjekt
  • write: Schreibender Zugriff auf das Zielobjekt (ändern, umbenennen, löschen)
  • manage: Vollzugriff einschließlich der benötigten Rechte, um auf operationelle Attribute zuzugreifen

Daneben existieren noch spezielle Berechtigungen wie "selfwrite". Diese ermöglicht es, lediglich den eigenen DN zu schreiben, beispielsweise um eigene Gruppenmitgliedschaften zu pflegen. Jeder Berechtigungsumfang enthält automatisch alle jeweils vorgenannten. So gibt eine read-Berechtigung auch die Rechte zu "disclose", "auth", "compare" und "search"-Aktionen. Dies ist in der Regel sinnvoll und die Verwendung der "access levels" ist meist ausreichend. Andernfalls können Berechtigungen über privilege-Operatoren detaillierter vergeben werden.

Mehrere "by"-Klauseln

Innerhalb einer Zugriffsdirektive können beliebig viele "by"-Klauseln aufeinander folgen. Die Auswertung innerhalb einer Direktive wird gestoppt, sobald eine zutreffende "by"-Klausel gefunden wird. Dies ist der Fall, sobald ein in der "by"-Klausel genannter Benutzer dem anfragenden Benutzer entspricht oder diesen beinhaltet. Eine klassische Zugriffsdirektive ist z. B.

access to *

by self write

by anonymus auth

by group.exact="CN=admin, ou=groups, DC=bsi, DC=bund, DC=de" write

by users read

Durch diese Direktive kann jeder Benutzer seinen eigenen Eintrag verändern, ein anonymer Benutzer kann jeden Eintrag benutzen, um sich zu authentisieren, Mitglieder der Administratorengruppe können Einträge verändern und ein authentisierter Benutzer kann alle Einträge lesen. Die letzte "by"-Klausel könnte auch "by * read" lauten und hätte den selben Effekt. Da für nicht authentisierte Benutzer bereits die zweite "by"-Klausel zutrifft, wird die vierte Klausel immer nur für authentisierte Benutzer (users) geprüft, die keine Administratoren sind. Wären die erste und vierte "by"-Klausel vertauscht, würden keine Schreibrechte auf Einträge bestehen, da die hinter der "users"-Klausel folgende "group"-Klausel sowie die "self"-Klausel nicht mehr verarbeitet würden. Trifft keine Benutzerangabe in einer Direktive auf einen anfragenden Benutzer zu, wird diesem auch keine Berechtigung gewährt. Bei der Auswertung wird jede Direktive behandelt, als würde sie mit der Klausel "by * none" abschließen, auch wenn diese nicht dort steht.

Mehrere Zugriffsdirektiven

Es können beliebig viele Zugriffsdirektiven aufeinanderfolgen. Die Direktiven werden der Reihe nach abgearbeitet. Eine ACL wird nicht weiter ausgewertet, sobald eine zutreffende Direktive gefunden wird. Eine Direktive gilt als zutreffend, wenn das angefragte Zielobjekt dem aus der Direktive entspricht oder in diesem enthalten ist. Zum Beispiel führen die Direktiven

access to dn.subtree="DC=grundschutz, DC=bsi, DC=bund, DC=de"

by users write

access to dn.subtree="DC=bsi, DC=bund, DC=de"

by users read

dazu, dass authentisierte Benutzer alle Inhalte des fiktiven Teilverzeichnisses bsi.bund.de lesen können und auf Inhalte von grundschutz.bsi.bund.de schreibend zugreifen dürfen. Wären die Direktiven in umgekehrter Reihenfolge angegeben, würde das Schreibrecht entfallen, da eine Operation mit dem Zielobjekt "DC=grundschutz" bereits eine Teilmenge von "DC=bsi, DC=bund, DC=de" ist. Trifft keine Zielobjektangabe irgendeiner Direktive auf ein angefragtes Zielobjekt zu, so wird auf das Zielobjekt auch keine Berechtigung gewährt. Jede Zugriffskontrollliste wird bei der Auswertung behandelt, als würde sie der Direktive "access to * by * none" abschließen, auch wenn diese nicht dort steht.

Reihenfolge und Control Flags

Aus diesen Beispielen wird ersichtlich, dass die Reihenfolge von ACL-Einträgen von großer Bedeutung ist. Es gilt grundsätzlich, dass spezielle Rechte zuerst und allgemeine Rechte zuletzt definiert werden müssen.

Sollte dennoch der Bedarf bestehen, die Berechtigungen weiter auszuwerten, nachdem eine zutreffende Regel gefunden wurde, kann dies durch die Steuerungsschalter ("Control Flags") "continue" (für die Prüfung weiterer "by"-Klauseln innerhalb einer Direktive) und break (für die Prüfung weiterer Direktiven) erreicht werden. Die Control Flags sollten äußerst sparsam eingesetzt werden, da sie eine Zugriffskontrollliste unübersichtlich machen. Es muss beachtet werden, dass eine weitere zutreffende Regel die schon gewährten Rechte ersetzt. Das Control Flag "continue" kann durch eine korrekte Planung der ACL eigentlich immer vermieden werden. Es wird nur benötigt, wenn die "privilege"-Operatoren eingesetzt werden.

Das Control Flag "break" ist dazu geeignet, eine umfassende Berechtigung für spezielle Benutzer an den Anfang einer ACL zu stellen. Zum Beispiel gewährt die folgende Direktive einem für Replikationszwecke eingesetzten Benutzer Leserechte auf das gesamte Verzeichnis, während die Direktive für alle anderen Benutzer "überlesen" wird:

access to *

by dn.exact="[DN des Replikations-Benutzers]" read

by * break

ACL in der slapd-config

Die bisher beschriebene Syntax gilt für die Konfiguration mittels der Konfigurationsdatei "slapd.conf". Wird die Datenbank "slapd-config" verwendet, gilt entsprechend:

olcAccess: {n}to [Zielobjekt]

by [Benutzer] [Berechtigungsumfang]

by [Benutzer] [Berechtigungsumfang]

...

Der optionale Index {n} steuert die Reihenfolge der Einträge, die sich im Gegensatz zur Konfigurationsdatei "slapd.conf" nicht aus deren Positionen in der Datei ergeben kann, da die Verzeichnisdienstobjekte olcAccess auf der gleichen Ebene stehen. Ohne einen Index ist die konfigurationsinterne Reihenfolge und damit die Wirksamkeit der Einträge nicht vorhersehbar.

ACLs global und datenbankspezifisch

Zugriffskontrolllisten lassen sich global und auf Datenbankebene festlegen. Die Zusammenhänge müssen bei der Umsetzung von OpenLDAP korrekt berücksichtigt werden. Datenbank-Direktiven haben Vorrang vor globalen Direktiven. Dabei wird die globale Zugriffskontrollliste an die datenbankspezifische angehängt und die Gesamtliste für die Auswertung durch die Direktive "access to * by * none" abgeschlossen, auch wenn diese nicht eingetragen wurde. Spezielle Direktiven zu Beginn einer globalen ACL werden deshalb bei Kombination mit einer datenbankspezifischen Zugriffskontrollliste oft nicht wie gewünscht umgesetzt.

Zugriffsrechte über Gruppenmitgliedschaften

Die Vergabe von Berechtigungen über Gruppenmitgliedschaften ermöglicht es, die Zugriffsrechteverwaltung und die technische Wartung des slapd-Servers organisatorisch zu trennen. Um Zugriffsrechte zu verwalten, müssen nur noch Gruppenobjekte geändert werden, ein Zugriff auf die Konfiguration selbst ist nicht mehr notwendig.

Werden Zugriffsrechte über Gruppenmitgliedschaften verwaltet, so sind folgende Punkte zu beachten:

  • OpenLDAP löst in der Version 2.4 keine Zugriffsrechte auf, wenn sich Gruppen innerhalb von Gruppen befinden. Als Lösungsansatz bietet OpenLDAP das "Set"-Konzept an. Solange "Sets" in der Version 2.4 als experimentell eingestuft werden, sollten sie in produktiven Umgebungen nicht eingesetzt werden.
  • Es wird empfohlen, das Overlay "memberof" (Member of) einzusetzen. Wenn ein DN einem Gruppenobjekt zugeordnet wird, sorgt das Overlay "memberof" dafür, dass die entsprechende Eigenschaft auch beim DN als operationelles Attribut vermerkt wird. Dadurch werden aufwändige Suchoperationen im Rahmen der Zugriffskontrolle vermieden.

In OpenLDAP besteht für eine ebenfalls von der Konfiguration losgelöste Verwaltung von Zugriffsrechten die Möglichkeit, über den Mechanismus "Access Control Information" (ACI) Zugriffsrechte beim jeweiligen Benutzer zu hinterlegen. ACI ist jedoch sehr aufwändig in der Konfiguration, da jeder Benutzer einzeln einzurichten ist. Zudem ist die Syntax des Mechanismus noch nicht standardisiert, der Mechanismus hat in der Version 2.4 zudem nur einen experimentellen Status. Solange ACI einen experimentellen Status hat, sollte es nicht verwendet werden.

Testen von Zugriffsberechtigungen

Jede Änderung der Zugriffskontrollliste sollte anschließend durch das Werkzeug slapacl überprüft werden. Über das Werkzeug werden ein Benutzer und eine Operation angegeben und slapacl ermittelt, ob diese Operation vom angegebenen Benutzer erfolgreich durchgeführt werden könnte, ohne die Operation tatsächlich durchzuführen. Diese Prüfung sollte insbesondere dann durchgeführt werden, wenn der Zugriff abgelehnt werden soll. Das Tool slapacl prüft gegen die Konfigurationsdatei "slapd.conf". Wirksam ist die geänderte Zugriffskontrollliste aber erst nach einem Start oder Neustart des slapd-Servers. Darum sollte der slapd-Server beim Einsatz der slap*-Werkzeuge immer gestoppt sein. Selbst wenn der Einsatz der slap*-Werkzeuge keine technischen Auswirkungen hat, können Ergebnisse bei laufendem slapd-Server zu falschen Schlussfolgerungen führen.

Es wird empfohlen, aus dem Berechtigungskonzept Testfälle abzuleiten und diese mit dem Werkzeug slapacl zu testen,

  • wenn die Zugriffskontrolllisten wesentlich verändert wurden,
  • wenn neue Backends, Datenbanken oder Suffixe definiert wurden oder
  • wenn OpenLDAP aktualisiert wurde.

Keine Einschränkung des rootDN

Die ACLs gelten grundsätzlich nicht für den rootDN einer Datenbank. Wird er dennoch in Zugriffskontrolllisten einbezogen, so führt dies lediglich zu erhöhtem Administrationsaufwand und einem Performanceverlust. Andererseits ist zu beachten, dass der Verzicht auf Zugriffskontrolllisten nicht dazu führt, dass lediglich der "rootDN"-Zugriff auf den Verzeichnisdienst unter OpenLDAP hat. Ohne Zugriffskontrolllisten greift eine Voreinstellung, die allen, auch anonymen Benutzern, Leserecht auf alle Inhalte des Verzeichnisdienstes gewährt. Auf ACLs darf keinesfalls verzichtet werden.

Komplexität der Zugriffsberechtigungen

Zugriffskontrolllisten können in zahlreichen Einzelaspekten gesteuert werden und fast beliebig komplex sein. Administratoren sollten sich mit den umfangreichen Beispielkonfigurationen im frei verfügbaren OpenLDAP Administrator's Guide vertraut machen. Es wird jedoch darauf hingewiesen, dass sich die in dieser Maßnahme zusammengestellten "access levels" bewährt haben und für die Abbildung von Zugriffsrechten in der Regel ausreichend sind. Insbesondere mit regulären Ausdrücken und Suchfiltern ist vorsichtig zu verfahren, da diese sehr leicht zu umfangreich definiert werden und so ungewollt Zugriffsrechte gewähren. Darüber hinaus schränken sie die Verarbeitungsgeschwindigkeit bei Zugriffen deutlich ein, da ihre Prüfung Ressourcen verbraucht. Je umfangreicher die Zugriffsrechte in der slapd-Server-Konfiguration wird, desto wichtiger sind umfangreiche Tests mittels slapacl. Kommt es hierbei immer wieder zu Fehlern, sollte das Design der Zugriffsrechte grundsätzlich überarbeitet werden.

Prüffragen:

  • Wird ein Berechtigungskonzept für den Zugriff auf Objekte in OpenLDAP technisch umgesetzt?

  • Werden die Zusammenhänge von globalen und datenbankspezifischen ACLs bei der Umsetzung von OpenLDAP korrekt berücksichtigt?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK