development-environment - tengo - soy administrador pero no puedo hacer cambios

¿Deben los desarrolladores tener permisos de administrador en su PC? (21)

¿Deben los desarrolladores tener permisos de administrador en su PC o les está dando suficiente acceso a los usuarios avanzados?

Algunos comentarios:

Si quieren probar alguna aplicación nueva que requiera instalación, entonces pueden probarla en una máquina virtual y luego pedirle al administrador de red que la instale. ¿Crees que eso funcionaría?
¿Hay algo que un desarrollador deba hacer en su PC que requiera permisos de administrador?

Somos un equipo de 5 desarrolladores y desarrollamos aplicaciones web

Sin usuario avanzado

En primer lugar, Power User es básicamente un administrador, por lo que " limitar " a un usuario a Power User no proporciona ningún aumento en la seguridad del sistema; también podría ser un administrador.

Inicie sesión interactivamente como un usuario normal

En segundo lugar, por supuesto, un desarrollador necesita acceso administrativo a su máquina de desarrollo (y servidores y segundos cuadros, etc.) pero, por supuesto, nadie debe iniciar sesión de forma interactiva como administrador durante el desarrollo normal o las pruebas. Use una cuenta de usuario normal para esto y para la mayoría de las aplicaciones.

En serio, no desea ejecutar [inserte ningún navegador, complemento, mensajería instantánea, cliente de correo electrónico, etc.] como administrador.

Normalmente, tampoco inicia sesión en su cuadro de Linux como root, incluso si es probable que tenga acceso a la raíz cuando lo necesite.

Use una cuenta de administrador personal separada

Proporcione al desarrollador una cuenta de administrador personal separada para su máquina (preferiblemente una cuenta de dominio) que también sea un administrador válido en otros servidores y servidores de desarrollo / prueba a los que la persona necesita acceso administrativo.

Utilice "ejecutar como" y en Vista + UAC para solicitar o solicitar un aviso e ingresar las credenciales administrativas para tareas y procesos solo cuando sea necesario. PKI con tarjetas inteligentes o similares puede reducir enormemente la tensión al ingresar credenciales a menudo.

Todos están felices (o?)

Luego audita el acceso. De esta forma hay rastreabilidad y una manera fácil de descubrir quién está usando las sesiones de servicios de terminal en un servidor de prueba / desarrollo particular al que tiene que acceder en este momento ...

Ciertamente, definitivamente hay trabajo de desarrollo que nunca requerirá privilegios de administrador local, como la mayoría del desarrollo web donde la implementación se prueba en un servidor o máquina virtual separada y donde cassini o lo que se usa para la depuración local realmente funciona bien como un usuario normal.

¡Absolutamente! ¿De qué otra forma podría instalar el administrador de descargas para descargar películas por la noche?

A veces los desarrolladores realmente necesitan instalar cosas o cambiar algo en el sistema para probar alguna idea. Será imposible si debe llamar al administrador cada vez que necesita cambiar algo.

También tengo mi observación personal de que algunos administradores tienden a apretar todo lo que es posible para que incluso las pequeñas cosas dependan de ellos diariamente, así ... ¿qué? ¿Asegurando su trabajo? molestando a los otros usuarios? No tengo respuesta Pero el sentido común no se ve aquí.

La última vez que tuve un problema con mi PC, tomé parte activa en la restauración del sistema, hice algunas sugerencias trabajando en el equipo con el administrador, o al menos eso pensé ... Admin se volvió muy enojado y me acusó de intentar enseñar él o redefinir las reglas. Supongo que era solo su ego, ya que no se lo veía tan bien en nuestra habitación, entre otros colegas.

¡La respuesta es que los desarrolladores deberían tener 2 máquinas!

Uno de desarrollo que tiene derechos de administrador y poder suficiente, memoria, tamaño de pantalla y portabilidad, y privilegios de ADMIN, con software antivirus corporativo cargado pero configurable por el desarrollador cuando sea necesario con la política de autoreset.
Uno corporativo que tiene carga corporativa, políticas, privilegios de usuario no administrador, etc. El desarrollador puede usar este para pruebas de unidades de modo de lanzamiento de aplicaciones ya que algunos desarrolladores tienen la desagradable costumbre de hacer todas las pruebas unitarias con privilegios de administrador.

