OneNym.idParlons intégration
Français

ENCRYPTION / HOW IT WORKS

Comment fonctionne le chiffrement,
et ce qu'il protège.

La valeur ne dépend pas seulement du nom de l’algorithme. La question clé est de savoir comment séparer ceux qui détiennent les données de ceux qui peuvent les lire.

Chiffré ne signifie pas toujours la même protection.

Pensez à stocker une adresse de livraison. Le chiffrement du transport, des disques et des données protège différentes limites.

Chiffrement des transports / TLS
Protège la communication entre le navigateur et le serveur. Le serveur de réception peut traiter l'adresse ; TLS ne protège pas automatiquement le contenu de la base de données ou une application compromise.
Cryptage du stockage
Protège contre le vol de disques et de supports de sauvegarde. Si la base de données déchiffre de manière transparente les lectures normales, les utilisateurs disposant d'un accès en lecture SQL peuvent toujours voir les adresses.
Chiffrement avant stockage
Cryptez l'adresse dans l'application et stockez le texte chiffré. Séparez les autorisations de lecture de la base de données des autorisations d'utilisation des clés pour vous protéger contre le vol de la base de données uniquement.

OneNym combine ces couches avec une autorisation spécifique à un objectif. Une cryptographie forte est importante, tout comme la limitation des chemins de déchiffrement.

L’adresse entière est déchiffrée en mémoire, puis seuls les champs autorisés sont renvoyés. Ce n’est pas un chiffrement par champ. Gérez le texte reçu ainsi que les journaux et stockages précédant l’enregistrement. Guide de démarrage

Protégez une clé de données avec une clé distincte.

Un DEK crypte l'adresse ; un KEK protège ce DEK. Il s’agit du chiffrement d’enveloppe. Un exemple avec un DEK dédié pour chaque adresse suit.

  1. Générez un DEK à l’aide d’une source aléatoire cryptographiquement sécurisée et cryptez l’adresse avec un chiffrement authentifié.
  2. Enveloppez la DEK avec une KEK gérée par un service de gestion de clés. L'emballage crypte et protège la clé.
  3. Stockez le texte chiffré, le DEK encapsulé, la version de clé et les métadonnées de déchiffrement. Ne stockez pas de DEK en texte brut dans la base de données.
  4. Lorsqu'une adresse est nécessaire, autorisez le organisation, l'objet, l'enregistrement et les champs.
  5. Le service autorisé déballe le DEK, déchiffre l'adresse et renvoie uniquement les champs autorisés.
Service de gestion des clés de base de données
Adresse chiffrée KEK protégeant la DEK
Autorisations et audit d'utilisation de clé DEK enveloppés
Nom occasionnel / tag / version clé
          ↓ Le service autorisé accède aux deux
       Déchiffrement temporaire → Traitement de la livraison

Même une KEK non exportable peut faire l’objet d’abus si ses autorisations d’utilisation sont volées. Séparez l’accès à la base de données et au KMS, l’administration, les opérations d’urgence et les informations d’identification du service. Protégez également la mémoire déchiffrée et les caches de clés.

Gérez les KEK via les services clés du cloud.

Le Vault utilise Azure Key Vault pour sa KEK. Séparez les droits sur la clé protégeant les clés de données (DEK) de l’accès à la base.

Les services cloud contrôlent les clés et l'accès aux opérations cryptographiques. OneNym autorise d'abord les organisations, les enregistrements, les champs et les objectifs. Les applications professionnelles bénéficient d'autorisations API Vault limitées, et non d'un accès KEK direct.

Services clés cloud et responsabilités OneNym →

Deux types différents de rotation des clés.

La rotation d'une KEK peut réemballer les DEK sans modifier le texte chiffré des données. Une DEK compromise nécessite un nouveau chiffrement avec une nouvelle DEK. La rotation ne peut pas récupérer le texte brut volé ou les copies des anciennes clés et du texte chiffré.

Détectez la substitution et protégez la confidentialité.

Le chiffrement authentifié tel que AES-GCM détecte les modifications du texte chiffré via une balise d'authentification. Rejetez les échecs. Ne réutilisez jamais un occasionnel avec la même clé AES-GCM, y compris lors de nouvelles tentatives et sur plusieurs serveurs.

Liez l’ID de organisation, l’ID d’enregistrement et la version du schéma en tant que données authentifiées supplémentaires (AAD). Le texte chiffré copié du organisation A dans l’enregistrement du organisation B échoue à la vérification lorsqu’il est comparé au contexte attendu du organisation B.

AAD n'est pas chiffré ; n'y mettez pas d'adresses secrètes. Dérivez les identifiants attendus à partir de demandes authentifiées et d’enregistrements fiables. Faire confiance aux identifiants fournis avec le texte chiffré substitué ne préserve pas la limite.

Qu’est-ce qui reste protégé en cas de violation ?

Seule une copie de la base de données est volée
Un chiffrement correct protège le contenu de l'adresse si les clés en texte brut et autres copies en texte clair sont absentes. Évaluez séparément l’exposition des métadonnées telles que les nombres, les identifiants, les horodatages et les tailles.
Les autorisations de base de données et de déchiffrement sont compromises
Le chiffrement à lui seul ne peut pas empêcher l'accès. Limitez l’impact grâce à l’autorisation étendue, aux contrôles d’utilisation, à la détection des anomalies et à la révocation.
Le serveur de livraison est compromis
Les adresses déchiffrées lors d'un traitement légitime peuvent être volées. Ne renvoyez aucun champ au-delà de ce que nécessite la livraison.
Une adresse a déjà été envoyée à un partenaire
La révocation de la clé du coffre-fort n’efface pas le texte brut partagé. Gérez également la rétention et la suppression des partenaires.

Questions à poser avant le déploiement.

Au-delà de savoir si AES est utilisé, demandez-vous qui peut utiliser les clés, si le déchiffrement est étendu, si l'utilisation des clés est auditée, à quelle vitesse la révocation atteint les caches et comment les clés perdues sont traitées. Les limites de protection et les preuves opérationnelles soutiennent l’évaluation.

Références techniques

Pour connaître les principes généraux de chiffrement et de gestion des clés, voir Aide-mémoire sur le stockage cryptographique de l'OWASP; pour les hiérarchies clés, voir Conseils de chiffrement au repos de Microsoft. Cette page explique la conception de la protection de OneNym ; les clés par enregistrement sont une configuration illustrative.

Discuter de l'intégration technique