Este es un problema de gestión.

Antes de que el código crítico sea desplegado, debe ser controlado por la versión, el código revisado, y al menos el uso debe ser documentado. Si la seguridad está preocupada, elegir a los revisores adecuados, y proteger el repo y los documentos. No hay razón para que esto no pueda ser iniciado inmediatamente.

Hay un problema más grande que la seguridad del trabajo.

Cualquiera de estos desarrolladores podría poner código malicioso en la compañía, ya sea por error o por sus propias razones. En el peor de los casos, podrían cometer activamente actos nefastos usando su propia situación creada (extorsión, sabotaje, espionaje industrial, etc.). En el mejor de los casos, su opacidad expone a todo el mundo a preocupaciones de seguridad, y siempre deja un signo de interrogación sobre cualquier auditoría o responsabilidad. Si algo sale mal, ¿quién puede decir que no estuvieron involucrados de alguna manera?

Necesitas recopilar un informe para la dirección.

Escribe un breve documento que describa exactamente por qué el enfoque actual está llevando a la empresa por un camino peligroso (ser golpeado por un escenario de autobús, por ejemplo). Esbozar los riesgos de seguridad, tal vez incluso citar cuentos de precaución de su industria, con referencias a artículos, etc.

Incluir también una lista de las formas en que el enfoque de este tipo está perjudicando su propio trabajo, así como el trabajo de sus compañeros de trabajo.

Por último, pero no menos importante, asegúrese de la lista de recomendaciones que deben aplicarse de inmediato, como añadir el código al control de versiones para que todos lo vean, y ejecutar el servidor en una VM a la que todo el mundo tenga acceso. Describa cómo estas medidas no deberían afectar de ninguna manera el trabajo de esta persona, y simplemente añadirá seguridad y transparencia a todo el proceso - dejar claro que no hay objeciones razonables a estas medidas.

Tal vez se siente con su jefe cuando le entregue este informe, y entregue verbalmente los temores exactos que ha escrito aquí: que este tipo se está construyendo un imperio en la infraestructura de la empresa, y que, en última instancia, es potencialmente peligroso. Si sus jefes creen que esta persona puede llegar a ser irrazonable, entonces usted puede seguir el consejo de @BillLeeper y tomar el control de su máquina para que sea incapaz de dañar su organización. Esto será, por supuesto, para que ellos decidan.

Desafortunadamente, no has dicho si alguien ha hablado de estas preocupaciones con el compañero de trabajo o la dirección. ¿Es realmente malicioso? ¿O su colega es simplemente ciego? ¿O quizás la dirección es ciega?

Yo mismo he sido “ese” tipo.

En mi anterior trabajo a veces tenía varias tareas secundarias para “hacer esta pequeña herramienta” o para hacer algo simple. Resulta que nunca hay recursos para el software interno… Normalmente era algo así:

– ¿Puede alguien mirar las soluciones que elegí para decir si son apropiadas? – Vamos, sólo necesitamos una herramienta sencilla que haga esta simple operación, hágala y estará bien.

– ¿Puedo crear un servidor virtual en nuestro servidor para esta cosa? – Hombre, es sólo para uso interno. Sólo ponlo junto con otras cosas en esa caja física rota. O póngalo en esa caja que hace las funciones de no-sé-qué. O ponlo en tu propia estación de trabajo.

Por supuesto, nunca hubo recursos de tiempo para escribir documentos. A menos que eligiera hacerlo en mi tiempo libre. Por supuesto, todo lo que podía decir cuando algunas herramientas tenían problemas era “trabajar en ello”.

Y entonces decidí dejarlo. Ese fue el primer momento en que alguien a mi alrededor se dio cuenta de que las “pequeñas herramientas internas” eran realmente importantes y que las cosas “simples” no son tan simples. Pasé un par de fines de semana escribiendo documentos para fastidiar menos a mis colegas. Ha pasado casi un año y todavía recibo múltiples llamadas cada mes sobre cómo hacer algo con mis herramientas internas.

Editar

Algunos comentarios han señalado que no debería ayudarles gratuitamente. Esto es generalmente correcto. Quería aclarar que no dedico horas de mi tiempo a resolver sus problemas, sólo dedico un minuto a responder una pregunta. Técnicamente sigue siendo cierto que de este modo estoy permitiendo y fomentando las prácticas existentes Por cierto, la empresa me ha ofrecido un puesto a tiempo parcial o pagado por horas para resolver problemas como lo hacía antes y lo he rechazado.

