Estamos a abrir um design partner program. Ver o programa

PROGRAMADORES

Lance armazenamento soberano por arquitetura. Sem escrever uma linha de criptografia.

Um SDK de cifragem do lado do cliente, em TypeScript: instale-o, aponte-o para o object storage que já utiliza, publique. A cifragem, a dispersão e a ancoragem pública acontecem por trás de uma API limpa, pelo que nada disso é código que escreva, mantenha ou defenda numa revisão de segurança. Os seus utilizadores veem apenas ficheiros.

Ler a documentação Ver exemplos

INÍCIO RÁPIDO

Instalar, apontar, publicar.

Inicialize um cliente, crie um projeto, faça o upload de um ficheiro, volte a lê-lo. Tudo o que está abaixo da linha da API, a derivação de chaves, a divisão em blocos, a redundância, a ancoragem, é código que nunca escreve, testa ou mantém atualizado. E quando a sua revisão de segurança perguntar o que está realmente dentro dessas chamadas, a secção seguinte é a resposta.

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,
});
const { index } = await pipeline.upload("contract.pdf", bytes, {
  chunkSize: 65_536,
  dataShards: 7,
  parityShards: 3,
});

// Download: shards fetched in parallel, reconstructed from any
// quorum, decrypted locally
const restored = await pipeline.download(index);

POR DENTRO

Quatro etapas. Sem magia.

Antes de lançar uma camada de cifragem, alguém do seu lado vai perguntar exatamente o que sai da máquina e o que acontece quando um fornecedor falha. Aqui está o pipeline por trás de upload(), etapa a etapa, com uma ligação para a página da documentação que traz o detalhe completo de cada uma. O suficiente para responder a essa revisão sem ler o nosso código-fonte.

  1. 01. DIVISÃO EM BLOCOS

    Divisão em blocos definida pelo conteúdo

    Edite um ficheiro grande e volte a enviá-lo: só as partes que mudaram realmente voltam a viajar. Os ficheiros são cortados em fronteiras naturais do conteúdo, não em posições fixas, pelo que uma inserção não volta a recortar tudo o que vem a seguir. Obtém novos uploads do tamanho da diferença sem manter um formato de diff seu.

    A divisão em blocos, na documentação do pipeline de ficheiros
  2. 02. CIFRAGEM

    Cifragem convergente, na sua máquina

    Cada chunk é cifrado na sua máquina antes de qualquer coisa sair dela: nenhum serviço de chaves para montar, nada para depositar. A derivação é determinista, pelo que conteúdo inalterado é reconhecido como já armazenado: um novo envio move apenas o que mudou realmente, e conteúdo idêntico ocupa o seu armazenamento uma só vez, não uma vez por cópia.

    A cifragem convergente, na documentação do pipeline de ficheiros
  3. 03. DISPERSÃO

    Redundância por fornecedores independentes

    Os blocos cifrados são expandidos com a redundância que escolher e dispersos pelos fornecedores independentes que configurou, pelo que a indisponibilidade de um fornecedor, ou um fornecedor que lhe corte a conta, continua a ser um não-acontecimento até essa redundância. Nenhum caminho de recuperação seu para escrever, ensaiar e manter sincronizado.

    A redundância, na documentação do pipeline de ficheiros
  4. 04. ANCORAGEM

    Um índice selado, ancorado num registo público

    O que é ancorado é um índice cifrado de tamanho constante, seja qual for o tamanho do ficheiro, e a sua integridade não assenta em nenhum operador, nós incluídos: as leituras reconstroem os seus dados a partir de qualquer quórum de fragmentos e decifram localmente. Mostrar que um ficheiro não foi alterado passa a ser uma verificação que quem pergunta executa, não um endpoint que tenha de construir e manter.

    Prisms e ancoragem, na documentação
UM CICLO DE VIDA DA ELIMINAÇÃO QUE PODE MOSTRAR

Eliminado significa enumerado e depois eliminado

Quando um cliente ou um regulador pergunta se eliminado significa mesmo eliminado, pode apontar para um ciclo de vida documentado em vez de uma caixa marcada num painel: a eliminação está especificada na referência do SDK para enumerar cada fragmento que um ficheiro deixou para trás, remover cada um deles no respetivo fornecedor e reportar tudo o que falhou, fornecedor a fornecedor. É um trabalho de reconciliação que não tem de escrever nem manter.

O ciclo de vida da eliminação, na referência do SDK

COMO O SDK PENSA

Um SDK de cifragem do lado do cliente, três garantias.

AS CHAVES FICAM CONSIGO

Tudo o que sai é texto cifrado

As chaves de chunk derivam do próprio conteúdo, o que torna barato reenviar dados inalterados. O índice que as junta é selado com uma chave derivada de um segredo que controla, e nenhuma das duas nos é alguma vez enviada: tudo o que o SDK envia para fora já vai cifrado. Acrescentar um fornecedor nunca alarga o que alguém pode ler.

O que cada ator consegue e não consegue ver está exposto na nossa arquitetura de segurança verificável.

INVISÍVEL PARA OS UTILIZADORES

Nenhuma criptografia exposta aos utilizadores finais

Nenhuma mecânica criptográfica é alguma vez exposta aos seus utilizadores. As chaves e a execução ficam por trás do login e da interface do seu próprio produto, pelo que não há nenhum passo novo no seu onboarding nem nada de extra a que a sua equipa de suporte tenha de responder. Para eles, é apenas armazenamento que por acaso é ilegível para todos os outros.

DOCUMENTADO DE PONTA A PONTA

Documentação completa e pública

Todas as camadas estão documentadas abertamente em docs.dataprism.co: a referência do SDK, o pipeline de ficheiros, os contratos, exemplos executáveis em Node.js e Next.js. Se sabe ler um README, consegue avaliar-nos antes de falar com alguém das vendas.

ALVOS DE INTEGRAÇÃO

Aponte-o para o armazenamento que já utiliza.

Nenhum novo fornecedor de armazenamento para integrar, nenhuma migração de infraestrutura, nenhum protocolo para aprender: onde quer que os fragmentos aterrem, o pipeline por trás do SDK mantém-se o mesmo. Acrescentar ou retirar um fornecedor é uma alteração de configuração, não um projeto.

  • AWS S3

    Os buckets que já opera passam a ser alvos de dispersão de fragmentos cifrados.

  • CLOUDFLARE R2

    Um fornecedor independente que alarga o conjunto de dispersão.

  • SCALEWAY

    Object storage europeu como alvo de dispersão independente.

  • ON-PREM

    O object storage que gere você mesmo junta-se ao mesmo conjunto.

Comece pela documentação.

Esta página mostra a forma do sistema. A documentação vai até ao fundo: a referência completa do SDK, o interior do pipeline e exemplos executáveis em Node.js e Next.js.

Ler a referência do SDK Falar com um engenheiro