Architekturschulden erkennen und reduzieren

Architekturschulden erkennen und reduzieren

Microsoft 365 ist in vielen Unternehmen längst produktiv im Einsatz. Exchange Online, Teams, SharePoint, OneDrive, Entra ID, Intune und Sicherheitsfunktionen sind eingerichtet und werden täglich genutzt.

Das bedeutet aber nicht automatisch, dass der Microsoft 365 Tenant sauber strukturiert ist.

Viele Tenants wachsen über Jahre. Neue Benutzer werden angelegt, Berechtigungen werden erweitert, Ausnahmen werden erlaubt, Teams entstehen, SharePoint-Sites werden erstellt, Lizenzen werden angepasst und einzelne Konfigurationen werden für konkrete Fälle verändert. Jede Entscheidung kann für sich genommen sinnvoll gewesen sein. In Summe entstehen daraus aber oft Architekturschulden.

Diese Architekturschulden fallen selten sofort auf. Sie werden sichtbar, wenn Berechtigungen nicht mehr nachvollziehbar sind, Lizenzkosten steigen, Sicherheitsstandards uneinheitlich greifen oder Änderungen im Tenant unerwartete Nebenwirkungen haben.

Was sind Architekturschulden in Microsoft 365?

Architekturschulden in Microsoft 365 entstehen, wenn kurzfristige Entscheidungen dauerhaft in der Umgebung bleiben, ohne später wieder geprüft zu werden.

Typische Beispiele sind:

• zu viele globale Administratoren

• historisch gewachsene Gruppenstrukturen

• direkte Berechtigungen statt gruppenbasierter Zuweisungen

• alte Gäste und externe Benutzer

• unklare Besitzer von Teams und SharePoint-Sites

• nicht mehr benötigte Lizenzen

• uneinheitliche Sicherheitsrichtlinien

• Ausnahmen in Conditional Access

• unklare Namenskonventionen

• fehlende Standards für neue Benutzer, Gruppen und Teams

Diese Punkte verhindern den Betrieb nicht sofort. Genau deshalb bleiben sie oft lange bestehen. Sie erhöhen aber den Aufwand für jede spätere Änderung.

Warum ein eingerichteter Tenant nicht automatisch durchdacht ist

Ein Microsoft 365 Tenant ist nicht nur eine technische Plattform. Er ist die zentrale Struktur für Identität, Zusammenarbeit, Kommunikation, Zugriff, Datenhaltung und Sicherheit.

^{Bildquelle: Microsoft Learn, Step 3. Identity for your Microsoft 365 for enterprise tenants. Die Dokumentation zeigt das Zusammenspiel des Tenants mit Microsoft-365-Diensten, Benutzerkonten und Conditional Access}

Microsoft beschreibt Tenant Management für Microsoft 365 als Planung, Bereitstellung und laufenden Betrieb von Microsoft-365-Tenants. Genau dieser Punkt ist entscheidend: Ein Tenant muss nicht nur eingerichtet, sondern dauerhaft gesteuert werden.

In der Praxis liegt der Fokus häufig auf der Einführung. Benutzer sollen arbeiten können. E-Mails müssen funktionieren. Teams wird ausgerollt. Dateien werden migriert. Geräte werden angebunden.

Die strukturellen Fragen kommen oft später:

• Welche Standards gelten für neue Benutzer?

• Wer darf Teams erstellen?

• Wie werden externe Benutzer geprüft?

• Welche Admin-Rollen sind wirklich notwendig?

• Welche Gruppen steuern welche Berechtigungen?

• Welche Lizenzen werden über Gruppen vergeben?

• Welche Sicherheitsrichtlinien gelten für alle?

• Welche Ausnahmen sind dokumentiert?

• Welche Daten dürfen extern geteilt werden?

Wenn diese Fragen nicht geklärt sind, entsteht kein geordneter Tenant, sondern eine gewachsene Betriebsumgebung.

Wo Architekturschulden besonders häufig entstehen

1. Tenant Standards

Fehlende Standards sind eine der häufigsten Ursachen für spätere Unübersichtlichkeit. Dazu gehören Namenskonventionen, Gruppenmodelle, Rollenmodelle, Lizenzgruppen, Sicherheitsrichtlinien, Freigaberegeln, Teams- und SharePoint-Strukturen sowie Prozesse für neue Benutzer und austretende Mitarbeiter. Ohne Standards entscheidet jedes Team, jede Abteilung oder jeder Administrator anders. Das wirkt am Anfang flexibel. Später wird es schwer, die Umgebung zu erklären. Ein sinnvoller Standard legt nicht jede Ausnahme still. Er definiert aber, was der Normalfall ist und welche Abweichungen bewusst genehmigt werden müssen.

2. Berechtigungen und Admin-Rollen

Berechtigungen sind einer der kritischsten Bereiche in Microsoft 365. Microsoft empfiehlt bei Administratorrollen das Least-Privilege-Prinzip. Administratoren sollen nur die Rechte erhalten, die sie für ihre Aufgabe wirklich benötigen. Microsoft beschreibt dies in der Dokumentation zu Microsoft 365 Admin-Rollen und in den Least-Privilege-Rollen für Microsoft Entra ID. In gewachsenen Tenants sieht die Realität oft anders aus. Benutzer behalten alte Rollen, Dienstleister haben noch Zugriff, globale Administratoren wurden aus Bequemlichkeit vergeben oder Gruppenmitgliedschaften wurden nie vollständig überprüft. Das Problem ist nicht nur Sicherheit. Es ist auch Nachvollziehbarkeit. Wenn nicht klar ist, wer worauf Zugriff hat, werden Audits, Sicherheitsprüfungen und Änderungen unnötig aufwendig.

Eine Aufräumphase sollte deshalb mindestens prüfen:

• globale Administratoren

• privilegierte Rollen

• SharePoint- und Teams-Besitzer

• externe Benutzer

• Gastzugriffe

• Gruppenmitgliedschaften

• App-Berechtigungen

• Rollen von Dienstleistern

• alte Benutzerkonten

• Ausnahmen in Sicherheitsrichtlinien

Für wiederkehrende Prüfungen sind Microsoft Entra Access Reviews relevant. Damit lassen sich Zugriffe auf Gruppen und Anwendungen regelmäßig überprüfen.

3. Lizenzlogik

Lizenzmanagement wird oft operativ behandelt: Ein Benutzer braucht eine Lizenz, also bekommt er eine. Das funktioniert kurzfristig. Langfristig entstehen dadurch aber häufig unnötige Kosten und unklare Zuordnungen. Besonders problematisch wird es, wenn direkte Lizenzzuweisung und gruppenbasierte Lizenzierung gleichzeitig verwendet werden, ohne klares Modell. Microsoft beschreibt in der Dokumentation zur Lizenzzuweisung im Microsoft 365 Admin Center, dass Lizenzen einzelnen Benutzern oder über Produktseiten zugewiesen und entfernt werden können. Zusätzlich gibt es gruppenbasierte Lizenzierung. Microsoft dokumentiert auch typische Probleme bei gruppenbasierter Lizenzzuweisung, etwa fehlende Lizenzkontingente oder Konflikte zwischen Lizenzplänen.

Eine saubere Lizenzlogik beantwortet konkrete Fragen:

• Welche Lizenzpakete gibt es im Unternehmen?

• Welche Rollen oder Benutzergruppen erhalten welche Lizenz?

• Werden Lizenzen direkt oder über Gruppen vergeben?

• Wer entscheidet über Premium-Lizenzen?

• Welche Benutzer haben ungenutzte oder zu große Lizenzpakete?

• Welche Lizenzen werden bei Austritt automatisch entfernt?

• Welche Lizenzkosten lassen sich Abteilungen oder Bereichen zuordnen?

Lizenzlogik ist damit nicht nur Kostenkontrolle. Sie ist Teil der Tenant-Architektur.

Warum das eine Architekturfrage ist

Viele Probleme in Microsoft 365 wirken wie Betriebsaufgaben. Ein Benutzer hat zu viele Rechte. Eine Gruppe ist unklar. Eine Lizenz ist falsch vergeben. Ein externer Benutzer ist noch aktiv.

Einzeln betrachtet sind das operative Aufgaben. In Summe zeigen sie aber ein Architekturproblem.

Wenn diese Themen nur im Tagesgeschäft korrigiert werden, bleibt die Grundstruktur unverändert. Dann wird ein einzelnes Problem gelöst, aber das Muster bleibt bestehen.

