Beispiellogs für Dienstkonten

Auf dieser Seite finden Sie Beispiele für die Audit-Logs, die beim Verwalten und Verwenden von Dienstkonten generiert werden.

Weitere Informationen zum Aktivieren und Anzeigen von Audit-Logs finden Sie unter IAM-Audit-Logging.

Logs zum Erstellen von Dienstkonten

Wenn Sie ein Dienstkonto erstellen oder ändern, generiert Identity and Access Management (IAM) Logeinträge. Das folgende Beispiel zeigt einen Logeintrag zum Erstellen eines Dienstkontoschlüssels:

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "example-user@example.com"
    },
    "methodName": "google.iam.admin.v1.CreateServiceAccount",
    "response": {
      "email": "my-service-account@my-project.iam.gserviceaccount.com",
      "@type": "type.googleapis.com/google.iam.admin.v1.ServiceAccount",
      "display_name": "My service account."
    }
  },
  "resource": {
    "type": "service_account"
  }
}

Logs zum Zuweisen von Rollen

In diesem Abschnitt werden die Logeinträge gezeigt, die Sie erhalten, wenn Sie Rollen zuweisen, die sich auf Dienstkonten beziehen.

Logs zum Zuweisen der Rolle „Dienstkontonutzer”

Ein Hauptkonto kann durch eine Identitätsübernahme des Dienstkontos die gleichen Berechtigungen wie ein Dienstkonto erhalten. Hauptkonten, die eine Identitätsübernahme für ein Dienstkonto durchführen möchten, benötigen die Rolle "Dienstkontonutzer" (roles/iam.serviceAccountUser) für das Dienstkonto.

Das folgende Beispiel zeigt einen Logeintrag für die Zuweisung der Rolle "Dienstkontonutzer" an ein Hauptkonto:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "methodName": "google.iam.admin.v1.SetIAMPolicy",
    "request": {
      "@type": "type.googleapis.com/google.iam.v1.SetIamPolicyRequest",
      "resource": "projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"
    },
    "resourceName": "projects/-/serviceAccounts/123456789012345678901",
    "response": {
      "@type": "type.googleapis.com/google.iam.v1.Policy",
      "bindings": [
        {
          "members": [
            "user:my-user@example.com"
          ],
          "role": "roles/iam.serviceAccountUser"
        }
      ]
    }
  },
  "resource": {
    "type": "service_account"
  }
}

Wenn Sie die Rolle "Dienstkonto-Token-Ersteller" (roles/iam.serviceAccountTokenCreator) gewähren, die einem Hauptkonto das Erstellen kurzlebiger Anmeldedaten ermöglicht, generiert IAM einen ähnlichen Logeintrag.

Logs zum Gewähren des Zugriffs auf ein Dienstkonto für eine Ressource

Sie können einem Dienstkonto für eine bestimmte Ressource eine Rolle zuweisen, damit das Dienstkonto auf die Ressource zugreifen kann. Wenn der Dienst, dem die Ressource gehört, auch Audit-Logging unterstützt, generiert die Zuweisung einer Rolle für das Dienstkonto einen Audit-Logeintrag. Der Logeintrag enthält das Feld protoPayload.authenticationInfo.principalEmail, mit dem das Hauptkonto identifiziert wird, das die Rolle für das Dienstkonto erteilt hat.

Das folgende Beispiel zeigt einen Audit-Logeintrag zum Zuweisen einer Rolle zu einem Dienstkonto für ein Projekt. In diesem Beispiel hat example-user@example.com dem Dienstkonto die Rolle "Organisationsbetrachter" (roles/resourcemanager.organizationViewer) zugewiesen. Das Feld protoPayload.serviceName ist auf cloudresourcemanager.googleapis.com gesetzt, da Resource Manager der Google Cloud-Dienst ist, der Projekte verwaltet. Außerdem ist das Feld resource.type auf project gesetzt:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "example-user@example.com"
    },
    "methodName": "SetIamPolicy",
    "request": {
      "@type": "type.googleapis.com/google.iam.v1.SetIamPolicyRequest",
      "resource": "my-project"
    },
    "resourceName": "projects/my-project",
    "response": {
      "@type": "type.googleapis.com/google.iam.v1.Policy",
      "bindings": [
        {
          "members": [
            "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
          ],
          "role": "roles/resourcemanager.organizationViewer"
        }
      ]
    },
    "serviceName": "cloudresourcemanager.googleapis.com"
  },
  "resource": {
    "type": "project"
  }
}

Logs zum Anhängen von Dienstkonten an Ressourcen

Wenn ein Nutzer die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) für ein Dienstkonto hat, kann er das Dienstkonto an Ressourcen anhängen. Wenn Code, der auf der Ressource ausgeführt wird, auf Google Cloud-Dienste und -Ressourcen zugreift, verwendet er das an die Ressource angehängte Dienstkonto als Identität. Beispiel: Sie hängen ein Dienstkonto an eine Compute Engine-Instanz an und die Anwendungen auf der Instanz verwenden eine Clientbibliothek, um Google Cloud APIs aufzurufen. Diese Anwendungen verwenden automatisch das angehängte Dienstkonto für die Authentifizierung und Autorisierung.

In diesem Abschnitt werden einige der Protokolle angezeigt, die generiert werden, wenn Sie einer Ressource ein Dienstkonto zuordnen.

Protokolle zur Verwendung der Berechtigung iam.serviceAccounts.actAs

Zum Anhängen eines Dienstkontos an eine Ressource ist die Berechtigung iam.serviceAccounts.actAs erforderlich. Wenn ein Hauptkonto diese Berechtigung verwendet, um einer Ressource ein Dienstkonto zuzuweisen, wird ein Audit-Log generiert.

Das folgende Beispiel zeigt einen Logeintrag für ein Hauptkonto, das mit der Berechtigung iam.serviceAccounts.actAs ein Dienstkonto an eine Compute Engine-Instanz angehängt hat.

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "example-user@example.com"
    },
    "serviceName": "iam.googleapis.com",
    "methodName": "iam.serviceAccounts.actAs",
    "authorizationInfo": [
      {
        "resource": "projects/-/serviceAccounts/sample-service-account@sample-project.iam.gserviceaccount.com",
        "permission": "iam.serviceAccounts.actAs",
        "granted": true,
        "permissionType": "ADMIN_WRITE"
      }
    ],
    "resourceName": "projects/-/serviceAccounts/sample-service-account@sample-project.iam.gserviceaccount.com",
    "request": {
      "name": "sample-service-account@sample-project.iam.gserviceaccount.com",
      "project_number": "787155667719",
      "@type": "type.googleapis.com/CanActAsServiceAccountRequest"
    },
    "response": {
      "success": true,
      "@type": "type.googleapis.com/CanActAsServiceAccountResponse"
    }
  },
  "insertId": "vojt0vd4fdy",
  "resource": {
    "type": "audited_resource",
    "labels": {
      "project_id": "sample-project",
      "method": "iam.serviceAccounts.actAs",
      "service": "iam.googleapis.com"
    }
  },
  "timestamp": "2024-08-05T21:56:56.097601933Z",
  "severity": "NOTICE",
  "logName": "projects/sample-project/logs/cloudaudit.googleapis.com%2Factivity",
  "receiveTimestamp": "2024-08-05T21:56:56.097601933Z"
}

Logs zum Einrichten einer Compute Engine-Instanz, die als Dienstkonto ausgeführt werden soll

Wenn ein Nutzer die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) für ein Dienstkonto hat, kann er eine Compute Engine-VM-Instanz erstellen, die als dieses Dienstkonto ausgeführt wird. In diesem Szenario erstellt der Nutzer die VM-Instanz mit seinen eigenen Anmeldedaten und die Anfrage gibt ein Dienstkonto an, das von der VM-Instanz verwendet werden soll.

Wenn ein Nutzer eine VM-Instanz erstellt, erstellt Compute Engine mehrere Logeinträge. Das folgende Beispiel zeigt den ersten Logeintrag, der den Nutzer, der die VM-Instanz erstellt hat, sowie das von der Instanz verwendete Dienstkonto identifiziert. In diesem Beispiel hat der Nutzer example-user@example.com eine Instanz erstellt, die das Dienstkonto my-service-account@my-project.iam.gserviceaccount.com verwendet. Daher wird das Feld protoPayload.authenticationInfo.principalEmail auf example-user@example.com und das Feld protoPayload.request.serviceAccounts[0].email auf my-service-account@my-project.iam.gserviceaccount.com gesetzt:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "example-user@example.com"
    },
    "methodName": "v1.compute.instances.insert",
    "request": {
      "@type": "type.googleapis.com/compute.instances.insert",
      "serviceAccounts": [
        {
          "email": "my-service-account@my-project.iam.gserviceaccount.com"
        }
      ]
    },
    "resourceName": "projects/my-project/zones/us-central1-a/instances/my-instance"
  },
  "resource": {
    "type": "gce_instance"
  }
}

Logs für den Zugriff auf Google Cloud mit einem Dienstkontoschlüssel

In diesem Abschnitt werden die Logeinträge angezeigt, die Sie erhalten, wenn Sie einen Dienstkontoschlüssel erstellen und dann mit dem Schlüssel auf Google Cloud zugreifen.

Logs zum Erstellen eines Dienstkontoschlüssels

