Permisos de Windows para desarrolladores?

Trabajo en una compañía Fortune 500 como desarrollador de software de Windows en I + D. Actualmente, la TI corporativa se está preparando para una implementación de Win7 en toda la empresa y, como parte de ella, buscan bloquear completamente los derechos de administrador en todos los cuadros (incluidas nuestras estaciones de trabajo de desarrollo).

Se me ha encomendado trabajar con ellos para que la transición sea lo más fluida posible. Suerte la mía.

Me gustaría saber si hay recursos publicados u otros recursos altamente respetados que pueda usar para:

1. averiguar dónde dibujar una línea en la arena
2. respaldar mi posición.

Personalmente, mi opinión es que estamos en I + D y nuestro trabajo es hacer cosas que están "listas para usar". Por lo tanto, necesitamos derechos de administrador. Sin embargo, después de comenzar mi carrera como administrador de Windows, soy consciente de sus objetivos y de lo que necesitan lograr. Lo que necesito descubrir y respaldar es una forma de construir el entorno de manera que tanto TI como I + D puedan vivir con él y continuar desempeñando su trabajo de manera productiva.

Las máquinas virtuales de desarrollo con derechos de administrador local definitivamente ayudarán mucho, pero no en todos los casos ya que interactuamos con una gran cantidad de hardware personalizado.

El CIO que está impulsando estos cambios es definitivamente un tipo de 'puro IT' con conocimiento limitado del proceso de desarrollo, por lo que necesito algunas referencias que serían apropiadas para compartir con alguien así.

No estoy buscando reunir muchas opiniones personales (muchas de las cuales ya se han compartido aquí ), realmente necesito documentos técnicos, artículos de revistas, trabajos académicos, etc.

Debido a que va específicamente a Windows 7, debe esforzarse mucho para ser administradores en sus propios cuadros. Hay dos razones realmente buenas para evitar que los desarrolladores sean administradores:

• la misma razón por la que evitas que todos los demás sean administradores, para que el malware no haga cosas realmente horribles si se ejecuta
• para que no escriban aplicaciones que solo funcionan si eres administrador

Con UAC, ninguna de estas cosas sucederá, ya que las aplicaciones que inicies no se ejecutarán como administrador a menos que se lo pidas deliberadamente. Por lo tanto, hay poco riesgo de permitirle tener una cuenta de administrador.

Algunos jefes tienen una tercera razón: no quiero que instales juegos o herramientas no autorizadas. Sin discutir los méritos de esta razón, observaré que usualmente permanece sin declarar. Necesita acceso de administrador para instalar lo que está escribiendo, configurar IIS, reconfigurar su máquina para varios tipos de pruebas (por ejemplo, editar su archivo host) y las dos razones "reales" para evitar el acceso de administrador ya no se aplican a Windows 7 Por lo tanto, deben ser administradores.

Honestamente, creo que será un caso difícil de hacer. Una vez que la alta gerencia toma una decisión, es bastante difícil lograr que cambien. Si permitieran más privilegios en su máquina, alguien más podría acceder y realizar las acciones para las cuales todo este plan fue diseñado.

Estos pueden ayudar:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

PD: ¡Mucha suerte!

Una opción es solicitar estaciones de trabajo de prueba que permitan el acceso administrativo.

Otra opción es hacer exactamente lo que dicen. Luego, cuando llegue el próximo proyecto, no avanzará porque tiene que ir a TI para cada pequeño cambio. Explique esto al líder del proyecto, y él se encargará de los derechos de administrador rápidamente.

Una tercera opción es verificar si su departamento está representado en el proyecto de migración de Win7. Si es así, comuníquese con su representante y pregúntele si puede agregar derechos administrativos a la lista de requisitos de su departamento.

Una cuarta opción es comerciar. El proyecto de migración generalmente necesita desarrollo para actualizar su software para Win7. Podría ser posible condicionar una actitud de apoyo a los derechos administrativos en el nuevo entorno.

No puedo imaginar tratar de desarrollarme sin ser un administrador local, sin embargo, creo que las necesidades variarán dependiendo de las tareas de desarrollo y de lo estandarizado que sea el proceso de desarrollo y la cadena de herramientas en su lugar de trabajo.

