2 – Pourquoi ?
Nous avons dit que la firme Oracle a besoin d’argent… Il suffit de regarder les cours de bourse d’Oracle pour constater son inexorable déclin. Dans le même temps, comparer ceux de son principal challenger Microsoft…

Comment Oracle en est-il arrivé là ? Il n’y a pas que le prix exorbitant des licences qui font reculer les clients… D’autres éléments clefs font rétrécir la part de marché d’Oracle. Cela a commencé il y a plus de 10 ans, lorsqu’est sortit la version 2005 de SQL Server de Microsoft. À l’époque, Oracle se croyait « unbreakable ». Hélas plusieurs analystes montraient que sur le plan de la sécurité Oracle était bien moins bonne que celle de SQL Server, avec des bogues récurrents et un temps de correction anormalement lent (voir notamment l’étude de David Litchfield de 2006). Sécurité qui ne s’est pas améliorée hélas au fil du temps ou les comparaisons basées sur les failles (CVE : Common Vulnerabilities and Exposures) recensées par le NIST (National Institute of Standards and Technology) donne un avantage de plus en plus grand à SQL Server au détriment d’Oracle sur le plan des failles de sécurité ! (voire l’étude Edison de 2013)

Etude Litchfield – comparatif de sécurité entre Oracle et SQL Server de 2000 à 2006

Etude Edison – CVE NIST historique des vulnérabilités Oracle vs SQL Server

Bases de données les plus utilisées pour les missions critiques (source Information Week – State of Database Technologie 2016)

Outre ces éléments il y a un facteur majeur qui rentre en ligne de compte sur le long terme. Le cloud (infonuagique) !… Larry Ellison y a longtemps été peu favorable et indécis. Le résultat est sans appel. Microsoft y existe et s’en trouve être un des leader derrière Amazon. Oracle n’existe pas sur ce marché. Les enquêtes du Gartner Group (Magic Quadrant pour le cloud) le montre bien…

Gartner Magic Quadrant 2014 for Cloud Infrastructure as a Service

Gartner Magic Quadrant 2015 for Cloud Infrastructure as a Service

2 – Des pratiques scandaleuses
Dans l’article de Business Insider une pratique s’apparente à du chantage. Oracle consent à réduire l’addition, si le client passe dans le cloud. Or nous venons de le voir, les clients sont loin de se précipiter dans l’infonuagique à la sauce Oracle, lui préférant de loin Amazon lorsqu’ils restent Oracleur ou Azure lorsqu’ils passent à SQL Server.
Un autre article (« Comment se déroule un audit logiciel avec Oracle… » du Monde Informatique) montrent à quel point les pratiques d’Oracle sont scandaleuses et frisent le hors la Loi… « Oracle réclame des informations qu’elle n’est pas supposée demander contractuellement sur les serveurs sur lesquels ne tournent pas de logiciel Oracle et sur le personnel de Mars qui n’utilise pas les logiciels d’Oracle« . Imaginez quelles sont les implications d’une telle intrusion dans vos serveurs ou auprès de vos employés !
D’où les conseils distillés par certains juriste et économistes, d’intégrer les risques de coûts associés aux audits d’Oracle comme charges supplémentaire aux offres commerciales, ce qui a pour effet de gonfler la note finale d’acquisition des licences Oracle !

3 – les options payantes
Je me suis livré à une comparaisons des options payantes dans oracle et gratuites dans SQL Server. Microsoft n’offre d’ailleurs pas d’options payantes, mais les fonctionnalités dépendant des versions (comme dans Oracle d’ailleurs). De plus, il existe de nombreux outils complémentaires gratuits pour SQL Server disponible sur le site web communautaire codeplex.
Voici un tableau résumant la chose :

Comparaison des fonctionnalités Oracle (payantes) et SQL Server (gratuites)

4 – Le prix…
De la même manière, j’ai étudié le montant comparatif des licences à payer pour l’équivalence d’Oracle avec SQL Server, basé sur la version Enterprise. Le résultat est édifiant…
Prix des options Oracle (21 juin 2016) « Processor Licence » :

