Sicherheits-Guide: So können Sie die MS Graph API Permission „GroupMember.Read.All” gezielt beschränken

Die Microsoft Graph API ist eine extrem mächtige Schnittstelle, um auf Daten und Dienste in Microsoft 365 zuzugreifen. Sie ermöglicht Entwicklern und Administratoren, Unternehmensressourcen wie Benutzer, Gruppen, E-Mails, Kalender und vieles mehr programmatisch zu verwalten. Diese Macht bringt jedoch auch eine große Verantwortung mit sich, insbesondere im Hinblick auf die Vergabe von Berechtigungen. Eine dieser Berechtigungen, die oft zu Diskussionen Anlass gibt, ist **GroupMember.Read.All**. In diesem umfassenden Guide erfahren Sie, warum diese Berechtigung mit Vorsicht zu genießen ist und wie Sie ihren Anwendungsbereich gezielt beschränken können, um das **Prinzip der geringsten Rechte (Least Privilege)** optimal umzusetzen.

### Die Macht der Microsoft Graph API und die Risiken von Broad Permissions

Die Microsoft Graph API ist der Dreh- und Angelpunkt für die Automatisierung und Integration im Microsoft 365 Ökosystem. Sie bietet eine einheitliche Schnittstelle zu einer Vielzahl von Diensten und Daten, was sie zu einem unverzichtbaren Werkzeug für Unternehmen macht. Anwendungen, die mit der Graph API interagieren, benötigen Berechtigungen, um auf diese Daten zugreifen zu können. Diese Berechtigungen werden in Microsoft Entra ID (ehemals Azure Active Directory) definiert und den Anwendungen (Dienstprinzipalen) zugewiesen.

Eine häufig benötigte Berechtigung ist **GroupMember.Read.All**. Auf den ersten Blick scheint sie harmlos: Sie erlaubt einer Anwendung, die Mitglieder *aller* Gruppen in Ihrer Organisation zu lesen. Für viele Szenarien ist dies auch die gewünschte Funktionalität – zum Beispiel, wenn eine Anwendung eine vollständige Übersicht über alle Gruppenzugehörigkeiten benötigt, um Compliance-Prüfungen durchzuführen oder Berichte zu erstellen.

Doch hier liegt die Gefahr: Wenn eine Anwendung mit **GroupMember.Read.All** kompromittiert wird, hat der Angreifer potenziell Zugriff auf die komplette Mitgliederliste *jeder* Gruppe in Ihrem Tenant. Dies umfasst oft auch sensible Informationen über Projektteams, Abteilungen, Zugriffsgruppen für vertrauliche Ressourcen oder sogar private Teams. Ein solcher Datenabfluss kann gravierende Sicherheits- und Datenschutzverletzungen nach sich ziehen.

Das **Prinzip der geringsten Rechte (Least Privilege)** besagt, dass eine Anwendung oder ein Benutzer nur die minimal notwendigen Berechtigungen erhalten sollte, um ihre Aufgaben zu erfüllen. Für **GroupMember.Read.All** bedeutet dies: Wenn eine Anwendung nur die Mitglieder *bestimmter* Gruppen lesen muss, sollte sie nicht die Berechtigung erhalten, die Mitglieder *aller* Gruppen zu lesen. Die Herausforderung besteht jedoch darin, dass die Microsoft Graph API für solche globalen Berechtigungen (mit „All” im Namen) oft keine native Granularität auf Ressourcenebene bietet. Man kann also nicht direkt sagen: „App X darf `GroupMember.Read.All` nur für Gruppe A und Gruppe B nutzen.”

### Das Dilemma: Warum „GroupMember.Read.All” so breit ist

Wie bereits erwähnt, ist **GroupMember.Read.All** eine breite Berechtigung. Sie ist eine sogenannte Anwendungsberechtigung (Application Permission), die einer Anwendung direkt zugewiesen wird und es ihr ermöglicht, als Dienstprinzipal zu agieren, ohne dass ein Benutzer angemeldet sein muss. Das Problem ist, dass es in Microsoft Entra ID keine direkte Möglichkeit gibt, den *Scope* dieser Berechtigung auf eine *Untermenge von Gruppen* zu beschränken. Die Berechtigung gilt entweder für *alle* Gruppen oder für *keine*.

