Berechtigungen in Microsoft 365 Gruppen

Four steps to Teams success

Kennen Sie das „Need-to-Know-Prinzip“? Falls nicht, werfen Sie noch einmal einen kurzen Blick auf die Definition des BSI:

„Eine der goldenen Regeln der Informationssicherheit ist das „Need-to-Know-Prinzip“: Jeder Benutzer (und auch jeder Administrator) sollte nur auf die Datenbestände zugreifen und die Programme ausführen dürfen, die er für seine tägliche Arbeit auch wirklich benötigt. Dazu gehört auch, dass Informationen einer Abteilung (z. B. Vertrieb, Entwicklung. Personal, Leitung etc.) nicht ohne weiteres von abteilungsfremden Mitarbeitern einsehbar sind, sofern sie diese Informationen nicht für ihre Arbeit benötigen.“

BSI Leitfaden Informationssicherheit

Kurz zusammengefasst:

„Jeder Benutzer sollte auf so viele Informationen Zugriff haben wie nötig, jedoch auf so wenige wie möglich.“

In klassischen Systemen, wie zum Beispiel Netzlaufwerken wird dieses Prinzip ständig verletzt, denn zum Beispiel IT-Administratoren können theoretisch überall hereinschauen (obwohl sie es gar nicht müssten).
Das verbessert sich mit Microsoft 365 und überträgt die Verantwortung der Berechtigungsvergabe von der IT in das Unternehmen.
Wie das funktioniert beschreibt der folgende Artikel.

Azure Active Directory

Das Active Directory ist der führende Verzeichnisdienst in fast allen Unternehmen.
In der On-Premise Welt können Benutzer und Gruppen in Organisatorischen Einheiten (OUs) organisiert werden und später auf die verschiedenen Services (über z.B. LDAP oder NTFS-Security) berechtigt werden.
Doch in der Cloud gibt es kein Active Directory mehr (auch kein LDAP).

Bei der Einführung von Microsoft 365 kann es passieren, dass Ihnen das Azure Active Directory (AAD) wie eine „Cloud Variante“ des Active Directories vorkommt.
Dies ist aber nicht richtig.
Zum Beispiel gibt es im AAD keine OUs mehr, um Ihre Gruppen in eine logische Struktur zu bringen. Und LDAP wurde durch OAuth 2.0 abgelöst.
Technisch gesehen haben AD und AAD tatsälich nichts mehr gemeinsam, obwohl es natürlich möglich ist beide Welten über AAD-Sync miteinander zu verbinden.
Eine der größten Neuerungen im AAD sind jedoch die Microsoft 365 Gruppen.
Angelegt werden können diese im Admin-Center, genau wie normale Sicherheitsgruppen:

Diese Herangehensweise ist allerdings sehr ungewöhnlich, denn die meisten Microsoft 365 Gruppen werden von normalen Benutzern über Apps erzeugt und nicht von globalen Admins.

Nach dem Anlegen einer neuen Gruppe werden Sie darum gebeten eine Mitgliederliste festzulegen:

Sie können im Bild erkennen, dass eine Gruppe zwei Arten von Teilnehmern hat: Besitzer und Mitglieder.
Besitzer werden beim Anlegen der Gruppe definiert. Im Admin Center kann dieser Besitzer frei gewählt werden. Falls die Gruppe jedoch (wie meistens) durch eine App wie z.B. Teams erzeugt wird, ist der Besitzer immer der Erzeuger des Teams.

Wie Anwender zu Gruppenmitgliedern werden

Der Besitzer einer Gruppe ist in der Lage andere Benutzer zu einer Gruppe hinzuzufügen. Und weil die Gruppe ihre Berechtigungen an alle zugehörigen Apps weiter vererbt, werden diese Rechte dann auch an Teams/SharePoint etc. weitergegeben. Für einen normalen Benutzer sieht es also so aus, als würde er z.B. ein Mitglied zu einem Team hinzufügen. In Wahrheit fügt er das Mitglied aber der Gruppe hinzu. Dies braucht der normale Anwender aber gar nicht zu verstehen.

