Discussion :

[gudbes]

Bonjour à tous,

Je viens vous demander conseil !!

voila le topo : J'ai fait l'installation d'un SQL SERVER STANDARD 2016 sur WINDOWS SERVER STANDARD 2016. Jusque là tout est bon ...

J'ai donc une seul instance mais plusieurs bases de données appartenant à plusieurs prestataires. Le compte de chaque prestataire est celui de l'active directory et pour le moment je suis le seul (compte) qui soit administrateur de l'instance.

Comment faire
1 - Pour que chacun puisse créer ses propres bases sans être administrateur de mon SQL
2 - Pour que les prestataires ne puissent allez visiter les bases de données des autres.

J'espère avec été assez explicite.

J'attend avec impatience vos avis !

Merci par avance.

[SQLpro]

Bonjour à tous,

Je viens vous demander conseil !!

voila le topo : J'ai fait l'installation d'un SQL SERVER STANDARD 2016 sur WINDOWS SERVER STANDARD 2016. Jusque là tout est bon ...

J'ai donc une seul instance mais plusieurs bases de données appartenant à plusieurs prestataires. Le compte de chaque prestataire est celui de l'active directory et pour le moment je suis le seul (compte) qui soit administrateur de l'instance.

Comment faire
1 - Pour que chacun puisse créer ses propres bases sans être administrateur de mon SQL

Donnez à la connexion le privilège CREATE ANY DATABASE

2 - Pour que les prestataires ne puissent allez visiter les bases de données des autres.

Ils ne verrons pas les bases des autres

J'espère avec été assez explicite.

J'attend avec impatience vos avis !

Merci par avance.

A +

[StringBuilder]

Y'a quand même un truc très moyen, que je n'ai jamais réussi à résoudre sans passer par une instance par prestataire / client : le fait que soit tout le monde voit la liste de toutes les bases, soit que personne ne voit aucune base dans la liste (mais peut s'y connecter s'il connaît le nom).

Il serait appréciable qu'on ne puisse voir que les bases auxquelles on a accès.

[gudbes]

J'ai un sql server standard qui (soit disant) me permet 50 instances. J'ai pensé faire une instance par prestataire mais en regardant des forums ... ça ne semblait pas recommander ... qu'en pense tu ... Est mieux sécurisé que de passer par une seule instance ?

Merci de tes conseils

[StringBuilder]

Le souci de démultiplier les instances, c'est que ça gaspille énormément de ressources (moteur de base de données en double, bases systèmes en double, pas de partage du cache et de la mémoire, etc.)

Personnellement, je m'en sert plutôt pour séparer DEV/TEST/PROD sur un même serveur : chaque instance peut avoir un paramétrage différent, être redémarrer indépendamment, etc.
Après, pour mettre plusieurs bases de PROD, c'est pas la première option vers laquelle je me tournerais. Mais dans ton cas, c'est à mon sens la seule solution d'avoir une imperméabilité totale entre les bases.

L'autre avantage, c'est que si un prestataire doit patcher son serveur, modifier des paramètres de l'instance, il peut le faire sans impact sur les autres.

[gudbes]

Malheureusement je pense que la solution des instances par prestataires ne va pas pouvoir être possible car il y a 6 prestataires donc 6 instances... Ce qui sera sûrement trop gourmand pour mon installation. As tu des recommandations pour moi... Pour mettre en place un minimum de sécurité entre les différents prestataires et bases. J'ai cru comprendre qu'il était possible de cacher toutes les bases et que seul ceux qui connaissent le nom de la base peuvent y accéder. C'est peut être très superflu mais ça peut être un bon début non ? Si oui pourrais tu m'expliquer stp comment mettre cela en place.

Merci !

[SQLpro]

Le souci de démultiplier les instances, c'est que ça gaspille énormément de ressources (moteur de base de données en double, bases systèmes en double, pas de partage du cache et de la mémoire, etc.)

Non seulement cela gâche énormément de ressources mais il faut paramétrer la RAM, les CPU, isoler les accès disques... Et surtout cela multiplie les scripts de maintenance : sauvegarde, vérification d'intégrité du stockage, maintenance des index et statistiques, audit du stockage...

L'autre avantage, c'est que si un prestataire doit patcher son serveur, modifier des paramètres de l'instance, il peut le faire sans impact sur les autres.

Aujourd'hui la plupart des paramètres de niveau serveur sont "descendus" au niveau de la base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER DATABASE ... SCOPED CONFIGURATION...

A +

[janlouk]

Il serait appréciable qu'on ne puisse voir que les bases auxquelles on a accès.

Je ne me souviens plus si cela fait ce que tu veux, mais il me semble que oui, non?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/*https://www.mssqltips.com/sqlservertip/2995/how-to-hide-sql-server-user-databases-in-sql-server-management-studio/
DO NOT MAKE CHANGES IN PRODUCTION WITHOUT PROPER TESTINGS IN LOWER-LIFE CYCLE ENVIRONMENTS
Only sysadmins and database owners can see databases
Conclusion
There are limited options to hiding databases. Once you hide all databases the only logins that can see the databases are the logins that are the owners of the database or if the login is a sysadmin.  Also, each database can only have one owner, so you can't assign multiple owners to the same database.
*/
 
USE MASTER
GO
DENY VIEW ANY DATABASE TO PUBLIC
GO
 
--For a specific user
USE MASTER
GO
DENY VIEW ANY DATABASE TO USER_A;
GO

[StringBuilder]

Malheureusement non, ce droit est vrai pour toutes les bases.

Le but, c'est que userA voit base1 et base2, alors que userB voit base3 et base4

[julien94320]

Pour le coup des instances par prestataire cela augmente également le coût les licences car les licences sont facturé par instance ...

En plus des problèmes d'administration ....


Seul alternative des droits spécifiques par user ou groupe d'utilisateur mais en se connectant via management studio les utilisateurs pourront toujours voir les bases disponibles même sans y avoir accès...


A+

[SQLpro]

Merci @SQLpro pour ton aide.
Je suis vraiement un novice sous SQL server et je ne sais pas ou indiquer ton conseil. Voila les écrans sur lesquels je me pose des questions [...]

L'IHM ne permet pas correctement de gérer les privilèges.

pour donner le privilège que j'ai indiqué au compte de connexion, il suffit de lancer la commande GRANT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GRANT CREATE ANY DATABASE TO nom_compte_connexion;

A +

[gudbes]

L'IHM ne permet pas correctement de gérer les privilèges.

pour donner le privilège que j'ai indiqué au compte de connexion, il suffit de lancer la commande GRANT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GRANT CREATE ANY DATABASE TO nom_compte_connexion;

A +

Merci de ton aide

Juste pour etre sur d'avoir bien compris cette commande permet de donner le droits de créer des bases au différents compte de connexion. Par contre y a t il autres choses à changer en droit (db_owner, public, ....)