Les développeurs doivent-ils être autorisés à interroger ( SELECT/ en lecture seule) des bases de données de production? Au lieu de travail précédent, l’équipe de développement avait le db_datareaderrôle; où je travaille maintenant, l'équipe de développement ne peut même pas se connecter à l'instance de production.

L'une des instances de test est une copie de la production restaurée à partir d'une sauvegarde de production une fois par semaine. Il n'y a donc aucun problème avec les développeurs qui voient réellement les données.

Quelles sont les bonnes raisons pour ne pas autoriser les développeurs à interroger la production (sauf simplement pour leur refuser l'accès aux données sensibles)?

Cela dépend vraiment de savoir si le développeur a des responsabilités de support. S'ils sont prêts à prendre en charge la troisième ligne, ils devront probablement consulter la base de données de production pour le faire.

En règle générale, il est déconseillé de faire quoi que ce soit sur un serveur de production, à moins que cela ne soit vraiment nécessaire.

Pour la plupart des objectifs de développement, les miroirs ou les instantanés de la base de données de production seront suffisants et probablement meilleurs que ceux de la base de données de production réelle. Si vous faites quelque chose impliquant une intégration, alors vous voudrez des environnements de base de données stables où vous pouvez contrôler ce qu’ils contiennent. Tout ce qui implique une réconciliation aura également besoin de la capacité de regarder à un moment contrôlé.

Si le problème vient du fait que vous n’avez pas d’environnements miroir de production ni de moyen de mettre une copie des données de production quelque part pour vos développeurs, il s’agit d’une question quelque peu différente. Dans ce cas, vos développeurs ont réellement besoin d'au moins un environnement miroir. Si vous ne pouvez pas voir quel est le problème dans les données, il est assez difficile de le résoudre.

Non.

Les développeurs ne doivent pas avoir accès aux systèmes de base de données de production pour les raisons suivantes:

1. Disponibilité et performances : disposer de droits en lecture seule sur une base de données n'est pas inoffensif. Une requête mal écrite peut:

   1. Verrouillez les tables en bloquant d'autres processus critiques.
   2. Corbeille votre cache de données, obligeant les autres processus à relire les données du disque.
   3. Taxez votre couche de stockage, ce qui a un impact sur les autres services partageant ce stockage.

2. Sécurité : votre base de données de production peut contenir des informations sensibles telles que:

   • mot de passe hash
   • détails de facturation
   • autres informations personnelles identifiables

   Seuls ceux qui ont absolument besoin d'accéder à cette information devraient l'avoir. Dans une entreprise bien organisée, les développeurs ne font pas partie de ces personnes. En outre, votre entreprise ne respectera pas les normes PCI et SOX si ses développeurs peuvent accéder aux systèmes de production avec ces données.

   Les raisons en sont évidentes. Le travail de développement d'un développeur passe par de nombreuses mains avant sa mise en ligne. Qu'est-ce qui empêche un développeur malveillant disposant d'un accès direct à la production de voler vos données de production ou de mettre votre base de données en direct à genoux?

   "Mais ça va aussi pour les DBA! Ils pourraient faire ça!" Exactement. Vous voulez le moins de superutilisateurs possible.

Oui.

Les développeurs doivent avoir accès aux systèmes de production.

Dans mon entreprise, nous avons quatre équipes chargées des bases de données de production. Elles sont:

1. Les développeurs , qui conçoivent et écrivent le schéma et le code des bases de données. Ils n'ont pas accès aux bases de données en production. Cependant, ils siègent parfois avec les administrateurs ou les personnes de soutien et les aident à regarder quelque chose en direct.
2. Administrateurs qui déploient, surveillent et gèrent les bases de données en production.
3. Supportez les personnes qui enquêtent sur des problèmes de production urgents et fournissent un retour d'information aux développeurs afin qu'ils puissent élaborer des correctifs.
4. Les responsables de la Business Intelligence , qui extraient les données des bases de données de productions à l'aide de copies actualisées régulièrement ou d'extraits soigneusement écrits et d'assurance qualité (généralement conçus par les administrateurs).

Il convient d’accorder à vos développeurs un accès à la production lorsque vous rencontrez certaines lacunes dans ces autres groupes.

Par exemple:

• Vous n'avez aucune équipe de soutien. Qui va savoir où chercher pour résoudre ce problème de production sensible au facteur temps? Vos développeurs. Accordez-leur un accès " casser le verre ".
• Vous n'avez pas d'équipe de BI. Vos administrateurs n'ont ni ne veulent rien savoir de rapports ou d'extraits. Qui va résoudre le rapport que vos dirigeants voient tous les matins? Vos développeurs. Accordez-leur un accès limité pour déboguer ces rapports et extraits.
• Vous n'avez pas d'équipe d'administration. Vous êtes dans une très petite ou une jeune entreprise, alors dites bonjour au "DBA accidentel". Vos développeurs font également office d’administrateurs et ont donc besoin d’un accès complet à la production.

La performance serait une GRANDE raison.

Ce n'est pas parce qu'ils ne peuvent pas modifier les données qu'ils ne peuvent pas affecter le serveur. Une requête mal rédigée pourrait mettre l'environnement de production à genoux et causer potentiellement d'autres problèmes (comme des débordements de tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

C'est une recette pour un désastre. Notez qu'il s'agit d'un produit cartésien avec une commande avant, ce qui signifie qu'il sera trié dans tempDB.

Le principe est "privilège minimum" et "besoin de savoir": les développeurs passent-ils ce test?
Surtout quand les auditeurs ou Sarbannes-Oxley viennent frapper à la porte.

Ensuite, mon hypothèse suivante: les développeurs sont stupides. Donc , s'ils ont besoin pour dire le soutien 3e ligne, qui alors a besoin? Les singes Web ne le sont généralement pas, mais les types de base de données sont oui s'ils doivent le prendre en charge.

Ensuite, l'accès est-il nécessaire en permanence? Ils peuvent avoir un accès «en clair» à l'aide d'un identifiant SQL ou d'un autre compte Windows nécessitant une fermeture de session. Dans notre cas, c’était le propriétaire des données (un homme d’affaires averti en technologie) et le responsable informatique qui l’approuvait.

Je l' ai vu les développeurs à tester contre ou exécuter des requêtes sur la production et démonteront à cause de l' ignorance. En disant cela, les développeurs doivent assumer la responsabilité de leurs actes: s’ils démantèlent un serveur, ils doivent en subir les conséquences. J'ai eu quelqu'un rétrogradé après un incident ...

Ceux-ci supposent un magasin de taille raisonnable bien sûr. Plus les gens portent de chapeaux, moins il y a de séparation des tâches.

De plus, existe-t-il un environnement dans lequel les développeurs peuvent exécuter des requêtes sur des données récentes? Dans mon dernier magasin, prod a été restauré chaque nuit sur un serveur de test pour le fournir.

Je pense que la réponse est, comme avec beaucoup de choses informatiques, "ça dépend".

Une base de données ERP massive contenant de nombreuses informations sensibles sur la société et les clients? Probablement pas (pour des raisons de sécurité et de performance).

Une base de données ministérielle de 5 Mo avec un système d’accès Access qui suit les contributions aux fonds Donut et Pizza? Cela ne fera pas beaucoup de différence, du moins pour l'accès en lecture seule.

Certes, le premier exemple est beaucoup plus courant que le second, mais vous devez être au courant de ces différences si vous êtes chargé de prendre ce type de décisions politiques. Mais du côté opposé, il est étonnant de voir à quelle vitesse une base de données de 5 Mo de fonds de beignets et de pizzas peut se faufiler vers un numéro de pièce de 50 Go / un numéro de carte de crédit client / qui sait ce qui est base de données d'autre si vous le laissez.

Sur un environnement OLTP 24/7 habituel, un développeur normal ne devrait pas être autorisé en production. Période! Si, de temps à autre, une raison particulière apparaît, des autorisations peuvent être accordées sur demande. Mais sur une base habituelle non.

J'ai vu beaucoup de raisons pour cela:

• SELECT * d'une grande table menant à:

  • problèmes de performance (produits cartésiens);
  • problèmes de blocage qui ont finalement amené le site à se mettre à genoux;
  • chaîne de blocage qui bloque la réplication;
  • commander un grand ensemble de données qui ont rempli le disque TempDB qui ..guess quoi? Causé folie complète :-)!
  • hypertension artérielle du DBA chargé de la production pour la nuit;

