Práticas recomendadas para organizações empresariais

Aprenda conceitos fundamentais e práticas recomendadas para tirar o máximo do Google Cloud Platform em uma empresa. Este guia abrange tópicos não funcionais relevantes para organizações de tamanho empresarial.

O guia está organizado nas seguintes seções:

Projetos e acesso

Projetos são o principal componente organizacional do Google Cloud Platform. Eles fornecem um agrupamento abstrato que você pode usar para associar recursos a uma equipe funcional ou um departamento específico. Todos os recursos do Cloud Platform pertencem a um projeto. É possível gerenciá-lo com o Console do Google Cloud Platform e com a Resource Manager API. A Cloud IAM API inclui um conjunto de métodos para gerenciar permissões de projetos por meio da Resource Manager API.

Usar projetos para controlar o acesso aos recursos

Os projetos fornecem um limite de isolamento, exceto quando as interconexões são explicitamente concedidas, entre os recursos do Cloud Platform usados ​​pela organização. Os usuários e os grupos podem receber diferentes papéis, como viewer, editor e owner, para diferentes projetos. Para atribuir papéis, use a página IAM e administrador no Console do GCP ou a Cloud IAM API. Atualmente, não é possível criar papéis personalizados e atribuir permissões a eles na API.

Também é possível delegar o controle sobre quem tem acesso a um projeto específico. Os usuários com papel owner podem conceder e revogar o acesso de usuários, grupos e contas de serviço.

Qualquer conta do Google pode ter acesso a um projeto

Você pode conceder acesso a um projeto a qualquer conta do Google, como uma conta do Gmail. Qualquer conta do Google também pode ter acesso por pertencer a um grupo que tenha acesso ao projeto. Esse recurso pode ser útil porque permite que você dê acesso rapidamente a terceiros, como contratados. No entanto, a organização talvez não queira permitir essa flexibilidade, de acordo com as políticas de segurança dela. Você pode gerenciar esse risco com a Cloud IAM API, e pode usá-la para criar uma funcionalidade de monitoramento que procura por atribuições que estão fora da política e dispara um alerta ou as revoga automaticamente.

Os projetos são identificados por identificadores universalmente únicos

Cada projeto tem um código de projeto universalmente único, que é uma string curta de letras minúsculas, dígitos e traços e um número de projeto. Ao criar um projeto, você pode especificar o código dele. O Google atribui o número do projeto automaticamente. Depois que o código e o número do projeto são criados, não podem ser alterados.

Recomendamos que você passe algum tempo planejando os códigos de projeto para facilitar o gerenciamento. Uma convenção típica de nomenclatura de código do projeto pode usar o seguinte padrão:

[company tag]-[group tag]-[system name]-[environment (dev, test, uat, stage, prod)]

Por exemplo, o ambiente de desenvolvimento para o sistema de remuneração do departamento de recursos humanos pode ser denominado acmeco-hr-comp-dev.

Você pode fornecer um nome de projeto legível. Esses nomes não precisam ser globalmente únicos e podem ser editados. Os códigos de projeto podem ter de 6 a 30 caracteres, enquanto os nomes dos projetos podem ter de 4 a 30 caracteres.

Os projetos facilitam o custo preciso

O Google organiza a fatura, incluindo a versão em CSV ou JSON exportável, por projeto. O projeto forma o agrupamento de nível superior da fatura. Há mais detalhamentos dentro desse agrupamento por SKU, mas o agrupamento de projetos de nível superior oferece excelente visibilidade sobre o custo geral de um grupo de recursos de computação e rede.

Para entender o conteúdo do arquivo de faturamento exportável, consulte Exportar dados de faturamento.

O acesso entre projetos é possível, mas precisa ser explicitamente permitido

Como usuários e grupos, as contas de serviço podem receber acesso a vários projetos. Esse acesso entre projetos possibilita que processos em um projeto acessem diretamente recursos dentro de outro.

Quando uma conta de serviço do projeto A acessa um recurso no projeto B, os custos são atribuídos ao projeto que possui os recursos, neste caso, o B.

A exceção a essa regra é quando você executa consultas no Google BigQuery. Se, a partir do projeto B, um usuário ou uma conta de serviço consulta dados do BigQuery armazenados no projeto A, os custos de consulta são cobrados pelo projeto que originou a consulta, ou seja, o B. No entanto, os custos de armazenamento de dados permanecem com o projeto A. Essa abordagem facilita o entendimento de como diferentes grupos estão utilizando o BigQuery para análise de dados.

Cada projeto pertence a uma conta de faturamento específica

As contas de faturamento são um recurso aplicável a toda a organização que só pode ser editado por administradores de faturamento. Esses administradores são gerenciados na página Faturamento do Console do GCP. Cada projeto está associado a exatamente uma conta de faturamento. Os projetos só podem ser associados a uma conta de faturamento por um usuário que é tanto o proprietário de projeto quanto o administrador de faturamento. As faturas e as cobranças de suporte estão associadas a uma única conta de faturamento.

Os projetos não são baseados em regiões geográficas nem equivalentes a zonas

