1. O princípio#
O dado clínico é do paciente e do profissional que o produziu. A MedDeck LTDA opera o diagnos para que esse dado circule com segurança entre quem precisa dele — não para acumular acesso a ele.
Isso tem uma consequência concreta na arquitetura. O diagnos foi construído para que nem a própria MedDeck consiga ler o conteúdo guardado no cofre de um workspace — com duas exceções nomeadas, que a seção 7 descreve em vez de esconder. Não é uma promessa de comportamento ("nós não olhamos"), é uma limitação técnica ("nós não conseguimos abrir"). A diferença importa: promessa de comportamento depende de disciplina interna, e limitação técnica continua valendo mesmo quando algo dá errado do nosso lado.
Três regras orientam cada decisão de segurança do produto:
- O conteúdo é cifrado antes de sair do dispositivo de quem o criou. O servidor guarda bytes que não sabe abrir.
- Cada workspace é um compartimento fechado. O isolamento entre clientes é estrutural, não uma condição de filtro que alguém pode esquecer de escrever.
- Nada é afirmado sem mecanismo real por trás. O que ainda não existe está escrito na seção 10, com o mesmo destaque do que já existe.
2. O cofre e o conhecimento zero#
Cada workspace tem um cofre. Exame, laudo, anotação, arquivo enviado e dado de paciente ficam dentro dele.
A chave que abre esse cofre nasce no dispositivo de quem é titular do dado e nunca é enviada ao servidor em texto claro. O conteúdo é cifrado ali, antes de sair do aparelho. O que chega ao servidor já é um bloco embaralhado, acompanhado apenas do necessário para guardá-lo e devolvê-lo depois.
Pense no servidor como um depósito de caixas lacradas. Ele sabe o tamanho de cada caixa, quando ela chegou e qual conta a entregou. Não tem a chave de nenhuma delas. É isso que a palavra "conhecimento zero" descreve: o serviço opera sobre o dado sem conhecer o dado.
Para a equipe técnica
São duas camadas independentes, com propósitos diferentes.
Cifra do lado do cliente (CSE, na sigla em inglês para Client-Side Encryption) — ChaCha20-Poly1305 em modo stream com catraca. ChaCha20-Poly1305 é uma cifra autenticada com dados associados (AEAD) padronizada na RFC 8439. O modo stream avança a chave a cada trecho do arquivo e autentica a posição de cada trecho, então um bloco reordenado, truncado ou adulterado falha na verificação em vez de ser decifrado. Isso permite cifrar um exame de gigabytes sem carregá-lo inteiro na memória e sem abrir mão da autenticação.
Cifra do lado do servidor (SSE) — AES-256 sobre o que fica em repouso na infraestrutura dos fornecedores, aplicada por cima do que já chegou cifrado.
A chave de conteúdo é derivada no próprio dispositivo, a partir da mistura de duas fontes de entropia: um valor aleatório gerado localmente e uma semente entregue pelo servidor, combinados por uma função de derivação. Prever a chave exige prever as duas metades — um gerador de números aleatórios fraco no aparelho não compromete a chave sozinho. A chave derivada é selada sob a chave do grupo de segurança do workspace e nunca trafega em claro. A chave de cada imagem, vídeo ou arquivo no formato Digital Imaging and Communications in Medicine (DICOM) enviado para um exame, e uma chave de cópias de cada exame derivada de mão única da chave dele, são seladas também para a chave do processador de mídia — a exceção descrita na seção 7. A chave do exame em si nunca é selada.
As duas camadas protegem contra coisas diferentes. A SSE protege contra quem obtenha acesso ao meio físico de armazenamento ou a uma cópia de backup do fornecedor. A CSE protege contra qualquer pessoa que tenha acesso ao servidor — o que inclui a equipe da MedDeck e o próprio fornecedor de infraestrutura. Uma camada sem a outra deixaria de fora exatamente o adversário mais importante.
A contrapartida é honesta e vale dizer em voz alta: como a MedDeck não tem a chave, a MedDeck também não consegue devolver o acesso sozinha. A recuperação de um cofre depende sempre da cooperação de um administrador daquele workspace. Um serviço que conseguisse restaurar seu conteúdo sem você seria, pela mesma porta, um serviço capaz de lê-lo sem você.
3. Como você entra#
A senha de segurança — a que destrava o cofre — nunca trafega pela rede e nunca é guardada pelo servidor. A autenticação usa o protocolo OPAQUE (troca de chave autenticada por senha), em que o servidor consegue verificar que você sabe a senha sem nunca recebê-la e sem guardar nada que permita descobri-la depois.
O efeito prático é direto: não existe, em lugar nenhum da infraestrutura, uma lista de senhas para vazar. Um atacante que copiasse o banco inteiro não sairia de lá com a senha de ninguém.
Passkeys (WebAuthn) são suportadas. A chave da passkey fica no seu dispositivo, não sai dele e não pode ser reutilizada em outro site — o que elimina a categoria inteira de ataque em que alguém copia uma credencial e a usa de outro lugar.
A conta sobe por níveis de segurança, e cada nível destrava mais capacidade dentro do workspace: e-mail verificado, dispositivo de segurança registrado com passkey, senha de segurança, telefone verificado e verificação de identidade. Quem administra um workspace ou assina laudo passa pelos níveis mais altos, porque responde por mais coisa.
Para quem só usa o sistema
Para a maioria das pessoas, manter o sistema operacional atualizado e usar uma passkey já resolve.
Se o seu trabalho te expõe mais que a média — jornalismo, pesquisa sensível, atuação pública, qualquer situação em que alguém teria motivo para ir atrás especificamente de você —, vale saber onde termina o que a plataforma consegue fazer. O diagnos protege o dado no trânsito e no servidor, mas o conteúdo aparece em claro na tela do seu dispositivo, porque é ali que ele precisa ser lido. Um aparelho comprometido derrota qualquer cifra, em qualquer produto.
Nesse cenário, há duas coisas que dependem de você e ampliam a proteção: usar um sistema operacional mais resistente a comprometimento, como o QubesOS, em hardware que você tenha motivo para confiar; e ativar os níveis mais altos de segurança de conta, até a verificação de identidade. Nenhuma das duas é exigida para usar o diagnos. Elas existem para quem precisa delas.
4. Isolamento entre workspaces#
Cada workspace tem banco de dados, armazenamento de arquivo e índice de busca próprios. Não é uma coluna de identificação dentro de uma tabela compartilhada com todos os clientes.
A diferença aparece no pior dia. Num sistema de tabela compartilhada, um erro em uma única condição de filtro expõe o dado de outro cliente. No diagnos, um erro desse tipo não tem para onde vazar: o dado do outro cliente não está no mesmo banco, nem no mesmo armazenamento, nem no mesmo índice.
As chaves também são por workspace. A chave que abre um cofre não abre nenhum outro, então nem mesmo um vazamento de chave se propaga entre clientes.
A exceção é a chave do processador de mídia (seção 7). Ela é uma só para todos os workspaces, e por isso fica guardada apenas dentro da função isolada do processador, que nunca lê arquivo. Cada trabalho de processamento, por sua vez, roda num ambiente de uso único que atende um só workspace e recebe só as chaves derivadas dos arquivos daquele trabalho.
5. Em trânsito#
Todo o tráfego entre o seu dispositivo e o diagnos usa Transport Layer Security (TLS) — a mesma cifra de transporte que põe o cadeado no navegador. Não existe rota em texto claro, nem para conteúdo, nem para chamada de sistema.
O conteúdo do cofre já viaja cifrado antes disso. O TLS protege o resto: os metadados da requisição, as chamadas que o aplicativo faz e o que não é conteúdo de cofre.
A aplicação não é exposta como um servidor próprio na internet. O tráfego entra por uma borda gerenciada, com firewall de aplicação web (WAF) e proteção contra volume anormal e abuso. Quem tenta alcançar a aplicação nunca fala direto com ela.
6. Onde o dado mora#
Todo dado pessoal tratado pelo diagnos fica nos Estados Unidos ou na União Europeia. Nunca em uma terceira região.
Estes são os fornecedores que sustentam a operação, o que cada um faz e onde o dado que passa por ele fica guardado:
| Empresa | Função | Onde fica o dado |
|---|---|---|
| Cloudflare, Inc. | Hospedagem, rede de entrega de conteúdo, banco de dados de borda e armazenamento de arquivo; passagem das chamadas ao modelo de inteligência artificial, sem guardar o conteúdo (AI Gateway) | União Europeia |
| Google LLC | Autenticação de conta, sincronização de dado em tempo real e modelo de inteligência artificial Gemini (Vertex AI) dos agentes de laudo | Estados Unidos |
| Modal.com | Processamento de mídia — compressão e conversão de exame enviado | Estados Unidos |
| Stripe, Inc. | Processamento de pagamento e gestão de assinatura | Estados Unidos |
| PostHog, Inc. | Análise de uso do produto | Estados Unidos |
| Sentry (Functional Software, Inc.) | Monitoramento e diagnóstico de erro de software | União Europeia |
| Didit Identity, Inc. | Verificação de identidade do representante legal, com comparação biométrica entre rosto e documento | União Europeia |
| Anthropic, PBC | Modelo de inteligência artificial do assistente do espaço de trabalho | Estados Unidos |
Nenhum deles recebe a chave do cofre, porque essa chave não existe do lado do servidor. O fornecedor que guarda o arquivo de um exame guarda um bloco cifrado — o mesmo bloco que a MedDeck vê.
As exceções são as duas da seção 7. A primeira passa pela Modal.com: o processador de mídia do diagnos roda na infraestrutura dela, guarda ali a chave que abre a mídia enviada para exames e, durante o processamento, decifra essa mídia nos Estados Unidos para gerar as cópias otimizadas, que voltam cifradas para o armazenamento na União Europeia. A segunda é o manifesto do visualizador de imagem, que carrega nome e identificador de paciente em claro e repousa na infraestrutura do fornecedor de hospedagem sob controle de acesso, não sob a chave do cofre (ref-769793806).
Nota
Esta é a mesma lista publicada na página Subprocessadores e na Política de Privacidade, mantida em um único lugar para não haver cópias que saem de sincronia. Cada fornecedor opera sob um Acordo de Processamento de Dados, fornecido a qualquer cliente que solicite.
7. Quem consegue abrir o quê#
"A MedDeck não vê nada" seria uma frase bonita e falsa. Parte do seu dado precisa estar em claro para a plataforma funcionar — uma conta precisa de um e-mail para receber convite, uma cobrança precisa de um dado de cobrança. O que segue é a divisão exata.
| A MedDeck consegue acessar | A MedDeck não consegue acessar |
|---|---|
| Dados cadastrais da conta: nome, e-mail, telefone, papel no workspace | Registro clínico do exame: texto do laudo, título, modalidade e data, em todas as versões |
| Dados de cobrança e de plano | Arquivo solto no drive, fora de exame |
| Metadados operacionais: quando um arquivo entrou, de qual conta, seu tamanho, qual operação foi executada e quando | Cadastro de paciente guardado no cofre |
| Conteúdo que você mesmo nos envia pelo suporte | Modelos de laudo guardados no cofre |
| Nome e identificador do paciente presentes no manifesto do visualizador de imagem (ver abaixo) | Anexo de exame que não seja imagem, vídeo ou DICOM |
| Pela chave do processador de mídia: imagens, vídeos e arquivos DICOM enviados para um exame, com o nome de cada arquivo, e as cópias otimizadas geradas a partir deles (ver abaixo) | Chaves que abrem o cofre, em qualquer forma utilizável |
As duas últimas linhas da coluna da esquerda são as exceções que não podem ficar escondidas numa tabela.
O processamento da mídia do exame. Para gerar as cópias otimizadas de um exame — versão de visualização e miniatura da imagem, vídeo em formato de reprodução contínua e o estudo DICOM que o visualizador abre — sem que ninguém precise estar conectado, duas chaves são seladas também para a chave do processador de mídia do diagnos: a de cada imagem, vídeo ou arquivo DICOM enviado para um exame, e uma chave de cópias de cada exame, que só serve para cifrar e abrir essas cópias. É o único ponto do produto em que um processo do sistema abre conteúdo do cofre, e por isso a MedDeck tem condição técnica de acessar essa parte do conteúdo: cada arquivo de mídia enviado para um exame, inclusive o nome dele, e as cópias otimizadas. Na operação normal, ela só é aberta durante o processamento; mas o selo fica guardado junto do exame e do arquivo, e a chave privada fica guardada no processador, então a capacidade técnica não depende de haver um processamento em curso. A chave privada do processador existe só dentro de uma função isolada que roda na infraestrutura da Modal.com e nunca lê arquivo; o servidor da aplicação e o serviço que organiza a fila de trabalho não a têm e não conseguem abrir o conteúdo. Cada trabalho roda num ambiente de uso único, que atende um só workspace, e o arquivo é convertido num processo separado que não recebe chave nenhuma. As cópias são cifradas de novo antes de serem guardadas, com a chave de cópias do exame: fora do processador, só quem tem acesso ao exame consegue abri-las.
A chave do exame em si nunca é selada. A chave de cópias é derivada dela por um caminho de mão única e não abre o registro clínico do exame — o texto do laudo, o título, a modalidade e a data, em nenhuma versão. Arquivo solto no drive, cadastro de paciente e modelo de laudo também nunca são selados para o processador.
O manifesto do visualizador. O arquivo técnico que alimenta o visualizador de imagem médica guarda nome e identificador do paciente em claro, porque o formato padrão que o visualizador lê depende desses campos. É a única estrutura de dado clínico do diagnos fora da hierarquia de chaves do cofre: ela é protegida por controle de acesso e cifrada em trânsito e em repouso na infraestrutura, mas a MedDeck consegue lê-la. Trazer esse arquivo para dentro da mesma proteção do resto do cofre — ou remover dele os campos identificadores — está em implementação (ref-769793806).
Para a equipe técnica
O selo do processador é um encapsulamento de chave híbrido, pós-quântico: X25519 combinado com ML-KEM-768 (o encapsulamento de chave resistente a computação quântica padronizado pelo governo dos Estados Unidos em 2024), com a chave final derivada por HKDF-SHA256 e o segredo selado cifrado com AES-256-GCM. O segredo selado é a chave de dados de cada arquivo de mídia (sob a qual também está cifrado o nome do arquivo) e, para cada exame, a raiz de saída — um HKDF de mão única da chave do exame, calculado no dispositivo, do qual não deriva nenhuma chave de versão do registro clínico. Os dados associados do selo amarram workspace e tipo de recurso, então um selo copiado para outro workspace não abre. A função que guarda a chave privada abre o selo, deriva só as chaves de conteúdo dos arquivos do trabalho, e entrega ao ambiente de processamento apenas essas chaves derivadas e a raiz de saída de cada exame, com credencial de armazenamento temporária restrita aos objetos daquele trabalho. O ambiente de processamento roda em contêiner isolado por gVisor, sem segredo nenhum e sem acesso a outras funções; o conversor roda num subprocesso sem privilégio, com ambiente vazio e limite de memória. Exame ou arquivo sem o selo não é processado.
Nem tudo que o produto faz acontece dentro do cofre. O assistente de inteligência artificial, por exemplo, precisa receber o texto ditado para transcrevê-lo e estruturá-lo, e por isso trabalha fora do cofre — o aviso aparece em toda janela de conversa, antes do uso, junto com o pedido para não escrever ali dado que identifique paciente. Onde um recurso trata conteúdo fora do cofre, o produto diz isso no lugar em que o recurso é usado.
Para a equipe jurídica
No tratamento do conteúdo clínico de um workspace, a MedDeck age como operadora: quem decide a finalidade do tratamento é o profissional ou a instituição de saúde titular do workspace. Nos dados da conta — cadastro, plano, cobrança, registro de acesso —, a MedDeck é controladora.
A cifra do lado do cliente muda o que é possível, não o que é devido. A MedDeck continua sujeita às obrigações de operadora previstas na Lei Geral de Proteção de Dados (LGPD) e no Regulamento Geral de Proteção de Dados (GDPR) — segurança, subcontratação controlada, auxílio ao controlador, eliminação ao fim do contrato. O que muda é a forma de cumpri-las. O processamento da mídia de exame é tratamento feito por instrução do controlador, com a Modal.com como subprocessadora, e não serve a nenhuma finalidade própria da MedDeck.
Em pedido de titular sobre conteúdo do cofre — acesso, correção, portabilidade, eliminação —, o controlador é quem executa, usando as ferramentas do produto, porque só ele tem a chave. A MedDeck auxilia com o que está do seu lado: metadados, registros e a eliminação definitiva dos blocos cifrados e do material de chave associado, o que torna o conteúdo irrecuperável para qualquer parte.
Em ordem judicial dirigida à MedDeck, a resposta é limitada pelo mesmo fato técnico, com as exceções desta seção: entregamos o que temos. Da mídia enviada para exames e das cópias geradas a partir dela, a MedDeck tem condição técnica de produzir o conteúdo em claro; do resto do cofre, inclusive do registro clínico do exame, o que temos é um bloco cifrado que não sabemos abrir. Isso não é objeção processual nem recusa de colaborar — é a descrição correta do que existe na nossa posse.
Fora das exceções desta seção, essa limitação vale contra nós mesmos. Ela não é um recurso que possa ser desligado para um cliente específico, para um pedido específico ou para uma autoridade específica: não há nenhum caminho no produto que devolva conteúdo de cofre em claro a quem não tem a chave.
Para autoridades com respaldo judicial
Diante de requisição com respaldo judicial, a MedDeck pode fornecer: dados cadastrais da conta, dados de cobrança, metadados operacionais (data, horário, conta que executou a operação, tamanho e identificador do objeto), os blocos cifrados tal como estão armazenados, e o nome e o identificador de paciente do manifesto do visualizador. Das imagens, dos vídeos e dos arquivos DICOM enviados para um exame e selados para o processador de mídia, tem condição técnica de fornecer em claro o arquivo, o nome dele e as cópias otimizadas geradas a partir dele.
A MedDeck não pode fornecer: o conteúdo em claro do resto do cofre — registro clínico do exame (texto do laudo, título, modalidade e data), arquivo solto no drive, cadastro de paciente, modelo de laudo, anexo de exame que não seja imagem, vídeo ou DICOM —, as chaves que o abrem, nem qualquer forma de acesso que contorne a cifra do lado do cliente nesse conteúdo. Essas chaves nunca estiveram em posse da MedDeck. Não existe chave-mestra, função administrativa de leitura nem canal de suporte capaz de abrir um cofre — uma ordem para entregar esse conteúdo em claro é tecnicamente inexequível, e a alternativa real é dirigir a requisição ao controlador do workspace, que detém a chave.
O procedimento de recebimento, os critérios de verificação da requisição, os prazos e a notificação ao cliente quando a lei a permite estão descritos no documento Solicitações de Autoridades.
8. Registro e auditoria#
Operação sensível deixa registro. Destravar um cofre, convidar ou remover uma pessoa, mudar permissão, registrar ou revogar um dispositivo, assinar um laudo, exportar dado: cada uma dessas ações grava quem executou, o que foi executado e quando.
O registro guarda o fato, não o conteúdo. Ele mostra que um arquivo foi acessado por uma conta às 14h32; não mostra — nem poderia — o que havia dentro dele. Isso é consequência direta do cofre descrito na seção 2.
Esse registro é o que permite responder "quem fez o quê e quando" quando a pergunta aparece: numa apuração interna, num pedido de cliente sobre a própria operação ou na investigação de um incidente. Sem ele, qualquer resposta a essas perguntas seria reconstrução de memória.
9. Se algo der errado#
Nenhuma arquitetura elimina a possibilidade de incidente. O que uma empresa controla é o que faz quando ele acontece, e em quanto tempo você fica sabendo.
O tratamento segue quatro passos, nesta ordem:
- Conter. Interromper o que está em curso — revogar credencial, bloquear acesso, isolar o componente afetado.
- Apurar o escopo. Determinar o que foi atingido, quais workspaces e quais categorias de dado, usando os registros da seção 8.
- Corrigir. Eliminar a causa e verificar que a correção funcionou.
- Comunicar. Avisar quem foi afetado e as autoridades competentes.
A comunicação ao cliente afetado acontece assim que o escopo estiver determinado, e diz o que se sabe, o que ainda não se sabe e o que ele precisa fazer do lado dele. Não esperamos ter todas as respostas para dar a primeira notícia.
Quando o incidente atinge dado pessoal com risco relevante, a comunicação à autoridade segue o prazo legal: três dias úteis para a Autoridade Nacional de Proteção de Dados (ANPD), conforme a Resolução CD/ANPD nº 15/2024, e 72 horas para a autoridade europeia, conforme o Artigo 33 do GDPR.
Os passos acima são o que a equipe executa hoje. A formalização completa desse processo — Política de Resposta a Incidentes aprovada, manual de execução e simulação periódica — está em implementação (ref-604727205).
10. O que ainda estamos construindo#
Um documento de segurança que só lista o que já funciona esconde metade da informação. Estas são as lacunas conhecidas hoje.
Teste de intrusão independente. A contratação de um teste de intrusão anual, conduzido por um fornecedor independente e com plano de correção rastreado, está em implementação (ref-318001844). Até que ele aconteça, a MedDeck não afirma ter tido sua plataforma testada por terceiro.
Certificação Service Organization Control 2 (SOC 2). A MedDeck não tem certificação SOC 2 e não se apresenta como certificada. O catálogo de controles no Centro de Confiança (/trust) traz o estado real de cada controle, incluindo os que ainda não estão prontos — é a informação que uma auditoria independente confirmaria, publicada antes de existir auditoria.
Health Insurance Portability and Accountability Act (HIPAA). A conformidade é parcial, e a razão é específica: os requisitos técnicos da norma estão atendidos pela arquitetura descrita aqui, mas a cadeia de Acordos de Associado de Negócios (BAA, na sigla em inglês para Business Associate Agreement) com os fornecedores ainda está sendo firmada (ref-039841448). Hoje existe acordo firmado com Google LLC; os acordos com Cloudflare, Inc., Modal.com, Sentry e Anthropic, PBC estão em negociação. Enquanto essa cadeia não estiver completa, o diagnos não se apresenta como plataforma em conformidade plena com a HIPAA.
Nenhum controle descrito nas seções 1 a 9 depende de algo desta lista para funcionar. O cofre, a cifra em duas camadas, o isolamento por workspace e o registro de auditoria são o que existe hoje, em produção.
11. Como reportar uma vulnerabilidade#
Se você encontrou uma falha de segurança no diagnos, escreva para [email protected]. Esse é o canal certo — um relato de vulnerabilidade enviado pelo suporte comum demora mais para chegar a quem consegue agir.
O que ajuda a resolver rápido:
- Uma descrição do que você encontrou e do impacto que enxerga.
- O passo a passo para reproduzir, com a data e o horário do teste.
- Teste feito apenas contra uma conta sua, sem acessar, alterar ou extrair dado de terceiro.
- Nada que degrade o serviço para outras pessoas: sem ataque de volume, sem engenharia social com a equipe ou com clientes.
- Tempo para corrigir antes de tornar o problema público.
O que você pode esperar de nós:
- Confirmação de recebimento em até dois dias úteis.
- Um retorno com nossa avaliação: se reproduzimos o problema, qual a severidade e qual o encaminhamento.
- Aviso quando a correção for publicada.
- Crédito público pelo achado, se você quiser — basta dizer como prefere ser identificado.
A MedDeck não mantém programa de recompensa por vulnerabilidade hoje. Somos uma equipe pequena e preferimos dizer isso com clareza a criar expectativa de pagamento.
A MedDeck não aciona medida legal nem retalia quem pesquisa de boa-fé dentro das regras acima. Pesquisa de segurança responsável torna a plataforma mais segura para todo mundo que a usa, e é tratada como contribuição, não como ameaça.