Como evitar que o código vaze fora do trabalho? [duplicado]

Esta é uma das situações em que você está procurando uma solução técnica para um problema social .

Um problema social deve exigir uma solução social, que, nesse caso, leva dois formulários complementares e uma solução organizacional adicional que pode ajudar:

• Confiança. Se você não confia em desenvolvedores, não os contrate. Trabalhar com pessoas em quem você não confia é sinônimo de falha. Relações baseadas em desconfiança exigem muito formalismo, o que pode afetar severamente não apenas a produtividade de seus funcionários, mas também o número de pessoas prontas para trabalhar com você. As chances são de que os melhores desenvolvedores evitem sua empresa a todo custo.

• NDA. Confiar em alguém não significa que você não deva tomar precauções legais. Essas precauções podem assumir a forma de um contrato ou uma cláusula NDA com consequências graves para o funcionário em caso de divulgação.

  Quão severas são as conseqüências depende de quem você é. Organizações governamentais, terroristas ou máfia podem permitir alguns impedimentos. As empresas ordinárias podem ser limitadas, por lei, apenas às financeiras.

• Fatiar. Confiança e contratos são um bom começo, mas podemos fazer melhor. Se a parte sensível da base de código puder ser dividida para que duas ou mais partes sejam necessárias para o produto funcionar, certifique-se de que o desenvolvedor do departamento 1 nunca veja o código-fonte desenvolvido no departamento 2 e vice-versa.

  As pessoas de um departamento não devem poder conhecer pessoas de outros departamentos e, idealmente, não devem nem conseguir adivinhar o que os outros departamentos estão fazendo nem quantos departamentos há. Cada pessoa conhece apenas uma pequena parte, o que não é suficiente para ter uma imagem completa (e reconstruir um produto inteiro fora da organização).

Essas foram medidas sociais e organizacionais.

Agora, falando tecnicamente , não há nada que você possa fazer.

Você pode tentar:

• Força os desenvolvedores a trabalhar em uma sala fechada em uma máquina que não esteja conectada à internet e não tenha portas USB.

• Instale câmeras que monitoram tudo o que acontece na sala, com vários agentes de segurança observando constantemente os desenvolvedores trabalhando.

• Pesquise os desenvolvedores a cada vez que ele sai da sala para ter certeza de que ele não tem nenhum dispositivo eletrônico que possa conter o código.

• Exigir que todo desenvolvedor tenha um monitor de tornozelo. O dispositivo escutará o que eles dizem, registrará sua posição e tentará detectar qualquer dispositivo eletrônico nas proximidades. Se o desenvolvedor estiver perto de um dispositivo que não esteja identificado e não tiver seu software de rastreamento instalado, os investigadores e hackers privados poderão tentar verificar se o desenvolvedor não estava usando o dispositivo para vazar informações.

• Proibir os desenvolvedores de deixar seus edifícios, a menos que estejam sob vigilância pesada, e interagir de qualquer maneira com o mundo exterior.

Algumas ou todas essas medidas são ilegais em muitos países (a menos que você represente algumas agências governamentais ), mas a pior parte é que, mesmo com todas essas medidas, os desenvolvedores poderão obter código, por exemplo, escrevendo-o discretamente em sua pele ou em um pedaço de papel e escondendo-o em suas roupas, ou simplesmente memorizando-o se tiverem Memória eidética .

Ou eles podem apenas memorizar globalmente as estruturas de dados e os algoritmos - essa é a única coisa importante em que a propriedade intelectual é importante - e criar seu próprio produto inspirado por essas duas coisas.

1. Faça com que eles assinem um contrato de não divulgação.

2. Contrate apenas pessoas nas quais você confia.

3. Compartimentalize sua base de código. Uso de injeção de dependência para que você possa dar a eles requisitos que, quando terminados, as classes resultantes se encaixariam na arquitetura existente, mas não terão acces à "imagem completa", apenas pedaços soltos. Somente pessoas de confiança e seniores teriam autorização para a "cola arquitetônica" que faz com que todo o trabalho funcione como um todo.

Eu adorei a ideia de que poderia haver uma idéia "inteligente" de que "nós", como desenvolvedores, ficariam perplexos. Dado que cada ferramenta de desenvolvedor escrita foi escrita por um desenvolvedor e tudo isso.

O maior problema do seu chefe é a ingenuidade com uma pitada de paranóia. Estou sendo educado lá. Realmente muito educado.

