Cloud IAM Pentesting: de identiteitsfouten die aanvallers echt misbruiken

TL;DR

• Identity, niet infrastructuur, is het grootste cloudrisico geworden: de meeste cloudinbreuken zijn terug te voeren op een gecompromitteerde of verkeerd geconfigureerde identiteit, niet op een ongepatcht systeem.
• Een cloud IAM pentest test of een account met beperkte rechten, een service principal of een geautomatiseerde workflow kan opschalen naar beheerdersrechten via roltoewijzingen, vertrouwensrelaties of configuratiefouten.
• MFA inschakelen is niet hetzelfde als identity beveiligen. Een kwetsbaarheid in Entra ID uit 2025 toonde aan dat bevoorrechte toegang mogelijk was zonder MFA, conditional access of een normaal auditspoor te triggeren.
• Een configuratieaudit en een penetratietest beantwoorden een andere vraag: een audit vindt wat er fout staat, een pentest bewijst wat een aanvaller er echt mee kan.
• Sectricity combineert beide in één opdracht, zodat je een geprioriteerd beeld krijgt, gebaseerd op wat echt exploiteerbaar is voor je cloud identity, niet enkel een compliancechecklist.

Cloudbeveiliging ging vroeger vooral over firewalls, patchen en netwerksegmentatie. In 2026 is dat verhaal veranderd. Binnen Azure, AWS en Google Cloud zijn het net de accounts, rollen en rechten die bepalen wie wat mag doen in je tenant, uitgegroeid tot het belangrijkste aanvalsoppervlak. Bij Sectricity's cloud pentests draait het steeds minder om infrastructuurkwetsbaarheden en steeds meer om identity: roltoewijzingen, privileged identity management, conditional access en de service principals die je applicaties met je cloudomgeving verbinden.

Waarom cloud identity het grootste risico is geworden

Een paar jaar geleden ging het gros van de cloudincidenten nog over een opengezette poort, een ongepatchte server of een vergeten publieke bucket. Vandaag ligt de meerderheid van de cloudinbreuken aan de basis bij een gecompromitteerde of verkeerd geconfigureerde identiteit, niet bij een technische kwetsbaarheid in de onderliggende infrastructuur. Die verschuiving is logisch: naarmate meer van wat een cloudtenant kan doen wordt uitgedrukt via rollen, groepen, conditional access beleid en service principals, wordt precies die laag het interessantste doelwit, en de plek waar een kleine, over het hoofd geziene fout het snelst zit.

Wat we echt testen in een cloud IAM pentest en configuratieaudit

Een cloud IAM pentest en configuratieaudit bekijken dezelfde omgeving vanuit twee invalshoeken: wat staat er geconfigureerd, en wat kan er echt worden misbruikt. In de praktijk vallen de meeste bevindingen onder een van vijf categorieën.

Privilege escalation via roltoewijzingen

Een cloud IAM pentest stopt niet bij het nalezen van wie welke rol op papier heeft. Testers zoeken actief naar accounts, menselijk of automatisch, die vanuit een beperkte rol kunnen opschalen naar volledige beheerdersrechten over een subscription of tenant. In de praktijk begint dit vaak met een onschuldig ogende roltoewijzing: een gebruiker of applicatie die Contributor- of Owner-rechten kreeg op één resourcegroep om iets snel voor elkaar te krijgen, en die nooit meer werd ingetrokken. Vandaar brengen testers in kaart of die toegang doorloopt naar een pad richting Global Administrator of volledige eigendom van de subscription.

Gaten in Privileged Identity Management

Privileged Identity Management (PIM) van Microsoft Entra ID is bedoeld om bevoorrechte rollen tijdelijk te maken en aan een verantwoording te koppelen. In assessments stoot Sectricity regelmatig op tenants waar de PIM-licenties wel beschikbaar zijn, maar simpelweg niet ingeschakeld voor de rollen die er echt toe doen. Daardoor blijven accounts continu, dag en nacht, over de rechten van een Global Administrator beschikken. Een gecompromitteerd credential op zo'n account geeft een aanvaller onmiddellijk en permanent bevoorrechte toegang, zonder extra stap.