Dies steht im Gegensatz zu anderen Bereichen, wie beispielsweise **Resource-Specific Consent (RSC)** für Microsoft Teams, bei dem Anwendungen sehr granular Berechtigungen für einzelne Teams erhalten können (z.B. „Team.ReadBasic.All” nur für Team X). Für die generelle Verwaltung von Entra ID-Gruppen gibt es diese direkte Granularität jedoch nicht.

Was können wir also tun, wenn eine Anwendung **GroupMember.Read.All** benötigt, aber nur für eine spezifische Auswahl von Gruppen? Der Lösungsansatz besteht in einer Kombination aus sorgfältiger Konfiguration in Microsoft Entra ID und robuster Anwendungslogik. Wir nutzen dabei **Custom Security Attributes (benutzerdefinierte Sicherheitsattribute)**, um die gewünschten Gruppen zu kennzeichnen und die Anwendung anschließend diese Kennzeichnung für ihre Filterung nutzen zu lassen.

### Der Lösungsansatz: Indirekte Beschränkung durch Kontext und Attribute

Da eine direkte Beschränkung der `GroupMember.Read.All`-Berechtigung auf Ebene von Microsoft Entra ID nicht möglich ist, müssen wir einen indirekten Weg gehen. Die Idee ist, nicht die *Berechtigung selbst* zu beschränken, sondern den *Zugriffskontext* und die *Daten*, die die Anwendung tatsächlich verarbeiten darf. Dies erreichen wir durch eine zweistufige Strategie:

1. **Kennzeichnung der erlaubten Ressourcen:** Wir markieren die Gruppen, für die eine Anwendung die Mitglieder lesen darf, mit speziellen **Custom Security Attributes** in Microsoft Entra ID.
2. **Durchsetzung in der Anwendung:** Die Anwendung erhält zwar die breite `GroupMember.Read.All`-Berechtigung, ist aber **programmiertechnisch so implementiert**, dass sie nur diejenigen Gruppen verarbeitet, die die entsprechende Kennzeichnung (das Custom Security Attribute) tragen.

Dieser Ansatz erfordert Disziplin bei der Konfiguration und Entwicklung, bietet aber ein hohes Maß an Kontrolle und Auditmöglichkeiten.

### Schritt 1: Grundlagen – Verstehen und Vorbereiten

Bevor wir ins Detail gehen, stellen Sie sicher, dass Sie die grundlegenden Konzepte verstehen und die notwendigen Vorbereitungen getroffen haben:

* **Identifizierung des Bedarfs:** Klären Sie genau, welche Gruppen die Anwendung tatsächlich benötigt. Erstellen Sie eine Liste dieser Gruppen und dokumentieren Sie den Geschäftszweck.
* **Erstellung eines Dienstprinzipals (Application Registration):** Ihre Anwendung muss als App-Registrierung in Microsoft Entra ID vorhanden sein. Stellen Sie sicher, dass Sie die notwendigen Berechtigungen (Application Administrator oder Cloud Application Administrator Rolle) haben, um App-Registrierungen zu erstellen und zu verwalten.
* **Erteilung von „GroupMember.Read.All”:** Ja, wir müssen diese Berechtigung zunächst erteilen. Gehen Sie dazu wie folgt vor:
1. Navigieren Sie im Microsoft Entra Admin Center zu **Identität > Anwendungen > App-Registrierungen**.
2. Wählen Sie Ihre Anwendung aus.
3. Gehen Sie zu **API-Berechtigungen > Eine Berechtigung hinzufügen**.
4. Wählen Sie **Microsoft Graph**.
5. Wählen Sie **Anwendungsberechtigungen**.
6. Suchen Sie nach `GroupMember.Read.All` und fügen Sie die Berechtigung hinzu.
7. Klicken Sie auf **Administratoreinwilligung für [Ihr Tenantname] erteilen**.

Dies ist der „notwendige Übel”-Schritt. Der nächste Schritt zeigt, wie wir die effektive Reichweite einschränken.

### Schritt 2: Implementierung der Beschränkung mit Custom Security Attributes

