Vergleich zwischen betriebssystemdefinierten Gruppen und ACL-Berechtigung

Anstatt Benutzer mehreren betriebssystemdefinierten Gruppen zuzuweisen, können Sie mit ACLs Elemente mehreren Gruppen zuweisen. Dies vereinfacht die Berechtigungsverwaltung.

Betriebssystemdefinierte Gruppen

In ClearCase Version 8.0 und früheren Releases verfügt jedes VOB-Element über drei Schutzkategorien: Eigner (owner), Gruppe (group) und Andere (other). Für jede Kategorie kann der Administrator die Bits für Lesen (read) und Ausführen (execute) setzen oder löschen. Liegt beispielsweise eine Quellendatei vor, die für den Eigner und die Mitglieder der Elementgruppe, jedoch nicht für alle Benutzer im Netz lesbar sein soll, setzen Sie die folgenden Berechtigungen: owner=read, group=read, other=none. Liegt eine ausführbare Datei für ein Programmiertool vor, können Sie für alle drei Kategorien das Lese- und das Ausführungsbit setzen.

In praktischer Hinsicht erfordert dieses Modell, dass Sie eine eigene Gruppe für jede Klasse von Elementen mit demselben Zugriffsschutz verwenden. Wenn nicht allen Benutzern das Lesen von Elementen in Ihrer VOB gestattet sein soll, müssen Sie other=none angeben und den Zugriff über die Kategorien für Eigner und Gruppe steuern.

Der Eigner eines Elements ist beim Schutz von Elementen nur von begrenztem Nutzen. Somit bleibt nur die Gruppe als wirksames Steuerungselement. Der Eigner eines Elements wird standardmäßig auf den Benutzeraccount gesetzt, der das Element erstellt hat. Wenn mehrere Entwickler vorhanden sind, unterscheiden sich dann die Eigner der Elemente. Dies ist für die Zugriffssteuerung nicht sinnvoll. Einige Administratoren konfigurieren einen Auslöser, um das Eigentumsrecht nach der Elementerstellung an den VOB-Eigneraccount zu übertragen. Dies ist jedoch auch nicht zielführend für die Zugriffssteuerung, da die meisten Benutzer selten die Identität des VOB-Eigners annehmen.

Daher bleibt die Gruppe des Elements als Mechanismus für die Steuerung des Zugriffs auf jedes Element übrig. Der Administrator muss eine eigene Gruppe für jede Klasse von Elementen definieren, die geschützt werden muss. Beispielsweise wird Elementklasse 1 für die Entwickler der Komponente A, Elementklasse 2 für die Entwickler der Komponente B und Elementklasse 3 für alle Entwickler (gemeinsam genutzter Code) definiert. Wenn 25 Komponenten (A-Y) und eine gemeinsame Komponente (Z) vorhanden sind, benötigen Sie 26 Gruppen, um den Zugriff zu steuern. Sie definieren alle Elemente in Komponente A als lesbar nur für Gruppe A. Ebenso gehen Sie bei den Komponenten B-Y vor. Jeder Entwickler der Komponenten A-Y ist ein Mitglied der entsprechenden Gruppe und außerdem ein Mitglied der Gruppe Z. Der Account, der für den Build und die Integration des gesamten Codes verwendet wird, muss ein Mitglied aller Gruppen (A-Z) sein.

Die von ClearCase verwendeten Gruppen sind vom Betriebssystem definiert (Windows-Domäne, UNIX NIS oder LDAP) und werden den Berechtigungsnachweisen eines Benutzers hinzugefügt, wenn er sich bei einem Host anmeldet, auf dem ClearCase ausgeführt wird. Leider kann ein einzelner Benutzer aufgrund von Einschränkungen bei den Netzprotokollen des Betriebssystems und von ClearCase nur 16 Gruppen (UNIX und Linux) oder 32 Gruppen (Windows) gleichzeitig mit ClearCase verwenden. Im obigen Beispiel muss der Account für Build/Integration 26 Gruppen verwenden, um den Build auszuführen. Dies bedeutet, dass entweder komplexe Sequenzen von Buildschritten und Berechtigungsnachweisänderungen durchgeführt werden müssen, um die jeweils für ClearCase aktivierten Gruppen zu definieren, oder weniger Elementklassen/Gruppen verwendet werden müssen, was die Elementsicherheit gefährden könnte. Keine dieser Optionen ist zufriedenstellend.

ACLs für Elemente

Wenn Sie in einer VOB mit Produktstufe 8 in ClearCase 8.0.1 ACLs für den Schutz von Elementen aktivieren, können Sie Ihre Zugriffssteuerungsstrategie in vielen Fällen ändern, in denen sich ansonsten die Begrenzung der Gruppenzugehörigkeit für Benutzer negativ auswirken würde. Möglicherweise ist es hilfreich, wenn Sie sich vor Augen führen, dass Sie mit ACLs Elemente mehreren Gruppen zuordnen können, anstatt Benutzer in mehrere Gruppen einzufügen. Da die Anzahl der zulässigen Gruppen in der effektiven ACL für ein Element wesentlich höher ist als die Anzahl der zulässigen Gruppen für einen Benutzeraccount, ermöglicht dieser Sicherheitsmechanismus einige neue Anwendungsfälle und erleichtert bestehende Anwendungsfälle für den Schutz.

