Protegendo dados confidenciais de desenvolvedores

A segurança não é uma varinha mágica que você pode acenar no final de um projeto, ela precisa ser considerada e incorporada a partir do primeiro dia. Não é um parafuso, é a aplicação consistente de uma variedade de soluções aplicadas iterativamente e revisado regularmente como parte de um sistema completo, que é tão strong quanto o elo mais fraco.

Como está, você sinalizou uma preocupação de segurança, que é um bom primeiro passo. Agora, no mínimo, você precisa definir: -

• Quais dados você está tentando proteger?
• De quem você está tentando proteger esses dados?
• Quem realmente precisa de acesso a quê (e quando)?
• Qual é o impacto legal / financeiro / comercial desses dados que estão sendo comprometidos?
• Qual é a necessidade legal / financeira / comercial de uma pessoa / grupo ter acesso aos dados?
• Qual orçamento o negócio deseja atribuir a uma estratégia "fique seguro, fique seguro" quando não era um requisito comercial anteriormente?
• Qual acesso o sistema precisa para os dados?
• Em que esse processo e sistemas esse aplicativo depende?
• O que é feito para proteger esses ambientes?
• Quem será responsável por implementá-lo e revisar todo o processo?

Até você conhecer todos em detalhes, você realmente não tem nada com o que trabalhar. Essas informações definirão quais mitigações para essas ameaças você pode (e não pode) aplicar e por quê.

Pode ser que a melhor coisa a fazer seja reconhecer que você não tem a experiência necessária e que seria melhor trazer alguém novo com essa experiência. Muitas vezes ouço a resposta de que não há orçamento - se for considerado realmente importante, então o orçamento será encontrado.

Você está certo. Se um aplicativo for capaz de acessar o conteúdo armazenado em máquinas corporativas, sem que o usuário passe informações extras a cada vez, os programadores, mantenedores, administradores de sistema etc. do provedor de serviços poderão acessar esse conteúdo. Isso é fundamentalmente inevitável e uma fonte importante de insegurança (Edward Snowden era um administrador de sistema e tinha privilégios especiais acima de "Top Secret", porque simplesmente não existe uma maneira de não concedê-los).

A única maneira de evitar isso é exigir que o usuário forneça informações que nunca chegam às máquinas corporativas. Isso é tedioso e propenso a erros, já que ninguém pode se lembrar de informações suficientes para formar uma barreira de acesso seguro e, portanto, as pessoas começarão imediatamente a armazenar suas credenciais eletronicamente em algum lugar, que se tornará o novo alvo de ataque (e provavelmente um alvo mais fraco do que aquele que você está mantendo). Mas se você quiser afirmar com sinceridade "Nossos funcionários não são fisicamente capazes de acessar o conteúdo de nossos usuários", é o único caminho.

(Observe também que tal modelo de negócios parece estar se tornando politicamente insustentável. As empresas foram forçadas a deixar de operar pelos serviços de segurança por tentarem fazer exatamente isso. Entendo que dar garantias de privacidade tem valor comercial, mas não pode possivelmente ter mais valor comercial do que o objetivo fundamental de permanecer no negócio.)

Você está certo; alguns desenvolvedores sempre precisarão acessar os dados do Live, apenas para diagnosticar problemas de produção. O melhor que você pode fazer é limitar o dano potencial reduzindo o número de pessoas envolvidas.

With great power comes great ... opportunity to really, *really* foul things up. 

Muitos desenvolvedores não vão querer essa responsabilidade e outros, apenas não estarão "prontos" para segurá-la, e não devem.

Pergunta: Por que sua equipe Desenvolvimento está executando versões ao vivo ?
Gostaria de sugerir que você precisa de uma "equipe" de gerenciamento de versões (mesmo que seja apenas um subconjunto de sua equipe, além de uma representação comercial para tomar decisões "diárias", como "Ir / Não-Ir")? Isso removeria muito da "necessidade" dos desenvolvedores de tocar em qualquer coisa ao vivo.

Você tem algum tipo de acordo de não divulgação / confidencialidade entre desenvolvedores e empresa? É pesado, mas pode ter algum mérito.

O problema é seus desenvolvedores terem acesso aos sistemas. Se eles precisarem de dados de produção para depuração, forneça a eles um dump de banco de dados em que todas essas informações confidenciais sejam removidas. Então os desenvolvedores podem trabalhar com esse despejo.

A implantação de uma nova versão não deve envolver nenhum desenvolvedor - uma tarefa de administração pura ou, melhor ainda, uma tarefa totalmente automatizada. Esteja ciente também de liberar e implantar, sendo duas tarefas muito diferentes. Se o seu processo não estiver ciente disso, altere-o de acordo.