Eine Architekturbetrachtung fragt anders:

• Welches Zielbild soll der Tenant haben?

• Welche Standards gelten künftig?

• Welche Rollenmodelle sind erlaubt?

• Welche Ausnahmen sind zulässig?

• Wie werden Berechtigungen regelmäßig geprüft?

• Wie werden Lizenzen strukturiert vergeben?

• Welche Konfigurationen müssen dokumentiert werden?

• Welche Altlasten werden bereinigt?

• Welche Aufgaben gehören in den laufenden Betrieb?

Erst durch diese Fragen wird aus Einzelkorrektur eine geordnete Tenant-Struktur.

Was eine Bestandsaufnahme leisten sollte

Eine sinnvolle Bestandsaufnahme eines Microsoft 365 Tenants sollte nicht nur technische Daten sammeln. Sie sollte bewerten, ob die vorhandene Struktur noch zum Unternehmen passt.

Wichtige Prüfbereiche sind:

Identität und Benutzer

Hier geht es um Benutzerkonten, Gäste, externe Benutzer, Gruppen, Rollen, Anmelderisiken und den Umgang mit Eintritten, Wechseln und Austritten. Zu prüfen ist insbesondere, ob alte Konten deaktiviert oder entfernt wurden, ob Gäste noch benötigt werden und ob Benutzergruppen eindeutig benannt und verantwortlich zugeordnet sind.

Administratorrollen

Admin-Rollen sollten vollständig ausgewertet werden. Besonders globale Administratoren, privilegierte Rollen und dauerhafte Rollenvergaben sollten kritisch geprüft werden. Die zentrale Frage lautet: Welche Person braucht welche Rolle, für welchen Zweck und für welchen Zeitraum?

Teams, SharePoint und Freigaben

In vielen Tenants entstehen über Jahre zahlreiche Teams, Gruppen und SharePointSites. Ohne Governance ist später oft unklar, welche Inhalte aktiv genutzt werden, wer Besitzer ist und welche externen Freigaben bestehen. Eine Bestandsaufnahme sollte deshalb Teams, Gruppen, Sites, Besitzer, externe Freigaben und inaktive Bereiche betrachten.

Lizenzierung

Lizenzen sollten nicht nur gezählt, sondern logisch bewertet werden. Relevant ist, ob Lizenzpakete zu Rollen passen, ob direkte Zuweisungen reduziert werden können, ob inaktive Benutzer noch Lizenzen besitzen und ob gruppenbasierte Lizenzierung sauber umgesetzt ist.

Sicherheit und Konfiguration

Microsoft stellt mit Microsoft Secure Score eine Möglichkeit bereit, die Sicherheitsposition einer Organisation zu bewerten und empfohlene Maßnahmen sichtbar zu machen. Secure Score ersetzt keine Architekturprüfung. Er ist aber ein sinnvoller Einstieg, um Sicherheitskonfigurationen strukturiert zu betrachten und Verbesserungen zu priorisieren.

^{Bildquelle: Microsoft Learn, Microsoft Secure Score – Microsoft Defender XDR.}

Was eine Aufräumphase bringt

Eine Aufräumphase ist kein Selbstzweck. Sie soll den Microsoft 365 Tenant wieder erklärbar machen.

Das Ergebnis sollte nicht nur eine Liste behobener Einzelprobleme sein, sondern ein klares Zielbild für den weiteren Betrieb.

Eine gute Aufräumphase bringt:

• weniger unnötige Berechtigungen

• klarere Admin-Rollen

• nachvollziehbare Gruppenstrukturen

• bessere Kontrolle über externe Zugriffe

• transparentere Lizenzkosten

• weniger Ausnahmen

• dokumentierte Standards

• einfachere Audits

• geringeren Aufwand bei zukünftigen Änderungen

• bessere Grundlage für den laufenden Betrieb

Der wichtigste Effekt ist Nachvollziehbarkeit. Wenn ein Tenant erklärbar ist, lassen sich Risiken, Kosten und Änderungen deutlich besser steuern.

Wann ein Tenant neu geordnet werden sollte

Ein Microsoft 365 Tenant sollte spätestens dann strukturiert geprüft werden, wenn mehrere der folgenden Punkte zutreffen:

• Niemand kann sicher sagen, wie viele globale Administratoren es gibt.