Administrador local sí, por todos los motivos indicados anteriormente. Network admin no, porque inevitablemente se verán atraídos por las tareas de administración de red porque "pueden". Los desarrolladores deberían estar en desarrollo. La administración de red es un trabajo completamente diferente.

Como administrador de sistemas, soy todo para desarrolladores que tienen derechos de administrador local en sus estaciones de trabajo. Cuando sea posible, no es una mala idea hacer la mayoría de las cosas con una cuenta de nivel de usuario estándar y luego usar otra cuenta de administrador para realizar cambios, instalar aplicaciones, etc. A menudo puede sudo o runas para lograr lo que quiere sin tener que iniciar sesión. fuera. También es útil recordarnos qué obstáculos de seguridad tendrán que pasar los usuarios finales al lanzarlos a la producción.

En una nota lateral, también es aconsejable tener un sistema [limpio] o VM (s) para que pueda probar las cosas correctamente y no entrar en el escenario "se ve / funciona bien en mi sistema" debido al ajuste del sistema.

Depende de las habilidades del desarrollador y de si es o no consultor.

Creo que es razonable que un desarrollador avezado y confiable tenga los derechos de hacer lo que quiera con su PC siempre que no perjudique su productividad.

En mi empresa, los desarrolladores, ingenieros y mi jefe (propietario de la empresa) tienen privilegios de administrador local. Mi jefe también tiene privilegios de administrador de red, solo en caso de que me golpee ese autobús descarriado (o lo dejen). Todos los demás se bloquean.

Como sysadmin, esta configuración me ha causado un poco de dolor de vez en cuando, especialmente cuando se instala un software no aprobado. Sin embargo, viniendo de un entorno de desarrollador, entiendo la necesidad de que los usuarios avanzados tengan más control sobre su entorno y, como tal, estoy dispuesto a aguantar el capricho o problema ocasional que pueda surgir. Realizo copias de seguridad de rutina de sus estaciones de trabajo, por las dudas.

Por cierto, he tenido más problemas con el jefe jugando con cosas que con cualquier otra persona. Algo así como la vieja pregunta: "¿Dónde se sienta un elefante? ¡A donde quiera!" Pero en una pequeña empresa en la que él es esencialmente el administrador de respaldo "sysadmin", no hay muchas opciones.

Habiendo soportado el dolor de tener que desarrollar sin derechos de administrador en la máquina, mi respuesta solo puede ser sí, es esencial.

La respuesta es sí''. Los desarrolladores necesitarán frig con configuraciones de sistema para probar elementos, instalar el software (para probar el proceso de instalación de lo que sea que estén desarrollando), explorar el registro y ejecutar un software que no funcionará correctamente sin privilegios de administrador (solo para enumerar algunos artículos). Hay una serie de otras tareas integrales para el trabajo de desarrollo que requieren privilegios de administración.

Teniendo en cuenta que el personal de desarrollo no necesariamente tiene acceso root a los sistemas de producción, los derechos de administrador en una PC local no comprometen significativamente la seguridad de los sistemas de producción. Prácticamente no existe una razón operacional legítima para restringir el acceso de los administradores a las PC locales para el personal que lo necesita para hacer su trabajo.

Sin embargo, la razón más importante para proporcionar acceso administrativo es que la configuración de un entorno de desarrollo comprometido o de segunda clase envía un mensaje a su personal de desarrollo:

"Valoramos tanto su trabajo que estamos preparados para comprometer significativamente su capacidad de hacer su trabajo sin una buena razón. De hecho, estamos muy contentos de hacer esto para cubrir nuestro propio culo, complacer los caprichos de la pequeña burocracia o porque simplemente no nos molestan. Ese es solo el mejor caso. En el peor de los casos, somos en realidad el tipo de fanáticos del control que lo ven como nuestro criterio para decirle cómo hacer su trabajo y qué necesita o no tiene que hacer. Acéptate con lo que te dan y sé agradecido de que hayas conseguido un trabajo.

Generalmente, proporcionar un entorno de trabajo de segunda categoría (para no mencionar fundamentalmente defectuoso) para el personal de desarrollo es una receta para las consecuencias naturales de cabrear a su personal: incapacidad para retener personas competentes, alta rotación de personal, baja moral y entrega de mala calidad. Salir de tu camino para hacerlo, especialmente si hay un matiz de complacer al capricho burocrático, es simplemente irresponsable.

