Losse sites, één omgeving¶

Meerdere overheidsdiensten die als aparte sites ogen, kunnen op één gedeelde analytics-omgeving zitten. Voor de bezoeker lijken het losse diensten met een eigen naam, een eigen adres en een eigen huisstijl. Onder de motorkap delen ze de infrastructuur die het gedrag meet. Dat is een technische verwevenheid die aan de buitenkant niet te zien is.

Concreet gaat het om een gedeelde tenant in een analytics-platform. In de praktijk herken je dat aan een gedeeld meet-id of een gedeelde container. Een Google Analytics 4-property heeft een meet-id in de vorm G-XXXXXXXX. Een tagmanager-container heeft een id in de vorm GTM-XXXXXXX. Als tien sites in hun paginabron hetzelfde id dragen, dan lopen ze door dezelfde omgeving. Dat is te controleren.

# haal het GA4- of GTM-id uit een reeks sites en vergelijk
for host in dienst-a.nl dienst-b.nl dienst-c.nl; do
  id=$(curl -s "https://$host" | grep -oE 'G-[A-Z0-9]{8,}|GTM-[A-Z0-9]{5,}' | sort -u | tr '
' ' ')
  echo "$host: $id"
done

Komt bij meerdere diensten hetzelfde id terug, dan is de gedeelde omgeving gemeten. Wie het beheer voert en hoe de rechten binnen die omgeving verdeeld zijn, blijft dan nog vermoed, want dat staat niet in de paginabron.

Waarom dat het risico vermenigvuldigt¶

Als tien diensten dezelfde omgeving delen, is één verkeerde instelling meteen een probleem voor alle tien. Een instelling die te veel deelt, een verkeerd doorgezette identifier, een tag die te veel meestuurt: wat op één plek fout gaat, gaat op alle aangesloten sites tegelijk fout. De fout leeft op sectorniveau, niet op siteniveau.

Niemand ziet dat als één risico, omdat het als losse websites oogt en los wordt beheerd. Elke dienst heeft een eigen webredactie, een eigen contract, een eigen indruk dat het over de eigen site gaat. De gedeelde laag eronder heeft geen gezicht en geen eigenaar in het dagelijkse beeld. Gedeelde infrastructuur betekent gedeelde fouten, en daarmee een schaal die niemand overziet vanuit één dienst.

Dat is de asymmetrie die het gevaarlijk maakt. Het risico is gecentraliseerd, het beheer is verspreid. Eén configuratie raakt velen, terwijl niemand zich verantwoordelijk voelt voor het geheel. Dezelfde asymmetrie maakt de fout ook lastig te melden. Een bezoeker die iets opmerkt, klopt aan bij de dienst die hij bezocht. Die dienst kan wijzen naar de gedeelde omgeving, die geen eigen loket heeft in het beeld van de bezoeker. Zo kan een fout die iedereen raakt toch bij niemand op het bordje belanden, simpelweg omdat de laag waar hij zit geen zichtbare eigenaar heeft.

Hoe één instelling over de reeks uitwaaiert¶

Een voorbeeld maakt de schaal concreet. Stel dat in de gedeelde omgeving de instelling voor het inkorten van IP-adressen uit staat. Op één site zou dat betekenen dat bezoekers-IP's volledig worden doorgegeven aan de analytics-partij. Bij een gedeelde tenant geldt die ene instelling voor elke aangesloten dienst tegelijk. Tien diensten lekken dan hetzelfde, om dezelfde reden, zonder dat één webredactie iets fout deed op de eigen site.

Hetzelfde geldt voor dataretentie, voor het meesturen van paginapaden die gevoelige parameters bevatten, en voor het delen van gegevens met andere producten van de aanbieder. Elk van die knoppen zit op omgevingsniveau. Zet iemand er één verkeerd, dan is de fout meteen sectorbreed. Dat de fout op alle sites tegelijk optreedt is dan afgeleid uit het gedeelde id, want dezelfde omgeving voert dezelfde instelling uit. Wat elke site precies doorstuurt blijft per site meetbaar, en daar controleer ik de afgeleide tegen de werkelijkheid.

De tagmanager als open deur¶

Naast de gedeelde omgeving zag ik een terugkerend beeld: weiger-knoppen die niet echt weigeren, en tagmanagers die overal aanwezig zijn. Die twee versterken elkaar.

Een tagmanager is een laag waarmee je scripts kunt plaatsen zonder de site zelf te wijzigen. Dat is het hele doel ervan. Op elke aangesloten site kan de tagmanager nieuwe scripts binnenlaten, en de dienst zelf hoeft daar niets voor te doen. Bij een gedeelde container geldt dat voor alle aangesloten sites tegelijk. Wie de container beheert, kan in één handeling een script uitrollen over de hele reeks. Dat maakt de fout breed en moeilijk te overzien, en het maakt een verkeerde toevoeging even besmettelijk als een verkeerde instelling.

De weiger-knop die niet weigert maakt het compleet. Als de toestemmingsvraag geen echte werking heeft, dan vuren de gedeelde tags ongeacht wat de bezoeker kiest. De fout is dan niet alleen breed, maar ook niet af te wenden door de bezoeker.

Wat de AVG hiervan zegt¶

Bij een gedeelde omgeving is de vraag wie de verwerkingsverantwoordelijke is. De AVG kent in artikel 26 de figuur van de gezamenlijke verwerkingsverantwoordelijken. Wanneer twee of meer partijen samen doel en middelen van een verwerking bepalen, zijn ze gezamenlijk verantwoordelijk en moeten ze in een regeling vastleggen wie waarvoor opdraait. Een gedeelde analytics-tenant waarin diensten samen dezelfde meet-infrastructuur inrichten, komt dicht bij die situatie.

Dat is een juridische gevolgtrekking, geen meting, en de precieze kwalificatie hangt af van hoe de omgeving is opgezet. Er speelt nog een tweede punt. De analytics-aanbieder is doorgaans een verwerker onder artikel 28, die alleen op instructie van de verantwoordelijke mag handelen. Bij een gedeelde tenant is de vraag wiens instructie leidend is als tien diensten dezelfde verwerker delen. Zonder heldere afspraken kan de aanbieder de facto zelf de instellingen bepalen, en dan verschuift de zeggenschap stil naar de partij die de omgeving beheert. Dat is precies het soort onduidelijkheid dat de AVG met de artikelen 26 en 28 wil voorkomen. Het punt dat overeind blijft is dit: gedeelde verwerking vraagt om een duidelijke rolverdeling en om afspraken over instellingen en beveiliging onder artikel 32. Als niemand die rol expliciet draagt, ontstaat precies het gat waarin één fout zich ongehinderd over de hele sector verspreidt. Een register van datastromen dat dit inzichtelijk maakt, hoort daarom bij zulke opzetten, zie Een register van wat de overheid uitstuurt hoort particulier te zijn.

Wat dit voor mijn werk betekent¶

Ik beoordeel gedeelde overheidsdiensten niet meer één voor één alsof ze los staan. Zodra ik hetzelfde meet-id of dezelfde container over meerdere diensten meet, behandel ik het als één risico met een sectorbrede reikwijdte. Een fout die ik op één site vind, noteer ik met de vraag: staat dit id ook elders, en telt de fout dan mee voor de hele reeks.

Dat verandert de weging. Een verkeerde instelling op een gedeelde tenant is zwaarder dan dezelfde instelling op een losse site, want de reikwijdte is groter en niemand overziet het geheel. Het risico zit in de optelsom van wat gedeeld wordt, zie Het risico zit in de optelsom, niet in het losse veld. En de meetlat die ik hier aanleg is dezelfde die ik voor commerciële partijen gebruik, zie Dezelfde meetlat voor de overheid en de app in je broekzak. Een overheid die infrastructuur deelt, deelt ook de fouten, en dat verdient een toets op het niveau van de hele sector.

Zie ook Een register van wat de overheid uitstuurt hoort particulier te zijn, Het risico zit in de optelsom, niet in het losse veld en Dezelfde meetlat voor de overheid en de app in je broekzak.