Authentifizierung und Zugriff¶
Das Portal meldet Benutzer mit Microsoft Entra ID an und entscheidet anhand des Catalogs, was sie sehen dürfen: Ein Team sieht die sensiblen Details der workloads, die es besitzt. Diese Seite beschreibt das Referenzdesign. Dein Deployment kann abweichen.
Anmeldung¶
Jede Umgebung hat ihre eigene Entra-App-Registrierung. Benutzer werden zu Entra ID weitergeleitet, und das Portal ordnet das angemeldete Konto einer User-Entity im Catalog zu.
| Element | Detail |
|---|---|
| Provider | Microsoft (Entra ID), eine App-Registrierung pro Umgebung |
| Delegierte Berechtigungen | email, offline_access, openid, profile, User.Read, mit Admin Consent |
| Redirect-URI | https://<portal-domain>/api/auth/microsoft/handler/frame |
| Benutzer und Gruppen | Vom Catalog aus Entra ID gelesen (Catalog und Entity-Modell) |
| Standard-Resolver | emailMatchingUserEntityAnnotation: Die Anmelde-E-Mail muss zur E-Mail-Annotation einer User-Entity passen |
Passt keine User-Entity, schlägt die Anmeldung fehl. Ein neuer Mitarbeiter kann sich daher erst anmelden, wenn der nächste Benutzer-Sync gelaufen ist.
Umgebung des Anbieters
In der eigenen Umgebung des Anbieters verwendet das Portal einen eigenen Anmelde-Resolver. Er sucht den Benutzer per E-Mail und erlaubt die Anmeldung dann nur für Mitglieder einer konfigurierten Menge von Entra-Gruppen. Das ist Teil des internen Tooling des Anbieters und gilt nicht für eine Standardumgebung. Siehe Konfiguration.
Für die lokale Entwicklung unterstützt das Portal eine Gast-Anmeldung. In der Produktionskonfiguration ist sie deaktiviert.
Service-to-Service-Zugriff¶
Externe Aufrufer, etwa MCP-Clients, können ein für die Umgebung konfiguriertes statisches Token oder OAuth nutzen. Siehe MCP-Server.
Zugriff auf sensible Details¶
Der Zugriff folgt dem Eigentum. Die workload-Entity hat einen Owner (eine Team-Gruppe). Ein Benutzer besitzt die Entities, die seine Gruppen besitzen. Das Portal fragt das Backstage-Permission-Framework, bevor es sensible Details zurückgibt, und eine Policy antwortet mit einer Bedingung: Der Benutzer muss Owner der Entity sein.
| Frage | Antwort |
|---|---|
| Wer sieht die Übersichtsseiten (workloads, Domänen, Secure Score, Compliance Score, Kosten)? | Jeder angemeldete Benutzer |
| Wer sieht das Detail eines workloads (Firewall-Logzeilen, blockierte Gateway-Anfragen, Security-Empfehlungen, Compliance pro Policy)? | Owner dieses workloads |
| Enthalten Ownership-Claims die Gruppenmitgliedschaft? | Ja: Die Claims stammen aus der Anmeldeidentität des Benutzers, die die Gruppen enthält, in denen er Mitglied ist |
| Was, wenn die Prüfung gegen eine Entity nicht ausgewertet werden kann? | Die Anfrage wird abgelehnt |
Was geschützt ist¶
Die Standard-Policy schützt genau vier Berechtigungen. Alles andere ist erlaubt.
| Berechtigung | Schützt |
|---|---|
networking.firewall.logs.read |
Azure-Firewall-Logzeilen eines workloads |
azure-network.application-gateway.blocked-requests.read |
Blockierte Application-Gateway-Anfragen eines workloads |
security-insights.detail.read |
Security-Details pro Empfehlung eines workloads |
compliance-insights.detail.read |
Compliance-Details pro Policy eines workloads |
Kosten sind nicht geschützt
Kostendaten sind für alle angemeldeten Benutzer sichtbar. Die Policy schützt Kosten nicht. Entscheide also, ob das akzeptabel ist, bevor du Cost Insights aktivierst.
Dieselben Berechtigungen gelten, wenn die Daten über den MCP-Server oder durch einen Agenten angefragt werden, weil diese Aufrufe mit der Identität des Benutzers laufen.
Status des Designs
Der Entscheidungsdatensatz für dieses Modell ist noch als vorgeschlagen markiert, obwohl die Policy im Code implementiert ist (Entscheidungen). Die breiteren Security- und Compliance-Ansichten werden in der Quelle als in Arbeit beschrieben. Lies die Tabelle oben als Verhalten des aktuellen Codes, nicht als Zusage.
Audit-Ereignisse¶
Der Service, der den Entity-Zugriff prüft, erzeugt für jede Prüfung ein Audit-Ereignis über den Backstage-Auditor. Das Ereignis hält fest, ob der Zugriff erfolgreich war oder fehlgeschlagen ist. Wo diese Ereignisse landen (Log-Stream, Application Insights), hängt von der Logger-Konfiguration der Umgebung ab. Siehe Betrieb.