Intune Rollen und Berechtigungen richtig verstehen

Das häufigste Berechtigungsmodell, das ich in kleineren Umgebungen immer noch antreffe: “Wer mit Intune arbeitet, bekommt Global Administrator.” Das funktioniert - bis es das nicht mehr tut. Ein Helpdesk-Mitarbeiter löscht das falsche Autopilot-Gerät, oder ein Praktikant mit zu vielen Rechten rollt eine Compliance-Richtlinie tenant-weit aus. Genau dafür gibt es Intune’s rollenbasierte Zugriffskontrolle (RBAC) - und es lohnt sich, sie von Anfang an sauber aufzusetzen, statt sie erst nachzurüsten, wenn schon etwas schiefgelaufen ist.

Built-in Rollen

Im Intune Admin Center unter Tenant-Verwaltung > Rollen findest du eine Reihe von vordefinierten Rollen, die die meisten Alltagsszenarien abdecken:

• Intune Administrator - volle Kontrolle über den Intune-Dienst, aber nicht über andere Microsoft-365-Workloads. Das sollten die meisten deiner Intune-Admins bekommen, nicht Global Administrator.
• Helpdesk Operator - kann Geräte- und Benutzerdetails einsehen, ein Gerät zurücksetzen (Retire/Wipe) oder neu starten, aber keine Richtlinien, Profile oder App-Zuweisungen anfassen. Diese Rolle vergebe ich am häufigsten an den First-Level-Support.
• Policy and Profile Manager - kann Konfigurationsprofile und Compliance-Richtlinien erstellen und zuweisen, ohne Apps oder die Registrierung zu verwalten.
• Application Manager - verwaltet App-Zuweisungen und App-Protection-Richtlinien, sonst nichts.
• School Administrator - eine schmalere Rolle für Bildungs-Tenants (Intune for Education).
• Read Only Operator - genau das, was der Name sagt: alles einsehen, nichts ändern. Praktisch für Auditoren oder eine Führungsperson, die Einblick will, ohne Schreibrechte zu brauchen.

Jede Built-in-Rolle kommt mit einem fixen, vordefinierten Satz an Berechtigungen - du kannst sie zuweisen, aber nicht anpassen, was sie darf.

Custom Roles

Wenn keine der Built-in-Rollen passt, kannst du eine Custom Role von Grund auf erstellen oder eine bestehende Rolle duplizieren und anpassen. Berechtigungen in einer Custom Role sind nach Objekttyp gruppiert - Managed Devices, Mobile Apps, Compliance Policies, Configuration Profiles, Enrollment usw. - jeweils mit granularen Aktionen wie Read, Create, Update, Delete oder Assign.

Ein Muster, das ich oft einsetze: Helpdesk Operator duplizieren und genau die eine zusätzliche Berechtigung ergänzen, die ein bestimmtes Team wirklich braucht (zum Beispiel “Managed Apps > Assign” für ein regionales IT-Team, das seine App-Rollouts selbst macht) - statt es gleich auf Intune Administrator hochzustufen. Kleinere, additive Custom Roles sind später viel einfacher nachzuvollziehen als eine Handvoll breiter Rollen.

Scope Tags: die andere Hälfte von RBAC

Eine Rollenzuweisung beantwortet für sich allein nur die Frage “was darf diese Person tun”. Scope Tags beantworten die zweite Frage: “auf welchen Geräten, Benutzern oder Objekten”. Ohne Scope Tag gilt eine Rollenzuweisung tenant-weit - ein Helpdesk Operator ohne Scope Tag kann jedes Gerät im Tenant zurücksetzen, nicht nur die des eigenen Standorts oder der eigenen Abteilung.

Ich nutze Scope Tags ständig, um Zugriff auf bestimmte Standorte, Abteilungen oder Gerätegruppen zu delegieren, ohne Rollen pro Standort zu duplizieren. Wie man einen Scope Tag über Autopilot vergibt und bis in die Intune- und Defender-for-Endpoint-Gerätegruppen mitführt, habe ich hier im Detail beschrieben: Defender for Endpoint Scope Tag mit Autopilot und Intune - derselbe Scope-Tag-Mechanismus gilt genauso für Konfigurationsprofile, Compliance-Richtlinien und Apps, nicht nur fürs Defender-Onboarding.

Ein praktisches Beispiel

Nehmen wir an, du hast drei Regionalbüros, jedes mit eigenem IT-Ansprechpartner vor Ort, der nur die Geräte seines eigenen Standorts verwalten soll:

1. Erstelle pro Region einen Scope Tag (Region-CH, Region-DE, Region-US).
2. Weise den Scope Tag den passenden Autopilot-Geräten, Gruppen und Richtlinien der jeweiligen Region zu.
3. Dupliziere die Helpdesk-Operator-Rolle einmal pro Region und weise jede Kopie dem jeweiligen Regionalkontakt zu, gescoped auf den Tag seiner Region.

Jeder Regionalkontakt sieht und verwaltet jetzt nur noch seine eigenen Geräte in der Intune-Konsole - nicht weil du drei separate Custom Roles mit unterschiedlichen Berechtigungen gebaut hast, sondern weil derselbe Berechtigungssatz pro Zuweisung unterschiedlich gescoped ist.

Least-Privilege-Empfehlungen

Ein paar Dinge, die ich immer prüfe, wenn ich einen Tenant übernehme oder auditiere:

• Global Administrator sollte für niemanden die Alltagsrolle für Intune sein. Nutze stattdessen Intune Administrator (oder eine schmalere Custom Role) und reserviere Global Administrator für echte Notfall-Zugriffsszenarien.
• Überprüfe Rollenzuweisungen regelmässig, genauso wie du veraltete Geräte aufräumst - Leute wechseln Teams oder verlassen die Firma, und ihre alten Rollenzuweisungen werden selten automatisch entzogen.
• Bevorzuge mehrere schmale Scope Tags gegenüber einem breiten. Es ist viel einfacher, Zugriff später zu lockern, als nach einem Vorfall herauszufinden, wer eigentlich worauf Zugriff hatte.
• Nutze Read Only Operator für alle, die nur Einblick brauchen - Führungspersonen, Auditoren oder ein Security-Team, das Compliance überwacht, ohne Richtlinien ändern zu müssen.

Fazit

Intune RBAC besteht eigentlich aus zwei unabhängigen Entscheidungen - welche Berechtigungen (Rolle) und welche Objekte (Scope Tag) - und der grösste Nutzen entsteht, wenn man eine schmale Rolle mit einem schmalen Scope kombiniert, statt aus Bequemlichkeit zu einer breiteren Built-in-Rolle zu greifen. Das von Anfang an sauber aufzusetzen kostet wenig Mehraufwand und erspart dir, zu breite Zugriffsrechte später wieder entwirren zu müssen - meist genau dann, wenn dir die Zeit dafür am wenigsten passt.