Práticas recomendadas para organizações empresariais

Conheça os principais conceitos e as práticas recomendadas para utilizar ao máximo o Google Cloud Platform em uma configuração corporativa. Neste guia, abordamos tópicos não funcionais relevantes para organizações de tamanho empresarial.

O guia é organizado nas seguintes seções:

Projetos e acesso

Os Projetos são o principal componente organizacional do Google Cloud Platform. Eles oferecem um agrupamento abstrato a ser usado para associar recursos a um determinado departamento ou equipe funcional. Todos os recursos do Cloud Platform pertencem a um projeto. É possível gerenciar projetos usando o console do Google Cloud Platform, bem como a API Resource Manager. A API Cloud IAM inclui um conjunto de métodos que gerencia as permissões do projeto por meio da API Resource Manager.

Usar projetos para controlar o acesso a recursos

Os projetos fornecem um limite de isolamento, exceto quando as interconexões são concedidas de forma explícita entre os recursos do Cloud Platform usados por sua organização. Os usuários e grupos recebem diferentes papéis, como viewer, editor e owner para diferentes projetos. Para atribuir papéis, utilize a página do IAM e do administrador no console do GCP ou a API Cloud IAM. Essa API atualmente não permite a criação de papéis personalizados e a atribuição de permissões a esses papéis.

Também é possível delegar o controle sobre quem tem acesso a um projeto específico. Usuários com papel de owner concedem e revogam 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 recursos de toda a organização que podem ser editadas somente por administradores de faturamento. Esses administradores são gerenciados usando a página "Faturamento" no console do GCP. Cada projeto está associado a uma conta. Essa associação é feita apenas por um usuário que é proprietário do projeto e administrador do faturamento. As cobranças e faturas de suporte estão associadas a uma única conta de faturamento.

Projetos que não são baseados em geografia ou equivalentes a zonas

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

Por exemplo, o projeto A contém recursos no centro dos EUA, na Europa e na Ásia, cada um com diversas zonas, enquanto o projeto B contém recursos apenas na Europa, também com diversas zonas.

Ao criar um projeto, não é preciso configurar uma região geográfica ou zona. A única exceção a essa regra está no Google App Engine. Os aplicativos do App Engine sempre têm uma localização geográfica. Ao criar um novo projeto, é possível alterar o local do Google App Engine a partir do local padrão. Observe que, após a criação de um projeto, determinados recursos são fixados em localizações geográficas específicas. Esse conceito será explicado mais detalhadamente nas próximas seções.

Autenticação e identidade

Nesta seção, fornecemos as práticas recomendadas para criar e gerenciar autenticação e identidades no Google Cloud Platform.

Usar credenciais de login corporativo

No Google Cloud Platform, as Contas do Google são usadas para autenticação e gerenciamento de acesso. Recomenda-se o uso de contas corporativas totalmente gerenciadas do Google para aumentar a visibilidade, a auditoria e o controle sobre o acesso aos recursos do Cloud Platform.

O Cloud Identity fornece Contas do Google gratuitas e gerenciadas. Use-as com os serviços do Google, incluindo o Cloud Platform. Com as contas do Cloud Identity para cada um dos usuários, é possível gerenciá-los em todo o domínio no Google Admin Console.

Como administrador do G Suite, você gerencia todos os usuários e configurações por meio do Admin Console do G Suite. Por padrão, todos os novos usuários recebem uma licença do G Suite. Caso você tenha um subconjunto de desenvolvedores que não requeiram licenças do G Suite, adicione as contas do Cloud Identity.

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

Provisionar usuários no diretório do Google

No diretório global do G Suite é fornecido um armazenamento de dados estruturados 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, sendo provisionado por diversos meios. Os usuários provisionados aproveitam os recursos de autenticação avançada, incluindo o logon único (SSO, na sigla em inglês), o OAuth e a verificação de dois fatores.

É possível provisionar usuários automaticamente com uma das seguintes ferramentas e serviços:

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

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

Caso prefira criar uma solução própria para provisionar usuários e grupos, use o Google Admin SDK. Nele há métodos para gerenciar usuários do Cloud Platform e respectivas associações a grupos e organizações. O SDK é compatível com pontos de extremidade HTTPS REST, além de fornecer bibliotecas de clientes em Python, Java, .NET etc.

Além dessas ferramentas e serviços nativos, muitos dos principais fornecedores de gerenciamento de identidade fornecem conectores ao diretório global do G Suite. Nesses conectores, geralmente é feito o provisionamento dos usuários do G Suite e respectivas associações a grupos e organizações usando a API Google Admin SDK's Directory. Como o Cloud Platform e o G Suite compartilham uma infraestrutura de diretório comum, esses conectores são aplicáveis ao Cloud Platform e ao G Suite.