El caso es que no estoy dispuesto a obligar a mis ex colegas a “investigar mejor” en lugar de preguntarme simplemente “¿En qué máquina funciona el Veeam?” si puedo decir simplemente el nombre o la dirección IP sin pensarlo o decir “Debería estar escrito en […]”. Además 2 minutos de llamada telefónica con ex-colega suele ser una distracción tan positiva y relajante como visitar Stackexchange.

Fin de la edición

¿Qué puedo sugerir? Su colega parece bastante capaz, ¿no? Discuta esto con la dirección. No le digas “se está volviendo irremplazable”. Sólo pregúnteles… ¿Y si se va? ¿Qué pasa si se enferma por un tiempo prolongado? Convéncelos de que el problema es real. Deberían discutirlo con ese tipo ellos mismos para encontrar soluciones. ¿Tal vez sólo carece de recursos? ¿Tal vez necesita otra persona en el equipo de “software interno” para que todo sea bonito y agradable?

La mayoría de estas respuestas son WAY OVERBOARD en suponiendo intención maliciosa por parte del desarrollador en cuestión.

Antes de hacer una imagen subrepticia del servidor y luego de sacar al tipo de la oficina, ¿por qué no tomar un respiro y tratar de entender lo que está pasando?

Podría muy bien ser que la persona en cuestión esté sobrecargada de trabajo, no tenga suficientes recursos y esté más que dispuesta a compartir el conocimiento. O tal vez lo ha estado haciendo de esta manera durante mucho tiempo y nunca ha recibido una indicación de que necesita hacer lo contrario. Como mínimo, especialmente si su material FUNCIONA, merece la oportunidad de resolver sus preocupaciones y colaborar con sus compañeros de trabajo.

No veo ninguna evidencia de que nada de esto se haya intentado en la pregunta de la OP. Antes de considerar opciones draconianas, intente primero la comunicación. Si la persona no tenía intención de hacer daño, puede esperar cooperación de él.

Hay algo que no he visto en las otras respuestas todavía:

Empieza casualmente a buscar un nuevo trabajo

Por supuesto, esto se basa en la suposición de que ya has hablado con tu gerente sobre esto. Otras respuestas han proporcionado las razones por las que este no es tu problema sino el de tu gerente y también han dado indicaciones sobre cómo enfocar esta conversación con tu gerente.

Ahora, estoy viendo la situación en la que has hablado de esto con tu gerente y luego, después de que ha pasado un tiempo razonable, no ha pasado nada al respecto. Tienes la sensación de que tu gerente no considera esto como un problema tan grande como sabes que es.

Ahí es donde quizás quieras empezar a buscar un nuevo trabajo. No importa si tu jefe no cree que esto sea un problema o si simplemente no lo entiende lo suficientemente bien como para ver el problema, hay algo que no está bien. (Y no me refiero al código “privado”, sino al problema de que el gerente no haga algo al respecto)

Tal problema es algo que no es probable que puedas cambiar desde la posición de un desarrollador. Sin embargo, hay otras empresas y no tienen los mismos problemas, por lo que es posible que quieras buscar un empleador diferente.

Sin embargo, mirándolo desde el lado positivo, no hay demasiada presión sobre ti en este momento. Tienes un trabajo y no esperas perderlo. No tendrás que comprometerte para poder seguir pagando el alquiler/hipoteca/costos de vida. Puedes empezar a buscar casualmente y no dejar tu trabajo actual hasta que encuentres el que realmente te gusta.

Parece que hay algunos buenos remedios aquí para prevenir esto en el futuro, pero no qué hacer al respecto ahora.

1. Asegure la computadora. O bien hacer que la dirección y un experto en informática revisen cuando esté desbloqueado y desatendido, o ir y exigir que desbloquee la máquina y conceder el acceso. Luego saque a este monstruo de la red. Haz una imagen inmediata del HD en caso de que tenga un interruptor de hombre muerto.

2. Despida a este individuo inmediatamente. Acompáñelo a la puerta. No se preocupe por la causa, habrá muchas pruebas en su ordenador. Si la compañía está preocupada, que su abogado haga su magia, para eso les pagan.

3. Reúne al equipo. Explica lo que pasó. Este individuo actuó de manera imprudente y poco profesional. Puso la compañía en riesgo y fue despedido por eso. Se necesitarán todos los recursos que tenemos para arreglar este lío.

4. Usar el equipo para reconstruir y re-desplegar este trabajo de manera adecuada en máquinas seguras, etc. El equipo va a tener que revisar aplicación por aplicación y controlar las cosas. No se preocupe inmediatamente por la reescritura, sólo asegúrese de que no haya puertas traseras, etc., y luego ponga los servicios en hardware fresco y controlado.

5. Consiga un experto en seguridad. Este tipo probablemente no se irá tranquilamente y tratará de ‘hackear’ de nuevo para sabotear o conseguir acceso a su sistema. También puede tener contraseñas globales de los sistemas con los que interactuó u obtuvo contraseñas individuales a lo largo del tiempo. IT debería activar un restablecimiento forzado de las contraseñas de todos los usuarios y bloquear cualquier acceso externo por un tiempo (como VPN).

Todas las respuestas actuales y la mayoría de los comentarios actuales sólo indican la situación actual o proporcionan sugerencias para tomar medidas extremas.

Sólo para resumir: Hay dos situaciones posibles: Los compañeros de trabajo lo hacen intencionadamente, en este caso son maliciosos de una forma u otra, y entonces es necesario tener una precaución extrema. O los compañeros de trabajo no ven los problemas y peligros potenciales y reales que están causando, entonces son “amigables” pero se les debe enseñar a hacerlo mejor.

Por lo tanto, la siguiente hoja de ruta intenta dos cosas al mismo tiempo: 1) Intentar minimizar el daño potencial, que esos compañeros de trabajo pueden hacer, si son maliciosos, y 2) tratar de mantenerlos en la empresa (para que puedan llegar a ser compañeros de trabajo cooperativos en el futuro) si son amigables:

(btw: Ya sé, no eres el jefe, pero con la información, que otros han proporcionado, supongo que tendrás todo en tus manos para convencer a tu jefe, para tomarte este hilo muy en serio, así que este mapa de ruta trata de lo que tu jefe podría hacer, no de lo que tú harías. Lo único que puedes hacer es llamar la atención de tu jefe. btw2: Si tu jefe sigue sin escuchar, busca un nuevo trabajo y renuncia tan pronto como encuentres uno nuevo. Porque esos compañeros de trabajo son bombas de tiempo, sin importar si son amistosos o maliciosos - eso no importa en absoluto).

1.) Haz silenciosamente copias de seguridad de todo lo que puedas acceder. No apagar los sistemas en el proceso, apagar los sistemas podría potencialmente disparar algunos tipos de trampas explosivas.

2.) Construya una razón, que las estaciones de trabajo necesitan apagarse. Si necesita una idea, contácteme en privado.

3.) Extraer los discos duros, hacer una imagen completa, volver a colocarlos. Hazlo durante un fin de semana más o menos

4.) Si los sistemas tienen material de detección de intrusos a nivel de BIOS, y no puedes eludirlos, construye otra razón, por la que esos sistemas de detección de intrusos se dispararon.

Esos compañeros de trabajo están creando herramientas para cosas internas, ¿verdad? ¿Así que no necesitan acceso a los sistemas de los clientes y similares?

5.) Si tienen acceso a los sistemas, no lo necesitan, cambien las contraseñas, asegúrense, no hay ningún tipo de acceso de clave pública, comprueben los puertos para los procesos que permiten un acceso no estándar. Revisar los trabajos cron/at, revisar inetd, revisar todo lo que se está ejecutando actualmente. Por cada pid, tienes que ser capaz de responder, por qué ese proceso se ejecuta en absoluto.

6.) Consigue un nuevo empleado (realmente nuevo, completamente desconocido. Debe ser un muy buen experto, porque debe ser capaz, de tomar su trabajo solo por un mes si es necesario. No puedes tomar algún estudiante graduado al azar (ni siquiera uno con la más alta calificación), necesitas algunos de esos tipos, que nunca visitaron una universidad en absoluto pero que aún saben todo) e insertarlo en ese equipo para apoyarlos. Especialmente porque están causando bloqueos en los otros trabajadores, puede ser fácilmente justificado. Su trabajo oficial es apoyarlos, su verdadero trabajo es aprender, cómo funcionan.

