Berechtigungsmanagement in Confluence

Confluence ermöglicht Teams rund um ihren Content effizienter und besser zusammenzuarbeiten. In diesem Artikel geben wir einen High-Level Überblick über das flexible Berechtigungssystem von Atlassian Confluence.

Benutzer und Gruppen

In Confluence lassen sich Berechtigungen auf registrierte Benutzer und Gruppen vergeben. Gruppen sind schlicht Listen von Benutzern (oder weiteren Gruppen), die zusammengefasst werden, da sie identische Zugriffsrechte erhalten werden.

Daneben ist es auch möglich, anonymen Benutzern den Zugang zu bestimmten Inhalten und Funktionen zu vergeben. Ist der öffentliche Zugriff aktiviert, wird jeder nicht eingeloggte Benutzer die Rechte eines anonymen Benutzers erhalten. Für anonyme Benutzer kann nur ein eingeschränktes Subset aller Berechtigungen vergeben werden. In den globalen Einstellungen lässt sich der Zugriff in den Allgemeinen Einstellungen unter Globale Berechtigungen erteilen. Neben dem Zugriff auf die Applikation kann dort auch festgelegt werden, ob Benutzerprofile für anonyme Benutzer sichtbar sein sollen.

Es gibt zwei spezielle Gruppen die per Default angelegt sind.

confluence-users

Neu angelegte Benutzer werden automatisch dieser Gruppe zugewiesen. Entsprechend erhalten Sie nach der Erstellung automatisch die Berechtigungen dieser Gruppe zugeteilt. Wird diese Gruppe gelöscht, haben neue Benutzer keine Berechtigungen.

confluence-administrators

Die Mitglieder dieser Gruppe erhalten Zugriff auf die Administrationsmasken von Confluence. Administrationsrechte lassen sich auch ohne diese Gruppe erteilen. Entsprechend kann diese auch gelöscht werden, sofern vorher die Administrationsrechte auf anderem Weg gesichert wurden – andernfalls kann sich der Administrator so ausschliessen. Es empfiehlt sich daher ein vorgängiges Backup.

Das optimale Lizenzmodell wählen

Das Preismodell von Confluence ist anhand der Anzahl Benutzer abgestuft. Werden zum Beispiel 90 Benutzer mit Confluence arbeiten, muss eine Lizenz für 100 Benutzer beschafft werden. Verlässt ein Mitarbeiter die Firma, kann sein Benutzeraccount deaktiviert werden. Seine Daten bleiben dann noch erhalten, aber er belegt keine Lizenz mehr. Besonders wenn eine grosse Anzahl Benutzer über externe Benutzerverzeichnisse wie das Active Directory der Firma integriert werden, ist es oft schwer die Anzahl belegten Benutzerlizenzen über die Benutzeroberfläche zu ermitteln. Über eine SQL-Datenbankabfrage lässt sich dies jedoch in den meisten Fällen bewerkstelligen und kann oft bereits Optimierungspotential offenlegen.

Eine aus Sicht der Softwarelizenzierung wichtige Eigenschaft des anonymen Benutzerzugriffs ist, dass unabhängig von deren Zahl und Zugriffshäufigkeit kein Einfluss auf das Preismodell besteht. Ausschliesslich registrierte Benutzer, die Zugriff auf die Applikation haben, belegen eine Benutzerlizenz. Nutzen in ihrem Unternehmen viele Benutzer das System lesend oder die Identität der Benutzer ist unwesentlich, sollten Sie daher prüfen, ob diese überhaupt ein eigenes Applikationslogin erhalten sollen oder ob die Zugriffsmöglichkeiten der anonymen Benutzer ausreicht. Selbstverständlich ist zu beachten, dass die diesen Benutzern zugänglich gemachten Informationen dann defacto innerhalb des Netzwerks öffentlich gemacht werden. Steht das System in einem geschützten Netzwerk, werden sie, je nach Sicherheitsrelevanz der Informationen, dies potentiell durch die Netzwerkkonfiguration als ausreichend geschützt betrachten können. Ausserdem wird durch anonymen Zugriff die Nachvollziehbarkeit und damit die Auditierbarkeit von Zugriffen und Änderungen stark eingeschränkt, was möglicherweise unerwünscht oder situationsabhängig auch aufgrund regulatorischer Vorgaben verboten sein kann.

Organisatorische Skalierung über dezentrales Berechtigungsmanagement möglich

Alle Inhalte in Confluence werden jeweils in einem Container genannt Bereich oder englisch Space abgelegt. Für jeden Bereich können unterschiedliche Bereichsadministratoren definiert werden. Diese haben dann zwar keine globalen Administrationsrechte in Confluence, können jedoch innerhalb ihres Bereichs den Inhalt und die Zugriffe darauf verwalten. So lassen sich in grösseren Organisationen die Administrationsaufgaben auf mehrere Personen aufteilen oder dezentralisieren. Beispielsweise kann die HR-Leitung als Administrator des Bereichs HR definiert werden um zu ermöglichen, dass diese selbstständig gewisse Inhalte nur für bestimmte Führungspersonen sichtbar macht oder ähnlich.

