Toute indication sur la réduction de mes privilèges dans la production mais sans compliquer excessivement mon travail

Exécution de SQL Server 2005 et 2008 sur Windows 2008 R2.

Nous allons réduire les privilèges de production pour les développeurs - et j'aimerais faire la même chose pour moi en tant qu'administrateur de base de données , en limitant les droits de production et en les augmentant si nécessaire .

Mon objectif principal serait d'éliminer les erreurs stupides - faites par les administrateurs de base de données , les devopers auront tout au plus un accès en lecture en production. Nous aimons agir comme si nous étions des super-héros qui ne peuvent pas se tromper, mais ne pas avoir de droits de production tout le temps est logique et c'est une meilleure pratique, recommandée par certains.

Quelle est la meilleure approche? Qu'est-ce qui sera le moins pénible à utiliser au quotidien et lors des installations?

Nous avons actuellement un groupe Windows pour les administrateurs de base de données qui a des droits sur tous nos serveurs et bases de données.

Je serais également intéressé à réduire les autorisations de connexion au système d'exploitation / à distance - mais je suis le plus préoccupé par les droits DB.

Je suppose que nous aurions besoin de privilèges élevés pour exécuter des traces en tant que sa, et éventuellement pour un nettoyage de la propriété avant de supprimer les droits SA de notre ancienne connexion. À quels autres problèmes pouvons-nous nous attendre?

Merci pour vos conseils et pour partager vos expériences!

Idéalement, pour une base de données de production opérationnelle, vous ne voulez pas que les développeurs aient accès au serveur ou à une base de données sur celui-ci. Ce genre de chose est l'une des premières choses que vous devrez faire pour la conformité SOX .

Pour le genre de droits qui courent sous noms d' utilisateurs, les seuls droits dont ils devraient vraiment avoir sont db_datareader, db_datawriteret explicites GRANT EXECUTE ON x TO y(pour chaque procédure stockée et la fonction définie par l'utilisateur xpour l'ID utilisateur y).

Si vous devez exécuter des traces en production, vous rencontrez des problèmes et il vous faudra un Great Wall of Text ™ pour tout expliquer. Ma première recommandation est d'avoir un environnement QA qui est verrouillé comme la production et si des traces doivent être exécutées, restaurer une sauvegarde de la base de données de prod à QA et y exécuter les traces. Encore une fois, si vous avez des exigences SOX, HIPAA ou PCI-DSS , vous feriez mieux de désinfecter les données de prod avant de les restaurer en QA.

Nous avons actuellement un groupe Windows pour les administrateurs de base de données qui a des droits sur tous nos serveurs et bases de données.

Donnez-leur une connexion et consultez les droits sur les données; cependant, pour effectuer des tâches DBAly, utilisez une connexion distincte avec des privilèges élevés. Je connais un client financier qui fait cela - les connexions basées sur l'authentification Windows standard étaient limitées dans les dommages qu'ils pouvaient faire par inadvertance. Les restaurations et l'exécution de DML doivent être exécutées avec la connexion d'authentification SQL distincte.

Une agence gouvernementale avec laquelle j'ai travaillé a utilisé 2 connexions distinctes pour chaque administrateur de serveur / base de données. Donc, si Tangurenac'était ma connexion au domaine (cette connexion aurait des Userprivilèges réguliers ), alors ce TangurenaAdminserait ma Administratorconnexion séparée . Vous avez des ennuis si vous utilisez votre compte administrateur tout le temps, mais il manque alors d'autorisations pour d'autres choses (comme pas de courrier électronique. Oh, vous dites que comme c'est une mauvaise chose ... ).

L'agence gouvernementale actuelle avec laquelle je travaille a chaque administrateur serveur / db ayant des privilèges supérieurs à l'utilisateur standard, mais pas tout à fait administrateur (pensez-y comme le PowerUsergroupe). Les fonctions d'administration de domaine sont exécutées avec un compte d'administrateur de domaine partagé.

Une erreur courante consiste à restaurer la mauvaise base de données (comme le contrôle qualité restauré sur le serveur de production), et cela ne sera pas résolu via des droits restreints ou plusieurs connexions. Faire des choses potentiellement destructrices par paires est un moyen de minimiser les risques.

Je suppose que nous aurions besoin de privilèges élevés pour exécuter des traces en tant que sa

Non. Vous n'avez besoin que des autorisations ALTER TRACE:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

Au début, je vous suggère de faire tout le jeu de privilèges dans un environnement de développement ou d'assurance qualité où il n'y a aucun problème si l'accès est supprimé pendant un certain temps. Vous devrez voir si les applications n'auront aucun problème de sécurité.

Je vais vous dire notre approche interne:

• toutes les applications utilisent un seul utilisateur de domaine qui dispose des autorisations nécessaires sur une base de données (généralement le rôle de base de données db_owner).

• pour la lecture occasionnelle de données, nous utilisons une connexion SQL. Pour cet utilisateur, nous attribuons le rôle de base de données - db_datareader. C'est là que cela met fin à l'accès pour les développeurs sur le cluster de base de données principal. Pour toute autre idée qu'ils auraient, ils utiliseront les bases de données du serveur de rapports qui sont des copies (effectuées à l'aide de Log Shipping) des bases de données du serveur principal effectuées à minuit. Afin de ne pas tuer le serveur de rapports avec des requêtes ad hoc killer, nous utilisons les allocations de groupes de ressources pour la mémoire et le processeur.

• pour l'équipe DBA, nous avons un groupe de domaines qui a tous les privilèges sur la machine et le serveur (admin sur la machine Windows et sysadmin sur le serveur SQL)

• pour les installations, nous avons un utilisateur SQL qui est db_owner sur les bases de données que nous utilisons lors de l'exécution des mises à jour - nous utilisons des déclencheurs DDL pour surveiller les modifications de schéma et nous devons voir quelles modifications ont été effectuées pendant l'installation ou en tant que modification distincte

• il existe des exceptions occasionnelles pour les développeurs expérimentés, mais une fois leur besoin satisfait, nous supprimons leur accès - ils reçoivent des autorisations en fonction de leur connexion au domaine, afin que nous puissions surveiller les connexions dans les vues traces / ddl et toutes les modifications possibles avec les déclencheurs ddl.

Quant à la façon de faire tout ce travail avec les connexions et les utilisateurs - dans Management Studio dans le dossier de sécurité du serveur, vous créez toutes les connexions nécessaires, puis vous les associez à vos bases de données et leur donnez les rôles dont elles ont besoin. Si vous scriptez l'action, vous verrez qu'initialement, il sera créé une connexion au serveur, puis un utilisateur de base de données connecté à cette connexion, puis affecté un rôle de base de données pour cet utilisateur. Vous pouvez conserver le script dans votre ensemble de scripts, afin de pouvoir vérifier à chaque fois quels utilisateurs doivent être actifs et qui ne doivent pas l'être.

Dans SQL Server, vous pouvez créer un utilisateur de base de données et lui attribuer une database roleautorisation de lecture / écriture / propriété. Une fois que l'utilisateur est migré vers la production, vous pouvez accéder à l'utilisateur de la base de données qui a été migré et décochez les rôles que vous ne souhaitez pas qu'il ait. Par exemple, supposons que l'utilisateur stan soit membre de db_owner (propriétaire de la base de données) dans test. Une fois que l'utilisateur stan est migré vers la production, vous pouvez le retirer de db_owner et lui attribuer uniquement un rôle de db_datareader (lecture seule).

Dans SQL 2005+, un contrôle plus granulaire peut être effectué avec le schema. Vérifiez ce lien sur le schéma pour plus de détails.