Votre architecture reste telle quelle
Vos fournisseurs restent : aucun projet d’infrastructure à financer.
Produit
Un stockage que votre propre cloud ne peut ni lire, ni perdre, ni altérer en silence.
DataPrism se pose sur le cloud que vous exploitez déjà : un seul pipeline applique la propriété à ce stockage, si bien que ce que vous pouvez prouver de vos données change pendant que votre architecture reste exactement telle quelle.
Chiffré avant l’envoi. Dispersé avec redondance. Prouvé en public.
La propriété commence par le chiffrement côté client : les clés sont dérivées chez vous, et ce qui sort est déjà illisible. Chaque étape ci-dessous fait passer une garantie de la promesse d'un fournisseur au comportement de la donnée elle-même, ce qui la rend démontrable devant un client, un auditeur ou un régulateur. Là où le chiffrement avant envoi est déjà en place, commencez par les trois expositions qu'il laisse ouvertes.
-
Fichier
-
Chiffré
-
Fragmenté
-
Dispersé
-
Ancré
Fichier
Chiffré
Fragmenté
Dispersé
Ancré
Ce que c’est
Un overlay souverain, pas un silo de plus.
Vous gardez vos fournisseurs d’object storage. DataPrism les compose en quelque chose qu’aucun d’eux ne peut offrir seul : un stockage où un fournisseur détient toujours vos octets mais ne peut plus les lire, et ne décide plus si vous les gardez. Remplacer vos fournisseurs voudrait dire remplacer aussi vos contrats, vos régions et votre posture de conformité. L’overlay laisse les trois où ils sont, ce qui transforme une décision d’infrastructure en une décision que vos équipes sécurité et conformité peuvent prendre seules.
Vous chiffrez déjà ?
Votre fournisseur ne peut pas le lire. C’est un problème sur trois.
Chiffrez avant l’envoi avec une clé que vous détenez, et votre fournisseur est aveugle à vos données. C’est réel, et c’est là que notre propre pipeline commence. Trois choses restent exactement ce qu’elles étaient : il détient toujours l’intégralité, il peut toujours vous empêcher d’y accéder, et vous n’avez toujours rien qu’un tiers puisse vérifier sans vous.
Ce qu’il détient toujours
Un seul parc, une seule adresse
Votre texte chiffré se trouve en entier à l’intérieur du parc d’un seul fournisseur. Ce qui atteint ce parc atteint le tout, en une seule opération, et une copie prise aujourd’hui peut être conservée jusqu’au jour où elle vaudra la peine d’être lue. Les fichiers sont découpés, chiffrés et dispersés avec redondance chez les fournisseurs indépendants que vous configurez : la même opération doit désormais réussir autant de fois que vous l’avez fixé. Ce nombre, vous le choisissez, et vous pouvez l’énoncer quand on vous demande ce qu’atteint une compromission unique.
Ce qu’il ne peut pas tenir
La confidentialité n’est pas la disponibilité
Une clé que vous détenez ne fait rien contre une panne, un compte suspendu ou un changement de conditions. Vos données vont là où va ce fournisseur unique. Dispersée avec redondance, la perte de l’un est absorbée par le seuil que vous avez configuré, pas par votre plan de reprise.
Ce qu’il ne peut pas montrer
Rien qu’un tiers puisse vérifier
La garde des clés est une affirmation sur votre propre configuration, et la preuve tient à votre parole plus celle de votre fournisseur. Une empreinte de taille constante sur un registre public est vérifiable par la personne qui pose la question, au moment où elle la pose, sans rien exiger de vous.
Rien de tout cela n’est un argument contre le fait de chiffrer d’abord. C’est la liste de ce que chiffrer d’abord laisse ouvert.
Ce que l’intégration demande
Un seul SDK à intégrer. Votre produit se comporte exactement comme aujourd’hui.
Vous ajoutez un SDK TypeScript au code qui gère déjà vos uploads. Ses appels d’upload et de download prennent la suite des vôtres, les types viennent avec, et le reste de votre produit continue : les mêmes écrans, le même mode opératoire de support, la même livraison que celle que vous alliez publier de toute façon.
- 01
Installer
Ajoutez le SDK TypeScript là où vit déjà votre gestionnaire d’upload. Il s’exécute dans votre propre processus, dans le navigateur ou sur votre serveur.
- 02
Pointer
Pointez-le vers le stockage que vous exploitez déjà : les mêmes comptes, les mêmes régions, les mêmes contrats.
- 03
Livrer
Livrez-le dans une release ordinaire. Ce qui change, c’est ce que vos fournisseurs peuvent remettre, et votre produit garde le comportement qu’il a.
La page développeurs montre le code : le SDK de chiffrement côté client.
Pourquoi ça tient
Appliqué par consensus, pas par un opérateur.
Toute garantie qu’un opérateur applique, un opérateur peut la rompre en silence. L’intégrité ne dépend donc ici de la bonne conduite de personne, la nôtre comprise : l’index racine ancré ne grossit jamais avec vos données, et chaque fragment est adressé par son contenu, si bien que toute altération est détectable de bout en bout. Quand un client ou un auditeur demande comment vous savez que rien n’a été altéré, vous montrez une preuve que n’importe qui peut vérifier, pas un rapport que seul votre fournisseur peut produire, et lui répondre ne demande d’ouvrir de ticket chez personne.
Les garanties sont formelles : voir l’intégrité prouvable des données, spécifiée dans notre recherche. Ce que chaque acteur peut voir est exposé dans Confiance et sécurité.
Ce que vous obtenez
Ce qui atterrit dans votre stack.
Une seule compromission ne suffit pas
Des fragments chiffrés chez les fournisseurs que vous configurez : atteindre un parc n’est plus atteindre vos données.
Vous survivez à la perte d’un fournisseur
Les pannes et les refus de fournisseurs cessent d’être des événements à anticiper.
Une seule vérification, à tout volume
Une seule empreinte, quel que soit le volume derrière elle : la même vérification unique à toute échelle.
Vous sauriez si cela avait changé
Chaque fragment adressé par son contenu : l’altération remonte au lieu de passer inaperçue.
Un chiffrement que votre équipe n’écrit pas
Un SDK TypeScript : aucune plomberie cryptographique à construire ou à défendre en revue.
Explorez là où s’applique la protection des données sensibles.
FAQ
Posées avant chaque démo.
- Devons-nous migrer nos données ?
- Vos fournisseurs, vos régions et vos contrats restent exactement tels quels, et il n’y a pas de plateforme vers laquelle déménager. Ce qui passe par le pipeline, ce sont les données elles-mêmes, et il y a deux façons de commencer : l’appliquer à tout ce qui sera écrit désormais, ce qui laisse l’existant intact, ou faire passer une fois un périmètre existant, ce qui réécrit ces fichiers en fragments dans les mêmes comptes. Dans les deux cas, c’est un changement qu’une seule équipe livre, pas un programme d’infrastructure à budgéter. L’ensemble des destinations vous appartient, et vous pouvez le faire évoluer : plusieurs comptes chez un même fournisseur, plusieurs fournisseurs côte à côte, votre propre stockage on-premise, ou n’importe quel mélange des trois. Tout ce qui parle l’API S3 est une destination dès aujourd’hui, et en ajouter une plus tard relève de la configuration, pas d’une seconde intégration. L’overlay est décrit dans « Ce que c’est », plus haut.
- Nous chiffrons déjà côté client. DataPrism remplace-t-il cela ?
- Non, et il ne vous demande pas de le défaire. Le SDK chiffre lui aussi de votre côté : un objet que vous lui remettez déjà chiffré traverse le pipeline comme votre texte chiffré. Ce qui change, c’est tout ce qui vient après le chiffrement : le nombre d’endroits où atterrissent les fragments, et ce qu’un tiers peut vérifier. La section ci-dessus expose ce que le chiffrement seul laisse ouvert.
- Qu’est-ce qui atterrit réellement sur le registre public ?
- Un index scellé, et rien d’autre : la carte qui remet vos fragments ensemble, chiffrée avec une clé que nous ne recevons jamais. Aucun contenu et rien de lisible n’y atterrit jamais, si bien que n’importe qui peut vérifier votre affirmation d’intégrité sans que vous publiiez quoi que ce soit sur vos données. Ce que chaque acteur peut voir, et ce qu’aucun ne peut voir, est exposé dans la vue d’ensemble de l’architecture de sécurité.
- Que deviennent nos données si DataPrism s’arrête ?
- Vos fichiers restent dans vos propres comptes, et la clé reste dérivée de votre côté, si bien que la récupération tient sans nous. La reconstruction s’exécute côté client à partir des fragments détenus par vos fournisseurs et de l’index inscrit au registre public, et le SDK lit cet index via une interface que n’importe quel nœud public peut servir. Le chemin de récupération est une propriété de la conception plutôt qu’un engagement de notre part, ce qu’expose la vue d’ensemble de l’architecture de sécurité.
- Quel stockage peut-il composer ?
- Tout object storage que vous exploitez, où qu’il tourne : AWS, GCP, Azure ou on-prem. Le pipeline est le même pour tous, et aucune partie de votre intégration ne change quand la combinaison de fournisseurs change.