Como proteger cargas de trabalho de renderização

Neste artigo, explicamos como tomar medidas para ajudar a proteger seu pipeline de renderização no Google Cloud. Aproveite os recursos de segurança do Google Cloud, como gerenciamento de identidade e acesso (IAM) e projetos para controle de acesso, verificação automática de políticas, criptografia, sub-redes e regras de firewall. Neste artigo, explicamos como 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 aqui para ampliar.

Projetos e acesso

Os projetos são um componente organizacional essencial do Google Cloud. 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 Google Cloud, como instâncias do Compute Engine e 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 IAM inclui um conjunto de métodos para gerenciar permissões de projeto por meio da API Resource Manager.

Usar projetos para controlar o acesso aos recursos

Os projetos fornecem um limite de isolamento para dados de rede e administração de projetos. No entanto, é possível conceder explicitamente interconexões entre os recursos do Google Cloud usados pela sua organização ou outros projetos dentro dela. 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 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 uma hierarquia de recursos do Google Cloud:

diagrama de uma estrutura de projeto

Conceder acesso

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

Você também pode conceder acesso a um projeto ou recurso para qualquer usuário de uma organização. Basta adicionar o usuário a um Grupo do Google que tenha acesso a esse projeto ou recurso. Os Grupos permitem dar acesso rapidamente a partes externas, como fornecedores e freelancers. Mas 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 SDK e API

Se você acessar o Google Cloud por SDK gcloud ou gsutil, será necessário autenticar ao se conectar à API Google Cloud. É preciso fazer isso apenas uma vez por ambiente de usuário local.

Caso seus aplicativos ou scripts acessem o Google Cloud pelas 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.

Identificar projetos

Cada projeto tem um código universalmente único, 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 código do projeto é baseado nesse nome, com números anexados para torná-lo globalmente único. Modifique o código do projeto atribuído, mas o nome precisa ser globalmente único.

Seu projeto também recebe um número longo, globalmente único e aleatório, que é gerado automaticamente. Os códigos 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 código e o número dele permanecem iguais, mesmo que você 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 e reduzir 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.

Automatizar verificações de segurança

O Policy Scanner fornece uma biblioteca para a execução de verificações de segurança automatizadas no projeto visando garantir a correta definição 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 defini-lo para execução semanal ou diária.

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 canal de renderização, as permissões de usuário costumam ser gerenciadas localmente por configurações de permissão no nível do SO, juntamente com um serviço de diretório como LDAP ou Active Directory.

Ao contrário do que ocorre em um canal de renderização típico, a maioria dos artistas não precisa de acesso ao projeto, pois 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 em operação em uma conta de serviço.

Ao implementar o princípio de menor privilégio em nível local e na nuvem, você pode 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 canais 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 IAM das permissões definidas no nível do sistema operacional em uma instância em execução. Elas funcionam juntas para oferecer um perfil completo de usuário, mas os dois sistemas têm objetivos diferentes, sendo criados e modificados com mecanismos diferentes.

O 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 de SO, que podem ser sincronizadas com o IAM. A concessão de permissões do 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 de fazer login. Os dois sistemas são projetados para serem complementares: o IAM é usado para conceder acesso a recursos do Google Cloud, 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 fazer 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.

IAM

Para gerenciar recursos do Google Cloud, o IAM permite criar e gerenciar permissões nos níveis da organização, do projeto e dos recursos. O IAM unifica o controle de acesso dos serviços do Google Cloud em um só sistema e apresenta um conjunto consistente de operações.

Papéis e grupos do IAM

Há três papéis básicos do 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 no nível de proprietário do projeto, como membros do departamento de TI, administradores de sistema ou gerentes de produção. Os proprietários de projetos podem alterar tudo, como contas de faturamento e níveis de acesso de qualquer outro usuário. Por isso, é preciso ter muito cuidado ao atribuir esse papel.