El paso 6 es especialmente importante, porque de esta manera, tienes la oportunidad, de averiguar realmente, si esos compañeros de trabajo son maliciosos en absoluto.

Si el nuevo tipo se integra bien en el equipo, entonces puedes asumir que son amistosos, ese nuevo tipo debería ser capaz de implementar los cambios necesarios sin necesidad de decirles a esos tipos, que ha habido alguna sospecha contra ellos en absoluto.

Si el nuevo tipo se da cuenta, son maliciosos, pero lo integran, entonces su trabajo es seguirles la corriente. Aprender todo, encontrar lo mejor de lo que están haciendo, y así sucesivamente. Páguele el doble de dinero, porque tiene que trabajar dos veces, porque una vez que vuelve a casa, tiene que anotar todo lo que ha aprendido y enviarlo a algún equipo recién formado que debería hacerse cargo del trabajo tan pronto como se haya transferido suficiente conocimiento.

Si los tipos maliciosos no lo integran, entonces su única oportunidad es esperar, tiene suficientes datos respaldados (sólo por si acaso) y despedir a ese equipo. Entonces puede que necesites dos o más de esos súper expertos de los que hablaba antes, para meter un nuevo equipo en ese código muy rápido.

Espero que esta hoja de ruta ayude - al menos como fuente de inspiración sobre cómo manejar esto. Tal vez, en tu empresa, tienes algunas opciones, que no puedo considerar, tal vez, hay algunas diferencias culturales, por lo que todavía tienes que pensar en esto y tal vez ajustar el plan.

El programador en cuestión no debe recibir ningún trabajo nuevo hasta que la situación se resuelva de una forma u otra. Todos los nuevos requisitos deben ir a otro desarrollador/equipo que debe seguir los procedimientos adecuados de control de la fuente y revisión por pares (nuevas contrataciones si es necesario). El programador en cuestión puede mantenerse ocupado arreglando defectos o “combatiendo el fuego” de su legado existente. Los recursos deben asignarse a la ingeniería inversa del legado existente y a la reimplementación mediante los procesos adecuados. El coste de hacer esto tiene que ser justificado por el riesgo existente - ¿qué le costará al negocio si todo lo que este programador ha hecho se pierde de repente? O peor aún, ¿qué datos propietarios (de la empresa) son vulnerables a la pérdida por la competencia?

Podría valer la pena preguntarle a este empleado: “¿Qué nos pasa si te atropella un autobús o decides hacer un crucero de un mes alrededor del mundo?” y medir la respuesta para decidir si entregará su código voluntariamente. Si coopera, no hay necesidad de que la situación se convierta en adversaria; si no hay signos de preocupación para la empresa por su parte, es hora de ocuparse de asegurar todo lo que ha tocado.

¿Cómo abordar a la gerencia sobre esto?

Decir que la mejor práctica es no permitir esto, por muchas razones.

Los programadores profesionales deben saber que esta no es la manera de manejar un negocio; y si los gerentes no saben nada más deben al menos saberlo (los programadores deben decirle a los gerentes y/o los gerentes deben decirle a los programadores).

Las razones son esperanzadoramente tan conocidas que no necesito decirles. Incluyen “respaldo”, es decir, que estás en problemas si pierdes al programador (o si se le reasigna a otra cosa), o si el programador pierde su máquina.

Por lo menos tú tienes “control de versión de la compañía”, así que no necesitas pelear esa batalla; sólo haz que sea un requisito de trabajo/proceso que realmente se use.

Probablemente no deberías ejecutar software de producción en la máquina del desarrollador. Un primer paso podría ser insistir en que:

• Los usuarios no hacen conexiones de red con la máquina del desarrollador
• El software se ejecuta en/desde un servidor de producción
• El software que se ejecuta en el servidor de producción debe poder ser construido por otra persona (o por una máquina de construcción), desde el control de código fuente

Implementación que requiere que el código fuente sea comprobado, las instrucciones de construcción publicadas. Le sugeriría que lo haga como una semi-emergencia. Permitir al desarrollador que no tenga acceso de escritura al servidor de producción o a la máquina de compilación (para verificar que el código de producción se puede compilar desde el control de versiones).