• Externe Benutzer wurden lange nicht überprüft.

• Teams und SharePoint-Sites haben keine klaren Besitzer.

• Lizenzen werden direkt und uneinheitlich vergeben.

• Sicherheitsrichtlinien enthalten viele nicht dokumentierte Ausnahmen.

• Neue Benutzer werden manuell und unterschiedlich eingerichtet.

• Gruppenstrukturen sind historisch gewachsen.

• Berechtigungen werden nur bei konkreten Problemen geprüft.

• Kosten lassen sich nicht sauber erklären.

• Änderungen im Tenant erzeugen unerwartete Nebenwirkungen.

Ein gewachsener Tenant ist kein Zeichen von Versäumnis. Er ist ein Zeichen dafür, dass Microsoft 365 aktiv genutzt wird. Die Frage ist nur, ob die gewachsene Struktur noch zu den heutigen Anforderungen passt.

Vorgehensweise für eine Microsoft 365 Tenant Aufräumphase

Eine pragmatische Aufräumphase kann in fünf Schritten erfolgen.

1. Bestand erfassen

Zuerst werden Benutzer, Gruppen, Rollen, Lizenzen, Teams, SharePoint-Sites, Gäste, Freigaben und Sicherheitskonfigurationen aufgenommen. Ziel ist Transparenz, nicht sofortige Korrektur.

2. Risiken bewerten

Danach wird bewertet, welche Punkte sicherheitskritisch, kostenrelevant oder betrieblich problematisch sind. Nicht jede Abweichung ist sofort kritisch. Entscheidend ist Priorisierung.

3. Zielbild definieren

Anschließend wird festgelegt, welche Standards künftig gelten sollen. Dazu gehören Rollenmodell, Lizenzmodell, Gruppenmodell, Freigaberegeln, Sicherheitsstandards und Prozesse für Benutzerlebenszyklen.

4. Altlasten bereinigen

Erst danach beginnt die eigentliche Bereinigung: unnötige Rollen entfernen, alte Gäste prüfen, Lizenzzuweisungen konsolidieren, Gruppen bereinigen und Ausnahmen dokumentieren oder entfernen.

5. Betrieb übergeben

Nach der Aufräumphase muss klar sein, wie der Tenant dauerhaft betrieben wird. Sonst entstehen dieselben Muster erneut. Dazu gehören regelmäßige Reviews, klare Verantwortlichkeiten, Dokumentation, Monitoring und ein definierter Prozess für Änderungen. Der geordnete Betrieb kann anschließend durch das Schwesterunternehmen basecloud übernommen werden.

Prüffragen für den eigenen Microsoft 365 Tenant

Diese Fragen helfen bei einer ersten Einschätzung:

• Wann wurden Microsoft 365 Berechtigungen zuletzt vollständig überprüft?

• Wie viele globale Administratoren gibt es?

• Sind alle Admin-Rollen fachlich begründet?

• Gibt es regelmäßige Access Reviews?

• Sind externe Benutzer und Gäste noch notwendig?

• Gibt es klare Standards für Teams und SharePoint?

• Werden Lizenzen über Gruppen oder direkt vergeben?

• Sind Lizenzkosten nachvollziehbar?

• Gibt es dokumentierte Ausnahmen in Sicherheitsrichtlinien?

• Ist der Tenant für Dritte erklärbar?

Wenn diese Fragen nicht eindeutig beantwortet werden können, ist eine strukturierte Bestandsaufnahme sinnvoll.

Fazit

Microsoft 365 ist schnell eingeführt, aber nicht automatisch sauber strukturiert. Über Jahre entstehen Berechtigungen, Ausnahmen, Gruppen, Freigaben und Lizenzmuster, die im Alltag funktionieren, aber langfristig zu Architekturschulden werden. Diese Schulden zeigen sich nicht immer sofort. Sie werden sichtbar, wenn Sicherheit, Kosten, Audits oder Änderungen schwieriger werden.

Ein gewachsener Microsoft 365 Tenant ist kein Problem an sich. Problematisch wird er erst, wenn niemand mehr erklären kann, warum die Struktur so ist, wie sie ist.

Eine Aufräumphase schafft Klarheit. Sie reduziert Risiken, macht Kosten transparenter und legt die Grundlage für einen geordneten Betrieb.