Para provisionar manualmente usuários e respectivas associações a grupos e organizações para testes e outras finalidades, os administradores do Cloud Platform usam o G Suite Admin Console.

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

Resolver conflitos de contas 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 são gerenciados pelo Admin Console ou por meio da API Roles. Para mais informações, veja Sobre papéis de administrador.

Implementar o SSO com troca de SAML

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

Ao acessar diretamente ou por outro aplicativo uma dessas ferramentas sem prévia autenticação no provedor de SSO, o usuário é solicitado a fornecer o nome de usuário, mas não a senha. Nessa etapa, é fornecida ajuda à infraestrutura de autenticação do Google para determinar o domínio em que o usuário quer ser autenticado.

Para mais informações sobre como configurar o SSO do Google, veja Configurar o logon único em contas do G Suite. Este guia é aplicável ao Google Cloud Platform e ao G Suite, já que ambos compartilham uma infraestrutura de diretório, autenticação e SSO.

Usar o Google como um provedor de identidade para outros serviços

É possível passar para uma solução de autenticação 100% baseada em nuvem. Basta autenticar os próprios aplicativos com o OpenID Connect do Google e usar o Google como um provedor de identidade SAML 2.0 para autenticar aplicativos comerciais prontos para uso.

O Google e terceiros fornecem bibliotecas para que você cuide dos muitos detalhes de implementação do OpenID Connect na autenticação de usuários. Use o Google como 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 conhecidos. Dentre os parceiros de identidade do G Suite recomendados, citamos Ping e Okta. É possível também adicionar novas integrações personalizadas de aplicativos SAML.

A utilização do Google como provedor de identidade permite usufruir da 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

É possível usar os Grupos do Google para gerenciar a autorização de projetos em uma grande organização. Caso você já esteja familiarizado com o Controle de acesso baseado em papéis (RBAC, na sigla em inglês), pense nos Grupos do Google como análogos a papéis do RBAC, e os papéis de projetos no Cloud Platform como análogos a permissões do RBAC. É possível atribuir papéis de projetos a grupos de forma semelhante aos que você atribui a usuários, bem como gerenciar associação a grupos, conforme descrito anteriormente.

Autorizar interações de servidor para 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 operações a partir de um terminal de linha de comando, é possível autorizar o acesso a APIs pela ferramenta de linha de comando gcloud em nome da conta de usuário ou de uma conta de serviço. Essas credenciais também são 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 que controlam todo o acesso à rede

O Cloud Platform utiliza uma rede definida por software que fornece muita flexibilidade em dispositivos virtuais. É possível criar regras de firewall para controlar a entrada de tráfego em instâncias e balanceadores de carga, seja da Internet pública ou de outras instâncias na mesma rede. Além disso, é possível aplicar essas regras em determinadas tags de instâncias. Por exemplo, crie uma regra de firewall que se aplique dinamicamente a um conjunto de instâncias marcadas com a mesma tag, facilitando o escalonamento automático de clusters.

As rotas são igualmente flexíveis. Você estabelece as rotas na rede que definem como as instâncias da VM direcionam o tráfego para outras instâncias na mesma rede, bem como recursos externos. As rotas também são aplicadas a tags de determinadas instâncias, permitindo a configuração das regras dinamicamente aplicáveis a instâncias, conforme o fluxo delas.

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

As regras de firewall do Cloud Platform controlam a entrada de tráfego para as instâncias da VM, mas as rotas de rede controlam a saída de VMs para intervalos de endereços IP. Como exemplos, citamos o roteamento de todo o tráfego externo por meio de um gateway de NAT, todo o tráfego para intervalos IP corporativos por meio de um gateway de VPN ou a negação do acesso a intervalos de IP por roteamento para um IP inexistente. Caso seja necessário controlar o tráfego de saída das instâncias de VM para portas específicas, como filtrar 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 um endereço IP público

Cada instância de VM é atribuída a um endereço interno que se ajusta ao espaço de endereço de rede em que foi criado. Esse endereço é usado para tráfego entre instâncias da mesma rede. Como alternativa, anexe um endereço IP público externo a uma VM. Esse endereço é efêmero ou, mediante uma taxa, estático. Observe que a cobrança é feita por um endereço IP estático reservado quando a instância da VM não está em execução e também quando o IP não está associado a nenhuma instância da VM.

Sua cota padrão inclui a disponibilidade de um pequeno número de endereços IP externos: 23 efêmeros e 7 estáticos por região. Com um aumento de cota, é possível aumentar o número de endereços IP externos efêmeros para 500 por região. Caso você precise de mais endereços IP externos do que de cotas, entre em contato com o suporte do Cloud ou com o gerente técnico de contas para tratar disso.

É necessário um endereço de IP público para acessar os serviços do Cloud Platform nas instâncias de VM.

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. É preciso ainda executar uma revisão de segurança manual.

Usar o Cloud Router para adicionar rotas dinamicamente ao Cloud VPN

Mesmo com a flexibilidade do Cloud VPN, é necessário que os intervalos de endereços IP sejam adicionados estaticamente e removidos dos túneis e para eles. No Google Cloud Router, é possível diminuir essa limitação com o uso do Border Gateway Protocol (BGP) para atualizar os túneis dinamicamente.

Uma rede pode ser dividida em sub-redes

Com as sub-redes do Compute Engine, você controla o espaço de endereço em que são criadas as instâncias de VM, mantendo a capacidade de roteamento entre elas. As sub-redes são qualquer intervalo de IP não público. Isso quer dizer que elas não precisam pertencer a uma rede pai comum. As sub-redes em um determinado agrupamento de redes conseguem acessar umas às outras.

Você consegue maior isolamento entre sub-redes usando regras de firewall e rotas.

Registro, monitoramento e auditoria

Para reconhecer ameaças e reduzir riscos, monitore o acesso e o uso da sua conta e dos recursos do sistema. O Cloud Platform tem um conjunto muito avançado de ferramentas de monitoramento que são partes importantes da solução geral.

Use o Cloud Logging como local de registros centralizado

No Google Cloud Logging é oferecido um local de registros generalizado e centralizado. Nessa área de registros centralizada, aparecem automaticamente registros de instâncias de VM, App Engine e serviços gerenciados. Além disso, é possível enviar outros registros arbitrários ao Cloud Logging. Use esse recurso para reunir todos os registros do sistema e do aplicativo em um só lugar e facilitar a análise e o monitoramento.

Monitore o acesso dos recursos do sistema

Para controlar o acesso dos recursos do sistema, monitore os seguintes itens:

  • Modificações de recursos do Compute Engine, como criar e excluir instâncias e discos, alterar regras de firewall e configurar o balanceamento de carga e o escalonamento automático usando a API RegionOperations.

  • Solicitações de informações do Compute Engine, como chamadas de instance/get usando os 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

Use a API Reports e o Registro de auditoria de login no Admin Console para monitorar todas as tentativas de acesso à conta de domínio.

Monitorar ações administrativas

Use a API IAM para monitorar as alterações nos papéis dos projetos e, com o registro de auditoria do Admin Console, monitore todas as operações executadas no console administrativo do domínio.

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

O BigQuery é uma excelente ferramenta para analisar rapidamente enormes quantidades de dados. É também uma forma bastante econômica de armazenar dados para análise. É possível configurar o Cloud Logging de maneira que a exportação de registros seja feita diretamente para o BigQuery. Essa é uma ferramenta poderosa que permitirá a realização de análises detalhadas e a identificação de tendências nos registros.

Evitar alterações indesejadas nos registros

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

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

Privilégio mínimo

Conceda o mínimo possível de permissões necessárias para executar o job. Restrinja o uso do papel de owner para projetos e intervalos de registros. O objetivo do papel de owner é gerenciar a associação da equipe, a autorização e assim por diante.

Os membros da equipe com o papel de editor também implantam aplicativos e modificam ou configuram os respectivos recursos.

É possível fornecer acesso gerenciado a intervalos e a objetos para uma população mais ampla por meio de um aplicativo personalizado, que usa a API Cloud Storage com uma conta de serviço dedicada e adiciona auditoria no aplicativo.

Não repúdio

Todos os dados do Cloud Storage são criptografados automaticamente antes de serem gravados no disco. É possível fornecer outra garantia de não-repúdio com a implementação do controle de versão do objeto nos intervalos dos registros. Em um intervalo, quando um objeto é substituído ou excluído, uma cópia do objeto é salva automaticamente com propriedades de geração que o identificam. Esse recurso não oferece proteção que impeça o proprietário de um projeto de excluir o objeto arquivado ou desativar o controle de versão.

Separação de tarefas

É possível fornecer outra garantia de separação de tarefas. Por exemplo, você precisa de duas pessoas que inspecionem e assinem os registros. Copie os intervalos de registros em um projeto de proprietário diferente, usando o gsutil cp como parte de um cron job frequente ou, para uma quantidade de dados copiados maior do que 10TB de dados de registro de cada vez, use o Serviço de transferência do Cloud Storage. Essa abordagem não oferece proteção que impeça o proprietário de um projeto de excluir o intervalo original antes de a cópia ocorrer ou de desativar a geração de registros original.

Com essa abordagem, é feita uma cópia baseada em nuvem, sem cópia para a máquina local, o que a torna rápida e eficiente. Não há cobrança pela entrada ou saída de cópias na rede em uma região. No entanto, há cobranças operacionais pelo processo de cópia.

Reduza os custos de armazenamento de duplicação dos registros, copiando os objetos para o Nearline Storage, implementando o gerenciamento do ciclo de vida do objeto nos objetos de intervalos de origem e removendo-os após verificar se foram replicados para o projeto de backup, talvez semanalmente.

Usar o Stackdriver Monitoring para monitorar seus recursos e fornecer alertas

É possível usar o Stackdriver Monitoring para monitorar diversos recursos, como instâncias de VM, App Engine e Cloud Pub/Sub. Muitas dessas integrações de monitoramento são fornecidas automaticamente. Basta configurar limites para alertas.

O Cloud Platform também oferece a capacidade de detectar determinadas entradas de registros e criar métricas personalizadas em torno desses itens.

Unificar todas as suas necessidades de registros e monitoramento usando o Cloud Platform

Com o Stackdriver Monitoring, você envia métricas de monitoramento de VMs localizadas fora do Cloud Platform. Use um agente instalável para relatar e alertar sobre todos os recursos em um único painel, inclusive recursos no local e em outras nuvens.

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

A página Atividade no console do GCP oferece um fluxo das atividades de toda a organização, em todos os projetos. Ele é filtrado por um ou mais projetos, tipos de atividades e intervalos de datas para zerar rapidamente em alterações ou ajustes. Um conjunto principal de produtos atualmente é compatível com o fluxo de atividades, e outros serão incluídos ao longo do tempo.

Suporte e treinamento

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

É adquirido um pacote de suporte para toda a organização. Há uma série de pacotes de suporte disponíveis, mas recomendamos enfaticamente os pacotes Gold e Platinum para tratar, em tempo hábil, de problemas críticos dos projetos em produção.

A comunidade é uma excelente fonte de suporte

Os funcionários do Google apoiam e incentivam ativamente a comunidade de usuários. Para uma lista de locais comuns da comunidade, em que você encontra informações detalhadas sobre o Cloud Platform, veja Participe de uma comunidade do Google Cloud Platform.

Treinamento introdutório e avançado que ajudará a evitar armadilhas comuns

O Google oferece treinamento de qualificação para o Cloud Platform. No treinamento são incluídas desde visões gerais introdutórias de alto nível até sessões detalhadas de aprofundamento em tecnologias específicas. É possível encontrar uma aula no site do Google Cloud Platform.

Recomendamos que você tenha pelo menos pessoas-chave qualificadas em Cloud Platform na organização. O curso CPO200: Google Cloud Platform para profissionais de operações de sistemas é útil especialmente para pessoas que implantem e gerenciem aplicativos do Compute Engine.

Criar centros internos de excelência em produtos

São oferecidos com o Cloud Platform, um amplo conjunto de produtos, serviços e APIs, combináveis de maneiras criativas e inesperadas. O Google continua a investir nesses produtos e novos recursos vêm sendo continuamente implantados. É valiosa a captura de informações sobre experiência e padrões da organização, em uma base de conhecimento interna como em um site do wiki, do Google Site ou da intranet.

No wiki próprio, inclua uma lista de especialistas em produtos que aconselhem novos usuários e os ajude a usar determinados produtos do Cloud Platform de acordo com as práticas recomendadas da organização.

Estabeleça uma câmara de compensação de suporte interna

Há um número máximo de pessoas autorizadas por você para enviar tíquetes de suporte em nome da organização. Recomendamos que você configure uma câmara de compensação interna ou uma mesa de triagem. Essa abordagem ajuda a evitar a duplicação de tíquetes e a falta de comunicação, além de manter o máximo de clareza na comunicação com o Google Cloud Support.

Utilizar os parceiros do Google

Convém complementar periodicamente a experiência e a capacidade da organização com ajuda externa. Um avançado ecossistema de parceiros foi criado pelo Google, ajudando a preencher essas lacunas. Para mais informações sobre parceiros, consulte Parceiros do Google Cloud Platform.

