CRM integraties en security: de vragen die je móét stellen

In gesprekken met potentiële partners horen we af en toe dat de oplossingen van verschillende CRM integratieontwikkelaars “ongeveer hetzelfde” zijn. De meeste oplossingen tonen immers een klantkaart, laten je zoeken en registreren, en helpen gebruikers sneller werken.

Toch zijn er grote verschillen in wat gebruikers daadwerkelijk zien en in hoe integraties technisch zijn opgezet. Maar juist de minder zichtbare keuzes, zoals de verwerking van data en de inrichting van security, zijn in de huidige wereld minstens zo belangrijk en mede bepalend voor de risico’s die je loopt.

Onze visie is dat CRM integraties zouden moeten werken op basis van realtime data, zonder opslag of synchronisatie buiten het CRM. Vanuit die visie bouwen wij bij Red Cactus aan een veilige, generieke standaard en schrijven we over onderwerpen als dataverwerking en security, in de hoop dat ook andere CRM integratieontwikkelaars deze standaard gaan volgen.

In eerdere artikelen gingen we al in op het herkennen van AVG proof CRM integraties. In dit artikel introduceren we een top 6 security checklist voor CRM integraties, gericht op de technische en infrastructurele beveiliging. Deze checklist sluit aan op de standaard die wij bij Red Cactus hanteren bij het ontwerpen en ontwikkelen van CRM integraties

Security checklist voor CRM integraties

1. Authenticatie en toegangsbeheer

De manier waarop gebruikers inloggen op een CRM integratie vormt de basis van de beveiliging. Een veilige integratie ondersteunt bij voorkeur single sign on via de bestaande identity provider van de organisatie, zodat centrale security policies automatisch van toepassing zijn. Daarbij moet het mogelijk zijn om op organisatieniveau te bepalen welke identity providers zijn toegestaan. Niet gebruikte identity providers, zoals Microsoft, Google of andere aanbieders, moeten uitgeschakeld kunnen worden. Ook hoort een integratie gebruikers automatisch te blokkeren na een vastgesteld aantal mislukte inlogpogingen.

Wanneer single sign on niet beschikbaar is en een integratie werkt met gebruikersnaam en wachtwoord, moet multifactor authenticatie minimaal verplicht kunnen worden gesteld. Security mag hierbij nooit een individuele gebruikerskeuze zijn, maar moet afdwingbaar zijn op organisatieniveau.

Kan een CRM integratie niet aan deze uitgangspunten voldoen, dan is het terecht om je af te vragen of dit een oplossing is waar je verder mee wilt. Controleer in dat geval in ieder geval dat ongewenste toegang tot een account niet direct leidt tot toegang tot klantdata, bijvoorbeeld doordat gegevens worden gecached of gesynchroniseerd binnen de integratie. Vanuit privacy en AVG perspectief is het essentieel dat een inlogincident niet automatisch resulteert in een datalek.

2. Gebruikerscontext, rollen en permissies

Een CRM integratie zou altijd de rollen en rechten van het CRM moeten respecteren. Gebruikers mogen via de integratie nooit meer data kunnen zien of bewerken dan wat binnen het CRM zelf is toegestaan. De autorisatiestructuur van het CRM moet leidend zijn. Om dit correct af te dwingen, moet een CRM integratie werken in de context van de individuele gebruiker. Dat betekent dat data en acties worden opgehaald namens de ingelogde gebruiker en herleidbaar zijn tot een specifiek account. Dit is essentieel voor controle, auditing en het correct toepassen van toegangsrechten.

Daarbij is het belangrijk dat ook de authenticatie richting het CRM plaatsvindt op basis van individuele gebruikers en niet via één centraal technisch account. Wanneer een integratie met een centraal account verbinding maakt met het CRM, vervalt de koppeling tussen gebruiker en data. In de praktijk betekent dit dat iedereen via de integratie toegang kan krijgen tot dezelfde informatie, ongeacht rol of functie.

Het gebruik van centrale accounts introduceert extra risico’s, zoals gedeelde wachtwoorden, handmatig beheer van toegang en beperkte traceerbaarheid. Ook ontstaat het risico dat toegang blijft bestaan wanneer medewerkers uit dienst gaan. In combinatie met toegang tot klantdata vergroot dit de kans op ongewenste inzage en maakt het incidenten lastiger te onderzoeken.

Kan een CRM integratie deze rollen en gebruikerscontext niet ondersteunen, dan is het belangrijk om kritisch te kijken naar de gevolgen daarvan. Wanneer CRM data uitsluitend realtime beschikbaar wordt gemaakt en niet centraal wordt opgeslagen, blijft de impact van dergelijke beperkingen aanzienlijk beperkter dan bij integraties die data cachen of synchroniseren.

3. Datascheiding en infrastructuur

CRM integraties worden vaak als cloudoplossing aangeboden, maar de onderliggende architectuur verschilt sterk per CRM integratieontwikkelaar. Onze visie is dat data strikt gescheiden moet worden, ook al brengt dit een hogere kostprijs met zich mee, terwijl we in de praktijk regelmatig oplossingen zien met gedeelde infrastructuren waarin data van meerdere klanten binnen dezelfde omgeving wordt verwerkt. Zeker wanneer CRM integraties zijn gebouwd op technieken die gebruikmaken van datacaching of synchronisatie, leidt dit tot een aanzienlijk groter risico.

