Stel dat jouw leverancier elke dag automatisch software uitrolt naar jouw Azure-omgeving. Ergens in dat proces moet een systeem bewijzen dat het toegang mag hebben. Hoe dat gebeurt, bepaalt grotendeels hoe groot het risico is als iets fout gaat. De meeste kmo-zaakvoerders weten echter niet welke methode hun dienstverlener gebruikt. En dat is precies het probleem. Je hoeft daarom geen code te lezen om dit te bewaken. Je moet gewoon de juiste vragen stellen, en weten wat je verwacht als antwoord.

Waarom die authenticatie voor jou als zaakvoerder relevant is

Wanneer een geautomatiseerd systeem iets doet in jouw Azure-omgeving, moet het zich eerst identificeren. Dat kan op twee manieren: met een langdurige sleutel (een zogenaamd secret) die opgeslagen zit in je pipeline, of via een tijdelijk token dat automatisch vervalt na gebruik.

De eerste methode werkt via een technisch gebruikersaccount met een wachtwoord, ook wel een Service Principal genoemd. Dat wachtwoord, het secret, heeft een vervaldatum en moet periodiek vervangen worden. Als iemand dat secret te pakken krijgt, heeft die persoon toegang tot je cloudomgeving, soms voor maanden. Bovendien worden zulke secrets vaak opgeslagen op meerdere plekken: in pipelines, configuratiebestanden, soms zelfs in versiebeheer. Hoe meer plekken, hoe groter de kans op een lek.

De tweede methode heet OpenID Connect (OIDC), ook wel workload identity federation genoemd. Hier wordt namelijk geen permanent wachtwoord bewaard. In plaats daarvan krijgt het systeem op het moment van uitvoering een tijdelijk token dat na enkele minuten vervalt. Er valt dus niets te stelen dat later bruikbaar is.

Voor jou als opdrachtgever betekent dit concreet: een technisch gebruikersaccount met secret vraagt actief beheer, regelmatige rotatie en strikte opslag. Gaat dat even mis, dan loop je risico. OIDC verwijdert dat beheer grotendeels uit de vergelijking, maar vraagt wel dat je dienstverlener de configuratie correct en traceerbaar inricht.

OIDC versus SPN: het verschil in één overzicht

Volgens Microsoft Tech Community wordt OIDC inmiddels goed ondersteund door GitHub Actions, Azure DevOps en Terraform, de meest gebruikte tools voor moderne clouddeployments. Dat maakt de overstap voor veel kmo’s haalbaar, maar niet automatisch verplicht.

Wat je als zaakvoerder moet begrijpen: het gaat niet om de technologie an sich, maar om de beheerlast en het risicoprofiel dat erbij hoort. Een goed beheerde omgeving met technische gebruikersaccounts is niet per definitie onveilig. Een slecht geconfigureerde OIDC-omgeving is dat wel. Het verschil zit daarom in de discipline van je dienstverlener en de afspraken die je maakt.

Beide methodes vereisen bovendien dat toegangsrechten zo beperkt mogelijk zijn. In gewone taal: geef een systeem nooit meer toegang dan het strikt nodig heeft. Dat principe geldt voor beide methodes gelijkelijk.

Eén ding is zeker: als je leverancier vandaag nog met handmatig opgeslagen secrets werkt en geen migratieplan heeft, loont het om dat gesprek aan te gaan. Niet omdat OIDC de enige goede optie is, maar omdat het signaleert hoe je dienstverlener omgaat met beveiliging in het algemeen.

Welke vragen stel je morgen aan je leverancier?

Je hoeft dit niet zelf te implementeren. Wat je wel kunt doen, is je dienstverlener bevragen en concrete verwachtingen vastleggen. Hieronder vind je de vragen die ertoe doen:

1. Welke authenticatiemethode gebruiken jullie vandaag voor onze Azure-pipelines: OIDC of een technisch gebruikersaccount met secret?
2. Als het een technisch gebruikersaccount met secret is, wanneer worden die secrets geroteerd en hoe wordt dat bijgehouden?
3. Worden onze Entra-aanmeldingslogboeken actief gemonitord op afwijkingen?
4. Ondersteunen alle tools die jullie inzetten OIDC, of zijn er uitzonderingen?
5. Wat is jullie plan als we willen migreren naar OIDC, en hoe ziet een testomgeving eruit voordat we live gaan?

Daarnaast zijn er contractuele punten die je kunt opnemen in je SLA (Service Level Agreement, de dienstverleningsovereenkomst):

• Een expliciete vermelding van de gebruikte authenticatiemethode en wie die beheert.
• Een verplichting tot aantoonbare logging van toegang tot je Azure-omgeving.
• Een garantie dat bij migratie eerst getest wordt in een sandbox (een afgeschermde testomgeving) voordat wijzigingen live gaan.
• Een fallbackprocedure als OIDC tijdelijk niet beschikbaar is.

Bij Clear IT bekijken we dit soort vragen soms samen met klanten voordat ze een nieuw contract tekenen of verlengen. Niet om de leverancier te vervangen, maar om te zorgen dat de afspraken kloppen.

Stel deze vragen op je eerstvolgende overleg

Je hoeft geen expert te zijn om dit dossier aan te pakken. Stuur je leverancier de vijf vragen uit dit artikel en vraag om een schriftelijk antwoord. Als de antwoorden vaag blijven of de termen onbekend zijn, is dat al een signaal. Een goede dienstverlener legt dit immers zonder moeite uit. Vraag daarnaast naar een korte impactanalyse voor een eventuele migratie naar OIDC, inclusief een testplan. Zonder die basis geef je nooit akkoord voor een wijziging in je cloudbeveiliging.

Veelgestelde vragen

Moet ik als zaakvoerder zelf begrijpen hoe OIDC technisch werkt?

Nee. Het volstaat om te weten dat OIDC het risico op gestolen inloggegevens vermindert doordat er geen permanent wachtwoord opgeslagen wordt. Jouw rol is die eisen stellen aan je leverancier en laten controleren of ze correct zijn ingesteld.

Is een technisch gebruikersaccount met secret altijd onveilig?

Niet per definitie. Een technisch gebruikersaccount met secret dat correct beheerd wordt, regelmatig geroteerd is en minimale rechten heeft, kan veilig functioneren. Het probleem zit echter in de extra beheerlast: die beheerplicht wordt in de praktijk vaak onderschat, zeker bij kleinere teams.

Wat als mijn leverancier zegt dat OIDC niet compatibel is met onze tools?

Vraag dan welke tools dat zijn en waarom. GitHub Actions, Azure DevOps en Terraform ondersteunen OIDC goed in hun huidige versies. Als een tool het niet ondersteunt, vraag dan wanneer dat verandert en wat de tijdelijke mitigatie is tot dan.

Kan ik OIDC opnemen in een bestaande SLA?

Ja. Je kunt bij een contractverlenging of evaluatiemoment vragen om een addendum dat de gebruikte authenticatiemethode, loggingvereisten en een migratiepad naar OIDC vastlegt. Laat je juridisch adviseur of leverancier een standaardclausule opstellen die past bij jouw situatie.