Azure Lighthouse-beveiliging en machtigingen: hoe je multi-tenant cloudtoegang veilig beheert

By Mirko Peters · 2026-10-21

Lees hoe de beveiliging van Azure Lighthouse werkt, hoe je least privilege over tenants heen afdwingt, en hoe klanten volledige controle over hun cloud houden.

Automatically translated with AI from the original post. Read the English original

De beveiliging van Azure Lighthouse steunt op least-privilegeprincipes, logische resourceprojecties en strikte grenzen die de klant zelf bepaalt. Zo kunnen managed service providers multi-tenant cloudomgevingen beheren zonder ooit beheerderswachtwoorden in handen te krijgen. Ze gebruiken daarvoor ingebouwde Azure-rollen en permanente audittrails.

Belangrijkste punten

• Klanten behouden volledige zeggenschap over hun Azure-tenants door precieze scopes en ingebouwde rollen te definiëren.
• Registratiedefinities en -toewijzingen vormen een blijvende handdruk die Azure bij elke actie controleert.
• Volledige Owner-rollen en toegang tot het data-plane worden in Azure Lighthouse-delegaties helemaal niet ondersteund.
• Providers werken via logische projecties in hun eigen portal, zonder gebruikerswachtwoorden of referenties te delen.
• Activiteitenlogboeken leggen elke wijziging in de tenant van de klant vast en vormen zo een transparante audittrail.

De beveiligingsarchitectuur van Azure Lighthouse

Het beheren van meerdere cloudomgevingen vroeg vroeger om een eigen beheeraccount in elke afzonderlijke klanttenant. Die aanpak bracht grote beveiligingsrisico's met zich mee: wildgroeiende spreadsheets met tijdelijke wachtwoorden en vergeten referenties die in externe systemen blijven hangen. Azure Lighthouse verandert dit fundamenteel door een veilige, cryptografisch vastgelegde deur te bieden tussen afzonderlijke cloudomgevingen.

In plaats van tenants samen te voegen of referenties te delen, gebruikt Lighthouse een logische projectie. De resources van de klant blijven volledig binnen de eigen cloudomgeving: hun tenant, abonnement en resourcegroepen. De managed service provider bekijkt deze resources via een beveiligde doorgang vanuit de eigen beheertenant. Elke aanvraag van de provider gaat langs de validatielaag van Azure, die voortdurend de autorisatiedocumenten controleert voordat een opdracht wordt uitgevoerd.

De handdruk in twee delen

Beveiliging in Azure Lighthouse berust niet op blind vertrouwen. Ze is verankerd in twee onveranderlijke, op JSON gebaseerde configuratiebestanden die de beheerder op het hoogste niveau van de klant rechtstreeks uitrolt.

Het eerste deel is de registratiedefinitie. Dit document staat in het account van de klant en beschrijft expliciet welke externe organisatie vertrouwd wordt en welke specifieke ingebouwde rollen die organisatie krijgt. Het tweede deel is de registratietoewijzing. Die fungeert als het adres: ze koppelt de definitie aan een specifiek abonnement of een specifieke resourcegroep.

Omdat deze onderdelen in de tenant van de klant staan, heeft de klant de volledige controle. Als een contract eindigt, kan de klant de registratietoewijzing verwijderen. Zo sluit hij de deur direct af, zonder medewerking van de serviceprovider nodig te hebben.

Least privilege afdwingen in multi-tenant omgevingen

Een kernprincipe van moderne cloudbeveiliging is het least-privilegeprincipe: gebruikers en systemen krijgen alleen de minimale machtigingen die nodig zijn om hun taken uit te voeren. Azure Lighthouse maakt het eenvoudig om dit principe af te dwingen door machtigingen te koppelen aan beveiligingsgroepen, service-principals en automatiseringsaccounts in plaats van aan afzonderlijke menselijke gebruikers.

Een managed service provider kan de teamtoegang bijvoorbeeld in verschillende niveaus indelen:

• Supportteam: Krijgt de rol Lezer toegewezen om de status van virtuele machines en diagnostische logboeken te controleren zonder wijzigingen aan te brengen.
• Migratie-engineers: Krijgen de rol Inzender op specifieke resourcegroepen toegewezen om workloads uit te rollen en updates toe te passen.
• Automatiseringsscripts: Krijgen beperkte, aangepaste serviceaccounts toegewezen om nachtelijke back-ups uit te voeren en telemetriegegevens te verzamelen.

