Esta semana em cloud (13–19/jul): quem guarda a chave guarda o dado — e paga em throughput

TL;DR — Enquanto o mercado olhava para o GA do Microsoft Agent Framework, os provedores entregaram algo mais estrutural: controle dentro da camada de dados. A Oracle liberou chaves fora da nuvem, o BigQuery ganhou tags de governança globais por coluna, o AKS ganhou criptografia em trânsito para NFS e o PostgreSQL no Azure ganhou postura contínua. Todo controle novo cobra em throughput, latência ou recriação de volume — e a identidade segue como elo fraco.

Nas últimas semanas, esta newsletter girou em torno do agente: ele já está dentro da operação, faltava contê-lo. Entre 13 e 19 de julho, o agente continuou rendendo manchete — o Microsoft Agent Framework atingiu GA e levou junto uma dezena de anúncios satélites. Mas o movimento mais consequente da semana aconteceu um andar abaixo, onde quase ninguém olhou: os provedores passaram a entregar controle dentro da própria camada de dados.

Quatro lançamentos independentes, em três nuvens diferentes, na mesma semana. Vistos isolados, são notas de release. Vistos juntos, desenham uma mudança de endereço: o ponto de controle saiu do perímetro e desceu para a chave, a coluna, o pacote e a postura.

O que os quatro lançamentos da semana têm em comum?

O que apareceu	Onde o controle passa a morar	O que isso destrava
External Key Management para Fusion (Oracle)	Na chave — armazenada num KMS on-premises ou em outra nuvem, fora da Oracle	Crypto-shredding e custódia própria: revogar a chave inutiliza o dado, sem depender do provedor
IAM Data Governance Tags no BigQuery (preview, Google Cloud)	Na coluna — tags globais definidas na organização, com hierarquia de até 5 níveis	Classificar antes de proteger, com replicação automática das tags para a região secundária
Encryption in Transit para NFS no AKS (GA, Microsoft)	No pacote — TLS entre o pod e o share Azure Files NFS v4.1, via CSI driver	Criptografia de trânsito com um parâmetro no StorageClass, sem VPN nem sidecar
Defender CSPM para PostgreSQL Flexible Server (GA, Microsoft)	Na postura — avaliação contínua do banco gerenciado	Detecção de misconfiguration, risco de IAM e gap de compliance sem varredura manual

A leitura é direta: durante anos, proteger dado em nuvem significava construir camadas em volta dele — VPN, bastion, sidecar de criptografia, varredura periódica. O que a semana entregou foi o oposto: controle embutido, ativado por configuração. É a diferença entre security as bolt-on e security as built-in, e ela muda o desenho: menos infraestrutura acessória para manter, mais decisões de política para acertar.

Vale a honestidade sobre maturidade. Dos quatro, dois estão em GA (NFS EiT e Defender CSPM), um é preview (as tags do BigQuery) e um é liberação de recurso para uma linha específica de produto (EKMS para Fusion). Não é um cronograma de migração — é um sinal de direção.

Se o controle é nativo, por que ele ainda custa caro?

Porque ninguém revogou a física. Cada um desses controles cobra em algum lugar, e a semana ofereceu o exemplo mais didático disso quase como nota de rodapé.

A Oracle anunciou os Bucket Keys para SSE-KMS no OCI Object Storage. O problema que eles resolvem é revelador: quando você usa chaves gerenciadas pelo cliente, cada objeto gravado ou lido dispara uma chamada ao Vault KMS. Em buckets de alta taxa de transferência, isso vira latência em PUT/GET e, no limite, throttling. Os Bucket Keys reduzem essas chamadas repetitivas — mantendo o controle sobre a chave. Ou seja: um recurso inteiro criado para pagar a conta operacional do controle que você escolheu ter.

O mesmo padrão aparece no AKS. O EiT para NFS não tem custo adicional de licença, mas o overhead de TLS aparece em throughput e latência — e a documentação recomenda benchmark antes de mover workload de I/O intenso. Some duas armadilhas operacionais que não estão no título do anúncio: o recurso não é retroativo (volume criado sem EiT precisa ser recriado, com tudo que isso implica de janela e migração de dados) e depende de versões recentes do CSI driver e do kernel dos nodes.