Regra nº 1 de segurança: se alguém tiver acesso a informações, elas terão acesso a essas informações

Essa tautologia é irritante, mas é verdade. Se você der acesso a um indivíduo, ele terá acesso aos dados. Para os usuários, isso geralmente significa controle de acesso, mas para desenvolvedores ... bem ... eles são os que têm que escrever o controle de acesso.

Se este é um grande problema para você (e parece que é), considere a criação de segurança em seu software. Um padrão comum é projetar software seguro em camadas. Na camada mais baixa, uma equipe de desenvolvimento confiável cria um software que gerencia o mais desnudo controle de acesso. Esse software é validado e verificado pelo maior número de pessoas possível. Qualquer pessoa que crie esse código tem acesso a tudo, então a confiança é essencial.

Depois disso, os desenvolvedores podem criar um controle de acesso mais flexível sobre essa camada principal. Este código ainda tem que ser V & Vd, mas não é tão rigoroso, porque você pode sempre confiar na camada principal para cobrir o essencial.

O padrão se estende para fora.

A parte difícil, de fato, a arte de projetar esses sistemas, é como construir cada camada para que os desenvolvedores continuem a desenvolver e depurar enquanto ainda fornecem à sua empresa a segurança que você espera. Em particular, você precisará aceitar que a depuração demanda mais privilégios do que você acha que deveria, e tentar bloquear isso resultará em desenvolvedores muito irritados.

Como uma solução secundária, considere criar bancos de dados "seguros" para fins de teste, onde os desenvolvedores podem extrair todos os mecanismos de segurança e fazer depurações sérias.

No final, você e seus desenvolvedores precisam entender um princípio importante de segurança: Toda segurança é um equilíbrio entre segurança e usabilidade. Você deve atacar por conta própria equilíbrio como empresa. O sistema não estará perfeitamente seguro e não será perfeitamente utilizável. Esse equilíbrio provavelmente irá se mover à medida que sua empresa crescer e / ou exigir mudanças nos desenvolvedores. Se você está aberto a essa realidade, você pode resolver isso.

Configure duas implantações do aplicativo que também usam implantações de banco de dados separadas. Uma é a implantação de produção e uma é a implantação de teste.

A implantação de teste deve ter apenas dados de teste. Isso pode ser um dado fantasioso criado para esse propósito ou uma cópia dos dados de produção que foi anonimizada para impedir que os desenvolvedores descubram as pessoas e entidades reais por trás dos dados.

Em duas empresas financeiras, os desenvolvedores não tinham acesso a máquinas de produção. Todas as solicitações para modificar máquinas de produção tiveram que passar por um processo de aprovação, com um script, e foram aprovadas pelos gerentes. A equipe de desenvolvedores concluiu as implantações reais. Eu assumo que esta equipe era apenas funcionários e passei por verificações de antecedentes. Eles também não tinham conhecimento do desenvolvedor, então provavelmente não poderiam bisbilhotar se quisessem. Além disso, você criptografaria todas as entradas do banco de dados usando uma chave secreta armazenada nas variáveis de ambiente. Mesmo se os bancos de dados vazassem publicamente, ninguém poderia lê-lo. Essa chave pode ser mais protegida por senha (PBKDF) para que apenas um executivo possa desbloqueá-la. Seu sistema pode exigir a senha executiva na inicialização (ou, mais provavelmente, delegada a dev-ops ou a um gerenciador de desenvolvimento). Basicamente, a estratégia é dispersar o conhecimento, de modo que uma massa crítica de conhecimento requerido não existe em uma pessoa e existem verificações e equilíbrios. É assim que a Coca-Cola protege sua fórmula. Honestamente, algumas dessas respostas são desculpas.

O MongoDB tem controles de segurança limitados e depende de um ambiente seguro. Ligar a um ip e porta específicos (e ssl desde 2.2), e uma autenticação bruta, é o que oferece. MYSQL adiciona GRANT o ON db.t TO ... Os dados em repouso não são criptografados e o ssl não é usado por padrão. Crie uma cerca. O acesso somente leitura para desenvolvedores aos arquivos de log relacionados ao aplicativo deve ser suficiente para depurar. Automatize o ciclo de vida da aplicação.

O Ansible nos ajudou a automatizar as operações padrão (implantar, atualizar, restaurar) em muitos ambientes com um único segmentador ao usar armazenamentos criptografados distintos para armazenar variáveis de ambiente sensíveis, como hosts, portas e credenciais. Se cada cofre só puder ser descriptografado por diferentes funções, e apenas em um host de bastiões, para operações registradas, a auditoria fornecerá segurança aceitável. Se você concede o SSH, use o selinux para evitar adulterações de chaves, use um host de bastiões com autenticação ldap / kerberos para administração e use o sudo com sabedoria.