Dine ansatte koblet 47 apper til Google i fjor. Kan du nevne én av dem?

12. mai 2026 | Blogg

OAuth-tokener utløper ikke når ansatte slutter, passord endres eller apper blir ubrukelige. Sikkerhetsprogrammet ditt må forstå denne risikoen og fjerne unødvendige og forlatte rettigheter så snart som mulig.

Se for deg en reservenøkkel. Du ga den til en entreprenør for seks måneder siden slik at de kunne fikse HVAC-systemet ditt. Jobben er gjort. Entreprenøren gikk videre. Men nøkkelen fungerer fortsatt, og du ba aldri om å få den tilbake. Det er mer eller mindre det som skjer hver gang noen i bedriften din kobler en tredjepartsapp til Google Workspace eller Microsoft 365 ved hjelp av OAuth. Digitale nøkler opprettes av dine ansatte. De utløper ikke, og i de fleste organisasjoner er det ingen som sporer dem, gjennomgår dem eller fjerner dem når de ikke lenger trengs!

OAuth er systemet bak knappene «Koble til Google» og «Tillat tilgang» som teamet ditt klikker på hver dag. Det lar apper lese kalenderen din, sende e-poster på dine vegne eller hente data fra skylagringen din, alt uten å dele det faktiske passordet ditt. Det høres flott ut. Haken er at tilgangstokenet den oppretter blir værende lenge etter at du har glemt at appen eksisterer. Det blir ikke kansellert når en ansatt slutter. Det tilbakestilles ikke når noen endrer passordet sitt. Flerfaktorautentiseringen din gjør ingenting for å stoppe en angriper som allerede har et gyldig token.

Mange organisasjoner vet ikke om dette problemet. Enda færre løser det.

forskning fra Materiell sikkerhet fant ut at 80 % av sikkerhetsledere anser uadministrerte OAuth-tildelinger som en kritisk eller betydelig risiko. Dette tallet har vært høyt i årevis. Bevissthet er imidlertid kanskje ikke hovedproblemet her, men det å redusere denne trusselen is.

45% av organisasjoner gjør ingenting for å overvåke OAuth-tildelinger i stor skala

33% stole på manuell sporing som regneark og ad hoc-gjennomganger

Et regneark som viser hvilke apper som har tilgang er ikke det samme som å vite hva disse appene gjør med den tilgangen. Det ene er en liste. Det andre er sikkerhet. Akkurat nå har de fleste team bare listen.

Et reelt angrep som allerede har skjedd

I 2024 og 2025 brukte en trusselaktør kjent som UNC6395 (sporet av Palo Alto Unit 42) stjålne OAuth-oppdateringstokener fra Drift, en plattform for salgsengasjement, for å få tilgang til Salesforce-miljøene til over 700 organisasjoner. Drift hadde legitime OAuth-tilkoblinger til disse Salesforce-kontoene. Angriperen fikk tak i disse tokenene, sannsynligvis gjennom tidligere phishing-angrep, og gikk rett inn hoveddøren.

Hva gjorde dette angrepet så effektivt
Ingenting så mistenkelig ut. Tokenene var gyldige. Appen var klarert. Innloggingen skjedde aldri fordi angriperen ikke logget inn i det hele tatt. De presenterte en eksisterende token som Drift allerede hadde fått tillatelse til å bruke. MFA hadde ingen rolle å spille fordi det ikke ble skrevet inn noe passord. Vel inne hentet UNC6395 data og søkte i dem etter legitimasjon som AWS-nøkler, Snowflake-tokener og passord. Cloudflare, PagerDuty og dusinvis av andre var involvert i det.

Konklusjonen er ikke at Drift var en dårlig app. Konklusjonen er at en pålitelig app ved installasjon kan bli en risiko senere hvis påloggingsinformasjonen blir stjålet. Sikkerhetsverktøyene dine må overvåke hva tilkoblede apper gjør over tid, ikke bare hvilke tillatelser de ba om på dag én.

