Pour continuer dans la série “chiffrement et bases de données”, nous allons évoquer le sujet “native network encryption” et “data integrity” dans le cadre d’une connexion client /serveur sur une base de données Oracle 19c.
Présentation
Le mécanisme consiste à chiffrer le trafic réseau entre un client Oracle et la base cible distante. Pour cela, nous allons tester, via des traces, ce que nous pouvons relever dans les informations SQLNet entre le client et le serveur de bases de données.
Attention, point important à remonter, cette fonctionnalité est accessible pour toutes les éditions Oracle et ce pour toutes versions. C’est plutôt une bonne nouvelle quand on connaît le coût d’une licence Entreprise Edition avec “Advanced Security”.
Consulter l’information sur ce lien
Les algorithmes de chiffrement
Pour procéder au chiffrement client/server, Oracle travaille sur une liste d’algorithmes que l’on peut utiliser.
Voici une liste, extraite du site Oracle, pouvant être prise en charge.
Depuis la version 19c, seuls les algorithmes AES (Advanced Encryption Standard) ont été validés. On peut ajouter à cette liste AES192.
Pour utiliser les nouveaux algorithmes AES, Oracle recommande l’installation d’un patch de prise en charge à prendre en compte dans la note 2118136.2. Ceci pour les anciennes versions Oracle.
L’algorithme 3DES peut également être choisi, mais attention aux soucis de performances récemment relevés par Oracle. A n’utiliser qu’avec des systèmes très performants en CPU.
Data Integrity
Il faudra penser à conserver l’intégrité des données, en effectuant un « checksum » sur celles-ci.
Oracle utilise pour cela les algorithmes SHA pour procéder: SHA1, SHA256, SHA384, and SHA512.
Attention, MD5 est encore compatible mais plus recommandé.
Performances
Voici quelques tests de performances effectués permettant d’avoir un retour sur les temps de réponses des
connexions passant à travers le chiffrement. Ces tests ont été faits sur certains algorithmes qui sont dépréciés aujourd’hui.
Un exemple, trouvé sur le net, est le suivant :
“on interroge 100 fois la table des objets d’une base (dba_objects).
On relèvera les temps écoulés pour chacune de ces opérations.”
Chacun des tests est exécuté 3 fois sur les différents algorithmes utilisés avec chacun des checksums.
Ce qui donne le tableau suivant
On considère une base 100% une connexion sans paramètres de chiffrement défini.
Configuration
Afin de mettre en œuvre le chiffrement, nous devrons passer des paramètres dans le fichier “sqlnet.ora“
coté client, et coté serveur.
Les paramètres qui seront à configurer cotés client sont:
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT
SQLNET.CRYPTO_SEED
SQLNET.ENCRYPTION_TYPES_CLIENT
SQLNET.CRYPTO_CHECKSUM_CLIENT
SQLNET.ENCRYPTION_CLIENT
Au vu des résultats sur les performances et des recommandations Oracle, nous utiliserons, pour le test,
les algorithmes AES256 pour le chiffrement et SHA384 pour le checksum.
A noter, que l’on pourra définir une clé “crypto_seed” pour la connexion, en choisissant une valeur de
10 à 70 caractères alphanumériques.
Pour la partie serveur, les paramètres à définir sont les suivants :
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER
SQLNET.CRYPTO_SEED
SQLNET.ENCRYPTION_TYPES_SERVER
SQLNET.CRYPTO_CHECKSUM_SERVER
SQLNET.ENCRYPTION_SERVER
Les algorithmes devront être identiques (encryption et crypto_checksum) entre le client et le serveur
pour que la communication se fasse.
Les 4 valeurs que l’on peut choisir pour le paramètre SQLNET.ENCRYPTION coté client et serveur sont les suivantes :
REQUESTED : le chiffrement est demandé mais si ce n'est pas possible, le flux client/serveur se passera via trafic non chiffré. REJECTED : Pas de chiffrement demandé. REQUIRED : seul le trafic avec chiffrement sera accepté. ACCEPTED : le client ou le serveur accepte toute connexion chiffrée ou non chiffrée. Valeur par défaut si "native network encryption" n'est pas activé
Le tableau suivant donnera la matrice de compatibilité des différents modes de négociations utilisés
pour une connexion.
Il est possible, selon les paramètres SQLNET.ENCRYPTION et SQLNET.CRYPTO_CHECKSUM choisis d’activer ou non le chiffrement.
Ce tableau est extrait du site Oracle sur ce lien
Lorsque la connexion échoue, le client reçoit une erreur ORA-12650.
C’est le cas, si nous sommes en REJECTED coté client et REQUIRED coté serveur, par exemple.
Test avec chiffrement actif
Nous testons dans un premier temps une connexion avec chiffrement actif.
Aussi, nous choisissons, coté serveur le mode ACCEPTED.
Puis coté client REQUESTED, ceci pour
l’encryption et le checksum.
En résumé, voici les paramètres que nous définirons dans le sqlnet.ora coté client :
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)
SQLNET.CRYPTO_SEED = ‘”i5rrruweotcadsfdsafjkdsfqp5f201p45mxskdlfdasf”‘
SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)
SQLNET.CRYPTO_CHECKSUM_CLIENT = requested
SQLNET.ENCRYPTION_CLIENT = requested
et le sqlnet.ora coté serveur :
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA384)
SQLNET.CRYPTO_SEED = ‘”4fhfguweotcadsfdsafjkdsfqp5f201p45mxskdlfdasf”‘
SQLNET.ENCRYPTION_TYPES_SERVER= (AES256)
SQLNET.CRYPTO_CHECKSUM_SERVER = accepted
SQLNET.ENCRYPTION_SERVER = accepted
Les opérations se déroulent avec les caractéristiques suivantes
- Pour la partie client, une installation d’Oracle Client 12.2.
- Pour la partie serveur, 1 base CAPDATADB version 19c avec le patchser 19.11 d’avril 2021
Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production SQL> show user USER is "MANU"
Voici le contexte de connexion coté base de données. On s’assure ainsi que le chiffrement client/serveur est bien actif
SQL> set pages 3000 linesize 190 SQL> select c.sid, c.serial#, c.network_service_banner,c.client_connection from v$session_connect_info c 2* inner join v$session s on (s.sid=c.sid) and s.username ='MANU'; SID SERIAL# NETWORK_SERVICE_BANNER CLIENT_CONNEC ---------- ---------- ----------------------------------------------------------------------------------------------- ------------- 32 1490 TCP/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous 32 1490 Encryption service for Linux: Version 19.0.0.0.0 - Production Homogeneous 32 1490 AES256 Encryption service adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous 32 1490 Crypto-checksumming service for Linux: Version 19.0.0.0.0 - Production Homogeneous 32 1490 SHA384 Crypto-checksumming service adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous
L’algorithme AES256 et le checksum SHA384 apparaissent dans les infos de connexions.
On pourra aussi mettre en place une trace sqlnet afin de voir que les données envoyées via le réseau sont bien chiffrées durant cette connexion.
Les paramètres à mettre en place sur le “sqlnet.ora” du client sont les suivants :
TRACE_UNIQUE_CLIENT = on
TRACE_DIRECTORY_CLIENT = /opt/oracle/product/12.2/dbhome_1/network/trace
TRACE_FILE_CLIENT = trace_client
TRACE_LEVEL_CLIENT = 16
DIAG_ADR_ENABLED = OFF
Les traces sont donc générées, coté client, dans le répertoire « /opt/oracle/product/12.2/dbhome_1/network/trace ».
Nous passons le paramètre TRACE_LEVEL_CLIENT à 16 ou niveau SUPPORT afin de récupérer le maximum
d’informations, y compris les trames envoyées vers le serveur.
On teste une connexion, avec une simple interrogation sur la vue d’instance (v$instance).
[oracle@ip-172-44-2-250 ]$ sqlplus manu@CAPDATADB SQL*Plus: Release 12.2.0.1.0 Production on Wed Feb 28 15:34:23 2024 Copyright (c) 1982, 2016, Oracle. All rights reserved. Enter password: Last Successful login time: Wed Feb 28 2024 15:20:13 +00:00 Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production SQL> select INSTANCE_NAME,HOST_NAME,VERSION,STATUS,DATABASE_STATUS from v$instance; INSTANCE_NAME ---------------- HOST_NAME ---------------------------------------------------------------- VERSION DATABASE_STATUS ----------------- ------------ ----------------- CAPDATADB ip-172-44-2-141.capdata-aws.fr 19.0.0.0.0 ACTIVE
Une trace est alors générée dans le répertoire $ORACLE_HOME/network/trace. Le pid de notre connexion Oracle est le 5129.
[oracle@ip-172-44-2-250 trace]$ ls -rtl total 332 -rw-rw----. 1 oracle oinstall 337246 Feb 28 15:36 trace_client_5129.trc
Si l’on observer les packets envoyés par le client, on voit que ceux-ci sont bien chifrrés. La requête
select sur la vue v$instance n’apparait pas en clair, les trames reçus par le serveur sont chiffrés :
On retrouve bien les informations d’encryption dans les trames des packets.
Test sans chiffrement actif
Nous effectuons le même test avec une connexion sans chiffrage actif.
S’il l’on se réfère au tableau de compatibilité client/serveur sur les mode ENCRYPTION, en plaçant les algorithmes d’encryption sur REJECTED coté
client et ACCEPTED coté serveur, nous sommes dans un scénario ou le chiffrement est désactivé.
Les paramètres du sqlnet.ora sont les suivants coté client :
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)
SQLNET.CRYPTO_SEED = ‘”i5rrruweotcadsfdsafjkdsfqp5f201p45mxskdlfdasf”‘
SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)
SQLNET.CRYPTO_CHECKSUM_CLIENT = rejected
SQLNET.ENCRYPTION_CLIENT = rejected
Coté serveur, on ne modifie rien, on laisse à ACCEPTED.
Les opérations se déroulent à l’identique, avec les mêmes environnements que précédemment.
Si l’on interroge les contextes de connexion du user MANU sur la base
SQL> select c.sid, c.serial#, c.network_service_banner,c.client_connection from v$session_connect_info c 2* inner join v$session s on (s.sid=c.sid) and s.username ='MANU' SID SERIAL# NETWORK_SERVICE_BANNER CLIENT_CONNEC ---------- ------- ----------------------------------------------------------------------------------------------- ------------- 32 24306 TCP/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous 32 24306 Encryption service for Linux: Version 19.0.0.0.0 - Production Homogeneous 32 24306 Crypto-checksumming service for Linux: Version 19.0.0.0.0 - Production Homogeneous
On voit à présent que les algorithmes AES256 et SHA384 n’apparaissaient pas dans les informations de
connexion.
S’il l’on se réfère à nouveau au fichier trace, on cherche si les informations sont plus « parlantes ».
On réexécute un test de connexion, avec la même requête sur un simple select dans la vue v$instance .
Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production SQL> set pages 3000 linesize 200 SQL> select INSTANCE_NAME,HOST_NAME,VERSION,STATUS,DATABASE_STATUS from v$instance; INSTANCE_NAME HOST_NAME VERSION STATUS DATABASE_STATUS ---------------- ---------------------------------------------------------------- ----------------- ------------ ----------------- CAPDATADB ip-172-44-2-141.capdata-aws.fr 19.0.0.0.0 OPEN ACTIVE
La trace générée est la suivante , avec le pid 6116 cette fois ci.
[oracle@ip-172-44-2-250 trace]$ ls -lrt total 568 -rw-rw----. 1 oracle oinstall 337246 Feb 28 15:36 trace_client_5129.trc -rw-rw----. 1 oracle oinstall 239231 Feb 28 15:58 trace_client_6116.trc
Nous voyons dans la trace que le chiffrement est bien inactif :
Nous disposons mêmes des informations du user connecté, son nom, son programme, mais aussi, la
machine depuis laquelle il est connecté, et le PID attachée à la session (ici 616 ce qui correspond au
nom de la trace généré).
Et surtout, nous retrouvons bien notre requête select sur la vue from v$instance dans les packets envoyés au
serveur :
Avec, en clair, le résultat obtenu pour cette requête :
Points d’attention
Selon les besoins en sécurité, nous choisirons d’activer, ou non, le chiffrement sur les connexions client/serveur en fonction du degré de criticité du serveur et de son exposition au réseau.
Etant donné que l’option se place sur le fichier sqlnet.ora, toutes les bases attachés à ce ORACLE_HOME prendront en compte le chiffrement.
Attention également à désactiver les traces coté client, une fois les divers tests terminés.
En effet, les répertoires ‘trace’ dans $ORACLE_HOME/network/trace peuvent vite être saturés.
Dans le sqlnet.ora du client :
TRACE_LEVEL_CLIENT = OFF
🙂
Continuez votre lecture sur le blog :
- Le chiffrement et SQL Server – Episode 2 : Mise en oeuvre de TDE (Capdata team) [SQL Server]
- Le chiffrement Oracle : Transparent Data Encryption sur Oracle 19c (Emmanuel RAMI) [Oracle]
- Le chiffrement et SQL Server – Episode 1 : Transparent Data Encryption (TDE) vs Always Encrypted (Capdata team) [SQL Server]
- Se connecter à SQL Server à travers Oracle, quelle drôle d’idée ? (Capdata team) [OracleVintage]
- Le chiffrement et SQL Server – Episode 3 : Always Encrypted (Capdata team) [AzureSQL Server]