Sécurisation Base de Données au niveau utilisateur
3 réponses
Stéphane
Bonjour,
Tout d'abord je tiens à dire que mes connaissance sont TRES limité dans le
domaine des sgbd.
Ensuite vous dire que ma question est purement à titre informatif (et non un
problème précis auquel je suis confronté).
Cela concerne la sécurité..
Je vois comment sécuriser une connexion.
Je vois comment sécuriser une authentification.
Mais qu'existe-t-il (s'il existe quelque chose ;-) ) au niveau utilisateur
DANS la base de donnée ?
Exemple:
2 users TITI et GROMINET
Chacun ont accès à LEUR propre données en LECTURE.
Est-il possible (par des procédés malveillant ;-) ) que TITI puisse ECRIRE ?
ou que GROMINET puisse LIRE les données de TITI alors que la base lui
interdit ?
Qu'existe-t-il donc pour sécuriser au possible en interne (au niveau
utilisateur donc) des données qui pourraient être sensible?
Doit-on uniquement faire une sécurité max au niveau TCP (tunnel SSH, IPSec,
..) ainsi qu'au niveau authentification (SRP, Kerberos, SecureID, ..) et
croiser les doigts en espérant que la base de données (MySQL, PostgreSQL,
...) soit codée de façon secure?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD - SQLpro
Stéphane a écrit:
Bonjour,
Tout d'abord je tiens à dire que mes connaissance sont TRES limité dans le domaine des sgbd.
Ensuite vous dire que ma question est purement à titre informatif (et non un problème précis auquel je suis confronté).
Cela concerne la sécurité.. Je vois comment sécuriser une connexion. Je vois comment sécuriser une authentification. Mais qu'existe-t-il (s'il existe quelque chose ;-) ) au niveau utilisateur DANS la base de donnée ?
Utilisateurs SQL et privilèges
Exemple: 2 users TITI et GROMINET Chacun ont accès à LEUR propre données en LECTURE.
Les concepts de lecture et écriture n'ont pas de sens dans les SGBDR On ne parle d'ailleurs pas de droits, mais de privilège d'exécution.
Privilège d'exécuter telle ou telle commande. par exemple privilège accordé à l'utilisateur SQL TOTO d'exécuter une commande INSERT mais pas EXTRACT, DELETE ou UPDATE.
A lire : http://sqlpro.developpez.com/cours/sqlaz/dcl/
Est-il possible (par des procédés malveillant ;-) ) que TITI puisse ECRIRE ? ou que GROMINET puisse LIRE les données de TITI alors que la base lui interdit ? Qu'existe-t-il donc pour sécuriser au possible en interne (au niveau utilisateur donc) des données qui pourraient être sensible?
Doit-on uniquement faire une sécurité max au niveau TCP (tunnel SSH, IPSec, ..) ainsi qu'au niveau authentification (SRP, Kerberos, SecureID, ..) et croiser les doigts en espérant que la base de données (MySQL, PostgreSQL, ...) soit codée de façon secure?
Les SGBDR intègre leur propre sécurité. Ne jamais utiliser la sécurité au niveau OS pour gérer la sécurité des utilisateurs de SGBDR, c'est le moyen le plus sûr d'aller à des problèmes complexes et indémerdables.
Une base de données n'a rien à voir avec la notion d'utilisateur physique ni de fichier. Ce sont les applications qui utilsient le SGBDR et non les utilisateurs qui accèdent directement aux données !!!
Merci pour vos infos et réponses :-)
Stéphane
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Stéphane a écrit:
Bonjour,
Tout d'abord je tiens à dire que mes connaissance sont TRES limité dans le
domaine des sgbd.
Ensuite vous dire que ma question est purement à titre informatif (et non un
problème précis auquel je suis confronté).
Cela concerne la sécurité..
Je vois comment sécuriser une connexion.
Je vois comment sécuriser une authentification.
Mais qu'existe-t-il (s'il existe quelque chose ;-) ) au niveau utilisateur
DANS la base de donnée ?
Utilisateurs SQL et privilèges
Exemple:
2 users TITI et GROMINET
Chacun ont accès à LEUR propre données en LECTURE.
Les concepts de lecture et écriture n'ont pas de sens dans les SGBDR
On ne parle d'ailleurs pas de droits, mais de privilège d'exécution.
Privilège d'exécuter telle ou telle commande.
par exemple privilège accordé à l'utilisateur SQL TOTO d'exécuter une commande
INSERT mais pas EXTRACT, DELETE ou UPDATE.
A lire :
http://sqlpro.developpez.com/cours/sqlaz/dcl/
Est-il possible (par des procédés malveillant ;-) ) que TITI puisse ECRIRE ?
ou que GROMINET puisse LIRE les données de TITI alors que la base lui
interdit ?
Qu'existe-t-il donc pour sécuriser au possible en interne (au niveau
utilisateur donc) des données qui pourraient être sensible?
Doit-on uniquement faire une sécurité max au niveau TCP (tunnel SSH, IPSec,
..) ainsi qu'au niveau authentification (SRP, Kerberos, SecureID, ..) et
croiser les doigts en espérant que la base de données (MySQL, PostgreSQL,
...) soit codée de façon secure?
Les SGBDR intègre leur propre sécurité.
Ne jamais utiliser la sécurité au niveau OS pour gérer la sécurité des
utilisateurs de SGBDR, c'est le moyen le plus sûr d'aller à des problèmes
complexes et indémerdables.
Une base de données n'a rien à voir avec la notion d'utilisateur physique ni de
fichier.
Ce sont les applications qui utilsient le SGBDR et non les utilisateurs qui
accèdent directement aux données !!!
Merci pour vos infos et réponses :-)
Stéphane
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Tout d'abord je tiens à dire que mes connaissance sont TRES limité dans le domaine des sgbd.
Ensuite vous dire que ma question est purement à titre informatif (et non un problème précis auquel je suis confronté).
Cela concerne la sécurité.. Je vois comment sécuriser une connexion. Je vois comment sécuriser une authentification. Mais qu'existe-t-il (s'il existe quelque chose ;-) ) au niveau utilisateur DANS la base de donnée ?
Utilisateurs SQL et privilèges
Exemple: 2 users TITI et GROMINET Chacun ont accès à LEUR propre données en LECTURE.
Les concepts de lecture et écriture n'ont pas de sens dans les SGBDR On ne parle d'ailleurs pas de droits, mais de privilège d'exécution.
Privilège d'exécuter telle ou telle commande. par exemple privilège accordé à l'utilisateur SQL TOTO d'exécuter une commande INSERT mais pas EXTRACT, DELETE ou UPDATE.
A lire : http://sqlpro.developpez.com/cours/sqlaz/dcl/
Est-il possible (par des procédés malveillant ;-) ) que TITI puisse ECRIRE ? ou que GROMINET puisse LIRE les données de TITI alors que la base lui interdit ? Qu'existe-t-il donc pour sécuriser au possible en interne (au niveau utilisateur donc) des données qui pourraient être sensible?
Doit-on uniquement faire une sécurité max au niveau TCP (tunnel SSH, IPSec, ..) ainsi qu'au niveau authentification (SRP, Kerberos, SecureID, ..) et croiser les doigts en espérant que la base de données (MySQL, PostgreSQL, ...) soit codée de façon secure?
Les SGBDR intègre leur propre sécurité. Ne jamais utiliser la sécurité au niveau OS pour gérer la sécurité des utilisateurs de SGBDR, c'est le moyen le plus sûr d'aller à des problèmes complexes et indémerdables.
Une base de données n'a rien à voir avec la notion d'utilisateur physique ni de fichier. Ce sont les applications qui utilsient le SGBDR et non les utilisateurs qui accèdent directement aux données !!!
Merci pour vos infos et réponses :-)
Stéphane
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Côme de Christen
Bonsoir
Pour ma part c'est la notion de "vue" qui permet de résoudre ce type d'accès sélectif. Une vue permet à l'utilisateur de n'acceder qu'à ses données. Même sans la fonctionnalité (exemple MySql) une vue est très simple à implémenter en SQL.
Le programme doit en outre pour les requêtes DELETE ou UPDATE ajouter automatiquement la vérification que les données transmises concernent l'utilisateur en question (dans la clause WHERE) et pour l'INSERT on affecte automatiquement le nouvel enregistrement à l'utilisateur. Sur le Web on peut utiliser l'identifiant de de session pour cela.
J'espère que ceci vous aidera
Côme
Bonsoir
Pour ma part c'est la notion de "vue" qui permet de résoudre ce type d'accès sélectif. Une
vue permet à l'utilisateur de n'acceder qu'à ses données. Même sans la fonctionnalité
(exemple MySql) une vue est très simple à implémenter en SQL.
Le programme doit en outre pour les requêtes DELETE ou UPDATE ajouter automatiquement la
vérification que les données transmises concernent l'utilisateur en question (dans la
clause WHERE) et pour l'INSERT on affecte automatiquement le nouvel enregistrement à
l'utilisateur. Sur le Web on peut utiliser l'identifiant de de session pour cela.
Pour ma part c'est la notion de "vue" qui permet de résoudre ce type d'accès sélectif. Une vue permet à l'utilisateur de n'acceder qu'à ses données. Même sans la fonctionnalité (exemple MySql) une vue est très simple à implémenter en SQL.
Le programme doit en outre pour les requêtes DELETE ou UPDATE ajouter automatiquement la vérification que les données transmises concernent l'utilisateur en question (dans la clause WHERE) et pour l'INSERT on affecte automatiquement le nouvel enregistrement à l'utilisateur. Sur le Web on peut utiliser l'identifiant de de session pour cela.
J'espère que ceci vous aidera
Côme
Stéphane
Merci.
Désolé de faire si court, mais vous avez pris du temps pour me répondre, je me dois d'en prendre pour vous remercier. :-)
Stéphane
"Côme de Christen" a écrit dans le message de news:418befa8$0$19819$
Bonsoir
Pour ma part c'est la notion de "vue" qui permet de résoudre ce type
d'accès sélectif. Une
vue permet à l'utilisateur de n'acceder qu'à ses données. Même sans la
fonctionnalité
(exemple MySql) une vue est très simple à implémenter en SQL.
Le programme doit en outre pour les requêtes DELETE ou UPDATE ajouter
automatiquement la
vérification que les données transmises concernent l'utilisateur en
question (dans la
clause WHERE) et pour l'INSERT on affecte automatiquement le nouvel
enregistrement à
l'utilisateur. Sur le Web on peut utiliser l'identifiant de de session
pour cela.
J'espère que ceci vous aidera
Côme
Merci.
Désolé de faire si court, mais vous avez pris du temps pour me répondre, je
me dois d'en prendre pour vous remercier. :-)
Stéphane
"Côme de Christen" <come.dechristen@wanadoo.fr> a écrit dans le message de
news:418befa8$0$19819$626a14ce@news.free.fr...
Bonsoir
Pour ma part c'est la notion de "vue" qui permet de résoudre ce type
d'accès sélectif. Une
vue permet à l'utilisateur de n'acceder qu'à ses données. Même sans la
fonctionnalité
(exemple MySql) une vue est très simple à implémenter en SQL.
Le programme doit en outre pour les requêtes DELETE ou UPDATE ajouter
automatiquement la
vérification que les données transmises concernent l'utilisateur en
question (dans la
clause WHERE) et pour l'INSERT on affecte automatiquement le nouvel
enregistrement à
l'utilisateur. Sur le Web on peut utiliser l'identifiant de de session
