¿Deberían los desarrolladores tener permisos de administrador en su PC?

¿Deberían los desarrolladores tener permisos de administrador en su PC o les está dando suficiente acceso de usuario avanzado?

Algunos comentarios:

• Si quieren probar alguna aplicación nueva que deba instalarse, pueden probarla en una máquina virtual y luego pedirle al administrador de la 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 creamos aplicaciones web

La respuesta es sí'. Los desarrolladores necesitarán adaptarse a las configuraciones del sistema para probar elementos, instalar software (por lo menos, para probar el proceso de instalación de lo que sea que estén desarrollando), hurgar en el registro y ejecutar 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 raíz 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. Casi no hay una razón operativa legítima para restringir el acceso de administrador 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 creación de un entorno de desarrollo comprometido o de segunda categoría envía un mensaje a su personal de desarrollo:

'Valoramos tan poco su trabajo que estamos preparados para comprometer significativamente su capacidad de hacer su trabajo sin ninguna buena razón. De hecho, estamos muy contentos de hacer esto para cubrir nuestro propio trasero, complacer los caprichos de la pequeña burocracia o porque simplemente no podemos ser molestados. Ese es solo el mejor caso. El peor de los casos es que somos realmente el tipo de fanáticos del control que lo ven como nuestra perogativa para decirle cómo hacer su trabajo y qué debe hacer o no hacer. Haz lo que te dan y agradece que hayas conseguido un trabajo.

En general, proporcionar un entorno de trabajo de segunda categoría (y mucho menos fundamentalmente defectuoso) para el personal de desarrollo es una receta para las consecuencias naturales de enojar a su personal: incapacidad para retener a personas competentes, alta rotación de personal, baja moral y entrega de baja calidad. Salir de su camino para hacerlo, particularmente si hay un trasfondo de complacencia al capricho burocrático, es simplemente irresponsable.

Tenga en cuenta que la rotación de su personal no solo implica costos de reemplazo del personal. El costo más serio de la rotación del personal es que la mayoría de los que se quedarán 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 encontrar una reputación.

Un punto a tener en cuenta es que los privilegios administrativos son mucho menos problemáticos 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 necesidad de permisos en todo el sistema. Probablemente aún desee acceso root o sudo para los desarrolladores, pero no tener esto se pondrá mucho menos a menudo. Esta flexibilidad es una razón significativa pero menos conocida de la continua popularidad de los sistemas operativos derivados de Unix en las escuelas de informática.

Los desarrolladores deben tener un control total 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 descargan y prueban cosas nuevas con frecuencia. Agregar pasos adicionales, como la necesidad de que un administrador de la red venga e instale algo para ellos, simplemente frustra al desarrollador y rápidamente convertirá la vida en un infierno para la persona de operaciones de la red.

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

Si y no.

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

No, tus usuarios no lo tienen, así que no cuentes con él.

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

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

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

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

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

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

Sí, Half-Life 1 (y todas las modificaciones relacionadas: contraataque, día de la derrota, etc.) necesitan derechos de administrador (al menos para la primera 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? (uno horrible, seguro)

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

¡Absolutamente! ¿De qué otra manera instalaría 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 tiene que llamar al administrador cada vez que necesite cambiar algo.

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

La última vez que hubo un problema con mi PC, participé activamente en la restauración del sistema, haciendo algunas sugerencias trabajando en el equipo con el administrador, o eso pensé ... El administrador se enojó mucho y me acusó de tratar de enseñar. él o redefinir las reglas. Supongo que era solo su ego, ya que no se lo veía tan genial 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 suficiente potencia, 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 aplicaciones de modo de lanzamiento de prueba de unidad ya que algunos desarrolladores tienen el desagradable hábito de hacer todas las pruebas de unidad con privilegios de administrador.

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

Pero en realidad, creo que la respuesta depende de su contexto, su entorno. Las pequeñas empresas tendrán una respuesta diferente a la agencia gubernamental certificada por ISO.

Sí, pero deben ser conscientes de las limitaciones a las que se enfrentarán sus usuarios cuando ejecuten software en un entorno más limitado. Los desarrolladores deben 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, para que siempre pudiera tener una idea rápida de cómo funcionaba el software en un extremo. máquina del usuario

Los programadores también tienen la responsabilidad de conocer las reglas estrictas de escribir software para usuarios que no son administradores. Deben saber exactamente a qué recursos del sistema siempre se les permite (o prohíben) acceder. Deben conocer las API que se utilizan para adquirir estos recursos.

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

Como administrador de sistemas, estoy a favor de los 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 hacer cambios, instalar aplicaciones, etc. A menudo puede sudo o runas para lograr lo que desea sin siquiera iniciar sesión fuera. También es útil recordarnos qué problemas de seguridad tendrán que atravesar los usuarios finales cuando salgan a producción.

En una nota al margen también es recomendable 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 a ajustes del sistema.

Ningún 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 administrador.

Inicie sesión interactivamente como usuario normal

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

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

Tampoco normalmente inicia sesión en su cuadro de Linux como root, incluso si es probable que tenga acceso de root cuando lo necesite.

Use una cuenta de administrador personal separada

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

Utilice "ejecutar como" y en Vista + UAC para solicitar o solicitar una solicitud e ingrese las credenciales administrativas para tareas y procesos solo cuando sea necesario. La PKI con tarjetas inteligentes o similar puede reducir en gran medida la tensión para ingresar credenciales con frecuencia.

Todos son felices (o?;)

Luego auditar el acceso. De esta manera, hay trazabilidad y una manera fácil de averiguar quién está utilizando las sesiones de servicios de terminal en un servidor de desarrollo / prueba en particular al que tiene que acceder en este momento ...

De acuerdo, 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 sea que se use para la depuración local realmente funciona bien como un usuario normal.

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

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

• Por un lado, tener derechos de administrador disponibles bajo demanda le da al desarrollador el poder total sobre su estación de trabajo cuando sea necesario.

• Por otro lado, el software de Windows tiene una larga historia 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 no administradores es que sus desarrolladores lo ejecuten ellos mismos como usuarios no administradores.

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

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

Solía ​​ser administrador de mi máquina 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 teniendo estos derechos locos ... nunca tuvimos ningún problema. En realidad, resolvimos muchos problemas actualizando db manualmente. Podríamos hacer muchas cosas realmente rápido para los hotfix y los desarrolladores.

Ahora cambié de trabajo. Logré (llorando mucho) ser administrador de mi máquina Windows. Pero el servidor de desarrollo es un servidor de red hat al que nos conectamos usando ssh. Intentar instalar Qt fue una tortura, límites de cuota, límites de espacio, ejecución y derechos de escritura. Finalmente nos rendimos y le pedimos al administrador que lo haga por nosotros. 2 semanas después todavía no hay nada instalado. Me estoy volviendo muy rápido leyendo periódicos y presionando alt + tab.

Solicité derechos de administrador, ya que solo el desarrollador de mi software utiliza esta máquina.

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

-> Intentando explicarle a un gerente no técnico: "No tendré derechos de administrador en los entornos de producción o UAT. Pero mi máquina de desarrollo es diferente. Si tuviera que construir sillas en lugar de softwares, ¿me diría que puedo No pongo las herramientas que quiero en mi taller porque mi taller debe parecerse al lugar donde se usará la silla. Le doy un paquete ejecutable a uat. Las bibliotecas y herramientas que utilicé para construirlas son invisibles para el usuario final o para el tipo que instala el paquete ".

Todavía estoy esperando hoy. Encontré una solución, abrí un entorno de desarrollo, acudí a tu juez en línea favorito, desafíate a ti mismo. cuando alguien mire tu pantalla, te estará viendo programando. ;)

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

Depende de si es necesario que hagan su trabajo. Si es así, otórgueles poderes administrativos sobre su computadora. Si no, entonces 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.

He trabajado 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 al servicio de asistencia y me concedieron derechos de administrador temporal hasta que reinicié. Esto fue un dolor a veces, pero así fue, así que viví con eso. También he trabajado en lugares donde tengo derechos de administrador completos para mi computadora. Esto fue genial, excepto por el tiempo que instalé un software que alojaba el sistema operativo y tuve que llevar mi computadora al servicio de asistencia y hacer que volvieran a crear imágenes del disco duro ...

