[mysql] chiffrage des donnees
Le
paf le chien
bonsoir,
je commence à me demander s'il est possible d'utiliser MySQL dans un
contexte où les données ne doivent être lisibles que par un groupe
d'utilisateurs, mais PAS par l'administrateur du serveur.
Parce que maintenant que j'y pense, j'ai l'impression que ça ne
passerait que par le chiffrage à l'insertion des données, mais alors,
quid des clauses WHERE ou HAVING ?
y a t'il un moyen de rendre les données inaccessibles à l'administrateur
du serveur? je veux dire, qu'il puisse toujours supprimer la base bien
sûr mais rien d'autre?
merci
--
paf le chien
virez le primate pour répondre
je commence à me demander s'il est possible d'utiliser MySQL dans un
contexte où les données ne doivent être lisibles que par un groupe
d'utilisateurs, mais PAS par l'administrateur du serveur.
Parce que maintenant que j'y pense, j'ai l'impression que ça ne
passerait que par le chiffrage à l'insertion des données, mais alors,
quid des clauses WHERE ou HAVING ?
y a t'il un moyen de rendre les données inaccessibles à l'administrateur
du serveur? je veux dire, qu'il puisse toujours supprimer la base bien
sûr mais rien d'autre?
merci
--
paf le chien
virez le primate pour répondre
Poser une question
Si vous ne faites pas confiance à l'administrateur qu'est-ce qui peut vous
garantir qu'il n'a pas remplacé les binaires de MySQL par une version qui
fait tout comme normalement mais qui en plus copie les données (en clair)
dans un coin, pour lui, sans bien sûr que cela se voit ?
Sans compter l'usage d'un proxy.
Sauf à peut-être alimenter la base initialement off-line (genre rsync des
fichiers du disque depuis un serveur que vous maîtrisez), et faire les
déchiffrements uniquement du côté applicatif (mais bonjour alors les
performances et les problèmes pour faire des recherche et autre).
Bref, ajouter du chiffrement ne solutionne pas miraculeusement tous les
problèmes. Il faut d'abord que vous identifiez précisément « l'attaquant »,
les moyens à sa disposition et les cas de figure d'attaques contre
lesquelles vous souhaitez essayer de vous prémunir.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
Et à quoi cela servirait-il ? Dans une analyse de risque, il faut
plutôt considérer qui croit que vos données ont de la valeur et s'en
protéger. Si on ne peut pas faire confiance à un hébergeur, la seule
solution est d'héberger à la maison !!!
Denis
simple utilisé un SGBD qui a prévue la sécurité tel les SGBDMV (voir
page 148 section 3-13 de la doc de openqm l'explication de ENCRYPT() et
DECRIPT() qui fournissent cela avec une clef de 128bits)
les fichiers SQL ne sont pas sécurisé et sont lisible en clair avec un
simple éditeur de texte tel vim ou édit par n'importe qui
bé oui pour le moment c'est la solution que j'ai retenue, AES_ENCRYPT()
et AES_DECRYPT() à l'insertion, également chiffré avec un clef de 128
bits mais le problème est plus complexe que ça
non il y a moyen comme je le disais mais comme l'observe un autre
posteur, partant de là, qu'est-ce qui interdit, quand on ne fait pas
confiance à l'admin, d'envisager qu'il ait pu remplacer l'exécutable...
--
paf le chien
virez le primate pour répondre
ah oui c'est très juste. C'est un argument qui va beaucoup compter.
voilà c'est à ça que je pensais
en fait l'attaque est ultra improbable mais le client est obligé de
fournir à ses propres clients des garanties de confidentialité et c'est
à cette exigence que je dois répondre.
Par souci d'économie pour le client (qui achète, je dois dire,
l'application pour un prix dérisoire), on utilise un hébergement en
ligne tout à fait commun (on va dire semi-pro) mais personnellement je
trouve ça incompatible avec un désir d'absolue protection mais bon.
D'autant qu'un petit serveur au bureau c'est pas la ruine.
merci pour votre précieuse réponse
--
paf le chien
virez le primate pour répondre