Integratie security: zo bescherm je je data bij het koppelen van bedrijfssystemen

Door Clen Mourik

50% van de MKB-bedrijven kreeg vorig jaar een cybersecurity-incident. API's en systeemkoppelingen worden steeds vaker als zwakke schakel misbruikt. Dit artikel legt uit hoe je je data beschermt bij het koppelen van bedrijfssystemen — zonder dat je een security-expert hoeft te zijn.

Hoeveel systemen gebruikt jouw bedrijf? Je boekhouding draait in AFAS of Exact Online. Je projectadministratie in een ander pakket. Je urenregistratie weer elders. En die systemen moeten met elkaar praten, anders typ je alles dubbel over.

Maar hier zit een risico waar weinig ondernemers bij stilstaan: elke koppeling tussen systemen is een potentiële toegangspoort voor mensen met slechte bedoelingen. Volgens het Cybersecuritybeeld Nederland 2023 van het NCSC heeft 50% van de MKB-bedrijven vorig jaar te maken gehad met een cybersecurity-incident. En API's — de techniek waarmee systemen verbonden worden — worden steeds vaker als zwakke schakel misbruikt.

Dit artikel legt uit hoe je je data beschermt bij het koppelen van bedrijfssystemen. Geen technisch jargon waar je niks aan hebt, maar concrete maatregelen die je vandaag nog kunt implementeren. Ook als je geen dedicated IT-afdeling hebt.

Inhoudsopgave

• Belangrijkste punten
• Waarom integratie security belangrijk is
• De 7 meest gemaakte security-fouten bij koppelingen
• OAuth 2.0 vs. API keys: wat is het verschil?
• Concrete security-maatregelen voor je integraties
• Welke aanpak past bij jouw bedrijf?
• Checklist: is jouw integratie veilig?
• Veelgestelde vragen

Belangrijkste punten

Waarom integratie security belangrijk is

Laten we eerlijk zijn: de meeste ondernemers denken "dit overkomt mij niet". Je bent geen bank, geen ziekenhuis, geen multinational. Waarom zou een hacker interesse hebben in jouw bouwbedrijf of groothandel?

Het antwoord is simpel: omdat het kan.

Moderne cyberaanvallen zijn geautomatiseerd. Criminelen scannen het hele internet op zwakke plekken — verkeerd geconfigureerde API's, systemen zonder wachtwoord, oude software met bekende lekken. Als jouw integratie een zwakke plek heeft, vinden ze die. Niet omdat je interessant bent, maar omdat je kwetsbaar bent.

De Autoriteit Persoonsgegevens registreerde in 2022 meer dan 28.000 datalekken in Nederland. Een significant deel kwam voort uit onveilige koppelingen tussen systemen. En het hoeft niet eens om persoonlijke data te gaan — ook je bedrijfskritische informatie is waardevol.

Denk aan een productiebedrijf waarbij een aanvaller toegang krijgt tot je productieplanning en kostenstructuur. Of een groothandel waarbij een concurrent je marges en inkoopprijzen kan uitlezen. Of een accountantskantoor waarbij de financiële data van al je klanten gelekt wordt.

Wat ik in de praktijk zie: bedrijven onderschatten hoeveel schade een datalek aanricht. Het gaat niet alleen om de directe kosten, maar ook om reputatieschade en verlies van klantvertrouwen.

De kosten? Een datalek kost een Nederlands MKB-bedrijf gemiddeld tussen de €15.000 en €50.000. En dan heb je het alleen over de directe kosten: forensisch onderzoek om te achterhalen wat er gebeurd is, melding aan de Autoriteit Persoonsgegevens, herstel van systemen, en eventuele boetes. Je hebt het nog niet over omzetverlies, reputatieschade en de tijd die je medewerkers ermee kwijt zijn.

De 7 meest gemaakte security-fouten bij koppelingen

Na honderden integraties voor MKB-bedrijven zie ik steeds dezelfde fouten terugkomen. Het goede nieuws: ze zijn allemaal te voorkomen.

1. API-credentials in de code

