Soevereiniteit als ontwerpdiscipline: onder de motorkap van Office EU

De term soevereine cloud raakt snel ingeburgerd, maar betekent niet overal hetzelfde. Office EU koos ervoor om soevereiniteit niet als marketinglabel te behandelen, maar als technische richtlijn: van de eigenaar van de hoster tot aan wie de TLS certificaten ondertekent. Een blik op de architectuurkeuzes achter het platform.

Als je aan leveranciers vraagt wat een soevereine cloud precies is, krijg je mogelijk evenveel antwoorden als dat er aanbieders zijn. De zaak rond DigiD en hostingpartij Solvinity maakte duidelijk waarom dat een probleem is: soevereiniteit bleek geen eigenschap van één dienst, maar iets dat per laag bij een andere partij kan liggen.

Toen een Amerikaanse overname van Solvinity dreigde, ontdekte de overheid dat de vlag op een datacenter weinig zegt over wie er uiteindelijk aan de touwtjes trekt.

Het is daarom verhelderend om soevereiniteit op te splitsen in vier lagen. De eerste is de functionele laag, oftewel governance: wie bepaalt wat de dienst doet, hoe de logica werkt en wat er met de data gebeurt. Bij DigiD bleef die laag keurig bij de Nederlandse beheerorganisatie Logius.

De tweede laag is operationeel: wie draait de infrastructuur dag in dag uit, welke beheerders hebben toegang, wiens personeel kan bij de systemen.

De derde laag is eigendom en jurisdictie: wie is de eigenaar van de operator en welke wetgeving reikt tot die eigenaar, denk aan de CLOUD Act, FISA 702 en EO 12333. Dat zijn drie verschillende Amerikaanse wetten en richtlijnen die Amerikaanse opsporings- en inlichtingendiensten de bevoegdheid geven om data op te vragen of af te tappen bij techbedrijven.

Dat geldt ook voor gegevens die buiten de Verenigde Staten, zoals in Europa, zijn opgeslagen. Dat is dan ook precies de laag die bij de uiteindelijk geblokkeerde overname van Solvinity door Kyndryl omgeklapt zou zijn.

De vierde laag is de data zelf: waar staan de bytes opgeslagen en wie kan toegang afdwingen.

Het grootste deel van de markt beantwoordt alleen die vierde vraag en suggereert daarmee impliciet dat de rest ook geregeld is. Het ontwerp van Office EU richt zich nadrukkelijk ook op de operationele laag en op eigendom en jurisdictie.

De meest fundamentele keuze: het volledige kritieke pad van het platform van Office EU is in Europese handen. De rekencapaciteit draait bij Hetzner, een van de grootste en meest populaire Europese webhosting- en cloudproviders.

De objectopslag ligt bij Impossible Cloud, een moderne, in Europa opererende cloudprovider uit Duitsland die gespecialiseerd is in gedecentraliseerde, enterprise-grade cloudopslag en AI-infrastructuur. Het bedrijf richt zich sterk op datasoevereiniteit, AVG-naleving en kostenefficiëntie.

Het Content Delivery Network (CDN) ligt bij Bunny in Slovenië, dat webpagina’s, afbeeldingen en video’s razendsnel levert aan de bezoekers.

Identiteitsbeheer gebeurt met een zelfgehoste Keycloak, een opensource systeem voor identiteits- en toegangsbeheer dat je zelf installeert en beheert.

Documentbewerking gaat via Collabora en Euro-Office, de officesuite die naar Nextcloud komt, en mail via Stalwart: moderne, opensource e-mail- en samenwerkingsserver die je zelf kunt hosten. De ontwikkeling van Stalwart is deels gefinancierd via NLnet, in het kader van het Next Generation Internet-initiatief van de EU.

In het pad dat een verzoek van een gebruiker naar een dienst aflegt, zit dus geen enkele rechtspersoon van buiten de EU. Daarmee bestaat er geen blootstelling aan extraterritoriale wetgeving via de eigenaar van een operator.

