Nutzung von IAM-Dienstkonten einschränken

Der Organization Policy Service bietet Einschränkungen, mit denen Sie in Organisationsrichtlinien die Nutzung von Identity and Access Management (IAM) Dienstkonten begrenzen können.

Viele dieser Einschränkungen bestimmen, ob Dienstkonten und andere Ressourcen auf bestimmte Weise erstellt oder konfiguriert werden können. Diese Einschränkungen sind nicht rückwirkend. Sie haben keinen Einfluss auf bereits erstellte und konfigurierte Dienstkonten.

Hinweis

Sie müssen die Berechtigung haben, Organisationsrichtlinien zu ändern, um Einschränkungen festzulegen. Die Rolle orgpolicy.policyAdmin hat beispielsweise die Berechtigung zum Festlegen von Einschränkungen für Organisationsrichtlinien. Weitere Informationen zum Verwalten von Richtlinien auf Organisationsebene finden Sie auf der Seite Organisationsrichtlinien erstellen.

Verwaltete Einschränkungen (Legacy) mit booleschen Regeln

Die folgenden Einschränkungen sind Typen von verwalteten Einschränkungen (Legacy) mit booleschen Regeln, die auf „true“ oder „false“ gesetzt sind.

Automatische Rollenzuweisungen für Standarddienstkonten deaktivieren

Einige Cloud de Confiance Dienste erstellen automatisch Standarddienstkonten. Wenn ein Standarddienstkonto erstellt wird, erhält es automatisch die Rolle „Bearbeiter“ (roles/editor) für Ihr Projekt.

Zur Verbesserung der Sicherheit empfehlen wir Ihnen dringend, die automatische Rollenzuweisung zu deaktivieren. Verwenden Sie die verwaltete Einschränkung (Legacy) iam.automaticIamGrantsForDefaultServiceAccounts, um die automatische Rollenzuweisung zu deaktivieren.

Erstellen von Dienstkonten deaktivieren

Mit der verwalteten Einschränkung (Legacy) iam.disableServiceAccountCreation können Sie die Erstellung neuer Dienstkonten deaktivieren. Auf diese Weise können Sie die Verwaltung von Dienstkonten zentralisieren, ohne die anderen Projektberechtigungen Ihrer Entwickler einzuschränken.

Wenn Sie diese Einschränkung in einem Projekt erzwingen, können einige Cloud de Confiance Dienste nicht automatisch Standarddienstkontenerstellen. Wenn das Projekt Arbeitslasten ausführt, für die eine Identitätsübernahme des Dienstkontos erforderlich ist, enthält das Projekt möglicherweise kein Dienstkonto, das von der Arbeitslast verwendet werden kann. Zur Behebung dieses Problems können Sie die Identitätsübernahme des Dienstkontos über Projekte hinweg aktivieren. Wenn Sie dieses Feature aktivieren, können Sie Dienstkonten in einem zentralisierten Projekt erstellen und diese Dienstkonten dann an Ressourcen in anderen Projekten anhängen.

Weitere Informationen zum Organisieren von Dienstkonten finden Sie unter Wo Dienstkonten erstellt werden können.

Erstellen von Dienstkontoschlüsseln deaktivieren

Mit der verwalteten Einschränkung (Legacy) iam.disableServiceAccountKeyCreation können Sie die Erstellung neuer externer Dienstkontoschlüssel und HMAC-Schlüssel für Cloud Storage deaktivieren. Damit können Sie die Verwendung von nicht verwalteten, langfristigen Anmeldedaten für Dienstkonten steuern. Wenn diese Einschränkung festgelegt ist, können keine von Nutzern verwalteten Anmeldedaten für Dienstkonten in Projekten erstellt werden, die von der Einschränkung betroffen sind.

Hochladen von Dienstkontoschlüsseln deaktivieren

