# Service accounts aanmaken en beheren

[[TOC]]

## Wat zijn service accounts

Service accounts zijn Google-accounts zonder wachtwoord voor mensen. Ze vertegenwoordigen een applicatie of geautomatiseerd proces. In plaats van een wachtwoord gebruiken ze een privésleutel (JSON-sleutelbestand) of, bij voorkeur, Workload Identity Federation voor authenticatie.

Gebruik service accounts voor:

- API-aanroepen vanuit een server of script.
- Apps Script dat namens gebruikers handelt.
- Cloud Functions die Workspace-resources benaderen.
- Integraties met tools van derden.

:::warn title="Krachtig en dus risicovol"
Service accounts zijn krachtig. Een gecompromitteerd service account met brede rechten kan enorme schade aanrichten. Volg altijd het principe van minste privilege en ken alleen de rollen en scopes toe die echt nodig zijn.
:::

## Service account aanmaken

:::howto title="Zo maak je een service account aan"
1. Ga naar [console.cloud.google.com](https://console.cloud.google.com).
2. Selecteer of maak een project.
3. Ga naar **IAM en beheer**, dan **Serviceaccounts**.
4. Klik op **Serviceaccount aanmaken**.
5. Vul een beschrijvende naam en een omschrijving in.
6. Wijs de benodigde rollen toe (zie hieronder).
7. Klik op **Gereed**.
:::

## Rollen en rechten toewijzen

Ken alleen de rollen toe die de applicatie echt nodig heeft. Gebruik voorgedefinieerde rollen in plaats van de brede `Owner` of `Editor`:

- `roles/admin.directory.readonly` voor leestoegang tot de Directory.
- `roles/gmail.readonly` voor leestoegang tot Gmail.
- Aangepaste rollen voor specifieke rechtensets.

Controleer regelmatig welke service accounts welke rollen hebben via **IAM en beheer**, dan **IAM** en **Serviceaccounts**.

## Sleutelbeheer

Kies bij voorkeur voor **Workload Identity Federation** in plaats van JSON-sleutelbestanden. Sleutelbestanden zijn langdurige, draagbare credentials die gelekt kunnen worden; Workload Identity Federation verwijdert de behoefte aan zulke sleutels.

:::info title="Sleutelaanmaak vaak standaard uit"
Voor organisaties die op of na 3 mei 2024 zijn aangemaakt, blokkeert Google standaard het aanmaken van service account-sleutels via de organisatie-policy `iam.disableServiceAccountKeyCreation`. Krijg je de melding dat sleutelaanmaak is uitgeschakeld, dan is dat doorgaans deze beveiligingsmaatregel. Gebruik in dat geval een keyless alternatief zoals Workload Identity Federation, een gekoppeld service account of service account impersonation.
:::

Als je toch sleutelbestanden gebruikt, houd je dan aan deze regels:

1. Bewaar ze nooit in code repositories.
2. Gebruik een geheimbeheerder (Google Secret Manager, HashiCorp Vault).
3. Roteer sleutels minimaal elk jaar.
4. Verwijder ongebruikte sleutels direct.

## Domeinbrede delegatie instellen

Domeinbrede delegatie (domain-wide delegation, DWD) geeft een service account de bevoegdheid om namens elke gebruiker in je Workspace-organisatie te handelen, zonder dat die gebruikers toestemming geven. Dit is een krachtige maar riskante instelling.

:::howto title="Zo stel je domeinbrede delegatie in"
1. Ga in de Admin Console naar **Beveiliging**, dan **Toegang en gegevensbeheer**, dan **API-besturingselementen**, dan **Domeinbrede delegatie**.
2. Klik op **Nieuw toevoegen**.
3. Voer het client-ID van het service account in (te vinden in de Cloud Console).
4. Voeg alleen de minimaal benodigde OAuth-scopes toe.
5. Klik op **Autoriseren**.
:::

Beperk DWD tot service accounts die het echt nodig hebben. Elke scope die je toekent is een extra aanvalsoppervlak.

## Service accounts monitoren

Log de activiteit van service accounts via **Cloud Audit Logs** in de Cloud Console. Stel waarschuwingen in bij onverwacht gebruik van scopes of bij aanroepen buiten kantooruren.

In de Admin Console onder **Rapporten**, dan **Auditlogboek**, dan **OAuth** zie je welke service accounts OAuth-tokens hebben aangevraagd.

:::tip title="Inventariseer periodiek"
Plan elk kwartaal een korte review: welke service accounts bestaan er, welke rollen en scopes hebben ze, en zijn er nog sleutels of accounts die je kunt opruimen? Ongebruikte rechten en oude sleutels zijn een veelvoorkomend lek.
:::

:::faq
### Kunnen service accounts inloggen op de Admin Console?
Nee, service accounts hebben geen toegang tot de Admin Console. Ze communiceren uitsluitend via API's.

### Wat doe ik als een service account-sleutel gelekt is?
Verwijder de sleutel direct in de Cloud Console onder IAM en beheer, Serviceaccounts, Sleutels. Verwijder ook het sleutelbestand overal waar het was opgeslagen en roteer alle secrets die het service account kende. Controleer daarna de auditlogs op verdacht gebruik.

### Heeft een service account een Workspace-licentie nodig?
Nee, service accounts zijn Google Cloud-identiteiten en vereisen geen Workspace-licentie.

### Kan ik een service account als lid aan een Workspace-groep toevoegen?
Ja, je kunt het e-mailadres van het service account aan groepen toevoegen. Dit is handig als de applicatie berichten naar de groep moet sturen.

### Waarom kan ik geen sleutel aanmaken voor mijn service account?
Waarschijnlijk staat de organisatie-policy die sleutelaanmaak blokkeert aan. Sinds 3 mei 2024 staat die voor nieuwe organisaties standaard aan. Gebruik een keyless alternatief zoals Workload Identity Federation, of laat een organisatiebeheerder de policy zo nodig aanpassen.

### Wat is het verschil tussen rollen in Cloud Console en scopes in domeinbrede delegatie?
Rollen in de Cloud Console bepalen wat het service account in Google Cloud mag doen. OAuth-scopes bij domeinbrede delegatie bepalen welke Workspace-gegevens van gebruikers het namens hen mag benaderen. Je hebt beide nodig en houdt beide zo beperkt mogelijk.
:::