Sécuriser vos données avec Actian Vector, partie 2

Pour faire suite à mon premier billet sur les capacités de chiffrement des bases de données d'Actian Vector, le prochain billet de la série sur la sécurité des données explique le chiffrement basé sur les fonctions dans Actian Vector.

Chiffrement basé sur des fonctions dans un vecteur actien

Le cryptage entièrement contrôlé par une application de base de données est appelé cryptage basé sur des fonctions dans Actian Vector. L'application utilise une paire de fonctions SQL intégrées pour crypter et décrypter des valeurs de données individuelles dans les colonnes des tables. En dehors de l'application de ces fonctions sur les données comme indiqué dans les instructions SQL, le serveur de base de données ne traite pas les données cryptées d'une manière spécifique. En particulier, le serveur de base de données n'est pas capable de décrypter lui-même les données cryptées.

L'application spécifie une phrase de passe avec la fonction de cryptage et doit à nouveau spécifier la même phrase de passe avec la fonction de décryptage. Le serveur de base de données déduit une clé de cryptage symétrique de la phrase de passe donnée et utilise cette clé pour crypter ou décrypter les données. Ni la phrase de passe ni la clé de chiffrement dérivée ne sont stockées dans le serveur de base de données. L'application est toujours responsable de la fourniture de la phrase de passe correcte à la fonction de cryptage et de décryptage.

En règle générale, l'application choisit une phrase d'authentification et utilise la fonction de cryptage lorsqu'elle insère des données dans un tableau. Les données sont cryptées sur la base de la phrase de passe choisie, puis stockées. Lorsqu'elle accède aux données stockées, que ce soit lors d'une sélection ou d'une mise à jour, l'application utilise la fonction de décryptage avec la même phrase d'authentification choisie pour obtenir les données en clair. L'accès aux données cryptées sans la fonction de décryptage permet simplement de récupérer les données cryptées, ce qui n'est généralement pas très utile.

L'application peut spécifier différentes phrases de passe avec des invocations individuelles des fonctions de cryptage et de décryptage. Par exemple, différents utilisateurs de bases de données peuvent chacun utiliser leur propre phrase d'authentification pour insérer des données cryptées dans la même table. Les utilisateurs peuvent être sûrs qu'aucun autre utilisateur ne peut voir le texte en clair de leurs propres données. Une application peut également crypter les données de différentes colonnes d'un tableau à l'aide de différentes phrases de passe, et fournir les différentes phrases de passe à différents groupes d'utilisateurs. Ainsi, un groupe d'utilisateurs ne peut voir les données en clair que dans une colonne, tandis qu'un autre groupe d'utilisateurs peut voir les données en clair dans l'autre colonne.

La fonction de cryptage peut être appliquée plusieurs fois avec des phrases de passe différentes sur les mêmes données. Pour accéder aux données en clair, les mêmes phrases de passe doivent être utilisées dans l'ordre inverse pour décrypter les données. Lors de la mise à jour de données cryptées, la fonction de décryptage est d'abord appliquée, la valeur en clair est mise à jour, puis la fonction de cryptage est utilisée pour crypter à nouveau les données mises à jour. Il ne s'agit là que de quelques exemples des possibilités infinies de combiner l'utilisation des fonctions de cryptage et de décryptage, toutes contrôlées par l'application.

Tout le cryptage basé sur des fonctions est effectué en utilisant les fonctions cryptographiques dans des instructions SQL normales. Cela signifie également que les phrases de passe en clair sont fournies aux fonctions cryptographiques dans les instructions SQL. L'utilisation correcte du chiffrement basé sur les fonctions doit donc veiller à ce que les instructions SQL restent suffisamment sûres, par exemple qu'elles ne soient pas tracées ou rendues visibles dans un historique de commande SQL.

En outre, la communication entre l'application et le serveur de base de données doit être sécurisée afin d'éviter la fuite des phrases de passe. À cet égard, l'utilitaire "sql" de Terminal Monitor n'est pas vraiment un exemple d'application sécurisée, car les phrases de passe en clair saisies dans les instructions SQL sont visiblement répercutées dans la fenêtre du terminal.

Exemples de chiffrement basé sur des fonctions :

• Definition du tableau utilisé dans les exemples suivants :

CREATE TABLE t1 (name CHAR(20), salary VARCHAR(50)) ; \g

