Oracle
 sql >> Base de données >  >> RDS >> Oracle

Sécurité de la base de données Oracle - Chiffrement et déchiffrement

Le cryptage des données est très important car c'est un moyen de protéger les données actuelles et archivées afin d'assurer leur confidentialité. Cela empêche un accès et une utilisation non autorisés. Dans cet article, je présenterai brièvement quelques aspects importants du chiffrement et du déchiffrement des données.

Systèmes de chiffrement

Dans un système de chiffrement, il y a deux composants principaux :l'algorithme de chiffrement, qui est la méthode utilisée pour modifier la valeur, et la clé de chiffrement , dont la sécurité dépend de la vulnérabilité des données chiffrées.

Oracle prend en charge deux types d'algorithmes de chiffrement :algorithmes symétriques (utiliser la même clé pour chiffrer et déchiffrer les données) pour chiffrer les données stockées et les algorithmes asymétriques (2 clés sont générées :une clé privée utilisée pour le déchiffrement et une clé publique qui sera utilisée par l'expéditeur du message afin de chiffrer le message) utilisée pour la connexion à la base de données et pour la communication entre une base de données et un client.

Les algorithmes de chiffrement symétriques disponibles dans Oracle sont les suivants :Data Encryption Standard (DES ) qui crypte un bloc de 64 bits de texte en 64 bits de texte crypté, à l'aide d'une clé de 56 bits, Triple Data Encryption Standard (3-DES ), une version plus avancée de DES et Advanced Encryption Standard (AES ), qui crypte un bloc de 128 bits de texte en 128 bits de texte crypté, à l'aide d'une clé de 128, 129 ou 256 bits.

On peut remarquer que les algorithmes de chiffrement mentionnés ci-dessus utilisent des blocs de dimension fixe, et donc, le texte qui doit être chiffré sera divisé en blocs d'une certaine dimension, requise par l'algorithme utilisé et ensuite, l'algorithme sera appliqué sur chaque obtenu bloquer.

Cependant, que se passe-t-il si la dimension des données n'est pas un multiple de la dimension requise du bloc ? La technique de rembourrage doit être utilisé pour remplir le dernier segment du texte jusqu'à ce qu'il atteigne la dimension d'un bloc. On peut choisir de remplir avec des zéros ou d'utiliser le schéma de remplissage appelé PKCS#5. Le schéma calcule la différence pour le dernier segment de texte

d =dim_block – dim_data MOD dim_block

et remplit chaque octet manquant avec la valeur hexa 0x0d ,

dim_block est la dimension en octets du bloc, requise par l'algorithme

et remplit chaque octet manquant avec la valeur hexa 0x0d ,

dim_block est la dimension en octets du bloc, requise par l'algorithme

Cependant, que se passe-t-il si le texte brut est composé de plusieurs blocs à chiffrer ? La technique d'enchaînement est utilisé, qui établit si le chiffrement d'un bloc est dépendant ou non du chiffrement des blocs précédents.

Les types de chaînage suivants sont disponible dans Oracle :

  • Livre de code électronique (CHAIN_ECB) :chaque bloc est chiffré indépendamment du reste des blocs. L'inconvénient est que l'on peut identifier des motifs répétitifs dans le fragment de texte.
  • Chaînage de blocs de chiffrement (CHAIN_CBC) :pour chaque bloc, avant chiffrement, un opérateur XOR est appliqué avec un vecteur. Pour le premier bloc de la séquence, un vecteur d'initialisation est utilisé, tandis que pour un bloc du reste de la séquence, le résultat de chiffrement du bloc précédent est utilisé comme vecteur de bits
  • Commentaires sur le chiffrement (CHAIN_CFB) :c'est similaire avec CBC, sauf que l'opérateur XOR est appliqué après le chiffrement par bloc.
  • Commentaires sur les résultats (CHAIN_OFB) :c'est similaire avec CFB, sauf que le résultat du bloc précédent est chiffré avant l'application de l'opérateur XOR

Pour chiffrer et déchiffrer les données, nous pouvons utiliser le package DBMS_CRYPTO disponible dans ORACLE. Pour utiliser ce package, SYSDBA doit accorder aux utilisateurs des droits d'exécution, à l'aide de la commande :

GRANT EXECUTE  ON dbms_crypto TO username;

Pour le chiffrement, dbms_crypto.encrypt est utilisé, qui a les paramètres suivants :

dbms_crypto.encrypt(
clear_text IN RAW,
operating_mode IN PLS_INTEGER,
key IN RAW,
initialization_vector IN RAW DEFAULT NULL)
RETURN RAW;

Pour le déchiffrement, dbms_crypto.decrypt est utilisé, qui a les paramètres suivants :

dbms_crypto.decrypt(
clear_text IN RAW,
operating_mode IN PLS_INTEGER,
key IN RAW,
initialization_vector IN RAW DEFAULT NULL)
RETURN RAW;

Un mode de fonctionnement est formé de :

code d'algorithme + code de remplissage + code de chaînage

Voici quelques exemples de chiffrement et de déchiffrement des données :

create or replace PROCEDURE encryption(text IN VARCHAR2, encrypted text OUT VARCHAR2) AS  
raw_set RAW(100);  
raw_password RAW(100);  
encryption_result RAW(100);  
encryption_password VARCHAR2(100) := '[email protected]%5,:QxV';  
operation_mode NUMBER; 
    BEGIN    
        raw_set:=utl_i18n.string_to_raw(text,'AL32UTF8');    
        raw_password := utl_i18n.string_to_raw(encryption_password,'AL32UTF8');        
        operation_mode:=DBMS_CRYPTO.ENCRYPT_DES + DBMS_CRYPTO.PAD_ZERO + DBMS_CRYPTO.CHAIN_ECB;        
        encryption_result:=DBMS_CRYPTO.ENCRYPT(raw_set,operation_mode,raw_password);           
        dbms_output.put_line(encryption_result);    
        encryptedtext := RAWTOHEX (encryption_result);  
END; 

variable result_encryption varchar2(200) 
exec encryption('Text to be encrypted', :result_encryption); 
print result_encryption

create or replace PROCEDURE decryption (encrypted_text IN VARCHAR2, decrypted_text OUT VARCHAR2) AS   
raw_set RAW(100);   
raw_password RAW(100);   
decryption_result RAW(100);   
decryption_password VARCHAR2(100) := '[email protected]%5,:QxV';   
operation_mode NUMBER; 
    BEGIN   
        raw_set:=HEXTORAW(encrypted_text);   
        raw_password :=utl_i18n.string_to_raw(decryption_password,'AL32UTF8');   
        operation_mode:=DBMS_CRYPTO.ENCRYPT_DES + DBMS_CRYPTO.PAD_ZERO + DBMS_CRYPTO.CHAIN_ECB;      
        decryption_result:=DBMS_CRYPTO.DECRYPT(raw_set,operation_mode,raw_password);   
        dbms_output.put_line(decryption_result);   
        decrypted_text := utl_i18n.raw_to_char (decryption_result,'AL32UTF8'); 
    END;  
variable result_decryption varchar2(200) 
exec decryption(:result_encryption,:result_decryption) 
print result_decryption 

Défis du chiffrement des données

Gestion des clés de chiffrement des données

Il est difficile pour les utilisateurs de la base de données de générer manuellement des clés de chiffrement efficaces, qui ont la longueur requise pour l'algorithme de chiffrement. Concernant la fourniture manuelle de la clé de chiffrement sous forme d'un ensemble de chaînes (converti puis en RAW), la longueur de l'ensemble est calculée selon la formule suivante :

L_set =Length_key_in_bits / 8 (caractères)

