Uw medewerkers hebben vorig jaar 47 apps aan Google gekoppeld. Kunt u er één noemen?

12 mei 2026 | Blog

OAuth-tokens verlopen niet wanneer medewerkers vertrekken, wachtwoorden wijzigen of apps zich misdragen. Uw beveiligingsprogramma moet dit risico begrijpen en onnodige en verlaten toegangsrechten zo snel mogelijk verwijderen.

Stel je een reservesleutel voor. Je hebt hem zes maanden geleden aan een aannemer gegeven om je airconditioning te repareren. De klus is geklaard. De aannemer is vertrokken. Maar de sleutel werkt nog steeds en je hebt hem nooit teruggevraagd. Dat is min of meer wat er gebeurt elke keer dat iemand binnen je bedrijf een app van een derde partij koppelt aan Google Workspace of Microsoft 365 via OAuth. Digitale sleutels worden aangemaakt door je medewerkers. Ze verlopen niet en in de meeste organisaties houdt niemand ze bij, controleert ze niet en verwijdert ze niet wanneer ze niet meer nodig zijn!

OAuth is het systeem achter de knoppen 'Verbinden met Google' en 'Toegang toestaan' waarop uw team dagelijks klikt. Hiermee kunnen apps uw agenda lezen, namens u e-mails versturen of gegevens uit uw cloudopslag ophalen, allemaal zonder uw daadwerkelijke wachtwoord te delen. Dat klinkt geweldig. Het probleem is echter dat het toegangstoken dat wordt aangemaakt, blijft bestaan lang nadat u de app alweer bent vergeten. Het wordt niet geannuleerd wanneer een medewerker vertrekt. Het wordt niet gereset wanneer iemand zijn wachtwoord wijzigt. Uw multifactorauthenticatie biedt geen bescherming tegen een aanvaller die al een geldig token in handen heeft.

Veel organisaties zijn zich niet bewust van dit probleem. Nog minder organisaties pakken het aan.

Onderzoek van Material Security toonde aan dat 80% van de beveiligingsmanagers onbeheerde OAuth-toegang als een kritiek of significant risico beschouwt. Dat percentage is al jaren hoog. Bewustwording is hier misschien niet het grootste probleem, maar het beperken van deze dreiging wel.

45% van de organisaties doet niets om OAuth-toekenningen op grote schaal te monitoren.

33% vertrouwt op handmatige registratie, zoals spreadsheets en ad-hoc beoordelingen.

Een spreadsheet die laat zien welke apps toegang hebben, is niet hetzelfde als weten wat die apps met die toegang doen. Het ene is een lijst, het andere is beveiliging. Op dit moment hebben de meeste teams alleen de lijst.

Een echte aanval die al heeft plaatsgevonden.

In 2024 en 2025 gebruikte een cybercrimineel, bekend als UNC6395 (gevolgd door Palo Alto Unit 42), gestolen OAuth-verversingstokens van Drift, een platform voor sales engagement, om toegang te krijgen tot de Salesforce-omgevingen van meer dan 700 organisaties. Drift had legitieme OAuth-verbindingen met deze Salesforce-accounts. De aanvaller bemachtigde deze tokens, waarschijnlijk via eerdere phishingaanvallen, en kon zo direct toegang krijgen.

Wat maakte deze aanval zo effectief?
Niets leek verdacht. De tokens waren geldig. De app was betrouwbaar. De login vond nooit plaats, omdat de aanvaller helemaal niet inlogde. Ze presenteerden een bestaand token dat Drift al mocht gebruiken. MFA speelde geen rol, omdat er geen wachtwoord werd ingevoerd. Eenmaal binnen haalde UNC6395 gegevens op en doorzocht deze naar inloggegevens zoals AWS-sleutels, Snowflake-tokens en wachtwoorden. Cloudflare, PagerDuty en tientallen andere bedrijven werden hierbij getroffen.

De conclusie is niet dat Drift een slechte app was. De conclusie is dat een app die bij installatie betrouwbaar lijkt, later een risico kan vormen als de inloggegevens worden gestolen. Je beveiligingssoftware moet in de gaten houden wat verbonden apps in de loop van de tijd doen, niet alleen welke machtigingen ze op de eerste dag hebben aangevraagd.