**Custom Security Attributes** (benutzerdefinierte Sicherheitsattribute) sind ein relativ neues und mächtiges Feature in Microsoft Entra ID, das es Ihnen erlaubt, eigene, flexible Attribute zu verschiedenen Entra ID-Objekten (z.B. Benutzer, Gruppen, Anwendungen) hinzuzufügen. Diese Attribute können zur Speicherung von Informationen, zur Kategorisierung oder, wie in unserem Fall, zur Steuerung von Zugriffslogik verwendet werden.

#### Was sind Custom Security Attributes?

Stellen Sie sich Custom Security Attributes als erweiterbare Felder vor, die Sie Objekten in Entra ID zuweisen können. Sie sind hochgradig konfigurierbar: Sie können Attributsätze erstellen, die Attribute definieren (z.B. Text, Boolean, Integer, Multiselect), und dann diese Attribute einzelnen Objekten zuweisen.

#### Erstellen von Custom Security Attributes

1. **Navigieren Sie zum Microsoft Entra Admin Center:** Gehen Sie zu **Identität > Benutzer > Benutzereinstellungen**. Scrollen Sie nach unten zum Abschnitt **Benutzerdefinierte Sicherheitsattribute (Vorschau)** und klicken Sie auf **Benutzerdefinierte Sicherheitsattribute hinzufügen/verwalten**. (Alternativ finden Sie es auch unter **Identität > Anwendungen > App-Registrierungen > Benutzerdefinierte Sicherheitsattribute**).
2. **Attributsatz erstellen:** Ein Attributsatz ist ein logischer Container für Ihre Attribute. Klicken Sie auf **Attributsatz hinzufügen**.
* **Name:** Geben Sie einen aussagekräftigen Namen ein, z.B. `Anwendungszugriff`.
* **Beschreibung:** Eine kurze Erklärung, z.B. `Attribute zur Steuerung des Zugriffs von Anwendungen auf bestimmte Ressourcen.`
* Klicken Sie auf **Weiter**.
3. **Attribute definieren:** Innerhalb des Attributsatzes definieren Sie die einzelnen Attribute. Klicken Sie auf **Attribut hinzufügen**.
* **Name:** Wählen Sie einen Namen, z.B. `ErlaubteApp`.
* **Beschreibung:** `Gibt an, welche Anwendung auf diese Gruppe zugreifen darf.`
* **Datentyp:** Wählen Sie `String`.
* **Werte können vordefiniert werden:** Wählen Sie **Ja**.
* **Mehrfachauswahl:** Wählen Sie **Ja**, da möglicherweise mehrere Anwendungen auf eine Gruppe zugreifen dürfen.
* **Definierte Werte:** Fügen Sie die Namen der Anwendungen hinzu, die Sie zulassen möchten, z.B. `MeineBuchhaltungsapp`, `HR-Reportingtool`.
* Klicken Sie auf **Hinzufügen**. Wiederholen Sie diesen Schritt, wenn Sie weitere Attribute benötigen (z.B. `Anwendungszweck`, `Freigabedatum`).
* Klicken Sie auf **Speichern**.

#### Zuweisen von Custom Security Attributes zu Gruppen

Nachdem Sie Ihre Attribute definiert haben, weisen Sie diese den relevanten Gruppen zu:

1. Navigieren Sie im Microsoft Entra Admin Center zu **Identität > Gruppen > Alle Gruppen**.
2. Wählen Sie die Gruppe aus, deren Mitglieder die Anwendung lesen darf.
3. Klicken Sie im Menü links auf **Benutzerdefinierte Sicherheitsattribute (Vorschau)**.
4. Klicken Sie auf **Zuweisung bearbeiten**.
5. Wählen Sie Ihren Attributsatz (z.B. `Anwendungszugriff`).
6. Wählen Sie Ihr Attribut (z.B. `ErlaubteApp`).
7. Wählen Sie aus der Dropdown-Liste die entsprechenden Anwendungsnamen aus (z.B. `MeineBuchhaltungsapp`). Wenn Sie Mehrfachauswahl aktiviert haben, können Sie mehrere Werte auswählen.
8. Klicken Sie auf **Speichern**.
9. Wiederholen Sie diesen Vorgang für alle Gruppen, die von Ihrer Anwendung verarbeitet werden sollen.

