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 is typically found within hours, not months.
Business impact: whatever was in that bucket is now public — customer records, backups, contracts, scanned passports from onboarding. This is a reportable data breach on the day it happened, not the day we noticed. 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 wordt doorgaans binnen uren gevonden, niet binnen maanden.
Bedrijfsimpact: alles wat in die bucket stond is nu openbaar — klantgegevens, back-ups, contracten, gescande paspoorten uit het onboardingproces. Dit is een meldplichtig datalek vanaf de dag dat het gebeurde, niet vanaf de dag dat wij het merkten. Niemand heeft ons aangevallen. We hebben het zelf gepubliceerd.
Every cloud account is operated with 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.
Elk cloudaccount wordt bediend met 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.
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.
A cloud account exists in every region of the world at once, 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 bestaat in elke regio van de wereld tegelijk, 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”.
| 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. |
| Secrets vault | Leaked key (02) | Keys live in a vault, are issued for hours not years, and rotate automatically. Code fetches them; code never contains them. |
| 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. Alerts fire on new regions and 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 we must. 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. |
| Geheimenkluis | Gelekte sleutel (02) | Sleutels leven in een kluis, gelden uren in plaats van jaren en roteren automatisch. Code haalt ze op; code bevat ze nooit. |
| 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. Alarmen bij nieuwe regio's en 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 wij moeten doen. 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 is a significant incident: early warning within 24 hours, notification within 72, final report within a month. Affected customers must be informed. |
| 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. You must still show the supervisor how you configure, monitor and could leave the service. | A major ICT incident triggers notification within hours of classification, an intermediate report within 72 hours and a final report within a 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 becomes 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 must be disclosed to the user auditors, and may affect the opinion on your customers' financial statements. |
| 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 is een significant incident: vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur, eindrapport binnen een maand. Getroffen klanten moeten worden geïnformeerd. |
| 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. U moet de toezichthouder nog steeds laten zien hoe u de dienst configureert, bewaakt en zou kunnen verlaten. | Een ernstig ICT-incident vereist melding binnen enkele uren na classificatie, een tussenrapport binnen 72 uur en een 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 wordt een afwijking 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 moeten aan de auditors van uw klanten worden gemeld en kunnen het oordeel over hun jaarrekening raken. |