Bien que le salaire soit une valeur numérique, la colonne "salaire" est définie comme une colonne de caractères suffisamment grande pour contenir les octets de la valeur cryptée.

• Insérer des données cryptées dans un tableau :

INSERT INTO t1 values ('Joe', AES_ENCRYPT_IV(40000, 'Secret passphrase')) ; \g
INSERT INTO t1 values ('Adam', AES_ENCRYPT_IV(38000, 'Secret passphrase')) ; \g
INSERT INTO t1 values ('CEO', AES_ENCRYPT_IV(350000, 'Super passphrase')) ; \g

Les deux premières instructions chiffrent la valeur du salaire sur la base de la phrase d'authentification "phrase d'authentification secrète", tandis que la troisième instruction utilise une phrase d'authentification différente, la "super phrase d'authentification".

• Sélection de données cryptées :

1. 1. Sélectionner sans utiliser la fonction de décryptage :

SELECT nom, salaire FROM t1 ; \g
nom salaire
Joe XnE_msRe1?Uh]!cUUerQn4opT(C[ !)O~yTrzE%JS
Adam lyr*M%o53]O(5d$2`!3a:Bg$zW40wMySO5[-E7+u
CEO a*#eE!~p(1-euLx?K$w(2)@FHk+dzM`5}Q#=lD@g
(3 lignes)

Les données cryptées de la colonne "salaire" sont affichées cryptées et donc sans signification. La longueur de la sortie pour la colonne "salaire" montre que les données cryptées occupent généralement plus d'espace que les valeurs en clair correspondantes.

1. 2. Sélectionnez l'utilisation de la fonction de décryptage avec la firme phrase de passe :

SELECT name, AES_DECRYPT_IV(salary, 'Secret passphrase') FROM t1 ; \g

nom col2
Joe 40000
Adam 38000
PDG \020���x������
(3 lignes)

Les valeurs cryptées avec la firme phrase de passe sont correctement décryptées. La valeur cryptée avec une phrase de passe différente n'est pas affichée en clair.

1. 3. Sélectionnez un enregistrement données spécifique à l'aide de sa phrase d'authentification correcte :

SELECT nom, AES_DECRYPT_IV(salaire, 'Super phrase secrète')
  FROM t1 WHERE name = 'CEO' ; \g

nom col2
PDG 350000
(1 ligne)

La valeur cryptée est affichée en clair.

Lors de la sélection de données cryptées, la fonction de décryptage a besoin de la phrase d'authentification correcte pour afficher le texte en clair. Lorsque l'on utilise des phrases de passe différentes pour des enregistrements de données différents, il est préférable d'utiliser une clause WHERE qui limite le résultat aux enregistrements de données chiffrés avec la phrase de passe spécifiée dans le SELECT.

• Mise à jour des données cryptées :

Lors de la mise à jour de données cryptées, les données doivent être décryptées et généralement recryptées après la mise à jour. Pour ce faire, les deux fonctions, décryptage et cryptage, sont utilisées dans la même instruction UPDATE. En même temps, il est également possible de modifier la phrase d'authentification.

UPDATE t1 SET salary = AES_ENCRYPT_IV(
AES_DECRYPT_IV(salaire, 'Super passphrase') + 20000,
'Secret passphrase' ) WHERE name = 'CEO' ; \g

La déclaration ajoute 20000 au salaire du "PDG" et modifie en même temps la phrase d'authentification en "phrase d'authentification secrète". La fonction de décryptage nécessite la phrase de passe originale et la fonction de cryptage est fournie avec la nouvelle phrase de passe. Comme la nouvelle phrase de passe est la même que celle qui a été utilisée pour crypter le salaire des deux autres enregistrements de données, un SELECT utilisant cette phrase de passe peut désormais afficher le texte en clair de tous les enregistrements :

SELECT name, AES_DECRYPT_IV(salary, 'Secret passphrase') FROM t1 ; \g

nom col2
Joe 40000
Adam 38000
PDG 370000
(3 lignes)

Le prochain article de blog de cette série expliquera comment les clés de chiffrement de la base de données sont utilisées dans Actian Vector.

À propos de Martin Fuerderer

Martin Fuerderer est ingénieur logiciel principal chez HCLSoftware. Au cours des 25 dernières années, il a travaillé dans de nombreux domaines du développement de serveurs de bases de données. Ces dernières années, il s'est intéressé à la sécurité des serveurs de base de données.