Como proteger cargas de trabalho de renderização

Este artigo explica como tomar medidas que ajudem a proteger o pipeline de renderização no Google Cloud Platform (GCP). Aproveite os recursos de segurança do GCP, como projetos e Cloud IAM para controle de acesso, verificação automática de políticas, criptografia, sub-redes e regras de firewall. Neste artigo, você aprende a aderir ao protocolo de segurança exigido pelos grandes estúdios de cinema.

A imagem a seguir mostra uma arquitetura de renderização híbrida como referência:

Diagrama de uma arquitetura de renderização híbrida

Clique para ampliar.

Projetos e acesso

Projetos são o principal componente organizacional do GCP. Os projetos funcionam como um agrupamento abstrato que pode ser usado para associar recursos a um departamento, equipe funcional ou aplicativo específico. Todos os recursos do GCP, como as instâncias do Compute Engine e os buckets do Cloud Storage, pertencem a um projeto. É possível gerenciar projetos usando o Console do Google Cloud, assim como a API Resource Manager. A API Cloud Identity and Access (IAM) inclui um conjunto de métodos para gerenciar permissões de projeto por meio da API Resource Manager.

Como usar projetos para controlar o acesso aos recursos

Os projetos fornecem um limite de isolamento para dados de rede e administração de projetos. Porém, é possível conceder interconexões explicitamente entre os recursos do GCP usados pela organização ou outros projetos dentro da organização. Usuários e 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 Cloud ou a API Cloud IAM.

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

A imagem a seguir mostra um exemplo de hierarquia de recursos do GCP:

diagrama de uma estrutura de projeto

Como conceder acesso

Se a organização implementar o G Suite, é possível conceder acesso a qualquer projeto do GCP para qualquer usuário ou grupo da organização. Se você gerencia as identidades fora do G Suite, também é possível estabelecer credenciais de usuário com base no próprio servidor LDAP, incluindo o Microsoft Active Directory. Basta usar o Cloud Directory Sync.

Também é possível conceder acesso a um projeto ou recurso a qualquer usuário de uma organização. Basta adicioná-lo a um grupo do Google que tenha acesso a esse projeto ou recurso. Com os grupos, é possível conceder acesso rapidamente a partes externas como fornecedores e freelancers. No entanto, talvez não convenha à organização permitir esse nível de flexibilidade, dependendo das políticas de segurança. Use a API do Cloud para criar a funcionalidade de monitoramento que verifica se há atribuições fora da política e, em seguida, emite um alerta ou as revoga automaticamente.

Acesso por meio do SDK e da API

Se você acessar o GCP por meio do SDK do gcloud ou gsutil, precisará fazer a autenticação quando se conectar à API Google Cloud. É preciso fazer isso apenas uma vez por ambiente de usuário local.

Caso seus aplicativos ou scripts acessem o GCP por meio de bibliotecas de cliente da API, primeiro você precisará fazer a autenticação usando o SDK. Em seguida, as bibliotecas de cliente da API coletarão as credenciais criadas.

Como identificar projetos

Cada projeto tem um ID universalmente exclusivo, que é uma string curta de letras minúsculas, dígitos e traços. Quando você cria um projeto, especifica o próprio nome dele. O ID do projeto é baseado nesse nome, com números anexados para torná-lo globalmente exclusivo. Modifique o ID do projeto atribuído, mas o nome precisa ser globalmente exclusivo.

Seu projeto também recebe um número longo, globalmente exclusivo e aleatório, que é gerado automaticamente. Os IDs de projeto podem ter de 6 a 30 caracteres. Já os nomes de projeto podem ter de 4 a 30 caracteres.

Após a criação do projeto, o ID e o número dele permanecem iguais, mesmo que você mude o nome do projeto.

Recomendamos que haja algum planejamento em relação aos nomes de projeto para facilitar o gerenciamento. Os projetos devidamente nomeados podem ser classificados corretamente, o que reduz a confusão.

Uma convenção típica de nomenclatura de projeto pode usar o seguinte padrão:

[studio]-[project]-[role (rnd, dev, prod)]
    

Um nome de arquivo resultante pode ser, por exemplo: mystudio-myproject-rnd.

Como automatizar verificações de segurança

O Policy Scanner fornece uma framework para a execução de verificações de segurança automatizadas no projeto, garantindo a definição correta das políticas. Os projetos verificados que desviam da política conhecida são marcados, e você é alertado sobre os problemas. Execute o Policy Scanner quando achar mais conveniente ou configure-o para realizar execuções semanais ou diárias.

