![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/Capture-decran-2024-02-28-144722.png\")
<\/p>\n
<\/p>\n
Pour continuer dans la s\u00e9rie “chiffrement et bases de donn\u00e9es”, nous allons \u00e9voquer le sujet “native network encryption” et “data integrity” dans le cadre d’une connexion client \/serveur sur une base de donn\u00e9es Oracle 19c.<\/p>\n
<\/p>\n
<\/p>\n
Le m\u00e9canisme consiste \u00e0 chiffrer le trafic r\u00e9seau 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\u00e9es.<\/p>\n
Attention, point important \u00e0 remonter, cette fonctionnalit\u00e9 est accessible pour toutes les \u00e9ditions Oracle<\/strong> et ce pour toutes versions. C’est plut\u00f4t une bonne nouvelle quand on conna\u00eet le co\u00fbt d’une licence Entreprise Edition avec “Advanced Security”.<\/p>\n Consulter l’information sur ce lien<\/a><\/p>\n <\/p>\n Pour proc\u00e9der au chiffrement client\/server, Oracle travaille sur une liste d’algorithmes que l’on peut utiliser.<\/p>\n Voici une liste, extraite du site Oracle, pouvant \u00eatre prise en charge.<\/p>\n <\/p>\n Depuis la version 19c, seuls les algorithmes AES (Advanced Encryption Standard) ont \u00e9t\u00e9 valid\u00e9s. On peut ajouter \u00e0 cette liste AES192.<\/p>\n Pour utiliser les nouveaux algorithmes AES, Oracle recommande l’installation d’un patch de prise en charge \u00e0 prendre en compte dans la note 2118136.2<\/a>. Ceci pour les anciennes versions Oracle.<\/p>\n L’algorithme 3DES peut \u00e9galement \u00eatre choisi, mais attention aux soucis de performances r\u00e9cemment relev\u00e9s par Oracle. A n’utiliser qu’avec des syst\u00e8mes tr\u00e8s performants en CPU.<\/p>\n <\/p>\n Il faudra penser \u00e0 conserver l\u2019int\u00e9grit\u00e9 des donn\u00e9es, en effectuant un \u00ab checksum \u00bb sur celles-ci. Attention, MD5 est encore compatible mais plus recommand\u00e9.<\/p>\n <\/p>\n Voici quelques tests de performances effectu\u00e9s permettant d\u2019avoir un retour sur les temps de r\u00e9ponses des Un exemple, trouv\u00e9 sur le net, est le suivant :<\/p>\n “on interroge 100 fois la table des objets d\u2019une base (dba_objects). <\/p>\n On consid\u00e8re une base 100% une connexion sans param\u00e8tres de chiffrement d\u00e9fini.<\/p>\n <\/p>\n <\/p>\n Afin de mettre en \u0153uvre le chiffrement, nous devrons passer des param\u00e8tres dans le fichier “sqlnet.ora<\/span>“ Les param\u00e8tres qui seront \u00e0 configurer cot\u00e9s client sont:<\/p>\n SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT<\/em><\/strong> <\/p>\n Au vu des r\u00e9sultats sur les performances et des recommandations Oracle, nous utiliserons, pour le test, A noter, que l’on pourra d\u00e9finir une cl\u00e9 “crypto_seed<\/span><\/strong>” pour la connexion, en choisissant une valeur de SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER<\/strong><\/em> <\/p>\n Les algorithmes devront \u00eatre identiques<\/strong> (encryption<\/strong> et crypto_checksum<\/strong>) entre le client et le serveur<\/strong> Les 4 valeurs que l’on peut choisir pour le param\u00e8tre SQLNET.ENCRYPTION cot\u00e9 client et serveur sont les suivantes :<\/p>\n <\/p>\n Le tableau suivant donnera la matrice de compatibilit\u00e9 des diff\u00e9rents modes de n\u00e9gociations utilis\u00e9s Il est possible, selon les param\u00e8tres SQLNET.ENCRYPTION<\/span> et SQLNET.CRYPTO_CHECKSUM <\/span>choisis d’activer ou non le chiffrement.<\/p>\n <\/p>\n Ce tableau est extrait du site Oracle sur ce lien<\/a><\/p>\n Lorsque la connexion \u00e9choue, le client re\u00e7oit une erreur ORA-12650. <\/p>\n <\/p>\n Nous testons dans un premier temps une connexion avec chiffrement actif. Puis cot\u00e9 client REQUESTED, ceci pour En r\u00e9sum\u00e9, voici les param\u00e8tres que nous d\u00e9finirons dans le sqlnet.ora cot\u00e9 client :<\/p>\n SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)<\/strong><\/span> et le sqlnet.ora cot\u00e9 serveur :<\/p>\n SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA384)<\/strong><\/span> <\/p>\n Les op\u00e9rations se d\u00e9roulent avec les caract\u00e9ristiques suivantes<\/p>\n <\/p>\n <\/p>\n Voici le contexte de connexion cot\u00e9 base de donn\u00e9es. On s’assure ainsi que le chiffrement client\/serveur est bien actif<\/p>\n <\/p>\n <\/p>\n L’algorithme AES256<\/strong> et le checksum SHA384<\/strong> apparaissent dans les infos de connexions. Les param\u00e8tres \u00e0 mettre en place sur le “sqlnet.ora<\/strong>” du client sont les suivants :<\/p>\n TRACE_UNIQUE_CLIENT = on<\/strong> <\/p>\n Les traces sont donc g\u00e9n\u00e9r\u00e9es, cot\u00e9 client, dans le r\u00e9pertoire \u00ab \/opt\/oracle\/product\/12.2\/dbhome_1\/network\/trace<\/strong> \u00bb.<\/p>\n Nous passons le param\u00e8tre TRACE_LEVEL_CLIENT<\/strong> \u00e0 16 ou niveau SUPPORT afin de r\u00e9cup\u00e9rer le maximum On teste une connexion, avec une simple interrogation sur la vue d\u2019instance (v$instance<\/strong>).<\/p>\n <\/p>\n <\/p>\n Une trace est alors g\u00e9n\u00e9r\u00e9e dans le r\u00e9pertoire $ORACLE_HOME\/network\/trace. Le pid de notre connexion Oracle est le 5129.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Si l\u2019on observer les packets envoy\u00e9s par le client, on voit que ceux-ci sont bien chifrr\u00e9s. La requ\u00eate <\/p>\n On retrouve bien les informations d\u2019encryption dans les trames des packets.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Nous effectuons le m\u00eame test avec une connexion sans chiffrage actif.<\/p>\n S\u2019il l\u2019on se r\u00e9f\u00e8re au tableau de compatibilit\u00e9 client\/serveur sur les mode ENCRYPTION, en pla\u00e7ant les algorithmes d\u2019encryption sur REJECTED cot\u00e9 Les param\u00e8tres du sqlnet.ora sont les suivants cot\u00e9 client :<\/p>\n <\/p>\n SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)<\/strong><\/span> <\/p>\n Cot\u00e9 serveur, on ne modifie rien, on laisse \u00e0 ACCEPTED.<\/p>\n Les op\u00e9rations se d\u00e9roulent \u00e0 l\u2019identique, avec les m\u00eames environnements que pr\u00e9c\u00e9demment.<\/p>\n Si l’on interroge les contextes de connexion du user MANU sur la base<\/p>\n <\/p>\n <\/p>\n On voit \u00e0 pr\u00e9sent que les algorithmes AES256 et SHA384 n\u2019apparaissaient pas dans les informations de S\u2019il l\u2019on se r\u00e9f\u00e8re \u00e0 nouveau au fichier trace, on cherche si les informations sont plus \u00ab parlantes \u00bb. <\/p>\n <\/p>\n La trace g\u00e9n\u00e9r\u00e9e est la suivante , avec le pid 6116 cette fois ci.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Nous voyons dans la trace que le chiffrement est bien inactif :<\/p>\n <\/p>\n <\/p>\n Nous disposons m\u00eames des informations du user connect\u00e9, son nom, son programme, mais aussi, la <\/p>\n Et surtout, nous retrouvons bien notre requ\u00eate\u00a0 select sur la vue from v$instance\u00a0 dans les packets envoy\u00e9s au <\/p>\n Avec, en clair, le r\u00e9sultat obtenu pour cette requ\u00eate :<\/p>\n <\/p>\n <\/p>\n <\/p>\n Selon les besoins en s\u00e9curit\u00e9, nous choisirons d\u2019activer, ou non, le chiffrement sur les connexions client\/serveur en fonction du degr\u00e9 de criticit\u00e9 du serveur et de son exposition au r\u00e9seau.<\/p>\n Etant donn\u00e9 que l\u2019option se place sur le fichier sqlnet.ora, toutes les bases attach\u00e9s \u00e0 ce ORACLE_HOME prendront en compte le chiffrement.<\/p>\n Attention \u00e9galement \u00e0 d\u00e9sactiver les traces cot\u00e9 client, une fois les divers tests termin\u00e9s.<\/p>\n En effet, les r\u00e9pertoires \u2018trace\u2019 dans $ORACLE_HOME\/network\/trace peuvent vite \u00eatre satur\u00e9s.<\/p>\n Dans le sqlnet.ora du client :<\/p>\n TRACE_LEVEL_CLIENT = OFF<\/strong><\/p>\n <\/p>\n \ud83d\ude42<\/p>\n <\/p>\n Pour continuer dans la s\u00e9rie “chiffrement et bases de donn\u00e9es”, nous allons \u00e9voquer le sujet “native network encryption” et “data integrity” dans le cadre d’une connexion client \/serveur sur une base de donn\u00e9es Oracle 19c. Pr\u00e9sentation Le… Continuer la lecture ![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/license_oracle.png\")
<\/p>\nLes algorithmes de chiffrement<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/algo.png\")
<\/p>\nData Integrity<\/h3>\n
\nOracle utilise pour cela les algorithmes SHA pour proc\u00e9der: SHA1, SHA256, SHA384, and SHA512.<\/p>\nPerformances<\/h3>\n
\nconnexions passant \u00e0 travers le chiffrement. Ces tests ont \u00e9t\u00e9 faits sur certains algorithmes qui sont d\u00e9pr\u00e9ci\u00e9s aujourd’hui.<\/p>\n
\nOn rel\u00e8vera les temps \u00e9coul\u00e9s pour chacune de ces op\u00e9rations.”
\nChacun des tests est ex\u00e9cut\u00e9 3 fois sur les diff\u00e9rents algorithmes utilis\u00e9s avec chacun des checksums.
\nCe qui donne le tableau suivant<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/tableau_perf.png\")
<\/p>\nConfiguration<\/h2>\n
\ncot\u00e9 client, et cot\u00e9 serveur.<\/p>\n
\nSQLNET.CRYPTO_SEED<\/em><\/strong>
\nSQLNET.ENCRYPTION_TYPES_CLIENT<\/em><\/strong>
\nSQLNET.CRYPTO_CHECKSUM_CLIENT<\/em><\/strong>
\nSQLNET.ENCRYPTION_CLIENT<\/em><\/strong><\/p>\n
\nles algorithmes AES256<\/strong> pour le chiffrement et SHA384<\/strong> pour le checksum.<\/p>\n
\n10 \u00e0 70 caract\u00e8res alphanum\u00e9riques.
\nPour la partie serveur, les param\u00e8tres \u00e0 d\u00e9finir sont les suivants :<\/p>\n
\nSQLNET.CRYPTO_SEED<\/strong><\/em>
\nSQLNET.ENCRYPTION_TYPES_SERVER<\/strong><\/em>
\nSQLNET.CRYPTO_CHECKSUM_SERVER<\/strong><\/em>
\nSQLNET.ENCRYPTION_SERVER<\/strong><\/em><\/p>\n
\npour que la communication se fasse.<\/p>\nREQUESTED : le chiffrement est demand\u00e9 mais si ce n'est pas possible, le flux client\/serveur se passera via trafic non chiffr\u00e9.\r\nREJECTED : Pas de chiffrement demand\u00e9.\r\nREQUIRED : seul le trafic avec chiffrement sera accept\u00e9.\r\nACCEPTED : le client ou le serveur accepte toute connexion chiffr\u00e9e ou non chiffr\u00e9e. Valeur par d\u00e9faut si \"native network encryption\" n'est pas activ\u00e9<\/pre>\n
\npour une connexion.<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/tab_integ.png\")
<\/p>\n
\nC’est le cas, si nous sommes en REJECTED cot\u00e9 client et REQUIRED cot\u00e9 serveur, par exemple.<\/p>\n<\/code><\/pre>\n<\/h4>\n
Test avec chiffrement actif<\/h4>\n
\nAussi, nous choisissons, cot\u00e9 serveur le mode ACCEPTED.<\/p>\n
\nl’encryption et le checksum.<\/p>\n
\nSQLNET.CRYPTO_SEED = ‘”i5rrruweotcadsfdsafjkdsfqp5f201p45mxskdlfdasf”‘<\/strong><\/span>
\nSQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)<\/strong><\/span>
\nSQLNET.CRYPTO_CHECKSUM_CLIENT = requested<\/strong><\/span>
\nSQLNET.ENCRYPTION_CLIENT = requested<\/strong><\/span><\/p>\n
\nSQLNET.CRYPTO_SEED = ‘”4fhfguweotcadsfdsafjkdsfqp5f201p45mxskdlfdasf”‘<\/strong><\/span>
\nSQLNET.ENCRYPTION_TYPES_SERVER= (AES256)<\/strong><\/span>
\nSQLNET.CRYPTO_CHECKSUM_SERVER = accepted<\/strong><\/span>
\nSQLNET.ENCRYPTION_SERVER = accepted<\/strong><\/span><\/p>\n\n
Connected to:\r\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\n\r\nSQL> show user\r\nUSER is "MANU"<\/pre>\n
SQL> set pages 3000 linesize 190\r\nSQL> select c.sid, c.serial#, c.network_service_banner,c.client_connection from v$session_connect_info c\r\n2* inner join v$session s on (s.sid=c.sid) and s.username ='MANU';\r\n\r\nSID SERIAL# NETWORK_SERVICE_BANNER CLIENT_CONNEC\r\n---------- ---------- ----------------------------------------------------------------------------------------------- -------------\r\n32 1490 TCP\/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous\r\n32 1490 Encryption service for Linux: Version 19.0.0.0.0 - Production Homogeneous\r\n32 1490 AES256 Encryption service adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous\r\n32 1490 Crypto-checksumming service for Linux: Version 19.0.0.0.0 - Production Homogeneous\r\n32 1490 SHA384 Crypto-checksumming service adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous<\/pre>\n
\nOn pourra aussi mettre en place une trace sqlnet afin de voir que les donn\u00e9es envoy\u00e9es via le r\u00e9seau sont bien chiffr\u00e9es durant cette connexion.<\/p>\n
\nTRACE_DIRECTORY_CLIENT = \/opt\/oracle\/product\/12.2\/dbhome_1\/network\/trace<\/strong>
\nTRACE_FILE_CLIENT = trace_client<\/strong>
\nTRACE_LEVEL_CLIENT = 16<\/strong>
\nDIAG_ADR_ENABLED = OFF<\/strong><\/p>\n
\nd\u2019informations, y compris les trames envoy\u00e9es vers le serveur.<\/p>\n[oracle@ip-172-44-2-250 ]$ sqlplus manu@CAPDATADB\r\n\r\nSQL*Plus: Release 12.2.0.1.0 Production on Wed Feb 28 15:34:23 2024\r\n\r\nCopyright (c) 1982, 2016, Oracle. All rights reserved.\r\n\r\nEnter password:\r\nLast Successful login time: Wed Feb 28 2024 15:20:13 +00:00\r\n\r\nConnected to:\r\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\n\r\nSQL> select INSTANCE_NAME,HOST_NAME,VERSION,STATUS,DATABASE_STATUS from v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\nHOST_NAME\r\n----------------------------------------------------------------\r\nVERSION DATABASE_STATUS\r\n----------------- ------------ -----------------\r\nCAPDATADB\r\nip-172-44-2-141.capdata-aws.fr\r\n19.0.0.0.0 ACTIVE<\/pre>\n
[oracle@ip-172-44-2-250 trace]$ ls -rtl\r\ntotal 332\r\n-rw-rw----. 1 oracle oinstall 337246 Feb 28 15:36 trace_client_5129.trc<\/pre>\n
\nselect sur la vue v$instance n\u2019apparait pas en clair, les trames re\u00e7us par le serveur sont chiffr\u00e9s :<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/packet_chiffre.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/encrypt_actif.png\")
<\/p>\nTest sans chiffrement actif<\/h4>\n
\nclient et ACCEPTED cot\u00e9 serveur, nous sommes dans un sc\u00e9nario ou le chiffrement est d\u00e9sactiv\u00e9.<\/p>\n
\nSQLNET.CRYPTO_SEED = ‘”i5rrruweotcadsfdsafjkdsfqp5f201p45mxskdlfdasf”‘<\/strong><\/span>
\nSQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)<\/strong><\/span>
\nSQLNET.CRYPTO_CHECKSUM_CLIENT = rejected<\/span><\/strong><\/span>
\nSQLNET.ENCRYPTION_CLIENT = rejected<\/span><\/strong><\/span><\/p>\nSQL> select c.sid, c.serial#, c.network_service_banner,c.client_connection from v$session_connect_info c\r\n2* inner join v$session s on (s.sid=c.sid) and s.username ='MANU'\r\n\r\n\r\n\r\nSID SERIAL# NETWORK_SERVICE_BANNER CLIENT_CONNEC\r\n---------- ------- ----------------------------------------------------------------------------------------------- -------------\r\n32 24306 TCP\/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production Homogeneous\r\n32 24306 Encryption service for Linux: Version 19.0.0.0.0 - Production Homogeneous\r\n32 24306 Crypto-checksumming service for Linux: Version 19.0.0.0.0 - Production Homogeneous<\/pre>\n
\nconnexion.<\/p>\n
\nOn r\u00e9ex\u00e9cute un test de connexion, avec la m\u00eame requ\u00eate sur un simple select dans la vue v$instance .<\/p>\nConnected to:\r\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\n\r\nSQL> set pages 3000 linesize 200\r\nSQL> select INSTANCE_NAME,HOST_NAME,VERSION,STATUS,DATABASE_STATUS from v$instance;\r\n\r\nINSTANCE_NAME HOST_NAME VERSION STATUS DATABASE_STATUS\r\n---------------- ---------------------------------------------------------------- ----------------- ------------ -----------------\r\nCAPDATADB ip-172-44-2-141.capdata-aws.fr 19.0.0.0.0 OPEN ACTIVE<\/pre>\n
[oracle@ip-172-44-2-250 trace]$ ls -lrt\r\ntotal 568\r\n-rw-rw----. 1 oracle oinstall 337246 Feb 28 15:36 trace_client_5129.trc\r\n-rw-rw----. 1 oracle oinstall 239231 Feb 28 15:58 trace_client_6116.trc<\/pre>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/encrypt_inactif.png\")
<\/p>\n
\nmachine depuis laquelle il est connect\u00e9, et le PID attach\u00e9e \u00e0 la session (ici 616 ce qui correspond au
\nnom de la trace g\u00e9n\u00e9r\u00e9).<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/packet_nonchiff.png\")
<\/p>\n
\nserveur :<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/requete_claire.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/02\/donnees_claires.png\")
<\/p>\nPoints d’attention<\/h3>\n
<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"