Discussion :

[jesus144]

Bonjour,
Nous étudions la possibilité
- de chiffrer des données dans une base de données Oracle avec la solution Oracle Transparent Data Encryption (TDE)
- et de les masquer au niveau de la couche SQL via la solution Vault.

Pour le moment mon travail est essentiellement documentaire sachant que je ne suis pas DBA. J'ai passé pas mal de temps dans les documentations Oracle mais j'aimerais avoir un retour d'expérience sur le sujet et sur la sécurité de la solution.

Au niveau de l'OS:
Pour ce que j'en sais, les clés de chiffrement TDE sont stockées dans la wallet Oracle. De ce fait, plusieurs questions se posent:
- La Wallet peut être protégée par une master key ou être configurée en ouverture automatique. Savez vous comment cela fonctionne dans la pratique? Dans le premier cas, j'imagine qu'il faut saisir la master key pour démarrer l'instance Oracle qui va accéder à la clé de chiffrement. Ceci implique que les DBA / Admins sys la connaissent et donc, si ils ont accès à la base de données chiffrée et à la clé de chiffrement: La confidentialité des données n'est pas assurée. Dans le second cas, c'est encore pire, puisqu'il suffit de copier les fichiers contenant la base de données et la wallet, et on remonte la base de données où on veut.
- Peut on exporter la clé de chiffrement à l'extérieur de la wallet?
- Comment peut on ôter la protection offerte par le chiffrement si on ne souhaite plus que les données soient chiffrées?

Au niveau de la couche SQL
- De toute façon, le DBA a accès au données via la couche SQL. Il est donc nécessaire de masquer les données au niveau de la couche SQL (solution Vault). Mais la protection peut de toute façon être désactivée par un DBA, ce qui est même explicitement demandé par Oracle pour l'application de certain patch.

Que pensez vous de la sécurité de se type de solution? à mes yeux, pour que cela soit fiable, on ne peut pas se passer de chiffrement matériel via un boitier HSM ou assimilé. J'avoue que je ne suis pas du tout convaincu par ces solutions. Qu'en pensez vous?

Dans le même sens, avez vous un feedback sur les conséquences en terme d'exploitation (backup, maintenance, clustering...)?

Merci beaucoup de votre aide!!

[Pomalaix]

Ce que j'explique à mes clients dans ce genre de questions, c'est qu'il faut commencer par définir le besoin fonctionnel : contre quelles menaces voulez-vous vous protéger ?
Les solutions viennent ensuite, de type DBMS_CRYPTO, TDE, Database Vault, Audit Vault, Data masking, cryptage réseau, etc.

Comme vous le mentionnez, il est souvent nécessaire de combiner plusieurs de ces solutions, pour obtenir la couverture souhaitée.

Il est effectivement conseillé d'utiliser un système HSM pour stocker les clés de cryptage, en lieu et place du wallet.
Pour cesser le cryptage TDE (selon le mode), ce peut être un simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter table t1 modify (colonne DECRYPT);

Pour dire un mot sur Database Vault, c'est un système dans lequel le DBA abandonne certaines de ses prérogatives habituelles, telles que la gestion des utilisateurs. Le "pouvoir" est alors partagé avec un administrateur de sécurité, RSSI ou quelque chose dans cet esprit.
Certaines fonctionnalités, tout en restant dans le giron du DBA, vont nécessiter un paramétrage spécifique (par exemple Datapump, gestion des index, création d'un tablespace).
Concernant la désactivation, elle nécessite l'arrêt préalable de la base, ce qui ne passe quand même pas inaperçu.

[jesus144]

Bonjour,
Merci beaucoup pour ton retour. Effectivement, la fonction de DBA de sécu est LE pivot pour cette problématique.
Cordialement,