Se você realmente deseja que uma lista de compras de itens mantenha seu código proprietário, basta implementar o seguinte:

1. Desative o USB e outro IO em todos os computadores da empresa. Isso pode ser feito através da maioria dos antivírus corporativos ou similares.

2. Todas as máquinas do desenvolvedor são desktops ou torres. Não há laptops.

3. Não permita que qualquer máquina se conecte à internet. Sem web, ftp, e-mail, mensagens instantâneas, sem internet. Cortar os fios.

4. Nenhum trabalho / acesso remoto (meio que não é coberto por internet, mas alguma faísca inteligente pode sugerir uma VPN)

5. Nenhum celular ou outro dispositivo eletrônico deve ser levado para a sala de "desenvolvimento" segura.

6. Configure todas as impressoras para imprimir uma marca d'água visível grande em todas as páginas, frente e verso.

7. o saco pesquisa dentro e fora. Procure notas escritas à mão, qualquer coisa impressa em impressoras da empresa (qualquer coisa, elas podem ter código oculto em uma imagem com esteganografia!). Quaisquer dispositivos elétricos ou eletrônicos. Na verdade, provavelmente é melhor garantir que as bolsas sejam mantidas fora da área segura e os desenvolvedores devem usar roupas limpas, o tipo de coisa que você veria nas tocas de drogas e nas fábricas de chips.

8. Os servidores devem estar igualmente isolados, as cópias de segurança devem ser criptografadas e apenas o seu chefe deve saber a senha para restaurá-las.

Se as pessoas em questão não puderem confiar em seus contratos de trabalho, ele não precisará contratá-las.

Se ele acredita que NINGUÉM pode ser confiável, então ele está sendo excessivamente paranoico, e ele acabará por prejudicar a empresa se continuar assim.

Em algum momento você deve confiar em seus funcionários. Não é realmente uma opção para fazer o contrário. Se você não confia em seus funcionários, então eles não podem ser eficazes, porque você está gastando muito tempo desconfiando deles, e desperdiçando muito do seu tempo pulando através de aros devido a problemas de confiança.

Além disso, quando você deixa claro para as pessoas que você não confia nelas, elas tendem a se irritar. E os programadores irritados acabam encontrando outro emprego onde não são tratados dessa maneira.

A solução certa é uma verificação de antecedentes básica, um contrato de trabalho bem pensado e alguma confiança.

Eu costumava escrever código para sistemas de computador classificados. Eles tinham todo tipo de arcos ridículos para pular para mantê-lo em segredo. Por exemplo, não éramos autorizados a trazer CDs de música para certas salas, porque eles podiam ser disfarçados em CD-RWs.

Em outras palavras, há muitas coisas que você pode fazer para proteger de pessoas de fora, mas depois de deixá-las entrar, é praticamente uma questão de quanto você quer incomodá-las.

Resumindo , você precisa ter um acordo / contrato de não divulgação com os funcionários contratados. Além deste contrato assinado, contrate desenvolvedores nos quais você pode confiar .

Tecnicamente falando, esse código pode ser facilmente copiado para o dispositivo e reutilizado em outro lugar. O que seu chefe não quer é - acesso de seus concorrentes a este código. Você só pode aplicar tais políticas através de contratos de emprego ou parceria.

Outra coisa que pode funcionar é fornecer treinamento sobre a sensibilidade da informação , como cada funcionário deve ser alertado quando a confidencialidade da informação é violada. Além disso, rastrear as atividades do computador na rede do escritório também aumentará o nível de aviso.

Um tipo semelhante de treinamento é feito anualmente para os funcionários que lidam com informações relacionadas a PHI .

No entanto, conseguir um funcionário confiável e fornecer treinamento sobre como proteger essas informações pode ser o melhor caminho a seguir.

Você viu o Paycheck com Ben Affleck? Eu acho que é a única maneira de garantir que seu IP não seja "roubado". Posso dizer-lhe que por causa da minha memória, eu poderia recriar quase todos os sistemas em que trabalhei por um período significativo de tempo. Se não for uma linha por linha de recreação, eu poderia produzir os elementos significativos e provavelmente melhorá-los no processo por causa de como minhas habilidades cresceram ao longo dos anos.

Puro e simples, existem apenas duas coisas que você pode realizar "bloqueando" seu código:

1. Você vai repelir bons desenvolvedores que se ofendem com sua óbvia falta de confiança
2. Você criará uma grande bandeira que atrairá os desenvolvedores mais inescrupulosos

Se você acha que seu software é tão inovador e incrível, obtenha uma patente.