Prix des licences Oracle édition Enterprise : 47 500 $
Le prix des licences Oracle s’établie pour 2 processeurs. Par exemple sur une machine quadriprocesseur ayant des CPU comportant 12 coeurs, le facteur de licence est donc de 24 (4 x 12 / 2).

Prix des licences SQL Server édition Enterprise : 27 496 $
Le prix des licences SQL Server s’établie pour 4 processeurs. Par exemple sur une machine quadriprocesseur ayant des CPU comportant 12 coeurs, le facteur de licence est donc de 12 (4 x 12 / 4).

Comparaison basé sur le prix au processeur : (47 500 / 2) / (27 496 / 4) = 4
Oracle, sans aucune option payante, est donc naturellement 4 fois plus cher que SQL Server

Avec notre machine exemple (quadriprocesseur ayant des CPU comportant 12 coeurs) et toutes les options, nous arrivons à la différence suivante :
Oracle : 24 x ( 47 500 + 139 500 ) = 4 488 000 $
SQL Server : 12 x 27 496 = 329 952 $
À ce stade, Oracle est 13,6 fois plus cher…

Mais vous pouvez négocier !

• les remises maximales chez Oracle vont jusqu’à 70%, vous passez donc à : 1 346 400 $
• les remises maximales chez Microsoft vont jusqu’à 40%, vous passez donc à : 197 971 $

De plus si vous avez misé sur des serveur dotés de processeurs OPTERON d’AMD, alors Microsoft accorde un facteur de réfaction supplémentaire de 25%. La note passe donc à 148 478 $
Après négociation et utilisation de processeurs Opteron d’AMD, au final, Oracle s’avère 9 fois plus cher…

En conclusion

Comme je le mentionnait dans un article précédent « le déclin d’Oracle » la firme de Redwood Shores est en sérieuse perte de vitesse. Elle n’est même plus le champion de l’avancée technologique. Par exemple elle s’est faite grillée sur le « In Memory » par SAP avec HanaDB, puis par SQL Server…
Sur les performances la plupart des benchmarks effectués par les utilisateurs montre quelle est plus gourmande à performances équivalente que la plupart de ses challengers ou si l’on prend l’autre bout de la lorgnette, qu’elle est moins performantes sur une même machine. Mais Oracle interdisant de publier le moindre benchmark concernant le produit, vous ne trouverez pas d’étude sérieuses sur le sujet. Reste les benchmarks officiels du TPC, mais là c’est une autre histoire… Oracle ne publie que les résultats du TCP-C datant de 1992 donc sur une base de données datée de 23 ans comportant en tout et pour tout 8 tables et des jointures limitées à 2 tables sans aucune sous requête ! Et même dans ce cas, SQL AnyWhere de SAP (anciennement Syabse) la bât sur le coût…
En revanche SQL Server se sert du TPC-E plus récent (2007) et plus réaliste, comportant 33 tables des jointures avec 7 tables et de multiples sous requêtes. Et là curieusement, Oracle n’y a jamais présenté un seul résultat de benchmark !
Et ce déclin est bien constaté par d’inexorables chiffres. Par exemple celui comparant, pour un organisme de formation bien connu pour son indépendance, le nombre de stagiaires formés sur chacune des deux plateformes…

Formation professionnelle – évolution 2005-2015 Oracle vs SQL Server

Pas la peine de vous faire un dessin !

Le hachage consiste à calculer une donnée de petite dimension à partir d’une donnée de grande dimension afin de s’en servir comme repère dans différents processus algorithmique. La valeur obtenu par hachage est un nombre ou une chaine binaire et dans ce dernier cas généralement représentée en hexadécimal.
Les algorithmes de hachage les plus connus sont : MD2, MD4, MD5 (16 octets / 128 bits en sortie), SHA (ou SHA-0), SHA-1 (20 octets / 160 bits en sortie), SHA-2 (224 à 512 bits), Whirlpoll (64 octets / 512 bits).
On trouvera la description des algorithmes de calcul de ces fonctions de hachage aux URL suivantes :