Um projeto é um agrupamento lógico de recursos que não corresponde a uma determinada região geográfica. Da mesma forma, um projeto não representa uma zona de disponibilidade. Os recursos em um determinado projeto podem existir em várias regiões geográficas e em zonas diferentes.

Por exemplo, o projeto A pode conter recursos no centro dos EUA, na Europa e na Ásia, cada um com várias zonas, enquanto o projeto B pode conter recursos apenas na Europa, também com várias zonas.

Não é necessário definir uma região geográfica ou zona ao criar um projeto. A única exceção a esta regra está no Google App Engine. Os aplicativos do App Engine sempre têm uma localização geográfica. Ao criar um novo projeto, você pode alterar o local do App Engine a partir do local padrão. Observe que, após a criação de um projeto, determinados recursos podem ser fixados em locais geográficos específicos. Esse conceito é explicado em maiores detalhes nas próximas seções.

Autenticação e identidade

Esta seção oferece práticas recomendadas para criação e gerenciamento de autenticação e identidades no Google Cloud Platform.

Usar credenciais de login corporativo

O Google Cloud Platform usa Contas do Google para gerenciamento de acesso e autenticação. O Google recomenda o uso de contas corporativas totalmente gerenciadas para melhor visibilidade, auditoria e controle sobre o acesso aos recursos do Cloud Platform.

O Cloud Identity oferece Contas do Google gratuitas e gerenciadas que podem ser usadas com serviços do Google, incluindo o Cloud Platform. Com uma conta do Cloud Identity para cada um dos usuários, é possível gerenciá-los em todo o domínio, por meio do Google Admin Console.

Se você é um administrador do G Suite, gerencie os usuários e as configurações por meio do G Suite Admin console. Por padrão, os novos usuários recebem uma licença do G Suite. Se você tiver um subconjunto de desenvolvedores que não precisem de licenças do G Suite, adicione contas do Cloud Identity.

Para mais informações, consulte Primeiros passos com Cloud Identity.

Provisionar usuários com o diretório do Google

O diretório global do G Suite oferece um armazenamento de dados estruturado de usuários e grupos usado ​​para autenticação e autorização. Ele está disponível para os recursos do Cloud Platform e do G Suite e pode ser provisionado por vários meios. Os usuários provisionados podem aproveitar os recursos de autenticação avançados, que incluem logon único (SSO, na sigla em inglês), OAuth e verificação de dois fatores.

Você pode provisionar usuários automaticamente usando uma das seguintes ferramentas e serviços:

O GCDS é um conector que pode provisionar usuários e grupos em seu nome para o Cloud Platform e o G Suite. Usando o GCDS, você pode automatizar a adição, modificação e exclusão de contatos que não são funcionários, usuários e grupos. Você pode sincronizar os dados do servidor do diretório LDAP com o domínio do Cloud Platform ao usar consultas LDAP. Essa sincronização é unidirecional: os dados no servidor do diretório LDAP nunca são modificados.

O GCDS é executado dentro da rede em uma máquina que você controla. Ele se conecta ao servidor LDAP dentro da rede por meio do LDAP padrão ou LDAP seguro além do Secure Sockets Layer (SSL, na sigla em inglês). Essa conexão ocorre em qualquer porta que você especificar, mas o padrão são as portas LDAP padrão. O GCDS se conecta ao domínio do G Suite pela Internet por meio de HTTPS na porta 443. Essa conexão também pode ser executada por meio de um host proxy na rede.

Se você preferir criar sua própria solução para provisionar usuários e grupos, pode usar o Google Admin SDK. Ele fornece métodos para gerenciar usuários do Cloud Platform e as associações deles com grupos e organizações. O SDK é compatível com pontos de extremidade HTTPS REST e também fornece Python, Java, .NET e outras bibliotecas de cliente.

Além dessas ferramentas e serviços nativos, muitos dos principais fornecedores de gerenciamento de identidade oferecem conectores para o diretório global do G Suite. Esses conectores normalmente provisionam os usuários do G Suite e as associações deles com grupos e organizações por meio do uso da Directory API do Google Admin SDK. Como o Cloud Platform e o G Suite compartilham uma infraestrutura de diretório comum, esses conectores são aplicáveis aos dois.

Para provisionar os usuários manualmente para testes ou outros fins, os administradores do Cloud Platform podem provisionar usuários e as associações deles com grupos e organizações manualmente usando o G Suite Admin Console.

Para saber mais sobre o diretório global do G Suite, consulte Gerenciar o diretório global.

Resolver contas conflitantes durante o provisionamento de usuários

Se os membros do domínio tiverem usado os endereços de e-mail corporativos deles para criar uma Conta do Google pessoal, por exemplo, para se inscrever em um serviço do Google, como YouTube ou Blogger, essas contas gerarão conflitos ao serem adicionadas ao G Suite ou ao Cloud Platform. As autorizações para as contas existentes precisam ser revogadas manualmente e transferidas para as novas contas de usuário.

Para conseguir orientação sobre como evitar e resolver problemas com contas conflitantes, consulte Resolver contas conflitantes.

