Archiv

Posts Tagged ‘Berechtigungen’

Best Practice: Berechtigungskonzepte für Teamsites in SharePoint

In vielen Unternehmen werden Teamsites für die elektronische Zusammenarbeit in Projekten von der IT-Abteilung zur Verfügung gestellt. Dabei gibt es das zwei gegensätzliche Arten von Konzepten:

  1. Die IT gibt das Berechtigungskonzept (für alle Teamsites gleich) vor und die Business-User müssen sich in die vorgegebenen Benutzergruppen einordnen
  2. Die IT überlässt komplett dem Besitzer der Teamsite alle Freiheiten und damit viel Gestaltungsspielraum (Self-Service Gedanke)

Einige Vor- und Nachteile beider Konzepte liegen augenscheinlich auf der Hand – eine tiefere Analyse mit Entscheidungskriterien ist ein gesonderter Blogartikel wert.

Für das zweite Modell möchte hier mal ein paar wichtige Regeln und Guidelines beschreiben, da meist die IT-Abteilung hier keinerlei Beratung der Business-User (Fachseite) übernimmt.

Auf keinen Fall:

  • zu viele Personen als Site-Owner berechtigen
  • einzelne Benutzer mit Berechtigungen für Inhalte versehen
  • Berechtigungen für einzelne Ordner (nur in begründeten Ausnahmefällen) in Dokumentenbibliotheken vergeben
  • Berechtigungen für einzelne Dateien in Dokumentenbibliotheken vergeben (-> schlimmer geht’s nicht)

Auf jeden Fall:

Dokumentieren:

  • Anforderungen aufnehmen von Personen, die in der Teamsite arbeiten wollen:
    • Welcher Inhalt?
    • Wer liest diesen Inhalt?
    • Wer schreibt diesen Inhalt?
    • Wer darf auf keinen Fall diesen Inhalt sehen?
  • Schriftliches Dokumentieren des angelegten Berechtigungsmodells

Benutzergruppen:

  • Benutzergruppen anlegen für jede Interessensgruppe – je mehr desto besser
  • Anwender in Benutzergruppen einteilen – gerne auch einen Anwender in mehrere Benutzergruppen.
  • Als Gruppenbesitzer für jede Gruppe die „Admin-„Gruppe (mit Site-Owner Rechten) eintragen
  • Die Gruppe der Site-Owner möglichst nach dem Highlander-Prinzip verwalten – max. eine oder zwei weitere Person als Urlaubsvertretung

Berechtigungen:

  • Am besten die Rechte für jede Benutzergruppe für die ganze Teamsite festlegen und damit das auf alle Inhaltselemente (Listen & Bibliotheken) automatisch runter vererben lassen. -> Vererbung von Rechten nur im begründeten Ausnahmefall brechen
  • Berechtigungen nur auf Ebene der Dokumentenbibliotheken vergeben – also lieber mehr Bibliotheken als weniger
  • Request-Access Option für die Teamsite auf jeden Fall aktivieren und am Besten die Anträge an eine Verteiler-Mail-Adresse schicken lassen, so das immer jemand im Büro ist, der dann die Leute berechtigt.
  • Simpel: Neu hinzukommende User fragen, in welcher Interessensgruppe sie sind, und danach in eine oder mehrere Benutzergruppe einsortieren

(to be continued)

Berechtigungen konzipieren und verwalten für eigene SharePoint Anwendungen

23. November 2012 Hinterlasse einen Kommentar

Vor der Erstellung eines Berechtigungskonzepts für Portale und eigenen Anwendungen in SharePoint steht immer eine fachliche Analyse und Konzipierung von fachlichen Nutzerrollen. (Wenn das bei Ihnen bisher noch nicht so war, dann sollte das dringend geändert werden.) Trotzdem kommt es anschließend fast immer zu nachträglichen (wenn auch minimalen) Anpassungen im Berechtigungskonzept.

Use Cases und weiter

Im Rahmen dieser fachlichen Anforderungsanalyse werden meist auch Use Cases (fachliche Anwendungsfälle) schriftlich ausformuliert. In den Use Cases werden als Akteure fachliche Benutzerrollen zum Tragen kommen.

Die Herausforderung ist das Mapping zwischen fachlichen Use Cases und den daraus entstehenden Aktionen/Funktionen auf Daten in SharePoint. Also welcher Teil von CRUD auf welche SharePoint Liste oder SharePoint Item. Öfters werden solche Aktionen mittels Standard-Actions aus der Ribbon-Bar oder selbst entwickelten Custom-Actions durchgeführt.

Irgendwann in dem Prozess wird es ein Mapping von fachlichen Nutzerrollen auf technische Benutzergruppen im Active Directory und/oder im SharePoint Server geben. Entweder ist es ein reines 1:1 Mapping, oder ein 1:n Mapping; je nach Konzeption der Portalstruktur und der (meist schon vorhandenen) Gruppen im Active Directory.

Definieren von Berechtigungs-Sets und Berechtigungen

Die Permission-Levels (Berechtigungs-Sets) spielen eine entscheidende Rolle. Entweder werden die standardmäßigen Permission Levels (Reader, Contributer, …) verwendet, oder es werden eigene Permission Levels aus den 36 Einzelberechtigungen (Auflistung der Permissions für SharePoint 2010) zusammengestellt. Ich empfehle die Definitionen von eigenen Permission Levels, welche anschließend einer Benutzergruppe zugewiesen werden. Zur Definition eigener Levels bietet sich diese Vorlage (Excel-Tabelle siehe diesen Blog-Post) an.

In diesem Schritt muss auch definiert werden, welches definierte Permission-Level auf welchen Bereich (z.B. „Site“, Liste“) in den Site Collections und Websites angewendet wird.

Das gute an der Erfassung in Excel-Listen ist die Abstimmung mit dem Anforderer und nachträgliche Änderungen. Weiterhin kann man diese gut den Entwicklern zur Umsetzung übergeben.

P.S. Ein Teil 2 nach diesem Blog-Post ist in Planung.

Quellen und weitere Literatur-Tipps:

%d Bloggern gefällt das: