Checklist cloud security assessment: 12 controles voor Microsoft 365, Entra ID, Azure en AWS
Twaalf controles die je zelf doet in Microsoft 365, Entra ID, Azure en AWS met een leesrol, wat je eerst oplost, en wanneer een extern assessment of een cloud pentest de volgende stap is.

TL;DR
- Twaalf controles die je zelf doet in je eigen tenant of account, met een leesrol, voor je een externe cloud security assessment boekt.
- Identiteit eerst: hiaten in MFA, vaste beheerdersrechten, uitzonderingen in conditional access en vergeten app registrations doen meer schade dan een open poort.
- Daarna opslag, doorstuurregels in mail, logging en back-ups, want daar vinden beoordelaars telkens dezelfde fouten.
- Een checklist zegt of een instelling aan staat. Een assessment zegt of het geheel klopt, en een cloud pentest toont wat een aanvaller met de gaten doet.
Veel organisaties in Belgie en Nederland met 20 tot 500 mensen draaien op Microsoft 365, met Entra ID als identiteitslaag en daarnaast een paar subscriptions in Azure of een AWS-account. Die tenant krijgt zelden de aandacht die het kantoornetwerk kreeg. Deze checklist geeft je twaalf controles die je zelf in een namiddag doet, in de beheerportalen die je al hebt. Het is het praktische vervolg op ons eerdere artikel over wat een cloud security assessment bekijkt, dat elk domein dieper uitlegt. Laat je het liever door iemand anders doen, dan dekt onze cloud pentest dezelfde grond en probeert daarna te misbruiken wat hij vindt; het overzicht van onze pentests legt uit hoe zo'n opdracht verloopt.
Hoe je deze checklist gebruikt
Open het Entra admin center, de Microsoft Defender portal, de Azure portal en de AWS console met een rol die kan lezen maar niets wijzigt. Zet elke controle op groen, oranje of rood en schrijf erbij wie de fix bezit. Je geeft jezelf geen score. Je maakt een lijst.
Identiteit en toegang
1. MFA op elk account, zonder oude uitzonderingen
Controleer of elke gebruiker, ook gasten en beheerders, MFA afgedwongen heeft, en of legacy authentication (IMAP, POP, SMTP AUTH, basic authentication) geblokkeerd is. In AWS kijk je of de root user MFA heeft en of geen enkele IAM user met alleen een wachtwoord inlogt.
2. Vaste beheerdersrechten
Tel de Global Administrators in Entra ID en de rollen met AdministratorAccess in AWS. Wie die rechten permanent heeft, in plaats van ze te activeren wanneer het nodig is via Privileged Identity Management of een role assumption, staat op rood.
3. Conditional access en de uitzonderingen erop
Lees elk beleid, ook de policies in report-only die nooit zijn aangezet. In de uitzonderingslijsten vinden beoordelaars het serviceaccount dat MFA omzeilt omdat een migratie dat twee jaar geleden nodig had.
4. App registrations, service principals en access keys
Lijst de app registrations op die een secret of certificaat hebben, die waarvan niemand een eigenaar kan noemen, en de rechten die ze op Graph dragen. In AWS lijst je de access keys op die ouder zijn dan de rotatietermijn die je zegt te volgen.
5. Gasttoegang en delen
Kijk hoe gasten uitgenodigd worden, wat ze in de directory kunnen zien, en welke sites in SharePoint en OneDrive anonieme links toelaten. Meestal beslist een instelling voor de hele tenant hierover, en die staat vaak nog op de standaardwaarde.
Data, opslag en mail
6. Publieke opslag en SAS-tokens zonder einddatum
Zoek in Azure naar storage accounts die nog anonieme toegang tot blobs toelaten en naar SAS-tokens zonder vervaldatum. In AWS controleer je of Block Public Access aan staat op accountniveau en of geen enkele bucket policy leesrechten geeft aan iedereen.
7. Mailstroom en doorstuurregels
Lijst in Exchange Online de mailboxregels en transportregels op die naar externe adressen doorsturen, en controleer SPF, DKIM en DMARC op elk domein dat mail verstuurt. Een doorstuurregel is de standaardmanier waarop een aanvaller mail blijft meelezen nadat jij het wachtwoord hebt gereset.
Blootstelling van het netwerk
8. Beheerpoorten en databases open naar het internet
Zoek in de network security groups van Azure en de security groups van AWS naar regels die 0.0.0.0/0 toelaten op RDP, SSH of databasepoorten, en lijst elk publiek IP-adres op dat aan een database of opslagdienst hangt. Dit is de enige controle waar een scanner helpt. De andere elf vragen een mens die instellingen leest.
Geheimen
9. Waar geheimen staan
Controleer of connection strings en API-sleutels in Key Vault of Secrets Manager staan, of in app settings, pipelinevariabelen en repositories. Zoek in je repositories naar de voor de hand liggende patronen en kijk wie de vault kan lezen.
Logging, detectie en herstel
10. Logs die aan staan en bewaard blijven
Controleer of de Unified Audit Log aan staat in Microsoft 365, of de aanmeldlogs van Entra langer bewaard blijven dan de standaard en naar een workspace gaan waarin je kan zoeken, en of CloudTrail elke AWS-regio dekt. Niemand merkt de indringer als de logs na een paar dagen stoppen.
11. Back-up en een geteste restore
Kijk wat de bewaartermijnen van Microsoft 365 echt dekken, of de back-ups in Azure en AWS onveranderbaar zijn en in een apart account staan, en wanneer je het laatst iets hebt teruggezet. Een back-up die je nooit hebt teruggezet is een veronderstelling.
Eigenaarschap en gedeelde verantwoordelijkheid
12. Wie de tenant bezit
Schrijf op wie eigenaar is van elke subscription, elk account en de tenant zelf, wie de toegangen nakijkt en wanneer dat het laatst gebeurde. Secure Score in Microsoft 365 en Security Hub in AWS geven je een eerste nulmeting, maar een score is geen eigenaar.
Wat je eerst oplost
Los identiteit op voor al de rest: vaste beheerdersrechten, hiaten in MFA en de uitzonderingen in conditional access. Sluit daarna publieke opslag en externe doorstuurregels, want dat zijn de vondsten die een aanvaller op dag een gebruikt. Logging en back-ups komen op de derde plaats. Ze tellen even zwaar, maar ze beperken de schade in plaats van de inbraak te voorkomen.
Checklist klaar. Assessment, pentest of beide?
De checklist zegt of een instelling aan staat. Een cloud security assessment legt een extern paar ogen op de volledige configuratie, ook op de stukken waar je niet aan dacht; het eerdere artikel beschrijft wat dat omvat. Een cloud pentest gaat een stap verder. Hij neemt een account met weinig rechten en probeert via de gaten beheerdersrechten te bereiken, zoals we beschrijven in cloud IAM pentesting en configuratieaudit. Voor de meeste organisaties komt het assessment eerst, en volgt de pentest zodra de duidelijke vondsten zijn opgelost.
Veelgestelde vragen
Kan ik deze checklist voor een cloud security assessment zelf doen?
Ja. Een leesrol in elk portaal volstaat voor elke controle, en een tenant van Microsoft 365 met een of twee subscriptions kost je een namiddag. Wat je zelf niet kan, is zien wat je niet wist dat je moest nakijken, en dat gat dicht een externe beoordeling.
Dekt de checklist Microsoft 365 of alleen Azure en AWS?
Alle drie, want de identiteitslaag is gedeeld: Entra ID authenticeert je gebruikers van Microsoft 365 en je subscriptions in Azure. Controles 1 tot 5 en 7 gaan vooral over Microsoft 365 en Entra ID, controles 6, 8 en 9 over Azure en AWS, en de rest geldt overal.
Wat doe ik met de rode punten?
Groepeer ze per eigenaar, los eerst de identiteitspunten op en noteer wat je hebt gewijzigd. Wil je de fixes daarna laten nakijken, dan test een cloud pentest of de paden die je hebt gesloten ook echt dicht zijn, en geeft het rapport je bewijs voor een auditor of verzekeraar.
Past Google Cloud in deze checklist?
Ja, met andere namen voor dezelfde controles: IAM en organisatiebeleid voor identiteit, public access prevention voor Cloud Storage, Cloud Audit Logs voor logging. Het staat niet in de titel omdat de meeste tenants die wij in Belgie en Nederland zien op Microsoft 365 draaien, met Azure of AWS ernaast.
Is deze checklist genoeg voor NIS2 of ISO 27001?
Nee. NIS2 vraagt risicomaatregelen en bewijs dat je ze nakijkt, en ISO 27001 vraagt een managementsysteem rond de maatregelen. De checklist is een goede input voor beide; onze pagina over NIS2 compliance legt uit wat auditors in de praktijk vragen.
Hoe verhoudt dit zich tot zero trust?
Controles 1 tot 3 zijn de identiteitskant van zero trust zoals NIST het beschrijft in SP 800-207: elk verzoek verifieren, zo weinig rechten als mogelijk geven, het netwerk als vijandig beschouwen. De checklist maakt dat concreet voor een tenant; ons artikel over zero trust beveiliging behandelt het model.
Hoe vaak herhaal ik de checklist?
Elk kwartaal voor de identiteitscontroles, en na elke migratie of nieuwe koppeling voor de andere. Instellingen verschuiven omdat mensen problemen oplossen onder tijdsdruk, en de checklist vangt de uitzonderingen die het probleem hebben overleefd.
Gerelateerde diensten en bronnen
Onze cloud pentest voor AWS, Azure en Google Cloud pikt op waar deze checklist stopt, en de pagina over cloudbeveiliging beschrijft het volledige plaatje voor organisaties die blijvende aandacht willen. De redenering achter elk domein lees je in wat een cloud security assessment bekijkt, en de identiteitskant in detail in cloud IAM pentesting en configuratieaudit. Zijn gestolen inloggegevens je grootste zorg, dan legt het artikel over infostealers en gestolen inloggegevens uit hoe accounts overgenomen worden, en wat kost een pentest legt uit wat een offerte bepaalt voor je er een aanvraagt.