Conditional access en het omzeilen van MFA

Het beleid voor conditional access is vaak opgebouwd rond een beperkt aantal bekende scenario's, zoals blokkeren op locatie of MFA verplichten op het web, terwijl legacy authenticatieprotocollen, service accounts of break-glass accounts buiten het bereik blijven. Een cloud IAM pentest gaat na of deze hiaten kunnen worden gebruikt om MFA volledig te omzeilen, in plaats van er zomaar van uit te gaan dat een beleid werkt zoals bedoeld zodra het in de console staat.

Service principals, app-registraties en verouderde credentials

Elke integratie, CI/CD-pijplijn en interne tool die met je cloudomgeving communiceert, doet dat doorgaans via een service principal of app-registratie. Die stapelen zich op in de loop van de tijd, houden vaak client secrets aan die nooit verlopen, en worden zelden nog herbekeken zodra het project waarvoor ze werden aangemaakt, is afgerond. Testers zoeken specifiek naar overgeprivilegieerde of vergeten service principals als stille route naar blijvende toegang.

Rechten op storage accounts en SAS-tokens

Publiek toegankelijke storage accounts en te ruim toegekende Shared Access Signature (SAS) tokens blijven een van de meest voorkomende bevindingen in cloudassessments. Eén langlopend, breed scoped SAS-token kan een volledig storage account blootstellen aan iedereen die de link in handen krijgt, ongeacht hoe goed de rest van de tenant is geconfigureerd.

De les uit een echte kwetsbaarheid in Entra ID

In 2025 maakten onderzoekers een kritieke kwetsbaarheid in Microsoft Entra ID (CVE-2025-55241) bekend rond Actor tokens, een intern delegatiemechanisme dat door een verouderde API niet correct werd gevalideerd over de grenzen van een tenant heen. Het lek had een aanvaller kunnen toelaten om zich voor te doen als om het even welke gebruiker in om het even welke tenant, inclusief Global Administrators, zonder MFA, conditional access of een normaal spoor in de aanmeldlogs te triggeren. Microsoft loste het probleem snel op, maar de zaak blijft een nuttige les voor elke organisatie die met Entra ID werkt: een gecompromitteerde identiteit ziet er niet altijd uit als een mislukte inlogpoging of een melding van conditional access. Ervan uitgaan dat je identiteitslaag veilig is omdat de dashboards er netjes uitzien, is iets anders dan het effectief testen.

Configuratieaudit of penetratietest? Cloudomgevingen hebben beide nodig

Een configuratieaudit toetst je cloudomgeving aan een gekende, goede basislijn: welke rollen waar zijn toegewezen, of PIM en conditional access zijn ingeschakeld, hoe storage accounts en key vaults zijn geconfigureerd. Dat is grondig, systematisch en onmisbaar voor compliancekaders zoals NIS2 of ISO 27001. Wat een audit niet kan vertellen, is of die misconfiguraties in jouw specifieke omgeving, in combinatie met elkaar, ook echt exploiteerbaar zijn. Daar komt een penetratietest bij kijken: testers ketenen bevindingen aan elkaar zoals een aanvaller dat zou doen, om aan te tonen of net te ontkrachten dat een concreet pad naar bevoorrechte toegang bestaat. Sectricity's auditklare pentest aanpak combineert beide, zodat de auditbevindingen en het pad naar exploitatie in hetzelfde rapport terechtkomen, geprioriteerd op wat effectief bereikbaar is, niet enkel op een severity score.

Wat goede remediatie eruitziet

