Bundesamt für Sicherheit in der Informationstechnik

M 2.237 Planung der Partitionierung und Replikation im Novell eDirectory

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

Verantwortlich für Umsetzung: Administrator, Leiter IT

Als skalierbarer Verzeichnisdienst bietet eDirectory die Möglichkeit, Teile der Verzeichnisdatenbank in Partitionen zu zerlegen und auf verschiedene eDirectory-Server zu verteilen. Dies verkürzt die mittleren Zugriffszeiten, da die Suche sich unter Umständen nur auf eine spezielle Partition und nicht den gesamten Verzeichnisbaum erstrecken muss. Außerdem erhöht es die Ausfallsicherheit, da bei einem Serverausfall nur die dort befindliche Partition und nicht die gesamte Verzeichnisdatenbank betroffen ist. Weiterhin erlaubt es die Partitionierung, die Daten gemäß einer zuvor vorgenommenen Klassifizierung auf entsprechend gesicherte Server zu verteilen.

Bei der Planung der Partitionierung sind die vom eDirectory definierten Regeln für Partitionen zu berücksichtigen.

Partitionen können wiederum Unterpartitionen enthalten, welche gemäß den festgelegten Regeln gebildet wurden. Auf Partitionen können verschiedene Operationen ausgeführt werden, z. B. Erzeugen, Zusammenführen, Bewegen oder Annullieren einer der genannten Operationen.

Neben dem Mechanismus der Partitionierung des Verzeichnisbaums bietet eDirectory die Möglichkeit, Teile des Verzeichnisbaums auf andere eDirectory-Server zu replizieren. In der Terminologie von eDirectory wird dabei von Replicas gesprochen. In jeder Partition gibt es eine so genannte Master-Replica. Diese bildet den Mittelpunkt der jeweiligen Partition. Das Anlegen neuer Unterpartitionen oder neuer Replicas der aktuellen Partition ist von der Verfügbarkeit des Master-Replica-Servers abhängig. Es gibt verschiedene Möglichkeiten, die Verzeichnisdaten auf andere Server zu replizieren:

  • Read/Write Replica: Auf Read/Write Replicas einer Partition kann genauso zugegriffen werden, wie auf die Master-Replica selbst. Insbesondere ist es in einer Read/Write Replica möglich, Modifikationen der Daten vorzunehmen. Die Informationen werden automatisch zwischen den einzelnen Replicas ausgetauscht. Sofern der Server, auf dem die Master-Replica gehalten wird, dauerhaft ausfällt, kann eine Read/Write Replica zur Master-Replica umkonfiguriert werden.
  • Read-Only Replica: Diese Replicas empfangen lediglich Synchronisations-Updates von anderen Replicas. Clients können den Inhalt einer Read-Only Replica nicht ändern.
  • Filtered Read/Write Replica: Auf diese Server wird lediglich ein Teil einer eDirectory-Partition repliziert. Die Auswahl des replizierten Inhaltes ist dabei sowohl auf der Ebene der Objektklassen als auch auf der Ebene einzelner Attribute möglich. Der Inhalt dieser Replica kann von Clients verändert werden. Bei einer Änderung des Informationsstandes wird der Inhalt automatisch mit den weiteren Replicas synchronisiert.
  • Filtered Read-Only Replica: Dieser Typ einer Replica enthält nur eine Auswahl der gesamten Partition, die zudem nicht durch Clients verändert werden kann. Für die Auswahl des zu replizierenden Inhaltes bestehen die gleichen Möglichkeiten wie bei Filtered Read/Write Replicas.

Die oben beschriebenen Arten von Replicas werden manuell eingerichtet und konfiguriert. Die Replizierung selbst läuft automatisch ab. Ein weiterer Replikationstyp sind die Subordinate-Reference-Replicas. Diese werden vom eDirectory-System jedoch selbst angelegt und verwaltet. Sie enthalten lediglich Sprungadressen, um effizient Objektnamen über Partitionsgrenzen hinweg auflösen zu können (so genanntes tree walking).