• lecture de données sensibles (un développeur ne devrait pas avoir accès aux informations de carte de crédit, ni aux données personnelles de l'utilisateur);

Je suis sûr qu'il y a encore plus de raisons.

• Sécurité: certaines informations sensibles peuvent être vérifiées lorsqu'elles sont mises à la disposition des développeurs.
• Paranoïa: Certains pourraient penser que vous pourriez quand même gâcher les données en sélectionnant simplement un accès.
• Performances: une requête nécessite certaines ressources, et vous ne pouvez pas me dire que vos développeurs sont parfaits lorsqu'ils écrivent du code.

Couple d'éléments à considérer

• Les données sont-elles sensibles?
• Les programmeurs font-ils partie d'une équipe de confiance principale ou d'une équipe offshore?
• Quelle est l’ampleur des données interrogées en termes d’impact sur les performances?
• Quelle est l'ampleur du projet ou des dollars impliqués?
• À quel point le temps de disponibilité est-il critique?

Les petits budgets ont besoin de moins de processus, de développement plus rapide.

Plus gros dollars a besoin de plus de processus nécessite des normes plus strictes de pratiques de développement.

Adaptez vos pratiques à ce que vous faites.

Je travaille en tant que développeur pour une très grande entreprise. Tous les développeurs qui fourniront un support (essentiellement tous) auront accès aux bases de données de production pertinentes. Je ne peux parler que pour mon équipe spécifique, mais je vais vous dire pourquoi nous avons accès.

1. Nous avons besoin d'un accès en temps réel pour garder un œil sur notre traitement quotidien. (Bien que nous ayons un tableau de bord, nous devons pouvoir garder un œil sur les choses. Bien que ce soit bien d’avoir cette fonctionnalité sur notre tableau de bord, nous avons trouvé que cela n’était pas pratique.)
2. Nous avons besoin d'un accès en temps réel pour enquêter sur les défaillances de la production, car les retards peuvent avoir un impact considérable. (Je ne vais pas discuter de nos échecs ici. Ils viennent de toutes sortes)
3. Nous avons souvent besoin de créer des rapports personnalisés pour les utilisateurs professionnels et ces informations doivent être à jour. (les dba n’ont pas le temps de le faire et nous n’avons pas le temps de les attendre. pas idéal, bien sûr.)
4. Nous devons effectuer une vérification des déploiements / correctifs DDL / DML de production. (Les administrateurs de base de données les déploient, mais nous savons seulement comment elle devrait être structurée. Nous en savons plus sur la structure de notre base de données que les administrateurs de base de données. Cela peut paraître étrange ici, mais la base de données est très compliquée car nos activités sont très compliquées.)

La performance est une préoccupation. Nous avons des occurrences de développeurs provoquant des ralentissements. Cependant, il s'agit d'instances isolées et notre code SQL est tellement basé sur les performances qu'il est rare que nos développeurs ne comprennent pas l'impact de leurs requêtes.

Pour poser cette question, il faut présumer qu’ils n’y ont actuellement pas accès. Si votre organisation développe des logiciels et que cela sert à résoudre un problème client et que le client fournit une copie de sa base de données, alors «oui». Sinon, je recommanderais de garder les développeurs en dehors de la production et de créer des environnements de remplacement pour leurs besoins en matière de recherche. Une fois que le dentifrice est sorti du tube, il est difficile de le remettre en place.

Je conviens que le fardeau de la justification devrait incomber à ceux qui ont besoin d'un accès. Généralement, dans les environnements où j'ai consulté, j'ai eu accès à des systèmes de production dans lesquels l'environnement était petit et j'étais la personne de soutien. J'ai eu accès à des sauvegardes, etc. où j'étais support pour le support, et accès indirect (via un développeur de support dédié) aux données de production.

Le gros problème est le suivant: vous avez besoin de cet accès lorsque vous êtes obligé de tout faire pour que tout fonctionne bien et que vous deviez répondre à la question du responsable des finances à propos de quelque chose qui ne fonctionne pas. Dans ce cas, vous ne pouvez pas toujours utiliser des données anciennes. D'un autre côté, plus l'accès est important, plus il est mauvais. Généralement, en tant que consultant, j'ai tendance à éviter ce type d'accès, à moins que cela ne soit nécessaire. Depuis que je travaille sur des bases de données financières, la dernière chose que je veux, c'est être accusé de saisir mes propres factures :-D.

D'un autre côté, si vous n'avez pas besoin d'un accès, vous ne devriez pas l'avoir. Je n'achète pas vraiment l'argument des données sensibles, car le développeur est probablement responsable de s'assurer que tout est géré correctement (et il est très difficile de vérifier sans regarder ce qui a été réellement stocké lorsqu'un rapport de bogue arrive). Si vous ne pouvez pas faire confiance au développeur pour qu'il examine les données stockées dans l'application du développeur, vous ne devez pas l'embaucher pour l'écrire. Il y a trop de façons pour le développeur de masquer les données et de les envoyer par courrier électronique et vous ne pouvez jamais en être sûr. Les contrôles MAC aident ici mais ils sont toujours assez complexes à implémenter.

Le gros problème de mon côté concerne l’accès en écriture. Si un développeur n'a pas d'accès alors, a fortiori, le développeur n'a pas d'accès en écriture. Si vous souhaitez vérifier l'intégrité des livres, vous souhaitez conserver l'accès en écriture au moins de personnes possible. Les pistes d'audit sont beaucoup plus faciles à valider si les développeurs n'ont pas d'accès. Si le développeur a un accès en lecture, vous vous demandez toujours s'il existe un rattachement de privilèges pouvant donner un accès en écriture (peut-être une injection SQL dans une procédure stockée?). J'ai souvent eu un accès complet aux informations de facturation des clients lorsque j'ai eu accès à des environnements de transfert. Si un environnement de transfert fonctionne correctement, je demanderai généralement activement de ne pas avoir accès à la production sauf si cela est nécessaire.

Donc ce n'est pas parfait, bien sûr. Un développeur peut toujours créer des portes arrière dans l'application qui peuvent ne pas être facilement détectables, mais cette approche est une approche raisonnable, étant donné que les données de sauvegarde sont disponibles la veille, il me semble que c'est leur préoccupation.

J'espère que cela t'aides.

Edit: J'ajoute simplement que, dans les environnements plus vastes dans lesquels j'ai travaillé, j'ai eu accès à des données de sauvegarde complètes allant souvent de quelques jours à quelques mois pour le système financier. Cela a toujours été suffisant pour mon travail et la seule fois où cela a échoué, c’est quand les responsables des finances ont eu besoin de la capacité de tester des données plus récentes pour pouvoir les comparer à la production.

Ne pas avoir accès est une bonne chose et un moyen de protéger les développeurs et les autres de ne pas corrompre accidentellement les données ou les visualiser. Cela protège également les entreprises contrevenant à la loi (violations de Hipaa et problèmes de confidentialité)

Un développeur n'a jamais vraiment besoin d'accéder à un environnement de production, il est simplement plus facile du point de vue du développeur si un bug difficile ne peut pas être reproduit.

Toutefois, un développeur peut créer des mini-dumps ou des fichiers journaux et utiliser les fichiers de symboles de PDB pour recréer le bogue.

Si les données doivent être ramenées dans un environnement de test, il est typique qu'un processus quelconque les efface, ce qui peut créer un travail supplémentaire.

Selon le logiciel de base de données utilisé dans ce que vous appelez la production, une nouvelle licence peut être nécessaire pour que le développeur accède à la base de données, ce qui représente une dépense importante pour un simple accès en lecture.

Si votre entreprise ne vous fournit pas les outils nécessaires pour déboguer ou rechercher des problèmes de production, ce n’est pas parce que vous n’avez pas accès aux données de production.

Les données constituent la partie la plus précieuse de la plupart des applications!

La performance pourrait être l'une des raisons.

Les requêtes des développeurs peuvent souvent être inefficaces, entraînant un verrouillage excessif ou une utilisation excessive des ressources jusqu'à ce qu'elles soient correctement réglées.

Un système de production n'est pas un endroit approprié pour les développeurs.

Cela dépend du DBA et de la confiance qu'il a dans le développeur. Habituellement, les développeurs reçoivent des privilèges de requête (lecture) sur les bases de données de production. En règle générale, les développeurs ne doivent travailler qu'avec des bases de données test / dev.

Le défi est que la plupart des applications logicielles sont basées sur les données. Ainsi, lorsque vous essayez de résoudre un problème dans l'application, vous devez vraiment voir les données qui le pilotent. Les développeurs ont donc vraiment besoin d'une forme d'accès.