Você pode criar um projeto com um ou mais proprietários. O papel Administrador da organização pode manter esses proprietários no nível da organização. As pessoas com esse papel de administrador podem criar projetos, modificar o faturamento do projeto 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.

Visualizador Este papel somente leitura pode não ser útil em todos os canais, 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 podem ajudar a assegurar, 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.

Usar a hierarquia de recursos para controle de acesso

Você pode definir políticas do IAM em diferentes níveis da hierarquia de recursos. Os recursos herdam as políticas do recurso pai. Isso permite espelhar a estrutura hierárquica de política do IAM na estrutura da organização. É aconselhável seguir 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.

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 IAM por meio do Google 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". É aconselhável alterar essa configuração do Qube 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.

A imagem de inicialização deve ser configurada 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 locais.

Contas de serviço

Uma conta de serviço é uma conta especial do Google que pode ser usada para acessar serviços e recursos do Google de modo programático.

Para canais 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 Google Cloud usando credenciais da conta de serviço, permitindo que jobs sejam iniciados na nova instância.

Quando um novo projeto é criado, são criadas algumas contas de serviço padrão. É aconselhável manter 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 lançar instâncias. Tenha cuidado ao excluir contas de serviço, isso pode remover o acesso a alguns recursos de projeto.

Você pode optar por ter contas de serviço separadas para tarefas de canal individuais para que executem eventos baseados em programas. Essas contas de serviço recebem um papel do IAM com base no escopo das necessidades. Por exemplo:

  • Implantação da instância pelo gerenciador de filas de renderização: a conta de serviço principal para executar jobs de renderização no Google Cloud. Essa conta receberia 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 projeto, como o Cloud Logging. Essa conta de serviço receberia o papel logging.logWriter.

Access scopes

Escopos de acesso constituem o método legado que especifica permissões para 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 do Google. Recursos como o Compute Engine e o Cloud Storage são acessados por essas APIs.

Em vez de conceder permissões padrão a todos os usuários de uma instância, use papéis do IAM 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, um conjunto padrão de escopos será aplicado à 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 IAM, ler nos buckets do Google Cloud Storage e gravar registros usando a API Cloud Logging.

Ao criar 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 Cloud Storage usando a API Compute Engine.

logging.write

Permita o acesso de gravação da instância aos registros do Compute Engine usando a API Cloud Logging (v2).

monitoring.write

Permita que a instância publique dados de métricas nos projetos do Google Cloud usando a API Cloud Monitoring (v3).

servicecontrol

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

service.management.readonly

Permita que a instância publique dados de métricas nos projetos do Google Cloud usando a API Cloud 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 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 (bem como todos os dados no Google Cloud) são criptografados em repouso usando a 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 Google 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) desvinculada desse bloco de dados:

image

Também é possível escolher o Cloud KMS para gerenciar as chaves de criptografia.

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

Também é possível fornecer chaves de criptografia próprias para uso no Google Cloud Storage e para discos permanentes do Google Compute Engine. Porém, a menos que você já tenha um serviço de gerenciamento de chaves no local, é aconselhável deixar o Google gerenciar e alternar as chaves de dados do armazenamento. Essa alternância é realizada a cada 90 dias.

O Cloud KMS é um serviço do Google Cloud que permite manter chaves de criptografia centralizadas na nuvem para uso direto por serviços em nuvem. Atualmente, não há integrações de camada de armazenamento para criptografar seus dados armazenados em outros serviços do Google Cloud.

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ública/privada é gerado automaticamente, específico para essa conta. A chave pública é mantida pelo Google, e a chave privada é gerenciada por você. Essa chave privada é necessária para autenticar a conta de serviço quando ela executa tarefas no Google Cloud.

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 do resto dos dados do projeto. Projetos individuais podem ser uma maneira ainda mais efetiva de separar dados.

Quando você cria um novo projeto, devido ao recurso de sub-redes autônomas, várias sub-redes são criadas, uma por região do Google Compute Engine. Ao iniciar 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, é preciso 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 canal 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 Remote Desktop Protocol (RDP) 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 de allow nas duas direções.

