Module 7 - Sécurité
La sécurité embarquée dans les bases de données
Déverrouiller le module

Compte tenu des menaces qui pèsent sur nos données, un mouvement se fait de plus en plus net, qui consiste à embarquer les techniques de protection des données, directement dans les bases de données, en complément des développements spécifiques que l’on pourra toujours effectuer pour durcir les protections.

En matière de bases de données, il n’y a pas que le Big Data, plus concerné d’ailleurs par la gestion de fichiers, autrement dit par le stockage physique, que par leur description logique. Il y a aussi la sécurité que l’on veut associer aux données, histoire de se protéger contre les attaques tous azimuts, la récupération et la vente de nos données par des partenaires, etc. Les éditeurs de bases de données ont bien compris que la plus grande qualité dans ce domaine est d’être paranoïaque, constamment sur le « qui-vive » et que les artefacts de protection sont les bienvenus.

C’est en tout cas ce qui ressort des tendances actuelles, aussi bien chez Oracle, Microsoft e d’autres spécialistes, une évolution qui méritait le coup de projecteur que nous lui appliquons.

Les techniques de protection internes

Il ne s’agit pas ici de revenir sur les techniques d’authentification et de contrôle d’accès, car elles ne sont pas spécifiques aux bases de données. Ce qui nous intéresse ici ce sont les artefacts intégrés dans les « databases », dans les SGBD, qui permettent de les protéger, de les soustraire à la vue des usagers, de les discriminer en termes de sécurité.

Il y a trois grandes techniques mises en œuvre : le chiffrement, le masquage sélectif des données et le contrôle d’intégrité. Des techniques que l’on retrouve dans les deux grands SGBD du moment, Oracle 12c et SQL Server 2016.

Le chiffrement consiste à appliquer un algorithme « d’encryption » à tout ou partie d’une base de données, sur la foi de critères qui auront été définis séparément.

Oracle 12c est un bon exemple. Il comporte un mécanisme « Oracle Advanced Security », qui permet de chiffrer une colonne, une table ou la totalité de la base de données.

Il se fonde pour cela sur l’algorithme symétrique AES, avec une clé de 128, 192 ou 256 bits. L’avantage de la symétrie étant la rapidité de l’opération, AES ne souffrant pas, par ailleurs, des mêmes faiblesses que les autres algorithmes symétriques, dont AES. Il n’a, en fait, jamais été décrypté, ce qui est un signe de robustesse à défaut d’être une garantie…

Comme AES a besoin d’une clé pour fonctionner, la génération de cette clé se fait par un système de « master keys », stockées en dehors de la base, dans un « Wallet Oracle » ou un « Oracle Key Vault ». C’est à partir de cet « étage » que les clés AES sont générées.

En termes de sécurité, on ne peut guère faire mieux aujourd’hui, sachant que l’on peut appliquer le chiffrement de manière discriminatoire sur tout ou partie de la base de données.

Il faut cependant relever qu’il n’est pas possible d’appliquer ce traitement algorithmique sur une donnée chiffrée, ce qui nous obligera à déchiffrer les données avant de pouvoir les réutiliser. Ce problème dit du « chiffrement homomorphe », n’a toujours pas été résolu aujourd’hui, non pas en termes algorithmiques, mais de temps de traitement.

Les autres « databases » du marché, SQL Server, Postgre, Maria DB, etc., comportent toutes un mécanisme de ce type.

Alors qu’il y a peu, pour garantir la « sécurité » des données d’une base, il fallait développer du code, les SGBD disposent aujourd’hui de moyens internes, qui évoluent en permanence, pour prendre en charge certains de ses aspects. Trois domaines sont concernés : le chiffrement natif des données, le contrôle d’intégrité et le masquage sélectif.
Le contrôle d’intégrité

Le contrôle d’intégrité sur une database consiste à s’assurer non pas de la confidentialité des données, qui pourraient apparaître en clair, mais du fait qu’elles ne pourront pas être modifiées, par un tiers non autorisé.

La technique est classique, qui là aussi peut s’appliquer à une colonne, une table ou une base complète. Elle consiste à calculer une valeur de hash significative du périmètre à contrôler, qui sera recalculé et vérifié, à chaque fois que l’on voudra utiliser les données ainsi protégées.

Le calcul de hash se fait selon un algorithme dédié, SHA 3 maintenant et MD 5 par le passé, qui génère une suite binaire de 192 ou 256 bits, la totalité du hash, on dit aussi empreinte, étant changée si vous modifiez ne serait-ce qu’un seul caractère des données à protéger.

Pour calculer le hash, il y aura deux solutions. Soit on écrit un code SQL, soit on écrit du code avec un langage quelconque en utilisant un framework dédié.