Wenn Sie die Rolle "Dienstkontoschlüsseladministrator" (roles/iam.serviceAccountKeyAdmin) für ein Dienstkonto haben, können Sie einen Dienstkontoschlüssel erstellen und dann den Schlüssel verwenden, um Anfragen an Google Cloud-Dienste zu authentifizieren.

Das folgende Beispiel zeigt einen Logeintrag zum Erstellen eines Dienstkontoschlüssels. In diesem Beispiel hat der Nutzer example-user@example.com einen Schlüssel für das Dienstkonto my-service-account@my-project.iam.gserviceaccount.com erstellt:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "example-user@example.com",
    },
    "methodName": "google.iam.admin.v1.CreateServiceAccountKey",
    "request": {
      "@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountKeyRequest",
      "name": "projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"
    },
    "resourceName": "projects/-/serviceAccounts/123456789012345678901"
  },
  "resource": {
    "type": "service_account"
  }
}

Logs zur Authentifizierung mit einem Dienstkontoschlüssel

Nachdem Sie einen Dienstkontoschlüssel erstellt haben, können Sie mit dem Schlüssel ein OAuth 2.0-Zugriffstoken für ein Dienstkonto anfordern und anschließend mit diesem Zugriffstoken Anfragen an Google Cloud-Dienste authentifizieren. Im Allgemeinen enthalten die Audit-Logs für diese Dienste diese Informationen:

  • protoPayload.authenticationInfo.principalEmail: Die E-Mail-Adresse des Dienstkontos, das das Zugriffstoken darstellt.
  • protoPayload.authenticationInfo.serviceAccountKeyName: Der Dienstkontoschlüssel, mit dem das OAuth 2.0-Zugriffstoken angefordert wurde. Dieses Feld identifiziert den Dienstkontoschlüssel anhand seines vollständigen Ressourcennamens im Format //iam.googleapis.com/projects/project-id/serviceAccounts/service-account-email/keys/key-id.

Das folgende Beispiel zeigt einen Audit-Logeintrag für eine Anfrage zum Erstellen einer Memorystore for Redis-Instanz. Die Anfrage wurde mit einem OAuth 2.0-Zugriffstoken für ein Dienstkonto authentifiziert. In diesem Beispiel heißt das Dienstkonto my-service-account@my-project.iam.gserviceaccount.com und die Dienstkontoschlüssel-ID c71e040fb4b71d798ce4baca14e15ab62115aaef:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "my-service-account@my-project.iam.gserviceaccount.com",
      "serviceAccountKeyName": "//iam.googleapis.com/projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com/keys/c71e040fb4b71d798ce4baca14e15ab62115aaef"
    },
    "methodName": "google.cloud.redis.v1.CloudRedis.CreateInstance",
    "request": {
      "@type": "type.googleapis.com/google.cloud.redis.v1.CreateInstanceRequest"
    }
  }
}

Logs zur Identitätsübernahme des Dienstkontos für den Zugriff auf Google Cloud

In diesem Abschnitt werden die Logeinträge angezeigt, die Sie erhalten, wenn Sie kurzlebige Anmeldedaten für ein Dienstkonto erstellen und dann mit den Anmeldedaten eine Identitätsübernahme des Dienstkontos durchführen sowie auf Google Cloud zugreifen.

Logs zum Erstellen kurzlebiger Anmeldedaten

Wenn Sie die Rolle „Dienstkonto-Token-Ersteller“ (roles/iam.serviceAccountTokenCreator) für ein Dienstkonto haben, können Sie kurzlebige Anmeldedaten für das Dienstkonto erstellen und mit den Anmeldedaten eine Identitätsübernahme des Dienstkontos durchführen. Sie können beispielsweise kurzlebige Anmeldedaten erstellen, um eine Google Cloud API von einer Anwendung aus aufzurufen, die nicht in Google Cloud ausgeführt wird.

IAM kann Audit-Logs generieren, wenn Hauptkonten kurzlebige Anmeldedaten erstellen. Damit Sie diese Audit-Logs erhalten können, müssen Sie IAM-Audit-Logs für Datenzugriffsaktivitäten aktivieren.

Nachdem Sie IAM-Audit-Logs für Datenzugriffsaktivitäten aktiviert haben, generiert IAM jedes Mal einen Audit-Log-Eintrag, wenn ein Hauptkonto kurzlebige Anmeldedaten erstellt. Der Eintrag enthält diese Felder:

  • protoPayload.authenticationInfo.principalEmail: Das Hauptkonto, das die kurzlebigen Anmeldedaten erstellt hat.
  • resource.labels.email_id: Das Dienstkonto, für das kurzlebige Anmeldedaten erstellt wurden.

