Authenticatie en toegang¶
Het portaal meldt gebruikers aan met Microsoft Entra ID en bepaalt op basis van de catalog wat ze mogen zien: een team ziet het gevoelige detail van de workloads die het beheert. Deze pagina beschrijft het referentieontwerp. Jouw uitrol kan afwijken.
Aanmelden¶
Elke omgeving heeft een eigen Entra app registration. Gebruikers worden doorgestuurd naar Entra ID en het portaal koppelt het aangemelde account aan een User-entiteit in de catalog.
| Onderdeel | Detail |
|---|---|
| Provider | Microsoft (Entra ID), één app registration per omgeving |
| Delegated permissions | email, offline_access, openid, profile, User.Read, met admin consent |
| Redirect URI | https://<portal-domain>/api/auth/microsoft/handler/frame |
| Gebruikers en groepen | Door de catalog uit Entra ID gelezen (Catalog en entiteitenmodel) |
| Standaard resolver | emailMatchingUserEntityAnnotation: het e-mailadres van de aanmelding moet overeenkomen met de e-mailannotatie van een User-entiteit |
Als geen enkele User-entiteit overeenkomt, mislukt de aanmelding. Een nieuwe medewerker kan dus pas aanmelden nadat de volgende gebruikerssync heeft gedraaid.
Omgeving van de leverancier
In de eigen omgeving van de leverancier gebruikt het portaal een aangepaste sign-in resolver. Die zoekt de gebruiker op via e-mailadres en staat de aanmelding daarna alleen toe voor leden van een geconfigureerde set Entra-groepen. Dit is onderdeel van de interne tooling van de leverancier en geldt niet voor een standaardomgeving. Zie Configuratie.
Voor lokale ontwikkeling ondersteunt het portaal een gastaanmelding. Die is uitgeschakeld in de productieconfiguratie.
Service-to-service-toegang¶
Externe aanroepers, zoals MCP-clients, kunnen een statisch token gebruiken dat voor de omgeving is geconfigureerd, of OAuth. Zie MCP-server.
Toegang tot gevoelig detail¶
Toegang volgt eigenaarschap. De workloadentiteit heeft een eigenaar (een teamgroep). Een gebruiker beheert de entiteiten die zijn groepen beheren. Het portaal raadpleegt het Backstage permission framework voordat het gevoelig detail teruggeeft, en een policy antwoordt met een voorwaarde: de gebruiker moet eigenaar van de entiteit zijn.
| Vraag | Antwoord |
|---|---|
| Wie kan de overzichtspagina's zien (workloads, domeinen, secure score, compliancescore, kosten)? | Elke aangemelde gebruiker |
| Wie kan het detail van één workload zien (firewalllogregels, geblokkeerde verzoeken van de gateway, securityaanbevelingen, compliance per policy)? | Eigenaren van die workload |
| Bevatten eigenaarschapsclaims ook groepslidmaatschap? | Ja: de claims komen uit de aanmeldidentiteit van de gebruiker, en die bevat de groepen waarvan de gebruiker lid is |
| Wat als de controle niet tegen een entiteit kan worden geëvalueerd? | Het verzoek wordt geweigerd |
Wat is afgeschermd¶
De standaardpolicy schermt precies vier permissions af. Al het andere is toegestaan.
| Permission | Beschermt |
|---|---|
networking.firewall.logs.read |
Azure Firewall-logregels van een workload |
azure-network.application-gateway.blocked-requests.read |
Geblokkeerde verzoeken van Application Gateway voor een workload |
security-insights.detail.read |
Securitydetail per aanbeveling van een workload |
compliance-insights.detail.read |
Compliancedetail per policy van een workload |
Kosten zijn niet afgeschermd
Kostendata is zichtbaar voor alle aangemelde gebruikers. De policy schermt kosten niet af, dus bepaal of dat acceptabel is voordat je cost insights inschakelt.
Dezelfde permissions gelden wanneer de data wordt opgevraagd via de MCP-server of door een agent, omdat die aanroepen met de identity van de gebruiker draaien.
Status van het ontwerp
Het besluitdocument voor dit model staat nog als voorgesteld gemarkeerd, hoewel de policy in de code is geïmplementeerd (Beslissingen). De bredere security- en complianceweergaven worden in de bron als in uitvoering beschreven. Zie de bovenstaande tabel als het gedrag van de huidige code, niet als een toezegging.
Auditevents¶
De service die entiteitstoegang controleert, stuurt voor elke controle een auditevent uit via de Backstage auditor. Het event legt vast of de toegang is geslaagd of mislukt. Waar deze events terechtkomen (logstream, Application Insights) hangt af van de loggerconfiguratie van de omgeving. Zie Beheer.