Par exemple, pour ENCRYPT_AES128, la clé a 128 bits et l'ensemble aura la longueur L_set =128/8 =16 caractères.

Si la clé '1234567890123456' est fournie, elle sera acceptée, tandis que la clé '1234' lèvera l'exception 'longueur de clé trop courte'.

Pour le reste des algorithmes, le tableau suivant donne la longueur de clé effective :

Génération et transmission de clés

Les données sont cryptées en toute sécurité tant que la clé utilisée pour le cryptage est sécurisée. Par conséquent, la clé de chiffrement doit être générée de manière sécurisée. Le package de fonctions RANDOMBYTES de DBMS_CRYPTO offre une génération sécurisée de nombres aléatoires et implémente l'algorithme du générateur de nombres aléatoires. Les développeurs ne doivent pas utiliser le package DBMS_RANDOM car il génère des nombres pseudo-aléatoires, ce qui peut entraîner une pseudo-sécurité.

La fonction RANDOMBYTES est utilisée comme suit :

clé RAW (nr_bytes);

key :=DBMS_CRYPTO.randombytes (nr_bytes);

où nr_bytes représente le nombre d'octets de la clé de chiffrement

Lorsque la clé est transmise d'une application à la base de données, elle doit être chiffrée afin de ne pas être volée lors de sa transmission. Oracle Advanced Security fournit un chiffrement réseau, qui protège les données et les clés cryptographiques lors de leur transit sur le réseau.

Une fois les clés générées, elles doivent être conservées en lieu sûr, car leur divulgation pourrait compromettre la sécurité des données chiffrées. Il existe trois options pour conserver la clé :

  • au niveau de la base de données :stocké dans la base de données (dans une table spéciale) ou dans un fichier de base de données externe
  • au niveau de l'enregistrement :stocké dans la base de données (dans une table spéciale)
  • une combinaison entre les deux types précédents :il existe une clé principale au niveau de la base de données et pour chaque enregistrement, il existe une clé. Une clé hybride est utilisée à la fois pour le chiffrement et le déchiffrement : hybrid_key =master_key XOR record_key (pour la fonction XOR, il existe une fonction PL/SQL :UTL_RAW.bit_xor).

Quelle est la clé la plus efficace ? C'est la clé hybride. Si toute la base de données est volée, les données ne peuvent pas être déchiffrées lorsque la clé principale est stockée dans le système de fichiers. Si la clé principale ou un enregistrement de clé est volé, le reste de l'enregistrement sera toujours protégé.

Chiffrement transparent des données (TDE)

Une autre fonctionnalité de sécurité offerte par Oracle est le Transparent Data Encryption (TDE) , une fonction disponible auprès d'Oracle 10g. TDE permet de déclarer une colonne chiffrée au niveau table de la base de données. Lors de l'insertion de données dans la colonne chiffrée, Oracle chiffre automatiquement les données et stocke leur chiffrement dans la base de données.

Toute requête SELECT déchiffrera automatiquement les données. Il est important de se rappeler que le chiffrement transparent des données ne fait pas de différence entre les utilisateurs et donne les données décryptées, peu importe qui interroge la base de données. Aucune colonne ne peut être chiffrée par TDE :les colonnes de la clé externe (clé étrangère) ne peuvent pas être chiffrées à l'aide de cette méthode.

