¿Es común permitir el acceso de los administradores locales a los desarrolladores en las organizaciones?

Aquí hay un punto de datos de una compañía de software que tiene interés en la seguridad. Sé que esto es común en organizaciones similares.

Hay una serie de redes. Están separados físicamente y con espacios de aire, corren diferentes cables de red codificados por colores.

Cada empleado tiene una máquina de "administración", que puede conectarse a Internet (a través de un proxy) para realizar correos electrónicos, etc. Todos los usuarios están estrictamente bloqueados, y hay un control estricto de dispositivos y acceso.

Además de esto, cada desarrollador tiene una máquina de "ingeniería". Esto tiene acceso de administrador completo, y el usuario puede hacer lo que quiera. Sin embargo, está conectado solo a la red de ingeniería (no hay ruta a Internet).

En la mayoría de los contextos de desarrollo de software, esto podría verse como extremo, pero en organizaciones que tienen requisitos contradictorios de alta seguridad y libertad de desarrollador, esta es una solución común.

Para responder a su pregunta, sí, es común permitir que los desarrolladores tengan acceso de administrador, pero esto no siempre significa acceso de administrador a una máquina que podría causar problemas de seguridad de la información.

En mi experiencia, es común que los desarrolladores tengan acceso de administrador en sus propias máquinas. Es también común para ellos no tener acceso de administrador en sus propias máquinas. Sin embargo, en esta última situación, generalmente se hacen ajustes para que puedan hacer su trabajo sin demasiadas fricciones.

Una adaptación muy común es el acceso a un Hipervisor en la estación de trabajo (ya sea una versión de VMWare o el Hyper-V que viene con Windows), junto con los permisos específicos necesarios para crear y destruir máquinas virtuales. dentro de ese hipervisor según sea necesario ^{( Hyper-V / VMWare )} , incluida la creación de máquinas virtuales donde tengan derechos de administrador. el sistema operativo invitado. Por lo general, algunas de estas máquinas virtuales tendrán una larga vida útil, incluso si no se ejecutan todo el tiempo, donde nunca se trata de tener que preparar una máquina virtual completa solo para hacer lo que debería ser una prueba rápida con algo que necesita los privilegios de administrador.

El hipervisor puede o no estar configurado para permitir el acceso a Internet para sus máquinas virtuales; Lo he visto de ambas maneras, aunque personalmente estoy a favor de que se permita el acceso a Internet debería ... al menos para los tipos de desarrollo con los que tengo más experiencia. Pero el acceso a Internet, cuando se otorga, puede y debe configurarse, como mínimo, para obligar a las máquinas virtuales a una vlan dedicada, separada del resto de la red corporativa. No estoy seguro de que esto sea posible de aplicar directamente a través de Hyper-V o VMWare, pero puede usar 802.1x en los puertos para muchos conmutadores de red para evitar el acceso a ciertos vlans desde máquinas no autorizadas, incluidas las VM de Devloper. Luego, puede dar un pequeño tutorial a los desarrolladores sobre cómo establecer una etiqueta vlan en una máquina virtual y hacerles saber qué etiquetas vlan se permitirán en su puerto de switch. También he visto que esto se aplica simplemente como un decreto de política, en lugar de a través de medidas técnicas.

Y, por supuesto, esto coincide con proporcionar a los desarrolladores máquinas suficientemente potentes para ejecutar varias máquinas virtuales a la vez.

Trabajo para una empresa de gestión de inversiones bastante grande (~ 6000 empleados) y los desarrolladores son uno de los grupos que aprobamos para el acceso de los administradores locales. Les decimos que no instalen ningún software, ya que esto se maneja mediante el cumplimiento del software / escritorio local.

También tenemos un grupo de desarrolladores de AD que permite a los miembros cambiar la política de ejecución en sus máquinas sin necesidad de administración local.

En mi carrera, con compañías bastante pequeñas (menos de 100 personas), siempre tuvimos derechos de administrador local. O bien tenemos máquinas de escritorio reales que son mantenidas por TI, pero obtuvimos los derechos, o nos permitieron tener máquinas virtuales de todo tipo que completamente gestionamos por nosotros mismos.