La valeur en sortie est de taille fixe quel que soit la longueur de l’information d’entrée. Du point de vue des mathématiques il ne peut s’agir d’un processus de cryptage puisque le cryptage produit des données dont le volume est au moins aussi important que le volume des données en entrée, voir beaucoup plus lorsque les données d’entrée sont de petits volumes.
Certains logiciels utilisent leurs propres algorithmes pour générer des valeurs de hachage. Par exemple SQL Server implémente les fonctions CHECKSUM, BINARY_CHECKSUM et CHECKSUM_AGG pour calculer un entier 32 bits à partir d’une valeur, d’une expression ou d’une liste d’expression ou de valeurs combinées, soit pour une ligne, soit pour une colonne.
On trouvera un exemple de l’algorithme utilisé à l’URL suivante : http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=70832

Le hachage entraîne fatalement des collisions, c’est à dire que différentes informations peuvent produire une même valeur de hachage.

Voici un exemple de collision de hachage avec la fonction MD5…
Pour PostGreSQL :

Pour MS SQL Server :

le 20e octet est différent dans les deux chaines hexadécimales passées en argument.

Le hachage n’est pas non plus réversible. Il n’existe pas de fonction permettant à coup sûr de retrouver l’information initiale partant de la valeur hachée. La possibilité de collisions s’oppose à la bijection impérativement nécessaire à déterminer une fonction réciproque.

Le but du hachage n’est donc pas de crypter des données mais de donner une « empreinte » à une donnée.

Qu’est-ce que le cryptage ?

Le cryptage est l’ensemble des processus permettant à une donnée d’être transformée en une autre incompréhensible pour qui ne connais pas la donnée originale, puis, partant de la transformation, d’être retransformée en donnée d’origine.
Le cryptage nécessite donc l’existence de deux traitements conjoints et bijectifs : l’un de cryptage, l’autre de décryptage. On parle alors de correspondance univoque entre l’ensemble des données en clair et l’ensemble des données cryptées.
Le chiffrement est un sous ensemble du cryptage qui consiste à utiliser des fonctions mathématiques afin de crypter et de décrypter. Néanmoins il en existe d’autres comme par exemple la stéganographie…

Les techniques modernes de cryptage en matière informatique sont basées sur le chiffrement à l’aide d’algorithmes à clefs :

L’algorithme est connu et la clef de décryptage est confidentielle. La sécurité est basée sur la complexité d’un possible déchiffrement par une attaque de type « force brute » (essais de décryptage par toutes une série de clef probables).
La complexité du chiffrement est liée à l’algorithme et à la longueur de la clef. Les algorithmes à clef asymétriques étant plus fiables car plus complexes, mais aussi plus couteux en temps de traitement.

Principaux algorithmes (et longueur de clef) :

NOTA : les algorithmes de type RC sont aujourd’hui considérés comme peu fiables et ne doivent plus être utilisés en production, car ils sont faciles à casser. RC2 fût longtemps utilisé par Lotus Notes. RC4 est encore utilisé pour protéger les informations d’un réseau wifi avec clef WEP ou WPA.

Emploi du hachage

Les tous premiers emplois du hachage ont été une pseudo cryptographie à sens unique destinée à vérifier la justesse d’une information connue. Le principe est assez simple : on calcule une valeur de hachage sur des informations confidentielle et on stocke cette valeur plutôt que les informations.
Si quelqu’un vient avec les données originales que l’on hache avec le même algorithme, alors les deux valeurs (le hachage calculé et le hachage stocké) sont identiques; On suppose alors que les données sont les mêmes, ce qui, du fait des collisions potentielles est paradoxalement faux.
Mais avant l’an 2000, exploiter un véritable mécanisme de cryptage était considéré comme un crime et passible d’une peine de prison. C’est pourquoi le hachage prit de l’ampleur avant que deux choses ne se produisent :

Dès lors les algorithmes de cryptage ont remplacé la plupart des processus de hachage sauf dans les systèmes encore en vigueur dont ils constituent une part essentiel du fonctionnement.

