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:
- Vergeben von Rechten direkt an User (DON’T DO THIS)
- Vergeben von Rechten direkt an AD Gruppen (DON’T DO THIS)
- Erstellen von SharePoint Gruppen und einfügen von AD Gruppen
- Erstellen von SharePoint Gruppen und einfügen von Usern
- 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.
- Besitzer von…
- Besucher von…
- Mitglieder von…
Sobald Publishing (Veröffentlichungs-Infrastruktur) auf Site Collection Ebene aktiviert wird, kommen folgende SharePoint Gruppen dazu:
- Anzeigende Benutzer
- Designer
- Formatressourcenleser
- Genehmigende Personen
- Hierarchie-Manager
- Personen mit eingeschränkten Leserechten
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.
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:
- Teilnehmen (Neu: Mitwirken)
- Lesen
- Vollzugriff
- Design
- Beschränkter Zugriff
- 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.
Wird das Publishing aktiviert (Veröffentlichungs-Infrastruktur), stehen zusätzlich folgende Berechtigungsstufen zur Verfügung:
- Genehmigen
- Hierarchie verwalten
- Eingeschränkter Lesezugriff
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
Spread the Word, Share this Post
Gefällt mir Wird geladen …