Das Berechtigungssystem von Confluence ist dazu hierarchisch in drei Ebenen gegliedert. Die beiden ersten in der Grafik dargestellten Ebenen funktionieren dabei nach einen Whitelist-Ansatz. Nur wer explizit eine Berechtigung aufweist, erhält Zugriff zu Informationen. Die Dritte Stufe sind Einschränkungen auf bestimmte Inhaltsseiten, die ähnlich einer Blacklist definiert werden. Ist keine spezielle Einschränkung auf der Inhaltsseite definiert, haben per Default alle Zugriff, die auf die Applikation und den jeweiligen Bereich berechtigt sind.

Auf der ersten Ebene stehen globale Einstellungen, welche nur durch den Confluence Systemadministrator vergeben werden können. Dazu zählt die Verwaltung des Benutzerverzeichnisses respektive die Integration von externen Benutzerverzeichnissen, die Vergabe globaler Berechtigungen und die Definition von Standardberechtigungen für neu erstellte Bereiche.

Für registrierte Benutzer und Gruppen können neben dem grundlegenden Applikationszugriff selbst folgende globalen Berechtigungen vergeben werden:

  • Kann der Benutzer für sich einen persönlichen Bereich erstellen? Hier kann er persönliche Notizen, Linklisten usw. ablegen, ein persönliches Blog führen oder Informationen für andere bereitstellen, die nicht direkt in einen anderen Bereich passen.
  • Kann der Benutzer selbst neue Bereiche erstellen? Er wird dort nach der Erstellung automatisch als Bereichsadministrator eingetragen.
  • Ist der Benutzer ein Confluence-Administrator oder ein Systemadministrator mit Zugriff auf globale Einstellungen? Der Systemadministrator hat dabei Zugriff auch auf sicherheitsrelevante Einstellungen, während dem der Confluence-Administrator nur ausgewählte Einstellungen verändern kann. Die genauen Unterschiede können der Produktdokumentation entnommen werden. Die Berechtigung als Confluence-Administrator unterscheidet sich trotz sehr ähnlichem Namen mit der vorgängig in diesem Artikel erläuterten, speziellen Gruppe confluence-administrators. Die Mitglieder dieser speziellen Gruppe erhalten gegenüber den Benutzern mit Berechtigungen für die Confluence-Administration zusätzliche Rechte (vgl. Produktdokumentation). Dies kann einige Verwirrung stiften, ist jedoch in der Regel nur für grössere Organisationen relevant, die ihre Berechtigungen für die Confluence-Administration aufteilen wollen.

Feingranulare Berechtigungsverwaltung bis auf die einzelne Informationsseite

Innerhalb der Bereiche können die Berechtigungen feingranular definiert werden. Dabei werden auf der zweiten hierarchischen Ebene des Berechtigungssystem zuerst bereichsweit geltende Berechtigungen definiert. Für eine Gruppe, individuelle Benutzer sowie auch den anonymen Zugang können mehrere Berechtigungen vergeben werden. In den folgenden Abschnitten wird zur einfacheren Lesbarkeit jeweils von Benutzer gesprochen, unabhängig davon, ob dieser Benutzer die Berechtigung individuell zugewiesen erhält oder über eine Gruppe, deren Mitglied er ist, berechtigt wird.

Üblicherweise stellt die Berechtigung, Inhalte des Bereichs angezeigt zu erhalten, die Grundberechtigung dar die mindestens vergeben wird. Weiter kann danach einzeln für Seiten, Blogartikel, Anhänge und Kommentare definiert werden, ob diese erstellt (und geändert) und/oder gelöscht werden können. Ausserdem lässt sich separat festlegen, dass beispielsweise nur eigene Inhalte gelöscht werden können. Als eigener Inhalt gilt dabei alles, was der Benutzer selbst ursprünglich erstellt hat, unabhängig davon, ob diese Inhalte später von anderen Benutzern überarbeitet oder ergänzt wurden.

Als besondere Privilegierungen kann zusätzlich eingestellt werden, ob der Benutzer auf den Seiteninhalten weitere Zugriffsbeschränkungen definieren darf, ob auf dem Mailweg in das System eingegangene Inhalte gelöscht werden dürfen und ob der Benutzer den ganzen Bereich exportieren oder administrieren darf.