Das folgende Beispiel zeigt einen Audit-Logeintrag für eine Anfrage zum Erstellen eines kurzlebigen OAuth 2.0-Zugriffstokens. In diesem Beispiel hat der Nutzer example-user@example.com ein Zugriffstoken für das Dienstkonto my-service-account@my-project.iam.gserviceaccount.com erstellt:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "example-user@example.com"
    },
    "methodName": "GenerateAccessToken",
    "request": {
      "@type": "type.googleapis.com/google.iam.credentials.v1.GenerateAccessTokenRequest",
      "name": "projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"
    },
    "serviceName": "iamcredentials.googleapis.com"
  },
  "resource": {
    "labels": {
      "email_id": "my-service-account@my-project.iam.gserviceaccount.com",
      "project_id": "my-project",
      "unique_id": "123456789012345678901"
    },
    "type": "service_account"
  }
}

Logs zur Authentifizierung mit kurzlebigen Anmeldedaten

Nach dem Erstellen kurzlebiger Anmeldedaten für ein Dienstkonto können Sie mit den Anmeldedaten die Identitätsübernahme des Dienstkontos durchführen, wenn Sie Google Cloud APIs aufrufen.

Einige der von Ihnen aufgerufenen Methoden generieren möglicherweise Audit-Logs. Im Allgemeinen weisen diese Logeinträge diese Identitäten auf:

  • Das Dienstkonto, für das die kurzlebigen Anmeldedaten eine Identitätsübernahme durchführen
  • Die Identität, die die kurzlebigen Anmeldedaten erstellt hat

Beispiel: Der Nutzer example-user@example.com erstellt kurzlebige Anmeldedaten für das Dienstkonto my-service-account@my-project.iam.gserviceaccount.com. Der Nutzer erstellt dann ein neues Pub/Sub-Thema und führt dabei mit den kurzlebigen Anmeldedaten eine Identitätsübernahme des Dienstkontos durch. Pub/Sub generiert einen Logeintrag, der das Dienstkonto sowie den Nutzer identifiziert, der die Identitätsübernahme des Dienstkontos durchführt:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "my-service-account@my-project.iam.gserviceaccount.com",
      "serviceAccountDelegationInfo": [
        {
          "firstPartyPrincipal": {
            "principalEmail": "example-user@example.com"
          }
        }
      ]
    },
    "methodName": "google.pubsub.v1.Publisher.CreateTopic",
    "request": {
      "@type": "type.googleapis.com/google.pubsub.v1.Topic",
      "name": "projects/my-project/topics/my-topic"
    },
    "resourceName": "projects/my-project/topics/my-topic"
  },
  "resource": {
    "type": "pubsub_topic"
  }
}

Protokolle zu Aktionen von Dienst-Agents

Manchmal führt ein Dienst-Agent eine Aktion im Namen des Hauptkontos aus, wenn dieses einen Vorgang initiiert. Wenn Sie jedoch Audit-Logs für einen Dienst-Agent prüfen, kann es schwierig sein zu erkennen, in wessen Namen der Dienst-Agent gehandelt hat und warum.

Damit Sie den Kontext für die Aktionen eines Dienst-Agents besser nachvollziehen können, fügen einige Dienst-Agents zusätzliche Details in ihre Audit-Logs ein, z. B. den Job, mit der die Aktion verknüpft ist, und das Hauptkonto, das den Job erstellt hat.

Die folgenden Dienst-Agents fügen ihren Audit-Logs diese zusätzlichen Details hinzu:

Diese zusätzlichen Details finden Sie im Feld serviceDelegationHistory des Audit-Logs, das im Feld authenticationInfo verschachtelt ist. Dieses Feld enthält die folgenden Informationen:

  • Das ursprüngliche Hauptkonto, das den Job erstellt hat
  • Der Dienst-Agent, der die Aktion ausgeführt hat
  • Der Dienst, zu dem der Dienst-Agent gehört
  • Job-ID

Angenommen, example-user@example.com erstellt einen Job mit der BigQuery Connection API. Für diesen Job muss einer der Dienst-Agents der BigQuery Connection API eine Aktion ausführen. In diesem Fall würde das Audit-Log für die Aktion des Kundenservicemitarbeiters ein serviceDelegationHistory-Feld enthalten, das in etwa so aussieht: 

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "bqcx-442188550395-jujw@gcp-sa-bigquery-condel.iam.gserviceaccount.com",
      "serviceDelegationHistory": {
        "originalPrincipal": "user:my-user@example.com",
        "serviceMetadata": [
          {
            "principalSubject": "serviceAccount:bqcx-442188550395-jujw@gcp-sa-bigquery-condel.iam.gserviceaccount.com",
            "serviceDomain": "bigquery.googleapis.com",
          }
        ]
      }
    }
  }
}

Nächste Schritte