security - ¿Cómo se protege el código para que no se filtre afuera?
project-management source-code-protection (14)
A menos que esté trabajando con algo altamente clasificado y dado que no puede bloquear el correo electrónico y los dispositivos USB, supongo que no lo es, no habrá mucho daño, incluso si se filtra el código fuente. La cuestión es qué es el código, o partes de él vale la pena sin el conocimiento de cómo funciona y la organización que lo rodea.
En general, el valor de "fuente" es mucho menor de lo que comúnmente se promociona, básicamente la fuente sin las personas o la organización no vale la pena el almacenamiento que ocupa para un competidor.
Además, te estás perdiendo el vector de ataque más probable, y también es el que no puedes detener sin importar qué. Si alguien realmente quiere saber cómo hizo su magia, entonces tratarán de contratar a sus desarrolladores, y ya que no puede evitar que tengan información dentro de su cráneo e incluso si entregan todas sus posesiones, el conocimiento y el dominio la experiencia se está yendo con ellos. Básicamente, la retención y la confianza de los empleados es la única forma. Lo siento.
Esta pregunta ya tiene una respuesta aquí:
Además de la fuente abierta de su proyecto y legislación, ¿hay formas de prevenir, o al menos minimizar, los daños por fuga de código fuera de su empresa / grupo?
Obviamente, no podemos bloquear el acceso a Internet (para evitar enviar el código por correo electrónico) porque los programadores necesitan sus referencias. Tampoco podemos bloquear dispositivos periféricos (USB, Firewire, etc.)
El código es más importante cuando tiene algunos algoritmos de propiedad y conocimiento desarrollado internamente (a diferencia del código de rutina común para dibujar GUI, conectarse a bases de datos, etc.), pero algunas aplicaciones (como software de contabilidad y CRM) son solo eso: complejo colecciones de código de rutina que son simples de desarrollar en principio, pero tomará años escribir desde cero. Aquí es donde el código filtrado será útil para los competidores.
Por lo que yo veo, prevenir fugas depende casi por completo del proceso humano. ¿Qué piensas? ¿Qué precauciones y medidas estás tomando? ¿Y la fuga de código te ha afectado anteriormente?
El código no se filtra en sí mismo. Se necesita gente para tomarlo. Obviamente, hay algunas medidas de seguridad que puede utilizar, como el análisis del tráfico y el bloqueo en los repositorios, para que solo los desarrolladores autorizados puedan conectarse.
Pero al final del día, tu mejor opción es asegurarte de que nadie QUIERA robarte. Tu equipo tiene que ser feliz, deben estar orgullosos de trabajar para ti, tienen que ser leales a la empresa y a los demás. Si tiene ese equipo, es una simple cuestión de explicarle a todos que el código debe protegerse de terceros. No detendrá una mole dedicada pero evitará accidentes.
PS Y sí, las cláusulas adecuadas en los contratos tampoco dañarían, al menos se asegurarán de que los desarrolladores estén CONSCIENTES de que sacar el código al aire libre es moralmente incorrecto.
El mejor paso es reintegrar a los muchachos con un comportamiento ético fuerte. Se pueden tomar otros pasos, como todas las comunicaciones que se escanean. Hay lugares donde se escanea el correo electrónico y toda la información que sale. El escritorio / computadora portátil no tiene disco duro o el acceso está restringido y todo el trabajo está en las carpetas de la red, incluso cuando se trabaja desde casa, uno tiene que conectarse a internet. El trabajo fuera de línea se sincroniza. El USB y las unidades están desconectados.
Las otras políticas son para proporcionar acceso solo según las necesidades. Esto solo se ralentizará y obstaculizará hasta cierto punto, pero es uno de los que está muy determinado y luego encontrará formas de evitar esto. La otra forma es si el código es realmente muy importante, entonces tenga la idea copywrite protegida legalmente.
No puedes evitar que salga. Entonces, hay dos soluciones: detener a las personas que desean lastimarte y tomar precauciones legales. Para evitar que la gente odie, trátalos bien (es probable que decir más esté fuera del tema para el desbordamiento de la pila).
No soy un abogado, sino que me otorgo protección legal, si usted lo cree, patenta las ideas, pone un aviso de copyright en el código y se asegura de que los contratos de los programadores especifiquen cuidadosamente los derechos de propiedad intelectual.
Pero al final del día, la respuesta se ejecuta más rápido que la competencia.
Para ser sincero, es casi imposible. Si quisiera sugerir qué haría una empresa que aparecería en breve en el Daily WTF:
Desconecte la "computadora de trabajo" de Internet, ya que necesitan acceso a Internet para que todos compren un libro de referencia.
Rellenar las ranuras USB de los desarrolladores con epoxy y exigir que carguen / descarguen todo desde un servidor centralizado, que escanea todos los datos que pasan a través de la sintaxis como código.
O simplemente podría confiar en sus empleados y hacer que firmen un NDA ...
Personalmente nunca probé en ningún caso real, pero sugiero usar la fragmentación de código:
Básicamente divide su proyecto en varias bibliotecas, define interfaces y pruebas unitarias para cada una de ellas, luego separa repositorios SVN para que cada grupo tenga acceso a una parte limitada de su valioso código fuente.
Esta es también una buena práctica, no importa qué, y debería ayudarlo si está subcontratando en el extranjero.
Recuerdo que esto le sucedió a Valve cuando estaban desarrollando HL-2. Enlace de interés aquí: http://www.shacknews.com/onearticle.x/28619
Siga estas pautas y no debería importar si el contenido de su repositorio de código fuente completo se publica en :
http://geocities.com/mdetting/unmaintainable.html
Ah, y muestre a sus desarrolladores que no confía en ellos bloqueando el acceso a partes del código fuente, escaneando el correo entrante / saliente, etc. Esa es una manera segura de hacer que quieran quedarse ... ... nada mejora la moral como un poco de desconfianza en el lugar de trabajo.
Otra buena manera es decirles a la mitad que son "equipo a" y nombrar a la otra mitad como el "equipo b" poco confiable. A continuación, inviértalo y diga lo mismo a los miembros del "equipo b". Anímalos a vigilar a los "tipos malos" del otro equipo y a informar cualquier señal de lealtad hacia ti. Espolvoree algunos "inductores de conflictos" (por ejemplo, dígaselo a "Joe": " ¿sabes lo que Ed dice sobre ti a tus espaldas? "). Funciona de maravilla si configuras a los desarrolladores unos contra otros y creas algunos [inventados por -you] conflictos aquí y allá ...
(Eh, y no, en realidad no recomiendo ninguno de los anteriores. Es una broma. Pero he visto a personas usar todas las tácticas anteriores. Y no funcionó).
Todas las respuestas anteriores parecen centrarse en generar confianza y emplear personas éticas.
Otra posibilidad podría ser crear su propio lenguaje y herramientas específicos del dominio. Eso hará que cualquier código filtrado sea más difícil de usar. Todavía podría ser posible robar ideas útiles de él, pero no sería posible simplemente compilar un producto competidor a menos que se filtre toda la cadena de herramientas.
Confía en tus desarrolladores La gente tiende a vivir de acuerdo a las expectativas. Trátelos bien, y recuerde que la lealtad es en ambos sentidos. Después de todo, si no puedes cortar las unidades de memoria USB, no puedes evitar que nadie filtre código, sin importar cuánto no confíes en ellas.
Una vez dicho esto, encuentre un abogado con experiencia en secretos comerciales, probablemente experiencia en otras partes de la ley de propiedad intelectual, y pregunte cómo proteger legalmente las cosas. Desea asegurarse de que, si un competidor obtiene sus cosas, no es legal que el competidor se beneficie de ello.
De acuerdo, voy a ser un poco práctico aquí.
- Ser amable con todos y esperar que no te hagan daño no funciona.
Todo programador sabe desde el día en que se une a una compañía que no se quedará allí para siempre. Cambiará cuando haya aprendido lo suficiente como para tener una mejor oportunidad.
Los programadores que escriben el código creen que tienen la propiedad, incluso si lo escribieron en el momento en que alquilaron a otra persona. Muchos de ellos generalmente intentarán poner sus manos en el código fuente, incluso si no tienen la intención de lastimar a nadie.
Una vez que abandonan la empresa y llevan consigo el código fuente y pierden el contacto con sus colegas, la conciencia se tranquiliza y se va de vacaciones y, después de un tiempo, empiezan a aparecer fragmentos del código en todas partes.
Eso es lo que SÉ sucede porque atestigué que le sucedió a mi compañía.
Asi que, ¿Que hace uno?
- Firme una NDA que específicamente mencione que el programador NO tomará copias.
- Distribuya su producto entre los programadores, y si es posible obtenga los módulos codificados individualmente e integrados por un jefe cuya responsabilidad es que todos los programadores no obtengan todo el código.
- En el momento de la terminación, obtenga un compromiso por escrito de los codificadores de que no poseen ningún IP de la empresa y entienden las penalidades de la violación.
- Si alguien viola tu IP, ¡demanda al hombre! Sin excepciones. Funcionará como un ejemplo para el equipo actual.
¿Sueno extremo?
He trabajado en algún lugar donde había una verdadera cultura de secretismo sobre este tipo de cosas (históricamente había habido una serie de ocasiones en que la empresa era pequeña y los "clientes" tenían, digamos, que abusaron de su acceso a nuestro producto).
Mientras que en la parte superior la gerencia era muy protectora, lo veo de forma ligeramente diferente. Creo que nuestro código, aunque no es del todo irrelevante, no es tan clave como cabría esperar en una empresa de software.
La razón por la que tenemos éxito es:
1) El código es esencialmente la solución a un montón de problemas. Si obtienes nuestro código, obtienes esas soluciones, pero todavía tenemos las personas inteligentes que resolvieron esos problemas. Ellos entienden esos problemas mejor que tú y son más capaces de resolver los siguientes problemas mejor que tú.
2) Debido a que realmente entienden los problemas (y las soluciones), podemos hacer las cosas más rápido que nuestros competidores, lo que se traduce en más barato (o más rentable).
3) También debido a esas personas y la actitud dentro de la compañía, hemos entregado bien a nuestros clientes y hemos brindado un buen apoyo.
4) Y debido a eso tenemos una buena reputación y clientes de referencia.
Un pequeño número de empresas tiene un código que realmente vale la pena guardar en secreto: algoritmos propietarios y ese tipo de cosas, pero para la gran mayoría de nosotros, nuestros productos son fácilmente reproducibles por personas inteligentes.
Lo que estoy diciendo es lo básico: escribir en los contratos de las personas que no pueden tomarlo, mantenerlo seguro, etc., pero no se obsesione con eso. A menos que se encuentre en un mercado muy específico, es poco probable que sea lo que realmente hará que su negocio tenga éxito o fracase.
No sé cuánta ayuda real va a ser, pero:
No p * ss sus programadores apagado. No los coloque en una posición en la que quieran dar la fuente a un competidor. La mayoría de los lugares subestiman a sus desarrolladores. Dado dónde estás (SO), supongo que es menos probable que lo hagas. Nada me benefició más que ver a las personas de ventas en los juegos de golf, pagados y pagados por la empresa, mientras que tuvimos que pelear para conseguir pizza una vez al mes.
Realmente, si sus competidores directos obtuvieron su código hoy , ¿qué haría? ¿Está su producto o mercado vertical tan estancado que no lanzará versiones mejores y más nuevas antes de que puedan reaccionar? ¿No hay lugar para la innovación? La mayoría de las empresas sobrevaloran sus "algoritmos propios y el conocimiento desarrollado internamente". Claro, puede acortar el tiempo de descanso, pero es solo alrededor del 10% del problema.
Si tiene toda la fuente para todos los productos de sus competidores, ¿cuánto uso real sería? Supongo que te retrasaría meses. No hacia adelante. Espalda.
Si tuviera un sistema limpio y poco conocimiento externo / interno, ¿cuánto tiempo le llevaría obtener su propio producto en un estado edificable? ¿Cuánto tiempo lleva profundizar en el código y el entrenamiento de lo que está pasando? ¿Cuánto tiempo y dinero desperdiciaría tratando de resolver algo, en lugar de gastar tiempo y dinero en cómo hacer que su producto funcione mejor?
De hecho, he estado en la posición de tener toda la fuente - 1 millón de líneas + de código - en el producto de un competidor. No hicimos nada con eso, aparte de un poke-around y luego eliminarlo, que era más de lo que me sentía cómodo, pero esperaría que hubiéramos masticado meses para llegar a donde estaban. entonces.
Así que lo bombardeamos, dimos una palmada al id10t que lo consiguió (sí, un desarrollador / PM que vino de la otra compañía), y pensamos en cómo hacer que nuestro producto pateara tanto que no importaba lo que hicieran. Mucho mejor uso del tiempo. Funcionó bien, también. Teníamos diferenciadores, no solo volvíamos a hacer las mismas funciones de la misma manera que ellos.
Lo siento, pero no hay forma de que pueda evitar que las personas obtengan cosas, y aún así puedan trabajar realmente. Puedes evitar que quieran hacerlo, o hacerlo de modo que no tenga ningún valor que lo tengan.
También nos preocupaba que la gente descompilara nuestro código. Dejamos de preocuparnos cuando nos dimos cuenta de que NOSOTROS teníamos suficientes problemas para resolver lo que estaba ocurriendo dentro de las 500K + líneas de código C #, C ++ y HTML hablando con MAPI / Exchange. Si alguien puede descompilarlo y resolverlo, entonces queremos contratarlos ......
Por cierto, para mayor claridad, y dado a quién ahora trabajo, debo señalar que este no es mi empleador actual. Esto fue hace bastante tiempo.
La mayoría de las respuestas se basan en valores morales y éticos. Me pregunto si Google, Facebook, etc. solo confían en la buena voluntad de sus empleados. Dame un descanso, eso es totalmente utópico. No seas tonto Ser realista.
SÍ, es posible evitar fugas de código:
Al utilizar un servidor virtual que aloja máquinas virtuales, los programadores solo pueden acceder localmente a estas máquinas virtuales (intranet) a través de Escritorio remoto. El repositorio se administra localmente. se requieren claves privadas para acceder al repositorio. Copiar / pegar desde la máquina virtual al cliente está deshabilitado. solo se permite copiar / pegar de cliente a virtual.
Empresas como Facebook hacen eso.
La única forma de seguir codificando es tomar fotografías del código real, lo que no es práctico y factible en absoluto, y dado que hay cámaras de vigilancia en todas partes, tendrás que ir al baño para tomar esas fotos.