# Onde rodar uma carga de trabalho que precisa ser confidencial > Nitro Enclaves, VMs confidenciais, dstack, ancorado em blockchain — quatro lugares para colocar a parte do seu produto que o operador não pode ler, e como escolher um sem queimar seis semanas numa prova de conceito. 2026-09-20 · https://synsema.com/pt/blog/onde-rodar-uma-carga-de-trabalho-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](https://synsema.dev/en/0.6.x/24-attestation).