Außerdem erhält der Besitzer ebenfalls alle Anfragen, wenn Benutzer der Gruppe beitreten möchten.
Nehmen wir zum Beispiel an, es gäbe eine Microsoft 365 Gruppe mit dem Namen „Betriebsversammlung“.
Herr Müller wünscht sich nun, in diese Gruppe aufgenommen zu werden. Ein weiteres Mitglied der Gruppe könnte nun eine Anfrage an den Besitzer stellen Herrn Müller mit in die Gruppe aufzunehmen.
In Teams sähe das z.B. folgendermaßen aus:

Ein Besitzer braucht natürlich keine Anfrage zu stellen – er ist ja selbst der Besitzer.

Es gibt also folgende Wege, wie ein Anwender Mitglied einer Gruppe werden kann:

  • Er wird vom globalen Administrator als Mitglied hinzugefügt (sollte die Ausnahme sein)
  • Er wird vom Besitzer als Mitglied hinzugefügt (der normale Weg)
  • Er wird von einem bereits bestehenden Mitglied eingeladen (wenn der Owner zustimmt)

Es gibt tatsächlich noch einige weitere Wege, wie z.B. über einen Code, eine Drittsoftware und falls das Team öffentlich ist durch eine eigene Anfrage (das ging früher auch bei privaten Teams, wurde aber abgeschafft).

Besitzer sind keine besseren Mitglieder

Aus der Perspektive eines Benutzers sind Besitzer „bessere Mitglieder“. Denn sie können schließlich mehr als das normale Mitglied (Mitglieder hinzufügen, Gruppe umbenennen…)
Das sieht aber nur für den normalen Benutzer so aus. In Wirklichkeit wird nämlich beim Anlegen einer neuen Gruppe, der Erzeuger der Gruppe automatisch zu einem Besitzer und zu einem Mitglied gemacht.
Haben Sie zum Beispiel ein neues Team erzeugt, können Sie als globaler Admin Ihren Namen doppelt finden:

John Doe ist Besitzer und Mitglied:

  • Er ist Besitzer, damit er die administrativen Aufgaben, wie Mitglieder hinzufügen, Gruppe umbenennen etc. übernehmen kann.
  • Er ist Mitglied, weil er selbst mitarbeiten möchte.

Wenn Sie also über das Admincenter Berechtigungen vergeben oder Gruppen erzeugen, legen Sie einen Benutzer immer als Mitglied und als Besitzer fest.
Ein Teilnehmer, der nur Besitzer aber kein Mitglied ist, wird in seiner Mitarbeit in den jeweiligen Apps sehr eingeschränkt sein.
Apps wie Outlook, Teams oder SharePoint verstecken dieses Verhalten, in dem sie automatisch Besitzer auch zu Mitgliedern machen. Auch die doppelte Anzeige gibt es nicht.

Best practice: Gruppenbesitzer müssen auch Gruppenmitglieder sein.

Besitzer sind keine IT Admins

Früher wurde oft die IT dazu „missbraucht“ Berechtigungen zu setzen. Diese Zeiten gehen mit Microsoft 365 zu Ende (sie waren schon mit SharePoint zu Ende), denn hier können auch Abteilungsleiter, Projektmanager oder Geschäftsführer Berechtigungen setzen. Genauso darf ein IT Admin nicht einfach überall heimlich hereinschauen wie es ihm Spaß macht (auch das war früher möglich und verletzte die Compliance).
Überlassen Sie Ihren Führungskräften das Vergeben von Berechtigungen, denn die wissen ohnehin viel besser als die IT, wer etwas sehen/bearbeiten dürfen soll. Die IT sollte nur für den Support (und eventuelles Training) verantwortlich sein.

Best practice: Die IT sollte keine Berechtigungen vergeben.

Mitgliederberechtigungen