Pode ser útil incorporar tags de instância ao canal para permitir acesso a tipos específicos de instâncias com uma regra de firewall. Por exemplo, você pode 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, serão permitidas conexões de todas as portas.

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 IPs públicos. Por isso, é preciso 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 que o gerenciador de filas de renderização controle suas instâncias sem um endereço IP externo, implemente uma Cloud VPN. O gateway da VPN é o único recurso na sua rede com um endereço IP externo, a menos que você adicione um Cloud Router, que usa o Border Gateway Protocol (BGP) para transmitir intervalos de IP particulares entre sua rede local e suas redes do Google Cloud.

Imagens de disco

Em um canal VFX, recomendamos usar um projeto separado 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 em uso ativo 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.

É possível usar os papéis do IAM para compartilhar imagens em todos os projetos. Consulte Compartilhar imagens entre projetos para mais informações.

Imagens públicas

O Google Compute Engine oferece muitas imagens públicas pré-configuradas que têm sistemas operacionais Linux e Windows compatíveis. Cada imagem do sistema operacional é configurada para incluir determinados pacotes, como o Cloud SDK, ou ter serviços habilitados, 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 existente. É aconselhável que as imagens atendam a estas práticas recomendadas de segurança.

É aconselhável instalar o Linux Guest Environment for Google Compute Engine para acessar a funcionalidade disponível por padrão em imagens públicas. A instalação do ambiente convidado permite executar tarefas com os mesmos controles de segurança na imagem personalizada, como acesso a metadados, configuração do sistema e otimização do SO para uso no Google Cloud.

Conectividade

Há várias maneiras de se conectar ao Google a partir da instalação. Em todos os casos, é preciso implementar uma rede privada virtual (VPN, na sigla em inglês). Alguns métodos exigem configuração adicional, conforme descrito abaixo, para ajudar a 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 2048 bits gerado pela autoridade de certificação do Google;
  • criptografia de dados à medida que eles se movem entre os data centers da rede privada.
  • atualização de todos os certificados RSA para chaves de 2.048 bits, tornando nossa criptografia em trânsito para o Google Cloud e todos os outros serviços do Google ainda mais fortes.
  • uso do Perfect Forward Secrecy (PFS), que minimiza o impacto de uma chave comprometida ou ruptura criptográfica.

Conectar pela Internet

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

Peering direto

O Google hospeda a infraestrutura de rede de borda em mais de 100 instalações de ponto de presença em todo o mundo às quais os clientes Google Cloud podem se conectar diretamente. Todos os clientes Google Cloud que tenham um ASN público e um prefixo de IP publicamente roteável podem fazer 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 serviço Cloud Interconnect é uma opção. O Cloud Interconnect é para clientes que querem conectividade empresarial com a vantagem do Google. Os provedores de serviços de parceiro do Cloud Interconnect fornecem conectividade empresarial de uma destas duas maneiras:

  • Conexões de peering atuais, que têm capacidades gerenciadas em conjunto para garantir alto desempenho e baixa latência.
  • Interconexões dedicadas com o objetivo de transportar apenas o tráfego de clientes do Google Cloud (embora o Google anuncie rotas para todos os serviços por meio desses links).

Cloud VPN

Os canais de renderização locais nem sempre criptografam dados em trânsito. Porém, para um canal 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. O Cloud VPN conecta o gateway da VPN de mesmo nível à sua rede do Google Cloud por meio de uma conexão VPN IPsec. O tráfego entre as duas redes é criptografado por um gateway de VPN e depois decodificado pelo outro gateway de VPN. Além de ajudar a proteger os dados à medida que eles viajam pela Internet, isso não exige a implementação da criptografia de dados como parte do canal de renderização.

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

VPN fornecida pelo cliente

