Como posso evitar o acúmulo acidental de um banco de dados de produção?

Question

Recentemente, um desenvolvedor tentou acidentalmente restaurar um banco de dados para produção, quando deveria estar restaurando para uma cópia de teste. É fácil de fazer, já que os nomes do banco de dados são semelhantes, ou seja, CustomerName_Staging versus CustomerName_Production.

O ideal seria tê-las em caixas totalmente separadas, mas isso tem um custo proibitivo e, estritamente falando, não impede que a mesma coisa aconteça se o usuário se conectar à caixa errada.

Este não é um problema de segurança, por si só - era o usuário correto que trabalhava com o banco de dados de preparo e, se há trabalho a ser feito no banco de dados de produção, também seria ele. Eu adoraria ter um oficial de implantação para separar essas preocupações, mas a equipe não é grande o suficiente para isso.

Adoraria ouvir alguns conselhos em termos de prática, configuração e controles sobre como evitar isso.

    

Answer 1

Se isso é algo que você se vê fazendo frequentemente, automatize-o. E como vocês dois são desenvolvedores, escrever algum código deve estar em sua casa do leme. :) Falando sério ... automatizando, você pode fazer coisas como:

• Verifique se você está restaurando no servidor correto (ou seja, sem dev - > prod restaura)
• Verifique se é o "tipo" correto de banco de dados (no seu caso, "teste" e "produção")
• Descobrir quais backup (s) serão restaurados automaticamente observando as tabelas de backup em msdb

Et cetera. Você está limitado apenas pela sua imaginação.

    

Answer 2

Eu discordo da suposição da questão - é é segurança - mas eu também discordo que a automação vai salvar o dia por conta própria. Vou começar com o problema:

Você não deve ser capaz de fazer acidentalmente qualquer coisa para produção!

Isso inclui fazer coisas automatizadas acidentalmente.

Você está confundindo a segurança do sistema com conceitos como "quem tem permissão para fazer o quê". Suas contas de desenvolvimento só devem poder gravar em suas cópias, no servidor de controle de versão e no banco de dados de desenvolvimento. Se eles puderem ler / gravar produção, eles podem ser hackeados e explorados para roubar dados de clientes ou (como você demonstrou) podem ser mal-interpretados para perder dados de clientes.

Você precisa começar classificando seu fluxo de trabalho.

• Suas contas de desenvolvedor devem poder gravar em suas próprias cópias, controlar a versão e talvez puxar do controle de versão para um ambiente de teste.

• Os usuários de backup só devem conseguir ler a partir da produção e gravar em seu repositório de backup (que deve estar protegido adequadamente).

• Qualquer outra leitura / gravação em produção deve exigir uma autenticação especial e inconveniente . Você não deve poder entrar nele ou esquecer que está logado. O controle de acesso físico é útil aqui. Cartões inteligentes, flip-switches para "armar" a conta, acesso de chave dupla com giro simultâneo.

  Acessar a produção não deve ser algo que você precisa fazer todos os dias. A maior parte do trabalho deve estar em sua plataforma de testes e em implantações fora do expediente feitas na produção após um exame minucioso. Um pequeno inconveniente não vai te matar.

A automação é parte da solução.

Eu não estou cego para o fato de que o retorno completo (upload para VCS, verificação de cobertura, puxando para testar servidor, executando testes automatizados, reautenticação, criando um backup, puxando de VCS) é um processo longo.

Isso onde a automação pode ajudar, de acordo com a resposta de Ben. Existem muitas linguagens de script diferentes que facilitam muito a execução de certas tarefas. Apenas certifique-se de não tornar isso muito fácil de fazer coisas estúpidas. Suas etapas de reautenticação ainda devem ser pronunciadas (e, se forem perigosas), elas devem ser inconvenientes e difíceis de fazer sem pensar.

Mas sozinho , a automação é pior do que inútil. Isso apenas ajudará você a cometer maiores erros com menos pensamento.

Adequado para equipes de todos os tamanhos.

Notei que você aponta o tamanho do seu time. Eu sou um cara e me coloco nisso porque só leva uma pessoa a sofrer um acidente. Há uma sobrecarga mas vale a pena. Você acaba com um ambiente de desenvolvimento e produção muito mais seguro e muito mais seguro.

    

Answer 3

Um dos meus colegas de trabalho tem uma abordagem interessante para isso. Seu esquema de cores de terminal para produção é fugly . Cinza, rosa e difícil de ler, teoricamente supostamente para garantir que, seja lá o que ele escreve, ele realmente pretendia escrever.

Sua milhagem pode variar ... e eu provavelmente não tenho que dizer que dificilmente é à prova de balas por conta própria. :)

    

Answer 4

Os desenvolvedores não devem saber a senha para o banco de dados de produção. A senha prod deve ser aleatória e não memorável - algo como o resultado do esmagamento de teclado ( Z^kC83N*(#$Hx ). Sua senha dev pode ser $YourDog'sName ou correct horse battery staple ou qualquer outra coisa.

Claro, você pode descobrir qual é a senha, especialmente se for uma equipe pequena, observando o arquivo de configuração do aplicativo cliente. Esse é o único lugar onde a senha do prod deve existir. Isso garante que você teria que fazer um esforço deliberado para obter a senha do produto.

(Como sempre, você deve ter backups point-in-time para o seu banco de dados de produção. Por exemplo, com o MySQL, arquive os logs binários como backups incrementais. Para o PostgreSQL, arquive os logs write-ahead. último recurso para qualquer tipo de desastre, auto-infligido ou de outra forma.)

    

Answer 5

A resposta curta é RBAC - controle de acesso baseado em função.

Suas permissões para todos os ambientes precisam ser diferentes - e tão irritantes quanto coisas como UAC, você precisa delas: especialmente para ambientes PROD.

Não existe NUNCA um motivo para os desenvolvedores terem acesso direto ao Prod - independentemente de quão pequena seja a organização / equipe. Seu "Dev" também pode usar os bonés "Stage" e "Prod", mas ele precisa ter credenciais e processos diferentes para atingir diferentes ambientes.

É chato? Absolutamente. Mas isso [ajuda] impede que você borking seus ambientes? Absolutamente.

    

Answer 6

Uma solução rápida e simples: use duas contas de usuário diferentes, uma para seu trabalho de desenvolvimento normal que tenha acesso apenas ao banco de dados de desenvolvimento e outra diferente para o funcionamento real no banco de dados de produção, com acesso total a ele. Dessa forma, você terá que alterar ativamente a conta que está usando antes de fazer qualquer alteração na produção, o que deve ser suficiente para evitar erros acidentais.

A mesma abordagem pode ser usada se você tiver dois sites, dois servidores ou dois ambientes inteiros: uma conta de usuário para desenvolvimento sem acesso (ou pelo menos nenhum acesso write ) à produção, outra conta de usuário para trabalhar no (s) sistema (s) de produção.

Esta é a mesma abordagem de um administrador de sistema que possui uma conta não administrativa padrão para trabalhos de rotina (leitura de e-mail, navegação na Web, registro de tickets, planilhas de horas, documentação de documentos etc.) e uma conta distinta para ser usada. quando estiver operando em servidores e / ou no Active Directory.