Mitglieder dürfen in der Microsoft 365 Gruppe mitarbeiten.
D.h. sie können Dokumente lesen & bearbeiten, sich an Diskussionen in Chaträumen beteiligen oder Termine im Kalender erzeugen.
Allerdings können die Berechtigungen der Mitglieder auch vom Besitzer eingeschränkt werden.
Diese Einschränkungen sind von App zu App unerschiedlich. In Teams zum Beispiel haben Besitzer in den Teameinstellungen die Möglichkeit Mitglieder zu beschränken:

Besonders auf Dokmentenebene können die Standardberechtigungen manchmal nicht ausreichend sein.
Zum Beispiel mag es sein, dass ein Teil eines Teams nur für „besondere Mitglieder“ zur Verfügung steht. Wenn es sich dabei nur um Dokumente handelt, so lässt sich mit SharePoint eine geschützte Bibliothek erzeugen, auf die nur eine Teilmenge der Mitglieder Zugriff hat (zum Beispiel nur die Besitzer).
Falls aber auch Konversationen privat gehalten werden sollen, können private Kanäle angelegt werden.
Doch Vorsicht: Jeder private Kanal erzeugt wieder eine komplette SharePoint Sitecollection für die Dokumente und hat das Potential erneut eine Gefahr für Ihre Governance zu sein.
Gehen Sie behutsam mit privaten Kanälen um.

An dieser Stelle möchte ich mir sogar eine persönliche Bemerkung erlauben: In meinen Augen sind private Kanäle fast nie notwendig, denn:

  • Wenn Gruppenmitglieder privat miteinander reden möchten, sollten Sie einen Gruppenchat verwenden.
  • Wenn Gruppenmitglieder private Dokumente zu einem Thema teilen möchten, sollten sie eine geschützte SharePoint Bibliothek verwenden und diese ggf. ins Team einbinden.
  • Wenn Gruppenmitglieder sich einen privaten Bereich für Pläne, OneNote etc. wünschen, sollen Sie sich eine eigene Gruppe erzeugen.

Private Kanäle zerstören die einfache Struktur einer Microsoft 365 Gruppe und erschweren der IT den Überblick. Leider sind über 25.000 Menschen anderer Meinung und Microsoft führte die privaten Kanäle sehr widerwillig ein.

Private & Public

Berechtigungen in Microsoft 365 Gruppen haben noch eine weitere Dimension. Und das ist die Unterscheidung zwischen privaten und öffentlichen Gruppen.
Egal aus welcher App sie eine Gruppe erzeugen, müssen Sie immer die Entscheidung treffen, ob die Gruppe „Privat“ oder „Öffentlich“ sein soll:

Der Unterschied zwischen privaten und öffentlichen Gruppen ist leicht erklärt:

  1. Eine private Gruppe wird von einem Besitzer erzeugt und nur Mitglieder, die er hinzufügt können Teil der Gruppe sein.
  2. Eine öffentliche Gruppe kann von jedem Mitarbeiter Ihres Unternehmens betreten oder verlassen werden. Es kann also jeder Lesen & Schreiben.

Vielleicht fragen Sie sich jetzt, ob öffentliche Gruppen überhaupt sinnvoll sind und tatsächlich sind sie eher eine Seltenheit. Doch tatsächlich gibt es einige Anwendungsfälle, wo sie durchaus Sinn ergeben.
Zum Beispiel wäre eine Gruppe „ERP Kurse“ vorstellbar, wo jeder Mitarbeiter, der an ERP-Schulungen interessiert ist beitreten kann.
Das hat den Vorteil, dass niemand sich die Arbeit machen muss 200 Mitglieder einem Team hinzuzufügen.
In 98% aller Fälle werden Sie aber vermutlich eine private Gruppe anlegen.

Es gibt außerdem auch die Möglichkeit Organizationsweite Teams zu erzeugen, wo jeder Mitarbeiter automatisch Mitglied ist.

Zugriff von Nicht-Mitgliedern