Waarom de meeste beveiligingsprogramma's dit over het hoofd zien

De meeste OAuth-beveiligingstools doen hun werk op het moment dat een app verbinding maakt. Ze controleren of de gevraagde machtigingen buitensporig lijken. Ze markeren apps van onbekende leveranciers. Dat is echt nuttig en je zou het ook moeten doen. Maar het is op zichzelf niet voldoende.

Een bekende, betrouwbare app met redelijke machtigingen zou die controles gemakkelijk doorstaan. Als de inloggegevens van die app zes maanden later worden gestolen, detecteert uw controle op het moment van installatie niets. Het risico ontstond pas achteraf.

Wat goede OAuth-monitoring in de praktijk inhoudt

Het gedrag van de app gedurende langere tijd observeren, niet alleen tijdens de installatie. Plotselinge pieken in de gegevenstoegang, query's op ongebruikelijke tijdstippen of verzoeken om gegevenstypen die de app normaal negeert, zijn allemaal redenen om te signaleren. Bij statische controles van machtigingen worden dergelijke patronen nooit opgemerkt.
Inzicht in wiens account is gekoppeld. Een token dat gekoppeld is aan de inbox van een leidinggevende vol gevoelige contracten brengt veel meer risico met zich mee dan hetzelfde token dat gekoppeld is aan het account van een nieuwe medewerker. Bij het monitoren moet rekening worden gehouden met wat het gekoppelde account daadwerkelijk kan bereiken.
Reageren met de juiste snelheid. Een duidelijk kwaadaardige app zonder bekende leverancier en met ongebruikelijk gedrag vanaf dag één vereist onmiddellijke actie. Een vertrouwde integratie die een kleine afwijking vertoont, vereist eerst een menselijke beoordeling. Uw reactieproces moet deze twee situaties van elkaar kunnen onderscheiden.

OAuth is ontworpen voor een eenvoudiger tijdperk.

Toen OAuth werd ontworpen, was het typische gebruiksscenario dat een klein aantal door IT goedgekeurde apps beperkte toegang kreeg tot gedeelde agenda's. Dat was een beheersbare situatie. Tegenwoordig koppelt elke medewerker zelfstandig AI-tools, notitie-apps, automatiseringsplatforms en productiviteitsadd-ons aan zijn of haar werkaccount. Elke koppeling genereert een token. Geen van die tokens verloopt automatisch. De meeste organisaties weten niet hoeveel tokens ze hebben.

Naarmate AI-tools de standaard worden op de werkvloer, zal het aantal OAuth-verbindingen in uw omgeving toenemen. Het volledig blokkeren van het gebruik van AI-tools door werknemers is niet realistisch en zou de Drift-aanval sowieso niet hebben tegengehouden, aangezien die begon met een vertrouwde, goedgekeurde integratie.

Wat u nu kunt doen

Begin met het opvragen van een lijst van alle OAuth-apps die verbonden zijn met uw Google Workspace- of Microsoft 365-omgeving. Beide platforms stellen beheerders in staat dit te doen zonder tools van derden. Zoek naar apps die u niet herkent, apps die zijn gekoppeld aan accounts van mensen die niet meer werkzaam zijn, en apps met zeer brede machtigingen zoals 'alle e-mail lezen' of 'toegang tot alle bestanden'. Dit zijn uw eerste prioriteiten om te controleren en in te trekken.

Maak er vervolgens een gewoonte van om de OAuth-toekenningen elk kwartaal te controleren. Het kost minder tijd dan je denkt als je de eerste opruiming eenmaal hebt gedaan, en het voorkomt dat de lijst weer uit de hand loopt. Wanneer medewerkers vertrekken, neem dan het intrekken van OAuth-toekenningen op in je offboarding-checklist, samen met het resetten van wachtwoorden en het deactiveren van accounts.

Jouw CyberHoot-actiestap
Log deze week in op uw Google Admin Console of Microsoft Entra-portal en bekijk de lijst met verbonden apps van derden. Tel ze. U zult waarschijnlijk verbaasd zijn. Kies de vijf apps die u het minst bekend voorkomen en controleer tot welke toegang ze toegang hebben. Trek de toegang in van alle apps die er niet thuishoren. Deze ene actie maakt uw organisatie vandaag nog aanzienlijk veiliger. Hoera!