1. Você não pode impedir que o código vaze. Você pode limitar o vazamento para código menos importante.
2. Normalmente, há apenas uma parte do aplicativo que a torna única. Isso seria algum algoritmo. Você pode fazer a interface disso muito bem e colocar isso em uma ramificação de controle de origem separada. Você e apenas as pessoas que precisam trabalhar nele devem ter acesso a ele. Você fornece apenas um binário (ofuscado) e a interface para os outros desenvolvedores.
3. Divida seu código em mais módulos e permita que as pessoas trabalhem somente em um módulo específico. Os outros módulos são fornecidos em binário (ofuscado). Isso, no entanto, pode ser esticado demais para que seja incontrolável e possa levar à duplicação de código.

Eu conheço alguém que trabalhou em um ambiente como este.

Algumas medidas foram tomadas:

1. Sem acesso ao computador físico, todos os computadores foram armazenados em uma sala trancada com buracos na parede para exibição, teclado e mouse.

2. Sem acesso à internet.

3. Sistema operacional personalizado que usava um sistema de arquivos interno com criptografia (no caso de um computador ser roubado de alguma forma).

4. Os projetos foram divididos em bibliotecas estáticas, ninguém teve acesso a todo o código-fonte (isso, é claro, não se aplica a todas as linguagens de programação).

5. Foi um local de trabalho muito desagradável.

Tenha cuidado para não superestimar o valor do seu código-fonte para aqueles que estão fora da sua empresa.

Claro - você pagou muito dinheiro para engenheiros (desenvolvedores, controle de qualidade, etc), mas isso não significa que é intrinsecamente valioso para terceiros.

Quais ataques exatos existem?

O código-fonte geralmente é vazado de (por exemplo) desenvolvimento de jogos ou empresas de segurança de TI. É claro que esses vazamentos fazem com que pareçam ruins, mas por outro lado, não causam danos reais.

Pergunte-se:

• Você está tão envergonhado com a qualidade do seu código-fonte? Seria prejudicial para a sua reputação vazar isso?
• O próprio código-fonte contém segredos confidenciais (por exemplo, chaves de criptografia codificadas, detalhes de relações financeiras com outras empresas)? Deveria?
• Um concorrente poderia realmente se beneficiar do uso do seu código-fonte, apesar do risco de ser descoberto?

Até onde eu sei, houve um caso em que um membro da equipe de uma empresa de segurança de TI tentou vender o código-fonte a um concorrente. O concorrente imediatamente relatou isso ao seu empregador e logo foi demitido. Nenhum dinheiro mudou de mãos, mas o membro da equipe não pode mais trabalhar facilmente no setor de segurança de TI.

Você precisa confiar, mas às vezes é melhor monitorar as infrações. Por exemplo, se o código for executado, ele pode ligar para algum endereço IP na Internet sempre que for executado, registrando o endereço IP, informações do computador, talvez até mesmo a localização geográfica de onde ele está sendo executado. Revise esse log para procurar problemas.

É claro que há maneiras de contornar isso, e os desenvolvedores poderiam estar procurando no código, sem executá-lo.

Você poderia configurar seu firewall para fazer a inspeção de pacotes com algo como Snort que poderia a) bloquear a conexão imediatamente se detectasse, por exemplo, seu aviso de direitos autorais e b) informe a gerência para acompanhamento. Para contornar SSL e HTTPS, você precisaria estar executando um proxy HTTPS no seu firewall.

Talvez você possa ter um utilitário de sistema em todos os PCs que verificam unidades externas e unidades flash USB para arquivos específicos ou frases-chave enquanto estão conectados. Você também pode desativar / banir unidades externas (ouvi o DOD dos EUA fazer isso ). Você teria que exigir que eles usassem seu hardware e não trouxessem nenhum hardware de casa.

Existem provavelmente programas disponíveis que registram tudo que alguém faz com um computador. Apenas programe auditorias aleatórias desses logs e certifique-se de que os desenvolvedores estejam cientes desse recurso.

Depois de encontrar uma infração, acerte o desenvolvedor na cabeça com o NDA assinado por ele.

Uma solução técnica poderia ser ter todas as sessões de desenvolvimento hospedadas em um servidor sem acesso de rede (ou severamente restrito e monitorado) além do necessário para atender às sessões de RDP (ou VNC). Dessa forma, a fonte nunca está na máquina de um desenvolvedor. Também tornaria possível trabalhar em casa ou em um site do cliente.