Definir papéis de administração de domínio

Quando um projeto é associado a um domínio, um novo papel chamado Superusuário é criado. O papel Superusuário aplica-se ao próprio domínio. Use um dos papéis predefinidos ou crie um papel personalizado e defina o escopo de gerenciamento dele:

  • Usuários: organização, que é um subconjunto de usuários, ou global.
  • Privilégios: como gerenciamento de grupo ou gerenciamento de segurança.

Esses papéis podem ser gerenciados por meio do Admin Console ou da Roles API. Para mais informações sobre esses papéis, consulte Sobre papéis de administrador.

Implementar SSO com troca de SAML

O Cloud Platform é compatível com SSO baseado em SAML 2.0, que fornece SSO contínuo diante dos prompts de autorização do OAuth, da SSH baseada na Web e em linha de comando e do Cloud Platform Console. As ferramentas de interface de linha de comando do Cloud Platform, como gcloud, gsutil e bq, também usam o SSO baseado em SAML 2.0 para autenticação baseada em navegador.

Se o usuário acessar qualquer uma dessas ferramentas sem ter previamente autenticado diante do provedor de SSO, seja diretamente ou seja acessando outro aplicativo, ele será solicitado a inserir o nome de usuário, mas não a senha. Esta etapa ajuda a infraestrutura de autenticação do Google a determinar o domínio para o qual o usuário deseja ser autenticado.

Para informações sobre a configuração do SSO do Google, consulte Configurar o logon único em contas do G Suite. Este guia se aplica tanto ao Cloud Platform quanto ao G Suite, pois ambos os produtos compartilham diretório, autenticação e infraestrutura de SSO em comum.

Considerar o uso do Google como um provedor de identidade para outros serviços

Você pode migrar para uma solução de autenticação 100% baseada em nuvem por meio da autenticação de seus próprios aplicativos com o OpenID Connect do Google e com o uso do Google como um provedor de identidade SAML 2.0 para autenticar aplicativos comerciais e prontos para uso.

O Google e terceiros oferecem bibliotecas que podem ser usadas para cuidar de muitos detalhes de implementação do uso do OpenID Connect para autenticar usuários. Você pode aproveitar o Google como o provedor de identidade SAML 2.0 em vez de usar um diretório de terceiros, como o Microsoft Active Directory. O G Suite é compatível com mais de 15 provedores SaaS populares. Os parceiros de identidade recomendados do G Suite incluem Ping e Okta. Você também pode adicionar novas integrações de aplicativo SAML personalizadas.

A utilização do Google como provedor de identidade permite que você aproveite a avançada infraestrutura de autenticação do Google, incluindo autenticação de dois fatores e dispositivos de chave de segurança FIDO U2F.

Atribuir papéis de projeto a grupos de usuários

Você pode usar os Grupos do Google para gerenciar a autorização de projetos em uma grande organização. Se você já está familiarizado com o Controle de acesso baseado em papéis (RBAC, na sigla em inglês), pode pensar que os Grupos do Google são análogos aos papéis do RBAC, enquanto os papéis de projeto no Cloud Platform são análogos às permissões do RBAC. Você pode atribuir papéis de projeto a grupos de maneira semelhante à qual os atribui a usuários, e pode gerenciar a associação de grupos como descrito anteriormente.

Autorizar interações servidor-servidor com contas de serviço

Como usuários, as contas de serviço podem receber autorização para recursos específicos, com o uso de técnicas semelhantes. Exemplos incluem conceder a um aplicativo a capacidade de ler e gravar em intervalos do Google Cloud Storage ou de acessar conjuntos de dados específicos no BigQuery. As contas de serviço são úteis para executar processos automatizados porque são autenticadas com uma chave privada e não com uma senha.

Delegar autorização de aplicativos com OAuth2

As APIs do Cloud Platform são compatíveis com OAuth 2.0, e os escopos fornecem autorização granular sobre os métodos compatíveis. O Cloud Platform é compatível com OAuth de conta de serviço e de conta de usuário, também chamado de OAuth de três pernas.

Normalmente, o OAuth 2.0 é usado para autorizar aplicativos da Web. Ele também tem um modo de aplicativos instalados que é compatível com aplicativos de desktop.

O Cloud Platform é compatível com Application Default Credentials, ideal para o acesso a APIs independente de usuário, por exemplo, quando todos têm acesso aos mesmos dados. Para as operações executadas em um terminal de linha de comando, basta autorizar o acesso a APIs da ferramenta de linha de comando gcloud em nome da conta de usuário ou de uma conta de serviço. Essas credenciais também podem ser usadas pelo gsutil

Verificar a identidade da instância antes de transmitir dados

Com as instâncias, é possível gerar um token da Web JSON (JWT) com detalhes sobre a instância e a assinatura RS256 do Google. Nos aplicativos, a assinatura é verificada em relação aos certificados Oauth2 públicos do Google, para confirmar a identidade da instância que estabeleceu uma conexão com esses aplicativos.

