Cloud security analisten missen misconfiguraties niet omdat ze slecht opletten, maar omdat er niets is om op te letten. Het NCSC verwoordde het in juni 2026 scherp in een expertblog over misconfiguraties als open deur naar gevoelige gegevens: bij een misconfiguratie is er geen technische kwetsbaarheid die gepatcht kan worden, de functionaliteit werkt precies zoals bedoeld, alleen is de toegang verkeerd ingeregeld. Er is geen exploit, geen malware en geen afwijkende verbinding. Er is een API die antwoord geeft aan iedereen die het vraagt.
Waarom on-premise detectiereflexen hier falen
Cloud security analisten die zijn opgeleid in een klassieke omgeving zoeken naar afwijkingen: een proces dat niet hoort te draaien, verkeer naar een onbekend adres, een bestand met een verdachte hash. Die aanknopingspunten bestaan bij cloudmisbruik simpelweg niet.
Het NCSC beschrijft precies waarom dat zo is. Kwaadwillenden scannen geautomatiseerd het internet af, waarbij in veel gevallen een enkel HTTP-verzoek volstaat om vast te stellen of een omgeving verkeerd is geconfigureerd. Daarna wordt de data opgevraagd via de standaard functionaliteiten van het platform, met legitieme verzoeken, waardoor het verkeer zich nauwelijks onderscheidt van regulier gebruik. Voor cloud security analisten betekent dat een fundamenteel andere zoekopdracht: niet zoeken naar wat er niet hoort, maar naar wat er te veel of te vaak gebeurt.
Dat is voor cloud security analisten een omslag in denken die niet vanzelf komt. De detectievraag verschuift van handtekening naar gedrag, volume en context. Wie normaal gesproken vijf klantrecords per dag opvraagt en er vandaag veertigduizend ophaalt, doet niets wat technisch verboden is. Alleen iemand die weet hoe normaal gebruik van dat specifieke platform eruitziet, ziet daar een incident.
Er speelt nog iets wat de vergelijking met on-premise verstoort. In een eigen datacenter is de scheiding tussen beheer en gebruik fysiek zichtbaar; in de cloud lopen die door elkaar. Een medewerker met de juiste rechten kan een opslagbucket publiek maken vanuit een webinterface, zonder tussenkomst van beheer en zonder wijzigingsproces. Cloud security analisten moeten daarom niet alleen aanvallers volgen, maar ook de eigen organisatie, want de meeste openstaande deuren worden intern gezet en niet van buitenaf geforceerd.
De schaal van het probleem in Nederland
De cijfers die het NCSC aanhaalt maken duidelijk waarom cloud security analisten hier niet omheen kunnen. Volgens onderzoek van de Cloud Security Alliance worstelt 58 procent van de organisaties met het juist inregelen van toegang en rechten bij SaaS-applicaties, terwijl organisaties gemiddeld meer dan honderd SaaS-applicaties gebruiken. Dat is een aanvalsoppervlak dat geen enkele beheerder handmatig overziet.
De incidenten uit 2025 en 2026 die het NCSC noemt laten zien waar cloud security analisten in de praktijk tegenaan lopen. Bij verkeerd geconfigureerde Salesforce Experience Cloud-omgevingen hadden gastgebruikers te ruime rechten gekregen, waardoor data zonder authenticatie opvraagbaar was via de Aura API. Salesforce bevestigde dat het niet om een kwetsbaarheid in het platform ging maar om configuratiefouten bij klanten. Een aanvalsgroep claimde daarmee tussen de driehonderd en vierhonderd organisaties te hebben getroffen.
Dichter bij huis onderzocht DIVD autorisatiemisconfiguraties in applicaties gebouwd op het Mendix low-code platform. Uit een grootschalige scan bleek in februari 2026 dat meerdere applicaties te ruime rechten hadden toegekend aan anonieme of nieuw geregistreerde gebruikers, waarbij namen, contactgegevens, adressen en identiteitsdocumenten blootgesteld waren. Dat raakt aan de ketenvraagstukken die we beschreven in ons artikel over supply chain security: de misconfiguratie zit vaak niet bij jou maar bij een platform dat je gebruikt.
Welke cloudvaardigheden je analisten concreet missen
Het gat tussen klassieke en cloud security analisten is te benoemen in vier concrete competenties. De eerste is het lezen van cloudauditlogs. Waar een Windows-eventlog een bekende structuur heeft, vraagt een cloudlogboek om kennis van de specifieke API-aanroepen van dat platform, van welke acties er wel en niet in belanden, en van de vertraging waarmee ze verschijnen.
De tweede vaardigheid voor cloud security analisten is het beoordelen van rechten en rollen in cloudomgevingen. Een analist die een alert krijgt over een account, moet kunnen vaststellen wat dat account allemaal mocht en of dat klopte. Zonder inzicht in rolstructuren en overervingsregels blijft die vraag onbeantwoord.
De derde is inzicht in identiteitsfederatie en applicatietoestemmingen. Veel cloudmisbruik verloopt via een applicatie die ooit toestemming kreeg en die niemand meer in de gaten houdt. De vierde is kennis van hardeningstandaarden zoals de CIS Benchmarks, zodat een analist niet alleen kan vaststellen dat iets gebeurde, maar ook of de configuratie waaronder het gebeurde deugde.
Die vier competenties samen maken het verschil tussen een team dat cloudalerts doorzet naar beheer en cloud security analisten die ze zelf afhandelen. Het is dezelfde afhankelijkheid die we beschreven bij SIEM-investeringen zonder getrainde analisten: de logbron aansluiten is het makkelijke deel, de interpretatie is het werk.
Detectie inrichten op gedrag in plaats van handtekeningen
Het NCSC geeft de richting expliciet aan: omdat bij misbruik gebruik wordt gemaakt van legitieme platformfunctionaliteit, kan detectie lastig zijn, dus richt detectie in op afwijkingen in gedrag, volume en context, schakel auditlogging in en zorg dat logs centraal worden verzameld en periodiek geanalyseerd.
Praktisch levert dat voor cloud security analisten een handvol detecties op die in vrijwel elke cloudomgeving waarde hebben. Een sterke stijging in het volume van data-opvragingen door een enkel account of een enkele sessie. Toegang tot gegevens door anonieme of gastgebruikers waar dat niet hoort. Nieuwe applicatietoestemmingen met brede rechten. Wijzigingen in configuratie van kritieke diensten buiten de gebruikelijke wijzigingsvensters. En eerste toegang vanaf infrastructuur die je normaal nooit ziet.
Begin daarbij klein en kies bewust. Een organisatie die alles tegelijk wil monitoren, verzuipt in ruis en stopt binnen een kwartaal. Selecteer de twee of drie platformen waar de gevoeligste gegevens staan, breng in kaart welke gebruikers en applicaties daar toegang toe hebben, en richt daar de eerste detecties op in. Pas als die stabiel draaien en het team weet wat een terechte melding is, komt de volgende omgeving aan de beurt. Zo groeit de detectiedekking mee met de vaardigheid van het team in plaats van erop vooruit te lopen.
Geen van die detecties werkt zonder dat iemand de drempelwaarden kent voor de eigen omgeving. Dat is precies waarom cloud security analisten hun eigen platformen moeten begrijpen en niet alleen het detectieplatform. Leg die drempels en de bijbehorende handelingen vast op een manier die onder druk bruikbaar is, in dezelfde geest als ons artikel over bruikbare SOC-playbooks.
Een team dat deze detecties eenmaal draait, kan de volgende stap zetten: proactief zoeken naar misconfiguraties voordat een aanvaller ze vindt. Die werkwijze beschreven we in threat hunting binnen je bestaande team. Het NCSC merkt daarbij terecht op dat hoe langer een misconfiguratie bestaat, hoe groter de kans dat deze uiteindelijk wordt misbruikt.
Trainen op een omgeving die je zelf gebruikt
Cloud security analisten leren hun vak slecht uit een boek. Het verschil tussen weten dat er auditlogging bestaat en weten welke aanroep in jouw omgeving een gastgebruiker verraadt, ontstaat door het te doen. Daarom werkt training op de eigen omgeving beter dan een generieke cursus, een principe dat we eerder uitwerkten in praktijkopleiding versus certificering en in ons artikel over cybersecurity bootcamps voor bedrijven.
De opbouw naar volwaardige cloud security analisten volgt de rollen die je al hebt. Analisten die cloudalerts moeten kunnen triagen, beginnen bij de opleiding SOC T1 + T2 Analyst, waar gestructureerd onderzoek vanaf een signaal centraal staat. Voor het zelfstandig uitzoeken van de reikwijdte van een cloudincident, bijvoorbeeld wanneer blijkt dat een API maanden open stond, komt de opleiding SOC T3 Analyst in beeld. Twijfel je welk niveau je nodig hebt, dan helpt ons artikel over tier 1 versus tier 2 bij die keuze.
Twee aanvullende richtingen zijn voor cloud security analisten waardevol. Wie wil begrijpen hoe een aanvaller een verkeerd ingeregelde omgeving daadwerkelijk uitbuit, heeft baat bij de opleiding Penetration testing, omdat aanvalsdenken de snelste manier is om te zien waar je eigen configuratie rammelt. En loopt een cloudincident uit op bewijsvoering richting de Autoriteit Persoonsgegevens of een verzekeraar, dan telt de kwaliteit van het onderzoek; de opleiding Cyber Forensics Expert richt zich op sporen die standhouden.
Let bij dit alles op de werkdruk van je cloud security analisten. Cloudlogs genereren volume, en een groep die al kampt met alertmoeheid wordt door een nieuwe logbron eerder minder effectief dan meer. Bouw detectie daarom stapsgewijs op en meet of het werkt, langs de lijnen uit ons artikel over zinvolle cybersecurity KPI’s.
Van losse alerts naar structurele grip
Het NCSC sluit zijn analyse af met de observatie dat misconfiguraties niet nieuw zijn en onder tijdsdruk zo gemaakt, en juist daarom om structurele aandacht vragen in plaats van een incidentele check. Dat is precies het verschil tussen een scan die je een keer per jaar draait en een team dat elke week kijkt. Waar jouw organisatie op die schaal staat, bepaal je met het cybersecurity maturity model.
De conclusie is dezelfde als in information security structureel verbeteren: het probleem is niet op te lossen met een extra product, want de aanval gebruikt juist de standaardfunctionaliteit van producten die je al hebt. Wat wel werkt zijn cloud security analisten die de eigen omgeving door en door kennen. Welke rollen je daarvoor nodig hebt, staat in je eerste securityteam samenstellen.
Hoe je die capaciteit opbouwt vanuit je huidige bezetting, van open klas tot in-company traject op je eigen cloudomgeving, staat op de pagina voor werkgevers. Het volledige niveauoverzicht vind je bij alle opleidingen, waaronder de brede opleiding Cyber Security Specialist voor beheerders die doorgroeien naar een securityrol.
Wil je toetsen of jouw team een openstaande API in de eigen omgeving zou opmerken? Bekijk de eerstvolgende startdata of plan een kennismaking om de mogelijkheden te bespreken.