Después de hacer eso (después de saber que el código fuente está en el control de versiones y que las instrucciones de compilación están publicadas), entonces otros desarrolladores pueden pensar en inspeccionar el código fuente y ayudar a mantenerlo.

Ten en cuenta que * Deshazte del programador indispensable lo más rápido posible ** fue publicado por Gerald Weinberg en 1971 (así que, realmente, todo el mundo debería saberlo ya). IIRC la cita original es,

“Si un programador es indispensable, deshazte de él lo más rápido posible.”

Este no es tu problema, es la responsabilidad y el papel de los gerentes, eres sólo un compañero de trabajo y posiblemente no tienes toda la información necesaria. Me preocuparía más por mis propias tareas que por mis compañeros de trabajo. No puedo ver cómo puede salir algo positivo de armar un escándalo por tu compañero de trabajo.

Te harás enemigo de él, harás ver a tu gerente por ser incompetente y darás la impresión de que tienes tan poco trabajo que tienes tiempo para lanzar investigaciones internas sin que te lo pidan o sin tener autoridad para hacerlo.

La pregunta es, ¿cuánto deseas salir de este círculo vicioso? Porque no nos hagamos los tontos con esto, le va a costar al bufete.

1. La firma tendrá que gastar dinero para contratar a alguien que escriba el código que la firma controla.
2. La firma tiene que exigir el código del codificador, y respaldar esa demanda con ayuda legal si es necesario. Señalaré que el código fue encargado por la empresa, que el codificador recibió un cheque de la compañía mientras escribía el código, así que el código es de la empresa. Un fallo por parte del codificador para producir el código sería en el peor de los casos considerado como un robo, lo que sería un delito.

La libertad no es gratis. Si la firma no está dispuesta a gastar recursos para liberarse de este individuo, entonces todo lo que está haciendo es agitar las encías. Todos ustedes van a tener que enfrentar la situación, porque si el codificador se aleja o es atropellado por un camión, la firma es SOL.

Considere la razón por la que están haciendo esto. Es muy posible que se estén recortando las esquinas para ajustarse a las limitaciones de tiempo, los objetivos de rendimiento y las crecientes demandas. Esto a menudo lleva a una deuda técnica y a un codificador muy estresado que no tiene más remedio que arreglar cada problema fuera de la oficina.

Esta persona bien puede estar escribiendo cosas de una manera que sólo ellos pueden arreglar porque no tienen tiempo para documentar, versionar y mantener el código de manera oportuna. Confía en mí cuando digo que esto tiene un efecto completamente negativo en cualquiera que se encuentre en esta posición. No es un papel cómodo en el que alguien pueda sentarse y relajarse.

Si, como su título sugiere, no están resolviendo problemas, no habría ningún problema. Simplemente tirarías el codificador, con todo su código, porque es inútil.

La prevención de situaciones como ésta es una tarea de gestión extremadamente básica. De ello se desprende que la dirección que es consciente del problema no es competente, y la dirección que es competente no es consciente.

Desafortunadamente, desenredar situaciones como ésta es una tarea de gestión difícil. Por lo tanto, como los gerentes a cargo de este desenvolvimiento ni siquiera fueron capaces de prevenir la situación, no cuente con que puedan arreglar la situación.

*La única manera de arreglar esto es escalar a un nivel de gestión más alto. * Si están interesados y son capaces de arreglar esto, ni siquiera tienes que explicar nada más de lo que nos has explicado - sólo hazlo menos personal centrándote en los programas, y los problemas con ellos, en lugar de en el programador.

Deberías saber que esta es una opción de alto riesgo - baja recompensa. Si haces esto, incluso si funciona, el desarrollador y su manager (que probablemente también es tu manager) sufrirán, y sabrán que tú eres el responsable. El único beneficio que obtienes de hacer esto es que estás (posiblemente) siguiendo tu propio código de ética y honor, pero podrías perder tu trabajo por ello. Por eso algunas de las otras respuestas recomiendan dejarlo ir o simplemente buscar un mejor trabajo, que es lo más inteligente.

* La otra forma de arreglar esto es convertirse en gerente usted mismo, y arreglar esto, pero hay bastantes trampas involucradas.