Personalmente, creo que un ingeniero debe tener derechos de administrador en su computadora, pero con el entendimiento de que si lo arruinan, se puede volver a cargar una nueva imagen de línea de base y perderán todo lo que se hizo desde la línea de base original. Sin embargo, no creo que todos en una empresa tengan derechos de administrador para su computadora. Los departamentos de contabilidad, asistentes administrativos y otros departamentos realmente no necesitan tener esos derechos, por lo que no deben otorgarse.

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

En mi experiencia, siempre se necesita un compromiso entre nosotros (codificadores) y ellos (seguridad). Admito (aunque odio), hay mérito en el artículo de Microsoft anterior. Como he sido programador durante años, he experimentado el dolor en el que 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 frutración cada vez que quiero instalar una utilidad rápida o ajustar mi IIS local para que pueda causar un problema de seguridad grave. No entendí completamente esto hasta que vi a otro desarrollador ser enlatado. Estaba tratando de depurar y terminó apagando Symantec solo para transmitir (y luego DAR) algunos virus a cientos de personas. Fue un desastre. Al hablar con uno de los "secheads" (muchachos de seguridad) sobre lo que sucedió, pude ver que solo quería decir, "te lo dije ...".

He aprendido que nuestras secheads (bueno, al menos las mías) solo quieren proteger a nuestra empresa. ¡La buena noticia es que encontramos un compromiso, y puedo hacer mi trabajo y las búsquedas son geniales con nuestra red segura!

Credo

Sí, si desea que los pentesters o algunos usuarios malintencionados capacitados se asienten en comprometer su dominio.

es decir, comprometer una cuenta de bajo nivel> Buscar dónde admin -> Mimikatz -> Elevar permisos -> Administrador de dominio.

Entonces no, los usuarios normales no deberían ser administradores.

También Microsoft ha dicho que UAC no es un límite de seguridad, así que no lo use como tal. Hay varias derivaciones del mundo real de UAC disponibles.

Si necesitan administrador como parte de su función de trabajo, proporcione cuentas de usuario de administrador local de dominio separado que se usan solo para instalar software (con permisos de administrador solo en su propia máquina), nunca para uso general o acceso a Internet. Esto debería tener una política de contraseña más estricta (por ejemplo, 15 caracteres de longitud mínima). La funcionalidad Runas se debe utilizar para esto.

Cualquier entorno en el que las cuentas de usuario normales sean admin es una receta para un desastre de seguridad.

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

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

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

Si está desarrollando software de escritorio, no es una mala idea que los desarrolladores trabajen dentro de los límites que experimentarán sus usuarios finales, es decir, derechos limitados o restringidos. Si crea el software con derechos limitados, es muy probable que encuentre los mismos problemas a los que se enfrentarían sus usuarios objetivo con el mismo conjunto de permisos.

Dicho esto, si tiene un buen laboratorio de pruebas y / o un equipo de control de calidad decente, este podría ser un punto discutible, especialmente si tiene una práctica de ALM medio decente.

Finalmente, me 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 :)

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, en caso de que ese bus rebelde (o lo abandone) me golpee. Todos los demás quedan encerrados.

Como administrador de sistemas, 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 fondo de desarrollador, entiendo la necesidad de que los usuarios avanzados tengan más control sobre su entorno y, como tal, estoy dispuesto a soportar las peculiaridades o problemas ocasionales que puedan surgir. Realizo copias de seguridad de rutina de sus estaciones de trabajo, por si acaso.

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

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

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

Nadie en Windows XP debería usar una cuenta de administrador para el uso diario, y en Vista, si debe ser administrador, al menos debe tener UAC habilitado. 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 normal, pero les dé una segunda cuenta que sea un administrador en su PC para que puedan usarla según sea necesario (Ejecutar como). Sé que dijeron desarrollo web, pero para el desarrollo de Windows su software debe probarse utilizando una cuenta de usuario normal, no como administrador.