Re: [OT] Evitar robo de código fuente
2013/2/26 Calabaza <calalinux@gmail.com>:
> El 26/02/13, Juan Manuel Acuña Barrera <gps1mx@gmail.com> escribió:
>> Buenos días a todos.
>>
>> El día de hoy los molesto porque un cliente y amigo me hizo una petición muy
>> particular, y recurro a su experiencia a ver si les ha tocado algo similar o
>> me pueden orientar. Les expongo la situación:
>>
>> -> Mi cliente tiene software desarrollado a medida (php y mysql), en un
>> servidor Debian. Este software fue mandado a hacer unos años atrás, y fue
>> bastante costoso.
>>
>> -> Ya por el tiempo que tiene este software es necesario hacer adecuaciones,
>> pero mi cliente tiene miedo a que le roben el código fuente del mismo,
>> porque en una actualización anterior del sistema, el desarrollador que
>> tenían se enviaba él mismo a su correo partes de código fuente, fue
>> descubierto y despedido, pero le dejó un muy mal sabor de boca a mi cliente,
>> ya que este software es la ventaja competitiva que tiene mi cliente sobre su
>> competencia, por lo que es vital para su negocio.
>>
>> -> Mi cliente quiere poner en una de sus oficinas un área para los
>> desarrolladores (2 o 3 pc), con debian, para que los desarrolladores puedan
>> actualizar el software, pero quiere que se pueda "garantizar" que no se
>> llevan su código fuente. Pongo "garantizar" entre comillas por que me queda
>> claro que no hay imposibles, pero mi labor es dificultarlo tanto como sea
>> posible. Éstos equipos únicamente están destinados para el desarrollo de
>> software, no hay ni audio ni impresoras ni nada de nada. Los equipos se
>> conectan a internet por medio de un DSL común y corriente.
>>
>> Lo que he pensado es lo siguiente:
>>
>> -> Quitar todos los accesos USB a los equipos (usar equipos con ratón y
>> teclado pci).
>>
>> -> Quitar quemadores y similares de los equipos.
>>
>> -> Ya que los equipos se conectarían al servidor por internet, vía SSH,
>> permitir únicamente que se conecte a dicho servidor (no se como hacerlo,
>> pero me imagino que no debería ser tan difícil).
>>
>> ¿Alguien se ha enfrentado en el pasado a alguna situación similar?
>>
>> ¿Alguna recomendación para implementar lo anterior o para implementar otros
>> o mejores candados?
>>
>> Como siempre les agradezco mucho el tiempo que se tomaron en leer este
>> mensaje, que me quedó bastante más largo de lo esperado. También les
>> agradezco mucho sus comentarios y sugerencias.
>>
>> Saludos!
>>
>> Juan Manuel.
>
> Yo te recomendaría:
>
> a) por nada del mundo dar acceso directo al servidor de producción a
> los desarrolladores.
>
> b) montar un entorno de desarrollo lo más parecido posible al de producción.
>
> c) de ser posible no permitir conexiones externas de tu entorno de
> desarrollo hacia afuera.
> y si requieren internet tendrán que organizarse para usar alguna
> conexión en un equipo
> exclusivo dedicado al efecto y monitoreado por alguien de confianza.
>
> d) alguien "de confianza" debe hacerse a la tarea de ir comparando el
> codigo modificado con el de producción, dar el ok de que no es
> malévolo y pasarlo a producción.
>
> f) los desarrolladores deben entrar al trabajo sin ningún tipo de
> memorias usb, teléfonos inteligentes, etc, etc, etc.
>
> Realmente lo casi imposible es "automatizar" la honestidad de las personas,
> así que si con un contrato con cláusulas de confidencialidad, sesión de derechos
> del código fuente creado y semejantes "el jefe" no se siente a gusto pues
> tendría que tener un gran equipo para ir metiendo más actividades para
> filtrar el
> acceso al código.
>
> Por ejemplo podrías tener a un administrador de permisos del
> repositorio de código
> fuente que cada día habilite / deshabilite el acceso (permisos) a
> ciertos directorios
> dentro del repositorio svn ( si usan svn claro está.) según tengan determinado
> qué componentes van a ser modificados.
>
> En fin, espero te sirva algo.
>
> Un abrazo,
> --
> §~^Calabaza^~§ from Villa Elisa, Paraguay
> http://calablogbaza.blogspot.com/
>
> http://es.wikipedia.org/wiki/Top-posting
> http://es.wikipedia.org/wiki/Netiquette | http://www.ietf.org/rfc/rfc1855.txt
>
> http://www.sindominio.net/ayuda/preguntas-inteligentes.html
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] CADA3QfyzFPdk195hH8bKRXXse+BaPvTatP1YAyMyrcrZEaCtSQ@mail.gmail.com">http://lists.debian.org/[🔎] CADA3QfyzFPdk195hH8bKRXXse+BaPvTatP1YAyMyrcrZEaCtSQ@mail.gmail.com
>
La forma mas facil es que tu jefe programe el codigo y se quita de problemas.
Ya hablando enserio, es imposible mantener en secreto un codigo (ni
modo que te borren la memoria al salir de tu trabajo). Que firmen un
contrato de confidencialidad, o como dicen arriba, que libere el
codigo.
El contrato define quien es el autor intelectual del codigo fuente, y
lo mas probable es que te sentiras MUY INCOMODO al firmar el contrato,
pues aunque tus neuronas son las que se quemaron resolviendo los
problemas, tu trabajo al final de cuentas no te pertenecera ni tendras
la opcion de usarlo en tus propios proyectos.
Es un tema muy espinoso y filosofico, yo en particular estoy a favor
de lo que dice Richard Stellman: Cerrar un codigo enfrenta moralmente
a los programadores. Un compañero o yo, tenemos una necesidad, y yo se
como resolverlo, pero el contrato de confidencialidad me prohibe
implementar o compartir la solucion. Es equivalente a ver ahogarse a
un amigo ¿Lo dejo morir ahogado porque la vara con que puedo
rescatarlo tiene derechos propietarios? Es una cuestion moral...
--
ItZtLi
Reply to: