Exemplos de registos para contas de serviço

Esta página mostra exemplos dos registos de auditoria gerados quando gere ou usa uma conta de serviço.

Para mais informações sobre como ativar e ver registos de auditoria, consulte o artigo Registo de auditoria da IAM.

Registos para a criação de contas de serviço

Quando cria ou modifica uma conta de serviço, a gestão de identidade e de acesso (IAM) gera entradas de registo. O exemplo seguinte mostra uma entrada de registo para a criação de uma conta de serviço:

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

Registos para a concessão de funções

Esta secção mostra as entradas do registo que recebe quando concede funções relacionadas com contas de serviço.

Registos para conceder a função de utilizador da conta de serviço

Um principal pode obter as mesmas autorizações que uma conta de serviço usando a identidade da conta de serviço. Para permitir que um principal use a identidade de uma conta de serviço, pode conceder a função de utilizador da conta de serviço (roles/iam.serviceAccountUser) ao principal para a conta de serviço.

O exemplo seguinte mostra uma entrada de registo para conceder a função de utilizador da conta de serviço a um principal:

{
  "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.s3ns-system.iam.gserviceaccount.com"
    },
    "resourceName": "projects/-/serviceAccounts/123456789012345678901",
    "response": {
      "@type": "type.googleapis.com/google.iam.v1.Policy",
      "bindings": [
        {
          "members": [
            "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
          ],
          "role": "roles/iam.serviceAccountUser"
        }
      ]
    }
  },
  "resource": {
    "type": "service_account"
  }
}

Quando concede a função de criador de tokens de conta de serviço (roles/iam.serviceAccountTokenCreator), que permite a um principal criar credenciais de curta duração, o IAM gera uma entrada de registo semelhante.

Registos para conceder acesso a uma conta de serviço num recurso

Pode conceder uma função a uma conta de serviço num recurso específico, o que permite à conta de serviço aceder ao recurso. Se o serviço que é proprietário do recurso também suportar o registo de auditoria, a concessão de uma função à conta de serviço gera uma entrada no registo de auditoria. A entrada do registo inclui o campo protoPayload.authenticationInfo.principalEmail, que identifica o principal que concedeu a função à conta de serviço.

O exemplo seguinte mostra uma entrada do registo de auditoria para conceder uma função a uma conta de serviço para um projeto. Neste exemplo, //iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.com concedeu a função de leitor da organização (roles/resourcemanager.organizationViewer) à conta de serviço. O campo protoPayload.serviceName está definido como cloudresourcemanager.googleapis.com, porque o Resource Manager é o Trusted Cloud serviço que gere projetos. Além disso, o campo resource.type está definido como project:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "//iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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.s3ns-system.iam.gserviceaccount.com"
          ],
          "role": "roles/resourcemanager.organizationViewer"
        }
      ]
    },
    "serviceName": "cloudresourcemanager.googleapis.com"
  },
  "resource": {
    "type": "project"
  }
}

Registos para anexar contas de serviço a recursos

Se um utilizador tiver a função Utilizador da conta de serviço (roles/iam.serviceAccountUser) numa conta de serviço, pode anexar a conta de serviço a recursos. Quando o código executado no recurso acede a Trusted Cloud serviços e recursos, usa a conta de serviço anexada ao recurso como a respetiva identidade. Por exemplo, se anexar uma conta de serviço a uma instância do Compute Engine e as aplicações na instância usarem uma biblioteca cliente para chamar Trusted Cloud APIs, essas aplicações usam automaticamente a conta de serviço anexada para autenticação e autorização.

Esta secção mostra alguns dos registos gerados quando anexa uma conta de serviço a um recurso.

Registos da utilização da autorização iam.serviceAccounts.actAs

Anexar uma conta de serviço a um recurso requer a autorização iam.serviceAccounts.actAs. Quando um principal usa esta autorização para anexar uma conta de serviço a um recurso, gera um registo de auditoria.

