02Interne Anwendung · System Engineering

Mandantenübergreifende Microsoft-365-Verwaltung

Eine zentrale, rollenbasierte Verwaltungsoberfläche bündelt wiederkehrende Aufgaben für Benutzer, Gruppen, Lizenzen, Sicherheitsinformationen und Onboarding über mehrere Microsoft-365-Mandanten.

Zeitraum
2025–2026
Status
Anonymisierte Fallstudie
Meine Rolle
End-to-End-Entwicklung und Cloud-Architektur

01 — Ausgangslage

Problem & Kontext

Wiederkehrende administrative Aufgaben waren auf mehrere Microsoft-Portale und getrennte Mandanten verteilt. Das erschwerte standardisierte Abläufe und machte es aufwendig, Berechtigungen sowie den Zugriff auf einzelne Funktionen und Zielmandanten konsistent nachzuvollziehen.

Die interne Anwendung führt ausgewählte Verwaltungs- und Informationsflüsse in einer Oberfläche zusammen. Sie ersetzt nicht die Microsoft-Portale, sondern schafft für klar abgegrenzte Aufgaben einen kontrollierten, wiederholbaren Arbeitsweg.

Professionelle Rahmenbedingungen

  • Zielmandant, fachliche Funktion und interne Benutzerberechtigung müssen bei jeder Operation gemeinsam geprüft werden.
  • Zugriffe auf Microsoft Graph und Exchange benötigen privilegierte Identitäten, ohne dauerhafte Geheimnisse in Anwendung oder Pipeline abzulegen.
  • Operative Daten und verdichtete Reporting-Daten haben unterschiedliche Zugriffs- und Aktualisierungsanforderungen.
  • Länger laufende oder verteilte Vorgänge müssen wiederaufnehmbar, beobachtbar und eindeutig einem Auftrag zuordenbar sein.

02 — Verantwortung

Meine Rolle

Ich habe die Anwendung end-to-end konzipiert und umgesetzt: Architektur, Benutzeroberfläche, Azure Functions, Datenmodell, Identität und Graph-Integration sowie Infrastruktur, Tests und Delivery.

  1. 01Architektur von Identität, Microsoft-Graph-Zugriff und Zielmandantenauswahl
  2. 02Entwicklung von Benutzeroberfläche, Azure Functions und Datenzugriff
  3. 03Entwurf von RBAC, Scope-Prüfungen und sicherem Mandanten-Onboarding
  4. 04Bicep-Infrastruktur, private Netzwerktopologie und Observability
  5. 05CI/CD mit föderierten Workload-Identitäten und reproduzierbaren Umgebungen

03 — Umsetzung

Ansatz & Entscheidungen

Die Architektur behandelt Mandantenauswahl und Berechtigung als serverseitige Sicherheitsgrenze. Eine erfolgreiche Anmeldung allein reicht nicht aus: API-Scope, interne Rolle, Funktionsfreigabe und Zuordnung zum angefragten Zielmandanten werden gemeinsam ausgewertet.

D01

Mehrschichtige Autorisierung

Scopes schützen die API-Grenze, während interne Rollen und Mandantenzuordnungen den fachlichen Zugriff begrenzen. Dadurch kann eine gültige Identität nicht automatisch auf jede Funktion oder jeden Mandanten zugreifen.

D02

Passwortlose Dienstzugriffe

Managed Identity, Entra-Tokens und Key Vault reduzieren dauerhaft hinterlegte Zugangsdaten. Auch Datenbank- und Deployment-Zugriffe folgen nach Möglichkeit diesem Modell.

D03

Private Azure-Topologie

Anwendung, Functions, PostgreSQL, Storage und Konfiguration werden über kontrollierte Netzpfade verbunden. Die Topologie begrenzt öffentliche Angriffsflächen und macht erlaubte Kommunikationswege explizit.

D04

Getrennte Reporting-Sicht

Operative Graph-Abfragen und tägliche Berichtssnapshots werden getrennt behandelt. So lassen sich konsistente Auswertungen bereitstellen, ohne jede Analyse direkt gegen veränderliche operative Daten auszuführen.

04 — Technologie

Technischer Rahmen

  • C#
  • .NET
  • Azure Functions
  • Durable Functions
  • Microsoft Entra ID
  • Microsoft Graph
  • PostgreSQL
  • Bicep
  • Azure DevOps
  • Managed Identity

05 — Rückblick

Ergebnis & Erkenntnisse

Wiederkehrende mandantenübergreifende Aufgaben wurden in einer kontrollierten Oberfläche mit serverseitiger Autorisierung, zentraler Auditierbarkeit und reproduzierbarem Azure-Deployment gebündelt.

Wiederverwendbare Integrations- und Berechtigungsmuster schaffen eine Grundlage für weitere Verwaltungsabläufe, ohne Mandanten- oder Funktionsgrenzen aufzuweichen.

  • L01Multi-Tenant-Zugriff benötigt neben der Cloud-Identität immer eine explizite fachliche Zielmandanten-Autorisierung.
  • L02Least Privilege entsteht durch das Zusammenspiel von Identitäten, Scopes, Rollen, Netzgrenzen und Betriebsprozessen.
  • L03Reporting und operative Verwaltung profitieren von getrennten Datenwegen und Berechtigungsmodellen.
  • L04End-to-End-Sicherheit muss Anwendung, Infrastruktur und Pipeline gemeinsam betrachten.