Como você limita o acesso ao ambiente de produção na empresa em que trabalha?

Na empresa em que trabalho, os engenheiros de devops (atualmente apenas 2 membros, eu e outro colega de trabalho) são as únicas pessoas que têm acesso ao banco de dados de produção.

Portanto, quando qualquer outro desenvolvedor precisar executar uma consulta MySQL no banco de dados de produção. Eles enviavam a consulta aos 2 engenheiros para permitir que eles a executassem.

Aqui estão as situações em que precisamos executar comandos no banco de dados de produção:

1. O banco de dados contém dados corrompidos, que produzem bugs. Eles executam comandos para corrigir os erros.

2. Um bug é relatado. E eles querem ver os valores atuais dentro do banco de dados.

3. Um de nossos clientes deseja modificar seus dados. Mas nosso aplicativo da web não tem a capacidade de fazer a modificação. Portanto, temos que enviar comandos do MySQL diretamente para o banco de dados para concluir os requisitos do cliente.

4. A equipe de controle de qualidade criou contas de teste no ambiente de produção. E eles querem alterar o status da conta para que possam fazer outros testes.

Isso cria muitas interrupções para mim, o outro colega de trabalho. Quando desenvolvemos programas durante o dia, geralmente precisamos mudar o contexto apenas para executar algumas consultas.

Não acho que essa seja uma boa arquitetura para a empresa. Como você controla as permissões para o ambiente de produção em sua empresa?

Nosso banco de dados de produção consiste em informações confidenciais do cliente. Se os dados vazarem, nossa empresa poderá ser multada em milhões de dólares.

Se sua pergunta é sobre como gerenciar alterações no banco de dados, considere algo como Flyway . Isso permite que você controle suas alterações por meio de arquivos de configuração rastreados em seu repositório e os aplique por meio de um processo automatizado e controlado - use suas etapas normais de revisão e promoção de código.

Se a pergunta for "como faço para que os desenvolvedores parem de me incomodar para executar comandos SQL arbitrários", convém considerar o script como uma maneira de automatizá-lo ou fornecer a eles uma interface de usuário de terceiros para usar com uma conta bloqueada para evitar altera e restringe a visualização de tabelas sensíveis. YMMV, dependendo do layout do seu banco de dados.

Você pode incorporar alterações de esquema e dados do banco de dados no controle do código-fonte usando um conceito chamado migrações de banco de dados. Em seguida, eles podem ser executados em ambientes de desenvolvimento e preparação como parte de um processo de implantação parcialmente automatizado.

Por exemplo, no meu ambiente (aplicativo da Web PHP), estou usando o Doctrine Schema para atualizações de esquema, migrações Yii2 para alterações de dados. Os respectivos comandos fazem parte de um script bash de 7 linhas que executa todos os comandos necessários para implantar uma alteração em cada ambiente

Vejo um primeiro problema: o DevOps trata da criação de equipes capazes de lidar com um aplicativo, da construção à exploração.
Portanto, seus desenvolvedores devem ter acesso aos bancos de dados, você citou vários casos que são a realidade para muitas pessoas e a principal desvantagem que está transformando você e seu colega em um gargalo, além de impedir seu próprio trabalho.

Outras respostas abordam bem a alteração do esquema ou a alteração planejada que deve ser realmente integrada como parte do processo de entrega do aplicativo, mas elas não permitem corrigir rapidamente a necessidade de acesso ao vivo, quando um desenvolvedor pode precisar despejar o banco de dados para entender o que causou o bug e como corrigi-lo por exemplo.

Coisas como o ProxySQL que você já citou em um comentário podem ser aceitáveis ​​para os bancos de dados MySQL, apenas configurar o MySQL para registrar as coisas pode ser uma boa abordagem também. O MySQL oferece um plug-in de auditoria comercial que pode responder ao problema de permitir que seus desenvolvedores acessem o banco de dados e atendam às suas necessidades. Requisitos CISO para acompanhar o que é feito.

Se você possui mais do que apenas o Mysql DB e precisa auditar seu acesso, configurar cada sistema para auditar as ações dos usuários de log e não as ações do aplicativo pode ser complicado. Manter as coisas fechadas pode ser ainda pior, um desenvolvedor um dia integrará um shell de banco de dados em um aplicativo para contornar esse bloqueio e, eventualmente, entrará em operação na produção sem controle de acesso adequado e expor todos os dados. empresa a rever esta política.

Eu sei que existe uma solução comercial que pode ajudar (e permitir auditar mais do que apenas solicitações de banco de dados) que é strongDM , também permite auditar sessões ssh e rdp, como se seus desenvolvedores precisassem acessar o banco de dados, provavelmente também precisariam acessar o banco de dados. máquinas que hospedam os aplicativos para fins de depuração.

... eu e outro colega de trabalho ... somos as únicas pessoas que têm acesso ao banco de dados de produção.

Essa é uma boa posição inicial.
Com muita frequência, os DBAs tentam fechar a porta do estábulo depois que o cavalo sai correndo.

Então, quando qualquer outro desenvolvedor precisar executar uma consulta MySQL no banco de dados de produção ...

Pergunta:
Por que os desenvolvedores estão executando alguma coisa no banco de dados de produção?

Como você controla as permissões para o ambiente de produção em sua empresa?

Controle de acesso baseado em função.

Os usuários recebem acesso a cada banco de dados quando e quando sua função exigir, e as Funções são usadas para fornecer acesso às tabelas em cada banco de dados. O processo pelo qual essas contas são criadas e as funções concedidas são gerenciadas centralmente e auditadas estritamente.

Os desenvolvedores nunca devem ter acesso prático à atualização fora de seus bancos de dados de desenvolvimento. Todo o resto deve ser roteirizado, testado, auditado e liberado através de canais pré-preparados, controlados (e, de preferência, automatizados).