Néanmoins le hachage peut rendre d’inestimables services. Il est notablement utilisé dans les systèmes informatiques distribués ou dans la gestion du parallélisme d’accès à des ressources d’un système, notamment pour situer une information.
Ainsi dans un système de bases de données distribuées on calculera une clef de hachage sur les éléments d’authentification de l’utilisateur et sur cette clef on calculera un modulo en fonction du nombre de nœuds dans le maillage du système distribué.
Par exemple pour un site web comme fnac.com il existe de nombreux serveurs de bases de données, chacun ayant en table tous les produits à vendre, mais un client n’existant que sur un seul des serveurs.
Tant que l’utilisateur navigue anonymement on route ses requêtes sur le serveur le moins chargé à l’instant t;
Dès qu’il est authentifié ou calcule une clef de hachage sur son mail + mot de passe, puis on calcule un modulo en fonction du nombre de serveurs et on route dorénavant toutes ses requêtes sur le serveur dont l’indice correspond au modulo, puisque c’est seulement sur ce serveur que le client est connu.

Le même algorithme est appliqué dans certains moteurs de bases de données relationnelles pour gérer des traitements en parallèle ou diminuer le temps de traitement. Par exemple pour résoudre une jointure (hash join) ou un groupage (hash group)

Emploi de la cryptographie

La cryptographie sert à rendre confidentielles certaines informations qui ne pourrons être décryptées que par ceux qui connaisse la façon de crypter et donc de décrypter.
Elle permet aussi l’authentification, par le biais de certificat qui sont des documents liant une identité à une clef par le biais d’une signature (tiers de confiance) et permettent d’avoir la certitude sur l’origine d’une entité.

Signature de documents et authentification

La signature numérique (ou signature électronique) permet de garantir l’intégrité d’un document électronique et par là même d’en authentifier l’auteur.
Elle fonctionne à l’aide d’une clef asymétrique ou d’un certificat, et une fonction de hachage :

Il est par exemple possible de « signer » un programme informatique (exécutable ou DLL).

Chiffrement de données

Un exemple typique de chiffrement est la communication d’information confidentielle par email. En effet, les données d’un email peuvent être interceptées sur le réseau Internet, ce à quoi s’emploient certaines organisations telles que la NSA.

La confidentialité des données stockées notamment dans les bases de données nécessite parfois du chiffrement. C’est le cas des données des cartes bancaires ou des données personnelles notamment dans certains domaines sensibles comme la politique, le syndicalisme, la religion ou la santé.
Dans ce dernier secteur, la Loi française impose des standards de chiffrement très élevées lorsque ces données sont accessibles sur Internet (Décret n° 2006-6 relatif à l’hébergement de données de santé à caractère personnel).

Certains SGBDR incorporent des services de génération et de gestion de clefs, de cryptage/décryptage et d’authentification par certificat. C’est par exemple le cas d’Oracle ou de MS SQL Server qui sont leurs propres autorités de certifications et stockent les clefs dans les bases.
D’autres SGBDR propose des fonctions de cryptage/décryptage sans la gestion des clefs, ce qui pose le problème de la conservation des clefs… C’est le cas de MySQL et de PostGreSQL qui nécessite un tiers externe de certification et obligent à véhiculer les clefs d’une manière ou d’une autre, souvent par le biais de fichiers sur le serveur…
Le chiffrement des données dans les bases de données posent d’ailleurs d’autres problèmes :

Le salage est abordé au paragraphe suivant et constitue une faille de sécurité importante en son absence.

La rapidité d’accès à l’information est notablement diminuée par le fait de crypter et décrypter en permanence

La volumétrie des données cryptées est plus importante en général que lorsque les données ne sont pas cryptées

Enfin, il est très difficile de rendre les recherches performantes dès lors que les données sont cryptées et salées par le simple fait qu’il est impossible d’utiliser un index et que par conséquent, il faut lire séquentiellement toutes les données et les décrypter avant d’effectuer la comparaison.