Leia Como verificar a identidade de instâncias para aprender a solicitar e verificar tokens de instância assinados.

Rede e segurança

Usar projetos para isolar completamente os recursos

O Google usa uma rede definida por software que possibilita submeter todos os pacotes a verificações de segurança, permitindo assim o isolamento completo dos projetos do Cloud Platform. Você pode ler mais sobre redes definidas por software nos centros de dados do Google no blog do Cloud Platform.

Você pode ler mais sobre segurança na página Segurança do Google Cloud Platform.

Usar redes dentro de projetos para isolar grupos de instâncias de VM

Cada projeto é compatível com até cinco redes isoladas. Cada rede constitui um espaço de endereço IP global. Isso significa que você pode criar recursos, como instâncias de máquina virtual (VM, na sigla em inglês) do Google Compute Engine, em várias regiões geográficas e os recursos compartilharão o mesmo espaço de endereço IP porque estão na mesma rede virtual. Observe que, apesar do espaço de endereço de rede simples, ainda há cobranças de saída normais quando você sai da zona. Para mais informações, consulte Preços da rede.

Você pode solicitar um aumento de cota para compatibilidade com até 15 redes isoladas em cada projeto.

Aproveitar o DNS local da rede

Cada rede é compatível com um servidor de nomes de domínio (DNS, na sigla em inglês) local que permite que as instâncias de VM se encontrem de maneira rápida e fácil, por nome. Semelhante ao espaço de endereço global, esse DNS local opera em toda a rede, independentemente da região ou da zona da instância de VM que utiliza o serviço.

Um firewall virtual e rotas controlam todo o acesso à rede

O Cloud Platform utiliza uma rede definida por software que oferece muita flexibilidade em dispositivos virtuais. Você pode criar regras de firewall para controlar o tráfego de entrada para instâncias e balanceadores de carga, tanto da Internet pública quanto de outras instâncias da mesma rede. Você pode aplicar regras de firewall a tags de instância específicas. Por exemplo, você pode criar uma regra de firewall que se aplique dinamicamente a um conjunto de instâncias marcadas com a mesma tag, o que facilita muito o escalonamento automático de clusters.

As rotas são igualmente flexíveis. Você estabelece as rotas para a rede que definem como as instâncias de VM direcionam o tráfego a outras instâncias na mesma rede, bem como recursos externos. As rotas também podem ser aplicadas a tags de instância específicas, permitindo que você configure regras que podem ser aplicadas dinamicamente a instâncias à medida que elas vão e vêm.

Usar iptables e rotas para limitar ou filtrar o tráfego de saída

Enquanto as regras de firewall do Cloud Platform podem controlar o tráfego de entrada para as instâncias de VM, as rotas de rede podem controlar a saída de VMs para intervalos de endereços IP. Nos exemplos, estão incluídos o roteamento de todo o tráfego externo por meio de um gateway NAT, todo o tráfego para intervalos de IP corporativo por meio de um gateway VPN ou a negação de acesso a intervalos de IP por roteamento para um IP inexistente. Se você precisar de controle sobre o tráfego de saída a partir das instâncias de VM para portas específicas como a filtragem de todo o tráfego pela porta 80, configure o iptables ou outro mecanismo de filtragem baseado em host na instância.

As instâncias de VM têm um endereço IP interno e podem ter um endereço IP público

Cada instância VM recebe um endereço interno que corresponde ao espaço de endereço de rede no qual foi criada. Esse endereço pode ser usado para tráfego entre instâncias na mesma rede. Como opção, você pode anexar um endereço IP público externo a uma VM. Ele pode ser efêmero ou, por uma taxa, estático. Você é cobrado por um endereço IP estático reservado quando a instância de VM não está sendo executada e também quando o IP não está associado a nenhuma instância de VM.

A cota padrão inclui a disponibilidade de um pequeno número de endereços IP externos: 23 efêmeros e sete estáticos, por região. Com um aumento de cota, você pode aumentar o número de endereços IP externos efêmeros para 500 por região. Se você precisar de mais endereços IP externos do que as cotas oferecem, entre em contato com o suporte do Cloud ou com o gerente técnico de contas para discutir as necessidades.

As instâncias de VM exigem um endereço IP público para acessar os serviços do Cloud Platform

Para acessar recursos da Internet, incluindo APIs do Cloud Platform e outros serviços, cada uma das instâncias de VM precisa de um endereço IP externo. Embora essa prática possa gerar algumas preocupações, recomendamos que você limite o tráfego de entrada para essas instâncias de VM usando regras de firewall.

Se a política de segurança exigir instâncias de VM verdadeiramente internas, você precisará configurar manualmente um proxy NAT na rede e um caminho correspondente para que as instâncias internas possam acessar a Internet. É importante notar que você não pode se conectar de maneira direta a uma instância de VM totalmente interna usando SSH. Para se conectar a essas máquinas internas, é preciso configurar uma instância bastion que tenha um endereço IP externo e, em seguida, usar um túnel por ele. Para mais informações, consulte hosts Bastion.

Colocar determinados recursos em regiões e zonas para menor latência e recuperação de desastres