De meest voorkomende fout: een developer plaatst API-keys of wachtwoorden rechtstreeks in de broncode. "Maakt niet uit, dat ziet toch niemand" — totdat die code in een Git-repository komt die per ongeluk publiek staat. Of erger: de credentials staan in JavaScript-code die elke websitebezoeker kan inspecteren.

Wat ik vorige maand nog tegenkwam: een groothandel had hun WooCommerce-webshop gekoppeld aan hun voorraadsysteem. De API-keys stonden letterlijk in de JavaScript-code van de website. Een concurrent opende gewoon de broncode in zijn browser, vond de credentials, en had toegang tot hun complete voorraad- en klantdata.

2. Geen HTTPS/TLS-encryptie

Sommige koppelingen communiceren nog over HTTP in plaats van HTTPS. Dat betekent dat alle data onversleuteld over het internet gaat — wachtwoorden, klantgegevens, financiële informatie. Iedereen die het netwerkverkeer kan onderscheppen, kan meelezen.

Bij oudere on-premise systemen wordt dit nog weleens over het hoofd gezien. "Het draait toch binnen ons eigen netwerk?" Ja, totdat een medewerker vanaf de kroeg of het station inlogt op het bedrijfsnetwerk.

3. Te ruime toegangsrechten

Bij het aanvragen van OAuth-tokens of API-rechten vragen bedrijven vaak "alle rechten" aan. Waarom? Omdat het makkelijk is. Je hoeft niet uit te zoeken welke rechten je precies nodig hebt.

Maar als zo'n token gelekt wordt, heeft een aanvaller onnodig veel toegang. Je koppeling hoeft alleen orders te kunnen uitlezen? Geef dan alleen leesrechten op orders, niet volledige schrijfrechten op je hele administratie.

4. Geen logging en monitoring

De meeste MKB-bedrijven loggen hun API-aanroepen niet. Of ze loggen wel, maar bekijken die logs nooit. Resultaat: ongeautoriseerde toegang of abnormaal gebruik wordt pas opgemerkt als er daadwerkelijke schade is.

Onderzoek van IBM toont aan dat het gemiddeld 207 dagen duurt voordat een organisatie een datalek ontdekt. Bij onveilige API-koppelingen wordt vaak pas achteraf ontdekt dat er maandenlang ongeautoriseerde toegang is geweest.

5. API-endpoints zonder authenticatie

Sommige integraties hebben "webhook"-endpoints — URLs die data ontvangen bij bepaalde gebeurtenissen. Probleem: deze endpoints hebben vaak geen enkele verificatie. Iedereen die de URL kent, kan data naar je systeem sturen.

Voorbeeld: je voorraadsysteem heeft een webhook die voorraadmutaties ontvangt. Als die webhook niet beveiligd is, kan iemand willekeurige voorraadaanpassingen naar je systeem sturen en zo je administratie verknallen.

6. Vergeten oude API-keys te verwijderen

Na het testen van een integratie of bij wisseling van leverancier worden oude API-keys niet ingetrokken. Die blijven vaak jarenlang actief. Als een oud teamlid die credentials nog heeft, of als ze ergens in een oude backup staan, vormen ze een beveiligingsrisico.

7. Geen rate limiting

Rate limiting beperkt het aantal API-calls per tijdseenheid. Zonder rate limiting kan een aanvaller duizenden wachtwoorden proberen (brute force), je API overbelasten, of enorme kosten veroorzaken bij betaalde API's.

Recent voorbeeld: een webshop had een koppeling tussen Shopify en hun verzendpartner zonder rate limiting. Een botnet deed binnen enkele uren 500.000+ API-calls, waardoor ze hun API-limiet overschreden en €8.000 extra kosten maakten. Hun orderverwerking viel plat doordat de verzendpartner hen tijdelijk blokkeerde.

OAuth 2.0 vs. API keys: wat is het verschil?

Als je gaat koppelen tussen systemen, kom je deze twee termen tegen. Laten we het verschil helder maken.

API keys: simpel maar risicovol

Een API key is in feite een lang wachtwoord. Je krijgt van het systeem een code als "ak_live_xyz123abc" en die gebruik je bij elk verzoek. Voordelen: simpel, makkelijk te implementeren. Nadelen: als iemand die key heeft, heeft diegene volledige toegang. En het is moeilijk om rechten te beperken.

Het is vergelijkbaar met een fysieke sleutel van je pand. Als je die kwijtraakt, kan iemand anders naar binnen. En je kunt niet zeggen "deze sleutel mag alleen de voordeur openen, niet het magazijn".

OAuth 2.0: modern en veiliger

OAuth 2.0 werkt met tijdelijke tokens in plaats van permanente wachtwoorden. De standaard flow:

1. Jouw applicatie vraagt toestemming aan de gebruiker
2. Gebruiker authoriseert via de identity provider (bijvoorbeeld inlog bij Exact Online)
3. Applicatie krijgt een access token (tijdelijk, vaak 1 uur geldig)
4. Applicatie krijgt een refresh token (langere geldigheid, om nieuwe access tokens op te halen)

Voordelen: access tokens verlopen automatisch, je kunt precies aangeven welke rechten je nodig hebt (scopes), en als een token gelekt wordt heeft een aanvaller maar beperkte tijd toegang.

OAuth is niet perfect, maar het is wel een enorme verbetering ten opzichte van permanente API-keys. Het principe van tijdelijke toegang beperkt de schade als er iets misgaat.

Veel moderne systemen zoals Exact Online, AFAS en Shopify gebruiken OAuth 2.0 als standaard. Bij SyncIT bouwen we alle nieuwe integraties met OAuth waar het systeem dit ondersteunt.

Concrete security-maatregelen voor je integraties

Nu we weten wat er mis kan gaan, gaan we kijken naar concrete maatregelen. Niet alles is voor elk bedrijf nodig — ik leg uit wanneer welke maatregel zinvol is.

1. TLS/SSL-encryptie (verplicht voor iedereen)

Dit is de absolute basis. Alle communicatie tussen systemen MOET over HTTPS verlopen met TLS 1.2 of nieuwer. Geen uitzonderingen. Dit voorkomt dat data onderschept kan worden tijdens transport.

Controleer: als je API-URLs ziet die met "http://" beginnen in plaats van "https://", is er een probleem. Moderne browsers en systemen weigeren meestal al onveilige verbindingen, maar bij oudere on-premise software moet je hier expliciet op letten.

2. IP whitelisting (voor vaste locaties)

Als je weet dat je integratie alleen vanaf je kantoor of een vaste server draait, sta dan alleen die IP-adressen toe. Aanvallers vanaf andere locaties komen er dan niet in, zelfs als ze credentials hebben.

Wanneer zinvol: bij server-to-server koppelingen, vaste werkplekken, dedicated integratie-servers. Wanneer niet: bij mobiele medewerkers, thuiswerken, cloud-applicaties die vanaf verschillende IP's draaien.

3. Rate limiting (vooral bij publieke endpoints)

Beperk het aantal API-calls per minuut of uur. Dit beschermt tegen brute force aanvallen, onbedoelde loops in code, en voorkomt dat een fout in je systeem enorme kosten veroorzaakt.

Praktische waarden: 100 requests per minuut is vaak ruim voldoende voor normale bedrijfsvoering. Als je meer nodig hebt, is dat vaak een teken dat je integratie inefficiënt gebouwd is.

4. Logging en monitoring (iedereen, geen excuses)

Log minimaal deze zaken:

• Alle authenticatie-pogingen (geslaagd én mislukt)
• API-calls met timestamp, IP-adres, endpoint en gebruiker
• Fouten en exceptions
• Rate limit hits

En dan moet je die logs ook daadwerkelijk monitoren. Stel alerts in voor verdachte patronen: veel mislukte inlogpogingen, API-calls buiten kantooruren, ongebruikelijk hoge volumes.

Let op: log GEEN gevoelige data. Wachtwoorden, volledige creditcardnummers, BSN's horen niet in logs thuis.

5. Twee-factor authenticatie voor API-beheer