É possível configurar seu próprio gateway de VPN no Google Cloud, mas é melhor usar o Cloud VPN para ter mais flexibilidade e melhor integração com o Google Cloud.

Sistemas de arquivos

Há várias opções de servidor de arquivos disponíveis para gerenciar os dados. Dependendo da metodologia de canal, 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 canal de renderização. Por fazer parte do Google Cloud, o Cloud Storage utiliza recursos de segurança, como o controle de acesso, o IAM e 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, é melhor manter o armazenamento e a computação na mesma região para melhor rendimento e menos 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 taxas de saída adicionais. Como esses dados ficam acessíveis de modo global, é fundamental gerenciar corretamente os escopos de VM, os usuáriose 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

Os dados de produção ativos geralmente são armazenados em um servidor de arquivos compatível com POSIX. Isso pode ser adequado para renderizar canais que exigem acesso a metadados de arquivos, como horários de modificação, ou que dependem 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 node ú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 node único e montá-los nas instâncias. Basta isolar o armazenamento para cada porção do canal e restringir o acesso de usuários e grupos do sistema operacional, da mesma forma que nos sistemas de arquivos locais.

Você também pode proteger os dados nos servidores de arquivos de node único montando-os como somente leitura nas instâncias de renderização. O software, as ferramentas de canal 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, você também pode implantar um arquivador de node único por rede, pois as instâncias só podem montar servidores de arquivos na mesma rede.

Você também pode criar instantâneos do disco de software ou canal para realizar um rollback rápido 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 Google Cloud, como sistemas de arquivos em cluster e em cache. Consulte a documentação de conformidade do fornecedor individual para saber mais 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 em 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 raiz regularmente rotacionadas.

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

Recomendamos o uso do IAM para restringir quem tem acesso aos dados nos buckets do Cloud Storage ou em um projeto. Também é 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 canal 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, é aconselhável 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 Google Cloud, respeita os papéis do 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 sistemas de arquivos compatíveis com POSIX ou para eles, inclusive servidores de arquivos de nó único e Persistent Disk, é aconselhável usar scp ou rsync em uma conexão VPN.

UDP

Se você optar por usar um protocolo de transferência de dados baseado em UDP de terceiros no upload direto de dados para um bucket do Google Cloud Storage, como Aspera, Cloud FastPath, BitSpeed ou FDT, consulte a documentação do fornecedor para conhecer o modelo de segurança e as práticas recomendadas correspondentes. Esses serviços de terceiros não são gerenciados pelo Google.

Cloud Logging

O Cloud Logging permite monitorar e registrar uma variedade de atividades no seu projeto ou organização. O Cloud Logging foi originalmente escrito para aplicativos e serviços da Web, mas ele 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.

A API Cloud Logging não é ativada por padrão em novos projetos do Google Cloud. É aconselhável ativar a API Cloud Logging para que o Cloud Logging atue como um servidor de geração de registros para aplicativos externos.

O registro de auditoria ajuda a rastrear atividades administrativas usando o console ou a API para modificar 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 Cloud Logging explica por quanto tempo as entradas de registro são mantidas. Para manter os registros além do período de retenção, 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 Logging Agent, que não é instalado por padrão. As instruções de instalação se encontram 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 canal 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 no local. Em alguns momentos, é possível usar o mesmo gerenciador de filas para implantar jobs no Google Cloud. 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 Google Cloud. Consulte a documentação de terceiros para analisar as práticas de segurança.

As instruções enviadas ao Google Cloud pelo gerenciador de filas devem ser emitidas usando o comando gcloud. Se for preciso enviar comandos usando ssh,, será necessário gerar uma chave SSH para comunicação. Uma alternativa é executar seu servidor de gerenciamento de filas no Google Cloud, em vez de no local, para evitar isso.

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 canais 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 Google Cloud 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

Ao executar seu próprio servidor de licenças no Google Cloud, é aconselhável executá-lo em uma rede separada para permitir mais controle e monitoramento.

A seguir