Como controlar o acesso dos usuários

Nem todos os envolvidos em um projeto devem ter acesso irrestrito a todas as instâncias em execução, todos os serviços e todos os dados armazenados. Em um pipeline de renderização, as permissões de usuário costumam ser gerenciadas localmente por configurações de permissão no nível do SO, com um serviço de diretório como LDAP ou Active Directory.

Ao contrário do que ocorre em um pipeline de renderização típico, a maioria dos artistas não precisa de acesso ao projeto, porque quase todas as tarefas baseadas em nuvem, como sincronização de recursos, renderização e gravação ou cópia de dados, são realizadas pelo software de gerenciamento de filas que está sendo operado em uma conta de serviço.

Ao implementar o princípio de menor privilégio no nível local e na nuvem, é possível restringir o acesso dos usuários apenas às áreas do projeto ou às informações necessárias para realizar tarefas específicas conforme o papel de cada um.

Ao contrário das cargas de trabalho baseadas na Web, os pipelines de renderização costumam exigir acesso direto às instâncias em execução, por exemplo, para solucionar um problema de renderização em um tipo específico de instância. É possível entrar em uma instância usando uma API, como o comando gcloud, ou usando o SSH para se conectar diretamente a uma instância se tiver estabelecido pares de chaves SSH.

Limite o acesso direto aos administradores do sistema e outros papéis responsáveis pelo gerenciamento ou solução de problemas de renderizações. O acesso direto é essencial para:

  • depurar ou solucionar problemas de jobs com falha;
  • renderizar o controle do gerenciador de filas sobre a inicialização e o encerramento das instâncias;
  • conceder acesso por meio de um software ou mecanismo de geração de registros que monitore o uso de memória ou CPU;
  • executar tarefas durante o próprio job.

É importante diferenciar as permissões de usuário no Cloud IAM das permissões definidas no nível do SO em uma instância em execução. Elas trabalham juntas para oferecer um perfil completo de usuário, mas os dois sistemas atendem a diferentes objetivos, sendo criados e modificados com mecanismos diferentes.

O Cloud IAM não gerencia o SSH nem o acesso dos usuários a instâncias individuais. O acesso é gerenciado pelas permissões de usuário no nível do SO, que podem ser sincronizadas com o Cloud IAM. A concessão de permissões do Cloud IAM a um usuário ou uma conta de serviço não altera o modo como o usuário faz login nas instâncias nem as permissões dele depois do login. Os dois sistemas são projetados de modo a se complementarem: o IAM é usado para conceder acesso aos recursos do GCP, como o console ou a API, e o acesso direto é provisionado apenas para usuários que precisam dele.

Ao criar uma imagem personalizada, é possível ativar ou desativar o acesso SSH. Para isso, modifique o ssh e os daemons de conta do Google no disco de inicialização. Para fins de orientação, investigue os recursos de segurança já incorporados às nossas imagens públicas.

Identity and Access Management (IAM)

Para gerenciar os recursos do GCP, o Cloud IAM permite que você crie e gerencie permissões nos níveis de recurso, organização e projeto. Ele unifica o controle de acesso de serviços do GCP em um único sistema e apresenta um conjunto consistente de operações.

Papéis e grupos do IAM

Há três papéis primários do Cloud IAM: owner, editor e viewer.

Proprietário. Apenas um grupo restrito de pessoas confiáveis em uma instalação ou um projeto tem privilégios ao projeto no nível de proprietário, como membros do departamento de TI, administradores de sistema ou gerentes de produção. Os proprietários de projetos podem alterar tudo, incluindo contas de faturamento e níveis de acesso de qualquer outro usuário. Por isso, é preciso ter muito cuidado ao atribuir esse papel.

É possível criar um projeto com um ou mais proprietários. O papel administrador da organização mantém esses proprietários no nível da organização. As pessoas com esse papel podem criar projetos, modificar o faturamento deles e atribuir papéis sem dar acesso total de proprietário a projetos individuais.

Os administradores da organização recebem a maioria das notificações de todos os projetos da organização. Por padrão, algumas notificações só chegam aos proprietários do projeto.

Editor. Um editor do projeto pode realizar ações que modificam o estado em todos os recursos do projeto, como leitura e gravação de dados de projeto, inicialização e encerramento de instâncias ou leitura e gravação de metadados de projeto.

Leitor. Este papel somente leitura pode não ser útil em todos os pipelines, mas talvez convenha atribuí-lo a algumas contas de serviço relacionadas ao monitoramento e login em sistemas externos. Por exemplo, sistemas de análise de jornais diários que leem imagens ou vídeos ou APIs que se comunicam com sistemas de gerenciamento de projeto, como o Shotgun.