Um diesen Abschnitt zu verstehen, sollten Sie mit den Grundlagen von SharePoint bereits etwas vertraut sein.
Oben wurde bereits der Fall erwähnt, dass sich eine Teilmenge der Gruppenmitglieder in einen privaten Bereich zurückziehen möchte. Der umgekehrte Fall tritt jedoch sogar noch häufiger auf.
Was geschieht, wenn z.B. der Geschäftsführer Zugriff auf ein Dokument der Gruppe wünscht, jedoch nichts von der Zusammenarbeit mitbekommen möchte?
Dieser „Zugriff von außen“ kann, wenn es um Dokumente geht, elegant gelöst werden. Alle anderen Aspekte einer Gruppe (wie zum Beispiel die Kanäle eines Teams oder Pläne) lassen jedoch keinen Zugriff von außen zu. Wer auf diese Dinge Zugriff wünscht, muss Mitglied des Teams werden. Auch ein lesender Zugriff auf diese Resourcen ist nicht möglich (und auch nicht sinnvoll)

Kommen wir also zurück zu den Dokumenten, die – wie wir inzwischen wissen – immer in SharePoint gespeichert werden.
Überhaupt erfüllt SharePoint eine Sonderstellung in der Microsoft 365 Landschaft, weil es das Repository für alle Dokumente ist und daher der einzige nicht-optionale Teil einer Gruppe ist.

Mit SharePoint haben Sie folgende Möglichkeiten Nicht-Gruppenmitgliedern Zugriff auf Dokumente zu gewähren:

  1. Teilen Sie ein einzelnes Dokument oder einen Ordner über einen Link.
  2. Teilen Sie ein einzelnes Dokument oder einen Ordner über direkten Zugriff.
  3. Teilen Sie eine komplette Dokumentenbibliothek (oder die ganze Seite) mit einer Gruppe Mitarbeitern.
  4. Teilen Sie ein einzelndes Dokument oder einen Ordner über einen Link mit einem externen Benutzer.

1 Teilen eines Links

Teilen Sie einen Link, wenn Sie einem sehr kleinen Personenkreis von außen Zugriff geben möchten (zum Beispiel einer Führungsperson).
Doch vorsicht: Solche Links können einfach weiter geleitet und dann ggf. von nicht autorisierten Parteien geöffnet werden.
Die Zugriffsrechte liegen also im Link und nicht in der Identität des Empfängers.

Best practice: Teilen Sie einen Link mit maximal sechs Personen.

Die GUI ist ohnehin nicht dafür ausgelegt, sonderlich viele Mitarbeiter in der Liste anzuzeigen.

2 Teilen über direkten Zugriff

Mit direktem Zugriff erteilen Sie eine Berechtigung auf das Dokument, die nicht am Link, sondern an der Identität des Benutzers hängt. Verwenden Sie dieses Feature, wenn Sie einer größeren Personenzahl auf eine einzelne Datei oder einen Ordner Zugriff gewähren möchten.

Best practice: Wenn Sie mehrere Dateien mit einer externen Gruppe von Personen teilen möchten, verwenden Sie eine eigene Dokumentenbibliothek.

3 Teilen einer Dokumentenbibliothek

Eine ganze Bibliothek zu erzeugen und nach außen zu teilen ist die beste Strategie, wenn Sie mehrere Dokumente (oder sogar Ordner) nach außen teilen möchten. Sie könnten zwar auch einen ganzen Ordner mit Unterordnern über direkten Zugriff teilen, doch dies führt schnell zu sehr unübersichtlichen Berechtigungsstrukturen. Es empfielt sich also nur Einzeldateien über Methode 1 oder 2 nach außen zu teilen.
Komplette Ordner sollten nie oder nur selten auf diese Weisen geteilt werden. Bis auf eine Ausnahme, die im nächsten Abschnitt beschrieben wird.

4 Teilen eines Links mit einem externen Benutzer

Sie können auch Dokumente außerhalb Ihrer Organisation teilen (das macht immer dann Sinn, wenn derjenige nicht sowieso als Gast in Ihrem Tenant existiert)
In einem solchen Fall bietet sich ebenfalls das Teilen einer Datei (oder eines Ordners!) nach außen an.
Eine komplette Dokumentenbibliothek auf diese Weise zu teilen ist nicht möglich, weshalb sich dieser Ansatz gut für die Zusammenarbeit an mehreren Dokumenten mit einem externen Benutzer zu arbeiten.

