SharePoint Governance Teil V: Rechte

Kommen wir nun zum Bereich Rechte. Natürlich ist es auf jeder Plattform essentiell, sich über Rechte oder Berechtigungen zu unterhalten. Hier kommen wir an einen Punkt, der sehr kontrovers und z.T. auch heiss diskutiert wird. Wir wollen versuchen, den Weg der Best Practices zu verfolgen. Um eine saubere Rechtestruktur zu vermitteln, muss ich etwas ausholen und teile diesen Blogpost in verschiedene Teile ein.

Einführung

In der Rechtevergabe bei SharePoint möchte ich es sehr einfach halten. Wir unterscheiden SharePoint Gruppen, Active Directory Gruppen, User und Berechtigungsstufen.

Berechtigungselement Beschreibung
SharePoint Gruppe SharePoint Gruppen werden in SharePoint selbst angelegt. Sie dienen dazu, Inhalte von SharePoint mit Berechtigungen zu versehen. Sie enthalten User oder Active Directory Gruppen, nie aber weitere SharePoint Gruppen. SharePoint Gruppen werden von der IT oder von Super Usern gemanaged und auf Site Collections, Sites, Bibliotheken, Listen oder einzelne Items vergeben.
Active Direcotry Gruppe Diese Gruppen werden von der IT gemanaged. Sie enthalten User und sind z.T. auch im Outlook als Verteilergruppen sichtbar. Sie können in SharePoint Gruppen vergeben oder direkt wie solche verwendet werden.
User User werden von der IT im Active Directory angelegt. Sie regeln den Zugang zu Systemen und setzten sich aus einem Login und einem Passwort zusammen. Zusätzlich können weitere Informationen zum User hinterlegt werden.
Berechtigungsset Sie regeln die eigentliche Berechtigung auf einer Seite bzw. einem Item(Dokumente etc.) Stichwort dazu: CRUD (Create, Read, Update, Delete). Berechtigungssets werden an AD Gruppen, SP Gruppen oder User angehängt.

Es gibt folgende Arten, Berechtigungen zu steuern:

  1. Vergeben von Rechten direkt an User (DON’T DO THIS)
  2. Vergeben von Rechten direkt an AD Gruppen (DON’T DO THIS)
  3. Erstellen von SharePoint Gruppen und einfügen von AD Gruppen
  4. Erstellen von SharePoint Gruppen und einfügen von Usern
  5. Erstellen von SharePoint Gruppen und eine Kombination von 3 + 4 (Für die meisten Szenarien empfohlene Variante)

Es gibt Szenarien, wo es durchaus Sinn macht, alles in AD Gruppen zu steuern und diese in SharePoint Gruppen zu verteilen (Nr. 3) doch meistens macht es sinn, diesen Aufwand von der IT wegzunehmen und an Power User zu übergeben. Warum? Die IT weiss meist so wie so nicht, ob diese Rechte Sinn machen oder nicht. Sie befolgen einen Auftrag, der meist per Formular zu ihnen gekommen ist. Warum nicht die Abteilungen ihre Rechte mit einem definierten Prozess selbstständig regeln lassen? AD Gruppen werden so wie so gepflegt, also alles was so wie so gepflegt wird mit AD Gruppen lösen. Was aus dem Schema fällt löst man dann besser mit einzelnen Usern, welche man den SharePoint Gruppen zusätzlich zu den bereits bestehenden AD Gruppen hinzufügt.

Also nochmal zur Repetition: User kommen automatisch in AD Gruppen. Diese wiederum verteilt man in SharePoint Gruppen, wo das nicht reicht, ergänzt man die SharePoint Gruppen mit einzelnen Usern.

SharePoint Gruppen

Versuchen Sie die meisten Szenarien mit den SharePont Standardgruppen zu lösen. Wenn eine Webseite erstellt wird, so stehen folgende SharePoint Gruppen zur Verfügung.

  1. Besitzer von…
  2. Besucher von…
  3. Mitglieder von…