Oracle, par exemple, permet d’utiliser la commande SQL STANDARD_HASH, qui effectue son calcul en utilisant l’un des algorithmes standardisés par le « National Institute of Standards and Technology », de SHA 1 à SHA 3.

STANDARD_HASH(expr [, 'method' ])

ou “method” peut être SHA1, SHA256, SHA384, SHA512 ou MD5.

SELECT STANDARD_HASH('nom', 'MD5') FROM CLIENT

Commande qui va retourner le hash MD5 :

C47D187067C6CF953245F128B5FDE62A

Oracle ne prévoit aucune restriction sur la longueur d’ « expr », qui est en général un nom de colonne, si ce n’est qu’il ne pourra pas s’agir d’un type LONG ou LOB, ni d’un type objet défini par l’utilisateur.

Chez Microsoft et SQL Server 2016, les développeurs pourront utiliser le namespace Microsoft.SqlServer.Management.Dmf, avec par exemple la méthode GetHashCode applicable à un objet.

SQL Server 2016 comporte par ailleurs une commande SQL pour générer ce même hash : HASHBYTES

CREATE TABLE dbo.Test1 (c1 nvarchar(50)); 
INSERT dbo.Test1 VALUES ('This is a test.'); 
INSERT dbo.Test1 VALUES ('This is test 2.'); 
SELECT HASHBYTES('SHA1', c1) FROM dbo.Test1;

Qui génère l’empreinte :

0x0E7AAB0B4FF0FD2DFB4F0233E2EE7A26CD08F173 
0xF643A82F948DEFB922B12E50B950CEE130A934D6
 
 
L’intérêt de cette technique est qu’elle permet de signer numériquement un objet de base, une colonne, un champ dans une colonne, une table, etc.
Si par exemple, vous prévoyez qu’un seul utilisateur sera chargé de mettre à jour une valeur de champ bien précise, on pourra chiffrer le hash calculé avec la clé privée de l’usager, ce qui reviendra à la signer. On sera ainsi certain que la mise à jour a été effectuée par le bon usager…
 

 

Dans le futur il faudra que les SGBD, les OS et les processeurs prennent en charge le contrôle de nos données sensibles, exposées à « tous les vents » et faiblement protégées par les usagers eux-mêmes, pour qui la sécurité est plus une contrainte qu’une nécessité.
Le masquage sélectif de données


Le troisième dispositif est celui du masquage des données, un mécanisme qui évite d’afficher les données en clair, si le requêteur n’est pas autorisé à les visualiser de cette manière. Il ne s’agit donc pas d’une technique de chiffrement, mais bien d’un simple masquage.
SQL Server 2016 comporte une telle fonction, qui fait appel à un code SQL, dans lequel on va définir les règles de masquage avec MASKED WITH :


MASKED WIDT (FUNCTION = ‘<em><function></em>(<em><arguments></em>)’)
 
“function” pouvant être default, email, random ou partial (les deux derniers ayant besoin des arguments).
 
On précise le masque au moment de la création de la base (CREATE) ou de sa mise à jour (ALTER TABLE), avec quelques restrictions : pas de masque sur des champs calculés ou de type « Always Encrypted Columns », l’une des dispositions récentes de SQL Server 2016.
 
L’exemple suivant de création de table est proposé par RedGate Software :
 

CREATE TABLE EmpInfo(

EmpID INT PRIMARY KEY,

FirstName NVARCHAR(50) NOT NULL,

LastName NVARCHAR(50) 

MASKED WITH (FUNCTION = 'default()') NOT NULL,

Birthdate DATE  

MASKED WITH (FUNCTION = 'default()') NOT NULL,

CurrentFlag BIT  

MASKED WITH (FUNCTION = 'default()') NOT NULL,

SalesLastYear MONEY  

MASKED WITH (FUNCTION = 'default()') NOT NULL,

EmailAddress NVARCHAR(50),

SickLeave INT,

SalesYTD MONEY,

NatID NVARCHAR(15),

PhoneNumber NVARCHAR(25));

De même pour une mise à jour :

ALTER TABLE EmpInfo

  ALTER COLUMN EmailAddress NVARCHAR(50)  

      MASKED WITH (FUNCTION = 'email()') NULL;

À l’affichage et en fonction des règles et de la nature des cibles, on pourra n’afficher que certains éléments d’une donnée et pas les autres (exemple de SQL Server dans Azure) :

  • « default » : on affiche des XXXXX à la place des données ou 01-01-1900 pour les types date, datetime, time, etc., ou des valeurs vides pour les types spéciaux
  • carte de crédit : on affiche les quatre derniers chiffres des champs de masquage, tels que
  • XXX-XXX-XXX-1234
  • email : on se « contente » de la première lettre et on remplace le nom de domaine par XXXX.com
  • on peut aussi masquer un texte personnalisé, pour lequel on ne visualisera que le premier et le dernier caractère