Opvallend detail: zelfs het applicatieplatform is Europees. De Rails-portal en de landingssite draaien op het Franse Scalingo, niet op Heroku of Vercel. Dat is een bewuste keuze, want de standaardreflex van ontwikkelaars (“zet het even op een platform”) is exact de plek waar de eigendomslaag geruisloos kan weglekken. De data staan dan misschien netjes in Europa, maar de partij die de applicatie beheert valt onder een andere jurisdictie.

Achter die keuzes zit een vaste selectieregel voor componenten: elk onderdeel moet opensource zijn (inspecteerbaar, forkbaar, zelf te hosten, en dus te overleven als een leverancier wordt overgenomen) óf afkomstig van een Europese leverancier, zodat het eigendom binnen de EU jurisdictie blijft. Opensource fungeert als een structurele verzekering tegen precies het overnamerisico waar de Solvinity-casus om draaide. Nextcloud, Euro-Office en Stalwart voldoen zelfs aan beide criteria tegelijk.

Bij digitale soevereiniteit kijk je vaak naar de cloud, software en dataopslag. Maar daarbij wordt meestal één cruciale schakel vergeten: de partijen die de TLS-certificaten uitgeven – de digitale bewijzen waarmee websites laten zien dat ze veilig en betrouwbaar zijn.

Vrijwel alle aanbieders die zichzelf soeverein noemen, leunen voor hun certificaten op Let’s Encrypt: een Amerikaanse partij die daarmee het hart van de vertrouwensketen vormt. Begrijpelijk, want Let’s Encrypt is de feitelijke standaard waar elke client, elke library en elke tutorial van uitgaat. Maar het betekent wel dat de jurisdictievraag, die op de opslaglaag zo zorgvuldig dichtgetimmerd is, langs de vertrouwenslaag weer naar binnen komt.

Office EU heeft die afhankelijkheid wél als ontwerpkeuze behandeld. Europese certificaatautoriteiten met ACME-ondersteuning (Automated Certificate Management Environment) zijn in opkomst. Het Office EU-ontwikkelteam heeft het integratiewerk gedaan om daarop over te stappen, want een configuratieschakelaar die je even omzet is het niet: certificaatuitgifte zit verweven in clients, automatisering en tooling die allemaal van de Amerikaanse standaard uitgaan.

Precies daarom laten andere partijen dat liggen: het is werk dat klanten meestal niet zien – totdat het ertoe doet. De afhankelijkheid zit bij de partij die de certificaten ondertekent, volledig los van waar de data staan. De vraag die organisaties aan hun ‘soevereine’ leverancier zouden moeten stellen: wie tekent jouw certificaten? En niet alleen: waar staan jouw bytes?

Het OV-certificaat van Office.eu komt van HARICA (Griekenland), waarbij in het certificaat ook de organisatienaam geverifieerd is (EUfforic Europe B.V.). Het certificaat kan in een Linux terminal ingezien worden met:

Deze opzet biedt, naast Europese soevereiniteit, ook meer zekerheid dan een Let’s Encrypt-certificaat: er heeft niet alleen domeinvalidatie plaatsgevonden, maar ook verificatie van de organisatie zelf

Op de datalaag zelf zijn twee keuzes bepalend. Ten eerste worden de encryptiesleutels voor de objectopslag beheerd door Office EU zelf en niet door de opslagleverancier. Daarmee is de datalaag losgekoppeld van de operator: de partij die de schijven draait, kan de inhoud niet lezen.

Ten tweede de tenant-isolatie. Office EU kiest niet voor een gedeelde database waarin klantdata met een WHERE clausule uit elkaar wordt gehouden, maar voor een eigen instantie per klant. Elke klant krijgt een dedicated Nextcloud-omgeving met een eigen opslagbucket, automatisch uitgerold door een operator binnen het Kubernetes-cluster vanuit een pool van vooraf klaargezette instanties. De scheiding tussen klanten ligt daarmee op de grens van de opslagbucket, niet in applicatielogica.

