Tercerización de servicios (y la seguridad asociada)

Una de las cosas con las que frecuentemente solemos toparnos los desarrolladores, consultores y tecnócratas en general, es con la administración de permisos y seguridad en las redes. Si se tiene una empresa pequeña, unos 25 empleados en plan Fabrica de Software, pues.. lo normal es que todos los desarrolladores sean administradores locales, se establezca una política para subir cambios a un entorno de Desarrollo común, estable. Pasadas las pruebas del equipo de desarrollo, pasamos a un ambiente de pre-producción donde otras personas ejecutan sus test. Esto.. en plan pequeño.
Que sucede cuando nuestra compañía es una empresa de mas de 100 empleados, con personas con computadores portátiles, y donde hay tercerizados (esto es, nuestra empresa sub-contrata a otras empresas para labores específicas)? Cómo se determinan los privilegios administrador/usuario avanzado/colaborador/solo lectura?
En mi recorrido, creo que una práctica sana sería: los desarrolladores como usuarios restringidos en sus equipos, pero con una máquina virtual con la que puedan "trastear" y desarrollar. Políticas de supervisión de navegación en el proxy para limitar las cosas que pueden acceder (dudo que Youtube tenga algo interesante para un programador). Si el requerimiento es prohibir a los usuarios estar todo el dia conversando por MSN/GTALK (que me parece iluso, uno puede ser tan o incluso mas productivo y usar estas herramientas), algun cliente de mensajería que puedan usar los miembros del equipo de desarrollo, pero que no permita comunicación web (algo tipo MS Comunicator). Un servidor de fuentes, y una política acertada de cambios en servidores (a desarrollo puede ser diaria, mientras que a otros entornos, semanales o mensuales). A los miembros tercerizados, se les pudiese crear un "grupo" de Active Directory con pemisos similares a los del grupo de desarrollo local.
El asunto que vendría a complicar todo es: quien maneja el AD? personal de la empresa, o se subcontrata? esto es un asunto espinoso, ya que hay empresas en las que la burocracia y procedimiento de cambios en ambientes de explotación, suelen demorar mucho y pasar por tantos niveles, que mas que controlar la seguridad, entorpecen el desarrollo y mantenimiento de aplicaciones.

Rompiendo los ladrillos

De jovencito, recuerdo mi fascinación por los tipos que rompían ladrillos a punta de golpes: Manos, cabeza, piernas, rodilla. Todo era permitido. Me los imaginaba super fuertes. Un día, mi primo, que de eso sabía bastante, me indicaba no lo rompes solo con una parte del cuerpo, sino con todo el cuerpo. El peso ejerce un enorme poder al momento de transmitir algo....

Recuerdo también la "estela de la destrucción": los ladrillos que estaban arriba tenian pequeñas fracturas que a medida que se descendía, era mayor. Hasta llegar a los últimos ladrillos que quedaban desmenuzados.

Ya de "mayorcito" me he fascinado al ver como ese mismo fenómeno se repite en las oficinas. El Jefe Superioris está haciendo algo y le falla un sistema (digamos, un hipervínculo no se muestra en una página web). Comienza el proceso de "estela de destrucción": el dichoso jefe transmite a un gerente de primera linea (el CIO, el responsable de TI, etc, etc etc) la "incidencia" con un "sabes que me pasó esto". Empieza allí el calvario: "ya te envío a alguno de los muchachos para que lo resuelva" o "Que raro? ese comportamiento no es normal". Sigue un "vamos a escalarlo con el personal apropiado para verificar el porqué ocurre eso". Frases acartonadas van y vienen cual manual de protocolo. Y así comienza la estela. El gerente de primer nivel le dice al de segundo "el Jefe me manifestó que hay algo en la aplicación X que no le funciona". El de segundo al de tercero: "el jefe/dueño/manda más/chivo que mas mea/papá de los helados le dijo al gerente qe algo no le funciona". y sigue con un "el XXX le armó un rollo al gerente porque algo no le funcionó, y nos están presionando para que lo resolvamos lo mas pronto posible" hasta que llega al último nivel:
- Se presentó una incidencia, la aplicación falló totalmente (la desmesura de las palabras y lo exagerado de la situación) mientras la usaba el sr. Fulanito, se han encendido varias alarmas porque es algo que no salió en ninguna prueba...
- Disculpa, fulano... una pregunta..... según veo aquí, la incidencia es porque las palabras que constituyen un hipervínculo.. el mouse no cambia de puntero a la manito típica ni se subraya...
- Eso es correcto, pela_patatas_01
- Vale.. Es que.. según el correo enviado por el subgerente_posición_51 cuando la definición de requerimientos, dijeron que no querían que los hipervínculos tuviesen el subrayado ni el cambio del mouse, ya que querían que fuese un texto lo mas compacto, ultraliviano y que nada destacase por encima del resto de las palabras.....

Sorpresa, sorpresa. Comienza entonces una serie de reuniones con usuarios, gerents, desarrolladores, el Papa Juan Pabl.. ahh, que ahora es Ratzinger. Bueno.. en fin. La negociación típica de plazos, de eso no estaba en los requisitos iniciales, que el cambio cuesta tanto, que eso es mucho dinero para algo tan minúsculo, que si, que si no.. que es para el gerente, que se aprueban los 200 mil $ presupuestados... y al final, son los pobres programadores luchando para ver donde rayos estaba el condenado 'a href' que fallaba, con un plazo de 2 días, y si no lo cumples, corre que te despido!!

En fin.. que la terminan pagando los curritos, mientras que el jefe superioris se sorprende que el gasto de su departamento de TI se gaste 200mil $ colocando un 'a href'.. ahh.. no.. en un "proyecto de actualización, mejora y upgrade de las capacidades gráficas de la aplicación"...

Ya decía yo, El peso ejerce un enorme poder al momento de transmitir algo.... sobre todo si es el jefe superior quejándose de algo a los "mortales" que tiene por debajo en el organigrama