Zodra een cloud IAM pentest en configuratieaudit zijn afgerond, zijn de meest impactvolle fixes zelden exotisch. PIM verplicht maken voor elke bevoorrechte rol, permanente toegang als Global Administrator wegnemen, conditional access aanscherpen zodat legacy authenticatie en service accounts wel worden meegenomen, een gestructureerde opruiming van service principals uitvoeren, en langlopende SAS-tokens vervangen door tijdgebonden, nauw scoped alternatieven, lossen doorgaans het gros van de bevindingen op. De waarde van de pentest zit erin dat die aantoont welke van die fixes echt een exploiteerbaar pad sluit, zodat het remediatiewerk eerst gaat naar wat het meeste risico wegneemt.

Veelgestelde vragen

Wat is een cloud IAM pentest?

Een cloud IAM pentest is een beveiligingsassessment dat test of identiteiten in je cloudomgeving, zoals gebruikersaccounts, service principals en geautomatiseerde workflows, kunnen worden misbruikt om rechten op te schalen of ongeautoriseerde toegang te krijgen. Het gaat verder dan een configuratiecontrole door actief de escalatiepaden te proberen die een aanvaller zou gebruiken in Entra ID, AWS IAM of Google Cloud IAM.

Hoe verschilt een cloud configuratieaudit van een penetratietest?

Een configuratieaudit toetst je cloudomgeving aan een gekende, goede basislijn en signaleert instellingen die daarvan afwijken. Een penetratietest gaat verder door actief te proberen die misconfiguraties, alleen of in combinatie, uit te buiten om te bevestigen of ze tot echte ongeautoriseerde toegang leiden.

Welke cloudplatformen dekt een cloud IAM pentest?

Cloud IAM-assessments dekken doorgaans Microsoft Entra ID en Azure role-based access control, AWS IAM-rollen en -policies, en Google Cloud IAM, afhankelijk van welke platformen je organisatie gebruikt. Hybride omgevingen die on-premises Active Directory koppelen aan Entra ID vragen extra aandacht, omdat ze het aanvalsoppervlak over beide werelden uitbreiden.

Betekent MFA inschakelen dat onze cloud identity veilig is?

Nee. MFA verkleint het risico op eenvoudige diefstal van credentials, maar pakt geen privilege escalation via roltoewijzingen aan, geen hiaten in de scope van conditional access, en geen kwetsbaarheden in het identityplatform zelf. Een cloud IAM pentest test de paden die bestaan, ongeacht of MFA is ingeschakeld.

Hoe lang duurt een cloud IAM pentest?

De meeste cloud IAM pentests en configuratieaudits nemen één tot drie weken in beslag, afhankelijk van het aantal subscriptions, tenants en integraties binnen scope. Een gerichte opdracht op één tenant met een afgebakende set rollen kan vaak sneller worden afgerond.

Hoe vaak moeten we een assessment van onze cloud identity laten uitvoeren?

Een jaarlijkse cloud IAM pentest en configuratieaudit is voor de meeste organisaties een redelijke basis, met een extra check na grote wijzigingen zoals een nieuwe hybride opzet voor identity, een grootschalige applicatiemigratie, of een sterke toename van het aantal service principals en integraties in gebruik.

Gerelateerde diensten en bronnen

Het risico rond cloud identity staat zelden op zichzelf, en daarom levert Sectricity's cloud pentest doorgaans samen met een bredere blik op je cloudbeveiliging, inclusief netwerkconfiguratie, sleutelbeheer en logging naast identity. Organisaties die testbewijs moeten aantonen richting een toezichthouder of auditor, bijvoorbeeld onder NIS2 of een securityvragenlijst van een klant, combineren dit vaak met Sectricity's auditklare pentest, die bevindingen en remediatiebewijs specifiek daarvoor structureert. Twijfel je nog of een configuratieaudit, een volledige pentest, of beide zinvol zijn voor jouw omgeving? Dat gesprek voer je best vóór je een vaste opdracht laat scopen.