De stack is bovendien van begin tot eind gebouwd op open protocollen: Stalwart ondersteunt de protocollen JMAP, IMAP, SMTP, CalDAV, CardDAV en WebDAV, en de identiteitscontrole loopt via OIDC met Keycloak. Geen enkel onderdeel kan via een gesloten protocol de rest van de keten gijzelen, elk component is afzonderlijk vervangbaar.

Een vraag waar vrijwel elke zogenaamde AI-functie in de markt omheen loopt is: wiens model draait waar? Een antwoordagent die prompts naar een externe Amerikaanse LLM-API stuurt, zet bovengenoemde lagen drie en vier in één klap weer open – hoe soeverein de rest van de stack ook is. De jurisdictie over de promptdata en het eigendom van het model liggen dan immers weer buiten Europa.

Office EU laat AI niet verwerken door een gesloten buitenlandse dienst, waarbij onduidelijk is wat er precies met klantdata gebeurt. In plaats daarvan werkt Office EU met AI-modellen die in de EU worden gehost en waarvan de belangrijkste onderdelen openbaar en controleerbaar zijn. Zo blijven prompts, documenten en andere klantgegevens binnen de Europese jurisdictie, en is het model geen buitenlandse zwarte doos.

Office EU wil voorkomen dat belangrijke instellingen verspreid raken over losse leveranciersportals, waar iemand met toegang zomaar iets kan aanpassen. Daarom worden configuraties behandeld als softwarecode. Een wijziging wordt eerst voorgesteld, daarna gecontroleerd en pas dan toegepast.

Zelfs bij de facturatie, via het Europese Frisbii, werkt Office EU zo. Omdat Frisbii vooral een dashboard biedt, gebeurt het beheer als YAML als code in Git en wordt met eigen tooling gesynchroniseerd. Een prijswijziging gebeurt dus via gecontroleerde code, niet door snel iets aan te passen in een configuratiescherm.

Dat geldt voor de technische omgeving, voor toegangsrechten, voor wachtwoorden en sleutels, voor klantopslag en zelfs voor facturatie-instellingen. Ontwikkelaars klikken dus niet handmatig instellingen aan in beheeromgevingen, maar ze leggen wijzigingen vast in Git, laten die controleren en laten de systemen daarna automatisch bijwerken.

Ook geheime gegevens, zoals sleutels en wachtwoorden, worden niet ergens los ingevoerd. De ontwikkelomgeving en productieomgeving hebben ieder hun eigen sleutels. Daardoor kan een geheim uit de testomgeving niet zomaar in de productieomgeving worden gebruikt. Er is dan ook geen alles openende hoofdsleutel.

Hetzelfde geldt voor klantdata. Als een klant een eigen opslagruimte krijgt, wordt die automatisch beheerd door het platform. Wordt de klantomgeving verwijderd, dan wordt ook de bijbehorende opslag netjes opgeruimd. Daardoor blijven er geen vergeten databakken of onnodige cloudkosten achter.

Het voordeel van die werkwijze is dat Office EU zijn platform opnieuw kan opbouwen vanuit de bronbestanden. De ontwikkelomgeving en productieomgeving lijken sterk op elkaar en zijn daardoor beter te testen, te migreren en te herstellen. Dat is belangrijk voor digitale soevereiniteit: je wilt niet vastzitten aan één leverancier of één technische omgeving omdat niemand het systeem nog snel kan verplaatsen.

Bij DigiD bleek precies dat probleem zichtbaar toen de rechter in mei oordeelde dat de Staat het contract met Solvinity mocht verlengen omdat het DigiD-beheer niet zonder onaanvaardbare risico’s snel kon worden overgezet.

Office EU-prichter Maarten Roelfs vat het als volgt samen: “Soevereiniteit is voor ons een engineeringdiscipline, geen vinkje op een compliancelijst. De DigiD-zaak bewees dat een vlag op een datacenter niet genoeg is. Daarom hebben we van elke laag, tot aan het certificaat en de eigenaar van de leverancier, een bewuste technische beslissing gemaakt.”