Ilegível
A cifragem acontece antes do upload. Ninguém consegue ler os seus dados, nós incluídos. Por isso, quando alguém pergunta quem mais consegue ler isto, a resposta é uma arquitetura em vez de uma promessa: nem os seus fornecedores, nem nós.
Infraestrutura de dados soberana
Os seus dados deviam estar em lado nenhum.
Em lado nenhum legíveis, e em nenhum sítio novo: os seus dados ficam nos serviços cloud da sua escolha, mas retoma a soberania sobre eles.
O problema
A responsabilidade é local. O acesso não é.
O armazenamento na cloud, tal como existe hoje, não consegue estabelecer quem é capaz de ler os dados que aloja. Os fornecedores cifram os ficheiros com chaves que guardam do lado deles, e os sistemas destes decifram a pedido: para qualquer colaborador com o acesso certo, para qualquer autoridade que o imponha. A fechadura é real. Pertence ao operador, tal como o registo de quem a abriu.
A ordem não tem de vir do regulador a que os dados estão sujeitos. Um fornecedor sediado no estrangeiro responde perante a sua própria lei onde quer que estejam os servidores, e a divulgação chega depois, se é que chega. A notificação, a coima e a carta aos clientes afetados ficam com a organização que recolheu os dados, fosse quem fosse que detinha os bytes.
Todas as avaliações acabam da mesma maneira: a descrever um controlo que está nas mãos de outro.
Leia porque cifrado em repouso não significa privado.
A solução
Mantenha todos os fornecedores. Mude o que eles podem entregar.
A DataPrism é um overlay sobre o object storage existente. Os ficheiros são cifrados do lado do cliente antes de saírem do perímetro, divididos em fragmentos e dispersos por instâncias e fornecedores independentes. Nenhum fornecedor detém a chave, pelo que um pedido apresentado a qualquer um deles só produz fragmentos que ninguém consegue abrir, e o número de endereços distintos a que um pedido teria de chegar passa a ser um valor declarado em vez de um pressuposto.
Um índice selado do ficheiro é ancorado num registo público, de tamanho constante qualquer que seja o ficheiro: nenhum conteúdo e nada legível vai para lá, e quem revê pode obter o registo diretamente. Não há plataforma para onde migrar: os mesmos fornecedores, as mesmas regiões, as mesmas faturas. Os dados são reescritos através do pipeline, para contas que já são suas.
Veja como a cifragem do lado do cliente se torna prova pública.
Qualquer escala
Um documento ou todo o acervo. As mesmas propriedades.
A adoção começa onde vale a pena começar: em tudo o que for escrito a partir de agora, ou num perímetro existente que passa uma vez pelo pipeline. Nada tem de ser reconstruído à medida que o âmbito cresce, e um documento decisivo comporta-se exatamente como milhões de registos.
A adoção não exige um programa, um ciclo orçamental e um comité de acompanhamento antes de algo melhorar: cobre-se primeiro o perímetro mais exposto, demonstra-se e alarga-se a partir daí. E onde os pipelines têm de recolher dados sem os poder ler, a mesma infraestrutura pode ser concebida para a ingestão cega: recolha sem exposição.
Três propriedades
Ilegível. Imparável. Demonstrável.
Três propriedades que herda da arquitetura, para que não seja preciso confiar em ninguém para as manter.
Imparável
Perder um fornecedor por uma indisponibilidade, uma alteração de preço ou uma recusa em servi-lo deixa de ser um cenário que tem de contornar no planeamento: cada ficheiro é fragmentado e disperso por fornecedores independentes, com redundância integrada.
Demonstrável
Mostre a um terceiro que um ficheiro existe e não foi alterado, sem o abrir e sem que ninguém tenha de responder por si: a integridade é ancorada num registo público sob a forma de uma impressão digital de tamanho constante, seja qual for o tamanho do ficheiro.
Já cifra?
A cifragem resolve o primeiro problema. Não os que vêm atrás.
Cifrar antes do upload impede o fornecedor de ler os dados. É a parte difícil, vale a pena e é também onde este pipeline começa. É também o ponto onde a maioria das arquiteturas para, e ficam três exposições de pé.
-
01
Uma cópia completa continua num único endereço.
O que chega a esse endereço chega a tudo, numa só operação. Dados cifrados recolhidos hoje podem ser guardados indefinidamente, e a criptografia que aguenta agora não aguenta para sempre. A recolha em larga escala assenta exatamente nessa premissa: levar tudo, guardar, ler mais tarde.
-
02
Cifragem não é disponibilidade.
Uma conta suspensa, uma indisponibilidade, uma alteração de condições ou um resgate levam os dados consigo, com ou sem chaves. Quem detém todos os bytes é também quem pode deixar de os devolver.
-
03
A custódia das chaves não se demonstra.
É uma afirmação sobre uma configuração interna, e a prova é a palavra do próprio operador. Nada disso pode ser verificado por quem tem de dar o aval.
A dispersão por fornecedores independentes muda a quantos endereços distintos uma operação tem de chegar, a redundância absorve a perda de um deles, e uma impressão digital ancorada é verificável por quem pergunta. A cifragem continua a ser o primeiro passo. Deixa de ser o único.
Porquê agora
A pergunta chega-lhe pelos clientes antes de chegar pelo regulador.
Os compradores empresariais escrevem hoje a soberania nos processos de compra, e a resposta que querem não é uma promessa sobre quem detém os bytes. Questionários, auditorias, avaliações de impacto das transferências: todos perguntam o mesmo por outras palavras, e a maior parte das horas vai para reafirmar aquilo que não consegue demonstrar. As sanções passaram da teoria à prática, e a responsabilidade continua sua, fosse quem fosse que detinha os bytes. O mesmo regulamento indica a saída: quando os dados expostos são ininteligíveis, uma violação deixa de ser uma carta a todos os clientes que tem. A infraestrutura de dados soberana é a resposta para a qual os mandatos convergem, e o que falta é uma arquitetura que a produza nas clouds que já utiliza.
485 M€
já aplicados, por alcançar dados europeus a partir de fora da UE. Seis meses para corrigir, ou as transferências param. Onde estavam os servidores não era a questão
Art. 34
sem obrigação de informar cada pessoa afetada, quando os dados expostos eram ininteligíveis. A comunicação ao regulador mantém-se
Casos de uso
Três formas de chegar à sua secretária. Uma coisa a resolver.
Obrigações diferentes, equipas diferentes, perímetros diferentes. Em todas elas, o trabalho que deixa de fazer é o mesmo: argumentar que os seus dados estão protegidos, em vez de o mostrar.
Caso de uso 01
Uma intimação ao seu fornecedor devolve apenas fragmentos cifrados.
Para equipas cujas obrigações e cuja infraestrutura estão em lados opostos de uma fronteira.
Conformidade das transferências de dados transfronteiriças
Caso de uso 02
Guarde ficheiros de utilizador que nenhum fornecedor consegue abrir.
Os ficheiros que os seus utilizadores carregam, cifrados dentro do seu processo antes de saírem, ilegíveis para cada fornecedor que os armazena.
Cifrar os dados dos utilizadores antes do upload
Caso de uso 03
Perca um fornecedor. Mantenha o ficheiro.
Corte um e o ficheiro volta na mesma. Demonstrável numa chamada, não uma cláusula num contrato.
Soberania de dados sem mudar de fornecedor
Programadores
Lance armazenamento soberano por arquitetura. Sem escrever uma linha de criptografia.
Instale o SDK, aponte-o para os fornecedores que já paga, publique: nada acima ou abaixo dele tem de mudar.
import { readFile } from "node:fs/promises";
import { DataPrismKey, DEFAULT_ENCRYPTION } from "@dataprism/sdk/crypto";
import { CloudStandard } from "@dataprism/sdk/standard";
import { FilePipeline } from "@dataprism/sdk/files";
// Client, providers, project and key secret, one config file in your project:
// docs.dataprism.co/sdk/client
import { client, providers, project, secret } from "./dataprism";
// Create a project: an encrypted namespace you control
const key = DataPrismKey.fromSecret(secret, DEFAULT_ENCRYPTION);
const standard = new CloudStandard(key);
const { cloudId } = await client.prism(standard).create(project);
// Upload: encrypted on this machine, dispersed with redundancy,
// integrity anchored on a public registry
const bytes = await readFile("contract.pdf");
const pipeline = new FilePipeline({ standard, execution: client.execution, cloudId, providers });
await pipeline.upload("contract.pdf", bytes, {
chunkSize: 65_536,
dataShards: 7,
parityShards: 3,
});Provado, não prometido
Deixe os seus auditores verificarem, desde o primeiro dia.
Cifrado, fragmentado, disperso: nada disto pede a sua confiança, nem a nossa. Os modelos de fiabilidade abaixo mostram o que a arquitetura garante, e o registo que a aplica é público: um revisor percorre-o sem uma chamada prévia. A diferença face a todos os fornecedores usados até aqui: desta vez as chaves e todo o processo ficam de um só lado, e é o seu.
-
Artigo de investigação
A conceção de ponta a ponta, com garantias formais e modelos de fiabilidade que a sua própria equipa pode contestar.
Leia a investigação por trás da integridade de dados demonstrável
-
Contratos verificáveis
O registo é público e documentado, até à forma como cada entrada é lida.
Assente numa arquitetura de segurança verificável
Cifragem do lado do cliente
O que sai do seu lado já é ilegível, onde quer que vá parar.
Sem novo lock-in de fornecedor
Os seus fornecedores continuam seus, substituíveis e sob contrato.
Um SDK para integrar
Um SDK TypeScript, sem criptografia para a sua equipa acertar.
Aberto por conceção
Docs públicas, código verificável, investigação ainda por chegar.
Comece agora
Tenha a resposta pronta antes da próxima revisão.
Traga armazenamento soberano, ilegível, imparável e demonstrável para os buckets que já tem, sem mudar um único fornecedor. Desenhamos consigo o encaixe na sua arquitetura.
30 minutos. O seu sistema ou o seu questionário, sem slides.