Bei der Planung der Partitionen sollten folgende Punkte beachtet werden:

  • Berücksichtigung des Schutzbedarfs: Die Informationen, die im Verzeichnis gehalten werden, sollten gemäß ihrem Schutzbedarf klassifiziert werden. Anhand dieser Klassifizierung sollte die Verteilung der Objekte auf entsprechend geschützte Server erfolgen. Dabei ist darauf zu achten, dass besonders der Inhalt des Security-Containers auf einem ausreichend abgesicherten Server gelagert wird, da es sich hierbei um sensitive Informationen handelt. Im Security-Container werden beispielsweise die Key Management Objects sowie die Security Policies gespeichert.
  • geforderte Verfügbarkeit des Verzeichnisdienstes: Zur Verbesserung der Lastverteilung müssen hinreichend viele Repliken der Verzeichnisdaten auf eDirectory-Servern angelegt werden.
  • Verteilung der Administrationsaufgaben: Damit eine Rollentrennung der Administrationsaufgaben mit der Trennung der Datenhaltung einhergeht, sollten die Administrationsaufgaben auf einzelne Partitionen verteilt werden.
  • Einhaltung der eDirectory-Regeln zur Partitionierung. Die wesentlichen Regeln dabei sind:
    • Jede Partition beginnt hierarchisch mit einem einzelnen Container-Objekt.
    • Die Partition muss ein zusammenhängender Sub-Tree des eDirectory-Baums sein.
    • Verschiedene Partitionen dürfen sich nicht überschneiden.
    • Der Name der Partition muss der Fully Qualified Distinguished Name (FQDN) des Wurzelobjekts der Partition sein.
  • Die genauen Kontexte der Server, welche Partitionen/Replicas halten. Ist die Struktur zu flach, so entsteht ein hoher interner Replizierungsaufwand. Darüber hinaus führen einzelne - momentan nicht verfügbare - Server zu entsprechenden Statusmeldungen bei sämtlichen weiteren in den Replizierungsring eingebundenen eDirectory-Servern.

Bei der Planung der Replicas sind folgende Punkte zu berücksichtigen:

  • Aus den Anforderungen an Verfügbarkeit und Ausfallsicherheit des Verzeichnisdienstes müssen die Vorgaben für die Anzahl der anzulegenden Replicas abgeleitet werden.
  • Die geforderte Systemperformance führt zur Planung der Lastverteilung.
  • Es muss entschieden werden, ob durch die Definition von Filtern für Replicas ein Sicherheitsgewinn erzielt werden kann.
    Dieser liegt vor allem in der Möglichkeit einer getrennten Datenhaltung entsprechend einer zuvor vorgenommenen Klassifizierung der Daten. Es kann damit das Grundprinzip realisiert werden, dass jeder eDirectory-Server nur diejenigen Daten hält, welche er "benötigt" (bzw. welche die zugreifenden Nutzer oder Applikationen benötigen).
    Bei unbedachter Konfiguration kann dieser Sicherheitsgewinn allerdings wirkungslos bleiben. Ein möglicher Nachteil kann die Systemperformance sein. Sind gesuchte Daten auf einem eDirectory-Server nicht vorhanden bzw. nicht sichtbar, weil sie durch entsprechende Filterregeln ausgeblendet sind, so wird im Hintergrund weitergesucht (sofern dies zugelassen ist). Eine nicht bedarfsgerechte Konfiguration der Filterregeln kann also die Systemperformance negativ beeinflussen.
    Beispiel: Ein eDirectory-Server steht im Intranet einer Organisation und eine Teilmenge der dort gehaltenen Verzeichnisdaten soll auch im Internet verfügbar sein. Eine mögliche Lösung ist, einen weiteren eDirectory-Server in der demilitarisierten Zone ( DMZ ) zwischen Intranet und Internet mit einer gefilterten Replica aufzustellen, welche nur die im Internet tatsächlich benötigten Verzeichnisdaten hält.
  • Die Datenhaltung muss geplant werden. Hier geht es um eine möglichst detaillierte Planung, welche Daten von wem und von wo aus zugreifbar sein sollen. Für die Durchsetzung der Vorgaben können beispielsweise gefilterte Replicas eingesetzt werden.

Prüffragen:

  • Sind die Informationen, die im eDirectory-Verzeichnis gehalten werden, gemäß ihrem Schutzbedarf klassifiziert?

  • Wurden aus den Anforderungen an Verfügbarkeit und Ausfallsicherheit des Verzeichnisdienstes die Vorgaben für die Anzahl der anzulegenden Replicas abgeleitet?

  • Planung der Datenhaltung: Existiert eine möglichst detaillierte Planung, welche Daten von wem und von wo aus zugreifbar sein sollen?

Stand: 13. EL Stand 2013