Si no tuviéramos acceso de administrador local, probaríamos todo tipo de "soluciones" malas que, como en su caso, llevan a menos seguridad. Este es uno de esos casos, que las restricciones en realidad llevan a lo contrario de su intención.

En un departamento bastante pequeño de una organización más grande (~ 100 en el departamento, ~ 3500 en la organización completa), elegimos una solución en el centro :

• los administradores de sistemas tenían 2 cuentas, una (no administrador incluso para la máquina local) que se usaba para tareas no administrativas (correo, edición de documentos, etc.) y otra con privilegios de administrador de AD que se suponía que solo se usaba para la administración de AD
• todos los demás usuarios tenían una sola cuenta que no era administrador
• devs (y algunos usuarios avanzados ) recibieron una cuenta local con privilegios de administrador de la máquina local. Se suponía que rara vez se usaba cuando se requería la administración local.

Rehusar los derechos de administrador a los desarrolladores será una causa de pérdida de productividad, y eso tiene un costo inmediato para cualquier organización. La elección de otorgar privilegios de administrador en la máquina local a la cuenta principal o a una cuenta secundaria debe depender de la frecuencia de operación del administrador:

• Si es más de varias veces al día, aconsejaría usar la cuenta principal.
• Si menos de una vez a la semana, usaría una cuenta secundaria.

Elige el tuyo si estás entre ...

En mi experiencia, permitir y deshabilitar el acceso de los administradores locales es común, tan común como las soluciones sucias para este último. - Entonces deberías preguntarte:

¿Qué amenaza a su red empeora con los derechos de administración local?

La respuesta debe ser: NINGUNA : el acceso a los recursos en su red debe restringirse por usuario, sin relación alguna con el hecho de que este usuario tenga una raíz local, administrador o masterOfTheUniverse. Acceso en su máquina. Si el usuario tiene derechos para explotar su red, un virus local ni siquiera necesita acceso de administrador, solo puede usar la cuenta de usuario para explotar su red. - Y si la cuenta de usuario no puede acceder a algo en su red, los derechos de administrador local no cambiarán nada al respecto.

Debería confiar en que sus desarrolladores manejarán su propia máquina de manera responsable, y con una configuración de seguridad razonable en su empresa, los derechos de administrador local deberían ser peligrosos solo por una cosa: la máquina local. Por lo tanto, el único riesgo que acepta al dar un administrador local es que un desarrollador rompe su propia máquina (lo que ya puede hacer con una taza de café).

Anexo: Debería otorgar a sus desarrolladores la posibilidad de usar los derechos de administrador local cuando lo necesiten. Esto no significa que deban iniciar sesión con una cuenta de administrador no segura todo el tiempo, pero debe confiar en que lo usen con sensatez cuando lo necesiten, sin pedir permiso cada vez.

Por qué los desarrolladores deben tener derechos de administrador locales

Sus desarrolladores son personas a quienes usted confía el diseño de las operaciones centrales de su negocio. La mayoría de las empresas de hoy dependen mucho de su software, por lo que los desarrolladores son un recurso vital para dar forma a una parte muy importante de su empresa.

Primero, existe el beneficio de una mayor productividad, porque el desarrollador solo puede configurar, instalar y probar todo lo que necesita en su máquina local. Es posible que necesite cierto software, herramientas de ayuda o configuraciones inusuales para experimentar con ciertos aspectos de su software (por ejemplo, ejecutar su software en una versión más antigua de un sistema operativo o con controladores / SDK más antiguos).

En segundo lugar, existe el beneficio (en mi opinión, aún mayor) de mostrar a sus desarrolladores cómo los valora. Les muestra que confía en ellos con su propia máquina; trata a sus desarrolladores como personas responsables y conocedoras de TI que pueden administrar su propia máquina sin una niñera. (En muchas compañías donde los desarrolladores no obtienen administradores locales, tendrán que solicitar soporte técnico o seguridad para cada instalación / configuración que necesiten. Y en muchos casos, estas personas de soporte técnico saben menos sobre el software que su desarrollador principal. , pero todavía tienen que rogar por cosas que simplemente necesitan para hacer su trabajo, lo que puede ser muy frustrante.)

