Discussion :

[Immobilis]

Bonjour,

1 - Mon serveur SQL est sur un domaine
2 - Les utilisateurs du domaine sont autorisés à se connecter à la base de données. Les rôles sont :
a - Public
b - Datareader
c - Datawriter

Comment les empêcher d'utiliser Enterprise manager (par exemple) pour se connecter au serveur?

Merci

[WOLO Laurent]

Je ne comprends pas bien votre question.
Comment empêcher l'accès uniquement pour l'application entreprise Manager ?

[Immobilis]

C'est un peu ça.
En fait quelque soit l'application, je ne souhaite pas que n'importe qui puisse accéder à l'instance du serveur SQL.

Apparement, c'est ce qui se produit dans une configuration MIXTE de la gestion de la sécurité. Le fait d'ajouter un groupe de sécurité Windows à la liste des identifiants SQL permet à tous les membres de ce groupe d'utiliser Enterprise Manager pour naviguer dans la base. Au niveau au-dessous on peut affiner en attribuant des rôles.

Il n'a pas l'air d'y avoir bcp de post sur l'utilisation d'active directory pour la gestion de la sécurité au niveau du serveur SQL. La majorité des développeurs utilisent un identifiant SQL le mm pour tous.

A+

[Immobilis]

Je ranime un peu le post qui est parti bien loin pendant les vacances.

Bonne année.

[Fabien Celaia]

ce type de problème se règle généralement par 2 processus:

1) le gouverneur de ressources (pas dispo sous MS-SQL)
2) le trigger sur connexion (pas sur MS-SQL2000, mais peut-être sur MS-SQL 2005 ?)

Sinon, ne vous reste plus que la méthode "bourrin" consistant à créer un script checkant sysprocesses.program_name et tuant, au besoin, le processus via kill

[SQLpro]

En effet mixer la sécurité d'utilisateur OS et l'accès à SQL Server est à mon sens une grosse connerie.

Tous les experts et éditeurs de SGBDR (en dehors de MS) respectent le, standard d'indépendance entre données et application. Or aucun utilisateur n'accède directement au SGBDR. Il n'y a que des applications à y accéder...

Donc le couplage OS User / SGBDR est stupide et dangereux.

Passez à une sécurité purement SQL pour la base et purement Windows pour les utilisateurs et vous n'aurez plus d'ennuis de ce genre !

A +

[Fabien Celaia]

Tu es sur le coup un peu injute avec MS
Eux au moins laissent le choix entre les 2 startégies.

DB2, lui, se repose entièrement sur l'OS
Oracle offre les 2 possibilités (et même LDAP en plus), mais impossible de blinder la base par rapport à un admin local OS

[Immobilis]

En effet mixer la sécurité d'utilisateur OS et l'accès à SQL Server est à mon sens une grosse connerie

A mon sens, la meilleur sécurité est celle de Windows exclusivement. Que dire d'un mot de passe SQL qui ne change jamais (ex: "sa")??
Active Directory + SQL me semble un bon tandem. La solution de facilité est effectivement de différentcier OS et SGBD, faire un seul ID avec tous les droits et gérer les accès par l'application web. Mais c'est encore plus dangereux quand on connait ce mot de passe. Alors qu'avec Windows exclusivement, il faurait connaitre les mots de passe des utilisateurs.
En ce qui concerne "Enterprise Manager", la gestion de la securité par windows permet de n'autoriser que certaines actions.
En fait, c'est puissant, mais il faut être précis.
Au fait, pourquoi:

standard d'indépendance entre données et application

A+

[Fabien Celaia]

et bien, à mon sens, c'est un mixte des 2

1) pour les uitilisateurs, via l'authentification Windows
2) pour les DBA, via l'authentification mixte,car c'est la seule qui permet de sécuriser le serveur contre un accès d'un admin OS

[Immobilis]

sécuriser le serveur contre un accès d'un admin OS

L'admin OS a tellement d'autres privilèges, je ne comprends pas trop l'intérêt...

[SQLpro]

Au fait, pourquoi:
SQLpro a écrit:
standard d'indépendance entre données et application

Le jour ou vous aurez mappez tous vos user OS Win sur SQL Server et que votre SI est HS et que l'on vous demande de rétablir d'urgence en priorité l'accès aux données vous serez dans la merde la plus noire....

C'est généralement après ce genre de crash et la colère monstre des dirigants de l'entreprise que l'on révise sa position.

C'est aussi ce que la norme SQL impose : indépendance entre données et application (donc utilisateurs humains).

A +

[Fabien Celaia]

sécuriser le serveur contre un accès d'un admin OS

L'admin OS a tellement d'autres privilèges, je ne comprends pas trop l'intérêt...

Il n'aura en tout cas pas celui d'accéder aux données si on lui supprime le buildin\Administrator dans MS-SQL.

[Immobilis]

... votre SI est HS ...

Dslé, mais c'est quoi SI? D'une manière générale ça doit quand mm bien pouvoir se sauvegarder, non??

... rétablir d'urgence en priorité l'accès aux données ...

Au pire, on peut d'urgence basculer sur une authentification SQL, mettre un ID et modifier la chaine de connection, non??

SQL impose

As-tu une référence là dessus? Merci

Il n'aura en tout cas pas celui d'accéder aux données si on lui supprime le buildin\Administrator dans MS-SQL

Oui, mais c'est un peu dangereux. Partant du principe que les administrateurs ont "tous" les pouvoirs sur l'OS pourquoi pas aussi sur le serveur SQL. Mais bon, je suppose que c'est un choix d'administration.

Je pose peut-être des questions naïves, mais comme je débute sur SQL Server soyez indulgents

Merci bien

[Fabien Celaia]

Il n'aura en tout cas pas celui d'accéder aux données si on lui supprime le buildin\Administrator dans MS-SQL

Oui, mais c'est un peu dangereux. Partant du principe que les administrateurs ont "tous" les pouvoirs sur l'OS pourquoi pas aussi sur le serveur SQL. Mais bon, je suppose que c'est un choix d'administration.

Compte tenu de la capacité de nuisance par incompétence qu'ont certains administrateurs OS par rapport aux SGBDR, c'est le leur laisser qui est dangereux

[SQLpro]

Fadace à dit :

Compte tenu de la capacité de nuisance par incompétence qu'ont certains administrateurs OS par rapport aux SGBDR, c'est le leur laisser qui est dangereux

Oh que oui !!!! Pour une fois que tu clame la vérité haut et fort !
Ce qui m'étonne c'est l'incompétence de plus en plus grande des admin OS face aux contraintes des SGBDR. C'est de pire en pire. Je soupçonne plus de la moitié des administrateur OS en charge de SGBDR de n'avoir jamais fait de cours d'aministration de serveur SQL...
Si tu savait le nombre de conneries crasse que j'ai entendu de la part d'admin OS qui prétendait savoir et affirmait des conneries flagrante et en plus appliquait des mesures contre performantes sur des serveurs de bases de données... Et en plus certains sont des hébergeurs ! C'est lamentable et après ils viennent dire que MS SQL Server c'est de la merde...
Personnellement je suis assez mauvais en admin OS, c'est à dire que je connais bien que la partie nécessaire et suffisante pour MS SQL Server et il ne me viendrait jamais à l'idée de donner des conseils et critiquer ce que je ne sait pas.

Immobilis a écrit :

As-tu une référence là dessus? Merci

Tout simplement la norme SQL.
Vous pouvez vous procurer les différentes normes SQL auprès de l'ISO.
Les modules qui vous intéresseront sont : Foundation et Framework.
La version la plus récente de la norme est SQL:2003.
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=34132&ICS1=35&ICS2=60&ICS3=
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=34133&ICS1=35&ICS2=60&ICS3=

Si vous désirez quelque chose de plus "light" vous pouvez ouvrir mon récent livre sur SQL (en collaboration avec C. Soutou) aux pages 306/307 qui en parle brièvement.
Mais comme vous semblez mettre en doute ma parole...

A +

[Immobilis]

Mais comme vous semblez mettre en doute ma parole...

Ouh là, loin de là. Pas d'inquiétude. Je ne souhaite que comprendre les tenants et les aboutissants autant que possible. Tes remarques sont très interessantes.
Mon but est simplement d'implémenter une sécurité à la fois solide et pas trop lourde à gérer.
Je dois en plus surmonter les problèmes posés par les Administrateurs Systeme qui m'interdisent de me loguer sur le serveur mais qui me donnent les pleins pouvoirs sur le serveur SQL. A partir de mon poste, je dois administrer le serveur SQL en utilisant Enterprise Manager => pb de connexion et de création de l'instance (résolu).
En utilisant le ID des utilisateurs du domaine, je souhaitai ne pas laisser de mots de passe dans un seul fichier.
Apparement le compromis est de mise.

En fait, un pb résolu en soulève un autre. Pour simplifier, je vais sans doute passer par l'authentification SQL.

A+