Como protegemos nosso código-fonte?

3

Nosso código-fonte é o nosso bem mais valioso. Eu gostaria de ter isso:

  • garantidos pela proliferação de desenvolvedores internos , mas eles também precisam de acesso irrestrito ao código para fazer seu trabalho corretamente. Então não tenho certeza se isso é possível.
  • backup regularmente para proteger o local , mas seria seguro enviá-lo para um armazenamento na nuvem, como o box.net?

Alguma recomendação sobre estratégias? Ou eu sou paranóico?

    
por gAMBOOKa 09.09.2009 / 01:08

6 respostas

7
Proteger as coisas das ações de seu povo é mais uma questão humana do que uma tecnologia, infelizmente, então deixarei isso para os outros responderem (humanos não são meus bons - máquinas: sim, gatos: às vezes, humanos: não !).

Se você está enviando seu código para qualquer serviço externo, você deve certificar-se de que ele está criptografado com segurança antes de ser enviado, ou que você tenha totalmente verificado o serviço externo, de preferência os dois. Executar seus próprios servidores de backup será mais seguro (você tem mais controle direto), mas mais complexo (você precisa fazer tudo sozinho). Como seus servidores de backup provavelmente estarão rodando em espaços de cores que você não tem controle físico, você pode querer configurar os dados em sistemas de arquivos criptografados que não são montados automaticamente na inicialização (eles requerem manual intervenção, para enviar a (s) chave (s), se os servidores precisarem ser reiniciados - ter as chaves no servidor para poder montar automaticamente os volumes criptografados é como ter um cofre caro com a combinação escrita em uma nota de post-it próxima por.

De qualquer forma, você deve ter backups off-line e on-line, ou seja, discos / fitas fora do local e não conectados. Dessa forma, se você estiver completamente hackeado e todos os seus servidores principais, backups locais e backups online hospedados forem destruídos, você ainda deverá ter os backups offline para reverter.

Uma maneira de reduzir o problema de um hacker invadir seus servidores principais e usá-los para invadir seus servidores de backup (o que aconteceu com um serviço da Web de alto perfil há alguns meses), sugiro ter um serviço intermediário que tanto servidores ao vivo e de backup se conectam. Dessa forma, você não pode solicitar que os servidores ao vivo ou de backup tenham acesso uns aos outros, e o servidor intermediário não precisa efetuar login ao vivo ou backup. Os sites ativos entrariam no servidor intermediário para enviar os dados mais recentes e algum tempo depois que os servidores de backup fizessem login para puxá-los para si mesmos. Isso também não remove a recomendação de ter backups off-line off-line, embora reduza sua chance de precisar usá-los com raiva.

Uma opção extra para hospedar seus backups externos: se você tiver bons termos muito com outra empresa local não concorrente, talvez você possa hospedar os backups uns dos outros. Você ainda pode criptografar seus backups para verdadeira paranoia (não no caso de os outros negócios serem ruins, embora isso possa acontecer, mas para cobrir a possibilidade de serem hackeados ou assaltados).

E um ponto extra que muitas vezes é negligenciado: verifique se você tem um procedimento para testar os backups . Você não quer descobrir que eles pararam de trabalhar por algum motivo semanas atrás no dia em que você precisa restaurar algo deles. Há um número de maneiras de testar seus backups, o melhor a ser feito depende da natureza e do tamanho dos dados que você está armazenando e do formato em que eles estão armazenados. Por exemplo, eu tenho uma cópia do meu servidor de e-mail em execução. VM que pensa é o servidor live, mas não é visto do mundo exterior. Três vezes por semana, um script o interrompe, restaura o backup mais recente e o reinicia, sendo enviados erros para mim. Então, como parte da minha manutenção regular, faço login nesta VM de backup para verificar se tudo está OK (ele está em execução, mudanças recentes estão presentes, uma amostra aleatória de dados antigos parece OK também, ...). Você ainda deve ocasionalmente testar manualmente os backups, mas os testes automatizados às vezes são uma dádiva de Deus - eles podem sinalizar um problema menor antes de se tornar um grande problema.

É difícil ser demasiado paranóico quando se cuida do seu código-fonte. É o seu ativo principal, o seu negócio pode não valer nada sem ele, então você precisa protegê-lo de forças maliciosas externas (incluindo forças naturais!) Com muito cuidado.

    
por 09.09.2009 / 01:55
3

Não, você não é paranóico. Algumas coisas me ocorrem

  • Todos os desenvolvedores assinam contratos de não divulgação? Explica que o código-fonte é um ativo corporativo?
  • Você tem políticas que restrinjam explicitamente os desenvolvedores da realização de códigos fonte?
  • Os discos rígidos & Chaves USB para laptops de seus desenvolvedores criptografados?

  • Fazer backup para a "nuvem" está OK. Você deve considerar fazer o backup e armazenar o backup fora do site.

\\ Greg

    
por 09.09.2009 / 02:10
3

Não há absolutamente nenhuma diferença entre seu código-fonte e qualquer outro arquivo que você queira manter em sigilo (por exemplo, finanças). O lado humano é algo com o qual você terá que lidar como achar melhor. A segurança e a integridade dos arquivos podem ser gerenciadas de várias maneiras. Eu prefiro executar meus próprios backups em fita. Essas fitas são armazenadas fora do local, de modo que, no caso de um desastre (por exemplo, a queima do edifício - de novo!), Não se perde mais de um dia de dados.

Ao considerar o uso da "nuvem", lembre-se de que ela é chamada porque não há arestas ou definições rígidas. Muito simplesmente, você não pode saber onde seus dados estão em nenhum momento, ou quem tem acesso a eles. Se você acredita que seus dados precisam ser protegidos, você precisa controlá-los diretamente.

    
por 09.09.2009 / 02:44
2

Apenas ideias:

Primeiramente, use um sistema de controle de versão. Pelo menos assim o histórico de arquivos é mantido. Se algo acontecer a um arquivo, você sempre poderá reverter as alterações.

Em segundo lugar, posso considerar o uso de um DVCS como git ou bazar . O uso do DVCS permite um fluxo de trabalho onde os desenvolvedores podem ramificar o repositório completo. Eles podem fazer o checkout de arquivos, submeter arquivos, marcar, mesclar, etc., todos em sua própria filial, independentemente de todos os outros. Em seguida, mantenha um repositório de tronco principal em um servidor seguro em que apenas um gatekeeper tenha acesso. Os desenvolvedores podem mesclar alterações do tronco, mas apenas alguns poucos têm acesso para se comprometer com o tronco. O gatekeeper também pode ser um serviço automatizado, como o PQM ou alguma outra ferramenta de gerenciamento de patches.

Em terceiro lugar, o backup pode ser um assunto complicado. Coisas como "Você quer backups físicos armazenados?" "Você quer um servidor espelho?" "Qual é o tamanho do seu repositório?" "Quanta segurança eu preciso?" Eu não acho que eu possa responder algumas dessas perguntas para você, mas você deve levá-las em consideração ao desenvolver um plano de backup.

E NÃO, você não é paranóico ... essas são coisas que toda empresa de software deve lidar ... é o seu IP, você precisa protegê-lo.

    
por 09.09.2009 / 01:58
2
  1. Devem ser declarações muito claras no contrato de trabalho assinado no emprego que afirma que tudo é propriedade da empresa, e que a tecnologia / código não pode ser usado fora da empresa etc ... Você não pode impedi-los de quebrar isso, mas se isso acontecer, você pode tomar medidas legais e ganhar ...

    Outra coisa a fazer é garantir que os funcionários gostem de seu trabalho e, dessa forma, criar uma lealdade à empresa, o que reduz o risco de eles quererem explorar seu acesso ao código.

  2. Fazemos backups em discos removíveis. Temos 3 discos de backup que giram: um é conectado ao computador fazendo backups diários, um é bloqueado em uma firesafe no escritório e um fica em casa com o administrador do sistema. Os 3 discos giram. Isso garante que tenhamos sempre uma cópia de backup fora do escritório em caso de incêndio.

por 10.09.2009 / 09:13
1

O primeiro é um problema político / social (a menos que você esteja interessado em procurá-los indo e vindo do prédio, além de evitar a maior parte do tráfego de saída, qualquer bloqueio eletrônico é uma fachada falsa de segurança).

Para o segundo, criptografe os arquivos localmente (no seu lado) e, em seguida, envie cópias criptografadas para o seu provedor de armazenamento. Eu gosto da idéia do Jungle Disk, onde você cria e mantém sua conta do Amazon S3 e, em seguida, usa o software Jungle Disk para copiar os arquivos para a Amazon. Você terá sua chave de criptografia. Para um site corporativo, você pode duplicar a funcionalidade do Jungle Disk e ter controle total.

    
por 09.09.2009 / 02:01