En mi experiencia de trabajo para organizaciones más grandes, no es absolutamente común que los desarrolladores tengan todos los derechos para cualquier otra cosa que no sean recursos específicos de desarrollo.

Parece que su organización está en la frontera entre pequeñas y grandes, así que ...

Parece que es hora de que su organización desarrolle prácticas de desarrollo más maduras.

Para ser justos, este tipo de cambio no es algo con lo que los grupos de operaciones deberían sorprender a los equipos de desarrollo, como parece que se hizo en su caso.

La seguridad y la productividad del desarrollador no tienen por qué oponerse entre sí para su empresa. Puede evitar este choque completamente realizando sus actividades de desarrollo en una red que no tiene acceso a los recursos en su red de negocios principal.

De todos modos, no está haciendo desarrollo contra sus activos de producción, ¿verdad?

Si es así, no debería hacerlo, ya que presenta un riesgo significativo para sus activos, en particular para su disponibilidad.

Una práctica mucho mejor es tener una configuración completa del entorno de desarrollo que replique partes clave de la funcionalidad y los conjuntos de datos (sin exponer algo como información privada sobre personas reales en su empresa). Este entorno replicado hace que la separación sea bastante simple. Sus desarrolladores necesitan un control total de las máquinas en este entorno de desarrollo. No necesitan un control total de los activos fuera del entorno de desarrollo.

Hay varias formas de implementar un entorno de desarrollo separado:

• Hardware completamente separado (estaciones de trabajo, servidores, dispositivos de red, etc.), conectado a Internet o no
• entornos virtualizados (incluidas las redes virtuales); alojado en su hardware o con un proveedor de servicios en la nube y con o sin acceso a Internet
• Una combinación de los dos enfoques anteriores

También puede implementar algún tipo de puente (si aún no está utilizando un servicio de algún tipo) para cualquier uso compartido que necesite hacer dentro y fuera del entorno de desarrollo.

Los entornos de desarrollo deben estar protegidos como la mayoría de las redes. No solo coloque en línea todos sus recursos de código y desarrollo sin pensar en el control de acceso o en medidas de seguridad básicas.

También he visto que algunos lugares llevan esto un paso más allá y escriben todo su código en un entorno, luego lo crean / implementan en otro entorno completamente separado para las pruebas de integración.

Primero que todo, debes aprender que no importa qué "es común" o "típico" porque: por lo general, estas situaciones se manejan de forma horrible . Usted está haciendo el mejor caso para esta declaración.

Si el acceso de la administración local es necesario para una persona (ya sea un contratista o un empleado), es obligación del equipo de seguridad / persona, quien esté a cargo de esa área en particular, encuentra una solución. Hay varias soluciones: la creación de una VLAN aislada, las máquinas virtuales y otras se mencionaron aquí.

No tiene ningún sentido preguntar por la configuración de otras organizaciones solo para escuchar "también tenemos derechos de administrador en nuestras máquinas". No encontrará una infraestructura que sea exactamente igual a la suya. Lo único que importa es que el equipo de seguridad / persona planea una solución segura que luego es implementada por el departamento de TI en la organización esta en particular .

Si la solución que se ha implementado no funciona correctamente y, por lo tanto, aún no puede trabajar, vuelva a plantearla al equipo de seguridad / persona. Si esto no funciona, llévelo a su jefe o a su representante.

Lo que estás haciendo en este momento es quemar dinero y nada más. Si los otros participantes en este juego no han descubierto esto, es malo. Pero es bueno si lo haces.

Esto depende fundamentalmente del contexto, y en particular de su modelo de amenaza.

En algunas organizaciones, es común otorgar a los desarrolladores un control completo sobre su estación de trabajo de desarrollo, hasta el punto de permitirles instalar su propio sistema operativo en él.

En algunas organizaciones, todo el desarrollo debe realizarse en un entorno con espacio de aire, para que ningún dispositivo electrónico pueda entrar o salir.