Moderne API-beheerplatforms ondersteunen 2FA voor het aanmaken en beheren van API-keys. Betekent dat een aanvaller niet alleen je wachtwoord, maar ook je telefoon nodig heeft.

Klinkt als overkill? Een accountantskantoor waar we mee werkten had een medewerker wiens laptop gestolen werd. Dankzij 2FA op hun API-beheerportaal konden de dieven niks met de opgeslagen credentials.

6. Credentials nooit in code

Gebruik omgevingsvariabelen of een secrets management systeem. API-keys en wachtwoorden horen niet in je broncode, niet in Git, en zeker niet in JavaScript dat in de browser draait.

Als je een externe partij hebt die je integratie bouwt, vraag dan expliciet hoe ze credentials opslaan. Als het antwoord vaag is, is dat een red flag.

7. Principle of least privilege

Geef alleen de rechten die echt nodig zijn. Als je integratie alleen orders hoeft uit te lezen, geef dan geen schrijfrechten. Als het alleen facturen moet maken in je boekhouding, geef dan geen toegang tot personeelsdossiers.

Bij OAuth kun je dit regelen met scopes. Bij API-keys is dit vaak moeilijker, wat een reden te meer is om OAuth te prefereren waar mogelijk.

Welke aanpak past bij jouw bedrijf?

Er zijn verschillende manieren om integraties te bouwen en te beveiligen. Elk heeft voor- en nadelen. Laten we eerlijk zijn over wat bij welke situatie past.

Maatwerk integratie met directe API-koppelingen

Je laat een developer (intern of extern) een custom integratie bouwen die direct met de API's van je systemen praat.

Voordelen: volledig op maat, maximale controle, kan complexe edge cases aan. Nadelen: duurder, vraagt eigen security-kennis, onderhoud bij API-wijzigingen ligt bij jou.

Security-overweging: jij bent volledig verantwoordelijk voor alle security-aspecten. Als je geen IT-afdeling hebt die hier verstand van heeft, is dit risicovol.

Past bij: bedrijven met eigen IT-afdeling, complexe integraties die standaard tools niet aankunnen, zeer specifieke requirements.

iPaaS-platforms (Zapier, Make, Workato)

Integration Platform as a Service — platforms waar je met een visuele interface integraties bouwt tussen verschillende systemen.

Voordelen: snel, geen code nodig, pre-built connectoren, platform regelt veel security. Nadelen: minder flexibel, maandelijkse kosten stijgen snel bij volume, afhankelijk van platform-security.

Security-overweging: je vertrouwt op de security van het platform, maar zij hebben wel access tot je data. Bekijk hun certificeringen (ISO 27001, SOC 2) en waar data opgeslagen wordt (GDPR).

Past bij: standaard koppelingen, beperkt volume, geen gevoelige data of platform heeft goede compliance.

Specialized integratie-partijen

Bedrijven zoals SyncIT die gespecialiseerd zijn in integraties voor specifieke doelgroepen of sectoren.

Voordelen: expertise in zowel systemen als security, onderhoud en monitoring inbegrepen, vaak AVG-compliant en certificeringen. Nadelen: maandelijkse kosten, afhankelijkheid van externe partij.

Security-overweging: professionele partijen hebben security-protocollen, zijn vaak ISO/NEN gecertificeerd, en hebben ervaring met compliance. Vraag naar hun security-maatregelen en certificeringen.

Past bij: bedrijven zonder eigen IT-afdeling, complexere integraties, wanneer security en compliance belangrijk zijn.

Native koppelingen van softwareleveranciers

Bijvoorbeeld: AFAS heeft native koppelingen met Exact, Shopify heeft apps in hun App Store.

Voordelen: door leverancier getest, vaak simpel te activeren, support vanuit leverancier. Nadelen: beperkt tot wat leverancier biedt, soms functioneel beperkt.

Security-overweging: meestal goed beveiligd omdat leverancier hun reputatie beschermt. Maar controleer wel wat de app precies mag doen.

Past bij: standaard use cases, wanneer een native koppeling beschikbaar is die je behoeften dekt.