Mit der verwalteten Einschränkung (Legacy) iam.disableServiceAccountKeyUpload können Sie das Hochladen externer öffentlicher Schlüssel in Dienstkonten deaktivieren. Wenn diese Einschränkung festgelegt ist, können Nutzer keine öffentlichen Schlüssel in Dienstkonten in Projekten hochladen, die von der Einschränkung betroffen sind.

Anhängen von Dienstkonten an Ressourcen in anderen Projekten deaktivieren

Jedes Dienstkonto befindet sich in einem Projekt. Mit der verwalteten Einschränkung (Legacy) iam.disableCrossProjectServiceAccountUsage können Sie verhindern, dass Dienstkonten in einem Projekt an Ressourcen in anderen Projekten angehängt werden.

Wenn Sie die Verwendung von Dienstkonten über Projekte hinweg zulassen möchten, finden Sie weitere Informationen unter Identitätsübernahme des Dienstkontos über Projekte hinweg aktivieren.

Entfernen von Projektsperren einschränken, wenn Dienstkonten projektübergreifend verwendet werden

Wenn Sie zulassen, dass die Dienstkonten eines Projekts an Ressourcen in anderen Projekten angehängt werden, fügt IAM eine Projektsperre hinzu, die das Löschen des Projekts verhindert. Standardmäßig kann jeder, der die Berechtigung resourcemanager.projects.updateLiens für das Projekt hat, die Sperre löschen.

Wenn Sie die verwaltete Einschränkung (Legacy) iam.restrictCrossProjectServiceAccountLienRemoval erzwingen, können Hauptkonten die Sperre nur dann löschen, wenn sie die Berechtigung resourcemanager.projects.updateLiens für die Organisation haben.

Wir empfehlen, diese Einschränkung zu erzwingen, wenn eines Ihrer Projekte den projektübergreifenden Identitätswechsel für Dienstkonten zulässt.

Workload Identity-Clustererstellung deaktivieren

Mit der verwalteten Einschränkung (Legacy) iam.disableWorkloadIdentityClusterCreation können Sie verlangen, dass bei neuen Google Kubernetes Engine-Clustern die Workload Identity Funktion bei ihrer Erstellung deaktiviert ist. Wenn Sie den Zugriff auf Dienstkonten in Ihrer Organisation streng kontrollieren möchten, möchten Sie möglicherweise zusätzlich zur Erstellung von Dienstkonten und Dienstkontoschlüsseln die Workload Identity deaktivieren.

Bestehende GKE-Cluster mit aktivierter Workload Identity Federation for GKE sind nicht betroffen und funktionieren weiterhin wie gewohnt.

Verwaltete Einschränkung (Legacy) mit booleschen Regeln festlegen

gcloud resource-manager org-policies enable-enforce \
    --organization 'ORGANIZATION_ID' \
    CONSTRAINT_NAME

disable-enforce

Weitere Informationen zur Verwendung von Einschränkungen in Organisationsrichtlinien finden Sie unter Organisationsrichtlinien erstellen.

Beispiel für eine verwaltete Einschränkung (Legacy) mit booleschen Regeln

Das folgende Code-Snippet zeigt eine Organisationsrichtlinie, die die verwaltete Einschränkung (Legacy) iam.disableServiceAccountCreation erzwingt, die verhindert, dass Dienstkonten erstellt werden:

name: organizations/012345678901/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

Verwaltete Einschränkungen (Legacy) mit Listenregeln

Die folgenden Einschränkungen sind Typen von verwalteten Einschränkungen (Legacy) mit Listenregeln, die auf eine Liste von Werten festgelegt sind.

Lebensdauer von OAuth 2.0-Zugriffstokens verlängern

Sie können ein OAuth 2.0-Zugriffstoken erstellen, das kurzlebige Anmeldedaten für ein Dienstkonto bereitstellt. Standardmäßig beträgt die maximale Lebensdauer eines Zugriffstokens 1 Stunde (3.600 Sekunden). Sie können die maximale Lebensdauer jedoch auf 12 Stunden (43.200 Sekunden) verlängern.

