Digitale soevereiniteit, compliance by design en fors lagere kosten
Terwijl Nederland en Europa zich steeds luider afvragen hoe lang we nog afhankelijk kunnen blijven van Amerikaanse cloudreuzen, eisen wetgevingen zoals NIS2 en DORA onomstotelijke data-integriteit en sluitende audit-trails. Toch bouwen we onze kritieke applicaties nog altijd op traditionele relationele of NoSQL-databases. Dit brengt fundamentele risico’s met zich mee: logbestanden zijn niet volledig tamper-proof, en de index-bloat maakt cloud-repatriering bijna onmogelijk. Tijd voor een radicaal andere aanpak.
Blockchain in software is net even een andere ‘ball-game’
Wie aan blockchain denkt, associeert het vaak direct met cryptocurrencies en grote, gedistribueerde open netwerken. In essentie is blockchain echter niets meer dan een krachtige methode voor immutabele en verifieerbare data-opslag. Satoshi Nakamoto koos voor een blockchain-structuur bij Bitcoin omdat hij een protocol nodig had dat zowel extreem veilig was voor gebruik in een volledig openbaar, onbetrouwbaar netwerk als lichtgewicht genoeg om te draaien op duizenden nodes, beheerd door willekeurige particulieren over de hele wereld.
Publieke netwerken zijn weinig geschikt voor bedrijfs- en overheidstoepassingen, maar als data opslagmechanisme heeft de blockchain zich zeker bewezen. Juist wanneer blockchain wordt ingezet als interne datalaag binnen reguliere softwareapplicaties komen de fundamentele eigenschappen van blockchain – immutabiliteit, tamper-evidence en cryptografische integriteit – tot hun recht.
Zo ontstaat een nieuwe, lichtgewicht software-architectuur met een extreem lean en performant data-protocol dat lichtgewicht genoeg is om applicaties weer on-premise te draaien. Binnen de vertrouwde bedrijfscontext zijn validatieprotocollen overbodig, volstaat één leader node in plaats van een netwerk van duizenden nodes en fouten hoeven niet bediscussieerd te worden, maar worden behandeld als gewone softwarebugs tijdens reguliere testcycli.
Compliance by design
Chain Solutions heeft deze architectuur doorontwikkeld tot Chain Engine. Hierin wordt blockchain dataopslag gecombineerd met een in-memory replica die via event-sourcing de actuele applicatiestatus opbouwt.
Historische data aanpassen is in deze architectuur extreem moeilijk. Een manipulator heeft niet alleen diepgaande cryptografische kennis en volledige schrijftoegang tot het systeem nodig. Om de wijziging ook echt effect te laten hebben, moet hij de aanpassingen doen na het laatste cryptografisch beveiligde snapshot. Wijzigingen van vóór dat snapshot hebben namelijk geen invloed meer op de status in de in-memory replica.
Daarnaast moet de manipulator de applicatie herstarten om de gewijzigde events in de replica te effectueren. Tijdens die herstart voeren de recovery- en replicatiemechanismen echter een volledige validatie uit. Om deze mechanismen te laten slagen, moet de manipulator alle opvolgende blocks (van na de snapshot) opnieuw hashen en cryptografisch consistent maken. Dit maakt een succesvolle manipulatie in de praktijk vrijwel onmogelijk. Audits worden met deze data architectuur een formaliteit in plaats van een punt van zorg. De stand-alone auditor binaries dragen hier nog eens extra aan bij.
Standaardisatie als fundament voor snelheid en kostenbesparing
De blockchain-kern van Chain Engine is sterk gestandaardiseerd en gemoduleerd. Daardoor is de applicatie eenvoudig schaalbaar en kunnen ontwikkelteams zich volledig richten op businesslogica, zonder zich eerst bezig te hoeven houden met infrastructuur en database-inrichting.
In combinatie met meegeleverde AI-prompts kunnen flinke besparingen op de ontwikkeltijd worden behaald. Tegelijk dalen de totale eigendomskosten significant door lagere opslag- en licentiekosten, minder operationele complexiteit en sterk gereduceerde compliance- en auditkosten.
Het resultaat: enterprise software die veiliger, beter controleerbaar, wendbaarder én goedkoper is over de gehele levensduur.
Nieuwe strategische keuzes
Het gesprek in bestuurskamers hoeft niet langer te gaan over “Welke cloudprovider kiezen we?” of “Wat is onze optimale multi-cloudstrategie?” De fundamentele vraag wordt: Voelen we ons comfortabel bij het permanent uitbesteden van ons meest gevoelige bezit, onze bedrijfsdata, en de lock-in die daarbij hoort?
De nieuwe generatie software, gebouwd op de beste ideeën uit blockchain maar ontdaan van de complexiteit van publieke netwerken, biedt eindelijk een geloofwaardig, performant en soeverein alternatief. De cloud verdwijnt niet, maar hoeft niet langer de privacy-gevoelige kerngegevens te bevatten.
Meer weten over Chain Engine? Vraag een vrijblijvende demo aan via contact@chainsolutions.io
Ik mis een scherpere afbakening van wat toepassing van blockchain in dit geval precies bewijst. Een cryptografische log kan zeker waardevol zijn voor auditability, replayability, tamper-evidence e.d., maar zolang dezelfde organisatie als enige de keten beheert, bewijst het in de eerste plaats dat de overgelegde keten intern consistent is. Niet dat het ook de oorspronkelijke of volledige keten is.
Daarvoor is verankering buiten het bereik van diezelfde organisatie noodzakelijk, bijvoorbeeld door periodieke checkpoint-hashes bij een notaris, toezichthouder, accountant of andere onafhankelijke partij vast te leggen. Er moet onafhankelijk bewijs zijn dat op een bepaald moment een keten al bestond, en dat diezelfde keten de verifieerbare basis vormt voor een latere aanlevering.
Ook de claim dat blockchain hier een alternatief vormt voor SQL- en NoSQL-databases vraagt volgens mij om nuance. SQL- en NoSQL-systemen leveren meer dan opslag alleen: querymogelijkheden, referentiële integriteit, indexering, rapportagetools, beheer, recovery en een volwassen operationeel ecosysteem. Een hybride model ligt daarom meer voor de hand: conventionele databases voor de productieomgeving, met daarnaast een cryptografisch verifieerbare, periodiek verankerde bewijsketen.
Minder cloud-afhankelijkheid kan bijdragen aan soevereiniteit, maar waarborgt die op zichzelf nog niet. Zeker niet als beheerprocessen, sleutelbeheer, functiescheiding, exitstrategieën en onafhankelijke controle daardoor juist minder scherp worden geregeld.
Daarnaast zit de echte auditproblematiek vaak niet in het ontbreken van cryptografie, maar in de onvermijdelijk rommelige werkelijkheid van organisaties: uitzonderingen, noodgrepen, achterafcorrecties, informele routes en niet zelden ook heimelijke weerstand tegen volledige aantoonbaarheid. Zelfs een sluitende voorraadadministratie blijkt in de praktijk vaak al op weerstand te stuiten. Vaak strandt het zelfs eerder, bij de mensen die ermee moeten werken en het als praktisch onwerkbaar ervaren.
Het gaat wat mij betreft dus niet alleen om cryptografische integriteit, al kan die zeker helpen, maar ook om duidelijke grenzen aan het toepassingsgebied. Voeg daarbij zaken als volledigheidscontrole, waarborging tegen alternatieve administratieve routes en een realistische positionering ten opzichte van SQL/NoSQL.
Rob, bedankt voor uitgebreide reactie. Dat waardeer ik zeer.
Ik ben het op een aantal punten met je eens, maar ik merk ook dat je behoefte hebt aan meer duidelijkheid over hoe we dit precies toepassen. Dus laat ik daarmee beginnen.
Je schrijft: “Een cryptografische log kan zeker waardevol zijn voor auditability, replayability, tamper-evidence e.d., maar zolang dezelfde organisatie als enige de keten beheert, bewijst het in de eerste plaats dat de overgelegde keten intern consistent is. Niet dat het ook de oorspronkelijke of volledige keten is.”
Dat is feitelijk juist, maar waarom zou dit een groter probleem zijn dan bij een traditionele database? Ook daar is de organisatie zelf de enige beheerder. Om deze gecentraliseerde controle te doorbreken bestaan er audits en die blijven natuurlijk gewoon.
Chain Engine gebruikt een interne blockchain-datalaag die de traditionele database vervangt binnen de applicatie. Niets meer, niets minder. Net zoals een bedrijf zijn database niet zo maar weggooit, zal een bedrijf zijn blockchain ledger ook niet weggooien Wat wij willen bereiken is vooral dat bedrijven veel meer intern vertrouwen en controle krijgen over hun eigen historische data. En dat is met een normale database structureel veel lastiger. We starten de chain met een duidelijke genesis en de hele keten is veel makkelijker te auditeren. Daarover verschijnt morgen een uitgebreid vervolgartikel hier op Computable.
Je hebt gelijk dat een hybride model op korte termijn het meest voor de hand ligt, zeker voor analyse doeleinden. Bij Chain Engine houden we de in-memory Replica (de event-sourced actuele applicatiestatus) bewust zo lean mogelijk. Het is goed mogelijk om daarnaast een tweede Replica te voeden, die niet gebruikt wordt in het bedrijfskritische proces, voor zwaardere analytische queries, maar bestaande tooling en dus een hybride oplossing kan hier uitstekend in voorzien. Op middellange termijn verwachten we dat BI- en vooral AI-tools steeds beter overweg kunnen met event streams en daarmee een veel betrouwbaarder beeld geven dan de “huidige status” in een database.
Tot slot herken ik je punt over de menselijke en organisatorische kant heel sterk: uitzonderingen, noodgrepen en informele routes. Juist daar kan event sourcing een groot verschil maken. Het is niet meer mogelijk om “stiekem” iets recht te zetten in de database.
Elke wijziging moet als event vastgelegd worden. En omdat de status altijd uit die events wordt afgeleid, neemt de noodzaak voor dat soort noodgrepen sterk af. Bedrijven krijgen het overzicht en de controle weer terug. We claimen niet dat dit alles oplost, maar het is wel een krachtig instrument om zowel technische als organisatorische integriteitsproblemen aan te pakken.
Mocht je nog vragen hebben, dan staan we altijd open voor een goed gesprek of een demo.
Nogmaals bedankt voor de scherpe input!
Geralde Passchier, Chainsolutions.io
Dank voor je reactie, Geralde. Als het probleem niet groter is dan bij een traditionele database, volgt daar volgens mij niet uit dat de claim groter mag worden dan bij een traditionele database.
Een interne blockchainlaag kan zeker nuttig zijn voor tamper-evidence, replayability en interne controle, maar levert op zichzelf geen doorslaggevende extra auditwaarborg op voor derden. Daarvoor blijven externe checkpoints/digests, onafhankelijke bewaring, sleutelbeheer, functiescheiding en controle op alternatieve routes nodig.
Voor bijvoorbeeld het notariaat zou zo’n periodieke bewijsketen zeker een rol kunnen spelen, mits het bestuur of de toezichthoudende structuur periodieke checkpoints aantoonbaar buiten bereik van de operationele en IT-medewerkers brengt. Maar dan kom je al snel uit bij trusted timestamping, data escrow of onafhankelijke digest storage, dus bij een bredere controlearchitectuur dan alleen de interne chain.
Juist omdat het idee op componentniveau nuttig is, moet je er rekening mee houden dat bestaande databaseplatformen dit snel zullen oppakken voor zover ze dat niet al doen. Microsoft heeft met SQL Server/Azure SQL Ledger bijvoorbeeld al langer tamper-evident ledger tables, database digests en verificatie rond bestaande SQL-functionaliteit. Daar zou ik voor het succes op langere termijn goed naar kijken. Op langere termijn heb je volgens mij een slimme niche nodig.
De echte meerwaarde zal dus waarschijnlijk niet zitten in de algemene stelling “blockchain vervangt SQL/NoSQL”, maar in scherpe toepassing: interne controle, data escrow, volledigheidscontrole, borging tegen bypasses, goede governance en implementatiegemak. Zoals gezegd: ik zou dit niet te snel als databasevervanging positioneren, maar eerder als bewijs- en reconstructielaag naast de operationele omgeving. Je kunt als schilderbedrijfje niet de hele wereld opnieuw verven.
Als routes buiten de keten om mogelijk blijven, registreert de chain niet de hele werkelijkheid maar alleen het deel dat de chain bereikt. De database-transacties zijn daarvan maar één aspect. Bij een audit gaat het ook om imports, correctiescripts, admin-tools, migraties, noodprocedures, exports, spreadsheets en informele processen.
Bij een grap moet je eigenlijk de clou niet vertellen.
Maar lijkt hier toch nodig.
Rob, het is een advertorial, een “partnerartikel”, een “externe bijdrage”.
Dino, Dinosolutions.io