Ontwerpen tegen de monocultuur: een event-driven runtime
Eén slechte update liet ooit 8,5 miljoen machines in één middag crashen. De bug was te overleven. De architectuur niet. Zo wordt gebouwd zodat het niet kan gebeuren.
Onderdeel van de pijlerreeks Soevereiniteit die te operationaliseren is.
In de begeleidende post is betoogd dat gewone gereedschappen stilletjes kritieke infrastructuur worden. Dit is het vervolg voor de ingenieur: gegeven dat die concentratie bestaat, hoe wordt een platform gebouwd dat één foutieve wijziging niet continentbreed kan platleggen?
Het antwoord is ouder dan de cloud. In 2003 beschreven beveiligingsonderzoekers Dan Geer en Bruce Schneier softwarematige monocultuur: wanneer miljoenen systemen één codebase delen, geldt "what one machine has, so has every other", wat de ene machine heeft, heeft elke andere ook. Eén enkel defect wordt dan een gebeurtenis op populatieniveau (Schneier, 2003). Eenentwintig jaar later werd die stelling op schaal bewezen.
Anatomie van een continentbrede storing
Op 19 juli 2024 duwde een beveiligingsleverancier een content-update uit die ongeveer 8,5 miljoen machines in een bootlus liet crashen. De gepubliceerde hoofdoorzakenanalyse is een precieze anatomie van hoe een kleine bug een mondiale wordt (CrowdStrike RCA, 2024):
- Een configuratiesjabloon definieerde 21 invoervelden, maar de sensorcode leverde er slechts 20.
- Een content-update verwees naar dat niet-bestaande 21e veld en veroorzaakte een out-of-bounds read in code die in kernelmodus draait, een onherstelbare crash.
- De validator die het foute bestand had moeten tegenhouden, bevatte een logicafout en liet het door.
- En het beslissende deel: waar de code van de leverancier via een gefaseerde uitrol werd geleverd, ging de content-update in één keer naar de hele vloot, zonder canary en zonder dat de klant de timing kon bepalen.
Drie ingrediënten moesten samenvallen: homogeniteit (iedereen draait hetzelfde), een uitvoeringspositie met hoge rechten (kernelcode kan de host laten crashen), en een snel, ongefaseerd updatekanaal. Neem er één weg en de impactstraal stort in.
De overdraagbare regel schrijft zichzelf: als een wijziging de host onbruikbaar kan maken, gaat ze in ringen de deur uit, of het nu code, content, configuratie of data heet.
Wat is impactstraal, en hoe wordt die kleiner?
Impactstraal is de maximale schade die één storing kan aanrichten. Weerbare systemen zijn zo ontworpen dat dat getal een fractie van het geheel is, nooit "alles en iedereen". Een handvol goed begrepen patronen doet dat werk:
| Patroon | Wat het isoleert | Hoe het de impactstraal beperkt |
|---|---|---|
| Cellen (cellulaire architectuur) | Onafhankelijke replica's van de stack, elk voor een deel van de gebruikers | Een storing raakt circa 1/N van de gebruikers; uitrol gaat cel voor cel |
| Schotten (bulkheads) | Resourcepools per tenant of afhankelijkheid | Een overstroming in het ene compartiment kan de andere niet leegtrekken |
| Shuffle sharding | Combinatorische virtuele shards | Een giftige invoer raakt één shard; vrijwel elke klant krijgt een unieke combinatie |
| Zone- en regio-isolatie | Geografische storingsdomeinen | Een fout in de ene zone plant zich niet voort |
| Splitsing control plane / data plane | Wijzigingsmachinerie versus stabiele dienstverlening | Het data plane blijft draaien, ook als het control plane hapert |
Patronen ontleend aan gevestigde praktijk in de sector (bijv. de AWS Builders' Library).
Het onderliggende beginsel is bij alle hetzelfde: bouw grenzen in zodat een storing wordt ingedamd. Zoals Colm MacCárthaigh van AWS het formuleert: zonder isolatie is "the scope of impact for this kind of failure is 'everything and everyone'", voor dit soort storingen is de reikwijdte van de schade "alles en iedereen" (Amazon Builders' Library).
Event-driven weerbaarheid: falen als lokale, opvangbare gebeurtenis
Patronen zijn noodzakelijk; een runtime die falen opvangt is wat ze dagelijks laat werken. Een event-driven ontwerp, componenten die via een berichtenbus communiceren in plaats van elkaar rechtstreeks aan te roepen, maakt van een fout iets lokaals en herstelbaars in plaats van een gesynchroniseerde crash.
De dragende eigenschappen:
- Ontkoppeling. Een trage of gevallen consumer blokkeert de producer nooit; de bus houdt het bericht vast.
- Stateless workers. De toestand leeft in de bus en in het bronsysteem, dus elke worker kan elke taak oppakken en een gevallen worker wordt vervangen zonder dataverlies.
- Idempotentie plus herpogingen met backoff en jitter. Dubbele verwerking is onschadelijk en herpogingen veroorzaken geen stormloop.
- Dead-letter queues. Eén slecht bericht wordt in quarantaine gezet voor inspectie in plaats van de pijplijn te vergiftigen.
- Zelfherstellende reconciliatie. Het systeem convergeert doorlopend naar de gewenste toestand, herstel is normaal gedrag, geen heldhaftige handmatige gebeurtenis.
Uitrolveiligheid: een deploy is een gebeurtenis, geen redeploy
De les van CrowdStrike ging uiteindelijk over levering, niet over C++. Behandel elke wijziging, configuratie en content inbegrepen, als een afzonderlijke, waarneembare, omkeerbare gebeurtenis:
- Progressieve uitrol of ringuitrol. Stel een wijziging eerst bloot aan een kleine populatie; breid alleen uit als de gezondheidsmetrieken standhouden.
- Geautomatiseerde rollback. Detecteer afwijkingen en keer terug naar een bekend goede versie zonder op een mens te wachten, op vlootschaal zijn mensen te traag.
- Configuratie-als-data, gevalideerd. Configuratie krijgt een schema, een validator die zelf getest is, en dezelfde gefaseerde uitrol als code.
- Updateringen onder regie van de klant. Laat exploitanten updates pauzeren of faseren, een beginsel dat de Cyberweerbaarheidsverordening (CRA) nu bekrachtigt met haar recht om automatische updates te weigeren.
Ook toezichthouders hebben dit ingehaald. DORA, de NIS2-richtlijn en de CRA behandelen concentratie bij één leverancier en ongecontroleerde automatische updatekanalen inmiddels als systeemrisico's die beheerst moeten worden, niet als stijlvoorkeuren (Kroll, 2024). CISA-directeur Jen Easterly noemde de storing van 2024 "a useful exercise, like a dress rehearsal for what China may want to do to us", een nuttige oefening, een generale repetitie voor wat China ons volgens Easterly zou willen aandoen (Cybersecurity Dive, 8 augustus 2024).
Hoe de Soveryne Cloud Foundation is gebouwd voor de slechte dag
De Soveryne Cloud Foundation is op deze beginselen gebouwd, omdat weerbaarheid, net als soevereiniteit, een eigenschap van de architectuur moet zijn en niet een regel in een SLA.
De foundation is event-driven by design: componenten communiceren via een berichtgeadresseerde bus, rekenkracht is stateless en herbouwbaar, en werk dat faalt wordt opnieuw geprobeerd, in quarantaine gezet of gereconcilieerd in plaats van te mogen cascaderen. Ze draait op geografisch verspreide rekenclusters door de EU, geen enkele locatie en geen enkele aanbieder die alles kan meesleuren, en behandelt elke wijziging als een gefaseerde, omkeerbare gebeurtenis in plaats van een vlootbrede omschakeling. Het herladen van configuratie is een eersteklas, waarneembare handeling, geen redeploy.
Diezelfde foundation is de reden dat, wanneer er wél iets misgaat, de impactstraal een ingedamde gebeurtenis is in plaats van een continentbrede storing. En omdat operationele weerbaarheid tegenwoordig iets is dat aangetoond moet worden en niet alleen beweerd, maakt Command het mogelijk die beheersmaatregelen in kaart te brengen en doorlopend te valideren zoals DORA en de NIS2-richtlijn verwachten.
Veelgestelde vragen
Wat is softwaremonocultuur? Wanneer een grote populatie systemen dezelfde software draait, waardoor ze dezelfde kwetsbaarheden en faalvormen delen. Eén defect of één slechte update kan dan de hele populatie in één keer treffen, het digitale equivalent van een gewasmonocultuur die door één ziekteverwekker wordt weggevaagd.
Hoe maakte monocultuur de storing van 2024 erger? Miljoenen machines draaiden een identieke agent in een positie met hoge rechten en ontvingen dezelfde update tegelijk, waardoor één defect bestand een perfect gecorreleerde, mondiale storing opleverde.
Wat is impactstraal, en hoe wordt die verkleind? Impactstraal is de maximale schade van één storing. Die wordt verkleind met isolatiegrenzen, cellen, schotten, shuffle sharding, zone-isolatie, en met gefaseerde uitrol, zodat een storing beperkt blijft tot een fractie van het systeem.
Wat is een celgebaseerde architectuur? Een ontwerp dat meerdere onafhankelijke replica's ("cellen") van de volledige stack draait, elk voor een deel van de gebruikers, zonder gedeeld lot, zodat een storing of een slechte uitrol maar één cel raakt.
Een slechte wijziging is onvermijdelijk; een continentbrede storing is een ontwerpkeuze. Bekijk de event-driven, EU-soevereine foundation die we bouwden om haar in te dammen, ontdek de Soveryne Cloud Foundation, of lees de begeleidende post over waarom concentratie inmiddels een systeemrisico is.
Bronnen
- Geer, Schneier e.a., CyberInsecurity: The Cost of Monopoly (2003), https://www.schneier.com/essays/archives/2003/09/cyberinsecurity_the.html
- CrowdStrike, External Technical Root Cause Analysis, Channel File 291 (2024), https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf
- CISA, Widespread IT outage due to CrowdStrike update (2024), https://www.cisa.gov/news-events/alerts/2024/07/19/widespread-it-outage-due-crowdstrike-update
- AWS Builders' Library, Workload isolation using shuffle-sharding, https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/
- The Reactive Manifesto, https://www.reactivemanifesto.org/
- Kroll, CrowdStrike incident and systemic cyber risk under EU regulations (2024), https://www.kroll.com/en/publications/cyber/crowdstrike-incident-systemic-cyber-risk-eu-regulations
"Versleuteld in rust" is de meest geruststellende zinsnede in de zakelijke IT, en een van de minst informatieve. De vraag die de blootstelling werkelijk bepaalt, is eenvoudiger en lastiger: wie heeft de sleutels, en wie kan gedwongen worden ze te gebruiken?
Lees het volgende deel
Niemand besluit om van een SaaS-tool een dragende balk van de economie te maken. Het gebeurt gewoon, de ene gemakkelijke keuze na de andere.
Lees het bijbehorende artikel