La mayoría de las organizaciones se ubican entre estos dos extremos. Cuanto más cerrado esté el entorno de desarrollo, menos productivos serán sus desarrolladores y más probabilidades tendrá de perder su mejor talento. Su organización debe evaluar la probabilidad y el impacto de una estación de trabajo de desarrollador comprometida y cuánto están dispuestos a reducir la productividad del desarrollador para mitigar este riesgo.

He visto dos enfoques que funcionan.

1. Proporcione a los desarrolladores acceso de administrador a sus máquinas. Este es el enfoque más fácil y más común. Generalmente es la mejor opción
2. Cree un equipo en la organización cuyo trabajo completo sea garantizar que los desarrolladores puedan trabajar sin acceso de administrador. Este equipo suele ser de 3-4 personas. Encontrará que los requisitos de hardware del desarrollador aumentan dramáticamente a medida que va a utilizar contenedores y máquinas virtuales, por lo que el presupuesto para la compra de hardware nuevo para todos los desarrolladores. Cuando se lance, comience con un equipo de adoptadores tempranos, luego mueva gradualmente a todos sus desarrolladores a una máquina sin acceso de administrador. Este proceso llevará al menos seis meses.

Si haces lo que tu compañía está haciendo ahora, tus desarrolladores lo soportarán por un mes o así y luego comenzarán a buscar nuevos empleos.

El problema que realmente tiene es competente, ya que está intentando imponer una regla de cabeza dura. Realmente solo tiene una opción, dar a los desarrolladores un acceso de administrador efectivo.

Sigo viendo que el mismo consejo se repite una y otra vez, que se reduce a una segunda máquina que el desarrollador tiene admin pero no tiene internet. Si quieres tener seguridad de queso suizo, ese es el camino a seguir. Las listas de software instaladas en la computadora de un desarrollador típico suelen ser más largas que una pantalla. Muchos de estos solo tienen una opción para buscar actualizaciones: internet. No puedes parchearlos a través de WSU porque WSU no sabe que existen.

Esto es lo que los argumentos no entienden: violar las cuentas personales del desarrollador no es un punto de lanzamiento; es el premio gordo No hay razón para ir de administrador desde allí. La brecha tiene capacidad para modificar el código para insertar puertas traseras. Obtener administrador en la caja del desarrollador no es mucho más interesante.

¿Contra qué estás defendiendo cuando quieres negar al administrador? ¿Alguien accede a la base de código? ¿Alguien lo está utilizando como punto de partida? Si su LAN de producción no está protegida de sus cajas de desarrollo, está haciendo algo mal. ¿Los desarrolladores instalando cosas que no deberían? No. El desarrollador tiene un compilador y ejecuta el código de salida del compilador. Esta podría ser también la definición de ejecutar software no aprobado.

He escuchado muchas historias de que la política es que los desarrolladores no se administran, pero la práctica de las TI es de otra manera mientras que los desarrolladores anularon la política de seguridad. He escuchado muchas más de las IT que ni siquiera lo descubrieron. He escuchado a algunos de los gerentes de desarrolladores que le dicen a los desarrolladores que omitan las comprobaciones de seguridad.

Tarde o temprano, las organizaciones aprenden a dar simplemente a los desarrolladores la administración. La mayoría de los que probablemente no terminen de hacerlo sin saberlo realmente.

Es mucho más inteligente simplemente dar a los administradores locales en una caja conectada a Internet y al dominio local y estar preparado para lidiar con las consecuencias que puedan ser. Proteger la producción en su lugar. Hay menos personas que deberían acceder a la producción con un alto nivel de privilegio, por lo tanto, el bloqueo es más fácil y las organizaciones competentes aprenden a hacerlo.

Pero, de repente, quitar este tipo de administrador casi siempre provoca la pérdida de los desarrolladores más importantes. No quieres eso.

Ya que quiere hablar sobre los sitios de Windows, hay una anécdota que supera los datos de la mayoría de las personas. Microsoft le da a sus devs el administrador local. El fabricante de Windows ha llegado a la conclusión de que no hay beneficios suficientes para no dar administradores a los desarrolladores para que valga la pena. Por lo tanto, debes hacer lo mismo.

