Naar inhoud
lightbulb Welkom op de nieuwe kennisbank | We hebben de docs volledig vernieuwd met meer dan 160 features. Bekijk wat nieuw isarrow_forward

Service accounts aanmaken en beheren

Service accounts zijn speciale Google-accounts voor applicaties en geautomatiseerde processen. Ze authentiseren zonder menselijke gebruiker en zijn essentieel voor API-integraties.

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.
warning

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

Zo maak je een service account aan

  1. Ga naar 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

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.

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.

lightbulb

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.

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.