Papéis predefinidos. Alguns papéis predefinidos limitam usuários ou contas de serviço a tarefas específicas. Esses papéis garantem, por exemplo, que um artista não tenha acesso aos dados de faturamento de uma produção ou que um assistente de produção seja impedido de excluir uma instância em execução.

Como usar a hierarquia de recursos para controle de acesso

Defina políticas do IAM em diferentes níveis da hierarquia de recursos. Os recursos herdam as políticas do pai. Assim, é possível espelhar a estrutura hierárquica de política do IAM na estrutura organizacional. Recomendamos que você siga as orientações do conjunto de práticas recomendadas para implementar a hierarquia de recursos.

Desativar papéis sem uso

Alguns papéis são ativados por padrão e ficam à disposição dos criadores/proprietários do projeto para atribuição. Para reduzir a confusão, pode ser útil desativar os papéis que não se aplicam ao fluxo de trabalho específico. Isso só pode ser feito nas configurações da organização, e não para cada projeto.

Como controlar o acesso SSH às instâncias

Veja a seguir o que é necessário para garantir que as pessoas certas tenham acesso aos recursos:

  • Sincronização entre o serviço de diretório e o Cloud IAM por meio do Cloud Directory Sync. Isso garante que você tenha uma lista idêntica de usuários e as respectivas permissões no local e na nuvem.
  • Mecanismos de autenticação de usuários para ter acesso SSH a instâncias. Por exemplo, por meio do módulo PAM do Linux acoplado ao LDAP.

Nas cargas de trabalho de renderização, recomendamos restringir o acesso SSH a usuários específicos, como membros do departamento de TI, administradores de sistema e gerenciadores de renderização.

Jobs enviados para a nuvem por um gerenciador de filas costumam ser de propriedade de um usuário dedicado de renderização ou daemon. Por exemplo, por padrão, os jobs de renderização do Qube! são executados como o usuário "qubeproxy". Recomendamos alterar essa configuração do Qube (em inglês) para que seja executada como o usuário que iniciou o job. No Qube, isso é chamado de "modo de usuário". Assim, todos os processos são executados por meio do usuário que iniciou o job. As renderizações concluídas mantêm essa propriedade.

Configure a imagem de inicialização do mesmo modo que qualquer trabalho de renderização local. Ou seja, a autenticação é executada com os mesmos protocolos dos trabalhos de renderização no local.

Contas de serviço

Uma conta de serviço é uma conta especial do Google usada para acessar serviços e recursos do Google de maneira programática.

Para pipelines de renderização, as contas de serviço são úteis para controlar o modo como as instâncias são implantadas ou encerradas, e como os jobs são alocados e executados nas instâncias. O software de enfileiramento de renderização iniciará instâncias no GCP usando as credenciais da conta de serviço. Assim, os jobs são iniciados na nova instância.

Quando um novo projeto é criado, são criadas algumas contas de serviço padrão. Recomendamos que você mantenha apenas a conta de serviço chamada Compute Engine default service account e todas as contas de serviço usadas pelo seu software de enfileiramento para iniciar instâncias. Tenha cuidado ao excluir contas de serviço, porque isso pode remover o acesso a alguns recursos de projeto.

É possível ter contas de serviço separadas para tarefas de pipeline individuais para que executem eventos baseados em programas. Essas contas de serviço recebem um papel do Cloud IAM com base no escopo das necessidades. Exemplo:

  • Implantação de instâncias pelo gerenciador de filas de renderização: a principal conta de serviço para executar jobs de renderização no GCP. Essa conta recebe os papéis compute.instanceAdmin e iam.serviceAccountActor.
  • Gerente de recursos: uma conta de serviço para publicação de recursos, recuperação ou gerenciamento de banco de dados. Se você estiver usando o Cloud Storage, essa conta de serviço receberá o papel storage.admin.
  • Agente do Logging: uma conta de serviço usada especificamente pelo mecanismo de geração de registros do seu projeto, como o Google Stackdriver. Essa conta de serviço receberia o papel logging.logWriter.

Escopos de acesso

Os escopos de acesso são o método legado que especifica permissões de uma instância. Essas permissões se aplicam a qualquer usuário na instância. Os escopos de acesso concedem permissões padrão de uma instância às APIs Google. Recursos como Google Compute Engine e Google Cloud Storage são acessados por meio dessas APIs.

