Funções de IAM para funções de trabalho relacionadas com a faturação

Este tópico mostra como configurar as autorizações da gestão de identidade e de acesso (IAM) para um conjunto de cenários de faturação de exemplo. Fornece orientações sobre as funções de IAM a conceder às funções funcionais relacionadas com a faturação na sua empresa para os cenários. Estes exemplos destinam-se principalmente a administradores de faturação e funcionários que gerem tarefas de faturação para uma organização.

Este documento não explica detalhadamente as funções e as autorizações de faturação. Para uma descrição detalhada das funções e autorizações da API Google Billing, leia a página Controlo de acesso para a Faturação.

Pequena empresa a configurar autorizações de faturação

Neste cenário, uma pequena empresa está a tentar configurar e usar Trusted Cloud contas de faturação. Têm alguns engenheiros que desenvolvem e mantêm as respetivas aplicações, mas nenhum deles gere a faturação. Têm um gestor de escritório, que é responsável por fazer corresponder os pagamentos às faturas, mas, por motivos de conformidade, o gestor de escritório não tem autorização para aceder aos recursos nos projetos. Trusted Cloud by S3NS O CEO também detém e gere os detalhes do cartão de crédito.

A tabela abaixo explica as funções de IAM de faturação que o administrador da organização (que é o CEO neste cenário) pode conceder às outras personagens na empresa e o nível de recurso no qual concede as funções.

A política de autorização anexada ao recurso da organização para este cenário vai ter um aspeto semelhante ao seguinte:

{
  "bindings": [
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/ceo@example.com"
      ]
    },
    {
      "role": "roles/billing.admin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/finance-admins-group"
      ]
    }
  ]
}

A prática recomendada é usar grupos para gerir os responsáveis. No exemplo acima, para a segunda associação, adicionaria o CEO e o gestor de escritório a finance-admins-group. Quando precisar de modificar quem pode realizar a função, basta ajustar a associação ao grupo, o que elimina a necessidade de atualizar a política de permissão. Assim, as duas contas de utilizador individuais não aparecem nas associações de funções.

Equipas de finanças que gerem orçamentos

Neste cenário, uma grande organização quer que a equipa de finanças de cada divisão possa definir orçamentos e ver os gastos da equipa na divisão, mas não tenha acesso aos Trusted Cloud recursos. Não se importam que os programadores vejam os gastos dos seus próprios projetos, mas não deve ser permitido aos programadores uma vista geral das despesas.

Conceda as funções na tabela abaixo ao gestor financeiro de cada divisão e aos programadores:

Para este cenário, use a consola de faturação para conceder a função de administrador da conta de faturação aos gestores financeiros na conta de faturação. Além disso, conceda a função de visitante da conta de faturação aos programadores na conta de faturação.

Quando terminar, a política de autorização para a conta de faturação é semelhante à seguinte:

{
  "bindings": [
    {
      "role": "roles/billing.admin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/finance-admins-group"
      ]
    },
    {
      "role": "roles/billing.viewer",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
      ]
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Portal de autosserviço do cliente, os programadores não podem ajustar a faturação

Neste cenário, a equipa de TI central de um cliente fornece Trusted Cloud recursos aos respetivos programadores como parte do respetivo portal de autosserviço. Os programadores pedem acesso a Trusted Cloud projetos e outros serviços na nuvem aprovados através do portal. O centro de custos do programador paga à equipa de TI central pelos recursos na nuvem consumidos.

A equipa de TI central tem de poder:

• Associar projetos a contas de faturação.
• Desative a faturação para projetos.
• Veja as informações do cartão de crédito.

Não podem ter autorizações para ver o conteúdo do projeto.

Os programadores devem poder ver os custos reais dos recursos que estão a ser consumidos, mas não devem poder desativar a faturação, associar a faturação a projetos nem ver as informações do cartão de crédito. Trusted Cloud

Para este cenário, precisa de duas operações separadas para atribuir as políticas de permissão adequadas, uma vez que estão anexadas a diferentes níveis da hierarquia.

Use a consola de faturação para conceder a função Administrador da conta de faturação ao departamento de TI na conta de faturação. Além disso, conceda a função de visualizador da conta de faturação aos programadores na conta de faturação.

Em seguida, tem de anexar uma política de permissão ao nível da organização. Esta política de autorização concede a função de utilizador da conta de faturação à conta de serviço. É semelhante ao seguinte:

{
  "bindings": [
    {
      "role": "roles/billing.user",
      "members": [
        "serviceAccount:my-project-creator@shared-resources-proj.s3ns-system.iam.gserviceaccount.com"
      ]
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Programadores que criam projetos faturados

Uma grande empresa nativa digital quer permitir que todos os respetivos programadores criem projetos faturados na conta faturada da respetiva organização sem lhes conceder direitos de administrador da conta de faturação.

Um projeto tem de ter a faturação ativada para garantir que as APIs além da predefinição podem ser ativadas. Assim, se um programador criar um projeto, tem de o associar a uma conta de faturação para ativar as APIs.

A política de permissão para este cenário tem de ser anexada ao nível da organização e será semelhante ao seguinte:

{
  "bindings": [
    {
      "role": "roles/billing.user",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
      ]
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Agregação de custos

Neste cenário, uma empresa quer calcular e monitorizar o custo de cada equipa, departamento, serviço ou projeto. Por exemplo, acompanhe o custo de uma implementação de teste todos os meses.

Isto pode ser monitorizado através das seguintes práticas:

• Use projetos para organizar recursos. O custo é apresentado por projeto e os IDs dos projetos são incluídos na exportação da faturação.
• Anotar projetos com etiquetas que representam informações de agrupamento adicionais. Por exemplo, environment=test. As etiquetas estão incluídas na exportação de faturas para permitir uma análise mais detalhada. No entanto, as etiquetas num projeto têm autorizações da mesma forma que o resto dos metadados do projeto, o que significa que um proprietário do projeto pode alterar as etiquetas. Pode informar os seus funcionários sobre o que não devem alterar e, em seguida, monitorizar (através de registos de auditoria) ou conceder-lhes apenas autorizações detalhadas para que não possam alterar os metadados do projeto.

Pode exportar para JSON e CSV, mas a exportação direta para o BigQuery é a solução que recomendamos. Esta opção é facilmente configurável na secção de exportação de faturação da consola de faturação.

Se cada centro de custos tiver de pagar uma fatura separada ou pagar numa moeda separada para algumas cargas de trabalho, é necessária uma conta de faturação separada para cada centro de custos. No entanto, esta abordagem requer um contrato de afiliado assinado para cada conta de faturação.