O exemplo seguinte mostra uma entrada de registo para um principal que usa a autorização iam.serviceAccounts.actAs para anexar uma conta de serviço a uma instância do Compute Engine.

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "//iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.com"
    },
    "serviceName": "iam.googleapis.com",
    "methodName": "iam.serviceAccounts.actAs",
    "authorizationInfo": [
      {
        "resource": "projects/-/serviceAccounts/sample-service-account@sample-project.s3ns-system.iam.gserviceaccount.com",
        "permission": "iam.serviceAccounts.actAs",
        "granted": true,
        "permissionType": "ADMIN_WRITE"
      }
    ],
    "resourceName": "projects/-/serviceAccounts/sample-service-account@sample-project.s3ns-system.iam.gserviceaccount.com",
    "request": {
      "name": "sample-service-account@sample-project.s3ns-system.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"
}

Registos para configurar uma instância do Compute Engine para ser executada como uma conta de serviço

Se um utilizador tiver a função Utilizador da conta de serviço (roles/iam.serviceAccountUser) numa conta de serviço, pode criar uma instância de máquina virtual (VM) do Compute Engine que é executada como essa conta de serviço. Neste cenário, o utilizador cria a instância de VM com as suas próprias credenciais, e o pedido especifica uma conta de serviço para a instância de VM usar.

Quando um utilizador cria uma instância de VM, o Compute Engine cria várias entradas de registo. O exemplo seguinte mostra a primeira entrada do registo, que identifica o utilizador que criou a instância de VM e a conta de serviço que a instância usa. Neste exemplo, o utilizador //iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.com criou uma instância que usa a conta de serviço my-service-account@my-project.s3ns-system.iam.gserviceaccount.com. Como resultado, o campo protoPayload.authenticationInfo.principalEmail está definido como //iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.com e o campo protoPayload.request.serviceAccounts[0].email está definido como my-service-account@my-project.s3ns-system.iam.gserviceaccount.com:

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

Registos de acesso Trusted Cloud com uma chave de conta de serviço

Esta secção mostra as entradas do registo que recebe quando cria uma chave de conta de serviço e, em seguida, usa a chave para aceder ao Trusted Cloud.

Registos para criar uma chave de conta de serviço

Se tiver a função Administrador da chave da conta de serviço (roles/iam.serviceAccountKeyAdmin) numa conta de serviço, pode criar uma chave de conta de serviço e, em seguida, usar a chave para autenticar pedidos aos Trusted Cloud serviços.

O exemplo seguinte mostra uma entrada de registo para a criação de uma chave de conta de serviço. Neste exemplo, o utilizador //iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.comcriou uma chave para a conta de serviçomy-service-account@my-project.s3ns-system.iam.gserviceaccount.com:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "//iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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.s3ns-system.iam.gserviceaccount.com"
    },
    "resourceName": "projects/-/serviceAccounts/123456789012345678901"
  },
  "resource": {
    "type": "service_account"
  }
}

Registos para autenticação com uma chave de conta de serviço

Depois de criar uma chave de conta de serviço, pode usá-la para pedir um token de acesso OAuth 2.0 para uma conta de serviço e, em seguida, usar o token de acesso para autenticar pedidos aos serviços Trusted Cloud . Em geral, os registos de auditoria desses serviços incluem as seguintes informações:

  • protoPayload.authenticationInfo.principalEmail: o endereço de email da conta de serviço que o token de acesso representa.
  • protoPayload.authenticationInfo.serviceAccountKeyName: a chave da conta de serviço que foi usada para pedir a chave de acesso OAuth 2.0. Este campo identifica a chave da conta de serviço pelo respetivo nome do recurso completo, que usa o formato //iam.googleapis.com/projects/project-id/serviceAccounts/service-account-email/keys/key-id.

O exemplo seguinte mostra uma entrada do registo de auditoria para um pedido de criação de uma instância do Memorystore for Redis. O pedido foi autenticado com uma chave de acesso OAuth 2.0 para uma conta de serviço. Neste exemplo, a conta de serviço tem o nome my-service-account@my-project.s3ns-system.iam.gserviceaccount.com e o ID da chave da conta de serviço é 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.s3ns-system.iam.gserviceaccount.com",
      "serviceAccountKeyName": "//iam.googleapis.com/projects/my-project/serviceAccounts/my-service-account@my-project.s3ns-system.iam.gserviceaccount.com/keys/c71e040fb4b71d798ce4baca14e15ab62115aaef"
    },
    "methodName": "google.cloud.redis.v1.CloudRedis.CreateInstance",
    "request": {
      "@type": "type.googleapis.com/google.cloud.redis.v1.CreateInstanceRequest"
    }
  }
}