Acompanhar as novidades e anúncios do Cloud Platform

Mantenha-se atualizado sobre as últimas notícias, anúncios e histórias de clientes inscrevendo-se no Blog do Google Cloud Platform.

Faturamento e atribuição de custos

Na fatura mensal, os custos estão divididos por projeto e por tipo de recurso

Sua fatura mensal é enviada por e-mail aos administradores de faturamento. A fatura em si é bem detalhada. Lembre-se de que ela divide o uso de recursos primeiro por projeto e depois por tipo de recurso. A nomenclatura cuidadosa de projetos facilita a visualização das equipes ou produtos que consumem recursos. Use essas informações para facilitar os reembolsos para os departamentos da organização.

Usar diariamente a exportação de faturamento para receber uma versão da fatura, legível por sua máquina

Ative o recurso de exportação do faturamento para publicar diariamente o equivalente aos itens de linha da fatura detalhados. Formate esse arquivo como JSON ou CSV e publique em um intervalo do Cloud Storage. Esses dados brutos agilizam os relatórios diários quanto ao uso e os custos do Cloud Platform. Ative a exportação de faturamento na área de administração da conta de faturamento no console do GCP.

Usar rótulos de projeto para melhor categorizar os projetos na exportação do faturamento

Na página Projetos do console do GCP, adicione rótulos customizados aos projetos como pares de chaves-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. No console do GCP, defina essas configurações na página Alertas da conta de faturamento.

Monitore e analise os custos do BigQuery

É possível receber uma estimativa de custos do BigQuery antes do faturamento usando o método lista de jobs do BigQuery para ver número de bytes cobrados por consulta nos últimos seis meses. Para detalhar os custos da consulta individual, use o método Jobs: get para localizar a consulta e seu remetente.

Gerenciamento de riscos

Usar os projetos para designar propriedades de recursos

Use projetos do Cloud Platform para designar propriedades de recursos do Cloud Platform na organização. Lembre-se de que um departamento específico tem diversos projetos e os respectivos recursos. Use rótulos de projeto para indicar a propriedade organizacional ou outras dimensões que você quer rastrear. Por exemplo, é possível adicionar rótulos 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 melhor classificar a propriedade de recursos, como owner:johndoe.

Conceder aos usuários permissões apropriadas para facilitar o privilégio mínimo

O Cloud Platform oferece diversos mecanismos para ajustar as permissões ao privilégio mínimo. Conceda aos desenvolvedores os privilégios mínimos necessários ao nível do projeto: viewer, editor ou o papel de owner. Essas permissões são herdadas por recursos, como o Compute Engine e o Cloud Storage. O objetivo da permissão de owner é gerenciar a associação da equipe, autorização e assim por diante.

Avalie a necessidade de acesso dos desenvolvedores em nível de projeto ou se a concessão de acesso a um recurso específico do Cloud Platform é suficiente. Por exemplo, adicione chaves SSH às suas instâncias para conceder aos desenvolvedores acesso a instâncias de máquinas virtuais individuais sem conceder acesso ao seu projeto ou a todas as instâncias contidas nele.

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

Use os Relatórios de segurança para monitorar papéis de domínio, como o de superadministrador, ou use a API Roles para fazer isso em uma solução central de relatórios. Em seguida, crie um alerta ou revogue a permissão automaticamente quando ocorrer uma violação de conformidade.

Use o console do GCP para monitorar o uso do projeto em atribuições fora da política ou use a API Cloud IAM em uma solução central de relatórios para alertar ou revogar o acesso automaticamente.

Use a API Cloud Storage Bucket Access Controls para monitorar o uso de intervalos nas atribuições fora da política e para alertar ou revogar o acesso automaticamente. Isso é importante principalmente nos intervalos de registros de auditoria.

Aplicar política com os sistemas de direitos de políticas

A geração de registros, o monitoramento e a auditoria no Cloud Platform auxiliam no reconhecimento de ameaças e na redução de riscos. Além disso, é possível definir, gerenciar e aplicar a política integrando-se a sistemas de direitos de políticas de terceiros ou criando os seus próprios. Dessa forma, você consegue separar os papéis de propriedade do projeto dos papéis de gerenciamento de políticas. A implementação correta desse tipo de esquema requer um bom e avançado planejamento das contas e permissões do proprietário do projeto, especialmente com relação às permissões herdadas, como as do Cloud Storage. Avalie também se as APIs são compatíveis com as operações obrigatórias de gerenciamento de políticas.

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. Veja nossos tutoriais.

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

Enviar comentários sobre…