Wanneer data van meerdere klanten binnen een gedeelde infrastructuur wordt verwerkt, is het belangrijk om stil te staan bij de impact van een incident. Bij integraties die CRM data cachen of synchroniseren, kan een beveiligingslek of misconfiguratie ertoe leiden dat in één keer data van meerdere organisaties toegankelijk wordt. De impact van zo’n incident is daarmee aanzienlijk groter dan bij integraties die geen data opslaan.

Daarom is het belangrijk om verder te kijken dan alleen preventieve beveiligingsmaatregelen. Controleer hoe een CRM integratie is ingericht op het gebied van continuïteit en herstel. Is de infrastructuur redundant uitgevoerd? Hoe zijn backups ingericht, is er sprake van offsite backups en is duidelijk wat de verwachte hersteltijd is bij uitval of een beveiligingsincident?

Een cruciale vraag daarbij is of een aanbieder na een groot incident überhaupt weer volledig up and running kan komen, en binnen welk tijdsbestek. Dit zegt veel over hoe de infrastructuur is opgebouwd en of zaken als redundantie, failover en herstelprocedures daadwerkelijk zijn ingericht.

4. Onafhankelijke beveiligingstests

Security is geen eenmalige inspanning. CRM integraties veranderen continu door nieuwe functionaliteit, updates en afhankelijkheden. Daarom is het belangrijk dat de beveiliging van een integratie periodiek wordt getoetst door onafhankelijke specialisten.

Controleer of een CRM integratie regelmatig wordt onderworpen aan onafhankelijke penetratietests en of de resultaten daarvan worden opgevolgd. Een eenmalige test in het verleden is onvoldoende; structurele herhaling is essentieel om nieuwe kwetsbaarheden tijdig te identificeren.

Daarnaast is transparantie belangrijk. Kan een aanbieder aantonen dat deze tests plaatsvinden en op welk niveau ze worden uitgevoerd? Dit zegt veel over hoe serieus security wordt genomen binnen de organisatie.

Wanneer een CRM integratie geen periodieke, onafhankelijke beveiligingstests laat uitvoeren of hier geen inzicht in kan geven, is het belangrijk om kritisch te kijken naar het risico dat je loopt bij het verwerken van klantdata via die integratie.

5. Logging en monitoring

Een CRM integratie die toegang heeft tot klantdata moet beschikken over adequate logging en monitoring. Het moet inzichtelijk zijn wie wanneer toegang heeft gehad tot de integratie, welke acties zijn uitgevoerd en welke data is geraadpleegd. Logging is niet alleen belangrijk voor security, maar ook voor beheersbaarheid en compliance. Bij een incident moet snel duidelijk kunnen worden wat er is gebeurd en welke impact dit heeft gehad. Zonder goede logging is dat vrijwel onmogelijk.

Daarnaast is monitoring essentieel om afwijkend gedrag tijdig te signaleren. Denk aan ongebruikelijke inlogpogingen, verhoogde foutmeldingen of onverwachte pieken in dataverkeer. Vroegtijdige detectie kan de impact van een incident aanzienlijk beperken.

Kan een CRM integrator geen duidelijkheid geven over welke logs worden vastgelegd, hoe lang deze worden bewaard en hoe monitoring is ingericht, dan is het verstandig om kritisch te kijken naar de mate van controle die je hebt over de verwerking van klantdata.

5. Updates, patchmanagement en releasebeleid

Een CRM integratie is afhankelijk van onderliggende software, frameworks en infrastructuur die continu in ontwikkeling zijn. Kwetsbaarheden ontstaan vaak doordat beveiligingspatches niet of te laat worden doorgevoerd.

Controleer daarom of beveiligingspatches structureel worden uitgevoerd en of dit aantoonbaar is. Het releasebeleid van een aanbieder zegt veel over hoe security is ingericht. Is er sprake van een vaste release cycle? Worden updates gecontroleerd en consistent uitgerold?

Een volwassen CRM integratie kan security updates doorvoeren zonder bestaande koppelingen of klantomgevingen te breken. Wanneer updates leiden tot functionele regressie of handmatige aanpassingen bij klanten, blijft patching in de praktijk vaak liggen en neemt het risico toe.

Tot slot

CRM integraties lijken op het eerste gezicht op elkaar, maar de keuzes rondom security, dataverwerking en infrastructuur maken een groot verschil. Juist omdat CRM integraties diep ingrijpen in de verwerking van klantdata, verdienen ze dezelfde kritische beoordeling als het CRM zelf.

Wat we daarbij nog te vaak zien, is onverschilligheid. Het idee dat risico’s bij een incident wel bij de CRM integrator liggen, terwijl in de praktijk de impact vrijwel altijd breder is. Verantwoordelijkheid laat zich niet eenvoudig doorschuiven en zelfs als dat contractueel mogelijk lijkt, blijft de vraag of een integrator de gevolgen van een groot incident financieel kan dragen of daarvoor adequaat verzekerd is.

Een beveiligingsincident raakt zelden maar één partij. Het raakt jouw organisatie, je klanten en vaak ook de klanten van jouw klanten. Juist daarom is het essentieel om vooraf kritisch te zijn en bewust te kiezen voor een CRM integratie die security aantoonbaar serieus neemt. Gebruik je een andere CRM integratie dan die van Red Cactus, dan is deze checklist een goed startpunt om te bepalen welke risico’s je accepteert en waar je grenzen liggen.