Tenga en cuenta que la rotación de su personal no implica gastos de sustitución del personal. El costo más serio de la rotación de personal es que la mayoría de los que se quedan serán la madera muerta que no puede obtener un mejor trabajo. Con el tiempo, esto degrada las capacidades de los departamentos afectados. Si su industria está lo suficientemente cerca, también puede encontrarse obteniendo una reputación.

Un punto a tener en cuenta es que los privilegios administrativos son mucho menos un problema para el desarrollo en sistemas unix-oid o mainframe que en Windows. En estas plataformas, un usuario puede hacer mucho más en su propio dominio sin necesitar permisos en todo el sistema. Es probable que aún desee acceso raíz o sudo para los desarrolladores, pero no tenerlo se pondrá en marcha con mucha menos frecuencia. Esta flexibilidad es una razón importante pero menos conocida para la continua popularidad de los sistemas operativos derivados de Unix en las escuelas de informática.

Los desarrolladores deben tener el control completo y total de la máquina que están utilizando. La mayoría de las herramientas de depuración requieren permisos de administrador para conectarse al tiempo de ejecución de la aplicación que están creando.

Además, los desarrolladores frecuentemente descargan y prueban cosas nuevas. Agregar pasos adicionales, como la necesidad de que un administrador de red visite e instale algo para ellos, simplemente frustra al desarrollador y rápidamente hará la vida imposible para la persona de operaciones de red.

Dicho esto, deberían ser administradores en su caja, no en la red.

Los desarrolladores normalmente necesitan hacer cosas que la persona promedio no haría, y normalmente deberían tener cuentas de administrador. Hacerlos saltar a través de aros incómodos les hace perder el tiempo y los desmoraliza. Puede haber excepciones en situaciones de alta seguridad, pero si no puede confiar en alguien con una cuenta de administrador, seguro que no puede confiar en su código.

También deberían tener una cuenta disponible del mismo permiso que sus usuarios (más de una cuenta si el grupo de usuarios tiene diferentes estados de permisos). De lo contrario, pueden desarrollar algo interesante, implementarlo y luego descubrir que no funcionará para los usuarios.

También hay demasiadas formas de arruinar las computadoras con cuentas de administrador (sí, lo he hecho). El departamento de TI necesita una política que vuelva a crear una imagen de la computadora de un desarrollador si no puede solucionarlo rápidamente. En un lugar contratado en, tuve que firmar una copia de esa política para obtener mi cuenta de administrador.

Esta es una bonita respuesta específica de Windows. En Linux y otros sistemas Unix-y, los desarrolladores a menudo pueden arreglárselas solo con cuentas de usuario, a menudo no necesitan otra cuenta para la prueba (si tienen una cuenta con la que pueden hacer suing, saben cuándo están usando el sudo, pero pueden necesitar uno con los mismos permisos de grupo), y pueden causar daños increíbles en el sistema operativo con mucha facilidad, por lo que es necesaria la misma política de TI.

Nadie en Windows XP debería usar una cuenta de administrador para el uso cotidiano, y en Vista, si debe ser un administrador, al menos debe haber habilitado el UAC. Especialmente desarrolladores web y otros desarrolladores que navegan por la web con Internet Explorer.

Lo que puede hacer es que los desarrolladores usen su cuenta de usuario habitual, pero proporcióneles una segunda cuenta que sea un administrador en su PC para que puedan usarla según sea necesario (Ejecutar como). Sé que dijeron que el desarrollo web, pero para el desarrollo de Windows su software debe ser probado con una cuenta de usuario normal, no como administrador.

Puedes responder esto de dos maneras. Sí y no, o depende. - ¿Puedo ser más vago ...?

Depende si se requiere que hagan su trabajo. Si es así, otórgales poderes administrativos sobre su computadora. Si no, no lo hagas. No todo el desarrollo de software requiere que un ingeniero tenga derechos de administrador.

Sí y no depende de su punto de vista. Algunos ingenieros ven su computadora como su dominio y son las reglas de su dominio. Otros no quieren la responsabilidad.

