Eu tenho um aplicativo corporativo em execução que usa armazenamentos de dados MySQL e MongoDB . Minha equipe de desenvolvimento tem acesso SSH à máquina para executar lançamentos, manutenção de aplicativos etc.
Recentemente, aumentei o risco nos negócios, quando os usuários começaram a armazenar dados altamente confidenciais no aplicativo, de que os desenvolvedores têm acesso indireto a esses dados, o que causou um pouco de tempestade. Por isso, agora fui encarregado de proteger os dados para que não sejam acessível.
Para mim, isso não parece possível, porque se o aplicativo tiver acesso ao banco de dados, um desenvolvedor com acesso à máquina e à fonte do aplicativo sempre poderá acessar os dados.
server-security
Clinton Bosch
fonte
fonte
Respostas:
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 dia 1. Não é um problema, é a aplicação consistente de uma variedade de soluções aplicadas iterativamente e revisadas regularmente como parte de um sistema inteiro, que é tão forte 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ê deve definir: -
Até você conhecer todos esses detalhes, você realmente não tem nada com o que trabalhar. Essas informações definirão quais atenuações para essas ameaças você pode (e não pode) aplicar e por quê.
Pode ser que a melhor coisa a fazer é reconhecer que você não tem a experiência necessária e que seria melhor trazer alguém novo com essa experiência. Frequentemente ouço a resposta de que não há orçamento - se for considerado genuinamente importante, o orçamento será encontrado.
fonte
make-application-securecomando mágico que elas só precisam executar.Você está certo. Se um aplicativo é capaz de acessar conteúdo armazenado em máquinas corporativas sem que o usuário passe informações extras todas as vezes , os programadores, mantenedores, administradores de sistemas etc. do provedor de serviços podem acessar esse conteúdo. Isso é fundamentalmente inevitável e uma das principais fontes de insegurança (Edward Snowden era um administrador de sistemas e tinha privilégios especiais acima de "Top Secret" porque simplesmente não há como 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 segura e, portanto, as pessoas imediatamente começarão a armazenar suas credenciais eletronicamente em algum lugar, que se tornará o novo alvo de ataque (e provavelmente um alvo mais fraco do que o que você está mantendo). Mas se você deseja afirmar com sinceridade "Nossos funcionários não são fisicamente capazes de acessar o conteúdo de nossos usuários", é a única maneira.
(Observe também que esse modelo de negócios parece estar se tornando politicamente insustentável. As empresas foram forçadas a sair de operação pelos serviços de segurança por tentarem fazer exatamente isso. Entendo que dar garantias de privacidade tem valor comercial, mas não pode ter mais valor comercial do que o objetivo fundamental de permanecer no negócio.)
fonte
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.
Muitos desenvolvedores não querem essa responsabilidade e outras, apenas não estarão "prontas" para cumpri-la e, portanto, não deveriam.
Pergunta: Por que sua equipe de desenvolvimento está executando lançamentos ao vivo ?
Eu sugiro que você precise de uma "equipe" do Gerenciamento de Liberação (mesmo que seja apenas um subconjunto da sua equipe, além da representação comercial para tomar quaisquer "decisões" diárias, como "Ir / Não-Ir")? Isso removeria grande parte da "necessidade" de os desenvolvedores tocarem em qualquer coisa do Live.
Você tem algum tipo de acordo de não divulgação / confidencialidade entre desenvolvedores e empresa? É pesado, mas pode ter algum mérito.
fonte
O problema é que seus desenvolvedores têm acesso aos sistemas. Se eles precisarem de dados de produção para depuração, forneça um despejo de banco de dados em que todas as informações confidenciais serão removidas. Em seguida, os desenvolvedores podem trabalhar com esse despejo.
A implantação de uma nova versão não deve envolver nenhum desenvolvedor - uma tarefa administrativa pura, ou melhor ainda - uma tarefa totalmente automatizada. Também esteja ciente de liberar e implantar sendo duas tarefas muito diferentes. Se o seu processo não estiver ciente disso, altere-o de acordo.
fonte
Regra nº 1 de segurança: se alguém tiver acesso a informações, ele terá 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 ... são eles que precisam escrever o controle de acesso.
Se esse é um problema importante para você (e parece que é), considere incorporar segurança ao seu software. Um padrão comum é projetar software seguro em camadas. Na camada mais baixa, uma equipe de desenvolvimento confiável projeta software que gerencia o controle de acesso mais nu. Esse software é validado e verificado pelo maior número de pessoas possível. Qualquer pessoa que crie esse código terá acesso a tudo, portanto, a confiança é essencial.
Depois disso, os desenvolvedores podem criar um controle de acesso mais flexível sobre a camada principal. Esse código ainda precisa ser de pesquisa e desenvolvimento, mas não é tão rigoroso, porque você sempre pode confiar na camada principal para cobrir o essencial.
O padrão se estende para o exterior.
A parte difícil, na verdade a arte de projetar esses sistemas, é como criar cada camada para que os desenvolvedores possam continuar desenvolvendo e depurando enquanto ainda fornecem à sua empresa a segurança que você espera. Em particular, você precisará aceitar que a depuração exige mais privilégios do que você pensa que deveria, e tentar bloquear isso resultará em alguns desenvolvedores muito irritados.
Como uma solução secundária, considere criar bancos de dados "seguros" para fins de teste, nos quais os desenvolvedores podem eliminar todos os mecanismos de segurança e fazer uma depuração séria.
No final, você e seus desenvolvedores precisam entender um princípio fundamental de segurança: Toda segurança é um equilíbrio entre segurança e usabilidade. Você deve atingir seu próprio equilíbrio como empresa. O sistema não será perfeitamente seguro e não será perfeitamente utilizável. Esse equilíbrio provavelmente mudará à medida que sua empresa cresce e / ou as demandas dos desenvolvedores mudam. Se você está aberto a essa realidade, pode resolvê-la.
fonte
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 a outra é a implantação de teste.
A implantação de teste deve ter apenas dados de teste. Podem ser dados de fantasia criados para esse fim ou uma cópia dos dados de produção que foram anonimizados para impedir que os desenvolvedores descubram as pessoas e entidades reais por trás dos dados.
fonte
Em duas empresas financeiras, os desenvolvedores não tiveram acesso às 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 suponho que essa equipe era apenas funcionários e passou nas verificações de antecedentes. Eles também não tinham conhecimento de 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 que os bancos de dados vazassem publicamente, ninguém poderia lê-lo. Essa chave pode ser protegida por senha adicional (PBKDF), para que apenas um executivo possa desbloqueá-la. Seu sistema pode exigir a senha executiva na inicialização (ou provavelmente delegada a dev-ops ou a um gerente de dev-ops). Basicamente, a estratégia é dispersar o conhecimento, para que uma massa crítica de conhecimento necessário não exista em uma pessoa e haja balanços. É assim que a Coca-Cola protege sua fórmula. Honestamente, algumas dessas respostas são imitações.
fonte
O MongoDB possui controles de segurança limitados e depende de um ambiente seguro. Vinculação a um IP e porta específicos (e ssl desde 2.2) e uma autenticação bruta, é isso que ele oferece. O 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 dos desenvolvedores aos arquivos de log relacionados ao aplicativo deve ser suficiente para depurar. Automatize o ciclo de vida do aplicativo.
A Ansible nos ajudou a automatizar operações padrão (implantar, atualizar, restaurar) em muitos ambientes de um único inquilino, usando vaults criptografados distintos para armazenar variáveis de ambiente sensíveis, como hosts, portas e credenciais. Se cada cofre puder ser descriptografado apenas por funções diferentes, e apenas em um host bastião, para operações registradas, a capacidade de auditoria fornecerá segurança aceitável. Se você conceder o SSH, use o selinux para evitar violações de chave, use um host bastião com autenticação ldap / kerberos para administração e use o sudo com sabedoria.
fonte