Em vez de conceder permissões padrão a todos os usuários de uma instância, use papéis do Cloud IAM em conjunto com os escopos de acesso para conceder permissão a um único usuário ou conta de serviço.

Especifique a sinalização --no-scopes para impedir a aplicação de escopos padrão durante a criação de uma instância. Se você não especificar --no-scopes e nenhum escopo for especificado com a sinalização --scope, será aplicado um conjunto padrão de escopos à instância.

Por padrão, as instâncias começam com um conjunto de escopos. A maioria deles é necessária para acessar as contas de usuário do Cloud IAM, ler a partir dos buckets do Google Cloud Storage e gravar registros usando a API Stackdriver.

Quando você cria uma nova instância, os seguintes escopos são concedidos a ela:

Escopo

Tarefa de API

read only

Este escopo impede que qualquer usuário da instância grave em um bucket do Google Cloud Storage usando a API Compute Engine.

logging.write

Permite acesso de gravação de instância aos registros do Google Compute Engine usando a API Stackdriver Logging (v2).

monitoring.write

Permite que a instância publique dados de métrica nos projetos do GCP usando a API Stackdriver Monitoring (v3).

servicecontrol

Permite que a instância gerencie os dados do Google Service Control usando a API Service Control.

service.management.readonly

Permite que a instância publique dados de métrica nos projetos do GCP usando a API Stackdriver Monitoring (v3).

trace.append

Permite que a instância colete e grave dados de latência de um projeto ou aplicativo usando a API Stackdriver Trace.

O conjunto padrão de escopos não permite, por exemplo, que as instâncias gravem nos buckets do Google Cloud Storage. Se o pipeline de renderização exigir que as instâncias gravem renderizações concluídas no Cloud Storage, adicione o escopo storage-rw antes de iniciar instâncias de worker somente de renderização. Como isso permite que os usuários copiem quaisquer dados fora da instância, não adicione esse escopo a instâncias com acesso a dados confidenciais.

Gerenciamento de chaves de criptografia

Cloud Storage

Todos os dados do projeto (e os dados do GCP) são criptografados em repouso usando criptografia AES128 ou AES256. Também é possível fornecer suas próprias chaves de criptografia para o Cloud Storage e os discos do Compute Engine.

O Cloud Storage sempre criptografa os dados no lado do servidor antes de gravá-los em disco. Por padrão, o Google Cloud Storage usa chaves próprias do lado do servidor para criptografar dados. Os dados são criptografados em granularidade fina com uma chave de criptografia de dados (DEK, na sigla em inglês) que, por sua vez, é criptografada por uma chave de criptografia de chave (KEK, na sigla em inglês). As KEKs são gerenciadas em um serviço central de gerenciamento de chaves e compartilhadas com outros serviços do Google, como o Gmail.

Para descriptografar um bloco de dados, o serviço de armazenamento chama o serviço de gerenciamento de chaves interno do Google para recuperar a chave de criptografia de dados (DEK, na sigla em inglês) desvinculada desse bloco:

imagem

É possível escolher o Cloud KMS para gerenciar as chaves de criptografia.

Muitas vezes nos referirmos a uma única chave, mas o que realmente queremos dizer é que os dados são protegidos utilizando um conjunto de chaves: uma chave ativa para criptografia e um conjunto de chaves históricas para descriptografia, com um número que é determinado pelo cronograma de alternância de chaves.

Se preferir, é possível fornecer as próprias chaves de criptografia para uso no Cloud Storage e para discos permanentes do Compute Engine. No entanto, a menos que você já tenha um serviço de gerenciamento de chaves no local, recomendamos que deixe o Google gerenciar e rotacionar as chaves de dados do armazenamento. Essa rotação é realizada a cada 90 dias.

O Cloud KMS é um serviço do GCP para centralizar as chaves de criptografia na nuvem para uso direto dos serviços de nuvem. No momento, não há integrações da camada de armazenamento para criptografar os dados armazenados em outros serviços do GCP.

Recomendamos configurar um projeto centralizado separado para executar o Cloud KMS para todos os projetos.

Contas de serviço

Quando você cria uma conta de serviço, um par de chaves públicas/privadas é gerado automaticamente, específico para essa conta. A chave pública é mantida pelo Google, mas a chave privada é gerenciada por você. A chave privada é necessária para autenticar a conta de serviço quando ela executa tarefas no GCP.

Segurança de rede

