Les développeurs devraient-ils pouvoir interroger les bases de données de production?
Les développeurs devraient-ils être autorisés à interroger (SELECT/lecture seule) les bases de données de production? L'endroit précédent où je travaillais, l'équipe de développement avait le db_datareader rô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 de ne pas autoriser les développeurs à interroger la production (sauf simplement qu'ils ne veulent pas qu'ils aient accès à des données sensibles)?
Cela dépend vraiment si le développeur a des responsabilités de support. S'ils sont en attente de prise en charge de troisième ligne, ils devront probablement consulter la base de données de production pour ce faire.
Généralement, c'est une mauvaise idée de faire quoi que ce soit sur un serveur de production à moins qu'il ne soit vraiment nécessaire de le faire là-bas.
Pour la plupart des objectifs de développement, les miroirs ou les instantanés de la base de données de production seront adéquats, et probablement meilleurs que la base de données de production en direct. Si vous faites quoi que ce soit impliquant l'intégration, vous voudrez des environnements de base de données stables où vous pourrez contrôler ce qu'ils contiennent. Tout ce qui implique la réconciliation devra également avoir la capacité de regarder un moment contrôlé.
Si le problème est que vous n'avez pas d'environnements de production en miroir ou aucun moyen de mettre une copie des données de production quelque part pour vos développeurs, alors c'est une question quelque peu différente. Dans ce cas, vos développeurs ont vraiment besoin d'au moins un environnement miroir. Si vous ne voyez pas quel est le problème dans les données, il est difficile de le résoudre.
Non.
Les développeurs ne devraient pas ont accès aux systèmes de base de données de production pour les raisons suivantes:
Disponibilité et performances : Avoir des droits en lecture seule sur une base de données est pas inoffensif. Une requête mal écrite peut:
- Verrouillez les tables, bloquant d'autres processus critiques.
- Trash votre cache de données, forçant d'autres processus à relire les données du disque.
- Taxez votre couche de stockage, impactant les autres services qui partagent ce stockage.
Sécurité : Votre base de données de production peut contenir des informations sensibles comme:
- hachage de mot de passe
- détails de facturation
- autres informations personnellement identifiables
Seuls ceux qui ont absolument besoin d'accéder à ces informations devraient l'avoir. Dans une entreprise bien organisée, les développeurs ne font pas partie de ces personnes. De plus, votre entreprise échouera à la conformité 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 d'être mis 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 cela vaut aussi pour les DBA! Ils pourraient le faire!" Exactement. Vous voulez aussi peu de superutilisateurs que possible de manière responsable.
Oui.
Les développeurs devraient ont accès aux systèmes de production.
Dans mon entreprise, nous avons quatre équipes qui s'occupent des bases de données de production. Elles sont:
- 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 s'assoient parfois avec les administrateurs ou les personnes de support et les aident à regarder quelque chose en direct.
- Administrateurs , qui déploient, surveillent et gèrent les bases de données en production.
- Supporter les personnes , qui enquêtent sur les problèmes de production sensibles au temps et fournissent des commentaires aux développeurs afin qu'ils puissent développer des correctifs.
- Les gens de Business Intelligence , qui extraient des données des bases de données de production en utilisant soit des copies régulièrement actualisées de ces bases de données, soit des extraits soigneusement écrits et QA-ed (généralement conçus par les administrateurs) ).
Il est approprié d'accorder à vos développeurs un accès à la production lorsque vous avez certaines lacunes dans ces autres groupes.
Par exemple:
- Vous n'avez pas d'équipe d'assistance. Qui saura où chercher pour déboguer ce problème de production sensible au facteur temps? Vos développeurs. Accordez-leur l'accès " casse le verre ".
- Vous n'avez pas d'équipe BI. Vos administrateurs n'ont rien à voir avec les rapports ou les extraits. Qui va dépanner le rapport que vos execs voient chaque matin? 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 entreprise ou une startup, 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.
Les performances seraient 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 écrite pourrait mettre l'environnement de production à genoux et potentiellement causer d'autres problèmes (comme les dépassements 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 par, ce qui signifie qu'il sera trié dans tempDB.
Le principe est le "moindre privilège" et le "besoin de savoir": les développeurs réussissent-ils ce test?
Surtout quand les auditeurs ou Sarbannes-Oxley viennent frapper.
Ensuite, ma prochaine hypothèse: les développeurs sont stupides. Donc, s'ils ont besoin de dire pour le support de 3e ligne, qui alors en a besoin? Les singes Web ne le font généralement pas, mais les types de base de données oui s'ils sont censés le prendre en charge.
Alors, l'accès est-il nécessaire en permanence? Ils peuvent avoir un accès "bris de glace" en utilisant une connexion SQL ou un autre compte Windows qui nécessite une déconnexion. Dans notre cas, c'était le propriétaire des données (certains hommes d'affaires avertis, espérons-le) et le responsable informatique pour l'approuver.
Je ai vu des développeurs tester ou exécuter des requêtes sur la production et le retirer à cause de l'ignorance. Cela dit, les développeurs devraient assumer la responsabilité de leurs actions: s'ils arrêtent un serveur, ils devraient en souffrir. J'ai fait rétrograder quelqu'un après un incident ...
Ceux-ci supposent bien sûr un magasin de taille raisonnable. 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 ma dernière boutique, prod a été restauré chaque nuit sur un serveur de test pour fournir cela.
Je pense que la réponse est, comme pour beaucoup de choses informatiques, "ça dépend".
Une énorme base de données ERP avec de nombreuses informations sensibles sur l'entreprise et les clients? Probablement pas (à la fois pour des raisons de sécurité et de performances).
Une base de données ministérielle de 5 Mo avec un accès frontal qui suit les contributions aux fonds de beignets et de 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 ce sont des différences que vous devez savoir si vous êtes chargé de prendre ce type de décisions politiques. Mais d'un autre côté, il est étonnant de voir à quelle vitesse une base de données de 5 Mo de fonds de beignets et de pizzas peut se propager pour atteindre 50 Go de références/numéros de carte de crédit client/qui sait quoi? sinon base de données si vous le permettez.
Dans un environnement habituel 24/7 OLTP un développeur normal ne devrait pas être autorisé en production. Période! Si, de temps en temps, une raison particulière apparaît, des autorisations pourraient être accordées sur demande. Mais sur une base habituelle non.
J'ai vu plusieurs raisons à cela:
SELECT * à partir d'une grande table menant à:
- problèmes de performance (produits cartésiens);
- les problèmes de blocage qui ont finalement mis le site à genoux;
- chaîne de blocage qui a bloqué la réplication;
- commander un grand ensemble de données qui remplissait le lecteur TempDB qui .. devinez quoi? Causé une folie complète :-)!
- hypertension artérielle pour le DBA en charge de la production pour cette nuit;
lecture de données sensibles (un développeur ne devrait pas avoir accès aux informations de carte de crédit ... ni aux informations personnelles de l'utilisateur);
Je suis sûr qu'il y a encore plus de raisons.
- Sécurité: certaines informations sensibles peuvent être filtrées lorsqu'elles sont mises à la disposition des développeurs.
- Paranoïa: certains pourraient penser que vous pourriez encore gâcher des données avec simplement sélectionner l'accès.
- Performances: une requête nécessite des ressources pour être exécutée et vous ne pouvez pas me dire que vos développeurs sont parfaits lorsqu'ils écrivent du code.
Quelques éléments à considérer
- Les données sont-elles sensibles?
- Les programmeurs font-ils partie d'une équipe de confiance de base ou d'une équipe offshore?
- Quelle est l'échelle des données interrogées en termes d'impact sur les performances?
- Quelle est l'ampleur du projet ou les dollars impliqués?
- Quelle est l'importance de la disponibilité?
dollars plus petits nécessite moins de processus, nécessite un flux de développement plus rapide.
Bigger dollars nécessite plus de processus a besoin de 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 nos développeurs qui fourniront toute sorte de support (essentiellement tous) ont 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.
- 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 être en mesure de garder un œil approfondi sur les choses. Bien que ce soit bien d'avoir cette fonctionnalité sur notre tableau de bord, nous avons constaté que cela n'était pas pratique.)
- Nous avons besoin d'un accès en temps réel pour enquêter sur les échecs de production car les retards peuvent avoir un impact énorme. (Je ne vais pas discuter de nos échecs ici. Ils viennent de toutes sortes)
- Nous devons souvent 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. non idéal, bien sûr.)
- Nous devons vérifier les déploiements/correctifs DDL/DML de production. (Les administrateurs de base de données les déploient, mais nous seuls savons comment elle doit être structurée. Nous en savons plus sur notre structure de base de données que les administrateurs de base de données. Nous pouvons être étranges ici, mais notre base de données est très compliquée parce que notre entreprise est très compliquée.)
La performance est une préoccupation. Nous avons des occurrences de développeurs provoquant des ralentissements. Cependant, ce sont des instances isolées et notre SQL est tellement axé sur les performances qu'il est rare que nos développeurs ne comprennent pas l'impact de leurs requêtes.
Pour que cette question soit posée, il faut présumer qu’ils n’ont actuellement pas accès. Si une organisation développe un logiciel et que c'est pour 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 hors de production et de créer des environnements alternatifs créés pour leurs besoins de recherche. Une fois que le dentifrice est sorti du tube, il est difficile de le remettre en place.
Je conviens que la charge de la justification devrait incomber à ceux qui ont besoin d'accès. Généralement, dans des environnements où j'ai consulté, j'ai eu accès à des systèmes de production où c'était un petit environnement et j'étais la personne de support. J'ai eu accès à des sauvegardes, etc. où j'étais support pour le support, et un accès indirect (via un développeur de support dédié) aux données de production.
La grande chose est: vous avez besoin de cet accès lorsque vous êtes sur le crochet pour que tout fonctionne bien et que vous devez répondre à la question du gars des finances sur quelque chose qui ne fonctionne pas. Dans ce cas, vous ne pouvez pas toujours travailler à partir de données anciennes. D'un autre côté, plus il y a d'accès, pire c'est. Généralement, en tant que consultant, j'ai tendance à éviter d'avoir ce type d'accès à moins qu'il ne soit nécessaire. Étant donné que je travaille sur des bases de données financières, la dernière chose que je souhaite, c'est d'être accusé de saisir mes propres factures :-D.
D'un autre côté, si vous n'avez pas besoin d'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 prêt à s'assurer que cela 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 regarder les données que l'application du développeur stocke, vous ne devez pas engager le développeur pour écrire l'application. Il y a trop de façons dont le développeur pourrait obscurcir les données et les envoyer par courrier électronique et vous ne pouvez jamais en être sûr. Les contrôles MAC aident ici mais ils sont encore assez complexes à mettre en œuvre.
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'y ont pas accès. Si le développeur a un accès en lecture, vous vous demandez toujours s'il y a eu une attache d'escalade de privilèges qui peut donner un accès en écriture (peut-être une injection SQL de procédure stockée?). J'ai souvent eu un accès complet aux informations de facturation client lorsque j'ai eu accès à des environnements de transfert. S'il existe un environnement de mise en scène qui fonctionne, je demanderai généralement activement à d'avoir accès à la production, sauf si cela est nécessaire.
Ce n'est donc pas parfait, bien sûr. Un développeur pourrait toujours créer des portes dérobées 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 sur les environnements plus grands 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é assez bon pour mon travail et les seules fois où cela a échoué ont été lorsque les gars de la finance avaient besoin de pouvoir tester avec des données plus récentes afin de pouvoir comparer la production.
Ne pas y 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 de les afficher. Cela protège également les entreprises contre la violation de la loi (c'est-à-dire les violations de Hipaa et les problèmes de confidentialité)
Un développeur n'a jamais vraiment besoin d'accéder à un environnement de production, c'est simplement plus facile du point de vue des développeurs si un bug difficile ne peut pas être reproduit.
Cependant, un développeur peut placer des mini-vidages ou des fichiers journaux et utiliser les fichiers de symboles PDB pour recréer le bogue.
Si les données doivent être transférées dans un environnement de test, il est typique qu'un type de processus nettoie les données, ce qui peut créer un travail supplémentaire.
Selon le logiciel de base de données utilisé dans ce que vous appelez production, une nouvelle licence peut être requise pour que le développeur accède à la base de données, ce qui représente une dépense importante pour avoir simplement un accès en lecture.
Si votre entreprise ne vous fournit pas les outils 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 sont 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, provoquant un verrouillage excessif ou une utilisation 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 d'expérimenter.
Cela dépend du DBA et de la façon dont il ou elle est en confiance avec 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 devraient ne fonctionnent qu'avec les bases de données test/dev.
Le défi est que la plupart des applications logicielles sont pilotées par les données. Donc, lorsque vous essayez de résoudre un problème dans l'application, vous avez vraiment besoin de voir les données qui la motivent. Les développeurs ont donc vraiment besoin d'une forme d'accès.
L'utilisation des connexions SQL pour leur donner uniquement un accès en lecture seule aux tables est excellente. MAIS, qu'est-ce qui les empêche de créer une requête avec 20 jointures ou de faire SELECT * à partir d'une table avec des millions d'enregistrements? Ces requêtes peuvent accidentellement tuer les performances de votre base de données et de votre stockage.
Mon entreprise Stackify a trouvé 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 ne s'agit que 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.
Ce n'est qu'une des choses que nous proposons. Consultez-nous sur http://www.Stackify.com pour en savoir plus sur nos solutions support DevOps .
Oui. Dans certains cas, il est logique d'autoriser un sous-ensemble d'utilisateurs, y compris les développeurs, un certain niveau d'accès aux données de production de requête. Cependant, les limitations appropriées doivent être en place pour deux raisons. Tout d'abord, en tant que DBA, 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 involontaires comme les suppressions massives ou les vilolations de règles métier. Il va sans dire 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 sur les tables de base de données, il peut être judicieux d'autoriser les requêtes sur les vues et les procédures stockées. À l'aide des autorisations de base de données, vous pouvez empêcher les requêtes SELECT contre les tables directement 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 mise en œuvre.
Dans notre entreprise, nous maintenons des esclaves en lecture seule des bases de données de production qui ne sont pas utilisées par les services de production. Nous accordons aux développeurs l'accès à ceux-ci pour accéder 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 conservons 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 nuisibles dans le cas d'un environnement de production. Il augmente la charge et, aux heures de pointe, peut réduire l'ensemble des performances.
Toutes les informations dont ils ont besoin doivent passer par le DBA qui peut exécuter ce qu'ils veulent (Sélectionner) et leur envoyer les résultats. C'est comme ça que nous faisons dans notre environnement.