Uma região representa uma região geográfica ou, mais especificamente, o local de um campus de data center. Dentro de uma região, há várias zonas que são zonas de disponibilidade em relação à infraestrutura subjacente. Alguns recursos do Cloud Platform são globais, mas outros podem ser fixados em regiões específicas ou, em alguns casos, em zonas específicas. Instâncias de VM, discos permanentes, intervalos do Cloud Storage, aplicativos do App Engine, Cloud Bigtable, Cloud Dataproc, conjuntos de dados do BigQuery, Cloud VPN e alguns outros recursos podem ser criados em uma região geográfica específica.

Aproveite as regiões e zonas para conseguir redundância de serviço apropriada ou minimizar a latência considerando a região geográfica.

Usar o Cloud VPN para conectar redes remotas com segurança

O Google Cloud VPN é uma ferramenta flexível que pode ser usada para conectar redes remotas de maneira segura, inclusive entre o Cloud Platform e uma rede local, duas redes em projetos diferentes ou duas redes no mesmo projeto. Os túneis do Cloud VPN são faturados a uma taxa mensal estática mais cobranças de saída padrão. Observe que a conexão de duas redes no mesmo projeto ainda gera cobranças de saída padrão.

Usando tags de instância em rotas, você pode controlar dinamicamente quais instâncias de VM podem enviar tráfego pela VPN.

Verificar vulnerabilidades comuns em websites

Detecte vulnerabilidades comuns em websites com o Google Cloud Security Scanner. Essa ferramenta digitaliza os aplicativos do App Engine para scripts entre sites e questões de conteúdo misto.

Como acontece com todos os verificadores de vulnerabilidade dinâmicos, uma verificação sem ocorrências não garante que o site seja seguro. Você ainda precisa realizar uma análise de segurança manual.

O Cloud Router pode adicionar rotas dinamicamente ao Cloud VPN

O Cloud VPN, embora flexível, ainda exige que os intervalos de endereços IP sejam estaticamente adicionados e removidos de e para túneis. O Google Cloud Router alivia essa limitação ao aproveitar o Border Gateway Protocol (BGP, na sigla em inglês) para atualizar os túneis dinamicamente.

Uma rede pode ser dividida em sub-redes

As sub-redes no Compute Engine permitem que você controle o espaço de endereço no qual as instâncias de VM são criadas, além de manter a capacidade de rota entre elas. As sub-redes podem ser qualquer intervalo IP não público, o que significa que elas não precisam pertencer a uma rede principal e comum. As sub-redes dentro de um agrupamento em rede particular podem alcançar umas às outras.

Você pode conseguir maior isolamento entre as sub-redes usando regras e rotas de firewall.

Registro, monitoramento e auditoria

Para reconhecer ameaças e reduzir riscos, monitore o acesso e o uso da conta e dos recursos do sistema. O Cloud Platform tem um conjunto muito avançado de ferramentas de monitoramento e alerta que podem ser uma parte importante da solução global.

Usar o Cloud Logging como um local centralizado para registros

O Google Cloud Logging oferece um local generalizado e centralizado para registros. Os registros das instâncias de VM, do App Engine e dos serviços gerenciados aparecem automaticamente nessa área de geração de registros centralizada. Você também pode enviar outros registros arbitrários ao Cloud Logging. Use esse recurso para coletar todos os registros do sistema e do aplicativo juntos em um só lugar e, assim, facilitar a análise e o monitoramento.

Monitorar o acesso dos recursos do sistema

Para monitorar como os recursos do sistema são acessados, monitore os seguintes itens:

  • Modificações de recursos do Compute Engine, como criação e exclusão de instâncias e discos, alteração de regras de firewall e configuração do balanceamento de carga e do escalonamento automático usando a RegionOperations API.

  • solicitações de informações do Compute Engine como invocações instance/get com o uso de Registros de atividades

  • Registros de aplicativo do Compute Engine e tentativas de autenticação usando o Google Cloud Logging Agent.

  • Tráfego de gateway para gateway de VPN, incluindo endereços IP e de origem, usando o registro da rede privada.

  • Consultas do BigQuery e operações de tabela, conjunto de dados e visualização usando a BigQuery API.

  • Acesso a objetos do Cloud Storage usando os registros de acesso do Cloud Storage.

  • Implementações do App Engine, promoções da versão, cron, índice, fila ou outras alterações de configuração usando os registros do administrador do App Engine.

  • Operações do Cloud SQL usando o método operations.list do Cloud SQL.

  • Operações do Google Cloud Deployment Manager usando a Deployment Manager API.

Monitorar acesso à conta

Monitore todas as tentativas de acesso à conta de domínio usando a Reports API e o registro de auditoria de login no Admin Console.

Monitorar ações administrativas

Monitore as alterações de papéis do projeto usando a IAM API. Monitore todas as operações realizadas no Admin Console do domínio com o Registro de auditoria do Admin Console.

Exportar registros para o BigQuery para análise e armazenamento de longo prazo