**Wichtig:** Das Zuweisen von Custom Security Attributes kann auch automatisiert über die Microsoft Graph API erfolgen, was bei einer großen Anzahl von Gruppen oder dynamischen Anforderungen sehr nützlich ist. Sie benötigen dafür die Berechtigung `CustomSecAttributeDefinition.ReadWrite.All` und `CustomSecAttributeAssignment.ReadWrite.All`.

#### Zuweisung von Berechtigungen für Custom Security Attributes

Um Custom Security Attributes zu verwalten, benötigen Benutzer spezielle Rollen:
* **Attributdefinitionsadministrator:** Kann Attributsätze und Attribute definieren.
* **Attributzuweisungsadministrator:** Kann Attribute zuweisen und entfernen.
Diese Rollen sollten dem Prinzip der geringsten Rechte folgend zugewiesen werden.

### Schritt 3: Anwendungslogik – Die eigentliche Filterung

Dies ist der **kritischste Schritt** zur Beschränkung der **GroupMember.Read.All**-Berechtigung. Die Anwendung selbst muss die Filterung basierend auf den zugewiesenen Custom Security Attributes durchführen.

#### Wie die Anwendung GroupMember.Read.All nutzt

1. **Authentifizierung:** Die Anwendung authentifiziert sich bei Microsoft Entra ID und erhält ein Access Token, das die `GroupMember.Read.All`-Berechtigung enthält.
2. **Abrufen von Gruppen *mit* ihren Custom Security Attributes:**
Die Anwendung ruft zunächst eine Liste aller relevanten Gruppen ab, **inklusive ihrer Custom Security Attributes**. Beachten Sie, dass Sie die Attribute explizit mit `$select` anfordern müssen und sie derzeit *nicht* direkt in der Graph API für `$filter`, `$orderBy` oder `$search` verwendet werden können.
„`http
GET https://graph.microsoft.com/v1.0/groups?$select=id,displayName,customSecurityAttributes
„`
Die Antwort würde etwa so aussehen:
„`json
{
„value”: [
{
„id”: „group-id-1”,
„displayName”: „Buchhaltungsabteilung”,
„customSecurityAttributes”: {
„Anwendungszugriff”: {
„ErlaubteApp”: [ „MeineBuchhaltungsapp” ]
}
}
},
{
„id”: „group-id-2”,
„displayName”: „Marketingteam”,
„customSecurityAttributes”: {
// Keine Attribute oder andere Werte
}
},
// … weitere Gruppen
]
}
„`
3. **Anwendungsseitige Filterung:**
Die Anwendung iteriert nun durch die abgerufenen Gruppen und überprüft für jede Gruppe, ob sie das spezifische Custom Security Attribute mit dem erwarteten Wert besitzt.

* **Beispiel (Pseudocode):**
„`python
allowed_group_ids = []
for group in all_groups:
if „customSecurityAttributes” in group and
„Anwendungszugriff” in group[„customSecurityAttributes”] and
„ErlaubteApp” in group[„customSecurityAttributes”][„Anwendungszugriff”] and
„MeineBuchhaltungsapp” in group[„customSecurityAttributes”][„Anwendungszugriff”][„ErlaubteApp”]:
allowed_group_ids.append(group[„id”])

# Nun verarbeitet die Anwendung nur die Gruppen in ‘allowed_group_ids’
for group_id in allowed_group_ids:
# Beispiel: Mitglieder dieser spezifischen Gruppe abrufen
members = graph_client.get(f”/groups/{group_id}/members”).json()
# … weitere Verarbeitung …
„`
Dieser Schritt ist entscheidend. Die Anwendung **darf keine Gruppen verarbeiten oder deren Mitglieder abrufen**, die nicht die korrekten Custom Security Attributes aufweisen, selbst wenn die `GroupMember.Read.All`-Berechtigung dies technisch erlauben würde.

#### Best Practices für die Anwendungslogik:

* **Jede Abfrage überprüfen:** Stellen Sie sicher, dass diese Filterlogik bei jeder Interaktion mit Gruppendaten angewendet wird.
* **Caching mit Bedacht:** Die Liste der erlaubten Gruppen (und ihre Attribute) kann für eine gewisse Zeitspanne (TTL) zwischengespeichert werden, um die Performance zu verbessern. Achten Sie jedoch darauf, dass der Cache regelmäßig aktualisiert wird, um Änderungen an den Custom Security Attributes widerzuspiegeln.
* **Fehlerbehandlung und Protokollierung:** Protokollieren Sie Versuche, auf nicht autorisierte Gruppen zuzugreifen, als Sicherheitsvorfälle.
* **Code-Reviews:** Führen Sie sorgfältige Code-Reviews durch, um sicherzustellen, dass die Filterlogik korrekt und manipulationssicher implementiert ist.