Trabajé en una compañía donde no tenía derechos de administrador y cada vez que necesitaba hacer algo que requería derechos de administrador tenía que llamar a la mesa de ayuda y me otorgaban derechos de administrador temporal hasta que reiniciaba. Esto fue un dolor a veces, pero así era, así que viví con eso. También trabajé en lugares en los que tengo todos los derechos de administrador de mi computadora. Esto fue genial, excepto por el tiempo que instalé algún software que manejaba el sistema operativo y tuve que llevar mi computadora a la mesa de ayuda y hacer que volvieran a crear la imagen del disco duro ...

Personalmente, creo que un ingeniero debe tener derechos de administrador en su computadora, pero con la condición de que si lo arruinan, se puede volver a cargar una nueva imagen de línea base y perderán todo lo que se hizo desde la línea base original. No obstante, no creo que todos en una empresa tengan derechos de administrador en su computadora. Los contables, los asistentes administrativos y otros departamentos realmente no necesitan tener esos derechos, por lo que no deberían ser otorgados.

Sí, Half-Life 1 (y todas las modificaciones relacionadas: counter-strike, día de la derrota, etc.) necesitan derechos de administrador (al menos para la 1ª ejecución, creo) para funcionar correctamente en Windows NT, 2000, XP, etc. .

Y, ¿qué tipo de desarrollador no juega Counter Strike a la hora del almuerzo? (un asqueroso seguro)

Sí, pero deben ser conscientes de las limitaciones que enfrentarán sus usuarios cuando ejecuten software en un entorno más limitado. Los desarrolladores deberían tener fácil acceso a entornos "típicos" con recursos y permisos limitados. En el pasado he incorporado la implementación de compilaciones a uno de estos sistemas "típicos" (a menudo una VM en mi propia estación de trabajo) como parte del proceso de compilación, de modo que siempre podía tener una idea rápida de cómo funcionaba el software en un final máquina del usuario

Los programadores también tienen la responsabilidad de conocer las reglas de escritura de software para usuarios que no son administradores. Deben saber exactamente a qué recursos del sistema están autorizados (o prohibidos) acceder. Deben conocer las API que se utilizan para adquirir estos recursos.

"Funciona en mi máquina" ¡nunca es una excusa!

Si inviertes la pregunta, creo que se vuelve más fácil responder; ¿Deberíamos eliminar los permisos de administrador de los desarrolladores? ¿Cuál es la ganancia?

Pero en realidad, creo que la respuesta depende de tu contexto, tu entorno. El pequeño emprendimiento tendrá una respuesta diferente a la agencia gubernamental certificada por ISO.

Si y no.

Sí, ahorra mucho tiempo molestando el soporte del sistema.

No, tus usuarios no lo tienen así que no confíes en él.

Desarrollamos con permisos de administrador y prueba sin. Lo cual funciona bien.

Wow, esta pregunta ciertamente se abrirá a algunas respuestas interesantes. En respuesta, cito el que se usa a menudo: ''It Depends'' :)

En las pequeñas empresas esto podría ser simplemente una cuestión de ser pragmático. Es probable que los desarrolladores sean los más hábiles técnicamente, por lo que tiene sentido que administren sus propias máquinas.

Personalmente, soy un fan de la "cuenta de administrador" que se puede usar cuando sea necesario, es decir, "Ejecutar como ..." (noté que este enfoque era muy similar en principio a UAC más adelante).

Si está desarrollando software de escritorio, no es una mala idea para los desarrolladores trabajar dentro de los límites que experimentará el usuario final, es decir, derechos limitados o restringidos. Si construye el software con derechos limitados, es muy probable que tenga los mismos problemas que los usuarios objetivo enfrentarían con el mismo conjunto de permisos.

Habiendo dicho eso, si tienes un buen laboratorio de pruebas y / o un equipo de control de calidad decente, este podría ser un punto discutible, especialmente si tienes una práctica de ALM medianamente decente.

Entonces, finalmente, desarrollo sin UAC, principalmente porque confío en mí mismo y en mis habilidades. En un ambiente de equipo, lo pondría a votación. En organizaciones más grandes, es posible que no tenga esta libertad. Los administradores de la empresa a menudo tienen la última palabra :)

[disculpa el inglés no es mi lengua materna, haciendo mi mejor esfuerzo :)] Bueno,

Experiencia personal (soy un desarrollador de c ++ / SQL):

