Introductie
Hoeveel van jullie hebben het afgelopen jaar een kopie van productie op je laptop gehad? Geen strikvraag. Gewoon nieuwsgierigheid. De kans is groot dat het antwoord niet nul is.
Productiedata is bijzonder handig. Het bevat echte klanten, echte edge cases, echte inconsistenties. Precies de dingen die altijd net ontbreken in een synthetische dataset. En dus kopiëren we. Meestal met de beste bedoelingen en een gezonde dosis gewetensonderdrukking.
Dat is op zich niet verrassend. Het is efficiënt en vaak de snelste manier om een probleem te begrijpen. Ook de natuurkunde kent weinig experimenten zonder meetdata.
Maar dan volgt een reeks vragen:
- Welke data is eigenlijk gevoelig?
- Welke attributen bevatten persoonsgegevens, direct of indirect, of bevatten bedrijfsgevoelige informatie?
- Hoe anonimiseer of bescherm je die data?
- Wat doe je met referenties en afgeleide waarden?
- Hoe weet je dat je niets over het hoofd ziet?
- En als je dit morgen opnieuw moet doen, krijg je dan exact hetzelfde resultaat?
In de praktijk worden deze vragen zelden expliciet gesteld. De focus ligt op het reproduceren van de bug of het afronden van de user story. Niet op het formaliseren van een structurele aanpak voor databeveiliging.
Dan wordt de bescherming van gevoelige data geen feature van het model, maar een handmatige correctie achteraf.
De voorwaarden
Als bescherming van gevoelige data een volwassen ontwerp aspect moet zijn, moet het aan een aantal voorwaarden voldoen:
- Het moet transparant zijn. Keuzes over gevoelige attributen moeten een expliciet en zichtbaar onderdeel zijn van het ontwerp. Niet impliciet verborgen in scripts of in hoofden.
- Het moet voorspelbaar zijn. De beveiligingslogica moet verifieerbaar en reproduceerbaar zijn. Determinisme mag een bewuste ontwerpkeuze zijn, maar dat is geen verplichting. Toeval ook niet.
- Het moet consistent toepasbaar zijn over omgevingen heen. Wat in de ene omgeving wordt uitgevoerd, moet identiek herhaalbaar zijn in een andere.
Als er geen mechanisme is dat deze voorwaarden faciliteert of afdwingt, blijven ze afhankelijk van discipline. En discipline is omgekeerd evenredig aan projectdruk.
Het model
Als discipline geen garantie is, moet de structuur het werk doen. En in een Mendix-applicatie begint die structuur bij het domeinmodel, de formele beschrijving van de werkelijkheid. Entities definiëren wat bestaat. Attributen definiëren welke eigenschappen relevant zijn.
Bescherming van gevoelige data mag niet buiten het model blijven. Het moet er expliciet in vastgelegd worden.
Dit betekent dat er voor elke entity en voor elk attribuut een keuze wordt gemaakt. Wordt de waarde behouden, gewist of vervangen? Geldt dit altijd of alleen onder bepaalde voorwaarden?
Deze keuzes zijn geen technische details, maar beleidskeuzes. Ze bepalen hoe een organisatie omgaat met gevoelige informatie.
Hier ligt het fundamentele voordeel van een model-gedreven aanpak. Door het domeinmodel in runtime te spiegelen met ModelReflection ontstaat er een gestructureerd overzicht van alle entities en attributen. Op basis daarvan maak je voor elk attribuut een keuze voor bescherming. Niet verspreid over scripts, maar centraal en inzichtelijk.
Deze configuratie exporteer je ook naar JSON en pas je toe in andere omgevingen. Zo wordt bescherming niet alleen een technische implementatie, maar een expliciet beleid dat overdraagbaar en bespreekbaar is.
Het resultaat is een verschuiving van IT-oplossing naar bedrijfsinstrument. Stakeholders zien welke keuzes zijn gemaakt: welke data behouden blijft, welke wordt verwijderd, welke wordt gegenereerd.
Deze keuzes vermijden versimpelt het gesprek, maar niets is zo persistent als de werkelijkheid.
De implementatie
De keuzes die in het model zijn vastgelegd, zijn alleen waardevol als ze ook systematisch toegepast worden. Bescherming moet geen losse handeling zijn. Het moet functioneren als mechanisme.
Dit mechanisme is gebouwd rond vijf ontwerpprincipes: scope en schaalbaarheid, expliciete regels, determinisme, gecontroleerde generatie en uniciteit.
We gaan nu even de techniek in. Voor sommige lezers is dit een moment om koffie bij te schenken en bij ons te vervoegen in het volgende hoofdstuk.
1. Scope en schaalbaarheid
De uitvoering start met een optionele XPath-scope per entity. Op basis hiervan wordt eerst het totale volume bepaald via een aggregated count, gevolgd door verwerking in batches. Offset- en batchgrootte-batching voorkomt geheugenpieken en maakt grootschalige refresh van test- of acceptatiedata beheersbaar.
2. Expliciete regels
De configuratie in het model wordt via RuleTypes vertaald naar een uitvoeringsmodel. Voor elk attribuut kies je expliciet een strategie, zoals:
- KEEP
- CLEAR
- FIXED
- HASH
- GENERALIZE
- GENERATE
Elk RuleType correspondeert met een concrete, beheersbare transformatie. Er is geen impliciete “best guess”. Een ontbrekende of ongeldige configuratie resulteert in een expliciete fout in plaats van stille afwijking.
3. Determinisme en reproduceerbaarheid
Determinisme is een bewuste ontwerpoptie. Als een regel deterministisch is, wordt een seed berekend op basis van stabiele input, zoals attribuutnaam en originele waarde, gecombineerd met een salt.
De seed wordt cryptografisch afgeleid via SHA-256 en gereduceerd tot een long. Length prefixing wordt gebruikt om ambiguïteit in samengestelde inputs te vermijden.
Het resultaat is idempotentie: dezelfde input, dezelfde configuratie en dezelfde salt produceren dezelfde uitkomst.
4. Gecontroleerde generatie
Gegenereerde waarden gebruiken een gecontroleerde routing-laag bovenop Datafaker. Zowel native expressions als call-style invocations worden ondersteund, maar altijd binnen guardrails.
Provider- en methodenamen worden gevalideerd, risicovolle methoden geblokkeerd en alleen veilige return- en parametertypes geaccepteerd. Dit voorkomt dat een configuratieveld verandert in een generieke Java-invocation-engine.
5. Uniciteit
Uniciteit wordt niet blindelings afgedwongen. Voor String-achtige attributen wordt een gecontroleerde strategie toegepast om botsingen binnen een batch te vermijden, zonder globale state of externe opslag.
Daarnaast worden bestaande data bucket-based herverdeeld via shuffling, optioneel deterministisch. Dit behoudt de statistische verdeling terwijl individuele waarden niet meer traceerbaar zijn.
De context
Bij MxBlue hebben we bovenstaande aanpak vertaald naar een Mendix-module: DataProtection. De module is geen universele oplossing voor alle vormen van databeveiliging. Dat zou verdacht zijn.
Het is bedoeld voor situaties waarin data buiten productie wordt gebruikt en waar expliciete, model-gedreven keuzes vereist zijn.
De module is vooral geschikt wanneer:
- Productiedata wordt gerefresht naar test- of acceptatieomgevingen
- Realistische maar niet-traceerbare data nodig is voor demo of validatie
- Subsets van data gecontroleerd gedeeld moeten worden met partners
- Pseudonimisering nodig is voor analyse zonder het volledige productieprofiel te behouden
- Organisaties transparantie willen creëren over gemaakte beschermingskeuzes richting business en stakeholders
In deze situaties voegt de module structuur toe waar anders discipline het werk moet doen.
Er zijn ook situaties waarin deze module niet de juiste oplossing is. De module is niet bedoeld wanneer:
- Het doel is om data in productie zelf te beschermen tegen ongeautoriseerde toegang
- Encryptie of toegangscontrole vervangen moet worden
- Juridische interpretatie van regelgeving centraal staat
- Cryptografische anonimisering vereist is
- Toestemmingsbeheer ingericht moet worden
In die gevallen ligt de oplossing elders in de architectuur. De module richt zich op gecontroleerde transformatie van data buiten een productiecontext.
Conclusie
Het probleem dat hier beschreven wordt, is concreet. Productiedata wordt gekopieerd. Gevoelige informatie moet aangepast worden. Zonder een expliciet mechanisme gebeurt dit ad hoc.
De DataProtection-module biedt hiervoor een oplossing. Ze maakt beschermingskeuzes zichtbaar in het model, maakt ze overdraagbaar tussen omgevingen en past ze systematisch toe op data. Dit vervangt een kwetsbare handmatige stap door een reproduceerbaar mechanisme.
Wie productiedata buiten productie gebruikt, heeft een gestructureerde manier nodig om die data aan te passen. Deze module biedt dat.