image

Sobald Publishing (Veröffentlichungs-Infrastruktur) auf Site Collection Ebene aktiviert wird, kommen folgende SharePoint Gruppen dazu:

  1. Anzeigende Benutzer
  2. Designer
  3. Formatressourcenleser
  4. Genehmigende Personen
  5. Hierarchie-Manager
  6. Personen mit eingeschränkten Leserechten

image

Diese Gruppen werden nun auf der Ebene Site Collection, Site, Bibliothek, Liste oder Item vergeben. Natürlich kann man auch beim sogenannten Brechen von Berechtigungen einzelne User oder AD Gruppen vergeben, doch dies ist absolut nicht empfehlenswert, da sonst der Überblick verloren geht.

Rightsmanagement

Eine Site Collection vererbt an seine Inhalte (Unterwebseiten, Bibliotheken, Listen, Items), Eine Webseite vererbt an seine Inhalte (Unterwebseiten, Bibliotheken, Listen, Items), eine Bibliothek bzw. Liste vererbt an seine Inhalte (ggf. Ordner, Items). An jeder Stelle kann die Vererbung gebrochen und eine SharePoint Gruppe, eine AD Gruppe oder ein User eingesetzt werden. Wir auf der Ebene Webseite gebrochen, so vererbt diese Webseite die neu eingesetzten Berechtigungen wiederum auf die Unterwebseiten, Bibliotheken, Listen und Items. Wird auf der Ebene Bibliothek gebrochen, so erben danach ggf. Ordner und Items. Wird auf der Ebene Item gebrochen so betrifft es nur noch dieses Item.

Berechtigungsstufen

Grundsätzlich gibt es sechs Berechtigungsstufen. Natürlich kann man sich ganz individuelle Berechtigungsstufen konfigurieren, doch SharePoint liefert in der Grundstruktur sechs Stufen:

  1. Teilnehmen (Neu: Mitwirken)
  2. Lesen
  3. Vollzugriff
  4. Design
  5. Beschränkter Zugriff
  6. Nur lesen

Designen wird wird oft nur aufgrund von Szenarien gebraucht, bei welchen mit Genehmigungen (Einstellung in einer Bibliothek oder Liste) gearbeitet wird. Es empfiehlt sich jedoch, für Genehmigungen entweder die Publishing Gruppe “Genehmigen” zu benutzen, diese wird allerdings nur sichtbar, wenn Publishing auf der Site Collection aktiviert ist. Wenn Publishing nicht eingesetzt wird oder lediglich die SharePoint Foundation eingesetzt wird würde ich das Teilnehmen Berechtigungsset kopieren, neu benennen und zusätzlich Genehmigungsrechte zu vergeben.

image

Wird das Publishing aktiviert (Veröffentlichungs-Infrastruktur), stehen zusätzlich folgende Berechtigungsstufen zur Verfügung:

  1. Genehmigen
  2. Hierarchie verwalten
  3. Eingeschränkter Lesezugriff

image

Ich rate Ihnen an, sich an diese Standard Gruppen zu halten, denn mit ihnen lassen sich 90% aller Szenarien abbilden. Sie begeben sich auf dünnes Eis, wenn Sie anfangen, eigene Berechtigungsstufen zu erstellen.

Ausnahmen:

  • Sie benötigen ein Berechtigungsset, welches das Löschen von Content ausschliesst, nicht aber das Erstellen oder das Ändern von Content.
  • Sie arbeiten mit SharePoint Fundation und haben an ein- oder mehreren Stellen die Inhaltsgenehmigung aktiviert

Jede SharePoint Gruppe (und wenn man einzelne User oder AD Gruppen direkt berechtigen würde diese auch) erhält nun eine solche Berechtigungsstufe. Die Berechtigungsstufe definiert, welche Rechte die Gruppe am eingesetzten Ort hat. Auch hier gibt es natürlich auch Spielvarianten, wie Gruppe A hat auf der Bibliothek B grundsätzlich “Mitwirken” als Berechtigungsstufe, doch auf dem Ordner X in der Bibliothek B hat die selbe Gruppe A nur “Lesen”. Auch hier ist absolute Vorsicht geboten, man kann also ggf. nicht davon ausgehen, dass eine Gruppe einfach überall diese Rechte hat, wie es den Anschein haben mag.