Il faut aussi faire très attention dans les bases de données au recoupement des données qui permettrait, même avec un chiffrage, de trouver certaines données. En effet, toutes les informations ne sont pas chiffrées et heureusement sinon les performances seraient catastrophiques et la base inexploitable… Mais imaginons une base de données dans laquelle nous savons qu’un des patients est un général argentin… Si ces informations figurent en clair et que, comme il est probable, il y a peu d’argentins et peu de généraux dans les données, alors il est facile de trouver ou figure cet individu dans la base et par là même de retrouver de fil en aiguille certaines informations comme son prochain rendez-vous de chimio !

Pour pallier à ce dernier inconvénient, une autre solution de chiffrement dans les bases données est basée sur le cryptage du stockage et non plus des données (TDE ou Transparent Data Encryption que l’on trouve notamment chez Oracle et MS SQL Server). Les données sont alors manipulées en clair en mémoire et de façon optimisé (utilisation des index) alors qu’elles figurent de manière chiffrées dans les fichiers (données des tables en index et journal de transactions), le cryptage/décryptage étant assurée à la volée lors des entrées / sorties au niveau du disque.

Enfin, certains SGBDR (Oracle, MS SQL Server) permmettent d’utiliser des boitiers externes de chiffrement inviolables (HSM ou Hardware Security Module) que l’on place sur le réseau et qui sont utilisés par le serveur SQL. En cas de tentative d’accès au boitier, les clefs sont automatiquement détruites.
Un exemple d’utilisation d’un HMS en pratique est celui qui protège les données personnelles confidentielles de santé des agents territoriaux de France (environ 2 millions d’individus) par le biais d’un HSM et d’un serveur de bases de données Microsoft SQL Server,

Salage

Le salage, est une méthode permettant de renforcer la sécurité des informations cryptées en y ajoutant une donnée supplémentaire afin d’empêcher que deux informations identiques conduisent aux mêmes données chiffrées. Le but du salage est de lutter contre une attaque par analyse fréquentielle.
Le cas est classique dans les bases de données. En effet, lorsque le système concentre beaucoup de données, il est fréquent de trouver des informations identiques (redondances) comme c’est par exemple le cas des noms de famille (MARTIN, DURAND, LEFEBVRE…)
Dès lors une analyse basées sur la fréquence d’apparition des redondances permettrait assez rapidement de casser le code.
Pour pallier à cet inconvénient, certains SGBDR comme Oracle ou SQL Server intègrent automatiquement un salage pour que deux données identiques donnent deux codes chiffrés différents.

NOTA : les serveurs de bases de données comme MySQL ou PostGreSQL ne permettent pas d’utiliser un salage automatique des données lors de l’utilisation des fonctions de cryptage.

Bases de données et chiffrement

À la lecture des paragraphes précédent, il apparait clair que les solutions de chiffrement actuelles dans les bases de données « libres » comme PostGreSQL ou MySQL sont incapable de procurer une sécurité suffisante :

Exemple de chiffrement de données dans les bases de données

Avec PostGreSQL, extension pgcrypto avec algorithme AES :

Cryptage :

Décryptage :

Comme on le voit, le mot de passe de la clef de cryptage est passée en clair lors de l’utilisation des fonctions de cryptage et décryptage.
Le chiffrement de MARTIN a donné deux fois le même code, la longueur du code est d’une quinzaine d’octets…

Avec SQL Server (chiffrement intégré dans toutes les versions) algorithme AES :

Cryptage :

Décryptage :

Le mot de passe de la clef n’est pas passé pour crypter et décrypter. L’ouverture de la clef peut être automatisée côté serveur par un déclencheur FOR LOGON.
Le chiffrement de MARTIN a donné deux codes différents et la longueur du code est de 52 octets…
On peut aussi utiliser un certificat à la place du mot de passe.

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

À lire donc : Microsoft SQL Server and Oracle® Database : A Comparative Study on Total Cost of Administration (TCA)

Le site web sur le SQL et les SGBDR

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot