En todos los lugares donde he trabajado (como desarrollador por contrato), los desarrolladores tienen derechos de administrador local en sus escritorios.

Las razones son:

1) Los conjuntos de herramientas de los desarrolladores a menudo se actualizan con mucha frecuencia. Bibliotecas gráficas, ayudantes de código, actualizaciones de visual studio; Terminan teniendo actualizaciones que salen casi semanalmente que necesitan ser instaladas. El soporte de escritorio por lo general se cansa de obtener 20 tickets cada semana para instalar el software actualizado en todas las máquinas de desarrollo, por lo que solo le dan a los desarrolladores el derecho de hacerlo por sí mismos.

2) Las herramientas de depuración / prueba a veces necesitan derechos de administrador para poder funcionar. Ningún acceso de administrador significa que los desarrolladores no pueden hacer su trabajo de depuración de código. A los gerentes no les gusta eso.

3) Los desarrolladores tienden a ser más conscientes de la seguridad y, por lo tanto, tienen menos probabilidades de ejecutar / instalar malware peligroso. Obviamente, todavía sucede, pero en general se puede confiar en que todos los desarrolladores tengan acceso de nivel superior para poder hacer su trabajo.

Esto depende en parte del tipo de software que se espera que desarrolle el equipo de desarrollo. Algunos tipos de software son más fáciles de desarrollar sin derechos administrativos que otros.

Por ejemplo, puede hacer una buena cantidad de desarrollo de Java basado en la web utilizando Eclipse con artefactos de Maven, todos instalados localmente (y generalmente probados en el puerto 8080), sin necesidad de muchos derechos de administrador (es posible que necesite abrir ciertos puertos). Desarrollar herramientas que necesiten un acceso más cercano al hardware puede resultar imposible sin los derechos de administrador. Dicho esto, incluso para el desarrollo web, es una buena práctica poder reconstruir una máquina de prueba desde cero (normalmente una máquina virtual), que puede necesitar derechos de administrador.

Si se trata de confianza (es decir, algunos miembros de tu equipo de desarrollo podrían tener intenciones maliciosas), estás en problemas de todos modos. Es poco probable que los administradores de sistemas que aprobarían / rechazarían ciertos derechos podrán verificar en detalle lo que hace el código que han escrito. Eso no significa que tampoco debe dar a su equipo de desarrollo acceso sin restricciones a sus servicios de producción, ni que tengan acceso de administrador en más máquinas de las que necesitan, por supuesto. Es bueno contar con mecanismos para mitigar los riesgos, pero necesitará un nivel básico de confianza para que su organización funcione. Poner al equipo de desarrollo en una red física separada es un primer paso para mitigar los problemas de confianza y los posibles errores.

Un riesgo típico de tener alguien con acceso de administrador es poder capturar paquetes en la red. Este es un riesgo que puede tener que aceptar dependiendo de la naturaleza de lo que se haya desarrollado. Herramientas como Wireshark pueden ser útiles para el desarrollo a veces. Incluso dentro de su organización, las personas de TI o no de TI deben usar los servicios con SSL / TLS habilitado, si es posible, esto debería ayudar a evitar las escuchas ilegales y los ataques MITM.

Puedo pensar en algunas desventajas cuando no doy acceso de administrador a los desarrolladores (a menos que realmente no lo necesiten):

• Puede crear una cultura "them v.s. us" entre los desarrolladores y los administradores de sistemas de su organización. Esto ya existe en muchos lugares, pero generalmente no es algo bueno. Es probable que cada equipo considere al otro como un dolor. La seguridad no es un problema puramente técnico, sino también una interacción humana. Creo que una buena comunicación humana debería ayudar a los objetivos generales de su organización en general, no solo desde un punto de vista de seguridad, de hecho. (Siempre he encontrado que puedo encontrar mejores soluciones después de hablar en persona con los administradores de sistemas con quienes necesitaba resolver problemas en lugar de responder a un boleto sin rostro).

• La naturaleza humana es tal que las personas se vuelven creativas cuando están limitadas, pero no necesariamente de la manera correcta. Puede encontrar que los desarrolladores terminan poniendo una gran cantidad de esfuerzo (y, a menudo, lo logran) evitando las limitaciones que se les imponen dentro de la organización. Deberían usar su creatividad en lo que deben hacer en su lugar.

• Los sistemas de TI son complejos y la depuración es un arte oscuro. Si necesita depurar su producto con la biblioteca XYZ versión a.b.c_13 y a.b.c_24, es posible que los desarrolladores tengan que poder instalar y desinstalar cada versión, lo que a su vez puede requerir acceso de administrador. Perseguir los errores que dependen de los números de versión ya es molesto. Si tiene que levantar un boleto y esperar (quizás horas o días) para que otra persona instale / desinstale la versión correcta, se convertirá en una pesadilla: aumentará el problema cultural "ellos contra nosotros" y, lo que es más importante, costará Más a la organización. Puede pensar en esto desde una perspectiva de evaluación de riesgo / costo.

