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?
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 <http://www.dotandco.net/> <http://www.dotandco.com/>
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
<http://www.dotandco.net/> <http://www.dotandco.com/>
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 <http://www.dotandco.net/> <http://www.dotandco.com/>
Denis Beauregard
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
Le 31 Jan 2008 23:45:02 GMT, paf le chien <pafbabouinlechien@neuf.fr>
é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 !!!
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
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
Denis Beauregard a écrit :
Le 31 Jan 2008 23:45:02 GMT, paf le chien <pafbabouinlechien@neuf.fr>
é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
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
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
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...
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
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
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.
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
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 a grommelé:
Le 31 Jan 2008 23:45:02 GMT, paf le chien <pafbabouinlechien@neuf.fr>
é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 !!!
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 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
Le 01 Feb 2008 14:28:24 GMT, paf le chien <pafbabouinlechien@neuf.fr>
é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 ;-)
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
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é
paf le chien a écrit :
Denis Beauregard a grommelé:
Le 31 Jan 2008 23:45:02 GMT, paf le chien <pafbabouinlechien@neuf.fr>
é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é
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
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
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
