# Inlogauditlogs analyseren in Google Workspace

[[TOC]]

## Waar vind je het aanmeldlog in 2026

Het losse Aanmeldauditlog onder het oude menu Rapporten is verdwenen. Sinds de vernieuwing van de auditervaring vallen aanmeldgebeurtenissen nu onder **Gebruikerslogboekgebeurtenissen** in de tool Controle en onderzoek.

De huidige route is: **Rapportage** > **Controle en onderzoek** > **Gebruikerslogboekgebeurtenissen**. Daar vind je aanmeldpogingen, mislukte aanmeldingen, 2-stapsverificatie en als verdacht gemarkeerde aanmeldingen terug.

:::info title="Engelse Admin Console"
In de Engelse interface heet dit pad **Reporting** > **Audit and investigation** > **User log events**. De velden en filters zijn identiek.
:::

## Wat staat er in het aanmeldlog

Voor elke aanmeldpoging registreert Google onder meer:

- Tijdstip en datum.
- Gebruikersaccount.
- IP-adres en afgeleid land of locatie.
- Apparaattype, OS-versie en apparaat-ID.
- Browser of app.
- Aanmeldresultaat (geslaagd, mislukt, uitdaging vereist).
- Gebruikte aanmeld- of uitdagingsmethode (wachtwoord, passkey, apparaatprompt, SAML, en meer).
- Of de aanmelding als verdacht is gemarkeerd.

## Aanmeldlog openen

:::howto title="Zo open je het aanmeldlog"
1. Ga naar [admin.google.com](https://admin.google.com).
2. Open het menu en ga naar **Rapportage** > **Controle en onderzoek**.
3. Kies de gegevensbron **Gebruikerslogboekgebeurtenissen**.
4. Stel een of meer voorwaarden in via het filterpaneel.
5. Klik op **Zoeken** en bekijk de resultaten in de tabel.
6. Klik op een rij voor de volledige details van die aanmelding.
:::

## Verdachte aanmeldingen herkennen

Patronen die op een gecompromitteerd account kunnen wijzen:

- **Ongewone locaties**: een aanmelding vanuit een land dat de gebruiker normaal niet gebruikt. Let vooral op aanmeldingen vanuit meerdere landen op dezelfde dag (impossible travel).
- **Mislukte pogingen gevolgd door succes**: kan wijzen op een brute force- of credential stuffing-aanval.
- **Aanmeldingen buiten kantooruren**: avond- of nachtaanmeldingen die afwijken van het normale patroon van de gebruiker.
- **Onbekend apparaat**: een nieuw apparaat-ID dat nooit eerder bij dit account is gezien.

:::warn title="Een patroon is nog geen bewijs"
Een verdacht patroon bewijst geen compromittatie. Onderzoek altijd de context. Een VPN-gebruiker of zakenreiziger kan legitiem vanuit een onverwachte locatie inloggen. Bevestig je vermoeden met meerdere signalen voor je het account blokkeert.
:::

## Filteren en zoeken

Stel in het filterpaneel voorwaarden samen, bijvoorbeeld:

- **Gebruiker**: een specifiek e-mailadres.
- **Gebeurtenis**: aanmelding geslaagd, mislukt, of als verdacht gemarkeerd.
- **IP-adres of land**: alle aanmeldingen vanuit een specifieke locatie.
- **Datum**: een tijdsbereik.

Zo spoor je impossible travel op:

:::howto title="Impossible travel opsporen"
1. Filter op een specifieke gebruiker.
2. Sorteer de resultaten op tijdstip.
3. Controleer of opeenvolgende aanmeldingen geografisch onmogelijk zijn, bijvoorbeeld Nederland om 08:00 en Brazilie om 09:00.
4. Noteer de bijbehorende IP-adressen voor verdere correlatie.
:::

## Aanmeldactiviteit exporteren

Voor incidentonderzoek of langere bewaartermijn exporteer je de resultaten.

:::howto title="Resultaten exporteren"
1. Klik boven de resultatenlijst op **Resultaten exporteren**.
2. Kies export naar **Google Spreadsheets** of **CSV**.
3. Houd rekening met de exportlimiet: 100.000 rijen, of 30 miljoen rijen met de beveiligingsonderzoekstool.
4. Voor doorlopende logging zet je in plaats daarvan **BigQuery-export** aan via Rapportage.
:::

## Combineer met andere logs

Het aanmeldlog is het meest waardevol naast andere bronnen:

| Logbron | Vraag die je beantwoordt |
| --- | --- |
| Drive-logboekgebeurtenissen | Was er na de verdachte aanmelding een bulk-download? |
| Beheerderslogboekgebeurtenissen | Zijn er instellingen of rechten gewijzigd? |
| Gmail-logboekgebeurtenissen | Zijn er verdachte e-mails verstuurd of filters aangemaakt? |
| OAuth-tokens | Is er een nieuwe app of token geautoriseerd? |

Met BigQuery-export schrijf je query's die deze logs over een langere periode correleren.

:::tip title="Bewaar langer dan zes maanden"
In de Admin Console blijven auditgegevens standaard zes maanden zichtbaar. Wil je langer bewaren voor compliance of forensisch onderzoek, schakel dan BigQuery-export in en archiveer daar je gegevens.
:::

## Automatische alerts instellen

Wacht niet tot je handmatig het log doorzoekt. Stel via het Alert Center waarschuwingen in zodat je direct een melding krijgt bij een verdachte aanmelding of een aanmelding vanaf een geblokkeerd apparaat. Zie het artikel over beheerderswaarschuwingen voor de stappen.

:::faq
### Hoe lang worden aanmeldlogs bewaard?
Standaard ongeveer zes maanden in de Admin Console. Via BigQuery-export bewaar je activiteitsgegevens langer, afhankelijk van je eigen BigQuery-bewaarinstellingen.

### Heet het nog steeds Aanmeldauditlog?
Nee. Het losse aanmeldlog is opgegaan in de tool Controle en onderzoek. Aanmeldgebeurtenissen vind je nu onder Gebruikerslogboekgebeurtenissen.

### Kan ik aanmeldlogs ophalen via een API?
Ja, via de Admin SDK Reports API. Roep `activities.list` aan met `applicationName=login` om aanmeldgebeurtenissen op te halen.

### Hoe interpreteer ik de aanmeldresultaatcode?
Codes als `login_success`, `login_failure` en `login_challenge` zijn leesbaar in de tabel. Specifieke faalredenen en uitdagingstypes staan in de detailvelden van de gebeurtenis.

### Zijn aanmeldingen via SSO ook zichtbaar?
Ja, SSO-aanmeldingen verschijnen, maar met minder detail. De authenticatie gebeurt bij de externe identityprovider; Google registreert de tokenoverdracht en het uitdagingstype (zoals SAML).

### Tot hoe ver terug kan ik zoeken via de API?
De Reports API geeft activiteitsgegevens tot maximaal 180 dagen terug. Voor oudere gegevens gebruik je je BigQuery-archief.
:::