Identifizieren Sie dazu zuerst die Dienstkonten, bei denen eine verlängerte Lebensdauer für Tokens festgelegt werden soll. Fügen Sie diese Dienstkonten danach einer Organisationsrichtlinie hinzu, in der die constraints/iam.allowServiceAccountCredentialLifetimeExtension Einschränkung enthalten ist. Wenn Sie ein Token für diese Dienstkonten mit der REST API erstellen,können Sie eine Lebensdauer von bis zu 43.200 Sekunden (12 Stunden) angeben. Die Google Cloud CLI unterstützt nicht das Festlegen einer Lebensdauer für das Token.

Lebensdauer von Dienstkontoschlüsseln begrenzen

Mit einem Dienstkontoschlüssel können Sie eine Anfrage als Dienstkonto authentifizieren. Standardmäßig laufen Dienstkontoschlüssel niemals ab. Sie können diese Standardeinstellung ändern, indem Sie eine Ablaufzeit für alle neu erstellten Schlüssel in Ihrem Projekt, Ordner oder Ihrer Organisation festlegen.

Verwenden Sie die verwaltete Einschränkung (Legacy) constraints/iam.serviceAccountKeyExpiryHours, um eine Ablaufzeit festzulegen. Geben Sie dazu die Anzahl der Stunden an, für die ein neu erstellter Schlüssel gültig ist. Nach dieser Zeit läuft der Dienstkontoschlüssel ab und kann nicht mehr verwendet werden.

Diese verwaltete Einschränkung (Legacy) akzeptiert die folgenden ALLOW-Werte, aber keine DENY-Werte. Verwenden Sie als Best Practice die kürzeste Ablaufzeit, die Ihren Anforderungen entspricht:

• 1h: 1 Stunde
• 8h: 8 Stunden
• 24h: 24 Stunden (1 Tag)
• 168h: 168 Stunden (7 Tage)
• 336h: 336 Stunden (14 Tage)
• 720h: 720 Stunden (30 Tage)
• 1440h: 1.440 Stunden (60 Tage)
• 2160h: 2.160 Stunden (90 Tage)

Die Einschränkung constraints/iam.serviceAccountKeyExpiryHours kann nicht mit einer übergeordneten Richtlinie zusammengeführt werden. Wenn Sie diese Einschränkung erzwingen möchten, müssen Sie entweder die übergeordnete Richtlinie ersetzen oder übernehmen.

Zulässige externe Identitätsanbieter angeben

Wenn Sie die Workload Identity-Föderationverwenden, mit der externe Identitäten auf Cloud de Confiance Ressourcen zugreifen können, können Sie angeben, welche externen Identitätsanbieter zulässig sind. Standardmäßig sind alle Anbieter zulässig. Verwenden Sie zum Festlegen eines Limits die verwaltete Einschränkung (Legacy) constraints/iam.workloadIdentityPoolProviders, um URIs für die zulässigen Anbieter in den folgenden Formaten anzugeben:

• Amazon Web Services (AWS): https://sts.amazonaws.com

  Verwenden Sie die auf dieser Seite beschriebene verwaltete Einschränkung (Legacy) constraints/iam.workloadIdentityPoolAwsAccounts, um die zulässigen AWS-Konten zu begrenzen.

• Microsoft Azure: https://sts.windows.net/azure-tenant-id

• Andere Identitätsanbieter, die OpenID Connect (OIDC) unterstützen: Verwenden Sie den Aussteller-URI Ihres Identitätsanbieters.

Zulässige AWS-Konten angeben

Wenn Sie die Workload Identity-Föderationverwenden, mit der externe Identitäten auf Cloud de Confiance Ressourcen zugreifen können, können Sie angeben, welche AWS-Konten auf Ihre Ressourcen zugreifen dürfen. Standardmäßig können Arbeitslasten von jedem AWS-Konto auf Ihre Cloud de Confiance Ressourcen zugreifen. Wenn Sie begrenzen möchten, welche AWS-Konten zulässig sind, geben Sie mit der verwalteten Einschränkung (Legacy) constraints/iam.workloadIdentityPoolAwsAccounts eine Liste der zulässigen Konto-IDs an.