O BigQuery é uma excelente ferramenta para analisar rapidamente grandes quantidades de dados. O BigQuery também é uma maneira muito econômica de armazenar dados para análise. Você pode configurar o Cloud Logging para exportar registros diretamente para o BigQuery, o que oferece uma poderosa ferramenta para realizar análises detalhadas para identificar tendências nos registros.

Impedir alterações não desejadas nos registros

Os registros são armazenados no Cloud Storage no projeto de origem. Por padrão, os proprietários e editores do projeto têm permissões de propriedade para todos os intervalos do Cloud Storage no projeto e os objetos sob o modelo de permissões hierárquicas do intervalo.

Para minimizar o risco de alterações acidentais ou mal-intencionadas nos registros, aplique os seguintes princípios.

Menor privilégio

Conceda as permissões menos amplas que são necessárias para fazer o job. Restrinja o uso do papel owner a projetos e intervalos de registro. A finalidade do papel owner é o gerenciamento da associação à equipe, a autorização e assim por diante.

Os membros da equipe com o papel editor ainda podem implantar aplicativos e modificar ou configurar os recursos deles.

Você pode oferecer acesso gerenciado a intervalos e objetos a uma população mais ampla por meio de um aplicativo personalizado que usa a Cloud Storage API com uma conta de serviço dedicada e depois adicionar auditoria no aplicativo.

Não repúdio

O Cloud Storage criptografa automaticamente todos os dados antes de eles serem gravados no disco. Você pode oferecer garantia adicional de não repúdio por meio da implementação do controle de versão de objetos nos intervalos de registro. Quando um objeto é sobrescrito ou excluído em um intervalo, uma cópia dele é salva automaticamente com as propriedades de geração que o identificam. Infelizmente, esse recurso não pode proteger contra um proprietário de projeto que exclui o objeto arquivado ou desativa o controle de versão.

Separação de deveres

É possível oferecer garantia adicional de separação de deveres. Por exemplo, você pode exigir que duas pessoas inspecionem e assinem os registros. Para copiar os intervalos de registro para um projeto que tenha um proprietário diferente, use gsutil cp como parte de um cron job frequente ou, se a quantidade de dados copiados for maior do que 10 TB de dados de registro por vez, use o serviço de transferência do Cloud Storage. Essa abordagem não consegue proteger contra um proprietário do projeto que exclui o intervalo original antes que a cópia ocorra ou que desative a geração de registros original.

Essa abordagem faz cópias baseadas em nuvem sem copiar para a máquina local, por isso é rápida e eficiente. A entrada ou saída de rede de cópias dentro de uma região não é cobrada, mas há cobranças de operações pelo processo de cópia.

Para reduzir os custos de armazenamento da duplicação de registros, copie os objetos para o Nearline Storage, implemente o gerenciamento do ciclo de vida do objeto nos objetos de intervalo de origem e remova-os depois de verificar se eles foram replicados para o projeto de backup, talvez semanalmente.

Usar Stackdriver Monitoring para monitorar recursos e fornecer alertas

Use o Stackdriver Monitoring para monitorar vários recursos como instâncias de VM, App Engine e Cloud Pub/Sub. Várias integrações de monitoramento são fornecidas automaticamente, e você só precisa configurar limites para os alertas.

O Cloud Platform também oferece a capacidade de detectar entradas de registro específicas e criar métricas personalizadas para esses itens.

Unificar todas as necessidades de registro e monitoramento usando o Cloud Platform

Com o Stackdriver Monitoring, você envia métricas de monitoramento de máquinas virtuais localizadas fora do Cloud Platform. É possível usar um agente instalável que informe e alerte sobre todos os recursos em um único painel, incluindo os que estão no local e em outras nuvens.

Usar a página Atividade para ver a atividade nos projetos da organização

Na página Atividade do Console do GCP, você encontra um fluxo de atividades de toda a organização, em todos os projetos. Ela pode ser filtrada por um ou mais projetos, tipos de atividade e período para que você se concentre rapidamente nas alterações ou nos ajustes. Um conjunto básico de produtos é compatível com o fluxo de atividades hoje, e outros serão adicionados ao longo do tempo.

Suporte e treinamento

Os aplicativos de produção devem ter pelo menos suporte Gold

Um pacote de suporte é adquirido para toda a organização. Embora haja um espectro de pacotes de suporte disponíveis, recomendamos os pacotes Gold e Platinum para cuidar de problemas críticos dos projetos em produção em tempo hábil.

A comunidade é uma excelente fonte de apoio

Os funcionários do Google apoiam e incentivam ativamente a comunidade de usuários. Para conseguir uma lista de locais comuns da comunidade em que é possível encontrar informações detalhadas sobre o Cloud Platform, consulte Juntar-se a uma comunidade do Google Cloud Platform.

O treinamento introdutório e avançado ajudará a evitar armadilhas comuns

O Google oferece treinamento de qualificação para o Cloud Platform, que vai desde visões gerais introdutórias de alto nível até sessões detalhadas sobre tecnologias específicas. Você pode encontrar uma aula no website do Google Cloud Platform.

