Navigeer snel naar een pagina
Bram SuurdTechnologieBeheer softwarekoppelingen veilig: maak toegang niet-persoonsgebonden, beperk rechten en leg een intrekroute vast voor elke integratie.
In dit artikel
Vertel wat je wilt bouwen. We reageren binnen een werkdag, zonder verplichtingen.
Een koppeling tussen CRM, boekhouding of webshop draait soms ongemerkt op het account van de medewerker die hem ooit heeft ingesteld. Die persoon vertrekt, het wachtwoord verandert of de rechten worden aangepast. Dan stopt een proces plotseling, of de toegang blijft bestaan terwijl niemand meer weet waarom.
U voorkomt die afhankelijkheid door softwarekoppelingen te beheren als eigen bedrijfstoegang. Het gaat niet om een grote security-audit. Begin met weten welke koppelingen bestaan, welke gegevens ze mogen gebruiken en wie ze kan uitschakelen.
Automatiseringen beginnen vaak praktisch. Iemand koppelt Make, Zapier, Power Automate of een plug-in aan een werkaccount en bouwt een proces. Voor een proef is dat begrijpelijk. Als het proces daarna facturen, leads of klantgegevens verwerkt, ontstaat er een beheerprobleem.
Kies waar mogelijk een technische identiteit die bij het proces hoort. De leverancier kan dit een service account, integration user of aparte API-credential noemen. Sommige systemen werken juist met een OAuth-toestemming: de eigenaar van een account, of een beheerder van de organisatie, geeft een applicatie toegang zonder zijn wachtwoord aan die applicatie te geven. De precieze mogelijkheden verschillen per leverancier.
OAuth, een service account en een API-sleutel zijn dus geen synoniemen. Ze hebben wel dezelfde beheerbehoefte. Leg vast voor welk proces de toegang bestaat, wie er verantwoordelijk voor is en hoe u die toegang beëindigt. Gebruik geen gedeeld beheerdersaccount als integratie-identiteit. Leg voor herstel en noodtoegang ten minste twee menselijke beheerders vast.
Een token of API-sleutel kan geldig zijn en toch te veel toegang hebben. Een nieuwsbriefkoppeling die nieuwe contacten ontvangt, hoeft geen facturen of klantnotities te kunnen exporteren. Een voorraadkoppeling hoeft geen gebruikers te beheren.
Kies daarom per koppeling de kleinste beschikbare set rechten of scopes. Noteer niet alleen of een koppeling gegevens leest, maar ook of hij gegevens kan wijzigen, verwijderen of in bulk exporteren. Geef prioriteit aan koppelingen met betaalaccounts, financiële gegevens, klantdata, mailbox- of Drive-toegang, beheerdersrechten of AI-tools die documenten kunnen ophalen of bewaren.
Beperkte rechten lossen niet ieder risico op. OWASP beschrijft gebrekkige objectautorisatie als een veelvoorkomend API-probleem. Daarbij controleert de server van een leverancier onvoldoende of een geldige aanvrager toegang heeft tot een specifiek record. U lost zo'n fout in een SaaS-product niet zelf op met een kleinere scope. Wel beperkt u met minimale rechten de schade als een credential verkeerd wordt gebruikt. Vraag een leverancier bovendien hoe zij toegang tot afzonderlijke klanten, orders en documenten controleert.
Bewaar technische secrets zorgvuldig. Een langlevende API-sleutel, client secret of andere vertrouwelijke credential hoort niet in een spreadsheet, chatbericht, URL, browsercode of broncode. Gebruik de credentialopslag van het integratieplatform of een secret-kluis met rollen en beperkte inzage. Leg ook vast wie een secret vervangt, hoe u dat doet en wie bij een incident de toegang kan intrekken.
Voor de meeste MKB-bedrijven is een overzicht in een beveiligde werkomgeving genoeg. Vul per koppeling ten minste dit in:
| Veld | Wat u vastlegt |
|---|---|
| Koppeling | Bron- en doelsysteem, bijvoorbeeld webshop naar boekhouding |
| Gegevens | Welke gegevens gaan welke kant op, en of de koppeling leest, wijzigt, verwijdert of exporteert |
| Identiteit | Service account, OAuth-toestemming, API-credential of andere leverancierstoegang |
| Rechten | Scopes, rollen en eventuele beheerdersrechten |
| Eigenaar | Zakelijke proceseigenaar en technische beheerroute, inclusief vervanger |
| Intrekroute | Waar u toegang, refresh tokens of credentials beheert en wat de verwachte blokkeertijd is |
| Laatste controle | Datum, bevindingen en open herstelactie |
Een proceseigenaar weet waarom een koppeling bestaat. De technische beheerroute maakt duidelijk wie toegang kan wijzigen of beëindigen. In een klein bedrijf kan dat dezelfde persoon zijn, of een externe IT-partij. Zorg vooral dat u bij afwezigheid of vertrek niet afhankelijk bent van één naam of inbox.
Reserveer twintig minuten voor een eerste lijst, niet voor een volledige beoordeling. Noteer alle actieve koppelingen die bedrijfsgegevens raken. Begin bij:
Beantwoord voor de vijf koppelingen met de meeste impact deze vragen:
Komt u uit bij een oud persoonlijk account, een gedeelde sleutel of rechten die niemand kan uitleggen? Zet herstel op de backlog. Een aparte testtenant met synthetische gegevens is de veiligste plek om een aangepaste koppeling te beoordelen. Gebruik geen echte klant-, mailbox- of financiële gegevens als testmateriaal. Controleer na een wijziging ook de auditlogs van de betrokken systemen.
U hoeft OAuth of een API-protocol niet zelf te bouwen. U mag een leverancier of implementatiepartner wel vragen hoe de toegang werkt. De IETF publiceerde in 2025 RFC 9700 met actuele beveiligingsrichtlijnen voor OAuth 2.0. Dat document is geen checklist voor iedere SaaS-koppeling, maar het maakt wel duidelijk waarom een connector niet om het wachtwoord van een medewerker zou moeten vragen buiten de normale inlogomgeving van de oorspronkelijke leverancier.
Een leverancier die niet meteen op alle vragen een antwoord heeft, is niet automatisch onveilig. Laat een koppeling met gevoelige gegevens dan wel beoordelen voordat u hem breed inzet.
Controleer kritieke koppelingen bij vertrek van medewerkers, bij een leverancierswissel en wanneer een proces verandert. Plan daarnaast elk halfjaar een korte review van het register. De eerste concrete stap is klein: wijs deze week één eigenaar aan en vul de vijf koppelingen met de meeste impact in. Daarna weet u welke toegang u moet documenteren, beperken of opnieuw inrichten.
De Cyber Resilience Act raakt niet elke website. Wel moet u weten welke rol u heeft, wat er in uw software zit en wie bij een incident handelt.
© 2026 BLB Solutions. Alle rechten voorbehouden.
KVK-nummer: 42035511