Según mi experiencia, generalmente hay personal de desarrollo senior que necesitará instalar varias herramientas de desarrollo (a veces en horas impares) para crear prototipos rápidamente o solucionar problemas críticos. Es casi seguro que necesitan acceso de administrador local para instalar, depurar, trabajar con servicios, etc.

El resto del personal puede sobrevivir sin él, si su conjunto de herramientas es bastante constante y depende de lo que desarrollen / depuren / implementen. Mi sugerencia sería reunir a un pequeño grupo de su personal de desarrollo senior más equilibrado, explicar el problema y sus opciones, y hacer que tomen un par de días para considerarlo, y luego tener una reunión de planificación para determinar qué tipo de acceso el personal debería haberlo hecho.

Desde una perspectiva de TI pura y una perspectiva de desarrollo, muchas empresas resuelven el problema de esta manera:

Ponga todos los cuadros de desarrollo en una red separada. La red de desarrollo podría estar completamente aislada (sin internet ni intranet). En este caso, los desarrolladores tienen una caja corporativa separada que se utiliza para el correo electrónico y las comunicaciones oficiales, es decir, acceso a Internet e intranet. Esta solución tiene sus propios desafíos, ya que ciertos IDE (como Eclipse) y otras herramientas de desarrollo suponen que tiene una conexión en vivo a Internet para obtener actualizaciones y complementos. Aún así, la gran mayoría de las herramientas de desarrollo saben que existen redes aisladas.

Otra variación de este enfoque es tener la red de desarrollo en una subred. Tiene acceso indirecto a Internet e intranet a través de un estricto firewall DMZ, pero los desarrolladores aún tienen acceso de administrador local.

Considere darles a los desarrolladores dos cuentas.

La primera es una cuenta de usuario normal sin privilegios, que es la que se utiliza para todo el trabajo diario (incluido el desarrollo de software). La otra es una cuenta de administrador local, que solo tiene privilegios de administrador en máquinas específicas. Solo debería ser necesario al instalar cosas o ajustar la configuración de la máquina.

Asegúrese de que los servicios cotidianos, como el servidor proxy de Internet, el correo electrónico, etc., solo reconozcan la cuenta normal, de modo que los desarrolladores no puedan usar el administrador local todo el tiempo. Siempre que se requieran privilegios de administrador, UAC aparecerá y le ofrecerá al desarrollador la oportunidad de ingresar sus detalles de inicio de sesión de administrador local para continuar.

El desarrollo de software es una bestia fundamentalmente diferente de literalmente cualquier otro uso de una computadora, y debe tratarse como tal.

La capacidad de escribir su propio código y, lo que es más importante, rastrear la ejecución de su código en la depuración, requiere que tenga permisos en su computadora que, en cualquier otro contexto, supondría un gran riesgo para la seguridad local. Reformulado en forma de sonido:

Los permisos requeridos para el desarrollo de software no son apropiados para los usuarios típicos.

Para realizar su trabajo, debe ser administrador local. Pero al ser administrador local y eludir la política de seguridad, teóricamente representa un riesgo para el resto de la red. Por lo tanto, esa preocupación también debe abordarse. La forma en que las empresas críticas para la seguridad resuelven este problema es imponiendo dos reglas simples:

1. Los programadores tienen acceso de administrador local en su máquina de desarrollo.
2. Las máquinas de desarrollo no están conectadas a la red de la empresa.

Cómo se desarrolla la segunda regla depende del departamento de TI. A veces, la máquina de desarrollo está aislada por sí sola sin una red de entrada o salida (vista en varios contratistas de Defensa), y a veces la máquina está conectada a una red "Invitada" o "DMZ" para permitir el acceso a Internet (descarga de parches, acceso a la documentación , etc.) sin poner la red de la empresa en riesgo indebido.

Ahora, ¿encontrará alguna fuente oficial sobre esto? Supongo que eso depende de a quién veas como oficial . La opinión sobre este asunto es básicamente unánime. Pero se entiende tan bien que rara vez se dice. Es un poco como preguntar: " ¿Debería mi automóvil tener un freno de estacionamiento? "

¿Se puede usar un entorno virtual?

Si no está haciendo cosas pesadas con los gráficos, entonces ejecutar MSVC en vmware o virtualbox está bien (si tiene mucha memoria RAM), entonces puede tener administrador en el entorno virtual y 'su' instalación está bloqueada