Recomendamos que pelo menos as pessoas-chave na organização sejam qualificadas no Cloud Platform. O curso CPO200: Google Cloud Platform para profissionais de operações de sistemas é particularmente útil para pessoas que implantam e gerenciam aplicativos do Compute Engine.

Construir centros de excelência internos para produtos

O Cloud Platform oferece um extenso conjunto de produtos, serviços e APIs que podem ser combinados de maneiras criativas e inesperadas. O Google continua a investir nesses produtos, e novos recursos estão sendo continuamente lançados. Pode ser valioso capturar as informações, a experiência e os padrões da organização em uma base de conhecimento interna, como em um wiki, site do Google ou site de intranet.

No wiki, inclua uma lista de especialistas em produtos que podem aconselhar novos usuários e ajudá-los a usar determinados produtos do Cloud Platform de acordo com as práticas recomendadas da organização.

Estabelecer uma câmara de compensação interna

Há um número máximo de pessoas que você pode autorizar para enviar tíquetes de suporte em nome da organização. Recomendamos que você configure uma câmara de compensação de suporte interna ou uma mesa de triagem. Essa abordagem ajuda a evitar a duplicação de tíquetes e falhas de comunicação, além de manter a comunicação com o suporte do Google Cloud a mais clara possível.

Aproveitar os parceiros do Google

Às vezes, pode ser necessário complementar a experiência e a capacidade da organização com ajuda de fora. O Google construiu um avançado ecossistema de parceiros que pode ajudar a preencher essas lacunas. Para mais informações sobre parceiros, consulte Parceiros do Google Cloud Platform.

Acompanhar as notícias e os anúncios mais recentes do Cloud Platform

Mantenha-se atualizado sobre as notícias, os anúncios e as histórias de clientes mais recentes ao se inscrever no blog do Google Cloud Platform.

Faturamento e atribuição de custos

A fatura mensal divide os custos por projeto e, depois, por tipo de recurso

A fatura mensal é entregue por e-mail aos administradores de faturamento. Ela contém muitos detalhes. Lembre-se de que a fatura divide o uso de recursos primeiro por projeto e, depois, por tipo de recurso. A nomeação cuidadosa dos projetos torna muito fácil ver quais equipes ou produtos estão consumindo recursos. Você pode usar essas informações para facilitar os reembolsos cobrados desses departamentos na organização.

Usar a exportação de faturamento diariamente para conseguir uma versão da fatura o computador consegue ler

Você pode ativar o recurso de exportação de faturamento para publicar o equivalente aos itens de linha da fatura detalhados por dia. Esse arquivo pode ser formatado como JSON ou CSV e publicado em um intervalo do Cloud Storage. Esses dados brutos facilitam a geração de relatórios diários sobre o uso e os custos do Cloud Platform. Ative a exportação de faturamento na área de administração Conta de faturamento do Console do GCP.

Usar marcadores de projeto para categorizar ainda mais os projetos na exportação de faturamento

No Console GCP, na página Projetos, é possível adicionar marcadores personalizados a projetos como pares de chave-valor. Esses marcadores aparecem no arquivo de exportação de faturamento. Aplique esses rótulos para permitir a categorização maior de projetos.

Os créditos são aplicados a uma conta de faturamento, e não a um projeto específico

Se você receber créditos, como por um reembolso ou por motivos promocionais, eles serão aplicados à conta de faturamento, e não a um projeto específico. Isso significa que todos os projetos usam o conjunto de créditos até que eles sejam consumidos, o que pode tornar o cálculo exato dos custos um pouco mais desafiador. No entanto, os créditos geralmente não são aplicados com tanta frequência, de modo que não devem ter um grande impacto no cálculo de custos.

O gasto do projeto pode ser limitado

Os custos do Compute Engine são controlados por meio do sistema de cotas. Cada projeto tem uma cota específica que representa a quantidade máxima de recursos que podem ser consumidos por esse projeto. Para ajustar essas cotas, preencha o formulário Solicitação de alteração de cota.

Para o App Engine, que é um recurso de escalonamento automático, é possível abrir um tíquete de suporte para ter um recurso ativado que permita especificar um orçamento máximo para cada dia. Se você exceder o limite do orçamento, o aplicativo interromperá completamente o atendimento, por isso tenha cuidado ao usar esse recurso. Observe que o limite é uma aproximação; computar custos de consumo perfeitamente precisos exige um job off-line.

Definir alertas para limites de gastos mensais

Você pode configurar um limite mensal para cada conta de faturamento. Observe que isso não é um limite para o gasto da conta de faturamento. Em vez disso, é um mecanismo de monitoramento. Os administradores de faturamento recebem notificações quando a conta atinge 50%, 90% e 100% desse limite mensal. Os valores reais faturados podem ser maiores depois que todo o processamento de faturamento estiver concluído. Faça essas configurações na página Alertas da conta de faturamento no Console do GCP.

Monitorar e analisar custos do BigQuery