Trabajé durante un tiempo para una empresa que realmente cree en la seguridad (o eso creen).

De vez en cuando organizaban un evento social, como jugar bolos. La inscripción fue gratuita, pero tuvo que agregar su nombre a una lista en un archivo de Excel, colocado en una carpeta compartida. Esa carpeta estaba dedicada a eventos sociales, nada más.

Entonces, ¿quieres jugar bolos? ¿Quieres añadir tu nombre a esa lista? Ohhhhhhhhhh, querida ... No es que puedan dejar que todos editen ese archivo, ¿verdad? Tienes que pedir los permisos apropiados.

Este es el procedimiento:

• Abra el sitio de la compañía
• Encuentre la sección con algunos módulos listos para ser llenados
• Busque y descargue el documento llamado "Hoja de publicación"
• Imprímelo
• Rellénelo con su solicitud y fírmelo
• Entrégalo al secretario
• La secretaria llevará todas estas solicitudes al gerente la mañana del día siguiente
• Tarde o temprano el administrador lo firmará
• El secretario te lo devolverá
• En este punto, puedes escanearlo
• Abra el sitio utilizado por el departamento de TI para gestionar los tickets
• Cree un ticket que describa (nuevamente) lo que necesita y adjunte la Hoja de publicación escaneada. No olvide establecer la urgencia, de una hora a dos semanas.
• Eventualmente, la TI lo hará (con suerte)

En promedio, tomaría de 3 a 4 días para hacerlo. En algunos casos, semanas. Realmente eficiente, ¿eh? Oye, ¿solicitó acceso a una determinada carpeta pero se olvidó de mencionar la subcarpeta? ¡DECIR AH! ¡Has ganado otra ronda! ¿Y adivina qué? Dado que estaban siguiendo algún proceso de control de calidad, estaban organizando documentos en muchos de diferentes carpetas. Cuando venía un nuevo colega, podía pasar semanas tratando de obtener todos los permisos que necesitaba.

Ahora.

• ¿Crees que los gerentes se molestaron en verificar lo que estaban firmando? Ciertamente no. Reconocieron la hoja de lanzamiento, y eso fue todo.
• ¿Crees que las secretarias estaban revisando mucho más? Tal vez lo intentaron, pero ¿pueden realmente entender las implicaciones de darme permiso de lectura / escritura en una carpeta determinada en una máquina determinada? Ciertamente no.
• ¿Crees que al IT le importaba la urgencia? Ciertamente no.

Entonces, ¿a qué condujo este enfoque? Que si deseaba robar todo lo que la compañía había hecho, solo tenía que traer un dispositivo USB y conectarlo a su PC. ¿No tiene acceso a esa carpeta "Confidential_Documents"? Solo pídelo, lo firmarán. ¿Y si es urgente? "Hola, necesito ese documento pero no puedo acceder a él, ¿me puede dar su contraseña?"

Entonces, este "modelo de seguridad" era increíblemente lento, torpe y frustrante, y no protegía sus propiedades en absoluto, pero al menos nadie podía meterse fácilmente con los participantes en el evento de bolos ( xkcd obligatorio ).

Por favor, no seas esa empresa. Como han dicho otros: no preguntes si es común (lo es), solo pregunta si tiene sentido. Y la respuesta es: no, no es así, a menos que a su empresa le guste quemar dinero.

Sí y no: nuestros desarrolladores senior tienen una cuenta de administrador separada que les permite elevarse cuando sea necesario e instalar aplicaciones / actualizaciones. Sin embargo, no se les permite iniciar sesión en la computadora con la cuenta. Su cuenta de administrador también les permite el acceso de administrador a las computadoras de desarrollo normal para proporcionar un soporte más rápido que a través del equipo de TI.

Todo esto se combina con una aplicación de lista blanca / negra, políticas de contraseña segura, prohibición de dispositivos extraíbles, servidores proxy de pasarela, políticas de DLP, reglas de AV estrictas y más. Sus máquinas son auditadas rutinariamente y la visibilidad del equipo de TI es alta.