A conclusão prática para quem planeja: trate cada controle novo como mudança de capacidade, não como flag. O custo raramente está na fatura; está no throughput, na janela de recriação e no trabalho de classificação que as tags do BigQuery exigem antes de virarem política.

Ativar criptografia e governança de coluna sem derrubar throughput exige medir antes e desenhar a migração. A gente faz esse levantamento com o seu time.

E o elo mais fraco continua sendo a identidade?

Continua. E a melhor peça da semana foi justamente a que mostra o ataque vindo pelo outro lado.

A Mandiant publicou uma análise sobre funções cloud expostas que vale ler como antídoto ao otimismo dos anúncios acima. O encadeamento é banal e devastador: uma função serverless pública, sem autenticação, sofre command injection ou LFI/RFI; o atacante alcança o metadata server, extrai um token OAuth e passa a operar com a service account associada — que, na prática, quase sempre tem mais permissão do que a função precisava. Daí ao comprometimento do projeto inteiro é questão de minutos. As mitigações recomendadas não são exóticas: privilégio mínimo na service account, segregação de projetos, WAF na borda e ciclo de desenvolvimento seguro.

Ponha as duas histórias lado a lado. De um lado, controles cada vez mais finos dentro do dado — mascaramento por coluna, TLS por volume, chave sob custódia própria. Do outro, uma identidade excessivamente ampla que atravessa todos eles por cima. Mascarar coluna com service account irrestrita é trancar a gaveta e deixar a chave na porta. A ordem correta de investimento é a inversa da ordem dos anúncios: identidade primeiro, dado depois.

Foi por aí que caminhou o resto do bloco de identidade da semana. A extensão de autorização empresarial do MCP (EMA) propõe que o IdP corporativo volte a ser o ponto central de decisão, emitindo uma credencial validada pelos servidores MCP, em vez de consentimentos individuais espalhados — com a ressalva honesta de que Entra ID e App Service hoje entregam a governança centralizada, mas ainda não o protocolo EMA nativo. E o KeycloakCon Japan 2026 insistiu na tecla que nos interessa: usar padrões abertos — OAuth 2.0, token exchange, MCP — para governar acesso, inclusive de agentes, sem entregar a fonte de identidade a um fornecedor. É a mesma tese que já defendemos ao analisar IAM unificado sem lock-in com o Keycloak Organizations: a portabilidade da identidade é o que preserva sua liberdade de mudar de nuvem.

O que mais mereceu atenção

Fora do eixo de dados e identidade, cinco movimentos que valem registro:

HAMi entrou como projeto incubado da CNCF. O middleware de virtualização de GPU para Kubernetes permite fracionar aceleradores (GPU, NPU, DCU, MLU) por memória, core ou dispositivo, com isolamento em runtime e políticas de scheduling como binpack e topology-aware. Para quem tem GPU cara e subutilizada, é o caminho aberto para densidade sem comprar mais hardware.
Broadcom virou membro Platinum da CNCF e contribuiu o Velero — backup e restore nativo de Kubernetes — para o Sandbox. Um projeto que muita gente já usa em produção ganhando governança de fundação é boa notícia para quem precisa justificar dependências.
Azure Front Door ganhou Edge Actions: funções JavaScript executadas na borda com isolamento por hypervisor (Hyperlight), para roteamento e personalização sem tocar na origem.
O Microsoft 365 detalhou o COSMIC, sua camada de platform engineering sobre AKS. A lição não é o produto interno, é o padrão: centralizar provisioning, deployment seguro e observabilidade em vez de cada time reinventar a roda.
O Amazon SQS completou 20 anos. Num mês dominado por lançamentos de agentes, vale a nota: a fila continua sendo a peça mais entediante e mais confiável da arquitetura desacoplada.

O que isso muda para quem opera infra no Brasil?

Muda a ordem da fila de trabalho, e o argumento de compliance fica mais fácil de sustentar.

