[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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 6
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrick Mevzek
Le #21885221
Le Thu, 31 Jan 2008 23:45:02 +0000, paf le chien a écrit:
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?



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
Denis Beauregard
Le #21885211
Le 31 Jan 2008 23:45:02 GMT, paf le chien écrivait dans fr.comp.applications.sgbd:

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?



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
nobody
Le #21885201
Denis Beauregard a écrit :
Le 31 Jan 2008 23:45:02 GMT, paf le chien écrivait dans fr.comp.applications.sgbd:

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?



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
paf le chien
Le #21885191
nobody a grommelé:
Denis Beauregard a écrit :
[...]




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)



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

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



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
paf le chien
Le #21885181
Patrick Mevzek a grommelé:
Le Thu, 31 Jan 2008 23:45:02 +0000, paf le chien a écrit:
[...]



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 ?



ah oui c'est très juste. C'est un argument qui va beaucoup compter.

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).



voilà c'est à ça que je pensais

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.



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
paf le chien
Le #21885171
Denis Beauregard a grommelé:
Le 31 Jan 2008 23:45:02 GMT, paf le chien écrivait dans fr.comp.applications.sgbd:

[...]



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.



en fait le problème c'est qu'il s'agit de données médicales
(psychiatriques en plus) et même si le risque est passablement
inexistant, il y a une sorte d'obligation de moyens, par principe de
précaution.

En même temps je ne peux pas blâmer le client, ils ne savent pas ce qui
est possible simplement ou au prix d'investissements, ils demandent la
meilleure confidentialité, après il restera à leur expliquer ce qui peut
être garanti à peu de frais et ce qui exige un coffre fort et des gardes
armés.

Mais c'est vrai qu'à la base on se contente de se prémunir contre un
déchiffrement facile des données dans la base en chiffrant les
informations critiques lors de l'insertion, mais si on voulait être
rigoureux, il faudrait envisager d'autres types de risques.
Si ça se trouve c'est très facile de fracturer le bureau et disposer des
impressions des dossiers dans un tiroir qui s'ouvre avec un canife.
Reste à savoir qui ça intéresse, mais par définition, l'établissement
peut être un jour confronté à un patient qui fasse remarquer que la NSA
pourrait venir voler son dossier ;)

Si on ne peut pas faire confiance à un hébergeur, la seule
solution est d'héberger à la maison !!!



j'abonde (j'adore dire "j'abonde")

--
paf le chien
virez le primate pour répondre
Denis Beauregard
Le #21885161
Le 01 Feb 2008 14:28:24 GMT, paf le chien écrivait dans fr.comp.applications.sgbd:

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



Si je n'ai pas les moyens d'acheter une serrure, je n'ai pas les
moyens d'avoir une maison ;-)


Denis
Thierry B.
Le #21885151
--{ nobody a plopé ceci: }--

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



Le premier qui arrive à lire quelque chose de cohérent dans
les fichiers de psql avec Vim va gagner un Turing Awards.


--
"Quand le seul outil connu est un marteau, tout problème
est considéré comme un clou"
nobody
Le #21885141
paf le chien a écrit :
Denis Beauregard a grommelé:
Le 31 Jan 2008 23:45:02 GMT, paf le chien écrivait dans fr.comp.applications.sgbd:

[...]


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.



en fait le problème c'est qu'il s'agit de données médicales
(psychiatriques en plus) et même si le risque est passablement
inexistant, il y a une sorte d'obligation de moyens, par principe de
précaution.

En même temps je ne peux pas blâmer le client, ils ne savent pas ce qui
est possible simplement ou au prix d'investissements, ils demandent la
meilleure confidentialité, après il restera à leur expliquer ce qui peut
être garanti à peu de frais et ce qui exige un coffre fort et des gardes
armés.

Mais c'est vrai qu'à la base on se contente de se prémunir contre un
déchiffrement facile des données dans la base en chiffrant les
informations critiques lors de l'insertion, mais si on voulait être
rigoureux, il faudrait envisager d'autres types de risques.
Si ça se trouve c'est très facile de fracturer le bureau et disposer des
impressions des dossiers dans un tiroir qui s'ouvre avec un canife.
Reste à savoir qui ça intéresse, mais par définition, l'établissement
peut être un jour confronté à un patient qui fasse remarquer que la NSA
pourrait venir voler son dossier ;)

Si on ne peut pas faire confiance à un hébergeur, la seule
solution est d'héberger à la maison !!!



j'abonde (j'adore dire "j'abonde")





si on ne fait pas confiance à l'hebergeur on met soit même le SGBD chez
l'hebergeur et régulièrement contrôle que celui ci n'a pas été altérer

ou en monte un serveur soit même cela coûte presque rien : un PC + Linux
et c'est réglé
nobody
Le #21885131
Thierry B. a écrit :
--{ nobody a plopé ceci: }--

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



Le premier qui arrive à lire quelque chose de cohérent dans
les fichiers de psql avec Vim va gagner un Turing Awards.





personne ne risqe de lire un fichier psql puisque psql est une interface
et a ce titre n'a aucun fichier de données

http://docs.postgresqlfr.org/8.2/app-psql.html
Publicité
Poster une réponse
Anonyme