Identiteit: Entra ID, groepen en service principals

Elk recht begint met een naam

Een privilege is een zin: deze principal mag dit doen met dat object. Is de principal een losse lijst individuele gebruikers, dan veroudert de zin de dag dat iemand van team wisselt. Governance op schaal vraagt identiteiten die uit één bron komen, meeveranderen met die bron en per rol gegroepeerd zijn.

In deze les richten we identiteit in zoals wij dat op Azure Databricks doen: Microsoft Entra ID als bron, groepen als eenheid van toegang, service principals voor automatisering en geprivilegieerde rollen die alleen op aanvraag bestaan. Netwerktoegang en voorwaardelijke toegang in Entra ID zelf behandelen we niet.

Drie soorten identiteit

De Azure Databricks-documentatie noemt drie identiteitstypen.

Identiteiten worden op accountniveau beheerd en daarna aan workspaces toegewezen. De documentatie zegt dat alle nieuwe workspaces standaard zijn ingeschakeld voor identity federation en dat dit niet uit te zetten is. Je beheert identiteiten dus één keer op het account en wijst ze toe aan zoveel workspaces als nodig. Oudere workspaces zonder federation gebruiken workspace-lokale groepen, die geen accountgroepen zijn en niet werken voor Unity Catalog-rechten. Die migreren is de eerste governancetaak in een ouder landschap.

Een account heeft limieten voor identiteiten en groepen. De documentatie noemt standaardlimieten van 10.000 gebruikers en service principals samen en 5.000 groepen, met hogere limieten voor nieuwere accounts en op aanvraag. Ontwerp groepen voor rollen, niet voor individuen, dan kom je er niet bij.

Entra ID als bron van waarheid

De documentatie raadt aan identiteiten uit Microsoft Entra ID te synchroniseren met automatic identity management, standaard ingeschakeld voor accounts die na 1 augustus 2025 zijn gemaakt. Daarmee zoek je Entra ID-gebruikers, service principals en groepen rechtstreeks in de workspace-instellingen en voeg je ze toe aan de workspace en het account. Entra ID is de bron van waarheid, dus een wijziging in groepslidmaatschap daar wordt in Azure Databricks overgenomen.

Dat is het model dat wij gebruiken: geen handmatig gebruikersbeheer in Databricks.

• Maak de groepen in Entra ID, met een eigenaar en een naamconventie.
• Laat automatic identity management ze binnenhalen. Waar een oudere inrichting SCIM-provisioning gebruikt, is het principe gelijk: de identiteitsprovider is de bron en Databricks de afnemer.
• Voeg geen gebruikers rechtstreeks toe aan workspaces, catalogs of schema's. Een gebruiker krijgt toegang door lid te zijn van een groep.
• Verwijder mensen in Entra ID. Offboarding gebeurt dan op één plek en het effect bereikt Databricks zonder tweede stap.

Single sign-on met Entra ID is standaard beschikbaar voor zowel de accountconsole als workspaces en just-in-time-provisioning kan bij de eerste login een gebruiker aanmaken. JIT is handig voor gebruikers, maar toegang komt nog steeds uit groepen, dus een nieuwe gebruiker ziet niets totdat een groep het toekent.

Groepsnamen en structuur

Een conventie maakt rechten leesbaar en controleerbaar. De onze:

Rollen zijn reader, contributor en owner. We gebruiken ze in les 3. Eén groep per toegangsniveau per scope houdt het model klein: je leest een groepsnaam en weet wat hij toekent.

Geneste groepen zijn een valkuil als ze zonder kaart groeien. Geef de voorkeur aan een vlakke structuur van rolgroepen en zet mensen in de groepen die ze nodig hebben. Heb je een groep "finance-analisten" nodig, maak die dan lid van de readergroepen die ze nodig heeft en documenteer waarom.

Service principals voor alles wat zelfstandig draait

Jobs, pipelines, CI/CD en apps draaien als service principal. De documentatie beschrijft service principals als identiteiten voor jobs, geautomatiseerde tools en systemen zoals scripts, apps en CI/CD-platforms. Regels die wij toepassen:

• Eén service principal per omgeving en doel. Bijvoorbeeld een uitrolprincipal per omgeving en een runtimeprincipal per domein.
• Least privilege. De pipelineprincipal voor silver heeft contributor op silver en reader op bronze, en niets anders.
• Geen geheimen waar federation werkt. Gebruik workload identity federation voor CI/CD en waar mogelijk managed identities, in plaats van langlevende client secrets.
• Benoem een eigenaar. De documentatie beschrijft service principal managers die rollen op een service principal kunnen toevoegen, wijzigen en verwijderen. Maak de manager een groep.

Handelt een agent of app namens een persoon, dan hoort hij met de rechten van die persoon te handelen, zodat hij niet kan lezen wat de persoon niet mag lezen. Ons artikel over on-behalf-of-toegang in Databricks Apps behandelt het patroon.

Beheerrollen en PIM

De documentatie noemt rollen die identiteiten mogen beheren: accountbeheerders, workspacebeheerders, groepsmanagers en service principal managers. Accountbeheerders kunnen elke gebruiker, service principal en groep beheren en workspacebeheerders hebben beperktere rechten binnen hun workspaces.

Beheerrollen zijn de identiteiten met het hoogste risico in het platform, dus onze standaarden voegen één regel toe: geprivilegieerde toegang is eligible en niet permanent. In Entra ID Privileged Identity Management (PIM) is een persoon eligible voor een beheerrol en activeert die voor beperkte tijd, met een reden en meerfactorauthenticatie. Activaties in acceptatie en productie vragen goedkeuring. Alleen break-glass-accounts hebben permanente toegang en zij hebben alerts.

Combineer dat met de Databricks-kant: houd het aantal accountbeheerders klein en geef workspacebeheer aan een groep die de rol via PIM krijgt, niet aan personen met naam.

Identiteitsattributen

De documentatie noemt dat Azure Databricks identiteitsattributen, zoals functie, afdeling en kostenplaats, uit je identiteitsprovider op accountgebruikers kan opslaan voor gebruik in toegangsbeleid. Het label bij deze functie is Beta. Wij behandelen Beta-functies als pilots: nuttig voor planning, maar niet de basis van een productietoegangsmodel zolang de status niet verandert.

Een snelle audit

Controleer deze vijf dingen in elk landschap dat je erft:

1. Zijn er workspace-lokale groepen met rechten?
2. Hebben individuele gebruikers rechtstreeks privileges?
3. Draaien productiejobs als een persoon?
4. Wie heeft accountbeheer en workspacebeheer, en is dat permanent of eligible?
5. Wanneer is het groepslidmaatschap voor het laatst gereviewd?

De antwoorden laten meestal binnen een uur zien waar het risico zit.

Samenvatting

Gebruik Entra ID als bron, groepen als eenheid van toegang, service principals voor automatisering en PIM voor geprivilegieerde rollen. Beheer identiteiten op accountniveau, geef nooit rechten aan individuen en benoem een eigenaar voor elke groep en service principal.

Volgende les: privileges en het reader- en contributorpatroon.