El riesgo es una función creciente del acceso

Hay una regla simple de cálculo de riesgos que explica el temor de sus colegas del equipo de TI. Cuanto más acceso tengas en cualquier sistema operativo cuanto más altos son los impactos de cualquier error o ataque.
Por ejemplo, si uno de sus colegas, digamos Bob, es atacado a través de un ataque de phishing estándar, Entonces la cuenta de Bob está disponible para los ciberdelincuentes y se vende en Internet. en minutos. Si la cuenta de Bob tiene privilegios de administrador, entonces esta cuenta se utilizará para enviar SPAM a gran escala en Internet, luego, para robar otras cuentas con ataques de phishing a gran escala, y muy rápidamente (en minutos) se abrirá una puerta trasera a su red (esto es posible porque la cuenta de Bob es de administración) permitiendo el control remoto total de la PC de Bob ( a través de herramientas como ssh , VNC , VPN ...). Este ataque iniciado desde una PC interna, desde una cuenta privilegiada es capaz de romper cualquier cortafuegos, detener cualquier antivirus, protección antispam.

  

El mal está dentro .

Incluso sus mejores administradores de red, administradores de sistema o administradores de seguridad puede dejar esta PC dañada sin ser detectada durante meses (consulte Stuxnet ).

Reducción de riesgo falso

Si sus colegas desarrolladores son buenos en la gestión del sistema operativo en el que funciona, y tiene un acceso físico a la computadora, entonces esta diferencia en el riesgo es nulo.

  

Cualquier ingeniero en cualquier sistema operativo puede otorgarse acceso de administrador
     si tiene acceso físico a la computadora.

El bloqueo del acceso de administrador en cualquier SO es un enfoque válido de reducción de riesgos para Los usuarios que no pueden hacer una diferencia entre los privilegios de administrador y privilegios de usuario normales.   Aquí está la pregunta clave que le haría a sus colegas del equipo de desarrolladores.   y actuar sobre su conciencia de riesgo:

  

"De qué te ocuparás si te conceden
  privilegio de administrador en su sistema operativo? "

Si son lo suficientemente buenos para ser conscientes de los riesgos, entonces son lo suficientemente buenos para obtener el acceso que quieren. Entonces no hay reducción de riesgo en rechazar Ellos tienen este acceso de administrador. Cuidado: existe un riesgo colateral para su compañía en general si les niega un acceso que pueden obtener fácilmente: lo harán de forma sucia, se comportarán como proscritos, no podrán pedir ayuda, no podrán hacerlo. Tendremos que cubrir cualquier contratiempo.

Algunas cosas que no se han mencionado en las respuestas y comentarios anteriores serían un argumento para los desarrolladores que trabajan con el menor privilegio:

1. Dependiendo de la industria en la que esté trabajando, puede haber razones legales o reglamentarias que impiden que los empleados tengan privilegios elevados en sus estaciones de trabajo. Permitir el acceso administrativo a los desarrolladores podría poner a la organización en riesgo de estar fuera de cumplimiento.

2. Cuando los componentes se desarrollan con privilegios elevados, puede haber un riesgo de falla durante la implementación en otros entornos que no tienen esos privilegios. Los desarrolladores pueden haber actualizado o agregado inadvertidamente bibliotecas a sus máquinas locales que no existen en otros entornos, y los componentes pueden tener dependencias en versiones específicas de esas bibliotecas. Además, las cuentas de usuario bajo las cuales los componentes se ejecutarán en otros entornos pueden no tener la base de datos requerida u otro acceso que asumió el desarrollador que trabaja con privilegios elevados. He visto esto suceder muchas veces en el pasado. A veces es obvio por qué la implementación falló, a veces no, y tienes que revertir todo hasta que puedas resolverlo.

3. Si los desarrolladores instalan bibliotecas o herramientas de código abierto y las utilizan para el desarrollo, podría haber restricciones de licencia no intencionales sobre cómo se distribuye el software que producen, especialmente cuando los términos "copyleft" son parte de la licencia. No hay nada de malo en usar herramientas o bibliotecas de código abierto, solo debe ser intencional. No desea saber en el momento de la entrega que ahora necesita liberar todo el código fuente a la comunidad porque sus desarrolladores usaron algún componente de código abierto que tenía términos de copyleft estrictos en la licencia que realmente no leyeron antes de lo instaló.