Personalmente, prefiero que los desarrolladores no tengan acceso de administrador local. Podríamos investigar las aplicaciones que necesitan UAC (averiguar las carpetas, regkeys, etc. que necesita) y mitigar el indicador de UAC, pero eso requiere tiempo e investigación y no todas las empresas tienen los recursos para hacerlo. Entonces, nos encontramos con ellos a mitad de camino y esperamos una confianza bidireccional. También utilizamos múltiples productos corporativos para hacer cumplir una multitud de reglas, por lo que hay algo de alivio en eso.

Resolvimos este problema mediante el uso de una máquina virtual .

Cada desarrollador tiene una cuenta de usuario normal sin ningún derecho de administrador. Dentro de esa cuenta de usuario hay una máquina virtual sin acceso a Internet. Dentro de la máquina virtual, el desarrollador puede ejecutar su aplicación con derechos de administrador.

De esa manera podemos separar el acceso a Internet y los datos importantes del uso de los derechos de administrador y al mismo tiempo obtener una manera de ejecutar los programas necesarios en un entorno cerrado.

Estoy en el mismo barco que los desarrolladores de software. Nuestra empresa recientemente pasó de estaciones de trabajo con acceso de administrador a máquinas virtuales sin. Fue un impacto tan grave en nuestro flujo de trabajo que muchas veces me encontré sin hacer nada más que leer artículos para que el departamento de TI ejecute algo como administrador para mí.

Lo que a la administración se le ocurrió fue un enfoque de dos máquinas virtuales .

Una de nuestras máquinas virtuales era una máquina de negocio básico con correo electrónico, acceso web y Microsoft Suite. Esto satisfizo la necesidad de comunicarse.

La otra máquina virtual tenía derechos de administrador local , pero estaba desconectada de Internet por completo . De esa manera, no podíamos descargar nada en esa máquina. (Aunque todavía podemos descargarlo y copiar la descarga a través de ...) Todavía tenemos acceso a sitios internos y en la lista blanca un par de cosas que utiliza Visual Studio (Nuget, Symbols, etc.)

Ese enfoque dejó al departamento de TI satisfecho en términos de seguridad, al tiempo que nos devolvió el acceso de administrador.

Lo único negativo es que no podemos usar nuestros monitores duales para una sola máquina, ya que necesitábamos que cada máquina estuviera en su propio monitor, pero en general solo usamos una pantalla para el código y la otra para la navegación web de todos modos.

Respuesta corta : Sí, es común tener acceso de administrador local a grupos seleccionados, como desarrolladores o administradores de TI. Básicamente, las personas cuyo trabajo diario es mucho más fácil con acceso de administrador, mientras que el empleado de oficina habitual lo necesitaría una vez al mes como máximo y, por lo general, mucho menos que eso.

Respuesta larga : depende ...

Para la población general de usuarios, no es necesario realizar un análisis completo de riesgos para comprender que el acceso de administrador tiene muchas posibilidades de que las cosas salgan mal y pocas ventajas para compensar ese riesgo.

Sin embargo, para los desarrolladores (y algunos otros grupos), definitivamente se justifica un análisis de riesgo, y se solicita una decisión adecuada sobre el asunto basada en los hechos, circunstancias, apetito de riesgo y situación de amenaza de la empresa. Señalar una "mejor práctica" y hacer una mudanza de talla única para todos, es una anulación por lo general causada por la (s) persona (s) responsable (s) de la seguridad de la información que carecen del tiempo y / o el conocimiento para ejecutar los números y llegar a Una decisión de tratamiento de riesgo basada en hechos.

Eso no significa necesariamente que estén equivocados . Un análisis completo podría muy bien llevar a la misma conclusión.

En el punto en que estás, por lo que escribes, eso es algo desconocido. Puede solicitar que se realice un análisis de riesgo adecuado, agregando su conocimiento experto al costo de la parte de mitigación de la ecuación, poniendo en números la pérdida de productividad y otros efectos de la medida actual. Esto debe sopesarse frente al riesgo que identifican las personas de seguridad de la información.

