Octroi de privilèges SA aux développeurs sur la zone de développement

8

Malgré nos vives protestations, notre direction a décidé que l'équipe de développement devait se voir accorder des droits «sa» sur le serveur de développement. Le hic, c'est que nous, le groupe de soutien DB sommes toujours responsables de la maintenance de cette boîte.

On nous a maintenant confié la tâche de dresser une liste de choses à faire et à ne pas faire pour les équipes de développement avec ces privilèges améliorés.

Veuillez ajouter à cette liste:

DO - confiner les activités à la DB en cours de développement

NE PAS --

  • modifier les paramètres d'instance SQL
  • sp_configure (y compris cmdshell)
  • ajouter / modifier / supprimer des paramètres de sécurité
  • ajouter / modifier / supprimer des objets de base de données
  • ajouter / modifier / supprimer des objets serveur comme des périphériques de sauvegarde et des serveurs liés
  • ajouter / modifier / supprimer la réplication
  • ajouter / modifier / supprimer des plans de maintenance
  • toucher n'importe quelle base de données qui n'appartient pas à votre équipe

Tous les pointeurs vers les outils disponibles pour suivre les activités de ces utilisateurs seront grandement appréciés.

sql-server sql-server-2005 permissions Raj
la source
1
De quelles tâches ont-ils besoin pour faire qui nécessitent des privilèges de niveau supérieur de SA?
Je pense que db_owner serait tout ce dont ils ont besoin ...
5
OK, s'il leur est conseillé de NE PAS "ajouter / modifier / supprimer des objets de base de données", que sont-ils censés faire? N'est-ce pas tout l'intérêt d'avoir une boîte de développement qu'ils puissent la casser?
Stuart Ainsworth
Ce sont des développeurs d'applications. Ils ont besoin des privilèges «sa» pour pouvoir déboguer les procédures stockées dans Dev Studio. La décision est déjà prise par la direction et elle ne veut pas bouger. Nous essayons de minimiser les maux de tête potentiels
2
+1 pour la question, car j'ai rencontré ce problème plusieurs fois. Une autre solution: Donnez aux développeurs une machine virtuelle en bac à sable avec SQL sur laquelle ils sont 100% boss. Ils sont également 100% responsables de le maintenir en vie :) -> c'est incroyable à quelle vitesse les DEV apprennent à ne pas casser leur propre système :)
Martin S. Stoller

Réponses:

8

Si ce n'est pas trop tard, une option de compromis que j'ai vu bien fonctionner est plutôt que de mettre à niveau les autorisations ou de remplacer les comptes existants des développeurs, créez un compte séparé qui n'est utilisé que lorsqu'ils ont besoin des autorisations élevées.

Donc, normalement, ils fonctionnent sous des comptes individuels "restreints" (que j'utilise librement car ces comptes restreints ont encore besoin de lourdes autorisations - c'est-à-dire créer, supprimer, modifier pour les tables). Mais pour cette rare occasion où ils pensent en avoir besoin sa, ils peuvent se connecter en utilisant ce compte. Ensuite, vous pouvez marquer le compte dans vos journaux et effectuer une surveillance supplémentaire sur celui-ci. Vous avez donné aux développeurs l'accès qu'ils demandaient, mais d'une manière qui est un peu plus contrôlable.

Finalement, en cas d'abus, les journaux de ce compte peuvent être utilisés comme preuve pour le retirer.

Joel Coehoorn
la source
6

Il indique ici (MSDN) que vous avez besoin de sysadmin (sa) pour déboguer sur SQL Server 2005.

Cependant, cette question SO montre une autre manière sans sa, ce que je pensais initialement. Laissez-les simplement s'exécutersp_sidedebug

Je suggère également de leur donner local SQL Express qui résout également d'autres problèmes ...

(édité avec plus d'informations)

Edit, après la réponse de W. Craig Trader

Autres problèmes avec les droits "sa", dans le pire des cas:

  • les développeurs créeront des assemblages CLR non fiables
  • ils utiliseront xp_cmdshell
  • toutes les actions sont dans le contexte du compte de service du serveur sql
  • ils assumeront les droits sa pour la connexion client
  • etc

par exemple xp_cmdshell 'scm -Action 6 -Server PRODSERVER'

gbn
la source
1
La réponse aux développeurs qui codent en dehors des lignes est de faire une intégration continue avec verrouillé 'comme cela sera exécuté par les autorisations des utilisateurs et échouer la génération en conséquence. Demandez au serveur de génération de recréer la base de données à partir de zéro et de la remplir avec des données de test (toutes à partir de SCM bien sûr). (Dans mon cas, j'ai utilisé exactement le même code que le programme d'installation de l'application utiliserait pour créer une nouvelle base de données, testant ainsi le programme d'installation ainsi que l'application.)
1
Trader @Craig: ne fonctionnera pas. Pour reformuler mon ancienne réponse, les développeurs ne peuvent pas faire confiance et integratiointegrationsn ne détectera pas tous les cas. Je suis développeur dba: un singe code client est mon ennemi. Dans mon entreprise, je gagne .... c'est ma rame et je traite avec le plus petit dénominateur commun ...
gbn
Apparemment, votre kilométrage peut varier. D'après mon expérience, j'ai généralement dû faire un peu de formation / orientation pour expliquer comment et pourquoi les choses se font, mais après cela, les choses fonctionnent généralement assez bien. Bien sûr, j'insiste toujours sur le fait que les seules versions qui vont au-delà du développement sont celles qui proviennent du serveur de construction étroitement contrôlé - si le code ne se construit pas là-bas, c'est un problème avec votre code (ou vos tests) pas le configuration. Je l'ai fait avec de petites équipes et de grands projets, dans de nombreuses entreprises, et toujours avec succès.
4

Sur suggestion, j'ai pour mettre en place une gestion basée sur les politiques et appliquer tous vos «faire» et «ne pas» comme règles de politique. Cela contribuerait grandement à protéger l'instance.

Je déploierais également l'audit des modifications DDL, voir Audit dans SQL Server 2008 , pas tant comme moyen de dissuasion, mais surtout comme système de suivi des modifications, donc quand quelque chose est vissé, au moins vous saurez ce qui a changé.

Remus Rusanu
la source
3

S'il s'agit du serveur de DÉVELOPPEMENT, quel est le problème avec les DÉVELOPPEURS pouvant avoir un accès complet? Dire aux développeurs que vous ne pouvez pas ajouter / supprimer / modifier des objets de base de données (par exemple: tables, colonnes, index), c'est comme leur dire "Vous pouvez avoir un compilateur, mais vous n'êtes pas autorisé à l'exécuter". Il me semble que les développeurs veulent / ont besoin d'accéder à leur propre instance de base de données spécifiquement pour leur permettre de tester différentes méthodes de résolution de problèmes SANS avoir à fouiller avec les bases de données PRODUCTION ou TEST. Vous devriez encourager ce genre de comportement, pas le décourager.

Certains pourraient suggérer que les développeurs travaillent avec des instances locales de SQL Express, mais bien que SQL Express pour chaque développeur puisse résoudre certains problèmes, il a des limites et des caractéristiques de performances différentes de SQL Server complet sur un serveur distinct.

Ce que vous DEVRIEZ faire est d'instaurer un programme de sauvegarde régulier (au moins tous les soirs) et de travailler avec les développeurs pour vous assurer qu'ils savent comment lancer des sauvegardes non planifiées et restaurer à partir de sauvegardes, afin que les temps d'arrêt soient minimisés en cas de problèmes.

Craig Trader
la source
Votre analogie est complètement fausse. Ce qui se passe, c'est qu'ils fouillent et se mettent à gémir quand ils ne peuvent pas migrer vers des serveurs verrouillés. Je suis un développeur DBA bien sûr :-)
gbn
Ensuite, un peu d'éducation est de mise. Je suis un développeur qui a été trop souvent DBA. Avec un pied dans les deux mondes, c'est généralement mon travail d'enseigner aux deux parties à coexister. Après tout, ce sont les UTILISATEURS qui sont l'ennemi, pas les DBA ou les développeurs ...
Il y a aussi des choses comme les plans de maintenance auxquelles ils ne devraient pas avoir accès.
Joel Coehoorn
1
Le problème est que nous avons plusieurs groupes de développeurs et que ce serveur héberge toutes leurs bases de données. Ce groupe qui requiert des droits «sa» ne possède que 33% des Dbs. Le problème est qu'ils risquent de bousiller et de faire tomber le serveur, impactant également d'autres groupes. L'entreprise ne veut pas leur fournir du matériel séparé, à moins que nous ne puissions prouver qu'ils ont foiré.
2
C'est ridicule. Chaque groupe de développement doit avoir son propre serveur, afin que personne ne marche sur les orteils de quiconque. De nos jours, le matériel est pratiquement gratuit et les logiciels presque aussi bon marché que le matériel. Et si votre organisation est suffisamment grande pour avoir plusieurs groupes de développement, elle devrait utiliser la virtualisation de serveur, ce qui rendrait tout cela encore plus facile.
3

Son le dev serveur, pas le serveur de groupe de soutien DB, ou le serveur de production. Gardez une bonne sauvegarde / image et laissez les développeurs pirater. Laisser DBA contrôler le devbox, c'est comme laisser la queue remuer le chien. Il est là pour que les développeurs travaillent sur les développeurs. Cela implique parfois de casser des choses et de supprimer des tables, puis de les remettre avec des paramètres différents. Les boîtes de développement vont toujours être dans un état de délabrement après un certain temps, c'est ce que nous faisons. Si nous ne savons pas où un problème survient, nous essayons différentes choses. Certains d'entre eux sont faciles à défaire, d'autres moins.


la source
Le problème ici est qu'il est facile pour les développeurs d'oublier que les applications qu'ils créent n'auront pas toujours les mêmes droits. Oui, donnez-leur sa, mais faites en sorte qu'ils ne soient pas sa par défaut, afin qu'ils sachent quand ils font quelque chose qui aura besoin d'un peu de travail supplémentaire pour se déployer correctement.
Joel Coehoorn
1

Je ne pense pas qu'ils aient besoin des privilèges SA sur la boîte de développement. Dans presque tous les cas, ils peuvent s'en passer.

Je pense qu'une bonne option est d'installer l'édition de développement locale.

question:

Vous ne voulez pas que les développeurs ajoutent / modifient / suppriment des objets de base de données? !! Comment vont-ils évoluer?

Raj More
la source
Désolé pour la confusion. Ce que je voulais dire par ce point, c'est que les développeurs ne doivent pas modifier les paramètres de la base de données ou supprimer des bases de données.
1

Nous exigeons que tous les changements de structure de base de données soient effectués avec des scripts (même sur dev) et enregistrés dans subversion. Ensuite, selon un calendrier défini, nous actualisons le développement de prod et ils doivent réexécuter leurs scripts pour revenir à leur stade de développement. Cela permet de garantir que tout se fait via des scripts et que les scripts sont prêts au moment du déploiement.

Je sais qu'en 2008, vous pouvez configurer des déclencheurs DDL pour suivre les modifications structurelles de la base de données, pouvez-vous le faire en 2005? De cette façon, vous pouvez au moins savoir quand quelqu'un change un paramètre qui l'a fait et savoir pourquoi.

HLGEM
la source