Todas as instâncias de computação são criadas como membros de uma Cloud Virtual Network. Por padrão, todas as redes são de sub-redes automáticas. As sub-redes regionais são criadas automaticamente para você. Cada rede é restrita a um único projeto. Uma rede não pode ter vários projetos. Apenas usuários com os papéis específicos de proprietários do projeto, administradores da organização ou administradores da rede de computadores podem alterar as propriedades da rede.

Redes e sub-redes

Isole recursos em redes separadas para adicionar um nível extra de segurança. Por exemplo, uma sequência de fotos com conteúdo altamente confidencial só pode ser renderizada dentro de uma rede separada, isolada dos outros dados do projeto. Os projetos individuais são uma maneira ainda mais efetiva de separar dados.

Quando você cria um novo projeto, por conta do recurso de sub-redes autônomas, várias sub-redes são criadas, uma por região do Compute Engine. Quando você inicia uma nova instância em uma região específica, ela é colocada na sub-rede dessa região e recebe um IP interno nessa sub-rede.

Regras de firewall

Cada rede tem um firewall que bloqueia todo o tráfego para as instâncias. Para permitir o tráfego de entrada, você precisa criar regras de "permissão" de firewall.

A rede rotulada como default em cada projeto tem regras de firewall padrão, conforme mostrado abaixo. Nenhuma rede criada manualmente tem regras de firewall, independentemente do tipo. Para todas as redes, exceto a rede padrão, é preciso criar as regras de firewall que forem necessárias.

Nem todas essas regras padrão são necessárias para um pipeline de renderização:

Regra

Observação

Recomendação

default-allow-internal

Necessária para permitir a comunicação entre instâncias. Se o gerenciador de filas for local, as instâncias provavelmente não precisarão se comunicar entre si.

Exclua esta regra se as instâncias não precisarem se comunicar com outras instâncias.

default-allow-ssh

Usada para permitir o acesso por SSH na porta 22.

Exclua esta regra e crie uma semelhante que permita apenas SSH em uma VPN ou um IP conhecido.

default-allow-rdp

Necessária somente quando se quer acessar instâncias em uma Área de trabalho remota (RDP, na sigla em inglês) pela porta 3389. Na maioria das vezes o acesso SSH é suficiente, então esta regra pode ser excluída.

Exclua esta regra, a menos que você esteja usando máquinas que executam o Windows.

default-allow-icmp

Permite a comunicação de erros ou informações operacionais em toda a rede. Esta regra permite o acesso a partir de qualquer IP.

Exclua esta regra e crie uma semelhante que permita apenas ICMP proveniente de endereços IP conhecidos.

Por padrão, as regras de firewall se aplicam a toda a rede. Se você quiser que duas sub-redes troquem tráfego, configure as permissões allow nas duas direções.

Pode ser útil incorporar tags de instância ao pipeline para permitir acesso a tipos específicos de instâncias com uma regra de firewall. Por exemplo, é possível colocar tag em todas as instâncias de renderização para permitir o acesso SSH de determinados papéis para solucionar problemas. Qualquer instância ausente dessa tag restringiria automaticamente o acesso SSH, como o servidor de licenças.

Se sourceRanges e sourceTags não forem especificados ao criar uma regra de firewall, o sourceRange padrão será 0.0.0.0/0. Portanto, a regra será aplicada a todo o tráfego de entrada dentro e fora da rede.

Se nenhuma porta for especificada na criação de uma regra de firewall TCP ou UDP, todas as portas poderão ser conectadas.

Rotas da rede

Todas as redes apresentam rotas criadas automaticamente para a Internet pública e para os buckets de IP na rede. O tráfego de saída não é bloqueado por padrão. Somente as instâncias com um endereço IP externo e um gateway padrão de Internet podem enviar pacotes para fora da rede.

As APIs do Google Cloud (por exemplo, gcloud e gsutil) só podem ser acessadas por meio de IPs públicos. Por isso, você precisa manter a Rota do gateway de Internet padrão em Rede > Rotas.

Como desativar endereços IP externos

Por motivos de segurança, recomendamos que as instâncias não tenham um endereço IP externo. Por padrão, um endereço IP externo é atribuído a todas as instâncias ao serem iniciadas. Para evitar isso, inicie suas instâncias com a sinalização --no-address.

Para controlar as instâncias por meio da renderização do gerenciador de filas sem um endereço IP externo, é preciso implementar uma VPN do Cloud. O gateway da VPN é o único recurso na rede com um endereço IP externo, a menos que você adicione um Cloud Router, que utiliza o protocolo do gateway de borda (BGP, sigla e conteúdo em inglês) para transmitir intervalos de IP particulares entre a rede local e as do Cloud Platform.

Imagens de disco

Em um pipeline VFX, recomendamos usar um projeto separado no nível da organização para gerenciamento de imagens. Com essa abordagem, impede-se a modificação de modelos de imagem padrão para toda a instalação, que podem estar sendo usados ativamente por todos os projetos. Essa abordagem também ajuda a organizar as imagens de inicialização em um local central, acessível a todos os outros projetos, conforme a devida atribuição de papéis.

Use os papéis do IAM para compartilhar imagens em todos os projetos. Consulte Como compartilhar imagens entre projetos para mais informações.

Imagens públicas

O Compute Engine oferece muitas imagens públicas pré-configuradas que têm sistemas operacionais Linux e Windows compatíveis. Cada imagem do SO é configurada para incluir determinados pacotes, como o SDK do Cloud, ou ter serviços ativados, como o SSH.

Essas imagens também incluem um conjunto de pacotes para configurar e gerenciar contas de usuários, além de ativar a autenticação baseada em chave SSH.

Imagens personalizadas

Crie sua própria imagem de disco personalizada com base em uma imagem atual. Recomendamos que as imagens atendam a estas práticas recomendadas de segurança.

Recomendamos que você instale o ambiente de convidado Linux para o Google Compute Engine para acessar a funcionalidade disponível por padrão em imagens públicas. Ao instalar esse ambiente, é possível executar na imagem personalizada tarefas com os mesmos controles de segurança das imagens públicas, como acesso a metadados, configuração do sistema e otimização do SO para uso no GCP.

Conectividade

Há várias maneiras de se conectar ao Google na instalação. Em todos os casos, é preciso implementar uma rede privada virtual (VPN). Alguns métodos exigem configuração extra, conforme descrito abaixo, para garantir a transmissão segura dos dados.

Alguns métodos de segurança aplicados aos dados são:

  • criptografia de links de dados ao Google por meio de TLS com um certificado de 2.048 bits gerado pela autoridade de certificação do Google;
  • criptografia de dados à medida que eles se movem entre os data centers da rede particular;
  • upgrade de todos os certificados RSA para chaves de 2048 bits, o que fortalece ainda mais a criptografia em trânsito para o GCP e todos os outros serviços do Google;
  • uso do Perfect Forward Secrecy (PFS), que minimiza o impacto de uma chave comprometida ou ruptura criptográfica.

Como se conectar pela Internet

É possível se conectar à rede do Google e aproveitar o modelo de segurança de ponta a ponta. Basta acessar os serviços do GCP pela Internet. Ao percorrer os túneis VPN, os dados são protegidos por protocolos autenticados e criptografados.

Peering direto

O Google tem infraestrutura de rede de ponta em mais de 100 instalações com ponto de presença pelo mundo. Os clientes do GCP podem se conectar diretamente a elas. Qualquer cliente do GCP com um ASN público e um prefixo de IP publicamente roteável pode executar um peering com o Google. Essa opção usa o mesmo modelo de interconexão que a Internet pública.

Cloud Interconnect

Para os clientes que não têm ASNs públicos ou que estabelecem conexão ao Google por meio de um provedor de serviços, o Cloud Interconnect é uma opção. Ele é para clientes que querem uma conexão de nível empresarial com as tecnologias avançadas do Google. Os provedores de serviços de parceiro do Cloud Interconnect oferece uma conexão de nível empresarial de uma destas duas maneiras:

  • Conexões de peering atuais com capacidades gerenciadas em conjunto para garantir alto desempenho e baixa latência.
  • Interconexões dedicadas que transportam apenas o tráfego de clientes do GCP, mesmo que o Google anuncie rotas para todos os serviços por essas conexões.

VPN do Cloud

Os pipelines de renderização locais nem sempre criptografam dados em trânsito. Porém, para um pipeline híbrido de renderização na nuvem, recomendamos que todos os dados em trânsito sejam criptografados.

Independentemente de como você está conectado ao Google, é necessário proteger sua conexão com uma VPN. A VPN do Cloud conecta seu gateway de VPN de peering à rede do GCP por meio de uma conexão VPN IPsec. O tráfego entre as duas redes é criptografado por um gateway de VPN e depois descriptografado por outro gateway desse tipo. Além de ajudar a proteger os dados à medida que eles viajam pela Internet, não é necessário implementar a criptografia de dados como parte do pipeline de renderização.

Se a instalação tiver muitos locais ou redes, você manterá as rotas sincronizadas entre esses locais e a VPN do Cloud usando um Cloud Router.

VPN fornecida pelo cliente

Configure o próprio gateway VPN dentro do GCP, mas é melhor usar a VPN do Cloud para ter mais flexibilidade e melhor integração com o GCP.

Sistemas de arquivos

Há várias opções de servidor de arquivos disponíveis para gerenciar os dados. Dependendo da metodologia do pipeline, talvez seja necessário implementar mais de um.

Baseados em objeto

O Google Cloud Storage é um armazenamento de objetos unificado apropriado para todos os dados gerados ou consumidos por todo o pipeline de renderização. Por fazer parte do GCP, o Cloud Storage aproveita recursos de segurança como o controle de acesso, o Cloud IAM e a criptografia.

Quando o local em que você cria um bucket é uma região, os dados dentro dele podem ser acessados globalmente pelos membros do projeto, mesmo que os dados estejam armazenados em um data center específico. Do ponto de vista do desempenho, é preferível manter o armazenamento e a computação na mesma região para ter o melhor rendimento e a menor latência.

Os dados no Google Cloud Storage ficam disponíveis globalmente, para que você possa compartilhar dados com outra instalação em outra parte do mundo sem precisar replicar. Isso pode gerar mais taxas de saída. Como esses dados ficam acessíveis de modo global, é fundamental gerenciar corretamente os escopos de VM, os usuários e as chaves de acesso para evitar que os dados escapem do pipeline de renderização.

Talvez seja preciso adaptar o pipeline de gerenciamento de recursos para interagir com a arquitetura baseada em objetos do Cloud Storage.

Conformidade com POSIX

Dados de produção ativos geralmente são armazenados em um servidor de arquivos compatível com POSIX, o que pode ser ideal para renderizar pipelines que exigem acesso a metadados de arquivos, como horários de modificação, ou que dependam de caminhos de arquivos para recursos de cena.

Dependendo das necessidades e da carga de trabalho da instalação, há algumas opções ao implementar um sistema de arquivos NFS.

Servidor de arquivos de nó único

Um servidor NFS compatível com POSIX está disponível como uma solução click-to-deploy. É possível executar vários servidores de arquivos de nó único e montá-los nas instâncias. Isso significa que é possível isolar o armazenamento para cada porção do pipeline, restringindo o acesso nos níveis de usuário e grupo do sistema operacional da mesma forma que nos sistemas de arquivos locais.

Também é possível proteger os dados nos servidores de arquivos de nó único montando-os como somente leitura nas instâncias de renderização. O software, as ferramentas de pipeline e as bibliotecas de recursos nunca devem ser modificados a partir de uma instância de renderização. Portanto, a montagem como somente leitura é uma maneira fácil de aplicar essa restrição.

Para proteger o projeto ainda mais, também é possível implantar um arquivador de nó único por rede, já que as instâncias só podem ativar servidores de arquivo na mesma rede.

Também é possível criar instantâneos do disco de software ou pipeline para realizar uma reversão rápida a versões anteriores com impacto mínimo na produção.

Outros sistemas de arquivos

Outros sistemas de arquivos de terceiros estão disponíveis para uso com o GCP, como sistemas de arquivos em cluster de armazenamento em cache. Consulte a documentação de conformidade do fornecedor individual para saber sobre segurança em sistemas de arquivos de armazenamento em cache de terceiros.

Segurança de armazenamento

Por padrão, o Cloud Storage gerencia as chaves de criptografia do servidor em seu nome por meio dos mesmos sistemas de gerenciamento de chaves com proteção aprimorada que usamos nos nossos dados criptografados. Isso inclui auditoria e controles rígidos de acesso por chave. O Cloud Storage criptografa o conteúdo do usuário em repouso, e cada chave de criptografia é criptografada com um conjunto de chaves mestre regularmente rotacionadas.

Todas as classes de armazenamento aceitam os mesmos controles de acesso OAuth e granular para proteger os dados.

Recomendamos o uso do Cloud IAM para restringir quem tem acesso aos dados nos buckets do Cloud Storage ou em um projeto. Também será possível aproveitar as listas de controle de acesso se precisar gerenciar apenas um pequeno número de objetos.

Opções de transferência

A segurança dos dados em trânsito refere-se à segurança dos dados conforme eles transitam entre o armazenamento local e a nuvem. Há muitas metodologias de pipeline que ajudam a gerenciar o movimento dos dados entre o local e a nuvem, mas o design e a implementação delas estão fora do escopo deste documento. Todos os métodos de transferência descritos abaixo são executados no conjunto completo de segurança do Google para autenticação e autorização, exceto os métodos de transferência de terceiros.

Linha de comando

Para transferir dados do Cloud Storage ou para ele, recomendamos usar o comando gsutil para copiar, mover ou sincronizar dados com tamanho inferior a 10 TB. O comando gsutil usa os mesmos recursos de segurança e autenticação que o GCP, respeita os papéis do Cloud IAM e executa todas as operações com criptografia da camada de transporte (HTTPS). O gsutil também é compatível com uploads paralelos.

Para transferir a partir de ou para sistemas de arquivos compatíveis com POSIX, incluindo servidores de arquivos de nó único e Persistent Disk, recomendamos o uso de scp ou rsync em uma conexão VPN.

UDP

Caso você opte por usar um protocolo de transferência de dados baseado em UDP terceirizado para fazer upload de dados diretamente para um bucket do Cloud Storage, como Aspera, Tervela Cloud FastPath, BitSpeed ou FDT (links em inglês), consulte a documentação das soluções para conhecer o modelo de segurança e as práticas recomendadas. Esses serviços de terceiros não são gerenciados pelo Google.

Como gerar registros com o Stackdriver

Com o Google Stackdriver, é possível monitorar e registrar uma variedade de atividades no projeto ou organização. O Stackdriver foi originalmente criado para aplicativos e serviços da Web, mas pode ser usado como um servidor de geração de registros para um pipeline de renderização, fornecendo um ponto de coleta para a enorme quantidade de dados gerados por renderizações de linha de comando.

Por padrão, as APIs Stackdriver não são ativadas nos projetos novos do GCP. No momento, há quatro APIs: Debugging, Logging, Monitoring e Trace. Nem todas elas se aplicam ao fluxo de trabalho. Porém, recomendamos pelo menos ativar o Stackdriver Logging para que ele possa atuar como servidor de geração de registros de aplicativos externos.

Com a geração de registros de auditoria, você rastreia a atividade de administrador usando o console ou a API que modifica a configuração ou os metadados de um serviço ou projeto. Não é possível modificar ou excluir registros de auditoria.

Todos os registros são mantidos por um período de tempo especificado e depois excluídos. A política de cotas do Stackdriver Logging explica por quanto tempo as entradas de registro são mantidas. Para manter os registros além do período de armazenamento, exporte-os para um bucket do Cloud Storage, um conjunto de dados do BigQuery, um tópico do Cloud Pub/Sub ou qualquer combinação dos três.

Os registros são coletados de instâncias individuais por meio do agente do Logging, que não é instalado por padrão. As instruções de instalação estão aqui.

Outras considerações

Esta seção aborda tópicos que estão fora da linha de produtos Google, mas costumam fazer parte de um pipeline de renderização típico.

Gerenciamento de filas

Muitos estúdios usam um gerenciador de filas para controlar a implantação, o rastreamento e as tarefas implantadas em um farm de renderização local. Às vezes, é possível usar o mesmo gerenciador de filas para implantar jobs no GCP. A abordagem específica pode variar conforme o software envolvido.

Alguns gerenciadores de filas fornecem plug-ins de software para permitir que servidores e clientes se conectem ao GCP. Consulte a documentação de terceiros para avaliar as práticas de segurança correspondentes.

Instruções enviadas ao GCP pelo gerenciador de filas devem ser emitidas usando o comando gcloud. Se você precisar enviar comandos usando ssh,, será necessário gerar uma chave SSH para comunicação. Para evitar isso, execute o servidor de gerenciamento de filas no GCP, em vez de no local.

Como automatizar a criação e o encerramento de instâncias

Em alguns casos, convém automatizar a criação de instâncias quando um job é iniciado, bem como o encerramento da instância quando o trabalho é concluído com sucesso. Por motivos de custo e segurança, evite manter instâncias em execução quando não estiver executando um job.

Software personalizado

Os pipelines de renderização geralmente incluem software de terceiros e personalizado. O software personalizado pode incluir qualquer coisa, desde scripts simples a binários complexos compilados com várias dependências.

Para manipular instâncias do GCP a partir de scripts ou programas, use as bibliotecas de cliente disponíveis. Cada versão fornece métodos de autorização do OAuth 2.0.

Licenciamento

Servidor de licenças local

O uso do servidor de licenças local próprio ajuda a fornecer um ambiente mais seguro quando a execução é feita por uma VPN. O nível de segurança ainda está sujeito às limitações da tecnologia de licenciamento em uso.

Servidor de licenças no Cloud

Se você executa o próprio servidor de licenças no GCP, recomendamos executá-lo em uma rede separada para ter mais controle e monitoramento.

A seguir