Ist ein Benutzer Mitglied mehrerer Gruppen oder erhält zusätzlich zu Gruppenberechtigungen als individueller Benutzer weitere Berechtigungen zugewiesen, ist zu beachten, dass die Berechtigungen sich kumulieren. Der Benutzer erhält also die Summe aller erteilten Rechte. Es ist daher nicht möglich, eine Benutzer über eine individuelle Berechtigung einzelne Rechte wieder zu entziehen, die er über eine Gruppenberechtigung erhalten hat. Ausserdem erhält jeder registrierte und eingeloggte Benutzer mindestens alle Rechte, die auch einem anonymen Benutzer erteilt wurden.

Die erläuterten Bereichsberechtigungen können grundsätzlich auch anonymen Benutzern erteilt werden. In der Regel werden hier jedoch nur Anzeigerechte und womöglich die Berechtigung für die Erfassung von Kommentaren erteilt.

Auf der Ebene der einzelnen Informationsseiten können danach Anzeige- und Bearbeitungs-Beschränkungen definiert werden. Per Default sind keine Beschränkungen gesetzt, jeder mit der jeweiligen Berechtigung auf der Stufe Bereich kann die Informationsseite einsehen oder editieren. Hier kann nun pro Seite ausserdem nur die Bearbeitung alleine oder gleichzeitig die Anzeige und die Bearbeitung zusammen weiter auf bestimmte Benutzer oder Gruppen eingeschränkt werden.

Die Beschränkung wird so auf einer bestimmten Inhaltsseite hinterlegt. Es werden nicht automatisch Änderungen in den Beschränkungseinstellungen untergeordneter Seiten vorgenommen, jedoch gibt es im Falle der Anzeige eine Vererbungsregel. Im nachfolgenden Beispiel wird eine Anzeigebeschränkung auf der Inhaltsseite mit dem Titel Projektleitung definiert.

In der Folge kann auch auf die untergeordneten Seiten Planung und Statusberichte nur noch von denjenigen Benutzern zugegriffen werden, welche auch auf die Seite Projektleitung Zugriff hat. Es ist nicht möglich, diese Beschränkung auf einer untergeordneten Seite wieder aufzuheben.

Zu beachten ist jedoch, dass, wenn die untergeordnete Seite Planung nun verschoben wird und beispielsweise unterhalb der Seite Konzept angeordnet wird, diese geerbte Anzeigebeschränkung automatisch für diese Seite wieder aufgehoben wird.

Dies verhält sich – was durchaus verwirrend sein kann – anders bei Bearbeitungsbeschränkungen. Im nachfolgenden Beispiel wird nur eine Bearbeitungsbeschränkung auf der Seite Projektleitung definiert.

Diese Beschränkung wird danach nicht vererbt. Das bedeutet also, dass die Seiten Planung und Statusberichte weiterhin ohne Einschränkungen bearbeitet werden können. Ist eine Vererbung erwünscht, muss diese auch auf den Unterseiten manuell eingetragen werden. Falls diese Beschränkung auf Unterseiten erfasst wird, bleiben diese Beschränkungen natürlich auch bestehen, wenn die Seite später verschoben wird.

Best Practice: Berechtigungen bevorzugt über Gruppen und auf Ebene Bereich

Als Best Practice empfiehlt sich einerseits, bei der Vergabe von Berechtigungen in erster Linie Berechtigungen an passende Gruppen zu erteilen und nicht individuelle Benutzer. Dies reduziert den Administrationsaufwand erheblich und sorgt für konsistente und durchgängige Berechtigungskonzepte.

Andererseits sollten Seitenbeschränkungen massvoll eingesetzt werden, da diese rasch unübersichtlich werden. Während dem der Einsatz von Anzeigebeschränkungen aufgrund ihrer Vererbungseigenschaft durchaus auch im Rahmen eines Berechtigungskonzepts noch relativ konsistent angewendet werden können, sind gerade Bearbeitungsbeschränkungen rasch ein Flickwerk da sie für jede relevante Seite neu vergeben werden müssen. Punktuell oder temporär kann es durchaus Anwendungsfälle für Bearbeitungsbeschränkungen geben. Doch stellt sich heraus, das eine bestimmte Themengruppe von Inhalten nur eingeschränkt bearbeitet werden dürfen, empfiehlt sich die Erstellung eines separaten Confluence Bereichs.


Über den Autor

Stefan Haller ist zertifizierter Confluence Administrator und Spezialist für Berechtigungskonzepte und Datenschutz bei linkyard. Benötigen Sie Unterstützung bei der Konzeption oder Bereinigung Ihres Berechtigungsmanagements? Möchten Sie für mehrere Applikationen ein Single Sign-on realisieren? Benötigen Sie eine Zwei-Faktor Authentisierung für Ihr Confluence oder eine andere Applikation? Melden Sie sich bei: stefan.haller@linkyard.ch | +41 78 746 51 16