Par exemple :considérons une table appelée ACCOUNT avec le schéma relationnel ACCOUNT (id_account#, card_series, possessor, amount), où id_account est considéré comme la clé primaire, fait indiqué par le signe ‘#’. Supposons que nous voulions déclarer la card_series et solde colonnes à chiffrer. Cela peut être fait avec ce qui suit :

ALTER TABLE accont MODIFY (card_series ENCRYPT USING 'AES128');
ALTER TABLE accont MODIFY (balance ENCRYPT USING 'AES128');

Pour que cette méthode fonctionne, un portefeuille doit être créé et configuré.

Pourquoi le chiffrement transparent des données empêcher le déchiffrement des données en cas de vol de la base de données ? Eh bien, toutes les colonnes chiffrées d'une table T utilisent la même clé privée Key_T. Si nous avons plus de tables, ,…, qui ont des colonnes chiffrées, alors il y a n clés privées, Key_,…,Key_. Chaque clé privée Key_, j=1,n est chiffrée avec la clé maîtresse, Key_Master, et le résultat de ce chiffrement est stocké dans le dictionnaire de données. La clé principale est stockée en externe dans un portefeuille.

Voyons maintenant les étapes de ce cryptage automatique. Ce sont :

  • obtenir le maître Key_Master à partir du portefeuille externe
  • déchiffrement de la clé privée, Key_, à l'aide de la clé principale
  • cryptage des données à insérer à l'aide de la clé privée, Key_
  • stocker les données chiffrées dans les colonnes du tableau

Les étapes du déchiffrement automatique sont :

  • obtenir la clé principale, Key_Master, à partir du portefeuille externe
  • déchiffrement de la clé privée, Key_, à l'aide de la clé principale
  • déchiffrement des données à l'aide de la clé privée, Key_
  • retourner le résultat

Qu'en est-il de l'intégrité des données lors du chiffrement ? Ici, nous utilisons la technique de hachage.

Hachage

Le chiffrement des données assure la confidentialité des données mais ne garantit pas leur intégrité. Pour éviter ce problème, outre le fait que seules les données originales doivent être chiffrées, nous pouvons utiliser une technique appelée hachage . il y a deux avantages importants :il ne permet pas de déchiffrer les valeurs d'origine et il est déterministe (ce qui signifie qu'appliqué de manière répétitive aux mêmes données, il génère le même résultat). Oracle autorise les algorithmes de hachage suivants :MD5 et SHA-1.

Utilisation :

DBMS_CRYPTO.Hash (
original_set IN RAW,
operation_mode IN PLS_INTEGER) 
RETURN RAW;
where operation_mode is either                        
DBMS_CRYPTO.HASH_MD5 or DBMS_CRYPTO.HASH_SH1

Exemple :

set serveroutput on
DECLARE
credit_card_no VARCHAR2(19) := '1234-5678-1234-5678';
credit_card_no_raw RAW(128) := utl_raw.cast_to_raw(credit_card_no);
encrypted_raw RAW(2048);
BEGIN
  encrypted_raw:=dbms_crypto.hash(credit_card_no_raw, dbms_crypto.hash_md5);
  dbms_output.put_line('MD5: ' || encrypted_raw);
END;

Chiffrement des données indexées

Il n'est pas recommandé aux développeurs de chiffrer les données indexées. Si un index d'une colonne contient des valeurs chiffrées, l'index peut être utilisé pour une simple vérification et est inutilisable à d'autres fins.

Par exemple, supposons qu'une entreprise utilise le numéro d'identification personnel pour le numéro d'employé stocké dans une table de base de données. Évidemment, ces chiffres sont considérés comme des données sensibles et confidentielles et l'entreprise souhaite chiffrer la colonne où elles sont stockées. Comme cette colonne contient des valeurs uniques, un index peut être effectué dessus afin d'avoir de meilleures performances. Cela signifie que l'index contiendra des données cryptées et serait fondamentalement inutilisable.

Conclusion

Pour conclure, il est très important de protéger les données sensibles en les cryptant et en les décryptant. Il faut être conscient de cet aspect et implémenter la sécurité de la base de données en conséquence.

Références :

  1. Développement d'applications à l'aide du chiffrement des données
  2. Feuerstein Steven (2009) Programmation Oracle PL/SQL (5e édition). Éditions O'Reilly. ISBN 978-0-596-51446-4. Chapitre 23 "Sécurité des applications et PL/SQL"
  3. Mode de fonctionnement du chiffrement par blocs