Como posso impedir o carregamento acidental de um banco de dados de produção?

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

Idealmente, eu os teria em caixas totalmente separadas, mas isso é proibitivo em termos de custos e, estritamente falando, não impede que a mesma coisa aconteça se o usuário se conectar à caixa errada.

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

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

Se isso é algo que você se vê fazendo com frequência, automatize-o. E como vocês são desenvolvedores, escrever algum código deve estar na sua casa do leme. :) Mas falando sério ... ao automatizá-lo, você pode fazer coisas como:

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

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

Discordo do pressuposto da pergunta - isso é segurança -, mas também discordo que a automação salvará o dia por si própria. Vou começar com o problema:

Você não deve poder acidentalmente fazer nada na 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 dev. Se eles podem ler / gravar a produção, eles podem ser invadidos e explorados para roubar dados do cliente ou (como você demonstrou) podem ser manipulados incorretamente para perder dados do cliente.

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

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

• Os usuários de backup só devem poder ler da produção e gravar no seu armazenamento de backup (que deve ser adequadamente protegido).

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

  O acesso à 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 implementações fora do horário comercial, produzidas após uma análise cuidadosa. Um pequeno inconveniente não vai te matar.

Automação é parte da solução.

Não estou cego para o fato de que a recuperação total (upload para VCS, verificação de cobertura, extração para servidor de teste, execução de testes automatizados, nova autenticação, criação de backup e extração de VCS) é um processo longo.

É aí que 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 determinadas tarefas. Apenas certifique-se de não facilitar demais coisas estúpidas. Suas etapas de nova autenticação ainda devem ser pronunciadas (e, se perigosas), devem ser inconvenientes e difíceis de executar sem pensar.

Mas , sozinha , a automação é pior que inútil. Isso apenas o ajudará a cometer erros maiores com menos reflexão.

Adequado para equipes de todos os tamanhos.

Percebi você apontando o tamanho da sua equipe. Eu sou um cara e me envolvi nisso porque é preciso apenas uma pessoa para 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.

Um dos meus colegas de trabalho tem uma abordagem interessante para isso. Seu esquema de cores terminal para produção é imprudente . Cinza, rosa e difícil de ler, o que teoricamente deveria garantir que, o que quer que ele escreva, ele realmente pretenda escrever.

Sua milhagem pode variar ... e eu provavelmente não tenho que dizer que não é à prova de balas. :)

Os desenvolvedores não devem saber a senha do banco de dados de produção. A senha do prod deve ser aleatória e não memorável - algo como o resultado do esmagamento do teclado ( Z^kC83N*(#$Hx). Sua senha do desenvolvedor pode ser $YourDog'sNameou correct horse battery stapleou o que for.

Claro, você pode descobrir qual é a senha, especialmente se você é uma equipe pequena, olhando para 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 prod.

(Como sempre, você deve ter backups pontuais para o banco de dados de produção. Por exemplo, no MySQL, arquive os logs binários como backups incrementais. No PostgreSQL, arquive os logs write-ahead. Essa é a sua proteção de último recurso para qualquer tipo de desastre, auto-infligido ou não.)

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

Suas permissões para todos os ambientes precisam ser diferentes - e, por mais irritantes que sejam as coisas como UAC, você precisa delas: especialmente para ambientes PROD.

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

Isso é chato? Absolutamente. Mas isso [ajuda] a impedir que os ambientes sejam prejudicados? Absolutamente.

Uma solução rápida e simples: use duas contas de usuário diferentes, uma para o seu trabalho normal de desenvolvimento, que tem apenas acesso ao banco de dados de desenvolvimento, e outra para realmente operar 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 sem acesso de gravação ) à produção, outra conta de usuário para trabalhar no sistema de produção ( s)

Essa é a mesma abordagem que um administrador de sistemas que possui uma conta padrão de não administrador para o trabalho de rotina (leitura de email, navegação na web, tickets de rastreamento, folhas de ponto de arquivamento, documentação de redação etc.) e uma conta de administrador completo distinta a ser usada quando realmente estiver em operação em servidores e / ou no Active Directory.