Offengelegte Dienstkontoschlüssel automatisch deaktivieren

Cloud de Confiance by S3NS stellt gelegentlich fest, dass ein bestimmter Dienstkontoschlüssel offengelegt wurde. Beispielsweise kann ein Schlüssel in einem öffentlichen Repository erkannt werden. Mit der verwalteten Einschränkung (Legacy) iam.serviceAccountKeyExposureResponse können Sie angeben, was mit diesen Schlüsseln tun soll. Cloud de Confiance Zu den überwachten Schlüsseln gehören langlebige Dienstkontoschlüssel und API-Schlüssel, die an ein Dienstkonto gebunden sind.

Diese verwaltete Einschränkung (Legacy) akzeptiert die folgenden ALLOW-Werte, aber keine DENY-Werte.

• DISABLE_KEY: Wenn Cloud de Confiance einen offengelegten Schlüssel erkennt, wird der Schlüssel automatisch deaktiviert. Außerdem wird ein Cloud-Audit-Logereignis erstellt und eine Benachrichtigung über den offengelegten Schlüssel an Projektinhaber und Sicherheits kontaktegesendet.

  Cloud de Confiance

• WAIT_FOR_ABUSE: Cloud de Confiance deaktiviert offengelegte Schlüssel nicht proaktiv. kann jedoch Cloud de Confiance offengelegte Schlüssel deaktivieren, wenn sie auf eine Weise verwendet werden, die sich negativ auf die Plattform auswirkt. Unabhängig davon, ob der offengelegte Schlüssel deaktiviert ist, Cloud de Confiance erstellt ein Cloud-Audit-Logereignis und sendet eine Benachrichtigung über den offengelegte Schlüssel an Projektinhaber und Sicherheits kontakte.

Wenn Cloud de Confiance einen offengelegten Schlüssel erkennt oder einen offengelegten Schlüssel deaktiviert, führt es auch Folgendes aus:

• Generiert Cloud-Audit-Logereignisse.

  • Wenn Cloud de Confiance erkennt, dass ein Schlüssel offengelegt wurde, wird in den Missbrauchsereignis-Logs ein Missbrauchsereignis erstellt.

  • Wenn Cloud de Confiance einen Schlüssel deaktiviert, enthalten die Audit-Logs die Deaktivierungs aktion durch das Hauptkonto gcp-compromised-key-response@s3ns-system.system.gserviceaccount.com.

• Legt das extendedStatus.value Feld des offengelegten oder deaktivierten Schlüssels fest. Das Feld für den erweiterten Status enthält den Ort, an dem die Offenlegung erkannt wurde.

Wir empfehlen dringend, diese Einschränkung auf DISABLE_KEY zu setzen. Wenn Sie diese Einschränkung auf WAIT_FOR_ABUSE setzen, erhöht sich das Risiko, dass offengelegte Schlüssel missbraucht werden.

Wenn Sie die Einschränkung auf WAIT_FOR_ABUSE setzen, empfehlen wir, Cloud-Audit-Logereignisse zu abonnieren, Ihre Sicherheitskontaktinformationen unter Wichtige Kontakte zu prüfen und dafür zu sorgen, dass Ihre Sicherheitskontakte zeitnah auf Benachrichtigungen reagieren.

Die Einschränkung iam.serviceAccountKeyExposureResponse kann nicht mit einer übergeordneten Richtlinie zusammengeführt werden. Wenn Sie diese Einschränkung erzwingen möchten, müssen Sie die übergeordnete Richtlinie ersetzen.

Verwaltete Einschränkung (Legacy) mit Listenregeln festlegen

gcloud resource-manager org-policies allow \
    CONSTRAINT_NAME \
    VALUE_1 [VALUE_N ...] \
    --organization=ORGANIZATION_ID \