Solía ser el administrador de mi máquina de Windows en mi trabajo anterior. También tenía derechos dbo (no dba) en las bases de datos, incluidas las bases de datos del entorno de producción. En 2 años y medio con 8 personas que tienen estos elevados derechos ... nunca tuvimos ningún problema. En realidad, resolvimos muchos problemas actualizando db manualmente. Podríamos hacer muchas cosas realmente rápido para arreglos urgentes y desarrolladores.

Ahora cambié de trabajo. Me las arreglé (llorando mucho) para ser administrador de mi máquina de Windows. Pero el servidor de desarrollo es un servidor de sombrero rojo al que nos conectamos mediante ssh. Intentar instalar Qt fue una tortura, límites de cuota, límites de espacio, ejecución y derechos de escritura. Finalmente nos dimos por vencidos y le pedimos al administrador que lo hiciera por nosotros. 2 semanas después todavía no está instalado nada. Me estoy volviendo muy rápido en la lectura de periódicos y en el alt + tab hitting.

Pedí derechos de administrador, ya que solo el desarrollador de mi software usa esta máquina.

-> Respuesta: "Si hay procesos es para que no hagas lo que quieras. Tiene que funcionar bien una vez en prod".

-> Tratando de explicarle a un gerente no técnico: "No tendré ningún derecho de administrador en entornos de producción o UAT. Pero mi máquina de desarrollo es diferente. Si tuviera que construir sillas en lugar de software, ¿podría decirme que puedo? Pongo todas las herramientas que quiero en mi taller porque mi taller debe verse como el lugar donde se usará la silla. Le doy un paquete ejecutable. Las librerías y herramientas que utilicé para construirlas son invisibles para el usuario final o para el tipo instalando el paquete ".

Todavía estoy esperando hoy. Encontré una solución, abrí un entorno de desarrollo, fui a tu juez en línea favorito, me desafío a ti mismo. cuando alguien mira tu pantalla, te estará viendo la programación. ;)

ht tp: //msdn.microsoft.com/en-us/library/aa302367.aspx

En mi experiencia, siempre se necesita un compromiso entre nosotros (codificadores) y ellos (seguridad). Lo admito (aunque odio), hay un mérito en el artículo anterior de Microsoft. Como he sido programador durante años, he experimentado el dolor donde necesitaba instalar un depurador diferente, solo para molestarme. No puedo. Me obligó a pensar creativamente en cómo hacer mi trabajo. Después de años de luchar contra nuestro equipo de seguridad (y varias discusiones), entiendo su trabajo de tener que proteger todas las áreas, incluido mi escritorio. Me mostraron las vulnerabilidades diarias que aparecen, incluso en la aplicación Quicktime más simple. Puedo ver su frutering cada vez que quiero instalar una utilidad rápida o ajustar mi IIS local para que pueda causar un problema serio de seguridad. No entendí completamente esto hasta que vi a otro desarrollador obtener enlatados. Estaba intentando depurar y terminó cerrando Symantec solo para obtener (y luego DAR) algunos virus a cientos de personas. Fue un desastre. Al hablar con uno de los "secheads" (chicos de seguridad) sobre lo que sucedió, pude ver que solo quería decir "te lo dije ...".

He aprendido que nuestros clientes (bueno, al menos los míos) solo quieren proteger a nuestra compañía. ¡La buena noticia es que encontramos un compromiso, y puedo hacer mi trabajo y las secheads son geniales con nuestra red segura!

Credo

Trabajo principalmente en el mundo * nix y el modelo estándar que hay para que los desarrolladores trabajen en una cuenta de usuario normal, sin privilegios con la capacidad (a través de sudo o su ) para escalar a privilegios de administrador cuando sea necesario.

No estoy seguro de cuál sería el acuerdo de Windows equivalente, pero esta es, en mi experiencia, la configuración ideal:

Por un lado, tener derechos de administrador disponibles bajo demanda le da al desarrollador pleno poder sobre su estación de trabajo cuando sea necesario.
Por otro lado, el software de Windows tiene un largo, largo historial de asumir que todos los usuarios tienen derechos de administrador, hasta el punto de que muchos programas no se ejecutarán para un usuario que no sea administrador. Muchos de los problemas de seguridad de Windows surgen directamente de este requisito implícito de que, para poder usar la computadora de manera confiable, todos los usuarios deben ser administradores. Esto debe cambiar y la forma más efectiva de garantizar que su software se ejecute para usuarios que no sean administradores es que sus desarrolladores lo ejecuten ellos mismos como usuarios que no son administradores.