Después de su propia autoevaluación ha decidido que no tiene oportunidad de ser promovido, y la única razón por la que la compañía tendría que mantenerlo es que les está ocultando el código.

No sé si estás de acuerdo con esto, pero si lo estás, el código probablemente podría ser hecho por alguien mejor. O si no explicas por qué este comportamiento asegura que nunca podrá ser promovido.

Creo que se reduce a si vale la pena arreglar esta situación tanto como a cómo arreglarla.

Esta es una tarea para la administración. Primero la gerencia debe tratar de descubrir si esto es intencional. Si es así, se debe hacer un plan para despedir a los infractores. Si no es intencional, se debe hacer un plan para entrenar a los infractores.

Diseñan sus programas… para que sean gradualmente más difíciles de reemplazar.

¡No si yo fuera el jefe!

Hay dos problemas aquí:

1. Mal programador.

2. Gestión incompetente.

Esto es, por supuesto, asumiendo que estás representando la situación correctamente.

No puedes arreglar el problema #1. Hay una ligera posibilidad de que puedas resolver el problema #2. Esta ligera posibilidad es si el jefe, por alguna razón, simplemente no es consciente de lo que está pasando. Ve al jefe, y cuéntale los problemas que ves y por qué son malos para la empresa. Es probable que eso fracase porque el jefe ya conoce el problema y no es competente para abordarlo, o sabe tan poco sobre el software y la gestión de los ingenieros de software que ni siquiera es competente para comprender el problema.

La única solución real es empezar por solucionar el problema nº 2, en el que, en el mejor de los casos, puedes desempeñar un papel menor. El gerente incompetente necesita ser reemplazado.

El nuevo gerente entonces se sienta con este programador, le hace explicar la arquitectura, y le dice que detenga cualquier nuevo desarrollo y documente todos los protocolos. Mientras tanto, consigue un nuevo ingeniero que está ahí para “ayudar” al primer ingeniero con la documentación de los protocolos, poniendo el software en control de fuentes, y asegurándose de que el código en sí está bien documentado. Este nuevo ingeniero hace cualquier nuevo desarrollo, y con suerte corrige errores y mejoras menores del software existente.

Al primer ingeniero no le gustará esto. Puede renunciar, hacer un berrinche, objetar ruidosamente, o peor aún, sabotear cosas. Por eso hacer una copia de seguridad es la primera orden del día. Sería bueno tener una transición suave del primer al segundo ingeniero, pero no esperes que eso suceda. El plan es eventualmente despedir al primer ingeniero, si no renuncia o se vuelve (aún más) destructivo contra la compañía primero.

Simplemente no puedes dejar que esta tontería continúe. Cuanto más tiempo lo hagas, más doloroso será finalmente arreglarlo. No arreglarlo porque ya será doloroso es absolutamente la manera equivocada de pensar en esto.

En este caso estaba usando el “tú” retórico. Para responder a la pregunta de qué puede hacer usted personalmente, empiece por llevar sus preocupaciones al jefe, como dije antes. De nuevo, es poco probable que eso resulte en algo útil.

El siguiente paso depende de las cosas que no nos hayas dicho. Puede ser muy peligroso pasar por encima de tu jefe. Si es así, entonces no hay mucho más que puedas hacer aparte de evaluar si realmente quieres seguir trabajando allí. Si es una empresa lo suficientemente pequeña como para que puedas hablar cómodamente con la alta dirección, entonces adelante. Es muy posible que la alta gerencia ya tenga la sensación de que el gerente de software de bajo nivel es incompetente, pero por supuesto no te lo van a decir. Esta podría ser la información adicional para que ellos tomen una acción más decisiva.

Otra posibilidad lejana, si tu objetivo principal es arreglar este lío y te ves a largo plazo en este lugar, es ofrecerte a encargarte tú mismo del desarrollo de la herramienta interna. Eso debería darte una razón legítima para hablar con el primer ingeniero, entender cómo funcionan las cosas, dónde vive el código, etc. Eventualmente, serías el chico de las herramientas y la gerencia puede deshacerse del primer ingeniero. Luego puedes pedirles que contraten a alguien para ese rol, para que puedas hacer la transición de vuelta a lo que quieres hacer. De nuevo, esto no es algo que sugiera seriamente, pero es una alternativa si realmente quieres y estás dispuesto.