De risico’s van data-caching bij CRM-integraties

Bij Red Cactus ontwerpen we onze CRM-integraties volgens het security-by-design-principe: vanaf de basis veilig, privacyvriendelijk en toekomstbestendig. Ons uitgangspunt bij het ontwikkelen van CRM-integraties is om geen technieken te gebruiken waarbij kopieën van persoonsgegevens worden opgeslagen (zoals periodieke datasynchronisaties), maar om integraties te ontwikkelen die primair gebaseerd zijn op realtime communicatie via API’s met het CRM (federated queries). 

Ons vorige artikel over het herkennen van AVG-proof CRM-integraties heeft behoorlijk wat stof doen opwaaien. Een aantal lezers gaven aan dat ze zich niet bewust waren van de risico’s van bepaalde technieken en vroegen hoe dat zit bij CRM-integraties die gebruikmaken van data-caching. In dit artikel gaan we daar dieper op in en leggen we uit waarom het data-cachen van persoonsgegevens niet alleen onnodig is, maar ook iets is dat je moet willen voorkomen.

Wat data-cachen inhoudt

Data-cachen betekent dat je gegevens tijdelijk opslaat, bijvoorbeeld om ze sneller beschikbaar te maken. Bij een inkomend telefoontje kan zo’n cache direct naam, e-mailadres en telefoonnummer tonen zonder live verbinding met het CRM te maken. Technisch kan dat handig lijken, maar juist bij persoonsgegevens kleven er grote nadelen aan.

Wat is het verschil tussen data-caching en periodieke datasynchronisaties

Data-caching slaat dus gegevens "tijdelijk" op buiten het CRM, terwijl bij periodieke data­synchronisatie gegevens op vaste momenten (bijvoorbeeld elk uur of dagelijks) uit het bronsysteem gehaald worden en buiten het CRM- wordt opgeslagen. Meestal worden deze gesynchroniseerde gegevens daarna óók in een cache geplaatst voor snelle verwerking. Hoewel de technieken verschillend zijn, hebben ze één belangrijke overeenkomst: in beide gevallen ontstaat er een kopie van persoonsgegevens buiten het bronsysteem wat problematisch is. 

De vijf grootste valkuilen van data-caching en periodieke synchronisatie

Het uitgangspunt van CRM-integratie­ontwikkelaars die kiezen voor de techniek van caching of periodieke synchronisatie is technisch problematisch en staat bovendien haaks op de geest van de AVG-kernbeginselen, zoals we in ons vorige artikel al hebben toegelicht. Hieronder zetten we de 5 belangrijkste nadelen, zowel technisch als in het kader van de AVG, op een rij:

1. Verouderde gegevens – Bij caching of periodieke synchronisatie worden wijzigingen in adressen, namen of privacy-instellingen pas verwerkt bij de volgende synchronisatie. Tot die tijd werkt de integratie met oude informatie, wat kan leiden tot fouten in weergave en dus communicatie. Omdat de AVG vereist dat persoonsgegevens juist en actueel zijn (artikel 5, lid 1, onder d), kan dit bovendien in strijd zijn met het beginsel van juistheid en toestemming.

2. Extra kopieën van persoonsgegevens – Elke extra opslaglocatie vergroot het risico op datalekken en maakt het "recht om vergeten te worden" (artikel 17) complex en foutgevoelig. De eigenaar van de data verliest bovendien grip en weet vaak niet waar de gegevens precies staan. Ook druist dit in tegen het AVG-beginsel van dataminimalisatie: als er technieken bestaan waarbij je geen persoonsgegevens hoeft op te slaan, moet je die gebruiken.

3. Autorisatieproblemen – Bij caching of periodieke synchronisatie worden toegangsrechten alleen gecontroleerd op het moment van synchronisatie. Rechten en rollen die in het CRM zijn ingesteld, worden volledig genegeerd voor alle accounts waarmee niet gesynchroniseerd wordt. Daardoor kunnen ongeautoriseerde gebruikers alsnog gegevens zien die zij niet mogen inzien. Omdat autorisatie niet per realtime request wordt bepaald, kan iemand die later rechten verliest toch toegang houden tot gevoelige informatie. Met een realtime aanpak via federated queries wordt dit voorkomen én ontstaat er een transparante audittrail, waarbij elke view herleidbaar is.

4. Functionele beperkingen – Omdat caching altijd een momentopname is, werken functionaliteiten die actuele CRM-data vereisen minder betrouwbaar. De beschikbare gegevens zijn bovendien beperkt, omdat je meestal niet je volledige CRM wilt synchroniseren. Technische logica of integraties die afhankelijk zijn van realtime data, zoals directe validaties of workflow-triggers, functioneren niet goed op verouderde kopieën. Met realtime opvragen via API’s heb je deze nadelen niet en kun je alle benodigde, actuele velden (inclusief zelf aangemaakte velden) uit je CRM direct gebruiken.
   
   