Para quem responde à LGPD, a semana entregou munição concreta. Criptografia em trânsito no NFS deixou de exigir VPN ou sidecar e virou parâmetro de StorageClass. Mascaramento por coluna no BigQuery ficou mais governável, com classificação desacoplada da política e replicação para failover. Postura de banco gerenciado passou a ser contínua em vez de auditoria trimestral. São três itens de relatório de adequação que saem do backlog com esforço de configuração, não de projeto.

O item mais estratégico, porém, é a chave. A discussão de soberania no Brasil costuma parar na região do datacenter, e é uma discussão incompleta: hospedar em São Paulo não significa muito se o provedor detém a chave e pode ser compelido a usá-la. O modelo de key management externo desloca a conversa para onde ela decide — a custódia. E, não por acaso, é também o modelo que preserva portabilidade: com a chave num KMS sob seu controle, trocar de nuvem deixa de significar entregar a custódia ao próximo fornecedor. A mesma lógica que aplicamos ao operar Kubernetes on-premises em infraestrutura estatal sem lock-in vale aqui: o que você não pode terceirizar é o controle.

Se for para tirar uma única ação da semana, tire esta: antes de habilitar qualquer um desses controles, audite as service accounts que atravessam a sua camada de dados. O anúncio bonito é o da criptografia; o incidente real começa numa função exposta com permissão demais.

Perguntas Frequentes

Guardar a chave fora da nuvem do provedor resolve a soberania de dados?
Resolve a parte que mais importa, mas não sozinha. O External Key Management da Oracle para Fusion permite manter as chaves num KMS on-premises ou em outra nuvem, o que habilita crypto-shredding — revogar a chave e tornar o dado ilegível sem depender do provedor. Isso é o núcleo técnico da soberania: quem detém a chave detém o dado. Mas soberania completa também envolve onde o dado reside, quem administra o plano de controle e quais jurisdições podem compelir acesso. Trate a chave externa como condição necessária, não suficiente.

Habilitar criptografia em trânsito no NFS do AKS tem impacto em performance?
Tem, e você precisa medir antes. O EiT para Azure Files NFS v4.1 chegou ao GA via CSI driver e não cobra a mais pelo recurso, mas o overhead de TLS aparece em throughput e latência — o que pesa em workloads de I/O intenso, como bancos de dados e pipelines de treino. Some a isso duas restrições operacionais: o recurso não é retroativo (volumes criados sem EiT precisam ser recriados) e depende de versões recentes do CSI driver e do kernel dos nodes. Faça benchmark com e sem, no seu perfil de carga.

Qual a diferença prática entre as policy tags e as novas data governance tags do BigQuery?
As policy tags são regionais e não têm disaster recovery automático. As IAM Data Governance Tags, em preview, são definidas no nível da organização e replicadas para a região secundária, mantendo a postura de segurança no failover. Elas também aceitam hierarquia de até cinco níveis (por exemplo, data_class > pii > private > email) e desacoplam a classificação da aplicação da política — você marca as colunas primeiro e decide depois o que mascarar. Atenção: as data policies em si continuam regionais e precisam existir na mesma região da tabela.

Se eu mascarar as colunas sensíveis, meu dado está protegido?
Não, se a identidade que consulta for ampla demais. A análise da Mandiant sobre funções cloud expostas mostra o caminho inverso do ataque: uma função serverless sem autenticação sofre command injection, o atacante extrai um token OAuth do metadata server e passa a agir com a service account — que costuma ter muito mais permissão do que a tarefa exigia. Controle de coluna é a última camada, não a primeira. Antes dela vêm privilégio mínimo na service account, segregação de projetos e WAF na borda.

Dá para adotar esses controles sem me prender a um provedor?
Dá, e a semana ofereceu os dois caminhos. O modelo de chave externa é justamente o que preserva portabilidade: o KMS fica sob seu controle, e migrar de nuvem não significa reencriptar tudo sob a custódia do próximo fornecedor. Na identidade, a discussão do KeycloakCon Japan 2026 apontou padrões abertos — OAuth 2.0, token exchange, MCP — como a base para governar acesso sem depender de um IdP proprietário. O risco de lock-in não está em usar o controle nativo, e sim em deixar a custódia da chave e a fonte de identidade dentro de um único fornecedor.

Fontes: