Comment limiter l'accès à l'environnement de production dans l'entreprise pour laquelle vous travaillez?

Dans l'entreprise pour laquelle je travaille, les ingénieurs devops (actuellement seulement 2 membres, qui sont moi et un autre collègue) sont les seules personnes qui ont accès à la base de données de production.

Ainsi, lorsque d'autres développeurs doivent exécuter une requête MySQL sur la base de données de production. Ils enverraient la requête aux 2 ingénieurs pour les laisser l'exécuter.

Voici les situations où nous devons exécuter des commandes dans la base de données de production:

1. La base de données contient des données corrompues, qui produisent des bogues. Ils exécutent des commandes pour corriger les bugs.

2. Un bug est signalé. Et ils veulent voir les valeurs actuelles dans la base de données.

3. Un de nos clients souhaite modifier ses données. Mais notre application Web n'a pas la possibilité de faire la modification. Nous devons donc envoyer des commandes MySQL directement à la base de données pour répondre aux exigences du client.

4. L'équipe QA a créé des comptes de test sur l'environnement de production. Et ils veulent changer le statut du compte pour pouvoir faire d'autres tests.

Cela crée beaucoup d'interruptions pour moi l'autre collègue. Lorsque nous développons des programmes pendant la journée, nous devons souvent changer de contexte juste pour exécuter certaines requêtes.

Je ne pense pas que ce soit une bonne architecture pour l'entreprise. Comment contrôlez-vous les autorisations d'accès à l'environnement de production dans votre entreprise?

Notre base de données de production se compose d'informations sensibles sur les clients. Si les données étaient divulguées, notre entreprise pourrait être condamnée à une amende de plusieurs millions de dollars.

Si votre question est de savoir comment gérer les modifications de la base de données, envisagez quelque chose comme Flyway . Cela vous permet de contrôler vos modifications via des fichiers de configuration suivis dans votre référentiel et de les appliquer via un processus automatisé et contrôlé - utilisez vos étapes normales de révision et de promotion du code.

Si la question est "comment puis-je faire en sorte que les développeurs cessent de m'embêter pour exécuter des commandes SQL arbitraires", alors vous voudrez peut-être envisager de créer un script pour l'automatiser ou de leur donner une interface utilisateur tierce à utiliser avec un compte verrouillé pour empêcher les modifie et les empêche de voir les tables sensibles. YMMV selon la disposition de votre DB.

Vous pouvez intégrer le schéma de base de données et les modifications de données dans le contrôle du code source en utilisant un concept appelé migrations de base de données. Ceux-ci peuvent ensuite être exécutés sur des environnements de développement et de transfert dans le cadre d'un processus de déploiement partiellement automatisé.

Par exemple dans mon environnement (application Web PHP), j'utilise Doctrine Schema pour les mises à jour de schéma, les migrations Yii2 pour les changements de données. Les commandes respectives font partie d'un script bash de 7 lignes qui exécute toutes les commandes nécessaires pour déployer un changement dans chaque environnement

Je vois un premier problème, DevOps concerne la constitution d'équipes capables de gérer une application de la génération à l'exploitation.
Donc, vos développeurs devraient avoir accès aux bases de données, vous avez cité divers cas qui sont la réalité pour beaucoup de gens et l'inconvénient majeur qui vous met, vous et votre collègue, dans un goulot d'étranglement et gêne votre propre travail.

D'autres réponses répondent bien au changement de schéma ou au changement planifié qui devraient en effet être intégrés dans le cadre du processus de livraison de l'application, mais elles ne permettent pas de résoudre rapidement le besoin d'accès en direct, lorsqu'un développeur peut avoir besoin de vider la base de données pour comprendre la cause. le bug et comment le corriger par exemple.

Des choses comme ProxySQL que vous avez déjà citées dans un commentaire pourraient être correctes pour les bases de données MySQL, juste configurer MySQL pour enregistrer les choses pourrait également être une bonne approche, MySQL propose un plugin d'audit commercial qui peut répondre au problème de laisser vos développeurs accéder à la base de données et remplir votre Les exigences du CISO pour garder une trace de ce qui est fait.

Si vous avez plus qu'une base de données Mysql et que vous devez auditer leur accès, la configuration de chaque système pour auditer les actions des utilisateurs du journal et non les actions des applications peut être fastidieuse. Garder les choses fermées pourrait être encore pire, un développeur intégrera un jour un shell DB dans une application pour contourner ce barrage routier et il finira par entrer en production sans contrôle d'accès approprié et exposer toutes les données, je vous conseille fortement de demander à votre pour revoir cette politique.

Il y a une solution commerciale que je connais qui peut aider (et permettre l'audit plus que les requêtes DB) qui est strongDM , elle permet également d'auditer les sessions ssh et rdp, comme si vos développeurs ont besoin d'accéder à DB, ils ont probablement aussi besoin d'accéder à la machines hébergeant les applications à des fins de débogage.

... moi et un autre collègue ... sommes les seules personnes qui ont accès à la base de données de production.

C'est une bonne position de départ.
Trop souvent, les DBA essaient de fermer la porte de l'écurie après que le cheval s'est enfui.

Ainsi, lorsque d'autres développeurs doivent exécuter une requête MySQL sur la base de données de production ...

Question:
Pourquoi les développeurs exécutent-ils quelque chose contre la base de données de production?

Comment contrôlez-vous les autorisations d'accès à l'environnement de production dans votre entreprise?

Contrôle d'accès basé sur les rôles.

Les utilisateurs ont accès à chaque base de données au fur et à mesure que leur rôle l'exige et les rôles sont utilisés pour leur donner accès aux tables de chaque base de données. Le processus par lequel ces comptes sont créés et les rôles attribués est géré de manière centralisée et strictement audité.

Les développeurs ne devraient jamais avoir un accès "pratique" à la mise à jour en dehors de leurs bases de données de développement. Tout le reste doit être scénarisé, testé, audité et publié via des canaux pré-préparés, contrôlés (et, de préférence, automatisés).