Ein Beispiel

Alle vier Möglichkeiten sind im folgenden Bild noch einmal zusammengefasst:

Schauen Sie sich das Bild genau an.
Sie können sehen, dass die Mitglieder der Gruppe „My team“ auf alle Apps Zugriff haben und dort Lesen & Schreiben dürfen (grüne Pfeile).
In SharePoint gibt es jedoch drei Bibliotheken, deren Zugriff ganz anders aussieht:

  1. Die Bibliothek „Dokumente“ wird mit den Dokumenten aus den Teams Kanälen gefüllt. Daher haben auch hier alle Mitglieder Lese/Schreib-Zugriff (wieder ein grüner Pfeil).
    Einige Herren aus dem Management wollen zwar nicht mitarbeiten (wie es ja oft der Fall ist ;-), sind aber trotzdem interessiert an den Arbeitsdokumenten.
    Daher wurden Ihnen in SharePoint zusätzliche Berechtigungen erteilt, obwohl Sie eigentlich nicht zur Gruppe gehören. Sie dürfen daher ebenfalls lesen & schreiben (drei grüne Pfeile).
    Ein einzelner Buchhaltungsmitarbeiter und ein externer Berater haben außerdem auf einige Dateien Lese und Schreibzugriff per Link und direktem Zugriff erhalten (gestrichelte grüne Pfeile).
  2. Die Bibliothek „Quartalsberichte“ ist nur für das Management zugreifbar. Sogar die Mitglieder der Gruppe dürfen nicht in die Dokumente schauen (daher rote Pfeile für alle, die keine Manager sind).
  3. Die Bibliothek „Shared“ ist für alle Mitarbeiter des gesamten Unternehmens lesbar (deswegen ein gelber Pfeil).
    Die Mitglieder und das Management können hier sogar schreiben (wieder grün).

Das dargestellte Szenario stellt keine unrealistische Anforderung dar.
Zwar wird es von Microsoft inzwischen empfohlen so wenige solcher Szenarien wie möglich zu erzeugen, weil auch das oft zu Chaos führt.
Doch hat man inzwischen auch eingesehen, dass die reinen Microsoft 365 Gruppenberechtigungen nicht für viele Geschäftsanforderungen ausreichen.

Wenn Sie dieses Beispiel verstanden haben, kennen Sie die wichtigsten Grundlagen. SharePoint-Berechtigungen können allerdings auch beliebig komplex werden…

Sensivity labels

Wenn die normalen Berechtigungen in SharePoint nicht ausreichend sind, gibt es auch noch die Möglichkeit einzelne Dokumente zu labeln.
Ein solches Label ordnet ein Dokument einer bestimmten Sicherheitskategorie zu, sodass es wirklich nur von dem entsprechenden Personenkreis gelesen oder geschrieben werden kann.
Das Label „folgt“ der Datei auch, wenn diese heruntergeladen und z.B. irgendwoanders gespeichert wird.
Somit lassen sich extrem komplexe Berechtigungsszenarien abbilden. Vorsicht daher!
Dieses Thema geht jedoch über die normalen Berechtigungen von Microsoft 365 Gruppen hinaus und gewinnt erst dann an Signifikanz, wenn eine gesamte Gouvernance Struktur geschaffen werden muss, die über die Cloud hinausgehen soll.
Lesen Sie hier mehr zu sensivity labels

Information barriers

Auch die Kommunikation zwischen Benutzern eines Microsoft 365 Tenants kann eingeschränkt werden. Dies kann sinnvoll sein, wenn es zum Beispiel konkurierende Teams gibt, die nicht in der Lage sein sollen direkt miteinander zu kommunizieren.
Information barriers gehen über das Thema von GroupHive hinaus und sind nur in bestimmten Fällen wirklich sinnvoll.