Nobody breaks into the data centre. They walk in through a setting we left wrong — in plain language: the four mistakes that cause most cloud breaches, and the one control that prevents each. Niemand breekt in bij het datacenter. Ze komen binnen via een instelling die wij verkeerd lieten staan — in gewone taal: de vier fouten achter de meeste cloudincidenten, en welke maatregel elke fout voorkomt.
Cloud storage is private by default. Then someone needs to share a file with a supplier, a deadline is close, and the quickest fix is one setting: make the bucket public. It works, nobody is hurt, and the setting is never changed back. Automated scanners run by criminals and researchers sweep the entire internet for exactly this, continuously. An open bucket can be found within hours.
Business impact: whatever was in that bucket is now public — customer records, backups, contracts, scanned passports from onboarding. With personal data inside, it can be a reportable breach under the GDPR: the Autoriteit Persoonsgegevens within 72 hours of becoming aware, and the people affected when the risk is high. Nobody attacked us. We published it ourselves.
Cloudopslag is standaard privé. Dan moet iemand een bestand delen met een leverancier, de deadline nadert, en de snelste oplossing is één instelling: maak de bucket publiek. Het werkt, niemand heeft er last van, en de instelling wordt nooit teruggezet. Geautomatiseerde scanners van criminelen en onderzoekers doorzoeken voortdurend het hele internet naar precies dit. Een open bucket kan binnen uren worden gevonden.
Bedrijfsimpact: alles wat in die bucket stond is nu openbaar — klantgegevens, back-ups, contracten, gescande paspoorten uit het onboardingproces. Staan er persoonsgegevens in, dan kan het een meldplichtig datalek zijn onder de AVG: binnen 72 uur nadat wij het weten bij de Autoriteit Persoonsgegevens, en bij hoog risico ook bij de betrokkenen. Niemand heeft ons aangevallen. We hebben het zelf gepubliceerd.
Automated scanners already sweep the internet for public buckets without any AI. What AI adds is speed of triage afterward: sorting thousands of exposed files by sensitivity so an attacker finds the passports and contracts first instead of wading through routine data.Geautomatiseerde scanners doorzoeken het internet al zonder AI op publieke buckets. Wat AI toevoegt is snellere triage achteraf: duizenden blootgestelde bestanden sorteren op gevoeligheid, zodat een aanvaller eerst de paspoorten en contracten vindt in plaats van zich door routinegegevens heen te werken.
A deployment pipeline connected to an AI coding assistant can follow an outdated example it was trained on and publish a bucket as public by default, turning a routine automated task into an exposure nobody reviewed before it went live.Een implementatiepijplijn gekoppeld aan een AI-codeerassistent kan een verouderd voorbeeld uit de trainingsdata volgen en een bucket standaard publiek maken, waardoor een routinematige geautomatiseerde taak een blootstelling wordt die niemand vooraf heeft beoordeeld.
AI can scan what is inside an exposed bucket and rank findings by how sensitive the content actually is, so the worst leaks get fixed first. Prevention still comes from policy-as-code that makes saving a public bucket impossible in the first place.AI kan de inhoud van een blootgestelde bucket scannen en bevindingen rangschikken naar hoe gevoelig die inhoud werkelijk is, zodat de ergste lekken het eerst worden opgelost. Preventie komt nog steeds van beleid als code dat het opslaan van een publieke bucket onmogelijk maakt.
Many cloud accounts are still operated with static keys — long random strings that grant access without a person, a password or a second factor. Developers need them to make things work, so they end up in configuration files, scripts and, sooner or later, in a code repository. If that repository is public for even a few minutes, automated bots harvest the key and use it before anyone can remove it. Deleting the commit does not help; the key has already been copied.
Business impact: the fastest version is a cloud bill for thousands of servers mining cryptocurrency over a weekend. The slower version is worse — the key is used quietly to read our databases for months. Either way the intruder has exactly the rights that key had, and keys that were created “to get it working” usually have far more rights than the job required.
Veel cloudaccounts worden nog bediend met vaste sleutels — lange willekeurige tekenreeksen die toegang geven zonder persoon, wachtwoord of tweede factor. Ontwikkelaars hebben ze nodig om dingen werkend te krijgen, dus belanden ze in configuratiebestanden, scripts en vroeg of laat in een coderepository. Is die repository ook maar een paar minuten publiek, dan oogsten bots de sleutel en gebruiken ze hem voordat iemand hem kan verwijderen. De commit weghalen helpt niet; de sleutel is al gekopieerd.
Bedrijfsimpact: de snelle variant is een cloudfactuur voor duizenden servers die een weekend lang cryptovaluta delven. De langzame variant is erger — de sleutel wordt maandenlang stil gebruikt om onze databases te lezen. In beide gevallen heeft de indringer precies de rechten van die sleutel, en sleutels die zijn aangemaakt “om het werkend te krijgen” hebben meestal veel meer rechten dan nodig was.
Bots that watch every public commit for credentials existed long before AI. What has changed is how cheaply anyone can build one: a short AI-written script now recognises dozens of key formats across providers, putting that capability within reach of far more actors.Bots die elke publieke commit op inloggegevens controleren, bestonden al ruim voor AI. Wat is veranderd, is hoe goedkoop iemand er nu een kan bouwen: een kort, door AI geschreven script herkent tientallen sleutelformaten bij verschillende leveranciers, waardoor veel meer partijen dit kunnen.
A developer using an AI coding assistant may paste a live key into the chat for help debugging, or let the assistant read a local configuration file it should never touch, so the leak now starts inside a tool rather than a public repository.Een ontwikkelaar die een AI-codeerassistent gebruikt, kan een actieve sleutel in de chat plakken om hulp te vragen bij het debuggen, of de assistent een configuratiebestand laten lezen dat hij nooit had mogen aanraken, waardoor het lek in een tool ontstaat, niet in een repository.
AI-based scanning classifies commit content and recognises a likely credential with far fewer false positives than plain pattern matching. Catching it faster only limits the damage if keys already live in a vault and expire in hours rather than years.AI-gebaseerde scanning classificeert commitinhoud en herkent een waarschijnlijk inloggegeven met veel minder valse meldingen dan eenvoudige patroonherkenning. Sneller vinden beperkt de schade alleen als sleutels al in een kluis leven en binnen uren verlopen in plaats van jaren.
Cloud platforms let us split our estate into many separate accounts: production, test, finance, each department, each product. That separation is the cheapest security we will ever buy — but only if nothing bridges it. In practice there is almost always one role that does: the platform team's administrator, a monitoring tool, a deployment pipeline that “needs access to everything”. Whoever holds that one credential holds the entire company.
Business impact: the difference between losing one test environment and losing everything, including the backups, is entirely decided by how that one role was set up. This is the same lesson as the domain administrator on-premises, and the same failure: convenience for the few people who run the platform, at the price of a single point of total compromise.
Cloudplatforms laten ons onze omgeving opdelen in veel losse accounts: productie, test, finance, elke afdeling, elk product. Die scheiding is de goedkoopste beveiliging die we ooit zullen kopen — maar alleen als niets haar overbrugt. In de praktijk is er bijna altijd één rol die dat wel doet: de beheerder van het platformteam, een monitoringtool, een uitrolpijplijn die “toegang tot alles nodig heeft”. Wie die ene inlog heeft, heeft het hele bedrijf.
Bedrijfsimpact: het verschil tussen één testomgeving kwijtraken en álles kwijtraken, inclusief de back-ups, wordt volledig bepaald door hoe die ene rol is ingericht. Dit is dezelfde les als de domeinbeheerder in het eigen datacenter, en dezelfde fout: gemak voor de paar mensen die het platform beheren, tegen de prijs van één punt van totale compromittering.
Holding the one credential that reaches every account is unchanged by AI; getting there still takes the same phishing or leak. Once inside, though, AI can map every downstream system that role can touch and rank which to hit first, in minutes instead of hours.Het bezit van de ene inlog die elk account bereikt, verandert niet door AI; die bemachtigen vraagt nog dezelfde phishing of hetzelfde lek. Eenmaal binnen brengt AI elk bereikbaar systeem in kaart en bepaalt wat het eerst wordt aangevallen, in minuten in plaats van uren.
A platform team gives its own AI assistant the same broad administrative role it uses daily, so a manipulated instruction hidden in a ticket or document the assistant reads can trigger an action across every connected account without anyone approving it directly.Een platformteam geeft zijn eigen AI-assistent dezelfde brede beheerdersrol die het dagelijks gebruikt, zodat een verborgen, gemanipuleerde instructie in een ticket of document die de assistent leest een actie kan triggeren over elk gekoppeld account, zonder dat iemand dit rechtstreeks goedkeurt.
Posture tools can automatically detect which single identity can reach every account, a bridge manual audits routinely miss between reviews. The fix is removing that bridge itself: least privilege per workload, with organisation-wide admin only as a logged, break-glass exception.Configuratietools kunnen automatisch detecteren welke ene identiteit elk account kan bereiken, een brug die handmatige audits tussen controles vaak missen. De oplossing is die brug zelf weghalen: minimale rechten per workload, met organisatiebreed beheer alleen als gelogde noodprocedure.
A cloud account can be used in many regions of the world at once — on AWS every region launched before 2019 is switched on by default — whether we use them or not. An intruder with a key does not set up shop where we work; they pick the region we never open, in the account nobody owns any more — the proof-of-concept from two years ago, the sandbox of a team that was reorganised away. Logging there was never switched on. Nothing they do generates an alert, because there is nothing to generate it.
Business impact: the intruder stays for as long as they like. Typically the finance department finds them first, when the monthly invoice doubles. By then the same key has usually been tried against the accounts we do watch. An estate we do not log is an estate we cannot say anything about to a regulator, an insurer or a customer — not even “we checked and nothing happened”.
Een cloudaccount is in veel regio's van de wereld tegelijk bruikbaar — bij AWS staat elke regio van vóór 2019 standaard aan — of we die nu gebruiken of niet. Een indringer met een sleutel vestigt zich niet waar wij werken; hij kiest de regio die wij nooit openen, in het account waar niemand meer eigenaar van is — het proefproject van twee jaar geleden, de zandbak van een team dat is wegereorganiseerd. Logging is daar nooit aangezet. Niets van wat hij doet levert een alarm op, omdat er niets is dat alarm kan slaan.
Bedrijfsimpact: de indringer blijft zo lang hij wil. Meestal vindt de financiële afdeling hem als eerste, wanneer de maandfactuur verdubbelt. Tegen die tijd is dezelfde sleutel doorgaans al geprobeerd op de accounts die we wél bewaken. Een omgeving die we niet loggen, is een omgeving waarover we niets kunnen zeggen tegen een toezichthouder, verzekeraar of klant — niet eens “we hebben gekeken en er is niets gebeurd”.
Inside a region with no logging at all, AI gives an attacker almost nothing extra to exploit, because there is no monitoring to evade in the first place. The advantage here was already total before any AI tool entered the picture.Binnen een regio zonder enige logging biedt AI een aanvaller bijna niets extra om te benutten, omdat er sowieso niets te omzeilen valt. Het voordeel was hier al volledig, ver voordat er een AI-tool aan te pas kwam.
An employee with legitimate cloud access can use an AI-written automation script to spin up resources in a forgotten region nobody watches, turning routine self-service convenience into a hiding place that looks like ordinary infrastructure work to anyone glancing at logs.Een medewerker met legitieme cloudtoegang kan een door AI geschreven automatiseringsscript gebruiken om resources op te zetten in een vergeten regio die niemand bewaakt, waardoor gewoon zelfbedieningsgemak een schuilplaats wordt die op gewoon infrastructuurwerk lijkt.
Anomaly detection on billing and account inventories can surface a region nobody is watching far faster than a manual sweep across every account. Someone still has to switch on logging for that region and act on the alert before it becomes a discovery by invoice.Anomaliedetectie op facturen en accountoverzichten kan een regio die niemand bewaakt veel sneller aan het licht brengen dan een handmatige controle van elk account. Iemand moet nog steeds logging voor die regio aanzetten en op het alarm reageren voordat de factuur het ontdekt.
| Control | Prevents | In one line |
|---|---|---|
| Landing zone | All four | Every new account is created from one template with logging, guardrails and ownership already in place. No account exists outside it. |
| Policy-as-code | Open (01) | A rule at organisation level that makes public storage impossible to save, not merely discouraged. Exceptions are explicit and time-limited. |
| No static keys | Leaked key (02) | Where possible, no static keys at all: workload identity federation (OIDC for pipelines, IAM roles, managed identities). Remaining secrets live in a vault, expire in hours and rotate automatically. On AWS, require IMDSv2. |
| Repository scanning | Leaked key (02) | Every commit is checked for anything that looks like a credential before it is accepted. A leaked key is revoked within minutes, automatically. |
| Least privilege | One role (03) | Each workload gets a role that can do only its own job in its own account. Organisation-wide administration is a break-glass procedure, logged and alerted. |
| Posture scanning | 01 · 03 | A continuous check of every setting against a baseline, with a dashboard the board can actually read: how many public buckets, how many admin roles, trend over time. |
| Central logging | Unwatched (04) | Every account and every region sends its logs to one place we cannot switch off from inside that account. A rule at organisation level denies the regions we do not use; alerts fire on new admin roles. |
| Cost alerts | Unwatched (04) | A spend anomaly is often the first sign of an intruder. Finance and security receive the same alert on the same day. |
| Shared responsibility | All four | Written down, per service: what the provider secures and what is ours. Reviewed when we adopt a new service, not after an incident. |
| Maatregel | Voorkomt | In één zin |
|---|---|---|
| Landingszone | Alle vier | Elk nieuw account ontstaat uit één sjabloon met logging, vangrails en eigenaarschap al ingericht. Buiten dat sjabloon bestaat geen account. |
| Beleid als code | Open (01) | Een regel op organisatieniveau die publieke opslag onmogelijk maakt om op te slaan, niet slechts ontmoedigt. Uitzonderingen zijn expliciet en tijdelijk. |
| Geen vaste sleutels | Gelekte sleutel (02) | Waar mogelijk helemaal geen vaste sleutels: workload identity federation (OIDC voor pijplijnen, IAM-rollen, managed identities). Overige geheimen staan in een kluis, verlopen na uren en roteren automatisch. Vereis bij AWS IMDSv2. |
| Repositoryscanning | Gelekte sleutel (02) | Elke commit wordt gecontroleerd op alles wat op een inloggegeven lijkt vóór hij wordt geaccepteerd. Een gelekte sleutel wordt binnen minuten automatisch ingetrokken. |
| Minimale rechten | Één rol (03) | Elke workload krijgt een rol die alleen het eigen werk in het eigen account kan doen. Organisatiebreed beheer is een noodprocedure, gelogd en gealarmeerd. |
| Configuratiescan | 01 · 03 | Een doorlopende controle van elke instelling tegen een basislijn, met een dashboard dat de directie echt kan lezen: aantal publieke buckets, aantal beheerrollen, trend in de tijd. |
| Centrale logging | Onbewaakt (04) | Elk account en elke regio stuurt zijn logs naar één plek die vanuit dat account niet is uit te zetten. Een regel op organisatieniveau weigert de regio's die we niet gebruiken; alarmen bij nieuwe beheerrollen. |
| Kostenalarmen | Onbewaakt (04) | Een afwijking in de uitgaven is vaak het eerste teken van een indringer. Finance en security krijgen hetzelfde alarm op dezelfde dag. |
| Gedeelde verantwoordelijkheid | Alle vier | Opgeschreven, per dienst: wat de leverancier beveiligt en wat bij ons ligt. Herzien bij elke nieuwe dienst, niet na een incident. |
Every cloud estate has hundreds of settings changed by dozens of people. Scanners test them all, continuously, for free.Elke cloudomgeving heeft honderden instellingen die door tientallen mensen worden gewijzigd. Scanners testen ze allemaal, doorlopend, gratis.
A reportable data breach without an attacker, a runaway cloud bill, or an intruder with months of unobserved access.Een meldplichtig datalek zonder aanvaller, een ontspoorde cloudfactuur, of een indringer met maandenlange onbespiede toegang.
Guardrails make the worst settings impossible to save; logging and cost alerts make the rest visible within a day.Vangrails maken de ergste instellingen onmogelijk op te slaan; logging en kostenalarmen maken de rest binnen een dag zichtbaar.
Executes through the platform team. The board owns the answer to “who can make our data public, and who would notice”.Uitvoering via het platformteam. De directie is eigenaar van het antwoord op “wie kan onze data publiek maken, en wie zou het merken”.
Number of public storage locations today · number of identities with organisation-wide admin rights · % of accounts and regions sending logs centrally · age of the oldest long-lived access key.Aantal publieke opslaglocaties vandaag · aantal identiteiten met organisatiebrede beheerrechten · % accounts en regio's dat centraal logt · leeftijd van de oudste langlevende toegangssleutel.
“A misconfigured cloud setting — public storage, a leaked key, an over-privileged role or an unmonitored account — exposes customer data or hands an intruder control of our cloud estate.”“Een verkeerde cloudinstelling — publieke opslag, een gelekte sleutel, een te ruime rol of een onbewaakt account — legt klantgegevens bloot of geeft een indringer controle over onze cloudomgeving.”
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | Risk management measures including access control, encryption, asset management and supply-chain security. Cloud providers are in scope as a critical sector; you remain responsible for your own configuration. | The provider's compliance covers their half of the shared-responsibility model only. Ask for the written split per service, and for the security features they enable by default. | A public bucket with personal data can count as a significant incident if it meets the thresholds: early warning within 24 hours, notification within 72 hours, final report within one month. Separately, the GDPR requires notifying the AP within 72 hours (Art. 33), and the people affected when the risk is high (Art. 34). |
| DORA | For financial entities: a register of all ICT third-party arrangements, including cloud services, with concentration risk assessed. Critical providers require prescribed contract clauses and exit plans. | The provider's report is one input to your own risk assessment. DORA still expects you to show the supervisor how you configure, monitor and could leave the service. | A major ICT incident: initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware), intermediate report within 72 hours, final report within one month — including root cause, which here is your own setting. |
| SOC 2 | If you issue one: logical access, change management and monitoring controls over your cloud accounts are tested over the period. Public storage and unrotated keys are exactly what auditors sample. | Every major provider publishes a SOC 2. It says nothing about how you use the service — read their complementary user entity controls: that list is your job. | A misconfiguration incident can become an exception in your next report. Customers will ask for a root-cause analysis and evidence that the guardrail now exists. |
| ISAE 3402 | Assurance over outsourced processes relevant to financial reporting. If your financial systems run in the cloud, the provider's report covers infrastructure; the application and its settings are yours to evidence. | Check the sub-service organisations named in the report. Your provider's report may itself rely on the cloud platform's, with the carve-out method — meaning a gap nobody has tested. | Exposed financial data or an intruder with write access to financial systems may affect the opinion on your customers' financial statements. ISAE 3402 creates no duty to notify user auditors: expect a deviation in the next report, and ask for interim disclosure in the contract. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | Risicobeheersmaatregelen waaronder toegangsbeheer, versleuteling, assetbeheer en beveiliging van de toeleveringsketen. Cloudleveranciers vallen als kritieke sector onder de wet; u blijft verantwoordelijk voor uw eigen configuratie. | De compliance van de leverancier dekt alleen zijn helft van het gedeelde-verantwoordelijkheidsmodel. Vraag om de schriftelijke verdeling per dienst, en om de beveiligingsfuncties die standaard aan staan. | Een publieke bucket met persoonsgegevens kan als significant incident gelden als hij de drempels haalt: vroege waarschuwing binnen 24 uur, melding binnen 72 uur, eindrapport binnen een maand. Daarnaast verplicht de AVG een melding bij de AP binnen 72 uur (art. 33), en bij hoog risico het informeren van betrokkenen (art. 34). |
| DORA | Voor financiële instellingen: een register van alle ICT-uitbestedingen, inclusief clouddiensten, met beoordeling van concentratierisico. Kritieke leveranciers vereisen voorgeschreven contractbepalingen en exitplannen. | Het rapport van de leverancier is één input voor uw eigen risicobeoordeling. DORA verwacht nog steeds dat u de toezichthouder laat zien hoe u de dienst configureert, bewaakt en zou kunnen verlaten. | Een ernstig ICT-incident: eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur na kennisname), tussentijds rapport binnen 72 uur, eindrapport binnen een maand — inclusief oorzaak, en die is hier uw eigen instelling. |
| SOC 2 | Als u er zelf een afgeeft: logische toegang, wijzigingsbeheer en monitoring van uw cloudaccounts worden over de periode getest. Publieke opslag en niet-geroteerde sleutels zijn precies wat auditors steekproefsgewijs controleren. | Elke grote leverancier publiceert een SOC 2. Die zegt niets over hoe ú de dienst gebruikt — lees hun complementary user entity controls: die lijst is uw werk. | Een misconfiguratie-incident kan een afwijking worden in uw volgende rapport. Klanten vragen om een oorzaakanalyse en bewijs dat de vangrail er nu is. |
| ISAE 3402 | Zekerheid over uitbestede processen die relevant zijn voor de financiële verslaggeving. Draaien uw financiële systemen in de cloud, dan dekt het rapport van de leverancier de infrastructuur; de applicatie en haar instellingen moet u zelf aantonen. | Controleer welke subserviceorganisaties in het rapport staan. Het rapport van uw leverancier kan zelf leunen op dat van het cloudplatform via de carve-outmethode — een gat dat niemand heeft getest. | Blootgestelde financiële gegevens of een indringer met schrijfrechten op financiële systemen kunnen het oordeel over de jaarrekening van uw klanten raken. ISAE 3402 schept geen plicht om de auditors van klanten te informeren: verwacht een afwijking in het volgende rapport, en vraag in het contract om tussentijdse melding. |
Checked against: GDPR Art. 33–34, NIS2 Art. 23 (2022), Delegated Regulation (EU) 2025/301 (2025), AWS Regions, AWS IMDSv2 and GitHub Actions OIDC documentation (2026) · September 2026.
Gecontroleerd tegen: AVG art. 33–34, NIS2 art. 23 (2022), Gedelegeerde Verordening (EU) 2025/301 (2025), documentatie van AWS-regio, AWS IMDSv2 en GitHub Actions OIDC (2026) · september 2026.