¿Cómo limita el acceso al entorno de producción en la empresa para la que trabaja?

En la empresa para la que trabajo, los ingenieros de devops (actualmente solo 2 miembros, que son yo y otro compañero de trabajo) son las únicas personas que tienen acceso a la base de datos de producción.

Entonces, cuando cualquier otro desarrollador necesita ejecutar una consulta MySQL en la base de datos de producción. Enviarían la consulta a los 2 ingenieros para que pudieran ejecutarla.

Estas son las situaciones en las que necesitamos ejecutar comandos en la base de datos de producción:

1. La base de datos contiene datos corruptos, que producen errores. Ejecutan comandos para corregir los errores.

2. Se informa un error. Y quieren ver los valores actuales dentro de la base de datos.

3. Uno de nuestros clientes quiere modificar sus datos. Pero nuestra aplicación web no tiene la capacidad de hacer la modificación. Por lo tanto, tenemos que enviar comandos MySQL directamente a la base de datos para completar los requisitos del cliente.

4. El equipo de control de calidad creó cuentas de prueba en el entorno de producción. Y quieren cambiar el estado de la cuenta para poder hacer otras pruebas.

Esto crea muchas interrupciones para mí, el otro compañero de trabajo. Cuando desarrollamos programas durante el día, a menudo tenemos que cambiar el contexto solo para ejecutar algunas consultas.

No creo que esta sea una buena arquitectura para la empresa. ¿Cómo controla los permisos para el entorno de producción en su empresa?

Nuestra base de datos de producción consta de información confidencial del cliente. Si se filtraran los datos, nuestra empresa podría ser multada por millones de dólares.

Si su pregunta es cómo administrar los cambios en la base de datos, considere algo como Flyway . Esto le permite controlar sus cambios a través de archivos de configuración rastreados en su repositorio y aplicarlos a través de un proceso automatizado y controlado; use sus pasos normales de revisión de código y promoción.

Si la pregunta es "¿cómo puedo hacer que los desarrolladores dejen de molestarme para ejecutar comandos SQL arbitrarios", entonces es posible que desee considerar la creación de scripts para automatizarlo o darles una interfaz de usuario de terceros para usar con una cuenta que está bloqueada para evitar los cambia y les impide ver tablas sensibles. YMMV dependiendo del diseño de su base de datos.

Puede incorporar el esquema de la base de datos y los cambios de datos en el control del código fuente utilizando un concepto llamado migraciones de bases de datos. Estos se pueden ejecutar en entornos de desarrollo y preparación como parte de un proceso de implementación parcialmente automatizado.

Por ejemplo, en mi entorno (aplicación web PHP), estoy usando Doctrine Schema para actualizaciones de esquemas, migraciones Yii2 para cambios de datos. Los comandos respectivos son parte de un script bash de 7 líneas que ejecuta todos los comandos necesarios para implementar un cambio en cada entorno

Veo un primer problema, DevOps se trata de crear equipos capaces de manejar una aplicación desde la compilación hasta la explotación.
Por lo tanto, sus desarrolladores deben tener acceso a las bases de datos, citó varios casos que son la realidad para muchas personas y el mayor inconveniente que los está poniendo a usted y a su colega en un cuello de botella, además de impedir su propio trabajo.

Otras respuestas abordan bien el cambio de esquema o el cambio planificado que, de hecho, debería integrarse como parte del proceso de entrega de la aplicación, pero no permiten corregir rápidamente la necesidad de acceso en vivo, cuando un desarrollador puede tener que volcar la base de datos para comprender qué causó el error y cómo solucionarlo por ejemplo.

Cosas como ProxySQL que ya citó en un comentario podrían estar bien para las bases de datos MySQL, solo configurar MySQL para registrar cosas también podría ser un buen enfoque, MySQL ofrece un complemento de auditoría comercial que puede resolver el problema de permitir que sus desarrolladores accedan a la base de datos y cumplan con su Requisitos de CISO para realizar un seguimiento de lo que se hace.

Si tiene más que solo Mysql DB y necesita auditar su acceso, configurar cada sistema para auditar las acciones de los usuarios de registro y no las acciones de la aplicación podría ser engorroso. Mantener las cosas cerradas podría ser aún peor, un desarrollador algún día integrará un shell DB en una aplicación para sortear este obstáculo y eventualmente se activará en producción sin el control de acceso adecuado y expondrá todos los datos, le recomiendo encarecidamente que pregunte a su empresa para revisar esta política.

Sé que hay una solución comercial que puede ayudar (y permitir auditar más que solo solicitudes de DB) que es strongDM , también permite auditar sesiones ssh y rdp, ya que si sus desarrolladores necesitan acceso a DB, probablemente también necesiten acceso a la máquinas que alojan las aplicaciones con fines de depuración.

... yo y otro compañero de trabajo ... somos las únicas personas que tienen acceso a la base de datos de producción.

Esa es una buena posición inicial.
Con demasiada frecuencia, los DBA se encuentran tratando de cerrar la puerta del establo después de que el caballo se haya escapado.

Entonces, cuando cualquier otro desarrollador necesita ejecutar una consulta MySQL en la base de datos de producción ...

Pregunta:
¿Por qué los desarrolladores ejecutan algo contra la base de datos de producción?

¿Cómo controla los permisos para el entorno de producción en su empresa?

Control de acceso basado en roles.

Los usuarios tienen acceso a cada base de datos cuando lo requiera su rol de trabajo y los roles se utilizan para darles acceso a las tablas dentro de cada base de datos. El proceso mediante el cual se crean estas cuentas y se otorgan los roles se gestiona de forma centralizada y se audita estrictamente.

Los desarrolladores nunca deberían tener acceso "práctico" a actualizaciones fuera de sus bases de datos de desarrollo. Todo lo demás debe ser programado, probado, auditado y publicado a través de canales pre-preparados, controlados (y, preferiblemente, automatizados).