Dine medarbejdere forbandt 47 apps med Google sidste år. Kan du nævne én af dem?

12. maj 2026 | Blog

OAuth-tokens udløber ikke, når medarbejdere forlader virksomheden, adgangskoder ændres, eller apps bliver ubrugelige. Dit sikkerhedsprogram skal forstå denne risiko og fjerne unødvendige og forladte rettigheder hurtigst muligt.

Forestil dig en reservenøgle. Du gav den til en håndværker for seks måneder siden, så de kunne reparere dit varme-, ventilations- og klimaanlæg. Arbejdet er færdigt. Håndværkeren gik videre. Men nøglen virker stadig, og du har aldrig bedt om den tilbage. Det er mere eller mindre, hvad der sker, hver gang nogen i din virksomhed forbinder en tredjepartsapp til Google Workspace eller Microsoft 365 ved hjælp af OAuth. Digitale nøgler oprettes af dine medarbejdere. De udløber ikke, og i de fleste organisationer er der ingen, der sporer dem, gennemgår dem eller fjerner dem, når de ikke længere er nødvendige!

OAuth er systemet bag knapperne "Opret forbindelse til Google" og "Tillad adgang", som dit team klikker på hver dag. Det lader apps læse din kalender, sende e-mails på dine vegne eller hente data fra din cloud-lagring, alt sammen uden at dele din faktiske adgangskode. Det lyder godt. Problemet er, at det adgangstoken, det opretter, bliver hængende længe efter, at du har glemt, at appen eksisterer. Det bliver ikke annulleret, når en medarbejder forlader appen. Det nulstilles ikke, når nogen ændrer sin adgangskode. Din multifaktor-godkendelse gør intet for at stoppe en angriber, der allerede har et gyldigt token.

Mange organisationer kender ikke til dette problem. Endnu færre løser det.

Forskning fra Materiel sikkerhed fandt ud af, at 80 % af sikkerhedsledere anser ikke-administrerede OAuth-tilladelser for at være en kritisk eller betydelig risiko. Dette tal har været højt i årevis. Bevidsthed er dog måske ikke det største problem her, men at mindske denne trussel is.

45% af organisationer gør intet for at overvåge OAuth-tilladelser i stor skala

33% stole på manuel sporing som regneark og ad hoc-gennemgange

Et regneark, der fortæller dig, hvilke apps der har adgang, er ikke det samme som at vide, hvad disse apps laver med den adgang. Den ene er en liste. Den anden er sikkerhed. Lige nu har de fleste teams kun listen.

Et rigtigt angreb, der allerede har fundet sted

I 2024 og 2025 brugte en trusselsaktør kendt som UNC6395 (sporet af Palo Alto Unit 42) stjålne OAuth-opdateringstokens fra Drift, en salgsengagementsplatform, til at få adgang til Salesforce-miljøer i over 700 organisationer. Drift havde legitime OAuth-forbindelser til disse Salesforce-konti. Angriberen fik fat i disse tokens, sandsynligvis gennem tidligere phishing-angreb, og gik direkte ind ad hoveddøren.

Hvad gjorde dette angreb så effektivt
Intet så mistænkeligt ud. Tokens var gyldige. Appen var betroet. Loginet fandt aldrig sted, fordi angriberen slet ikke loggede ind. De præsenterede et eksisterende token, som Drift allerede havde fået tilladelse til at bruge. MFA havde ingen rolle at spille, fordi der ikke blev indtastet nogen adgangskode. Da de var inde, trak UNC6395 data og søgte i dem efter legitimationsoplysninger som AWS-nøgler, Snowflake-tokens og adgangskoder. Cloudflare, PagerDuty og snesevis af andre var involveret i det.

Konklusionen er ikke, at Drift var en dårlig app. Konklusionen er, at en troværdig app ved installationen kan blive en risiko senere, hvis dens loginoplysninger bliver stjålet. Dine sikkerhedsværktøjer skal holde øje med, hvad forbundne apps laver over tid, ikke kun hvilke tilladelser de bad om på dag ét.

Hvorfor de fleste sikkerhedsværktøjer overser dette

De fleste OAuth-sikkerhedsværktøjer udfører deres arbejde i det øjeblik, en app opretter forbindelse. De kontrollerer, om de anmodede tilladelser virker for høje. De markerer apps fra ukendte leverandører. Det er virkelig nyttigt, og du bør gøre det. Men det er ikke nok i sig selv.

En velkendt, pålidelig app med rimelige tilladelser ville nemt bestå disse kontroller. Hvis apps loginoplysninger bliver stjålet seks måneder senere, fanger din installationstidskontrol ingenting. Risikoen kom bagefter.

Hvad god OAuth-overvågning rent faktisk omfatter

Overvågning af appens adfærd over tid, ikke kun ved opsætning. Pludselige stigninger i dataadgang, forespørgsler på usædvanlige tidspunkter eller anmodninger om datatyper, som appen normalt ignorerer, er alle værd at markere. Statiske tilladelsesgennemgange ser aldrig disse mønstre.
Forståelse af, hvis konto der er tilknyttet. En token knyttet til en leders indbakke fuld af følsomme kontrakter indebærer en langt større risiko end den samme token knyttet til en nyansat konto. Din overvågning skal tage højde for, hvad den tilknyttede konto rent faktisk kan nå.
Reagerer med den rette hastighed. En tydeligt skadelig app uden kendt leverandør og usædvanlig opførsel fra dag ét kræver øjeblikkelig handling. En pålidelig integration, der viser en lille anomali, kræver først en menneskelig gennemgang. Din responsproces skal skelne mellem disse to situationer.

OAuth blev bygget til en enklere tid

Da OAuth blev designet, var det typiske use case et lille antal IT-godkendte apps, der fik begrænset adgang til delte kalendere. Det var en overkommelig situation. I dag forbinder hver medarbejder uafhængigt AI-værktøjer, notetagningsapps, automatiseringsplatforme og produktivitetstilføjelser til deres arbejdskonti. Hver forbindelse opretter et token. Ingen af disse tokens udløber automatisk. De fleste organisationer ved ikke, hvor mange de har.

Efterhånden som AI-værktøjer bliver standard på arbejdspladsen, vil antallet af OAuth-forbindelser i dit miljø vokse. Det er ikke realistisk helt at blokere medarbejdere fra at bruge AI-værktøjer, og det ville alligevel ikke have stoppet Drift-angrebet, da det startede med en pålidelig, godkendt integration.

Hvad du kan gøre lige nu

Start med at hente en liste over alle OAuth-apps, der er forbundet til dit Google Workspace- eller Microsoft 365-miljø. Begge platforme giver administratorer mulighed for at gøre dette uden tredjepartsværktøjer. Kig efter apps, du ikke genkender, apps, der er forbundet til konti for personer, der har forladt applikationen, og apps med meget brede tilladelser som "læs alle mails" eller "adgang til alle filer". Det er dine første prioriteter at gennemgå og tilbagekalde.

Derefter kan du opbygge en vane med at gennemgå OAuth-tilladelser hvert kvartal. Det tager kortere tid end du tror, når du først har gjort den indledende oprydning, og det forhindrer, at listen løber løbsk igen. Når medarbejdere forlader virksomheden, skal du inkludere tilbagekaldelse af OAuth i din offboarding-tjekliste sammen med nulstilling af adgangskoder og deaktivering af konto.

Dit CyberHoot-handlingstrin
Log ind på din Google Admin Console eller Microsoft Entra-portal i denne uge, og hent din liste over tilsluttede tredjepartsapps. Tæl dem. Du vil sikkert blive overrasket. Vælg de fem, der ser mindst bekendte ud, og gennemgå, hvad de har adgang til. Tilbagekald alle, der ikke hører hjemme. Den ene handling gør din organisation betydeligt mere sikker i dag. Kom i gang!