Registos de utilização da identidade de uma conta de serviço para aceder ao Trusted Cloud

Esta secção mostra as entradas do registo que recebe quando cria credenciais de curta duração para uma conta de serviço e, em seguida, usa as credenciais para se fazer passar pela conta de serviço e aceder a Trusted Cloud.

Registos para criar credenciais de curta duração

Se tiver a função Criador de tokens de contas de serviço (roles/iam.serviceAccountTokenCreator) para uma conta de serviço, pode criar credenciais de curta duração para a conta de serviço e, em seguida, usar as credenciais para usar a identidade da conta de serviço. Por exemplo, pode criar credenciais de curta duração para chamar uma Trusted Cloud API a partir de uma aplicação que não é executada no Trusted Cloud.

A IAM pode gerar registos de auditoria quando os principais criam credenciais de curta duração. Para receber estes registos de auditoria, tem de ativar os registos de auditoria da IAM para a atividade de acesso a dados.

Depois de ativar os registos de auditoria do IAM para a atividade de acesso a dados, o IAM gera uma entrada de registo de auditoria sempre que um principal cria credenciais de curta duração. A entrada inclui os seguintes campos:

  • protoPayload.authenticationInfo.principalEmail: O principal que criou as credenciais de curta duração.
  • resource.labels.email_id: a conta de serviço para a qual foram geradas credenciais de curta duração.

O exemplo seguinte mostra uma entrada do registo de auditoria para um pedido de geração de um token de acesso OAuth 2.0 de curta duração. Neste exemplo, o utilizador //iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.com criou um token de acesso para a conta de serviço my-service-account@my-project.s3ns-system.iam.gserviceaccount.com:

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

Registos para autenticação com credenciais de curta duração

Depois de criar credenciais de curta duração para uma conta de serviço, pode usar as credenciais para se fazer passar pela conta de serviço quando chamar as APIs. Trusted Cloud

Alguns dos métodos que chama podem gerar registos de auditoria. Em geral, estas entradas de registo mostram as seguintes identidades:

  • A conta de serviço que as credenciais de curta duração estão a representar
  • A identidade que criou as credenciais de curta duração

Por exemplo, suponhamos que o utilizador //iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.com cria credenciais de curta duração para a conta de serviço my-service-account@my-project.s3ns-system.iam.gserviceaccount.com. Em seguida, o utilizador cria um novo tópico do Pub/Sub, usando as credenciais de curta duração para se fazer passar pela conta de serviço. O Pub/Sub gera uma entrada de registo que identifica a conta de serviço, bem como o utilizador que está a roubar a identidade da conta de serviço:

{
  "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.s3ns-system.iam.gserviceaccount.com",
      "serviceAccountDelegationInfo": [
        {
          "firstPartyPrincipal": {
            "principalEmail": "//iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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"
  }
}

Registos de ações realizadas por agentes de serviço

Por vezes, quando um principal inicia uma operação, um agente de serviço executa uma ação em nome do principal. No entanto, quando revê os registos de auditoria de um agente de serviço, pode ser difícil saber em nome de quem o agente de serviço estava a agir e porquê.

Para ajudar a compreender o contexto das ações de um agente de serviços, alguns agentes de serviços incluem detalhes adicionais nos respetivos registos de auditoria, como a tarefa à qual a ação está associada e o principal que criou a tarefa.

Os seguintes agentes de serviço incluem estes detalhes adicionais nos respetivos registos de auditoria:

Estes detalhes adicionais encontram-se no campo serviceDelegationHistory do registo de auditoria, que está aninhado no campo authenticationInfo. Este campo contém as seguintes informações:

  • O diretor original que criou a tarefa
  • O agente de serviço que executou a ação
  • O serviço ao qual o agente de serviços pertence
  • O ID do trabalho

Por exemplo, suponhamos que //iam.googleapis.com/locations/global/workforcePools/example-pool/subject/example-user@example.com cria uma tarefa através da API BigQuery Connection. Esta tarefa requer que um dos agentes de serviço da API BigQuery Connection execute uma ação. Neste caso, o registo de auditoria da ação do agente do serviço conteria um campo serviceDelegationHistory semelhante ao seguinte: 

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

O que se segue?