O Google Cloud abriu o beta das Confidential VMs, primeiro produto de seu portfólio de Confidential Computing, com a promessa de proteger dados também enquanto estão sendo processados.1 A proposta mira um ponto historicamente desconfortável da computação em nuvem: dados costumam ser criptografados em repouso e em trânsito, mas precisam ser descriptografados durante a execução.
A novidade usa recursos de Secure Encrypted Virtualization, o SEV, presentes em processadores AMD EPYC de segunda geração. Na prática, a memória da máquina virtual passa a ser criptografada com uma chave associada à própria VM e gerada em hardware. O Google posiciona isso como uma camada adicional de isolamento para workloads sensíveis, especialmente em setores regulados.
Dados em uso entram no contrato de cloud
Confidential Computing muda a conversa porque leva criptografia para o tempo de execução. A pergunta deixa de ser apenas onde os dados ficam armazenados e por quais links trafegam. O ponto passa a incluir o que acontece quando uma aplicação consulta, indexa, treina modelo, processa lote ou cruza bases dentro de uma VM.
Isso importa em arquiteturas multitenant. Provedores de cloud já combinam hipervisores, isolamento de rede, controles de identidade, telemetria e hardening de imagem. Mesmo assim, clientes que operam informações financeiras, dados de saúde, propriedade intelectual ou análises competitivas tendem a buscar garantias adicionais contra exposição no host, no firmware ou em camadas de operação.
A promessa mais atraente do beta é reduzir a barreira de adoção. O Google afirma que workloads já executados em VMs podem migrar para Confidential VMs sem reescrita de aplicação, com ativação simples no provisionamento.1 Se essa experiência se confirmar em ambientes reais, a tecnologia deixa de ser tema restrito a enclaves especializados e entra no fluxo normal de infraestrutura.
Segurança precisa conviver com desempenho
Criptografar memória durante processamento não pode virar gargalo invisível. O próprio anúncio enfatiza suporte a drivers para armazenamento e rede, como NVMe e gVNIC, e a intenção de manter métricas próximas às VMs N2D convencionais. Esse é o detalhe operacional que decidirá adoção fora de provas de conceito.
Times de plataforma vão precisar medir latência, throughput, custo e compatibilidade de imagens. Também precisarão revisar ferramentas de observabilidade, agentes de segurança, snapshots, backups e respostas a incidente. Uma VM confidencial não elimina controles clássicos; ela adiciona uma propriedade de proteção que precisa ser compreendida por quem opera o ciclo de vida inteiro.
Há ainda uma dimensão de governança. Se a VM vira a unidade de proteção, políticas de provisionamento, inventário e classificação de dados precisam ser precisas. Não adianta oferecer memória criptografada se workloads sensíveis continuam misturados a projetos sem dono, contas excessivamente permissivas ou pipelines sem aprovação.
Colaboração sensível ganha novo desenho
O Google também apresenta Confidential Computing como habilitador para colaboração entre organizações. A ideia é permitir análise conjunta de conjuntos de dados confidenciais sem expor o conteúdo a todos os participantes ou a camadas desnecessárias da infraestrutura. Esse cenário aparece com força em pesquisa, saúde, antifraude, serviços financeiros e analytics entre parceiros.
O movimento pressiona outros provedores e fornecedores de software a tratarem proteção de dados em uso como requisito competitivo, não como recurso exótico. Empresas que já pediam criptografia gerenciada, chaves próprias e controles de acesso granulares agora passam a perguntar como workloads são isolados durante a execução.
Confidential VMs ainda chegam em beta, portanto exigem avaliação cuidadosa antes de produção crítica. Mesmo assim, o anúncio desloca a fronteira de segurança cloud. Criptografia deixa de ser apenas propriedade de disco e rede; passa a ser parte do desenho de computação.
- Google Cloud Blog, "Introducing Google Cloud Confidential Computing with Confidential VMs", 14 jul. 2020. ↩