Mit ACLs für Elemente können Sie mehreren einzelnen Benutzern, mehreren Gruppen und einigen Kategorien von "Jeder" Zugriff erteilen. In diesem Thema werden ACLs für Elemente auf der Basis ihrer effektiven ACLs beschrieben. In diesem Thema und zugehörigen Themen finden Sie Beispiele dafür, wie mit einer Kombination aus Rollenzuordnungen und Richtlinien effektive ACLs generiert werden.

Im obigen Beispiel sind 25 Komponenten (A-Y) vorhanden, auf die ein jeweils anderes Team sowie ein Build-Account ("Builder") und keine anderen Benutzer Zugriff haben sollen. Mit ACLs schützen Sie jedes Element in einer Komponente mit einer gemeinsamen effektiven ACL, die der Gruppe A und der Gruppe "Builder" die Änderungsberechtigung erteilt.

Jede andere Komponente (B-Y) verfügt über eine analoge effektive ACL. Auch die Komponente Z (die gemeinsame Komponente) verfügt über eine analoge effektive ACL. In dieser Konfiguration befindet sich der Account für jedes Teammitglied in der entsprechenden Gruppe für seine Komponente sowie in der Gruppe für Z (wie vorher). Der Builder-Account muss sich jedoch nur in der Gruppe "Builder" befinden. Es treten keine Probleme aufgrund der Begrenzung der gleichzeitigen Gruppenzugehörigkeit für den Builder-Account auf.

Darüber hinaus müssen weder komplexe Strategien beim Systembuild angewendet werden, noch ist die Sicherheit der Komponenten A-Y gefährdet. Außerdem besteht die Flexibilität, zusätzliche Gruppen und reinen Lesezugriff auf Elemente hinzuzufügen. Angenommen, die Komponente Z wird von einem eigenen Team verwaltet und die Teams A-Y sollen nur über Lesezugriff verfügen. Dann fügen Sie die Entwickler der Gruppen A-Y der Gruppe "AlleEntw" anstatt der Gruppe Z hinzu. Sie können die Element-ACL der Komponente Z so konfigurieren, dass die Gruppe Z über die Änderungsberechtigung, "AlleEntw" über die Leseberechtigung und "Builder" über die Änderungsberechtigung verfügen.

Ein Entwickler in Team A kann Elemente in der Komponente Z lesen, jedoch nicht modifizieren. (Ohne ACLs ist zu diesem Zweck vor der Operation ein Check-out und ein mkbranch-Auslöser erforderlich, um die Berechtigungen für die Modifizierung des Elements zu überprüfen und eine Operation zurückzuweisen, wenn keine entsprechende Berechtigung vorhanden ist.)

Sie können auch einzelne Accounts zu Element-ACLs hinzufügen. Dies kann sinnvoll sein, wenn einige Einzelpersonen einen bestimmten Zugriff auf eine Komponente benötigen und es sich nicht lohnt, eine neue Betriebssystemgruppe nur zu diesem Zweck zu erstellen. Beispiel: Die Komponente B soll vom entsprechenden Team plus einem weiteren Benutzer ("WeitBen") geändert werden können. Die ACL erteilt dann der Gruppe B, "WeitBen" und "Builder" die Änderungsberechtigung.

Wenn einige Komponenten von mehreren Teams verwaltet werden, sind einige Gruppen aus dem vorherigen Beispiel möglicherweise sogar nicht mehr erforderlich. Angenommen, die Komponente E wird von allen Teammitgliedern für die Komponenten C und D verwaltet. Im Beispiel für 8.0 musste die Gruppe E alle Mitglieder der beiden Gruppen C und D enthalten. Mit ACLs können Sie beide Gruppen in die ACL für die Komponente E aufnehmen und brauchen die Gruppe E anschließend nicht mehr zu verwenden (d. h., Sie können sie aus der Gruppenliste für die Accounts in den Teams C und D entfernen).

Richtlinie und zugehörige Rollenzuordnungen

Die obige Beschreibung basiert auf effektiven ACLs. In einer VOB wird die effektive ACL durch Anwendung einer Rollenzuordnung auf eine Richtlinie generiert. Die VOB-Datenbank berechnet die effektive ACL für jede Rollenzuordnung und stellt sie in den Cache. Jedes Element ist einer Rollenzuordnung zugewiesen. Zur Implementierung der obigen Beispiele benötigen Sie eine eigene Rollenzuordnung für jede Klasse von Elementen (Komponenten A-Z). Sie können alle diese Rollenzuordnungen mit einer einzigen Richtlinie verknüpfen, die das allgemeine Zugriffsschutzmodell beschreibt. Unten finden Sie ein Beispiel für eine Richtlinie und eine Gruppe von Rollenzuordnungen, die die obigen effektiven ACLs ergeben. (In der Praxis empfiehlt sich wahrscheinlich die Hinzufügung eines Benutzers oder einer Gruppe mit Verwaltungsaufgaben, der bzw. die über uneingeschränkten Zugriff auf alle Elemente verfügt.)


Feedback