Onde rodar uma carga de trabalho que precisa ser confidencial

Você decidiu que alguma parte do seu produto precisa rodar onde você, o operador, não consegue ler os dados. Um banco não manda o arquivo de outro jeito; um hospital também não; ou você simplesmente não quer ser a parte que guarda uma cópia em texto claro do que os clientes de um concorrente fazem.

A decisão seguinte é onde a caixa vive. Existem quatro respostas práticas, e elas não são intercambiáveis. O que vem abaixo é a versão curta de cada uma, com as partes que de fato decidem a questão — não a página de marketing.

AWS Nitro Enclaves§

Uma segunda VM, enxuta, recortada de uma instância EC2 que você já paga. Sem armazenamento persistente, sem acesso interativo e sem rede própria: tudo passa por um canal vsock na instância pai, que você mesmo faz o proxy. A imagem é um EIF, e nitro-cli build-enclave imprime a medição (PCR0) que seus clientes vão fixar.

• A verificação é a mais fácil das quatro. O documento é assinado pela PKI de atestação da própria AWS, e um cliente em Synsema o verifica contra a raiz fixada dentro do motor — cadeia completa, assinatura COSE, falhando fechado na primeira dúvida.
• Sem chaves seladas. O Nitro não deriva uma chave a partir da medição; o caminho padrão é liberar uma do AWS KMS condicionada ao documento de atestação. Coloque isso no planejamento, é trabalho de verdade.
• Escolha quando sua infraestrutura já está na AWS, a contraparte é uma empresa que vai aceitar "assinado pela AWS" como raiz de confiança, e a carga é requisição/resposta em vez de um serviço com estado de vida longa.

VMs confidenciais: Intel TDX e AMD SEV-SNP§

Google Confidential Space, VMs confidenciais do Azure, Constellation e Contrast, e o mesmo silício em outras nuvens. A unidade é a VM inteira: você roda seu contêiner como rodaria em qualquer lugar, e a plataforma mede a imagem que subiu.

• De longe o menor esforço. Seu deploy de sempre, suas ferramentas de sempre. No Linux ≥ 6.7 o relatório vem do configfs-tsm sem nenhum SDK do fabricante dentro da imagem.
• A verificação é a metade difícil. Hoje um cliente dessas plataformas verifica o quote com o material do fabricante (Intel PCS, AMD KDS) ou, no Confidential Space, confere o token assinado da plataforma — que é verificação de JWT comum. Defina quem faz isso antes de prometer a alguém.
• Escolha quando a carga é um serviço normal que precisa ficar no ar, manter estado e escalar, e quando a contraparte está confortável com o provedor de nuvem como parte da história de confiança.

dstack (Phala)§

Um agente guest dentro de uma VM TDX que entrega ao seu contêiner o quote e, além disso, chaves derivadas da identidade da aplicação. Você monta o socket dele no contêiner e roda o compose como sempre.

• Estado selado, sem um projeto de KMS. attest_key("state") pede ao agente uma chave atrelada a esta aplicação; você cifra seu banco ou seu arquivo de estado com ela e outra build simplesmente não consegue ler.
• O quote carrega um event log, então quem verifica consegue reproduzir a medição que cobre o seu arquivo de compose — o deploy, não só a imagem.
• Escolha quando você quer estado confidencial com pouca cerimônia, ou quando seus usuários já estão nesse ecossistema.

Ancorado em blockchain§

Quando a contraparte não é uma empresa e sim um contrato — liquidação, um motor de matching, uma política de pagamentos — o trabalho do enclave é produzir um estado que a cadeia aceite. Os adaptadores guest do Synsema rodam com os rótulos de fluxo de informação sempre ligados e a cadeia como sumidouro público, então o que vai on-chain é exatamente o que o programa desclassificou e nada mais.

• Escolha quando a disputa contra a qual você está desenhando é "provar para todo mundo que a regra foi seguida", e não "deixar uma contraparte específica conferir antes de mandar um arquivo".

As três perguntas que realmente decidem§

1. Quem não pode ler os dados — e essa pessoa é o seu host? Se a resposta inclui o provedor de nuvem, uma VM confidencial nesse mesmo provedor é uma história mais fraca do que um enclave com uma raiz de atestação independente. Se são seus próprios funcionários e operadores, qualquer uma das quatro serve. 2. Quem verifica, e vai mesmo rodar a ferramenta? Um deploy confidencial que ninguém confere é um deploy comum com custo extra. Se o time de segurança da contraparte vai rodar um verificador, escolha a plataforma cujo documento dê menos trabalho de conferir. Se não vai, não compre nada exótico: escolha a mais barata de operar e publique a lista de verificação mesmo assim. 3. O estado precisa sobreviver a um restart? As chaves seladas são a linha divisória. O dstack as deriva para você; o Nitro te manda ao KMS; em VMs confidenciais depende do produto. Responda isso antes de escrever o schema, não depois.

O que fixar, e o que não§

Um detalhe que custa uma semana aos times: o digest da imagem não é a medição. Um digest Docker/OCI fixa o que você implantou; PCR0 no Nitro, MRTD e RTMRs no TDX, measurement no SEV-SNP vêm de como a plataforma embrulhou aquela imagem — a build do EIF, a imagem de sistema do dstack mais o hash do compose, a política de imagem no Confidential Space. Pegue o valor esperado da própria etapa de build da plataforma e publique esse como o que os clientes devem esperar. Fixe os dois: o digest para os seus deploys, a medição para os seus clientes.

Onde a Synsema Platform entra§

O enclave é a parte pequena. Tudo em volta — o site, o cadastro, o dashboard, a fila, o armazenamento do texto cifrado, a cobrança, os jobs de conciliação — é software comum que não deve ficar dentro da caixa, e essa parte é implantada aqui com um comando, com HTTPS, segredos e uma trilha de auditoria. O próximo post é sobre essa divisão, e sobre por que encolher o enclave costuma ser a decisão de maior alavancagem do projeto inteiro.

Os detalhes do lado do motor — a capacidade attest, os drivers, serve --attested e o attestation_verify do cliente — estão documentados em synsema.dev.