Hvorfor de fleste sikkerhetsverktøy går glipp av dette

De fleste OAuth-sikkerhetsverktøyene gjør jobben sin i det øyeblikket en app kobles til. De sjekker om tillatelsene som forespurtes virker overdrevne. De flagger apper fra ukjente leverandører. Det er virkelig nyttig, og du burde gjøre det. Men det er ikke nok alene.

En kjent og pålitelig app med rimelige tillatelser ville bestått disse kontrollene lett. Hvis appens legitimasjon blir stjålet seks måneder senere, fanger ikke installasjonskontrollen din opp noe. Risikoen kom i etterkant.

Hva god OAuth-overvåking faktisk inkluderer

Overvåking av appens oppførsel over tid, ikke bare ved oppsett. Plutselige økninger i datatilgang, spørringer på uvanlige tidspunkter eller forespørsler om datatyper som appen vanligvis ignorerer, er alle verdt å flagge. Statiske tillatelsesgjennomganger ser aldri disse mønstrene.
Forstå hvem sin konto som er tilkoblet. En token knyttet til en leders innboks full av sensitive kontrakter medfører mye mer risiko enn den samme token knyttet til en nyansatts konto. Overvåkingen din må ta hensyn til hva den tilkoblede kontoen faktisk kan nå.
Å svare med riktig hastighet. En tydelig skadelig app uten kjent leverandør og uvanlig oppførsel fra dag én krever umiddelbar handling. En pålitelig integrasjon som viser et lite avvik, krever først en menneskelig gjennomgang. Responsprosessen din må skille disse to situasjonene fra hverandre.

OAuth ble bygget for en enklere tid

Da OAuth ble utviklet, var det typiske brukstilfellet et lite antall IT-godkjente apper som fikk begrenset tilgang til delte kalendere. Det var en håndterbar situasjon. I dag kobler hver ansatt uavhengig AI-verktøy, notatapper, automatiseringsplattformer og produktivitetstillegg til jobbkontoene sine. Hver tilkobling oppretter et token. Ingen av disse tokenene utløper automatisk. De fleste organisasjoner vet ikke hvor mange de har.

Etter hvert som AI-verktøy blir standard på arbeidsplassen, vil antallet OAuth-tilkoblinger i miljøet ditt øke. Å blokkere ansatte fullstendig fra å bruke AI-verktøy er ikke realistisk, og det ville uansett ikke ha stoppet Drift-angrepet siden det startet med en pålitelig, godkjent integrasjon.

Hva du kan gjøre akkurat nå

Start med å hente en liste over alle OAuth-apper som er koblet til Google Workspace- eller Microsoft 365-miljøet ditt. Begge plattformene lar administratorer gjøre dette uten tredjepartsverktøy. Se etter apper du ikke kjenner igjen, apper som er koblet til kontoer til personer som har sluttet, og apper med svært brede tillatelser som «les all e-post» eller «tilgang til alle filer». Dette er dine første prioriteringer å gjennomgå og tilbakekalle.

Derfra bør du bygge en vane med å gjennomgå OAuth-tildelinger kvartalsvis. Det tar kortere tid enn du tror når du har gjort den første oppryddingen, og det hindrer at listen går over styr igjen. Når ansatte slutter, bør du inkludere tilbakekalling av OAuth i sjekklisten for offboarding sammen med tilbakestilling av passord og deaktivering av konto.

Ditt CyberHoot-tiltak
Denne uken logger du deg på Google Admin Console eller Microsoft Entra-portalen og finner listen over tilkoblede tredjepartsapper. Tell dem. Du vil sannsynligvis bli overrasket. Velg de fem som ser minst kjente ut, og se gjennom hva de har tilgang til. Tilbakekall alle som ikke hører hjemme. Den ene handlingen gjør organisasjonen din betydelig tryggere i dag. Hopp til!