Discussion :

[BioNerve]

Bonjour,

J'ai effectué des tests avec succès des tests sur les nouvelles fonctionnalités de chiffrement symétrique et asymétrique, proposées dans SQL Serveur 2005. Il me reste toutefois une ou deux ambiguités pour lesquelles je n'ai pas trouvé de réponse en lisant la documentation.

Je pensais proposer du chiffrement asymétrique pour un client me demandant une protection efficace contre les DBAs. Bien entendu, l'argument de la confiance revient régulièrement, mais bon, je tente tout de même de lui répondre avec du concret. Dans mes essais, j'ai utilisé le chiffrement par certificat et la génération de clés chiffrées par certificat.


Dans le cas d'un modèle n-tiers assez simple (serveur DB, serveur applicatif et clients lourds), il m'est possible d'enregistrer et lire des données chiffrées en asymétrique dans la base de données. Ce dont je ne saisis pas forcément l'utilité, c'est l'utilisation de certificats, accessibles par simple appel d'une requête SQL et permettant d'effectuer les opérations de chiffrement et de décryptage directement sur le serveur DB. Dans quelle mesure ce dispositif protège-t-il l'entreprise de ses DBAs?

J'ai pensé que l'ajout d'un tunnel chiffré par SSL entre le serveur DB et le serveur applicatif permettraient d'éviter que l'administrateur ne "sniffe" le trafic lorsque les premières requêtes ont lieu afin d'y capturer le mot de passe déverrouillant les certificats. Mais il me semble que l'admin peut toujours voir le trafic en passant par le traceur de requêtes.

En voyant des fonctionnalités de chiffrement asymétrique, je m'attendais plus particulièrement à voir un mécanisme où les secrets ne seraient jamais stockés dans le serveur mais uniquement publiés par le client (serveur applicatif) lorsqu'il établit ses connexions (un peu à la manière d'une connexion SSH avec authentification par clé).


Je crois que j'ai dû manquer une partie du raisonnement dans ma compréhension du chiffrement asymétrique des données sur SQL Serveur alors si une âme charitable se sent de m'éclairer, elle gagnera très certainement...toute ma reconnaissance :)

Sinon, si l'élargissement du débat est possible, avez-vous des ressources (lectures, idées) à conseiller pour établir une bonne séparation entre les données et les administrateurs DB? Le but étant que les admins n'aient pas la possibilité de lire les données stockées dans les bases et que ce soit un peu plus dur que de simplement extraire la clé enregistrée dans le serveur...

Merci d'avance,
Bio

[rudib]

Bonjour,

Il y a en effet un mélange dans le raisonnemment. Tu pars du principe que la clé asymétrique représente une architecture de type PKI, et donc qu'il y a une clé publique donnée à distance, ce qui n'est pas le cas. L'architecture de chiffrement de SQL Server est interne, tout est stocké dans la base de données. Les chiffrement est utilisé côté serveur, et le certificat est une façon comme une autre de chiffrer. Le certificat amène la possibilité de lier une clé avec un login, pour authentifier un utilisateur dans le cas d'une signature de procédure par exemple.
Il vaudrait mieux que tu sois plus précis dans ta question, notamment que tu expliques concrètement ce que tu entends par "protéger la base de des DBAs". En général, ce sont les DBAs qui protègent la base.

[BioNerve]

Bonjour Rudib,

En effet, j'étais resté sur cette idée d'avoir une paire de clés à disposition et de n'en laisser qu'une seule au serveur. Du coup, le serveur aurait stocké des données sous forme chiffrée et le décryptage des données n'aurait été possible qu'après que je lui aie communiqué la clé et non sans mon autorisation (depuis une application cliente quelconque).

En lisant ta réponse, je constate que cette notion existe mais reste intrinsèque au serveur, ce qui est tout aussi logique en un sens.

Pour préciser ma question: je souhaite garantir à mon client que les DBAs ne seront pas en mesure de "lire" les données stockées dans les tables des bases de données qu'ils administrent. SQL Serveur propose en ce sens le chiffrement par mot de passe, fourni lors de la première requête de session, et permettant de décrypter les données se trouvant dans les tables.

Ma question "élargie" serait donc: cette pratique est-elle réellement efficace contre les accès non autorisés par les DBAs? Peuvent-ils simplement tracer les requêtes et voir ces mots de passes apparaître en clair même si la connexion est chiffrée en SSL?

Ce qui m'étonne dans le mécanisme d'ouverture des clés de chiffrement dans SQL Serveur c'est qu'il n'y a aucune notion de challenge entre le client et le serveur : si le secret est capturé par un administrateur lors de l'envoi du secret, cet administrateur peut tout simplement 'copier' ce secret et le reproduire à volonté chaque fois qu'il souhaitera lire les données de la base.

Pour répondre à la question de confiance, il ne s'agit pas d'employer des DBAs en qui l'établissement n'aurait pas confiance mais de proposer une très haute garantie aux clients de l'établissement en leur affirmant que même les admins ne peuvent lire (trop facilement) leurs données.

En tous cas, merci pour cette première réponse, je sais à présent ce que je peux tirer de cette fonctionnalité et quelles sont ses limites. Par contre, tout ajout sur cette question de protection des données serait le bienvenu!

[PS: j'en profite pour recentrer le sujet du message dans le forum... ]

[rudib]

Ma question "élargie" serait donc: cette pratique est-elle réellement efficace contre les accès non autorisés par les DBAs? Peuvent-ils simplement tracer les requêtes et voir ces mots de passes apparaître en clair même si la connexion est chiffrée en SSL?

Tu peux chiffer par tout type de clé et ajouter un mot de passe pour ouvrir la clé (par exemple chiffer par clé symétrique, et chiffrer cette clé par certificat ou clé asymétrique, qu'il faut ouvrir au préalable en passant un mot de passe.

Sur la lisibilité du mot de passe, cela devrait aller : si la connexion est chiffrée en SSL, le DBA ne devrait pas pouvoir voir le mdp. Les instructions sensibles n'apparaissent pas en clair dans les traces SQL (qu'on voit dans le profiler).

[BioNerve]

Rudib,

Ok, en gros:

- chiffrement SSL point à point pour empêcher la capture ou le rejeu des données
- chiffrement des bases par EncryptByKey/DecryptByKey (je vais encore regarder
ce qu'il y a d'intéressant du côté de Transparent Data Encryption fourni dans SQL2008) pour empêcher la capture des données en repos (je ne connais pas le terme exact, data at rest)
- audit des accès aux traceur, pour surveiller les tentatives potentielles d'accès aux secrets

Il ne me reste plus qu'à en faire un PoC histoire de sortir de la théorie pour voir
si c'est jouable. Cela devrait plus ou moins constituer un modèle cohérent
pour répondre à mon besoin.

Un grand merci pour ces précisions!