GeoKey Manager: localização de dados também é uma política de uso das chaves

A reconstrução do GeoKey Manager da Cloudflare entrou em beta fechado em 23 de outubro para clientes existentes do Data Localization Suite, com disponibilidade geral planejada para o primeiro trimestre de 2027.[6] O desenho combina proteção pós-quântica com controle regional de chaves e rejeita operações quando contexto, região ou época de rotação não correspondem à política.[6] É uma escolha explícita: negar o processamento pode ser preferível a executá-lo fora da condição autorizada.

O que muda para quem desenvolve

Segundo a InfoQ, o mecanismo utiliza HPKE com combinação híbrida de ML-KEM-768 e X25519, além de HKDF-SHA-256 e AES-256-GCM.[6] Cada região tem uma chave-raiz simétrica de 256 bits, da qual são derivados pares por aplicação e época; as chaves privadas dos clientes ficam encapsuladas sob essas chaves de aplicação.[6]

Para receber uma raiz, o servidor deve comprovar identidade de hardware por TPM, ter localização correspondente no inventário Zinc e obter autorização de provisionamento.[6] As raízes ficam no keyring do kernel e desaparecem após reinicialização, exigindo nova autenticação.[6]

Minha leitura é que a arquitetura desloca a discussão de “onde o arquivo está” para “onde o processamento pode obter acesso ao conteúdo”. Por isso, eu exigiria documentação tanto do caminho das chaves quanto das dependências que autorizam sua entrega. O algoritmo é uma parte da avaliação, não seu substituto.

Como aplicar

Em uma revisão de serviço com requisitos geográficos, desenhe três fluxos separados: distribuição do material cifrado, provisionamento das chaves e autorização para utilizá-las. Identifique quem confirma a localização e como uma mudança de inventário chega à decisão de acesso.

Proponha, em homologação, uma matriz de falhas: chave ausente, época antiga, localização divergente e indisponibilidade do provisionamento após reinício. Para cada cenário, defina previamente se a aplicação deve recusar, aguardar ou encaminhar para outro destino permitido. Observe também se mensagens de erro e métricas permitem distinguir esses casos sem expor segredos.

Esse exercício não exige implementar o mecanismo da Cloudflare. Ele serve para tornar verificável o contrato de qualquer solução que prometa processar dados apenas em locais autorizados.

Cuidados e limites

No desenho relatado, chave ausente ou malformada impede o serviço de iniciar; a matéria também apresenta questionamentos sobre comprometimento da raiz, confiança no inventário e indisponibilidade regional, sem afirmar que ocorreu invasão.[6] Esses pontos devem entrar como perguntas de risco, não como vulnerabilidades comprovadas.

Não planeje uma implantação geral como se o beta já estivesse aberto. Minha recomendação é negociar antecipadamente o comportamento em falhas e o procedimento de recuperação. Localização controlada e disponibilidade não devem ser prometidas de forma independente quando a própria política pode exigir interrupção.

Fonte

[6] Fonte: InfoQ