Weitere Informationen zur Verwendung von Einschränkungen in Organisationsrichtlinien finden Sie unter Organisationsrichtlinien erstellen.

Beispiel für eine verwaltete Einschränkung (Legacy) mit Listenregeln

Das folgende Code-Snippet zeigt eine Organisationsrichtlinie, die die verwaltete Einschränkung (Legacy) iam.allowServiceAccountCredentialLifetimeExtension erzwingt, die die maximale Lebensdauer von OAuth 2.0-Zugriffstokens für die aufgeführten Dienstkonten verlängert:

name: organizations/012345678901/policies/iam.allowServiceAccountCredentialLifetimeExtension
spec:
  rules:
  - values:
      allowedValues:
      - SERVICE_ACCOUNT_ADDRESS

Einschränkungen mit Tags bedingt erzwingen

Tags können verwendet werden, um Ressourcen mit Tags in die Erzwingung von Organisationsrichtlinien einzubeziehen oder auszuschließen. Nachdem Sie ein Tag erstellt und an ein Dienstkonto angehängt haben, können Sie der Richtlinie eine Bedingung hinzufügen, um Dienstkonten mit Tags bedingt in die Erzwingung einzubeziehen oder sie davon auszuschließen.

Weitere Informationen zur Verwendung von Tags mit Organisationsrichtlinien finden Sie unter Organisationsrichtlinien mit Tags eingrenzen.

Fehlermeldungen

Erstellen von Dienstkonten deaktivieren

Wenn iam.disableServiceAccountCreation erzwungen wird, schlägt das Erstellen eines Dienstkontos fehl und folgende Fehlermeldung wird zurückgegeben:

FAILED_PRECONDITION: Service account creation is not allowed on this project.

Erstellung von API-Schlüsseln deaktivieren, die an Dienstkonten gebunden sind

Wenn iam.managed.disableServiceAccountApiKeyCreation erzwungen wird, schlägt das Erstellen eines API-Schlüssels, der an ein Dienstkonto gebunden ist, fehl und folgende Fehlermeldung wird zurückgegeben:

FAILED_PRECONDITION: Operation denied by org policy:
["constraints/iam.managed.disableServiceAccountApiKeyCreation":
"When enforced, disables creation of API Keys bound to service accounts."]

Erstellen von Dienstkontoschlüsseln deaktivieren

Wenn iam.disableServiceAccountKeyCreation erzwungen wird, schlägt das Erstellen eines Dienstkontos fehl und folgende Fehlermeldung wird zurückgegeben:

FAILED_PRECONDITION: Key creation is not allowed on this service account.

Workload Identity-Clustererstellung deaktivieren

Wenn iam.disableWorkloadIdentityClusterCreation erzwungen wird, schlägt das Erstellen eines GKE-Clusters mit aktivierter Workload Identity mit dem folgenden Fehler fehl:

FAILED_PRECONDITION: Workload Identity is disabled by the organization
policy constraints/iam.disableWorkloadIdentityClusterCreation. Contact your
administrator to enable this feature.

Bekannte Fehler beheben

Standarddienstkonten

Durch Anwendung der Einschränkung iam.disableServiceAccountCreation wird die Erstellung von Dienstkonten in diesem Projekt verhindert. Diese Einschränkung betrifft auch Cloud de Confiance Dienste, die bei Aktivierung automatisch Standard Dienstkonten im Projekt erstellen, wie zum Beispiel:

• Compute Engine
• GKE
• App Engine
• Dataflow

Wenn die Einschränkung iam.disableServiceAccountCreation angewendet wird, schlägt das Aktivieren dieser Dienste fehl, da ihre Standarddienstkonten nicht erstellt werden können.

So lösen Sie dieses Problem:

1. Entfernen Sie vorübergehend die Einschränkung iam.disableServiceAccountCreation.
2. Aktivieren Sie die gewünschten Dienste.
3. Erstellen Sie gegebenenfalls weitere Dienstkonten.
4. Wenden Sie die Einschränkung wieder an.