Utiliser des connexions SQL pour leur donner uniquement un accès en lecture seule aux tables est très utile. MAIS, qu'est-ce qui les empêche de créer une requête de 20 jointures ou d'effectuer SELECT * à partir d'une table contenant des millions d'enregistrements? Ces requêtes pourraient tuer accidentellement les performances de votre base de données et de votre stockage.

Mon entreprise Stackify a mis au point un moyen intelligent de résoudre ce problème. Les développeurs peuvent exécuter la requête via notre logiciel et nous utilisons le plan de requête pour nous assurer qu'il s'agit simplement d'une instruction SELECT et que le coût estimé de la requête est faible et qu'il ne renverra que quelques enregistrements. De cette façon, ils ne peuvent pas faire beaucoup de mal. Nous auditons également toutes les requêtes qu'ils exécutent.

Ceci est juste une des choses que nous fournissons. Consultez-nous à l' adresse http://www.Stackify.com pour en savoir plus sur nos solutions de support DevOps .

Oui. Dans certains cas, il est judicieux d'autoriser certains sous-ensembles d'utilisateurs, y compris les développeurs, à accéder à des données de production de requêtes. Cependant, les limitations appropriées doivent être en place pour deux raisons. Tout d'abord, en tant qu'administrateur de base de données, vous devez faire de votre mieux pour assurer le niveau de service requis par tous les utilisateurs. En outre, vous souhaitez éviter les mauvaises requêtes non intentionnelles, telles que les suppressions en masse ou les vilolations de règles métier. Il devrait aller de soi que des contrôles de sécurité appropriés doivent être en place.

Quelles que soient les raisons pour lesquelles vous ne pouvez pas autoriser les requêtes ad hoc directement dans les tables de base de données, il peut être judicieux d'autoriser les requêtes aux vues et aux procédures stockées. À l'aide des autorisations de base de données, vous pouvez empêcher directement les requêtes SELECT de conserver les tables et même limiter les vues et les procédures stockées auxquelles un utilisateur donné a accès. Non seulement cette méthode donne de la flexibilité à votre base d'utilisateurs, mais elle protège également l'intégrité et la fiabilité de vos données lorsqu'elle est correctement implémentée.

Dans notre société, nous maintenons des esclaves en lecture seule de bases de données de production sur lesquelles les services de production ne s'appuient pas. Nous accordons aux développeurs l'accès à ceux qui ont accès aux données de production. S'il existe des données sensibles (informations client, informations de paiement, etc.), nous limitons la réplication de ces tables et maintenons un exemple de table de données sur le serveur esclave.

Non jamais!!

C'est pourquoi nous avons des serveurs de développement / test / UAT. Les données de Production peuvent être copiées dans l'environnement de test et les développeurs peuvent poursuivre leurs tests. Certaines requêtes peuvent également être très dommageables dans un environnement de production. Cela augmente la charge et peut réduire toute la performance aux heures de pointe.

Toutes les informations dont ils ont besoin doivent passer par le DBA qui peut exécuter ce qu'ils veulent (Select) et leur envoyer les résultats. C'est ce que nous faisons dans notre environnement.

Je ne sais pas pourquoi tout le monde suppose que les développeurs sont stupides et ne savent rien. Je reçois un échantillon d'une tonne de rôles différents où ils se sont trompés et ne devraient pas être "en production". J'ai des administrateurs de bases de données, des administrateurs système, des administrateurs réseau, des développeurs, etc.

Personne (dev, dba, sa) n'a accès à un serveur ou à une base de données dans aucun environnement avec une connexion réseau normale. Ils ont tous des comptes "admin" spécifiques qui doivent être utilisés. Oui, les dba et sa utilisent généralement le leur plus souvent, mais même si elles doivent marcher légèrement. J'ai brulé par tout le monde.

Ainsi, un bon jour, aucun rôle informatique n’a besoin d’être accessible. Cependant, le sh! T frappe le ventilateur, tous sur le pont et nous avons besoin des bonnes personnes pour résoudre le problème. Ceci est généralement conduit par le développeur qui connaît l’application et guide les dba et sa sur certains points. C'est juste le retard inutile ou demande et approbation.

En outre, l’approbation n’est en aucun cas suivie d’audit de type, l’approbation ne signifie donc rien.