5. Impact bij datalek – Wanneer alle klantgegevens centraal in één omgeving worden opgeslagen, kan een beveiligingsincident gevolgen hebben voor alle klanten tegelijk. Je mag er van uitgaan dat data per klant logisch wordt gescheiden via database-tabellen en tokens, maar uiteindelijk bevindt alles zich fysiek binnen dezelfde infrastructuur. Dit maakt het aanvalsoppervlak groter en verhoogt het risico dat een incident meerdere klanten treft. In multi-tenant omgevingen kan bovendien kruisinzage ontstaan, waarbij gegevens van verschillende klanten per ongeluk toegankelijk worden voor onbevoegden. In het geval van een datalek, met alle directe en indirecte schade als gevolg, komt onvermijdelijk de vraag op wie verantwoordelijk is: de eindklant, de telecompartner of de CRM-integratieontwikkelaar. Dat kan leiden tot een langdurige juridische strijd. Bij realtime API-koppelingen beperk je dit risico significant doordat persoonsgegevens niet centraal worden opgeslagen.

Waarom federated queries de enige juiste keuze zijn voor CRM-integraties

De oplossing is het gebruik van federated queries, wat het standaard uitgangspunt is van Red Cactus bij het ontwikkelen van CRM-integraties. Dit betekent dat we niet uitgaan van het cachen van persoonsgegevens of periodieke synchronisatie. Persoonsgegevens blijven daarmee in het bronsysteem en worden uitsluitend realtime opgehaald wanneer dat nodig is. Komt er een telefoongesprek binnen, dan doen wij op dat moment een beveiligde, realtime API-call naar het CRM. Zo wordt de data direct opgehaald en gevalideerd, zonder de technische beperkingen van caching of periodieke synchronisatie. Bovendien voldoen deze CRM-integraties hiermee aan de kernbeginselen van de AVG.

Maar data-cachen heeft toch ook voordelen?

Data-caching bij CRM-integraties is vrijwel nooit nodig en bovendien onwenselijk. Een veelgebruikt argument om het toch te gebruiken is snelheid, maar dat is in de praktijk een unicum: het komt alleen voor bij CRM-softwareapplicaties met een technisch beperkte infrastructuur of sterk verouderde technologie. In zo’n situatie is het verstandiger om de leverancier aan te sporen de prestaties te verbeteren. 

Als data-cachen onvermijdelijk is, doe het dan zo

In een aantal unieke situaties ontkom je er technisch niet aan om iets te cachen. Dat geldt met name voor CRM-systemen waar we geen klantgegevens kunnen opvragen via de API op basis van het telefoonnummer van de beller. Moet je in zo’n geval toch data-cachen, doe het dan zoals wij het doen: cache geen persoonsgegevens, maar alleen klantnummers gekoppeld aan telefoonnummers. Bij een inkomend gesprek kun je dan via het klantnummer een realtime API-call doen om de actuele gegevens op te halen. Zo blijft de performance hoog, worden autorisaties altijd op het moment zelf gecontroleerd en blijf je volledig binnen de kaders van de AVG. 

Hoe zit het met deze uitzondering?

In de beginjaren van Red Cactus was er in de markt aanzienlijk minder aandacht voor de verwerking van persoonsgegevens dan vandaag de dag. Naarmate privacybescherming in de loop der jaren steeds meer een hot topic werd, hebben wij alle CRM-integraties die technisch verbeterd konden worden herschreven naar een toekomstbestendige aanpak op basis van federated queries. Van de 200+ CRM-integraties is er nog slechts één uit de beginperiode die persoonsgegevens cacht, uitsluitend in de persoonlijke storage folder van de gebruiker en dus niet centraal op een interne of externe server. Hoewel we dit type integratie nu niet meer zouden opnemen in ons portfolio, blijft deze bestaan omdat een alternatief technisch niet mogelijk is. Zodra het CRM zelf een technische wijziging doorvoert waardoor een privacyvriendelijkere oplossing beschikbaar komt, passen wij de integratie direct aan. Tot die tijd werkt deze integratie op deze manier en vermelden we in de technische handleiding duidelijk hoe zij functioneert, zodat klanten precies weten wat data-caching inhoudt.

Samen naar veiligere en betere CRM-integraties

Onze missie is een standaard neer te zetten die de kwaliteit van CRM-integraties in de hele markt verhoogt. Door hier actief over te schrijven, vergroten we het bewustzijn en stimuleren we andere ontwikkelaars om ons voorbeeld te volgen. Tegelijk laten we zien dat Red Cactus-partners hiermee nu al een duidelijk concurrentievoordeel hebben in commerciële trajecten.