Deze gedetailleerde aanpak zorgt ervoor dat menselijke fouten of gecompromitteerde referenties bij de provider niet kunnen uitgroeien tot catastrofale schade in alle beheerde klantomgevingen.

Beperkingen van ingebouwde rollen als beveiligingsvangrails

Om organisaties te beschermen tegen te ruime machtigingen, past Azure Lighthouse strikte vangrails toe op wat wel en niet gedelegeerd kan worden. Vooral de rol Eigenaar op het hoogste niveau wordt binnen een Lighthouse-delegatie helemaal niet ondersteund. Een serviceprovider kan nooit de bevoegdheid krijgen om machtigingen aan anderen toe te kennen of het uiteindelijke eigendom van het abonnement van de klant over te nemen.

Daarnaast kunnen rollen die toegang geven tot dataplanes, zoals het lezen van bestanden in Azure Blob Storage-containers of het bekijken van databaserecords, niet via Lighthouse worden gedelegeerd. Lighthouse beheert de controleplanes van de infrastructuur, zodat beheertoezicht nooit overgaat in een schending van gegevensprivacy.

Auditlogs en naleving bijhouden

Compliance-officers raken er vaak in paniek van als externe leveranciers toegang krijgen tot de kerninfrastructuur van de cloud. Azure Lighthouse neemt die zorg weg door aan de kant van de klant een nauwkeurig, manipulatiebestendig controlespoor bij te houden.

Elke handeling van een providergebruiker, of het nu gaat om het herstarten van een virtuele machine, het wijzigen van een firewallregel of het bijwerken van netwerkinstellingen, wordt rechtstreeks in het Azure-activiteitenlogboek van de klant vastgelegd. Omdat deze logboeken in de tenant van de klant staan, kunnen ze door de externe provider niet worden gewijzigd of verwijderd. IT-beheerders kunnen regelmatig audits uitvoeren om cruciale beveiligingsvragen te beantwoorden: Wie heeft deze resource aangeraakt? Wanneer is die gewijzigd? Welke exacte opdracht is uitgevoerd?

Bovendien kunnen organisaties Azure Lighthouse combineren met Privileged Identity Management (PIM) om just-in-time verhoging van rechten af te dwingen. In plaats van permanente Inzender-rechten aan te houden, kunnen providerengineers alleen toegang aanvragen wanneer zich een incident voordoet. Goedkeuringen worden gelogd en tijdslimieten worden automatisch afgedwongen.

Conclusie

Azure Lighthouse lost de eeuwige spanning op tussen robuuste cloudbeveiliging en efficiënt beheer van meerdere tenants. Door wachtwoorden delen te vervangen door cryptografisch geverifieerd, door de klant gecontroleerd gedelegeerd resourcebeheer, kunnen IT-leiders hun activiteiten opschalen zonder de beveiliging in gevaar te brengen. Wil je de fundamentele concepten achter deze architectuur verkennen? Beluister de volledige aflevering van de M365 FM Podcast voor een uitleg zonder jargon over modern cloudbeheer.

Veelgestelde vragen

Kan een Azure Lighthouse-provider de wachtwoorden van mijn organisatie zien?

Nee. Azure Lighthouse maakt wachtwoorden of gebruikersreferenties nooit zichtbaar, verzendt ze niet en deelt ze niet tussen tenants. Providers authenticeren met hun eigen enterprise-identiteitssystemen terwijl ze via logische projecties op jouw resources werken.

Wat gebeurt er met de Azure Lighthouse-toegang als een provider wordt gehackt?

Omdat de toegang strikt beperkt is tot de specifieke ingebouwde rollen en resources die in de registratietoewijzing zijn gedefinieerd, en de rol Eigenaar is uitgesloten, blijft de impact nauwkeurig beperkt. Bovendien kan de klant de toegang direct intrekken door de registratietoewijzing in het eigen portaal te verwijderen.

Ondersteunt Azure Lighthouse aangepaste RBAC-rollen?

Nee. Azure Lighthouse ondersteunt alleen ingebouwde Azure-rollen die door Microsoft worden aangeboden. Aangepaste rollen die binnen de tenant van de provider of de klant zijn gemaakt, kunnen niet in registratiedefinities worden gebruikt.

Wie heeft de bevoegdheid om Azure Lighthouse in de tenant van een klant in te stellen?

Alleen een gebruiker met bevoegdheden op hoog niveau – concreet een account met machtigingen om rollen toe te wijzen op abonnements- of resourcegroepniveau, zoals User Access Administrator of Owner – kan de registratiesjabloon uitrollen en de verbinding tot stand brengen.