También hay otras medidas que están relacionadas. Una solución típica que a veces recomiendo (soy un arquitecto de seguridad de la información por profesión, por lo que me hacen estas preguntas regularmente) es separar la red de desarrolladores de la red de oficinas ordinarias para contener el área de mayor riesgo. Refuerza las máquinas de los desarrolladores lo suficiente e insiste en los cortafuegos locales y la protección antivirus actualizada, y estás en contra de los escenarios típicos de ataque. Si su empresa tiene alguna exposición externa, también puede agregar capacitación adicional de concientización para desarrolladores para que no sean víctimas de ataques dirigidos con tanta facilidad.

He supervisado personalmente los entornos de desarrollador de ambos tipos, y con un poco de esfuerzo se puede hacer que ambos funcionen bien. El solo hecho de desconectar de una manera establecida de trabajo lo estaba manejando mal y la reacción de la que formaba parte era de esperar. Pero lo que está hecho está hecho y es probable que sea inteligente no centrarse en eso y mirar hacia el futuro.

A pesar de que MS-Windows NT ha sido un sistema de sistema multiusuario desde su inicio, no es realmente fácil operarlo de esa manera, y los desarrolladores (incluido Micosoft) todavía tienden a ignorar la idea de separación de privilegios. Este tipo de control de acceso está mal documentado, tiende a no aparecer en la capacitación, a menudo difícil de acceder a través de la interfaz de usuario, difícil de auditar, falta de patrones / herramientas para aplicar la separación ...

Para ser justos, incluso en sistemas Unix / Linux, veo que muchos desarrolladores no logran usar la separación de privilegios de manera apropiada tanto para usuarios reales como para servicios. Pero en cualquier plataforma, poner barreras en la forma en que los implementadores separan los privilegios es incluso más contraproducente para la seguridad que otorgarles privilegios de administrador (locales) completos .

Por otra parte, aunque sé poco sobre el desarrollo en MS-Windows, me parece sorprendente que se requiera un privilegio de administrador local para ejecutar Visual Studio. Y si la única razón por la que necesita acceso de administrador es para detener / iniciar servicios o reconfigurarlos, entonces no tengo mucha simpatía por usted, es posible proporcionar este servicio a los usuarios designados sin darles un administrador local. Uno de los grandes cambios en IIS7 fue el administrador delegado capacidad. Y siempre ha sido fácil delegar la reconfiguración de Apache, MySQL y PHP.

  

hubo una breve notificación de cuando se eliminó el acceso de administrador local

Parece que el problema es que el equipo de seguridad que aspira a un nivel de competencia que no pueden cumplir (esto, en mi experiencia, es muy común). No deberían haber impuesto un cambio de política sin realizar una evaluación de impacto adecuada y considerar las mitigaciones por cualquier daño a la productividad / seguridad.

  

Tenemos al menos 2 programas antivirus importantes en todas las estaciones de trabajo

Este es un enfoque muy ingenuo para proteger la integridad de estos sistemas y presenta una imagen de lo que tienes que enfrentar.

  

no parece haber muchas alternativas por ahí

Entrar en una discusión sobre eso probablemente no va a ser muy productivo en este momento.

En general, suena como si estuviera compitiendo con su equipo de seguridad local. No entienden lo que necesitas para hacer tu trabajo, no entiendes cómo cumplir sus objetivos. Y parece que ninguna de las partes está dispuesta a negociar. Ninguna herramienta disponible va a solucionar eso.

Segregue sus redes

Debe tener entornos relativamente aislados para desarrollo, pruebas, producción y negocios. Esto permite que sus desarrolladores tengan privilegios donde los necesitan.

La segregación adecuada evita cambios no autorizados, restringe la propagación de malware e impide la exfiltración de datos.

¿Qué sucede donde?

Desarrollo

La red de desarrollo es donde tiene lugar la codificación. Los desarrolladores deben tener derechos administrativos en caso de que quieran probar fragmentos de código o ejecutar algo sin empaquetarlo para su implementación para probar / prod.

Las computadoras ejecutan IDE, repositorios de origen y aplicaciones / marcos de requisitos previos para sus aplicaciones. Una herramienta de colaboración dedicada u otras aplicaciones específicas para desarrolladores son razonables.

Pruebas

La red de prueba es donde se prueba el código compilado, listo para enviar. Los desarrolladores pueden tener derechos de administrador, pero los administradores regulares del sistema deberían estar implementando aplicaciones.

Las implementaciones deben reflejar lo que los administradores mantendrán en producción para las aplicaciones internas. Deben ser paquetes listos para el cliente para aplicaciones externas (incluido el asistente de instalación y las firmas digitales, aunque utilizando una firma separada para propósitos de prueba para prevenir descargas de accidentes).

Los desarrolladores a menudo necesitan registros de sistema y acceso de depuración, y estas son las únicas razones por las que deben tener derechos de administrador. No deben participar en la instalación, configuración y pruebas a menos que sea absolutamente necesario.

Producción

La red de producción es donde proporciona servicios a clientes y socios. Dado que debe existir un proceso de implementación formal, no hay razón para que se conecte a sus redes de desarrollo / prueba.

Para minimizar los riesgos de malware y cambios accidentales transmitidos por Internet, las cuentas de las redes dev / test / business no deberían tener acceso a la producción si es posible, lo que se traduce en permisos limitados con argumentos ocasionales en la práctica.

Idealmente, esta red estaría completamente aislada, pero en la práctica esto es imposible en un mundo donde los servidores de producción deben interactuar con los sistemas de ventas, facturación, programación, netops y administración de proyectos. Acércate lo más posible al ideal; Es realmente todo lo que podemos hacer.

Negocios

Esta es la red de comunicaciones principal para la empresa.

El correo electrónico, la navegación web y la conectividad de socios conllevan una gran cantidad de riesgos. Sus redes de desarrollo, pruebas y producción deben estar aisladas de estos riesgos en la mayor medida posible.

Detalles, Detalles, Detalles

Es posible que su organización haya sido exagerada. Es más fácil girar el péndulo hasta el fondo que tratar con los innumerables detalles esenciales para una arquitectura de red segura y flexible.

Los desarrolladores pueden tener acceso de administrador a sus máquinas, con un riesgo mínimo para la empresa, si:

1. Hay cuentas separadas y sin privilegios para el acceso a Internet
2. Se utilizan cuentas únicas en cada entorno
3. Las reglas de firewall / ACL restrictivas existen entre los entornos
4. Se implementan medidas de seguridad estándar, como firewall, proxy web, IDS / IPS, etc.

Sus desarrolladores necesitarán cuatro cuentas:

• Cuenta de desarrollo sin privilegios para acceder a los recursos en Internet (si no quieren saltar de la red empresarial, lo que es oneroso)
• Cuenta de desarrollo con privilegios para configurar la estación de trabajo y el código de prueba
• Cuenta de prueba con privilegios para depurar aplicaciones
• Cuenta de negocios sin privilegios para correo electrónico, web, intranet

Si tienes desarrolladores que realizan alguna validación o trabajo de control de calidad, es posible que también necesiten cuentas sin privilegios en el entorno de prueba.

Los desarrolladores no deben tener acceso a la red de producción ni privilegios administrativos en la red empresarial. Si esto es imposible por el momento, entonces esos roles deberían separarse o, de lo contrario, se debería implementar un riguroso proceso de control de cambios.

Es típico que se deniegue el acceso de administrador local a los desarrolladores en compañías donde los desarrolladores son tan inútiles o malintencionados que abusan de esos privilegios, o donde el departamento de "TI y seguridad" es administrado por idiotas idiotas que observan todos los que no están en su círculo interno como una evidente amenaza de seguridad para hacer que se vean mal.

Teniendo en cuenta que su departamento de "TI y seguridad" también exige dos programas antivirus cuando Windows viene con uno gratuito perfectamente bueno, estoy bastante seguro de que puede determinar dónde está el problema en su organización y trabajar desde allí.