Roundup

Wie wir nun sehen, ist das Ganze schon an und für sich komplex. Wenn Sie nun anfangen, die Berechtigungen wild zu vergeben (Person X und Y haben Rechte auf Ordner A und B, Person Y und Z haben Rechte auf Ordner C und D etc.), dann werden Sie sich schon bald im puren Chaos wiederfinden. Wie stellt man also sicher, dass die Berechtigungen einigermassen im Griff zu halten sind?

Hier kommen wir nun zurück auf die Rollen. Es ist meines Erachtens zwingend, dass man die definierten Rollen auch gleich dazu verwendet, die Berechtigungen festzulegen. Welche Rolle hat welche Gruppenzugehörigkeit? Damit ist auch gleich klar, was die Rolle für Berechtigungen hat.

Szenario:
Sie haben ein Projekt, in welchem verschiedene Personen involviert sind. Sie möchten gerne die Berechtigungen dazu festlegen, wie gehen sie am besten vor.

Methode A:
Sie vergeben die Berechtigungen der Personen direkt auf die Ordner und Inhalte anhand Ihren Bedürfnissen.

Vorteile Nachteile
  • Direkte und individuelle Vergabe von Rechten möglich
  • Keine Übersicht über die vergebenen Rechte
  • Schwieriges Szenario bei neuen Projektmitgliedern (Wo muss die Person überall berechtigt sein?
  • Viel Zeitaufwand beim managen der Zugriffe
  • Um einigermassen den Überblick zu erhalten muss ein Excel mit den vergebenen Rechten geführt werden.

 

Methode B:
Sie vergeben die Berechtigungen der Personen mittels verschiedenen SharePoint Gruppen

Vorteile Nachteile
  • Gute Übersicht durch vorhandene Gruppen
  • Individuelle Vergabe von Rechten möglich
  • Schwieriges Szenario bei neuen Projektmitgliedern (In welche SharePoint Gruppen muss die Person verteilt werden?)
  • Nach wie vor viel Zeitaufwand beim managen der Zugriffe
  • Es muss ein Excel geführt werden, welche Gruppe wo Zugriff hat, und wer in welcher Gruppe ist.

 

Methode C:
Sie definieren klare Rollen (Projektleiter, Projektassistenz, Projektmitarbeiter, Berater, Besucher), erstellen pro Rolle eine SharePoint Gruppe mit entsprechender Berechtigungsstufe und verteilen die User nach ihren Rollen in eine der Gruppen. Die SharePoint Gruppen werden dann auf den Inhalt verteilt. (Projektleitungsordner etc.)

Vorteile Nachteile
  • Gute Übersicht durch vorhandene Gruppen
  • Schnelle Vergabe von Rechten möglich
  • Klare Verwaltung der Zugriffe
  • Bei Wechsel im Projekt müssen Sie die neue Person nur gemäss ihrer Rolle in eine der Gruppen berechtigen
  • Es braucht lediglich ein Grundkonzept welche Rolle was darf, dies ist danach generisch auf alle weiteren Projekte anwendbar
  • Gewisse Einschränkungen durch die Bindung an ein Rollenmodell und daraus entstehender Mehraufwand bei der Planung

 

Wie Sie sehen, ist Methode C die beste Wahl. Wenn ich betrachte, wie viel Aufwand betrieben werden muss um die Berechtigungen einigermassen im Griff zu halten, ist Methode C die zumindest erfolgversprechendste der drei Methoden. Ansonsten müssen Leintuchmässige Excel Listen geführt werden, um zu wissen, wer wo berechtigt ist.

Fazit

Ich möchte folgende Kernaussagen festhalten:

  • Verwenden Sie die Rollen, um die Berechtigungen zu bestimmen.
  • Nehmen Sie den initialen Aufwand in Kauf, dass für jedes Szenario Rollen gebildet werden müssen, sie werden es dafür später leichter haben.
  • Lassen Sie sich nicht von der Angst der unflexibilität in eine wilde Rechtevergabe treiben
  • Anwender möchten immer gerne alles in einem kleinen Garten geschützt haben (Ich und X haben Zugriff auf Ordner A etc.), doch dies ist nicht verwaltbar.
  • Verwenden Sie möglichst viel die Standardgruppen von SharePoint
  • Verwenden Sie möglichst ausschliesslich die Standard Berechtigungsstufen von SharePoint

Das Berechtigungsmanagement ist eines der heikelsten und auch der kontroversesten Themen im SharePoint. Lassen Sie sich nicht verwirren, es braucht eine Zeit bis man ein klares Konzept davon erfassen kann.

Lo long, Samuel

3 Gedanken zu “SharePoint Governance Teil V: Rechte

  1. Hi Samuel,

    danke für den Beitrag. Aus welchem Grund warnst du in der Einführung vor Variante 2 (AD-Gruppen direkt berechtigen)? In einer Organisation, die in ihrem AD sämtliche funktionalen Rollen und Zuständigkeiten mithilfe von AD-Gruppen abgebildet hat, sind diese doch ideale Träger von Berechtigungen. Sprechende Gruppen-Namen einmal vorausgesetzt. Anders gefragt: Worin liegt der Mehrwert, diese AD-Gruppen noch einmal in eine SharePoint-Gruppe zu legen?

    Danke für deine Erfahrungen hierzu und beste Grüße

    René Fritsch

    • Hoi René, das kann ich dir gerne erklären. Wenn du mal annimmst, dass zwei Teams A und B in einer Firma arbeiten. Team A ist Operations Team B ist Engineering. Nun hat Team A Krankheitsausfälle und Team B soll aushelfen. Dann kannst du die Aushilfe schnell unkompliziert zur entsprechenden Rolle hinzufügen. Das ist Case 1.
      Case 2: Wenn Du Projekte hast, wirst du wohl nicht für jedes Projekt AD Gruppen anlegen wollen oder?? Wenn ja, ist das weit gefehlt in der art und weise, wie SharePoint die Arbeit vereinfachen sollte. User sollen schnell und unkompliziert arbeiten können, und nicht zuerst in einem AD Tool Gruppen anlegen etc.

      Und by the way: Zeig mir bitte mal eine Firma mit sprechenden AD Gruppen, besonders wenn jede funktionale Rolle und Zuständigkeit abgebildet ist 😉

      • Fundierte Antwort! 🙂 Ich war bisher auch der Ansicht von René. Allerdings ist in der Tat die Mischung aus sicherer Organisation und Flexibilität in der Praxisanwendung entscheidend. Der Crux ist, dass die meisten (großen) Firmen es einfach nicht in der Griff bekommen, ihre AD-Gruppen aktuell zu halten. Da wird an Prozessen geschraubt und die simplesten, internen Prozesse hat man nicht im Griff – traurig. „Früher“ hätte man den neuen Mitarbeitern einen Laufzetter in die Hand gedrückt und sie hätten alles erledigt bzw. sich in den Abteilungen angemeldet. Heute gibt es zentrale IT-Systeme und man schafft es kaum, die Mitarbeiten in den wichtigsten AD-Gruppen aktuell zu halten.

        Zurück zu den Rollen! Ich habe immer noch Schwierigkeiten mit der abgrenzung zwischen Rollen und Gruppen in der Praxis der Administration. Vor allem aber bezweifle ich, dass SharePoint ein echtes Rollenkonzept kennt. Mir sind nur zwei Entitäten bekannt: User und Gruppen. Aber vielleicht habe ich die Rollen ja auch übersehen… 😉

        Gruß, Martin

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s