Você pode conseguir uma estimativa dos custos do BigQuery antes do faturamento usando o método Jobs:list para ver os bytes cobrados por consulta nos últimos seis meses. Para detalhar os custos de consulta individual, use o método Jobs:get para localizar a consulta e o solicitante dela.

Gerenciamento de riscos

Usar projetos para designar a propriedade dos recursos

Você pode usar projetos do Cloud Platform para designar a propriedade de recursos do Cloud Platform dentro da organização. Tenha em mente que um determinado departamento pode ter a propriedade de vários projetos e dos recursos que eles contêm. Você pode usar rótulos de projeto para indicar a propriedade organizacional ou outras dimensões que deseja rastrear. Por exemplo, você pode adicionar marcadores como owner:marketing ou cost-center:cc-123 a um projeto. É possível configurar esses marcadores para que fiquem visíveis no Console do GCP e na fatura exportada, e usá-los como filtro nas chamadas de API.

Somente os administradores de faturamento podem criar novos projetos

Os administradores de faturamento são as únicas pessoas que podem criar novos projetos faturáveis ​​associados às contas de faturamento que administram. Ao tornar os administradores de faturamento responsáveis ​​pelo gasto de recursos, você pode garantir a responsabilidade pelo uso e custo dos recursos.

Usar os proprietários do projeto para delegar a responsabilidade de controlar o acesso a recursos de propriedade

Cada projeto tem um conjunto de proprietários que precisam ser pessoas individuais. Grupos não são permitidos. Esses proprietários têm a capacidade de determinar quem tem acesso ao projeto e o tipo de acesso, ou papel. Use os proprietários do projeto para delegar a responsabilidade pelos recursos dentro da organização.

Usar rótulos de recursos para identificar ainda mais os proprietários dentro de um projeto ou entre projetos

Alguns recursos, como instâncias de VM, permitem que você adicione rótulos de nome-valor. Use esses rótulos para classificar ainda mais a propriedade do recurso, como owner:johndoe.

Conceder aos usuários as permissões apropriadas para facilitar o menor privilégio

O Cloud Platform oferece uma série de mecanismos para ajustar as permissões para o menor privilégio. Conceda aos desenvolvedores os privilégios menos necessários no nível do projeto: papel viewer, editor ou owner. Essas permissões são herdadas por recursos como o Compute Engine e o Cloud Storage. A finalidade da permissão owner é o gerenciamento da associação à equipe, a autorização e assim por diante.

Avalie se os desenvolvedores precisam de acesso no nível do projeto ou se o acesso a um recurso específico do Cloud Platform é suficiente. Por exemplo, adicione chaves SSH às instâncias para conceder aos desenvolvedores acesso a instâncias individuais de máquinas virtuais sem conceder acesso ao projeto ou a todas as instâncias no projeto.

Monitorar a conformidade das políticas com relatórios ACL

Use os Relatórios de segurança para monitorar papéis de domínio, por exemplo, o superusuário, ou a Roles API para fazer isso em uma solução central de geração de relatórios. Em seguida, configure-os para que um alerta seja emitido ou a permissão revogada automaticamente, caso ocorra uma violação de conformidade.

Use o Console do GCP para monitorar o uso do projeto para atribuições fora da política ou, em vez disso, use a Cloud IAM API em uma solução central de relatórios. Em seguida, configure-os para que um alerta seja emitido ou o acesso revogado automaticamente.

Use a Cloud Storage Bucket Access Controls API para monitorar o uso do intervalo para atribuições fora da política. Em seguida, configure-os para que um alerta seja emitido ou a permissão revogada automaticamente. Isso é particularmente importante para os intervalos de registro de auditoria.

Aplicar a política com sistemas de direitos de política

O registro, o monitoramento e a auditoria no Cloud Platform ajudam você a reconhecer ameaças e a mitigar riscos. Você também pode definir, gerenciar e aplicar políticas integrando-se a sistemas de direitos de política de terceiros ou criando o seu próprio. Isso permite separar os papéis de propriedade do projeto dos papéis de gerenciamento de política. A implementação correta desse tipo de esquema requer um planejamento avançado e adequado das contas e permissões do proprietário do projeto, particularmente no que diz respeito às permissões herdadas, como as do Cloud Storage. Você também precisa avaliar se as APIs são compatíveis com as operações de gerenciamento de políticas necessárias.

Planejar a recuperação de desastres

Eventos de interrupção de serviço podem acontecer a qualquer momento. A rede pode sofrer uma interrupção, o aplicativo push mais recente pode introduzir um bug crítico ou, em casos raros, você pode até ter que lidar com um desastre natural.

Quando as coisas vão mal, é importante ter um plano de recuperação de desastres robusto, direcionado e bem testado. O Cloud Platform oferece muitas das facilidades de que você precisa para implementar esse plano, como redundância, escalabilidade, conformidade e segurança.

O Manual para recuperação de desastres descreve alguns cenários para mostrar como o Cloud Platform pode ajudar.

Familiarizar-se com termos de serviço e certificações de conformidade

Estes são alguns links importantes:

Próximas etapas

Conheça outros recursos do Google Cloud Platform para seu uso. Confira nossos tutoriais.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…