Checklist: is jouw integratie veilig?

Gebruik deze checklist om je huidige of nieuwe integraties te beoordelen. Niet elk punt is voor elk bedrijf kritiek, maar hoe meer vinkjes, hoe beter.

Minder dan 6 vinkjes? Dan loop je significant risico. 6-9 vinkjes: redelijk, maar er is ruimte voor verbetering. 10+ vinkjes: je security is op orde.

Wil je hulp bij het doorlopen van deze checklist voor jouw specifieke situatie? We doen dit regelmatig als onderdeel van een adviesgesprek — dan kijken we naar je huidige setup en geven concrete verbeterpunten.

Veelgestelde vragen

Wat kost een datalek gemiddeld voor een MKB-bedrijf?

Tussen de €15.000 en €50.000 aan directe kosten (forensisch onderzoek, AP-melding, systeemherstel, eventuele boetes). Daar komen dan nog indirecte kosten bij zoals reputatieschade en omzetverlies. Grotere bedrijven kunnen kosten in de tonnen oplopen.

Is OAuth 2.0 altijd beter dan API keys?

In de meeste gevallen wel, omdat OAuth tijdelijke tokens gebruikt en granulaire rechten toestaat. Maar voor simpele server-to-server koppelingen zonder gebruikersinteractie kunnen API keys soms praktischer zijn — mits goed beveiligd met IP whitelisting en rate limiting.

Moet ik als klein bedrijf ook zorgen over API-security?

Ja. Moderne cyberaanvallen zijn geautomatiseerd en richten zich juist op kleine bedrijven omdat die vaak minder goed beveiligd zijn. Het NCSC rapporteerde dat 50% van het MKB vorig jaar een security-incident had. Goede beveiliging hoeft niet duur te zijn, maar je moet het wel serieus nemen.

Hoe weet ik of mijn huidige integratie veilig is?

Gebruik de checklist in dit artikel. Minimaal moet je kunnen bevestigen dat alles over HTTPS loopt, credentials niet in code staan, en je API-activiteit logt. Als je dit niet zeker weet, laat het dan checken door iemand met verstand van zaken.

Wat moet ik doen als ik een beveiligingsincident vermoed?

Direct actie ondernemen: verdachte API-keys intrekken, logbestanden beveiligen, betrokken systemen isoleren. Bij persoonlijke data: binnen 72 uur melden bij de Autoriteit Persoonsgegevens. Schakel expertise in voor forensisch onderzoek om te bepalen wat er precies gebeurd is.

Zijn iPaaS-platforms zoals Zapier veilig genoeg voor bedrijfskritische data?

Grote platforms zoals Zapier, Make en Workato hebben goede security en vaak certificeringen zoals ISO 27001 en SOC 2. Voor veel MKB-toepassingen is dit voldoende. Bij zeer gevoelige data (medische gegevens, financiële systemen van klanten) wil je mogelijk meer controle en kun je beter voor een dedicated integratie-oplossing kiezen.

Hoe vaak moet ik mijn API-keys verversen?

Bij OAuth-tokens gebeurt dit automatisch (access tokens verlopen vaak na 1 uur). Voor API keys die niet automatisch verlopen: minimaal bij personeel dat vertrekt, bij vermoedens van compromittering, en als best practice minstens jaarlijks. Sommige compliance-standaarden eisen 90-daagse rotatie.

Wat is het verschil tussen encryptie "in transit" en "at rest"?

"In transit" betekent tijdens verzending — dit regel je met TLS/HTTPS. "At rest" betekent tijdens opslag — credentials en gevoelige data in je database moeten ook versleuteld zijn. Je hebt beide nodig voor volledige bescherming.

Voor meer informatie over veilige integraties en hoe wij bij SyncIT omgaan met security, bekijk onze integratie-overzicht of lees meer in onze kennisbank.

Vragen over de security van jouw huidige of geplande integraties? We denken graag mee. Plan een adviesgesprek en we kijken samen naar wat er nodig is om je data goed te beschermen — zonder onnodige complexiteit.