Algo que he visto hacer es hacer que los desarrolladores trabajen con menos privilegios, pero les permite solicitar privilegios elevados durante un período de tiempo específico. Luego, esta solicitud de "llamada de fuego" para privilegios elevados se registra y monitorea, y se restablece automáticamente al final del tiempo solicitado.

Usted les otorga derechos de administrador local a su estación de trabajo y cualquier otra cosa que deseen. El entorno de desarrollo siempre está aislado de la red principal. El trabajo de TI es asegurarse de proporcionarles la configuración que necesiten y asegurarse de que nada en el entorno de desarrollo pueda dañar la red principal. Planee con anticipación y trabaje con la administración para comprar el equipo / software que necesita para lograr esto.

Tiene algunas preguntas que responder.

1. ¿Qué aplicaciones necesitan estos desarrolladores para usar a diario requieren privilegios de administrador y hay alguna forma de configurar estas aplicaciones para que no sea así?
2. ¿Por qué razones estos desarrolladores necesitan privilegios de administrador para realizar tareas diarias triviales y hay una manera de evitar esto?
3. ¿Estas máquinas desarrolladoras están conectadas a Internet?

La pregunta no debería ser cuáles son los riesgos, la pregunta debería ser (a la que solo puede responder) cuáles son las razones por las que los desarrolladores necesitan tener una cuenta de administrador. Puede tener una cuenta de "usuario avanzado" y darles la capacidad de hacer exactamente lo que necesitan, pero también limitar su capacidad de dañar su red.

Si estas máquinas están conectadas a Internet ... entonces, se presentará un gran riesgo debido a su capacidad para ejecutar cualquier cosa e instalar cualquier cosa en estas máquinas. Estos desarrolladores son buenos desarrolladores, no son expertos en seguridad, es solo una cuestión de CUÁNDO cometerán un error que exponga la red a malware.

Eche un vistazo a Google, por ejemplo. Un empleado de Google hizo clic en un enlace contenido en una ventana de MSN Messenger, descargó el malware que aprovechó un exploit que ya había sido reparado por Microsoft e infectó toda la red.

Debería agregar que el empleado de Google que hizo clic en el enlace no tuvo nada que ver con esta pregunta, fue para señalar que la gente cometerá un error, así que limite su exposición.

Los riesgos de seguridad asociados con proporcionar a los desarrolladores la capacidad de instalar sus computadoras son numerosos. Aquí es por qué me opondría (hablando como administrador del sistema)

1) Violación potencial de las mejores prácticas de seguridad : una de las 8 reglas de seguridad es la regla de privilegio mínimo. Solo dé a los empleados acceso a lo que necesitan para completar su tarea. Si alguien me dijera que sus desarrolladores necesitaban acceso de administrador para instalar el software para hacer su trabajo, respondía con "¿Por qué uno de mis empleados no puede instalarlo por ellos?". Tener un punto centralizado para instalar el software garantiza que un departamento de TI sepa exactamente qué software está en qué máquina.

2) Razones legales : quizás uno de tus desarrolladores tenga una ética menos que admirable y decida instalar un software pirateado. No solo es probable que ese software esté plagado de malware, sino que también puede abrir una gran cantidad de gusanos para litigios en caso de que lo atrapen con software pirateado en su computadora. Se considera que un departamento de TI es responsable de esas computadoras y, como tal, son responsables de auditarlas y garantizar que las licencias cumplan con los TOS de cada pieza de software. Si bien es conveniente para los desarrolladores que puedan instalar su propio software y no molestar al departamento de TI, usted crea mucho más trabajo para el departamento de TI.

3) Instalación no intencional de Malware : mencionada anteriormente, pero esto podría ser lo suficientemente inocente. Elevar los privilegios de los usuarios para que puedan instalar malware los hace susceptibles a los maliciosos al abrir un PDF infectado que obtuvieron a través de un correo electrónico o una unidad de descarga. Limitar el acceso de los usuarios para que no puedan instalar el software ayudará a mitigar la amenaza de malware.

4) Actividad malintencionada : es similar al punto 2, pero lo que quiere decir es que uno de sus desarrolladores no instalará una puerta trasera o abrirá otra amenaza a la seguridad en su red. Usted se sorprendería de cuántos profesionales de TI hacen esto para vengarse en caso de que sean despedidos o su jefe los moleste.

En general, tendría que aconsejarlo. Si bien la gente puede argumentar que ahorraría tiempo en evitar que siempre intenten que la TI instale el software, yo contrarrestaría que con "toma menos tiempo hacerlo que parchear los agujeros de seguridad creados al permitir que los usuarios instalen su propio software" . Si se considera que esto ES necesario, deberían colocarse en una red que no tenga acceso directo al mundo exterior.

Una solución alternativa es instalar una máquina virtual, no conectada al dominio. Será bastante complicado, pero es mejor que estar totalmente paralizado por las políticas.