### Schritt 4: Monitoring und Auditing

Die Implementierung allein reicht nicht aus; Sie müssen auch sicherstellen, dass das System wie erwartet funktioniert und keine Missbräuche stattfinden.

* **Microsoft Entra ID Audit Logs:** Überwachen Sie die Audit-Protokolle in Entra ID. Hier werden Änderungen an den Custom Security Attributes (Wer hat welches Attribut wann zugewiesen?) und die Aktivitäten Ihrer Anwendung (z.B. Token-Anforderungen) protokolliert.
* **Application Insights / Anwendungs-Protokollierung:** Implementieren Sie eine detaillierte Protokollierung innerhalb Ihrer Anwendung. Erfassen Sie, welche Gruppen die Anwendung abgefragt hat, welche Gruppen als „erlaubt” eingestuft wurden und welche als „nicht erlaubt” ignoriert wurden. Dies ist essenziell, um die Einhaltung Ihrer Beschränkungen zu überprüfen.
* **Regelmäßige Überprüfung:** Führen Sie regelmäßige Audits durch, um zu überprüfen, ob die zugewiesenen Custom Security Attributes noch korrekt sind und ob die Berechtigung `GroupMember.Read.All` für die Anwendung überhaupt noch notwendig ist. Passen Sie die Konfigurationen bei Bedarf an das **Prinzip der geringsten Rechte** an.

### Alternative / Ergänzende Maßnahmen

Obwohl Custom Security Attributes und Anwendungslogik der Hauptweg zur Beschränkung sind, können folgende Maßnahmen die Sicherheit zusätzlich erhöhen:

* **Conditional Access Policies:** Beschränken Sie den Zugriff Ihrer Anwendung basierend auf Netzwerkstandorten, Gerätezuständen oder anderen Bedingungen. Dies verhindert zwar nicht den Zugriff auf nicht autorisierte Gruppen, wenn die Anwendung kompromittiert wird, aber es erschwert Angreifern, überhaupt auf die Anwendung zuzugreifen.
* **Privileged Identity Management (PIM):** Wenn die Anwendung hochsensible Daten verarbeitet, können Sie PIM nutzen, um den Zugriff auf die Anwendung selbst (z.B. für die Verwaltung von App-Secrets) oder auf die Rollen, die Custom Security Attributes verwalten, als Just-in-Time-Berechtigung zu konfigurieren.
* **Resource-Specific Consent (RSC):** Für Microsoft Teams ist dies ein natives Feature, um Berechtigungen auf einzelne Teams zu beschränken. Wenn Ihr Anwendungsfall primär Teams-Gruppen betrifft, prüfen Sie, ob RSC für Sie anwendbar ist. Dies ist ein Beispiel dafür, wie granulare Berechtigungen aussehen könnten, ist aber leider nicht auf allgemeine Entra ID-Gruppen übertragbar.

### Fazit: Sicherheit ist ein Prozess

Die Beschränkung der **GroupMember.Read.All**-Berechtigung auf bestimmte Gruppen ist keine triviale Aufgabe, da Microsoft Entra ID hierfür keine native, direkte Filterung auf der Berechtigungsebene anbietet. Der hier vorgestellte Ansatz mit **Custom Security Attributes** in Kombination mit einer sorgfältig implementierten Anwendungslogik bietet jedoch einen effektiven Weg, das **Prinzip der geringsten Rechte** zu wahren und das Risiko eines unkontrollierten Datenzugriffs zu minimieren.

Es ist eine Lösung, die Disziplin bei der Konfiguration, eine robuste Anwendungsentwicklung und fortlaufendes Monitoring erfordert. Doch die Investition in diese Sicherheitsmaßnahmen zahlt sich aus, indem sie Ihre Organisation vor potenziellen Datenlecks schützt und das Vertrauen in Ihre Anwendungen stärkt. Denken Sie daran: **Sicherheit ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess.**