Une autre disposition est apparue avec SQL Server 2016, dite « row-line security », particulièrement intéressante, qui permet de protéger les lignes de la base à l’aide de deux prédicats : un premier qui filtre les lignes pour leur appliquer des opérations de lecture (SELECT, UPDATE, DELETE) et un second, BLOCK, qui bloque explicitement les opérations d’écriture (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE) qui violent la règle du prédicat.

Un excellent moyen, natif à la base, pour éviter des opérations malvenues sur des données sensibles.

Demain

Les besoins en matière de sécurisation des données sont immenses. Et ils vont se diversifier : Big Data, capteurs… avec des données de plus en plus fragiles, car exposées aux erreurs et malversations.

Auparavant c’est nous qui embarquions dans nos applications le code de protection qui nous semblait nécessaire, aujourd’hui ce sont les SGBD qui s’en chargent en partie, mais demain ce seront probablement des processeurs spécialisés qui prendront le relais, voire par des services embarqués dans le Cloud. Dont les actions sécuritaires seront sollicitées par des API ouvertes aux principaux langages : Go, C, Java, etc.

Ce changement est important, qui est à mettre en parallèle avec d’autres évolutions orientées sécurité, comme l’arrivée de machines entièrement chiffrées, comme le tout récent z14 d’IBM.

En matière de sécurité, on n’a probablement encore rien vu. Il est temps d’attacher nos ceintures…

Les critères sont évalués de 1 à 5
Marché : présence réelle sur le marché
Usage : intérêt potentiel, hors considérations commerciales
Standards : niveau de standardisation du sujet
Coût : coût de mise en œuvre ou d’usage (une valeur élevée témoigne d’un faible coût)
Futur : niveau de crédibilité prévisible
Maturité : niveau de maturité atteint actuellement
 
 

Plus de thématiques

 
Biométrie : des technologies étonnantes
La biométrie fait partie de notre univers et s’installe de plus en plus dans notre ...
Sécurité du TI : 2018 pire que 2017, ça on en est sûr…
Il est de bon ton chaque année, de dresser un état des lieux de la ...
Ingénierie sociale : le paradoxe du paillasson
L’ingénierie sociale concerne deux natures d’attaques. Il y a d’abord celles qui vise...
Le (grave) danger des « fileless malwares »
Depuis le début 2016, une nouvelle famille de malwares progresse de manière vertigineuse, les ma...
La sécurité des containeurs est-elle contestable ?
Il est de bon ton de reprocher à la technologie Docker de manquer de sécurité. ...
Sécurité : tout va changer, mais rien ne change
La maîtrise de la sécurité de nos systèmes d’information restera la grande in...
Le Wi-Fi est-il encore dangereux : oui.
Wi-Fi véhicule une réputation de mauvaise sécurité, au point que de nombreuses ent...
La calamité du Déni de Service et comment s’en protéger
Le DOS ou Déni de service (Denial of Service) existe sous 2 formes : DOS par ...
Le principe du moindre privilège sur PC
Dans un système d’information, il y a 2 « interlocuteurs » : la ressou...
Mots de passe, on n’en sortira jamais
La gestion des mots de passe est un sujet inépuisable et il y a encore ...
La protection sera cognitive…ou ne sera pas
Les années 2015-2020 seront perçues plus tard comme celles qui auront permis la transition entre...
Ce qu’il faut penser de l’analyse comportementale
Le temps des signatures de virus et des sempiternels chargements de bases de données chaque ...
Sécurité : la nouvelle classification des failles, CVSS 3.0 de FIRST
C’est en 2015 que le chantier de refonte de la classification CVSS 3.0 (Common Vulnerability ...
TOR : les transferts TCP anonymes sur Internet
TOR a un côté fascinant, car il est au point de convergence des technologies réseaux ...
Sécurité et virtualisation des serveurs : le pire comme le meilleur
Sur le principe, la virtualisation est à la fois un rempart supplémentaire contre toutes les ......
Sécurité : des attaques innombrables, impossible à prévenir
Dans le même temps, le comportement des usagers, qui appliquent le bon vieux principe selon lequel ...
Où en est ISO 27000 ?
SMSI, au cœur de la norme Tout l’arsenal ISO 27000 est élaboré pour amélio...
Mobiles et messagerie, les mauvais élèves du chiffrement des données sensibles
Rappel sur le chiffrement Le chiffrement est une opération mathématique qui permet de transfo...

8 grands modules qui couvrent le monde des TI de manière exhaustive. Chacun contient des dizaines de dossiers de fond qui décryptent, analysent et critiquent objectivement les tendances.

Les tarifs

Prix US$/EU/CAD
1 an d'abonnement
1 module = 100 US$ / 100 € / 130 CAD
Pack 8 modules = 700 US$ / 700 € / 910 CAD