Permissions SQL Server appropriées pour les développeurs

Question

Après quelques recherches sur Google et un rapide coup d'œil aux questions posées ici, je ne parviens pas à trouver ce que je pensais être une solution miracle pour les autorisations du serveur SQL.

Comme je le vois souvent dans les petites entreprises, la plupart des développeurs utilisaient un compte administrateur pour SQL Server pendant le développement. Je veux définir des rôles et des autorisations que je peux attribuer aux développeurs afin que nous puissions effectuer notre travail, mais aussi le faire avec les autorisations minimales requises. Quelqu'un peut-il me conseiller sur les autorisations SQL Server à attribuer ?

Composants :

• SQL Server 2008
• SQL Server Reporting Services (SSRS) 2008
• Services d'intégration du serveur SQL (SSIS) 2008

Plateformes :

• Production
• Mise en scène/QA
• Développement/Intégration

Nous utilisons une sécurité en "mode mixte" en raison de certaines applications et de certains réseaux existants, mais nous allons passer à Windows Auth. Je ne sais pas si cela affecte réellement la configuration des rôles.

Je prévois de configurer l'accès des développeurs aux bases de données Prod et Staging/QA en lecture seule. Cependant, je veux que les développeurs conservent la possibilité d'exécuter le profilage.

Nous avons besoin de comptes de déploiement avec des niveaux de privilèges plus élevés. Nous essayons actuellement de déterminer exactement les privilèges dont nous avons besoin pour les déploiements de paquets SSIS.

Dans le serveur de développement, les développeurs ont besoin de privilèges étendus. Cependant, je ne suis pas sûr que le fait de les nommer tous administrateurs soit vraiment le meilleur choix.

Il est difficile de croire que personne n'a publié un exemple décent script qui configure ces types de rôles avec un bon ensemble de permissions appropriées pour les développeurs et les déployeurs.

Nous pouvons probablement résoudre tout cela en verrouillant les choses et en ajoutant des autorisations au fur et à mesure que nous en découvrons le besoin, mais ce sera un trop gros PITA pour tout le monde.

Quelqu'un peut-il m'indiquer, ou me fournir, un bon exemple de permissions pour ce type de rôles sur ce type de plateformes ?

Answer 1

Cela varie considérablement d'une entreprise à l'autre. L'ingrédient clé est de verrouiller la production afin que les développeurs ne puissent pas créer ou modifier les objets. Nos développeurs n'ont que des droits de datareader sur la production, rien d'autre. Ils ne peuvent même pas exécuter une procédure stockée à moins d'être connectés à l'application et d'utiliser les autorisations de l'application.

Nous donnons à peu près tous les droits à de nombreux développeurs sur dev, mais cela peut varier en fonction des bases de données qu'ils sont censés développer et des serveurs auxquels ils doivent accéder pour les applications qu'ils prennent en charge. Ainsi, un développeur ayant un accès complet à un serveur de développement peut ne pas avoir de droits sélectifs sur un autre.

En excluant les développeurs de la production, nous avons gagné plusieurs choses essentielles. Premièrement, il n'y a pas de développement de base de données par des cow-boys. Ils savent qu'ils doivent créer des scripts pour que quelqu'un d'autre les exécute et donc ils ne font pas de changements aléatoires qu'ils oublient ensuite. Cela signifie également qu'ils n'ont pas de problème pour mettre les scripts dans le contrôle de la source, puisque les personnes qui ont des droits sur la prod n'exécuteront un scripts que s'il est dans le contrôle de la source.

Ensuite, il n'y a pas de personnes qui font des changements d'urgence à la volée, non testés, dans la production, qui ne sont jamais transmis au développement et à la qualité et qui sont donc perdus la prochaine fois qu'une nouvelle version est chargée. En conséquence, les changements qui ne fonctionnent pas sur la production ont également diminué, car maintenant tout est testé avant que quelqu'un essaie de le mettre sur la production.

Il n'y a pas non plus de personnes qui font des changements de données à la volée dans prod et qui mettent accidentellement à jour toute la table des utilisateurs parce qu'ils ont oublié de mettre en évidence une clause where (oui, cela s'est produit avant que nous verrouillions prod).

Answer 2

J'ai cherché des conseils similaires mais je n'en ai pas trouvé. Après quelques expérimentations, je pense qu'une configuration simple consisterait à ajouter l'utilisateur au rôle de serveur "dbcreator", puis à l'ajouter au rôle "db_owner" dans chaque base de données sur laquelle il travaillera. Cela permettrait à l'utilisateur de créer de nouvelles bases de données, ainsi que de modifier celles dans lesquelles il est membre de "db_owner".