Cette problématique était en effet la raison pour ma question...
Bonne chance pour le futur. En ce qui concerne les gens d'en face, ils ne resteront pas trop confortables. Leur politique crée continuellement des gens mécontents.
"Fabrice Burghgraeve" a écrit dans le message de news:c0imre$dk4$
salut.
"Roumegou Eric" a écrit dans le message de news: > mat a écrit : (...) > Meme si tu peux (pour Oracle), gérer des autorisations par tables et > par colonnes; cela devient très vite compliqué et nécessite un DBA. > Cela peut difficilement être pris en charge par l'appli. > > Perso, moi je trouve cela dangereux que les protections soient à ce > niveau. Il vaut peut être mieux gérer cela au niveau de l'OS. >
Perso, je crois que tu te plantes. Si la protection est au niveau de l'OS, tu piques les fichiers de la base, tu les fous sur une autre machine et hop. Faut meme pas etre pirate pour trouver ca ...
Par contre, si un utilisateur veut proteger ses données, il faut lui
laisser
la possibilité de changer son mot de passe aussi regulierement qu'il le veut. Voire meme le forcer a le faire. Car la plus grosse faille de securite des mots de passe, c'est qu'il faut que le mot de passe ne soit pas diffusé. Un mot de passe que tout le monde connait n'est plus un mot de passe.
Et les utilisateurs, on sait comment ils sont : "eh ! Robert ! J'ai pas le mot de passe pour aller dans ce programme.
C'est
quoi le tien ?" "Ah ben c'est Robert" "Ok merci"
et bye bye la tracabilite ...
Fabrice
Cette problématique était en effet la raison pour ma question...
Bonne chance pour le futur. En ce qui concerne les gens d'en face, ils ne
resteront pas trop confortables. Leur politique crée continuellement des
gens mécontents.
"Fabrice Burghgraeve" <regardez.ma.signature@cette.adresse.est.bidon.com> a
écrit dans le message de news:c0imre$dk4$1@news.nordnet.fr...
salut.
"Roumegou Eric" <Utilisezlelien@fin.msg> a écrit dans le message de
news:mesnews.6b0d7d42.d0f4d6a9.132.4556@fin.msg...
> mat a écrit :
(...)
> Meme si tu peux (pour Oracle), gérer des autorisations par tables et
> par colonnes; cela devient très vite compliqué et nécessite un DBA.
> Cela peut difficilement être pris en charge par l'appli.
>
> Perso, moi je trouve cela dangereux que les protections soient à ce
> niveau. Il vaut peut être mieux gérer cela au niveau de l'OS.
>
Perso, je crois que tu te plantes.
Si la protection est au niveau de l'OS, tu piques les fichiers de la base,
tu les fous sur une autre machine et hop.
Faut meme pas etre pirate pour trouver ca ...
Par contre, si un utilisateur veut proteger ses données, il faut lui
laisser
la possibilité de changer son mot de passe aussi regulierement qu'il le
veut.
Voire meme le forcer a le faire.
Car la plus grosse faille de securite des mots de passe, c'est qu'il faut
que le mot de passe ne soit pas diffusé.
Un mot de passe que tout le monde connait n'est plus un mot de passe.
Et les utilisateurs, on sait comment ils sont :
"eh ! Robert ! J'ai pas le mot de passe pour aller dans ce programme.
Cette problématique était en effet la raison pour ma question...
Bonne chance pour le futur. En ce qui concerne les gens d'en face, ils ne resteront pas trop confortables. Leur politique crée continuellement des gens mécontents.
"Fabrice Burghgraeve" a écrit dans le message de news:c0imre$dk4$
salut.
"Roumegou Eric" a écrit dans le message de news: > mat a écrit : (...) > Meme si tu peux (pour Oracle), gérer des autorisations par tables et > par colonnes; cela devient très vite compliqué et nécessite un DBA. > Cela peut difficilement être pris en charge par l'appli. > > Perso, moi je trouve cela dangereux que les protections soient à ce > niveau. Il vaut peut être mieux gérer cela au niveau de l'OS. >
Perso, je crois que tu te plantes. Si la protection est au niveau de l'OS, tu piques les fichiers de la base, tu les fous sur une autre machine et hop. Faut meme pas etre pirate pour trouver ca ...
Par contre, si un utilisateur veut proteger ses données, il faut lui
laisser
la possibilité de changer son mot de passe aussi regulierement qu'il le veut. Voire meme le forcer a le faire. Car la plus grosse faille de securite des mots de passe, c'est qu'il faut que le mot de passe ne soit pas diffusé. Un mot de passe que tout le monde connait n'est plus un mot de passe.
Et les utilisateurs, on sait comment ils sont : "eh ! Robert ! J'ai pas le mot de passe pour aller dans ce programme.
C'est
quoi le tien ?" "Ah ben c'est Robert" "Ok merci"
et bye bye la tracabilite ...
Fabrice
spetb
> Je ne partage pas cette opinion. Je protège mon travail en protégeant mon code. Le mot de passe sert tout d'abord à protéger les données de l'utilisateur (mon client). Ils sont de sa propriété et à mon avis il a tous les droits de les protéger avec son propre mot de passe. Afin d'avoir quand-même accès aux données en cas d'oublie d'un client, il existe également la notion de master password. On peut même en fabriquer un pour une application: accès aux données soit seulement avec "MotPasseMaitre"
ou
bien "MotPasseMaitre" + "MotPasseClient". Mais cela nécessite qu'on puisse protéger les fichiers par programmation et je n'ai toujours pas trouvé une solution acceptable pour HF.
Bonjour,
Je pense que les avis vont être partagés, pour moi la protection des fichiers me sert avant tout à protéger leur structure, afin que personne ne puisse la lire, et cette protection de la structure, j'en ai un besoin absolu pour certains fichiers, ainsi que les données contre les "indiscrets" externes. La protection de l'accès (lecture et écriture) des donnés pouvant (et c'est ce que je pratique) se faire par programmation. De plus le fait de ne pouvoir accéder aux données que par l'application qui les utilise et en protégeant cet accès, n'empêche en aucun cas le client d'y avoir accès, mais seulement par l'application propriétaire et non pas par n'importe quel moyen externe pour lequel il suffit de trouver le mot de passe pour lire (comme j'arrive à le faire par exemple pour les fichiers Acces protégés par mot de passe (moins de 5 secondes pour trouver ce mot de passe), c'est d'ailleurs une des raisons pour laquelle je n'utilise plus Access pour mes fichiers sensibles).
> Je ne partage pas cette opinion. Je protège mon travail en protégeant mon
code. Le mot de passe sert tout d'abord à protéger les données de
l'utilisateur (mon client). Ils sont de sa propriété et à mon avis il a
tous les droits de les protéger avec son propre mot de passe. Afin d'avoir
quand-même accès aux données en cas d'oublie d'un client, il existe
également la notion de master password. On peut même en fabriquer un pour
une application: accès aux données soit seulement avec "MotPasseMaitre"
ou
bien "MotPasseMaitre" + "MotPasseClient". Mais cela nécessite qu'on puisse
protéger les fichiers par programmation et je n'ai toujours pas trouvé une
solution acceptable pour HF.
Bonjour,
Je pense que les avis vont être partagés, pour moi la protection des
fichiers me sert avant tout à protéger leur structure, afin que personne ne
puisse la lire, et cette protection de la structure, j'en ai un besoin
absolu pour certains fichiers, ainsi que les données contre les "indiscrets"
externes.
La protection de l'accès (lecture et écriture) des donnés pouvant (et c'est
ce que je pratique) se faire par programmation.
De plus le fait de ne pouvoir accéder aux données que par l'application qui
les utilise et en protégeant cet accès, n'empêche en aucun cas le client d'y
avoir accès, mais seulement par l'application propriétaire et non pas par
n'importe quel moyen externe pour lequel il suffit de trouver le mot de
passe pour lire (comme j'arrive à le faire par exemple pour les fichiers
Acces protégés par mot de passe (moins de 5 secondes pour trouver ce mot de
passe), c'est d'ailleurs une des raisons pour laquelle je n'utilise plus
Access pour mes fichiers sensibles).
Sincères Salutations
--
Jean-Claude FLAJOULOT
Sécurité Pointage & Biométrie
SPetB_no_spam@wandoo.fr
(Otez _no_spam pour me contacter en PV)
> Je ne partage pas cette opinion. Je protège mon travail en protégeant mon code. Le mot de passe sert tout d'abord à protéger les données de l'utilisateur (mon client). Ils sont de sa propriété et à mon avis il a tous les droits de les protéger avec son propre mot de passe. Afin d'avoir quand-même accès aux données en cas d'oublie d'un client, il existe également la notion de master password. On peut même en fabriquer un pour une application: accès aux données soit seulement avec "MotPasseMaitre"
ou
bien "MotPasseMaitre" + "MotPasseClient". Mais cela nécessite qu'on puisse protéger les fichiers par programmation et je n'ai toujours pas trouvé une solution acceptable pour HF.
Bonjour,
Je pense que les avis vont être partagés, pour moi la protection des fichiers me sert avant tout à protéger leur structure, afin que personne ne puisse la lire, et cette protection de la structure, j'en ai un besoin absolu pour certains fichiers, ainsi que les données contre les "indiscrets" externes. La protection de l'accès (lecture et écriture) des donnés pouvant (et c'est ce que je pratique) se faire par programmation. De plus le fait de ne pouvoir accéder aux données que par l'application qui les utilise et en protégeant cet accès, n'empêche en aucun cas le client d'y avoir accès, mais seulement par l'application propriétaire et non pas par n'importe quel moyen externe pour lequel il suffit de trouver le mot de passe pour lire (comme j'arrive à le faire par exemple pour les fichiers Acces protégés par mot de passe (moins de 5 secondes pour trouver ce mot de passe), c'est d'ailleurs une des raisons pour laquelle je n'utilise plus Access pour mes fichiers sensibles).
