Deployment soberano e confidencial: VPC, on-prem, air-gapped e TEEs
Pergunte à maioria das equipas onde corre a sua IA e recebe uma resposta única: na cloud, ou on-premises, ou, se forem cautelosas, isolada da rede. Uma topologia, escolhida uma vez, aplicada a tudo. É uma decisão arrumada e, para um negócio não regulado, normalmente chega.
Só que, numa empresa regulada, uma topologia única é ou desperdiçadora ou perigosa, e muitas vezes as duas ao mesmo tempo. A topologia de deployment não é uma escolha que se faz para o sistema todo. É uma regra de encaminhamento conduzida pela sensibilidade dos dados, e tem de falhar fechada. Escolha uma topologia para tudo e ou sobrecondiciona trabalho barato e não sensível, fechando-o num air-gap de que nunca precisou, ou, muito pior, deixa dados regulados fluir para um sítio onde nunca deviam ter ido porque esse sítio era conveniente para outra coisa. O modelo certo é um espectro de topologias, e uma regra que encaminha cada carga para o ambiente menos exposto que a sua classe de dados permite.
Há também um ponto mais recente nesse espectro que a maioria das arquiteturas de referência salta, e é o que resolve o caso mais difícil: como processar dados regulados em infraestrutura que não controla fisicamente sem os expor, usando computação confidencial e ambientes de execução confiáveis. É aí que isto fica genuinamente interessante.
O espectro de topologias, encaminhado por sensibilidade
Pense no deployment como uma escada de exposição decrescente, e na sensibilidade dos dados como a coisa que decide quão alto tem de subir para cada carga.
No extremo tolerante à exposição está uma conta de cloud que traz consigo, com elasticidade e o menor peso operacional, ao custo de os dados saírem da sua conta para a região do modelo, se o permitir. Acima disso, um VPC fixado a uma região mantém os dados dentro do seu perímetro de cloud e da zona de residência exigida, em troca de ser você a operar a fronteira e o encaminhamento. Mais acima, o deployment on-premises dá controlo físico total quando as regras vedam qualquer processamento externo, e entrega-lhe em troca o planeamento de capacidade e a operação de GPUs. No topo, um ambiente air-gapped remove por completo o caminho de saída para o trabalho de sensibilidade máxima, e paga esse isolamento com atualizações de modelo e operações manuais e deliberadas.
O erro é ler essa escada como um menu e escolher um degrau para a organização toda. Não é um menu. É uma tabela de encaminhamento. Classifica os dados que uma dada carga transporta, e a classificação diz-lhe o degrau mais baixo em que essa carga pode correr. Um único processo de negócio abrange rotineiramente várias classes: um passo lê um dossiê regulado e pertence ao alto da escada, outro redige uma notificação genérica e pode ficar em baixo. Por isso o encaminhamento acontece passo a passo, e não uma vez para o sistema, e o mesmo processo pode tocar em duas topologias numa só execução.
Computação confidencial: processar dados regulados que não consegue isolar por completo
Eis o caso que a escada clássica trata mal. Por vezes precisa da elasticidade ou do hardware especializado de infraestrutura que não possui fisicamente, mas os dados são sensíveis demais para os expor a quem opera essa infraestrutura. O air-gap diz que não. O VPC diz "confie nos operadores do seu fornecedor de cloud". Nenhum satisfaz quando o modelo de ameaça inclui a própria plataforma.
É isto que a computação confidencial resolve, e o mecanismo é um ambiente de execução confiável, um TEE. Um TEE é um enclave imposto por hardware em que os dados são decifrados e processados mantendo-se cifrados em todo o resto: em memória, o enclave guarda-os numa região que o sistema operativo anfitrião, o hipervisor e o operador de cloud não conseguem fisicamente ler. Os dados ficam protegidos não só em repouso e em trânsito, os dois estados que toda a gente já protege, mas em uso, o estado que historicamente foi a lacuna. A carga corre, os dados regulados são processados, e o operador da máquina onde correu nunca teve a possibilidade de os ver.
Duas propriedades fazem disto um controlo em vez de uma promessa. O enclave é imposto pelo hardware do CPU, e não por configuração de software que um operador privilegiado pudesse desativar. E a atestação remota permite-lhe verificar criptograficamente, antes de enviar quaisquer dados, que o código a correr dentro do enclave é exatamente o código que espera e que está genuinamente a correr num TEE real. Não confia na garantia do operador de que os seus dados estão protegidos. Verifica o enclave, depois liberta-lhe os dados, e a verificação é uma assinatura que pode guardar como evidência.
Para uma organização regulada, isto reenquadra uma decisão que era binária. A pergunta antiga era "possuir o hardware, ou expor os dados". A computação confidencial acrescenta uma terceira resposta para uma fatia específica e valiosa de cargas: correr em hardware que não é seu, sobre dados que de outra forma não poderia expor, porque o ambiente é atestado e o operador fica criptograficamente de fora. Não substitui on-prem nem air-gap nos casos mais extremos. Estende o alcance da soberania a sítios onde antes não podia chegar.
Encaminhamento por soberania que falha fechado
Um espectro de topologias só é tão seguro quanto a regra que lhe atribui cargas, e a propriedade que torna essa regra defensável é concreta: falha fechada.
A política de encaminhamento classifica os dados por sensibilidade e fixa cada classe às topologias em que pode correr. Dados regulados e pessoais ficam dentro do seu perímetro por omissão, seja esse perímetro um VPC fixado a uma região, on-prem, um air-gap ou um enclave atestado. Só cargas explicitamente não sensíveis podem alcançar um modelo em região externa, e apenas quando uma política permitiu que essa classe saísse. A parte decisiva é o que acontece sob incerteza: quando uma classificação é ambígua, o sistema trata os dados como sensíveis e mantém-nos no ambiente mais protegido que as classes possíveis permitem. A omissão protege-o. Relaxá-la exige uma decisão deliberada e registada, não uma distração.
É essa a diferença entre "os seus dados nunca saem de casa" como frase de marketing e como arquitetura. Como arquitetura, a saída é negada por omissão e permitida apenas por política explícita, por classe de dados, por passo, com cada relaxamento registado. Uma má configuração não abre uma porta em silêncio, porque a porta está fechada a não ser que algo a tenha aberto deliberadamente. Falhar fechado é toda a razão por que um supervisor pode acreditar na alegação de soberania, porque significa que o modo de falha do sistema é a sobreproteção, e não a fuga.
A DORA e a residência são os motores, não a papelada
Nada disto é engenharia por si. É a forma que a obrigação regulatória impõe, e duas obrigações em particular conduzem-na.
A residência de dados é a direta. Regras que exigem que certos dados permaneçam numa jurisdição transformam "onde corre o modelo?" numa pergunta jurídica com resposta física. Um VPC fixado a uma região, um cluster on-prem, ou um enclave atestado na jurisdição certa não são uma preferência; são a forma de satisfazer uma regra que uma região por omissão conveniente violaria. Os regimes de resiliência operacional como a DORA empurram na mesma direção: preocupam-se com o risco de concentração e com a sua capacidade de manter um processo crítico a correr e inspecionável, que é exatamente o que uma postura encaminhada, agnóstica e com deployment em qualquer lado dá e uma topologia única e cablada não dá. Quando o seu deployment é uma regra de encaminhamento que controla, em vez da omissão de um fornecedor, consegue demonstrar a um supervisor onde os dados regulados ficam e como o processo sobrevive a um fornecedor ou uma região ficarem inutilizáveis.
Por isso, a pergunta a levar à próxima revisão de arquitetura não é "cloud ou on-prem?". É para cada classe de dados deste processo, qual é o ambiente menos exposto em que pode correr, o encaminhamento manda-a para lá por omissão, e o sistema falha fechado quando não tem a certeza? Se consegue responder a isso classe a classe, e se a computação confidencial estendeu o seu alcance às cargas que antes forçavam uma escolha impossível, tem uma arquitetura de soberania. Se a sua resposta é uma topologia para tudo, tem a esperança de que nada sensível tome nunca o caminho conveniente.
Se quiser mapear as suas classes de dados nas topologias permitidas, e descobrir onde é que um enclave atestado muda a resposta, marque uma reunião e traga-nos o processo com os dados mais sensíveis do ponto de vista jurisdicional.